When people think about application security in a large organization, big tech companies like Adobe, Cisco, Microsoft, and HPE often come to mind. These companies appear to have cracked the code on how to add security to the software development lifecycle (SDLC). They incorporate secure SDLC (S-SDLC), a series of steps and activities designed to eliminate as many threats and vulnerabilities from a product or application as possible prior to shipment or deployment. And they are vocal about their security programs, providing relevant details about security processes on their websites.
When it comes to healthcare and financial services companies, however, a lack of information might lead you to conclude that these sectors don't have a robust S-SDLC. But if you jumped to that conclusion, you'd be dead wrong.
There is an important distinction between tech and healthcare and financial companies, however. For a technology company, the product it's trying to secure is the primary thing it sells. For healthcare and financial organizations, technology plays a supporting role in their businesses, but their security need is more focused on the data that is captured in the delivery of their non-technology services—helping make people well and handling money transactions.
While some healthcare and financial companies are improving their practices and opening up in the constructive ways that tech sector companies have been doing, the majority of them could still benefit from being more transparent about their practices to prove that they don’t just do the bare minimum to meet regulations. What follows is my in-depth review of the specific security practices I’ve seen in these two industries over the past several years, and seven elements that should be included in the S-SDLC regardless of industry.
A financial services firm is focused on protecting the integrity of the financial transactions being performed by its software. The company must validate and ensure that when a user is making a request, that person is in fact the owner of the account. It must also deal with many syndicates attempting to commit fraudulent transactions. The confidentiality of customer data is also crucial.Financial services organizations have mature traditions in risk management. They leverage a mature risk management process to protect their reputation and maximize profits. Financial services must also balance regulatory policies with the goal of minimizing fines or costs related to violations. Reputation is king, even if it means a slightly higher financial cost or risk. However, historically, these risk management processes don’t extend to IT security beyond the traditional “secure the network boundary” concept.Robb Reck, CISO at Ping Identity and an expert on S-SDLC for the financial world, says:
“In general financial services companies have significantly higher regulatory pressures, so they are forced to document and prove the effectiveness of their controls more frequently than unregulated industries. In a similar vein, tech companies are more likely to utilize agile development, which requires a different perspective on security controls than waterfall.”
Financial services firms are categorized into two distinct groups in terms of their approach to security: those that take security seriously and those that treat security as a compliance or “check box” activity.
An anonymous source shared this insight:
“Upon entering the financial industry from healthcare, I distinctly remember thinking, 'Wow, we protect our money so much better than we protect our health information.'”
Those organizations that take security seriously have a strong S-SDLC with executive-level understanding and support. This support is what enables a holistic strategy for application security as well as the driver to push security to the left in the development lifecycle. Many of these companies participate in BSIMM, a consortium of vendors that share information on the measurement and impact of software security programs.
In contrast, organizations that treat security as a compliance-driven activity have little to no executive-level understanding or support for application security. Anything they do is driven by regulatory oversight. They do what they are forced to do but nothing more. This approach leaves a void in their solutions, as they attempt to place Band-Aids on their programs to cover their lack of application security investment.
Financial services firms are reserved in sharing information about their programs. This stems from their focus on reputation and regulation. As a vastly regulated industry, they do not wish to disclose any more information than they are required to disclose by law.
A secondary issue is that those companies outside of the BSIMM are likely not collecting robust metrics, so they are afraid to share even basic software security information for fear that the immaturity of their programs will look bad in the eyes of their customers.
Healthcare organizations focus their S-SDLC on the confidentiality and integrity of customer data. The customer data that their vast collection of applications protects contains multiple sources of protected health information (PHI). PHI is a close cousin to personally identifiable information (PII). The systems designed and developed within healthcare must protect that information.
The healthcare industry, like financial services, is heavily regulated. The Health Insurance Portability and Accountability Act (HIPAA) drives many of the decisions that healthcare companies make in regards to security.
A major difference for healthcare is around creating tools and practices. Tech companies craft some of their own tools and practices, but healthcare organizations leverage more vendor-provided offerings. As an example, a large healthcare organization may choose to purchase and customize the rules of a commercial static analysis tool to assess its Java code. The technology company may choose to write its own tool for assessing its more proprietary product releases.
Some companies are hiding [their S-SDLC] merely because it could be embarrassingly bad or nonexistent.
The healthcare industry often chooses to not share any information about internal security practices. There are exceptions like Aetna, who has a robust, open security program. However, many other healthcare companies naïvely think that attackers might be able to find flaws in a product if they know too much about how it’s made (the age-old "security through obscurity" maxim). But obscurity in your security development processes provides no benefits.
Attackers do not need knowledge of the S-SDLC process to attack an application. The attackers have what they need: a web browser and a list of security problems that are common in all applications. Hiding the S-SDLC process provides no protection against an active attacker. However, publishing your company's S-SDLC serves both customers and the industry, and does not modify the attackers' plan of attack as they profile an application. Again, some companies are hiding it merely because it could be embarrassingly bad or nonexistent.
Based on the feedback of experts in S-SDLC from healthcare, financial services, and tech, the following list of seven elements represents the recommended items to include within an S-SDLC program. All of these elements were contained in some form on lists submitted from healthcare, financial, and tech representatives.
Application security training is paramount for the success of your company. Provide relevant application security resources for all departments including design, development, testing, and deployment of applications and products.
Threat modeling is the process of brainstorming all the possible bad things that could happen to an application, feature, or product, and then putting in place proper mitigations to counter the threats. Threat modeling is a theoretical and practical exercise. Developers do not have to craft an exploit just to prove that a design change needs to be made. They can examine the potential vulnerability on paper and mitigate before ever writing a line of code.
SAST requires access to your source code to provide automated security reviews that check for dangerous patterns that present a security risk. SAST is also proficient at performing data and control flow analysis. Run SAST against your code during the development process, not just at the conclusion of development.
The software supply chain includes all the third-party and open source software you include within your product or application. This is a supply chain because the software you import goes through a development cycle of its own, outside of your control. Any vulnerabilities that exist within third-party or open source software belong to you. Your customer experiences your product as the sum of all its parts and does not differentiate between the pieces that came from someone else. So a vulnerability in a third-party library in your application is your problem too, not just the leaders of the project.
Code review is the process of having a second set of eyes review a given piece of code to determine if there are any visible flaws within it. Code review can be performed using multiple approaches. The traditional, manual approach involves having a developer send a piece of code to a peer for a review and modifying it by hand. Pair programming is the process of having two developers work side by side on the same piece of code, detecting problems and vulnerabilities as they go. Code review works in tandem with SAST. SAST excels at speed and code coverage, while human reviewers can detect logic flaws.
DAST consists of what is traditionally considered web application or vulnerability scanners. DAST tools search for active vulnerabilities in live, running code.
Incident response within the context of application security is the process you go through to be notified of vulnerabilities that testers find, both externally and internally. Your incident response team is responsible for tracking all vulnerabilities and responsibly disclosing the important problems to your entire customer base.
Healthcare, financial, and tech share common approaches to deploying application security. The top seven application security program elements apply to any type of organization. Incorporate them into your S-SDLC, or use them as the foundation to create an S-SDLC.
Ping Identity's Reck notes:
“The sector you're in shouldn't make much of a difference in how you go about applying application security controls. The risk posture and development activities of your company should determine that.”
This is consistent with what we learned after a closer look at both healthcare and financial industry security practices. The risk posture determines what pieces should exist within your S-SDLC process.
The primary distinction between the sectors is on the actual data they try to protect. Tech focuses on the final product and protecting the data the product processes, while healthcare and financial services are both driven by the confidentiality and integrity of the data they collect and process as they deliver their real-world services.
While regulation and risk drive decisions within healthcare and financial services, the most successful companies in those industries don't just do the bare minimum to meet regulation requirements. They employ the seven elements in this article, and they have support and understanding of their comprehensive security practices from the top down.