In today’s complex, technology-dependent enterprises, the answer to “Why?” is straightforward. Enterprises cannot expect a collection of independent activities—a pen test here, an hour of training there, some free tools that may not work as advertised to consistently result in secure software.
Enterprises train, buy some testing, and point developers at free tools, and still see the same security defects. If enterprises start with an immature software security initiative (SSI), then agile, DevOps and continuous integration/continuous deployment (CI/CD) just make the same buggy software faster. It takes a real business-level effort to pull everything together.
The SSI must ensure important issues are explicitly addressed after the business decides what level of risk is acceptable. There’s risk everywhere—schedule, compliance, budget, technical, people—so things rarely happen exactly as desired. That means the firm might overspend, be non-compliant, or produce the right thing too late.
Even if all that goes perfectly, which security defects will be allowed into production environments and which must be remediated immediately? Without guidelines, individual application owners or other risk acceptors can put the enterprise at risk or even out of business.
Corporations must accept that there are times when security will win over functions and schedule. Safeguards that delineate when security gets precedence are crucial. If an important middleware security patch breaks the application, then it’s the application that must be fixed. Open source has an undesirable license? It’s not allowed. A “high” vulnerability for which there are known automated attacks must be fixed because no one is allowed to “accept that risk.”
DevOps and CI/CD can be a great improvement over current development processes if the software security folks are included. Why make software development faster if you still wait on security testing at the end before pushing to production? The software security group (SSG) that leads the SSI can ensure all development and security operations tool chains have hooks where security tools run inline and at the cadence everyone expects.
Architects and developers must know what secure code looks like. “Awareness” doesn’t make code get better. Training helps, but isn’t going to make the big impact alone. No one’s born an application security architect and it takes years of experience with security requirements and technology stacks to get it right.
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. Additionally, developers need things like secure coding standards, secure-by-design libraries for non-functional security requirements, and pre-approved security features.
The company can save money by ensuring the various components of their SSI 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 aggregate analysis? Why make your developers fix “high” security defects in three days, but let “high” patches languish for weeks or months?
Enterprises cannot afford to sit before some law enforcement group after a breach and talk about how they’re going to build an SSI next year. In 2018, no enterprise 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.
Software and SaaS acquirers are increasing 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. Even if it’s the partner that fails expectations, it’s your firm’s name that’ll appear in the press and reap the ire of regulators, stockholders, and the public.
We need good attack intelligence so we know what the bad guys are doing and some guidance on what mature SSIs are doing. That helps us decide what kind of testing is necessary across the firm’s software 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? Where do all the bugs go? What gets fixed? When? Who accepts the risk?
A thread of governance running through the SSI must maximize prevention, but also provide the necessary detection and reaction to ensure the business is protected in addition to the software portfolio. Then, we use metrics to ensure everything is moving in the right direction.