In a world built for speed, security operations can’t afford to be gatekeepers. As organizations decentralize deployment, the notion of a “gate” no longer applies. And as developers gain the ability to deploy production apps themselves, on their own cloud infrastructure, conversations with security staff become optional rather than mandatory.
With code releases accelerating from once every year or two to monthly, weekly, or even dozens of times a day, no developer is going to opt into a conversation about a six-month code review. Instead, security must shift from being a gatekeeper to being an enabler, helping to ensure security by design without getting in the way of agile development and continuous delivery.
Transforming security for the age of DevOps involves cultural as well as technical changes; part of the challenge is to build a more collaborative relationship between security and developers. At the same time, modern app defense must involve both continuous feedback and continuous visibility.
To be successful against real attackers, you need to be able to answer the question: How do I know when my attackers are being successful? To achieve both goals, begin with adapting approaches to these four common elements of security across the software development lifecycle.
1. Static analysis: From heavyweight and top-down to lightweight and bottom-up
Traditional static analysis is as heavyweight as it comes: You’d bring in a tool, analyze everything, generate a report hundreds or thousands of pages long—99% of it false positives—and then spend months tuning the tool to improve its accuracy. As crazy as it sounds, the reality was that this was acceptable enough in a waterfall world, where tuning time might only cost you a single release cycle. But it’s clearly incompatible with the faster-paced world of DevOps.
Instead of boiling the ocean, begin by identifying specific classes of vulnerabilities that you’re most concerned about, and turn on analysis for just those classes—for example, command execution, SQL injection, or cross-site scripting. Once that analysis is complete, you can move on to the next, adding classes or depth as you go. The goal is to eliminate as much as possible all false positives and produce only real issues that can be directly consumed by developers themselves. At the same time, you make it possible to run static analysis quickly and accurately on every code commit—and in so doing, start to change that cultural association of security with slowness.
To add both value and velocity, look for opportunities to initiate conversations rather than simply blocking things. For example, if a DevOps team has used an outdated hashing or encryption function, find out what it was trying to protect so you can offer a more effective way.
2. Dynamic scanning: Cheap and effective use cases only
Legacy dynamic scanning has often been used as a baseline for discovering vulnerabilities: If a scanner can find it, we should probably fix it. But application architectures and functionality have changed significantly since scanners were pioneered in the early 2000s; given the complexity of many modern apps, trying to invest months in making dynamic scanning work with them is frankly more effort than it’s worth.
However, scanners can still serve well for two specific use cases:
- Ensuring that security policies are being enforced. We all know how messy production can be, and how easily edge cases can erode the consistency of security policies. Set up a scanner to continually crawl links to make sure, for example, that apps are served only across TLS supporting strong ciphers, that the X-Frame-Options header is always set to DENY, or whatever your policy calls for.
- Ensuring that previous vulnerabilities aren’t accidentally regressed back into apps. Things break all the time, and it can be easy for a fix to accidentally roll back a protection and allow a vulnerability to creep back in. Set the scanner to keep trying to attack fixed vulnerabilities; if it works, you’ll know to reapply the fix.
3. Security visibility: The power of real-time information
In the past, security visibility hasn’t really happened; disparate data sources such as logs, customer service reports, and outage reports have remained within their own silos. The goal now is to break down those silos and empower security, development, and DevOps teams with all the real-time information relevant to the security of their apps. That way, any of these groups can understand the full context of any incident they need to know about. This isn’t a new idea; it’s simply applying the principles of DevOps visibility to a security perspective.
4. Feedback: Bug bounties and pen tests
The classic feedback mechanism for security is a yearly penetration test. Of course, such tests only tell you if you have bugs—and the answer is always yes. In the age of continuous delivery, such annual checkups aren’t nearly real-time enough.
Bug bounties aren’t a replacement for pen testing, but they’re a vital complement. The main value of a bounty is its continuous, real-time nature—though at the same time, it’s more likely to yield general or broad feedback. Conversely, pen tests, while less frequent, can be more directed and highly targeted on specific areas of concern. Together, the two methods are far more effective than either used in isolation.
Putting it all together
Empowered with both continuous visibility and continuous feedback, you can accomplish three key security objectives:
1. Detecting attackers as early as possible in the attack chain
You want to know the moment the attacker discovers the vulnerability, long before the database goes out the door. Think about the attack chain in reverse order: exfiltration, lateral movement, command and control, exploitation, and initial vulnerability discovery and reconnaissance. At each stage, from the inside out, think about: How can I achieve visibility at this layer, and how can I make achieving an attack objective at this layer more difficult?
2. Continuously testing and refining your vulnerability triage and response
The beauty of DevOps is that, for the first time, you can move faster than your attackers. This is huge. With waterfall development, shipping an emergency patch can mean weeks or months of pandemonium; with DevOps, speed is business as usual.
3. Continuously testing and refining your incident response/DFIR/SecOps process
By treating even benign bug reports as sample incidents, you can continuously exercise and adapt your process to strengthen weak points. Meanwhile, instead of focusing on slow gatekeeping controls to entirely eliminate bugs before code is deployed—an impossible goal in the real world—security adapts and embraces the culture of DevOps.
Web app security at speed
By obtaining and refining continuous visibility and feedback from deployed apps and providing security capabilities that make developers and DevOps teams security self-sufficient, you can maintain effective protection while adapting to the speed and agility your business demands.
Zane Lackey is keynoting on this topic at DevSecCon Singapore today.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
