Computer security covers many different facets. From blue team, yellow team, red team, and all of the colors between. Defense teams (aka Blue Team) will always be present as a de-facto necessity, and penetration testing (aka Red Team) will always be a thing. But what is at the root of almost all computer security issues? Insecure code.
The vast majority of security issues are derived from insecure code; non-functionality bugs that lead to unforeseen actions and access to computer resources. And whether we like it or not, as we continue down the spiral of time and technology, more and more things are becoming code. Not only are our applications and programs code, but our infrastructure is now code, and soon our security controls will also be code.
As a long time 'web application penetration tester,' I've come from the red team world with a focus on web applications. That is, the computer software that makes up all websites, the majority of the internet. But after all my years doing Information Security (InfoSec), working for multiple companies, attending numerous trainings and conferences, I'm afraid that we all have a tendency to hyper-focus on the details of the day, while losing sight of the proverbial, "Security Forest."
What I mean is, there is a huge focus on the red team (penetration testing) as the primary factor of testing for computer security (blue team, I love you too, but that's outside of my purview for this). And it's not surprising, it's easily the 'sexiest' role in InfoSec, acting like a hacker for a living. However, I feel there are numerous downsides:
It is difficult to scale, especially within corporations with 10,000 plus employees. Bug bounty has been a fantastic solution for this, but ultimately bug bounty finds the issues that shouldn't have been there in the first place.
Penetration Testing potentially misses a lot issues because it's very easy to not execute all possible code paths in an application when testing at runtime. There are also a multitude of edge-cases, as all computer networks and the applications that run on them are different from company to company.
Tooling for dynamic security scanning has not kept up with advancements in web-based technologies. While most of our DAST (Dynamic Application Security Testing) scanners are still expecting HTML responses with simple links, script files, and straight forward parameterization (Query string and post body), modern web technologies are utilizing single-page frameworks written in JavaScript that interact via XML or JSON with backend APIs running on a server-less cloud solution.
Ultimately, the development teams who are writing insecure code rarely learn from their mistakes after a penetration testing engagement. They just close out the security issues in their Jira queue, then move on to writing the same code as before.
The days of just attacking web applications dynamically and reviewing code manually are quickly coming to a close. Our ability to do this work at scale and efficiency means we have to replace our Guy Fawkes mask for the yellow construction hard hat. As security professionals, we need to re-focus on the 'Security Forest,' and that forest is the insecure code that is behind almost all computer security bugs.
Doing penetration testing, in my mind, is still a mandatory need, but it cannot be the only security check we have for our applications. Myself and others as Web Application Pen Testers need to make the next step to ensure code security before it reaches the integration stage of the pipeline, and we need to really do more than just 'shift left.' That means that we as penetration testers, 'red teamers,' need to make the bold leap to becoming 'Security Builders.' And that means, as Jim Manico put so succinctly at Defcon 27 App Sec Village, "Code or die."
The future of all application security will rest with those who fully embrace the builder attitude, as opposed to the breaker. The breaker, again, has always been the fun, sexy side of security, but it ultimately doesn't solve the underlying issues of application security. We as future Security Builders need to integrate with development teams, to the point that there may no longer be dedicated "Application Security" teams, and just having "Security Coders" as a role on all development teams.
Ultimately education will save us all, and this blog is our little slice of doing that. College classes for computer sciences and code development need to put greater emphasis on code security topics, and to hammer that home as part of the curriculum. That is definitely starting to become a thing, but dedicated code security training is lacking in traditional higher learning institutions.
I hit my 9 year mark in Information Security around June of this year, and for the past few years, the above as been my guiding mentality. My personal career journey moving forward is to focus less on the attacking side of InfoSec, and to embrace the Security Forest, insecure code, head on.
About the Author
Aaron is an Application Security Engineer with over 10 years of experience. His unorthodox career path has led to many unique insights in the security industry.