Edition 10: Selling AppSec
Edition 10: Selling AppSec
In AppSec, most Security controls are implemented by folks outside the Security team. You cannot improve your AppSec posture, without "selling" the virtue of AppSec to your stakeholders.
Among my earliest memories in AppSec (2011 IIRC) is a conversation a developer had with his colleague. He was upset about a security report he had just received (authored by my team). He half-jokingly said “the Security team will be really happy the day our app is really secure, but does nothing else”.
It’s amazing how two different teams, with similar intentions (to keep an app from getting hacked) have such different opinions on facts (a security defect). I’ve always wondered what we can do to bridge this gap.
A few years after the incident, I found myself working closely with our sales team. Like many (far too many) engineers, I initially looked down on the sales process. The usual tropes about sales teams being pushy and not worried about quality of work occupied my conscious. As part of the job, I accompanied them on customer meetings, participated in internal sales discussions and in general, cared a lot for this team. I realized then, that the skills of a good salesperson is not to force feed cookie-cutter solutions, but to care about the customer’s requirements, qualify them, challenge assumptions, abstract problems, be creative with solutions and so on. Essentially, a good sales process is a win-win proposition where two parties exchange goods for money. Many of the skills used in sales can be useful in AppSec too.
I believe we can use techniques and frameworks from the world of sales to improve every organization’s Security posture. Here’s my hypothesis:
Much like selling a product or a service, we should also sell Security to stakeholders. Using techniques used by sales teams can help you empathize with your co-workers and improve the adoption of your Security program. This is especially true in AppSec, where security controls are mostly implemented by teams outside Security.
Applying the sales lens to an AppSec problem
To illustrate the point, I am going to use the help of a handy framework from “The challenger sale”. I am not an expert in sales theory, so I make no claims about it’s effectiveness, but this framework makes a lot of sense and has worked well for me in the past. YMMV.
Let’s consider the process of convincing engineering managers to adopt a newly purchased SAST tool. The conversations usually go something like below:
This is not a bad approach. It clearly communicates the value proposition (why SAST and why this tool), the expectations (SAST policy) and the operational details (how to implement and how we will track progress). But it has a few shortcomings:
Lack’s context: Does not tell you why we need SAST now? Why not do this 2 years down the line or why wasn’t this done before? An so on.
Lack’s empathy: Does not tell the engineering leaders why they should care. How does this help them? How does this help their team? What sacrifices will they have to make to get this working? Instead, it definitely tells them what will happen if they don’t implement SAST (the policy probably has fancy things like SLAs and escalation matrices)
So, if you were to sell the idea of a SAST tool, how would you approach the same problem?
Build credibility : Empathize with their challenges. Talk about how penetration tests at the end of the SDLC is such a painful way to deal with security defects. You've designed, built and QA'ed the app and now the security team finds a defect. Depending on the defect, you may now have to go back and do things all over again. Wouldn't it be nicer if we could find at least a subset of these issues much earlier?
Re-frame: Talk about how hackers need to find one bad vulnerability in our software, where we (the good people) have to shut down every piece of bad code to be secure. Hackers (in theory) have unlimited time to attack us if they so wish, we have limited time, limited money and a lot of other priorities. So, we need to use all the automation and tools we can to bridge this gap. If we can use our org setup and budget to buy tools which will help us find issues quickly, we may get a leg up against these pesky hacker.
Rational drowning: Show them the "cost of fixing bugs" chart. Show them relevant data from the BSIMM. Work hard at getting relevant data. For example, scan an old version of an app and show how you could have found a bunch of defects (which were discovered through a penetration test) through SAST and reduced all the drama (don’t talk about the “final solution” just yet).
Emotional impact: Talk about the awful experience for developers when Security advice comes at the wrong time. Engineering leader wants to keep their deveopers happy and productive. Isn't it better to equip them with tools to incorporate security instead of beating them with a stick after all their hard work is complete? Engineering leaders may or may not understand security, but they definitely understand developer productivity.
A new way: Talk about how everyone is talking about shift-left (OK, some are talking about “shift everywhere”, but that's a topic for another day) and it's time we start doing this too. We need to find novel ways of finding defects early and reducing release-time drama.
The solution: Now talk about your shiny new SAST tool and how it can solve the problems outlined earlier.
A few things to keep in mind
These techniques cannot eclipse the shortcomings of a poorly designed SAST program. That is important too. But too often, even well-designed AppSec programs don't see the right adoption and this approach can help.
This is not just limited to areas where your stakeholders are engineering leaders or you are an AppSec manager. If you are a Pentester, you should "sell" the defect you find by writing a good report (POC, Steps to reproduce, accurate impact description etc.). If you are a Security Engineer, you should keep UX in mind when building your tool (if I had a paisa for every Security tool with horrible UX, I'd be a Karodpati).
The above framework cannot be implemented in a single deck or a single conversation. Depending on what you are selling, you may need to do these over emails, presentations, white papers, water cooler conversations and so on. My suggestion is to follow the org culture. Depending on what works best in your environment, modify the mode of delivery.
The precise use of this framework is not important. I like the Challenger sales framework. There maybe other frameworks that you can find value from.
That’s it for today! Do you think applying the sales lens helps with AppSec adoption or am I torturing this analogy to make a non-existent point? Let me know! You can drop me a line on twitter, LinkedIn or email. If you find this newsletter useful, do share it with a friend, colleague or on your social media feed.