Enterprises need a software security program
Tuesday, January 30, 2018
|
Sammy Migues |
Why a software security program along with a whole system of secure software coding standards is a necessity for every enterprise.
The answer to the “why” enterprises need a software security program question is pretty straightforward. There are no circumstances under which any but the smallest firms can expect a collection of independent activities - a pen test here, an hour of training there, some free tools that may or may not work as advertised - will consistently result in appropriately secure software.
You can do some training and testing, point your developers at free security tools and still see the same security defects over and over. If you start with an immature software security initiative (SSI, or application security program, product security program), then Agile, DevOps, and CI-CD are just ways to make the same buggy software faster. It takes a real business-level effort to pull everything together.
- The business has to decide what level of risk is acceptable and what isn’t. There’s risk everywhere - schedule risk, compliance risk, budget risk, and a lot more. In other words, things don’t always happen the way we want them to. That means the firm might overspend, end up out of compliance, or produce the right thing too late for anyone to care. Even if all of that goes perfectly, which security defects will be allowed into production environments and which must be remediated immediately? Without clear rules for such decisions, individual application owners or other risk acceptors can end up putting the firm at risk, or even out of business.
- The culture has to accept that there are times when security will win over functions and schedule. There must be a governance backstop that clearly delineates when security gets precedence. A middleware security patch breaks the application? Fix the application. Open source has an undesirable license? It’s prohibited. A “High” vulnerability for which there are known automated attacks? Fix it; no one can “accept the risk.” CI/CD tool chain works only if we put the plaintext user ID/password in the automation script? No…just no.
- Development and Operations automation has to enable integration of security things that allow meeting business security objectives. DevOps and CI/CD can be a great improvement over current development processes. However, the software security folks also need to be in the mix. What’s the point of making software faster if you still have to wait on security testing at the end before pushing to production? The software security group (SSG) that leads the SSI has to ensure all the development and operations tool chains have the hooks where security tools can be run inline and run at the cadence that development expects.
- The architects and developers have to know what secure code looks like. We’re all familiar with the differences between education and training, and we know “awareness training” doesn’t make code better. Training certainly helps, but training alone isn’t going to make the big difference. No one’s born being an application security architect and it takes many years of experience with security requirements and technology stacks to get it right. Nearly all architects need pre-approved standards for things like crypto, data flows, and managing secrets in code; they need assistance with threat models as well as misuse and abuse cases; and they need specific, tailored, and repeated hand-on apprenticeship for secure design review. In addition to training, developers need things like secure coding standards, secure-by-design libraries for non-functional security requirements, and pre-approved security features.
- All the stakeholders have to know their roles and responsibilities. This isn’t difficult. Anyone who doesn’t know their responsibilities isn’t fulfilling them.
- The company needs a good software (and cybersecurity) story to tell the public, shareholders, regulators, and everyone else. You want the benefit of the doubt when something bad happens? Have a real SSI that people can understand and believe in. Not only that, but actually tell them about it. Then they are more likely to believe what happened was an error that can be studied and subsequently avoided rather than an indicator of systemic immaturity.
- The company needs to save money by ensuring the various components of its software security initiative actually work together instead of causing friction. Why track all the attacks against the firm and not use that knowledge to drive coding standards, training, and threat modeling? Why have all your SAST, DAST, and fuzzing test results in one database and never perform any analysis? Why make your developers fix “High” security defects in 3 days, but let “High” patches languish for weeks?
- No company can afford to go sit before Congress after a breach and talk about how they’re going to build a software security initiative next year. 2002 called and wants its excuses back. In 2018, no company can be “about to get started with an SSI.” Even if your firm doesn’t create software, you still need a story about the COTS, open source, bespoke, or other kind of software you put into production. Even if you just have a bunch of sensitive data processed entirely in other companies’ SaaS environments, you still need a software security story (because you’re the one who’ll get an engraved invitation to testify before Congress).
- Cybersecurity insurance firms are getting much pickier about policies and payouts for firms that can’t demonstrate a real software security capability. Consult an attorney; please do not seek or infer advice about this topic from an article that may one day grace the bottom of a parrot cage.
- Software and SaaS acquirers are greatly increasing their vendor management activities and scrutiny of vendor security practices, including vendor secure SDLC activities. Everyone understands the tremendous amount of trust firms put in SaaS and cloud providers, out-source software development firms, security tool providers, and a variety of others upon which the firms’ success depends. And we all know that even if it’s the partner that fails expectations, it’s your firm’s name that’ll appear in the press and that’ll reap the ire of regulators, stockholders, and the public.
- No company can keep up with the change of pace in attacker methods and tenacity if its only weapons are more SAST, DAST, and Pen Testing. Every firm needs a full SSI that accounts for needs related to vendor management, open source management, competency management, secure SDLC checkpoints, privacy and compliance, policy and standards, defect management and a healthy satellite embedded in the engineering teams. Even those things require a strong software inventory and effective tracking of software projects. They also depend on good choices and prompt maintenance by IT Security and Enterprise Architecture groups. Then, you some reliable attack intelligence to know what the bad guys are doing and some guidance on what mature SSIs are doing (see, for example, www.bsimm.com). All of that helps decide what kind of testing (security defect discovery) is necessary for each piece of software in the firm’s portfolio. Manual code review? SAST? DAST? Penetration Testing? IAST? RASP? Fuzzing? Threat modeling? Secure Design Review? Architecture Risk Analysis? How deep? How often? Where do all the bugs go? What gets fixed? How quickly? Who can accept the risk? There’s a thread of governance that must run through the entire SSI that does as much prevention as possible, and provides the necessary detection and reaction to ensure the software portfolio is protected appropriately. Then, use metrics to ensure everything is moving in the right direction.
Of course, there will be other reasons particular to your firm. Are you an auto manufacturer? It’ll take a real SSI to take new components from dozens of suppliers comprising millions of lines of code and turn them into a car that meets the public’s perception of privacy and security.
There is zero chance that all of this will happen by accident. It’s more likely that you could throw some sugar, butter, eggs, flour, baking powder, and milk into a cold oven and have a cake spontaneously appear than have an SSI appear just because you bought some tools and made slides titled “DevSecOps.”
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.
You can do some training and testing, point your developers at free security tools and still see the same security defects over and over. If you start with an immature software security initiative (SSI, or application security program, product security program), then Agile, DevOps, and CI-CD are just ways to make the same buggy software faster. It takes a real business-level effort to pull everything together.
The business-level effort - the SSI - must ensure some important issues are explicitly addressed:
- The business has to decide what level of risk is acceptable and what isn’t. There’s risk everywhere - schedule risk, compliance risk, budget risk, and a lot more. In other words, things don’t always happen the way we want them to. That means the firm might overspend, end up out of compliance, or produce the right thing too late for anyone to care. Even if all of that goes perfectly, which security defects will be allowed into production environments and which must be remediated immediately? Without clear rules for such decisions, individual application owners or other risk acceptors can end up putting the firm at risk, or even out of business.
- The culture has to accept that there are times when security will win over functions and schedule. There must be a governance backstop that clearly delineates when security gets precedence. A middleware security patch breaks the application? Fix the application. Open source has an undesirable license? It’s prohibited. A “High” vulnerability for which there are known automated attacks? Fix it; no one can “accept the risk.” CI/CD tool chain works only if we put the plaintext user ID/password in the automation script? No…just no.
- Development and Operations automation has to enable integration of security things that allow meeting business security objectives. DevOps and CI/CD can be a great improvement over current development processes. However, the software security folks also need to be in the mix. What’s the point of making software faster if you still have to wait on security testing at the end before pushing to production? The software security group (SSG) that leads the SSI has to ensure all the development and operations tool chains have the hooks where security tools can be run inline and run at the cadence that development expects.
- The architects and developers have to know what secure code looks like. We’re all familiar with the differences between education and training, and we know “awareness training” doesn’t make code better. Training certainly helps, but training alone isn’t going to make the big difference. No one’s born being an application security architect and it takes many years of experience with security requirements and technology stacks to get it right. Nearly all architects need pre-approved standards for things like crypto, data flows, and managing secrets in code; they need assistance with threat models as well as misuse and abuse cases; and they need specific, tailored, and repeated hand-on apprenticeship for secure design review. In addition to training, developers need things like secure coding standards, secure-by-design libraries for non-functional security requirements, and pre-approved security features.
- All the stakeholders have to know their roles and responsibilities. This isn’t difficult. Anyone who doesn’t know their responsibilities isn’t fulfilling them.
- The company needs a good software (and cybersecurity) story to tell the public, shareholders, regulators, and everyone else. You want the benefit of the doubt when something bad happens? Have a real SSI that people can understand and believe in. Not only that, but actually tell them about it. Then they are more likely to believe what happened was an error that can be studied and subsequently avoided rather than an indicator of systemic immaturity.
- The company needs to save money by ensuring the various components of its software security initiative actually work together instead of causing friction. Why track all the attacks against the firm and not use that knowledge to drive coding standards, training, and threat modeling? Why have all your SAST, DAST, and fuzzing test results in one database and never perform any analysis? Why make your developers fix “High” security defects in 3 days, but let “High” patches languish for weeks?
- No company can afford to go sit before Congress after a breach and talk about how they’re going to build a software security initiative next year. 2002 called and wants its excuses back. In 2018, no company can be “about to get started with an SSI.” Even if your firm doesn’t create software, you still need a story about the COTS, open source, bespoke, or other kind of software you put into production. Even if you just have a bunch of sensitive data processed entirely in other companies’ SaaS environments, you still need a software security story (because you’re the one who’ll get an engraved invitation to testify before Congress).
- Cybersecurity insurance firms are getting much pickier about policies and payouts for firms that can’t demonstrate a real software security capability. Consult an attorney; please do not seek or infer advice about this topic from an article that may one day grace the bottom of a parrot cage.
- Software and SaaS acquirers are greatly increasing their vendor management activities and scrutiny of vendor security practices, including vendor secure SDLC activities. Everyone understands the tremendous amount of trust firms put in SaaS and cloud providers, out-source software development firms, security tool providers, and a variety of others upon which the firms’ success depends. And we all know that even if it’s the partner that fails expectations, it’s your firm’s name that’ll appear in the press and that’ll reap the ire of regulators, stockholders, and the public.
- No company can keep up with the change of pace in attacker methods and tenacity if its only weapons are more SAST, DAST, and Pen Testing. Every firm needs a full SSI that accounts for needs related to vendor management, open source management, competency management, secure SDLC checkpoints, privacy and compliance, policy and standards, defect management and a healthy satellite embedded in the engineering teams. Even those things require a strong software inventory and effective tracking of software projects. They also depend on good choices and prompt maintenance by IT Security and Enterprise Architecture groups. Then, you some reliable attack intelligence to know what the bad guys are doing and some guidance on what mature SSIs are doing (see, for example, www.bsimm.com). All of that helps decide what kind of testing (security defect discovery) is necessary for each piece of software in the firm’s portfolio. Manual code review? SAST? DAST? Penetration Testing? IAST? RASP? Fuzzing? Threat modeling? Secure Design Review? Architecture Risk Analysis? How deep? How often? Where do all the bugs go? What gets fixed? How quickly? Who can accept the risk? There’s a thread of governance that must run through the entire SSI that does as much prevention as possible, and provides the necessary detection and reaction to ensure the software portfolio is protected appropriately. Then, use metrics to ensure everything is moving in the right direction.
Of course, there will be other reasons particular to your firm. Are you an auto manufacturer? It’ll take a real SSI to take new components from dozens of suppliers comprising millions of lines of code and turn them into a car that meets the public’s perception of privacy and security.
There is zero chance that all of this will happen by accident. It’s more likely that you could throw some sugar, butter, eggs, flour, baking powder, and milk into a cold oven and have a cake spontaneously appear than have an SSI appear just because you bought some tools and made slides titled “DevSecOps.”
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.
Become a subscriber of App Developer Magazine for just $5.99 a month and take advantage of all these perks.
MEMBERS GET ACCESS TO
- - Exclusive content from leaders in the industry
- - Q&A articles from industry leaders
- - Tips and tricks from the most successful developers weekly
- - Monthly issues, including all 90+ back-issues since 2012
- - Event discounts and early-bird signups
- - Gain insight from top achievers in the app store
- - Learn what tools to use, what SDK's to use, and more
Subscribe here
