Embedding security, the right way
As organizations proceed to move their processes from the physical world into the digital, their risk profile changes, too – and this is not a time to take risks. By not including security into DevOps processes, organizations are exposing their business in new and surprising ways.
DevOps
DevOps has accelerated software development dramatically, but it has also created a great deal of pain for traditional security teams raised up on performing relatively slow testing. Moving from annual security testing to an almost daily security cadence has put a huge strain on legacy approaches to automated testing, with the need for a centralized team of experts to run tools that undertake static analysis and dynamic scans.
Shift left
To help combat this, DevOps has spawned the “shift left” movement which focuses on including security in the software development lifecycle at an earlier stage than before. New technologies such as interactive application security testing (IAST) and runtime application self-protection (RASP) empower developers to do their own security. Automated software pipelines that provide an optimum testing infrastructure has allowed organizations to become much more effective in securing their apps. Certainly, this makes them far more effective and efficient than the old “tool soup” approach.
Done right, security can be more efficient in modern DevOps than it ever was in traditional waterfall processes. You can “shift left” to empower developers to commit secure code themselves. But don’t forget to also “extend right” to get accurate security telemetry and protection into production.
The goal of DevSecOps is to automate the process of verifying security before code goes into production, so that it runs continuously as part of your pipeline. The “Sec” is important: by closing the barn door before the horse has bolted, you improve your security posture and have better inbuilt protection against new and emerging risks.
DevSecOps principles
The first principle of DevSecOps is to create a security workflow. This means breaking security work up into small pieces and carrying them to completion, rather than splitting security work across a series of gigantic phases and never connecting the dots.
Take SQL injection (SQLi) for example. Most traditional approaches would have a threat model identifying SQLi, a security architecture with defenses for SQLi, security requirements, secure coder training, security libraries to use, scanning tools, penetration testing, security code review and web application firewall rules. Yet, as they were all done independently, there was little cohesion. Security should be about traceability and that should be one of the biggest benefits of DevSecOps.
The second principle is to create tight security feedback loops. For that, read instant security feedback – the timelier the feedback the better. Anything else skyrockets the cost and demolishes the success rate. Organizations need to use technologies that provide instant and accurate feedback. Anything else is virtually useless.
The third principle of DevSecOps is to create a culture of security innovation and learning – and for good reason. Security moves fast: to stay ahead, organizations need to be agile. Yet, most organizations today simply react to their auditors, adhering to standards written years ago about problems from years before that. We need to get to a place where organizations are thinking about the risks that might exist in ten years’ time and start planning their defenses now. Future-proofing them makes sound business sense.
Embedding security: Capitalize on DevSecOps
The idea of turning security requirements, security policy, security architecture, and security coding guidelines into software is very powerful. However, imagine a simple security rule like “Applications must use the X-FRAME-OPTIONS header to prevent clickjacking”. You could put that in all the documents above and nobody would ever read it. Mistakes would continue to happen. However, if it is turned into an embedded test that checks every HTTP response within the application to ensure that the header is set properly, it would be instantly reported to developers and could be fixed swiftly and correctly.
As the list of rules to be tested is added to over time, it will ensure greater accuracy and reduce the need for already time-sapped human expert intervention. This will, in turn, accelerate software development processes, ensuring an organization’s ability to compete. It will also produce an assurance that the applications are trusted and secure.
In the past couple of years, DevSecOps has quickly gained mindshare among developers and security teams alike. But it is still very early days. Many vendors are trying to capitalize on DevSecOps by slapping some DevOps lipstick on their tool and saying that it’s the best for DevSecOps. Organizations that want to make progress in DevSecOps should ask themselves:
1. Do we have continuous inventory of our applications, APIs, components, and other code everywhere in our enterprise? (You can’t secure what you don’t know.)
2. For each application, what real evidence do we have that our applications have the right defenses and that they are effective?
3. For each application, how good is our visibility into who is attacking, what techniques are they using, and do we have runtime exploit prevention in place?
Only then can organizations fully embrace the DevSecOps revolution to keep them and their customers safe.