Wait…What??? Don’t they mean the same thing? Well, yes, I used to think so. In fact, I was quite committed to this concept for a very long time, till I discovered that this might not be as true as you or I think it is.
Recently, I have been interviewing for AppSec Engineering Positions for my organization, we45. I received profiles from AppSec folks far and wide. It was truly heartening to see so many people in AppSec! And qualified ones too! A lot of them had the right certs, had used the right tools, had identified a ton of bounties against apps, and had glowing credentials on HackerOne, BugCrowd and elsewhere. A lot of them were from companies that are globally respected and looked up to, not only for Security, but otherwise as well.
After reviewing nearly 200 profiles and interviewing about 40–50 folks, I had the idea for this blog post. Let me first start off by saying it’s not a rant……Who am I kidding! It IS a rant! A pretty big one! but, I feel it’s important to bring this up, as I truly feel that this is a shared rant that a lot of folks in applications and application security will resonate with. Anyway, here goes….
During my initial interview, I start off with simple questions about the OWASP Top 10. More conceptual stuff than anything else. Questions like “What is DOM-Based XSS? How would you advise a developer to fix it?” or “What is Insecure Deserialization? If you come across Insecure Deserialization in an app, how would you engage with the engineering team to fix it?” To my surprise the most common answer to such questions is either “I don’t figure out the fixes for the flaws, I find the bug and that’s it” or something extremely high-level and rudimentary like “sanitize input” for DOM-Based XSS, and “Input Validation” for Insecure Deserialization. They don’t explain how, why and the logic behind the solution. Clearly, this solution is half-baked at best and sloppy at worst. This gives me an indication of why organizations continue to have the same, festering issues, test after test, assessment after assessment. It’s clear that these folks in AppSec don’t really engage with engineering teams to solve problems. They see themselves purely as bug-hunters who needn’t be involved with solutions. This behavior is specially exacerbated by bug bounty hunting, that has become an easy-money cottage industry for many self-styled AppSec experts. While I am not against bug bounties per sé, I do believe that it encourages a myopic view of application security. When AppSec folks just identify bugs without working with engineering from a replication, validation and consulting perspective, they become a part of the problem, and not the solution. This leads to security teams getting by-passed and overall, a blow is dealt to security.
I see that Robert Graham has brought this up in his tweets recently as well.
One of the things I do with candidates who clear a basic verbal round with me, is to give them an internal “Capture the Flag” application. This is an intentionally vulnerable app that my team and I have created, for internal contests and for use in trainings. These are apps that try and mimick real-world apps. For example, one is an corporatr expense management app, while another is a online hotel booking app (like booking.com) and so on. One of my colleagues or I usually behave as “observers” for a short time, while the candidate tries to go over the app and find security flaws. The test machine given to the candidates has a bunch of security tools loaded. Stuff like Nmap, Metasploit, Burp, ZAP, etc are loaded on these machines. The apps have a combination of easy and tough to identify flaws, often integrated with business logic.
Once the challenge is issued, invariably I find that the candidates open up the tools, especially Metasploit (God knows why) and start looking to exploit the system. They run a bunch of tools, which usually find little or nothing and after a few hours, they typically give up. I don’t get this behavior for the life of me. Most folks could care less about the functionality of the application. They could care less about what kind of platform its running on. They could care less about doing a good job of recon, information gathering and mapping. They could care less about trying to threat model this app (based on its functionality) and then proceed to use that knowledge to identify security flaws against the application. They jump directly to the tools, and if the tools say there’s nothing there. They are quite confident that there’s nothing there.
This is disconcerting to say the least, because, as AppSec professionals, your job is to understand the app that you are protecting or testing. While you may not be a domain expert, you need to have a good understanding of how attackers would attack this application and what they would typically go after. Threat Modeling skills are critical, but highly underrated and absent with most of the AppSec folks I interviewed.
In conclusion, I think we as AppSec professionals really need to do a lot towards contributing to Secure Applications, than focusing on a few elements of Application Security. A holistic approach to AppSec is absolutely required, rather than a purely exploit/bug hunting approach to application security. I think application security can only be an enabler to organizations and engineering teams when AppSec folks approach their trade and craft with a well-rounded set of skills and mindset.