By Sammy Migues, Principal Scientist, Synopsys
In today’s complex and technology-dependent enterprises,the answer to the “Why?” question is straightforward. Under no circumstances can enterprises expect that 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. The enterprises can do training, buy some testing, and point developers at free security tools, and still see the same security defects over and over.
If enterprises start with an immature software security initiative (SSI), then Agile, DevOps, and continuous integration/continuous deployment(CI/CD)are just ways to make the same buggy software faster. It takes a real business-level effort to pull everything together.
The SSI at an enterprise level must ensure that important issues are explicitly addressed. The business has to decide what level of risk is acceptable and what level isn’t. There’s risk everywhere—schedule risk, compliance risk, budget risk, and lots more. In other words, things don’t always happen the way we want them to. That means the firm might overspend, might end up out of compliance, or might produce the right thing too late for anyone to care. Even if all 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 enterprise at risk or even out of business.
The corporate culture has to accept that there are times when security will win over functions and schedule. There must be a governance safeguard that clearly delineates when security gets precedence. If a middleware security patch breaks the application, then that application must be fixed immediately. Open source has an undesirable license? It’s not allowed. A “High” vulnerability for which there are known automated attacks has to be fixed because no one is allowed to “accept the risk.” Development and Operations automation has to enable integration of security needs 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 development 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 “awareness training” doesn’t make code get better.
Training certainly helps, but training by itself isn’t going to make the big impact. 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 with misuse and abuse cases; and they need specific, tailored, and repeated hands-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.
The company needs to save money by ensuring the various components of their software security initiative actually work with each other instead of causing friction. Why track all the real 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 or months?
In today’s world, enterprises cannot afford to sit before some law enforcement groupafter a breach and talk about how they’re going to build a software security initiative (SSI) next year. In 2018, no enterprises can be “about to get started with an SSI.” Even if your firm creates no software, you still need a security story about the commercial off-the-shelf or open source 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.
As just one reason, cyber-security insurance firms are getting much pickier about policies and payouts for firms that can’t demonstrate a real software security capability.
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 enterprise can keep up with the pace of change in attacker methods and tenacity if their only weapons are more static applications security testing (SAST), dynamic application security testing (DAST), and penetration testing. Every enterprise 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 good software inventory and good tracking of software projects. They also depend on good choices and prompt maintenance by IT Security and Enterprise Architecture groups.
Then we need some good attack intelligence so we know what the bad guys are doing and some guidance on what mature SSIs are doing. All of that helps us 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?They all find different critical defects so how often do we do each one? 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, we use metrics to ensure everything is moving in the right direction.
