History doesn’t repeat itself, but it often rhymes. As AppSec evolves towards a new playbook, here’s what we can learn from IT’s journey.
Just over 20 years ago, Watts Humphrey declared that every business was a software business.
Not everyone agreed.
No one imagined sports shoe manufacturers, automakers and even barbecue brands building, developing and shipping software. Even crazier: Doing it at a pace that, a decade ago, would have made engineers’ eyes bleed.
It’s the kind of transformation that makes life difficult for AppSec teams: What do you do when the entire approach to software development has changed so radically? When developers must now be security-minded? Where release cycles have gone from a year to a day — and the output is going to the cloud?
Time for a new AppSec playbook
Fifty-four percent of software engineering leaders are now directly responsible for ensuring the security of applications. Like their IT security colleagues, they’re finding that traditional security approaches can’t keep pace with new realities. Balancing agile software development with proactive security — and extending that approach to cloud-native application architectures that already reduce the effectiveness of existing controls — has shifted toward a new playbook that includes automation, integration, risk management and new frameworks.
AppSec is being forced to evolve and adapt due to massive shifts in technology and business processes. Where toolsets like antivirus, firewalls and intrusion detection systems were once sufficient for data and systems security, as networks grew and changed, more advanced capabilities like role-based access control and EDR were invented. Similarly, AppSec now needs to move past cobbled-together, siloed tools like WAF, RASP and ASOC, into a more unified, proactive approach.
But how do you maintain visibility across the software supply chain and identify critical flaws and weaknesses in code when there’s so much going on?
You could start by asking your friends in IT security. Because they’ve been here before, and the parallels are remarkable.
There’s a lot we can learn from the solutions, approaches and frameworks that grew out of times of technology disruption and transformation. In this first post in a series of three, we take a look at how IT security evolved from a reactive approach into a more proactive, flexible and intelligent process – and how this resonates with AppSec today.
So let’s start at the beginning…
Hello computer
The late ‘80s and early ‘90s saw a dramatic shift in network security. We moved from a world of centralized, perimeter-bound networks built by specialized companies for specialized companies into one where everyone had a computer and access to connected systems.
Four new realities emerged:
Networking became distributed…
Many technology users weren’t experts…
Network assets became increasingly interconnected…
Security tools and approaches for these new environments were inadequate…
The transformation was rapid: Viruses and malware morphed from hypothetical and CompSci lab projects into the mainstream. Network attacks became an actual thing. Situations that were barely relevant before had evolved into massive challenges. And in response to this transformation, a completely new segment of IT security tools emerged.
Sound familiar?
Needle meets haystack
The reality that first-gen tools came with limitations, and surfaced new problems, will sound familiar to AppSec practitioners. Back then, security tools like AV, firewalls and network protection couldn’t handle this new wave of threats effectively. Signature-based and resource-intensive, they produced too many false positives, and (possibly most importantly) could only detect known attack types. As soon as the attack changed, even a little, detection failed.
False positives were a significant issue; anything falling within the scope of the signature was flagged, and inaccuracy bred inaccuracy, generating yet more false positives. While all of this was going on, the software, tools and threats themselves were evolving and changing. So a second generation of tools was invented…
By now, security teams were dealing with more technology, most of it working in silos, with little integration, normalization or correlation. Next-gen tools added more data — within each silo (sounds familiar?). Practitioners needed to move beyond signatures to behavioral-based approaches that would allow them to respond in a more intelligent, flexible way.
The big shift has happened: Instead of trying to address each individual risk after the fact, we see a switch in emphasis to prevention and integration of security earlier in the development cycle. Fast forward to AppSec 2024, and Gartner is predicting that 70% of platform teams will integrate application security tools as part of internal developer platforms to scale DevSecOps by 2026 – up from 20% in 2023. Like IT Security in the past, AppSec is responding to the challenges of complexity by trying to get in front of risk before they become an issue.
For security teams, the second generation of tools improved detection rates, but a new challenge emerged: managing everything. If you have ten deployed tools (silos), each detecting 10,000 threats…You now have 100,000 problems to manage. Context, accuracy and an aggregated data set is the next logical step. There was a huge need to consolidate the output of ten tools into a single console, without losing sight of everything…
Enter the security operations center (SOC) and next-gen tooling, along with the cybersecurity kill chain and MITRE frameworks —revolutions in their own right, driven by the same need for contextualization, prioritization and defense strategies that eliminate gaps, reduce noisy output and maintain workflows.
We’ll take a look at those next week.
We’ve been here before
For anyone charged with understanding what the future of AppSec could look like, there’s a lot to learn from our security past. Looking at how the tools and frameworks evolved to address changing security needs gives AppSec defenders a useful lens through which to view the challenges we face today.
As this post illustrates, both disciplines emerged from a reactive approach, evolving through a “mind the gaps” mindset to include more proactive “find the gaps” measures that involve a combination of preventive measures, security-by-design, and the use of clear frameworks and best practices to keep everyone on the same page. Eventually, automation and integration will become part of that shift. We’ll take a look at those in the next post too.
)