AppSec vs Secure Applications

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 upto, 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 blogpost. Let me first start off by saying its not a rant……Who am I kidding! It IS a rant! A pretty big one! But, I feel its 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 dont 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. Its 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 behaviour is specially exacerbated by Bug Bounty Hunting, that has become a 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 bypassed and overall, a blow is dealt to security.

I see that Robert Graham has brought this up in his tweets recently as well.

I strongly believe that AppSec folks should know how to code. They needn’t be amazing developers. But they need to know how write code (in any language). One, it gives them a perspective of how things work under the hood. Two. It gives them empathy and appreciation for security, that they can promulgate to developers and engineering teams. Most of the AppSec folks I interviewed listed “Python, C, C++, Java” knowledge in their resumés, but on probing further, I realized that most weren’t able to go beyond `print(“hello world”)`. In a fast-changing application landscape, where we are seeing containers, front-end JavaScript MVC Frameworks (React, Vue, etc), microservices and serverless tech, cloud andNoSQL DBs, etc, not being able to code, in an industry where you are primarily responsible in securing an ever-growing and complex stack (read luddite) is unacceptable to me. AppSec Engineers need to have the skills and capability to adapt to fast-changing application environments, which brings with it an ever-changing security landscape. Not only will they add more value to their organizations this way, they add more value to themselves.

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.