NOTE: This article is written based on a conversation on the Application Security Podcast with Matt McGrath, called “Security Coaches."
Most developers will say security is a concern, but not always the first concern. Developers get hit by the business to deliver user stories quickly and in a state of completeness. Developers often put security on the side but do not get the chance to go back and fix a security issue. The next wave of requirements comes down, and off they go. One solution to this issue is security coaching.
A security coach is much more than a wellness or life coach for your developers. They have some commonalities, but the security coach thinks about how to help the developer desire to get better at security. Developers are not going to kick and scream away from security but will embrace it if given a chance. The job description for a good coach does not require a development background. The biggest thing you need is a passion for security. Communication and technical skills also do not hurt.
People from a classic security background often don't get developers because they haven't been there. You can try to tell a developer what they have to do, but if they don't understand why they're doing it and the value that it adds, it's not going to stick. Developers take pride in the code they create, and do not want to whip out lines of code and throw it out there and say, “I'm done." Developers realize that others know who wrote each piece of code and their reputation depends on how reliable and secure their code is. Developers have all these external factors pushing them to hurry up and do it fast.
Security tells developers to fix a problem, but not why they need to fix it. An explanation is missing for the ramifications of not fixing a problem. The impact of a rushed fix or shortcut is not qualified. Developers are getting bombarded with requirements, and the product owners are pressuring to get the next deliverable out and want them to be able to remove these security blocks, not just quickly but with high quality.
A product owner’s goal is right; to have an application is as secure as possible because it takes one slip for an attacker to exploit a system. A data breach could result in a loss of brand, identity, reputation, and trust. Security coaches build a culture of not just throwing things over the wall to the developers, but instead guiding them in why and how to fix security issues.
Security coaches exist to help, guide and lead developers to where they need to be. Security coaches want developers to engage with them. In a positive security coaching environment, developers think of security coach as a comforting word for them to say and are synonymous with, "I need some help." My security coach will not just tell me what to do and walk away. They're going to take the time to help me understand.
A good coach can pull out from the developer the ability for that developer to dive deeper into issues to understand security impact. For example, with a complex task, a coach prepares all kinds of materials, references, documentation, and code snippets. The coach feels nervous because they don't know how deep they'll have to go. When this coach communicates well with the developer and interacts with their style and explains why they have the right perspective. The coach reveals vulnerability and why it is difficult to see when you are developing. As the coach prepares to go into technical details, the developer's eyes open, and they ask to take a step back and review all the materials offline and then address the issue, and then we'll get back together. The coach prepares to dive in and go into the code and perform a manual code review with them, but in the end, it wasn't necessary.
Security coaches must research on their own. Like a lot of the coaches, if they don't know it or if it's a new stack that is unfamiliar or a new vulnerability that they're not 100% on top of, they may have to do a little bit more digging and get a little bit more technical, but it's not too terrible.
Security coaches know the importance of security education. Both security coaches and developers need security education to prepare them to do their jobs. For the coach, training keeps them up to date on new security issues and techniques. At the same time, the developer uses education to understand the foundational pieces of security and then layers on the importance of secure coding.
As a security coach, you're trying to work yourself out of a job. You're trying to get to the point where that developer says, “I don't need this anymore. I got this figured out.” The goal of a good coach is that a developer doesn't have to come back for a particular task a second time. Coach yourself out of a job in a specific aspect of security. Teach the developer how to properly deal with XSS using the frameworks that exist in your organization, so that they do not have to come back again in the future for XSS but can eradicate XSS for any new code they write.
An active security coach has an internal desire for security. If a coach doesn't care about this subject matter, they are not going to go the extra mile to understand new vulnerabilities, languages, or frameworks. You want coaches who love security and have a passion for teaching others about how to develop more securely.
You don’t have to come from a development background to be a good coach, but it doesn’t hurt. As someone who is interacting with developers and trying to influence them, you'll need expertise in the subject you are teaching. You can gain this knowledge outside of past development experience through learning on your own. The key is that you must have the ability to code in the language your developer is using because they will want to show you code and get your advice on situations. A good security coach is going to help developers with a lot of different areas and code reviews and walking through why this code snippet is better than what they currently have. If you're not a developer, as long as you understand the flow of code and understand what it's doing at a high level, the developers will respect you.
If you can't talk well, you're not going to be able to help lead developers or a security discussion appropriately. Sometimes the conversation is not just with developers; it's also with the business. One of the biggest keys to security coaching is making sure that the coach can communicate easily to understand answers to the developer.
Communication is critical because you've got to know your audience and be able to figure out how to communicate. You must realize communication styles and translate because not everybody receives a message the same way. Different people have different levels of technical knowledge. A successful coach can speak to the most and least technical and help them to understand what action needs to occur.
Different organizations approach the rate of security coaching differently. With some, coaches meet with developers once per month. With others, they approach it on a request basis and have the developers reach out to the coach when they have an issue, or when they want to invite the coach to an important meeting such as an architectural design review or business meeting.
Security coaching should be a primary activity, added as part of a team member's responsibility. Companies organize their coaches in different ways, with small companies having just a single security coach, and large companies assigning a specific coach for a section, line of business, or application.
Coaching metrics are essential as you begin to scale out your program. Collect metrics around how many requests you are getting per month and how long are those requests are taking.
As your coaching practice grows, team members could grow into coaching full time. Coaching and training are related, and many coaches end up as trainers.
There is wisdom in providing the same coach to a given developer or function, as developers or business units should grow more comfortable with their coach as they work together more, and there is less ramp-up time for the coach with each new request.
The dev or business feels like they have a formal engagement with their coach. They're not just sending an email to a random box and hoping they get somebody; each area knows who their coach is. It is best to allow the individual coach to work their avenue and avoid micromanaging. Give them the freedom to work with their partners and peers. Let them figure out how they want to engage with the teams.
Security coaches versus security champions
Is a security champion like a coach? A security champion is a person that is a go-to for anything with security. A connector and network person that helps a developer find the right tool or resource they need to achieve an outcome.
A security champion is more like a general manager of a team, and a coach is a coach. The GM is going to make the decisions, while the coach is going to help corral the talent that they have on that team and make sure they get their best foot forward given the available resources. Coaches have the specific areas that they're going to help guide and provide answers. Coaches are experts in developing and assisting with security. The champion is there to line up all the schedules.
A security champion is someone who either has volunteered or been voluntold. The unsuspecting champion hears, "you're our new security champion.”
The security champion is the one on the other side of the table from the security coach. The security coach is already someone who loves security. They have as part of their job to help developers and other folks in the organization kind of get further down the road and understanding security and why we should care about it.
Security coaches and security champions support each other, but they're not the same thing. Realize their differences and unleash both of them.
Find those folks on your team who can be your coaching resources. Grab a couple of resources who are passionate, who want to help out. Look for those who are already good at working with other areas, other teams. See how it goes and see if it's well-received. Because one thing you don't want to do is have coaches, and not get requests.
Confirm that those stepping forward have the passion, development knowledge, and communication skills to succeed as coaches.
Start small and use a sample group or a single part of the business. Don't release coaching to the whole organization to start and get overwhelmed. Start with a smaller group and then refine the idea as you go, and then you can slowly branch out to the rest of the organization.
Take a sample group, a section, or an area in the business and assign a couple of coaches and communicate out that you have this new program you want to try. Carve out some resources, advertise, and then measure the outcomes.
Market and communicate the availability of this new security coaching effort. Utilize a ticket tracking system to build metrics of how many requests you're getting, to assist you in making a business case for future coaches.
Coaching can change your application or software security program and can add value on top of a security champions program. Look for coaches with passion, development knowledge, and communication skills, and unleash them on your organization to assist in changing your security culture, one developer at a time.