Read Part 1 here..
Last time we talked about how you would start an application security program and I want to try to move into a discussion around how you mature an application security program. The first question I guess I would have would be… Let’s say you have an application security program established. What would a company focus on next? What’s the next step that you would see a program manager taking?
One of the next big steps would be to identify the coverage of your AppSec program. How much of your companies development is on-boarded into the AppSec program? Depending on your organization, it might be pretty easy to say ‘these are the 12 applications that we are currently developing and we’ve got eight of them onboarded into our AppSec process.’ Then you can start to move that needle forward towards getting all development under that umbrella… I think that’s the next big maturity step and it’s a pretty easy metric to identify assuming you can identify all of your in-flight development.
Next, would be to look at remediation time and what phases of development the remediation is taking place in. This allows you to see the timeline from when a vulnerability is identified, to when it is remediated based on its severity and then continue to try to improve that metric. You’re more likely to get a vulnerability remediated quickly the further left in the development cycle you are. If an issue is identified via static code analysis or even within the organization’s own IDE, it’s much more likely to be remediated within hours or days, compared to something that’s identified post-launch. If identified post-launch, you may be looking at weeks to months of development and regression testing.
When you start an application security program, you are trying to get things rolling and established. Once you have things up and running, do you need to start looking at different skill sets to include or are you really looking to add more people with the same skill sets?
So I think the main change I would recommend would be to focus less on individual contributor skillsets, but how you can start teaching others outside of your immediate team, ideally in the development/engineering teams, to become self-sufficient… You’re not going to be able to scale your organization as it continues to grow unless you can start imbuing the project development team or the engineering team with the guidance, and the knowledge, and the capabilities to identify these issues and remediate them on their own. As the organization matures you’ll want to move towards “teaching them to fish.”
Let’s say that you have a program and a team that is reasonably well established, and might not be super mature, but it’s there and it’s functioning – and you’ve been brought in from the outside. You’ve taken the job as the manager… What’s the first thing you’re going to do as the new manager?
The first thing that I’m going to do is try to learn and understand what the current process looks like. Take stock in the current situation… what kind of metrics is the team currently gathering? Like what tools, skills, and guidance do we already have.. What is it that the team is expecting and that management is expecting to see? What changes or growth do they want to see? What are the problems that management and the team are seeing?
Try to get that holistic baseline of where the program currently sits. Also – look at all of the stakeholders – above and below your current role – what are their goals for the organization? That’ll help you start to map out your plans on how you want to proceed.
How can you help other executives at the organization understand that there is real value in the application security program? Typically application security programs don’t directly generate revenue and it can often be difficult to adequately fund the program going forward… How would you communicate the value of the program to others at the broader organization?
That is a tough one – a lot of organizations still are of the mindset that since a breach hasn’t happened to us we don’t have to worry about it. After a breach, there’s definitely a big driver to fix the situation and not let it happen again.
If your organization is of the first mindset, there are some steps you can take to help communicate the value of the program upward. There’s this wonderful graph below, that shows the cost to remediate a defect over time.
Basically, if a defect is identified as it’s being written it greatly reduces the time (and therefore cost) of the remediation. If you identify that same defect after production it can be 10 times more expensive to remediate.
If you can start to frame your arguments to leadership in such a way that it’s not about generating more revenue, but that it’s going to save your developers and your engineers time… If they are able to identify and remediate security issues earlier in the life cycle that will allow them more bandwidth, later on, to focus on revenue and profit-generating fixes and releases.
MORE FROM WHITE OAK SECURITY
White Oak Security is a highly skilled and knowledgeable cyber security testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion.