Part 3 — Tackling Security Culture and Awareness
Software development companies are starting to realise that to innovate, stay relevant and compete with competitors they need to adopt a different culture, to enable them to develop, release software faster and attract talent.
The difficulties with this shift in culture and practices from a security context are covered in Part 1 — Defensive Application Security in a Modern Organisation and Part 2 — Building an Application Security Programme. But one thing is for sure, to successfully implement and scale an application security programme within you company, the tech teams and other stakeholders will have to get involved. They will be the ones who write security related test cases, attend training sessions, use tools to check for vulnerable libraries and fix security issues that are identified. The security team (if there is one) will never be able to do all of this work on their own, especially if the company is growing the tech teams faster than the security team, which is almost always the case.
How then, can we introduce application security initiatives and controls into the tech teams development processes, without heavily slowing down product delivery or having to resort to enforcement of security controls? We all know what happens when someone is forced to do something… They will likely find away around it or do the bare minimum required.
Improving the perception of security within the company is a good place to start. Educate and convince the teams that security is an important, worthwhile initiative, that won’t slow them down too much and will protect the company from security related risks. There is no two ways around it, adding security initiatives into the development process will require effort from the tech teams and it will slow down delivery but hopefully only slightly, if implemented correctly.
The Netflix Culture
The Netflix culture is designed to allow tech teams to develop faster, with the freedom to innovate and to allow the company to scale while keeping the startup mentality. I.e. release features fast and reduce customer feedback loops, allowing you to “fail fast”.
What would happen if you try to squeeze manual application security activities into a fast moving development environment? It’s likely they won’t have a leg to stand on, unless you go for the enforcement option, but again that’s not desirable either. Remember that businesses deal in risk, so if the proposed application security activities significantly reduces the company’s speed to market or has the potential to hinder their competitive edge or to lose profit share, then implementing the activities would be a bigger risk to the business than if they did nothing. So how can we adapt our approach to security so that it fits into the development process, without hindering the business?
Shifting Left
Shifting Left, DevSecOps, Rugged DevOps, are terms that all describe a way of approaching security that compliments a DevOps driven environment, by taking advantage of the lessons and ideas learnt from DevOps principles. The idea is that we move security initiatives and controls closer to the design, development and deployment of applications and to bring developers, operations and security closer, rather than security being an afterthought that is bolted on at the end when the application is ready for production.
Shifting security closer to the start of the software development process and keeping up with the fast paced deliver timelines, also forces the security team to move quicker by automating as many security processes as possible. This will help reduce the manual effort required and reduce the feedback cycle so that the developers can be told about issues in their code sooner in the process rather than at the end. Automating security can be technically challenging but changing the “security is a blocker” perception throughout the organisation can be even harder!
Culture Goals
Successfully bringing development, operations and security closer together will improve the perception and culture around security within your organisation. So let’s start with a few culture improvement goals to aim towards:
- Convince product teams that the security team is easy to work with, so that they have the attitude of “would work with the security team again”.
- Teams proactively and without prompt reach out to the security team for advice, or to ask questions about how they can improve the security of their product.
- Teams defend and explain the importance of security initiatives and controls to other less aware team members or the wider product team.
- Teams members care enough about the security of their product that security champions start to form who act as the security voice for their team.
Assessing Culture Maturity
Like any company, culture improvements are going to take time and persistence to achieve. A good first step is to find out what teams currently think about security and if you have a security team, how they are perceived. Ask the product teams and other stakeholders following questions:
- When was the last time you interacted with someone from the security team?
- How was your experience? Did they respond quickly? Did they listen to your question and consider the constraints before suggesting a solution?
- Did they answer your question in a useful way? Were they able to work with you and your requirements?
- Could they compromise on security controls where acceptable or were they fixated on “their way or the highway”?
- Did they block you from doing your work? If so did they give you a good reason why?
- Do you know about the upcoming security initiatives and changes? If so how did you find out? Do you know why they are important to the business?
- What do you think about the approaches currently in place to secure your application? Could the approach be improved and why?
Security Culture Points System
One way to think about security culture is as a points system. The more points you have the more you have succeeded in creating a good security culture. You can redeem your points to do things like getting issues fixed faster than normal or asking teams to implement a security related control.
However, make sure it’s worth redeeming the points, as just like real money, it’s easier to spend than it is to earn! When you join a company as a security professional you will normally start with a negative points balance. Even if a company has a good security culture, it still takes time to gain the trust and respect from product teams. Do you think you have a positive or negative amount of points?
If you want to improve the security culture and awareness then we need to start earning some points! The following list of do’s and don’t are by no means complete, but should at least get you started.
Do’s
- Be able to compromise on security perfection. A design for a new feature might not tick all the security boxes but if they are willing to put in enough controls that it sufficiently lowers the risk then put away that box ticking pencil. In doing so you have just earned a few points for being able to compromise where acceptable.
- Send regular security updates via email and chat to the product teams. Let’s be honest, security is not the first thing people think about when they wake up in the morning, so reminding them can go along way to improving security awareness and in turn security culture too. But please make it entertaining, short and relevant otherwise it could have the opposite effect, hint, email filters and spam folders! Examples of a few updates could be the results of a bug bounty program or pen test (with graphs and metrics to make it skim-able), or the completion of major security projects like migrating to HTTPS or upcoming activities such as web training courses for tech teams.
- When devs do you a favour, reward them. Rewardable tasks could include getting a bug fixed quicker than expected by convincing a delivery manager to bump it up the queue, implementing more security controls than required, finding a bug in their own code and fixing it or even caring about security enough to come to you when they need advice or notice something fishy. The reward can be as simple as a face to face thank you or as big as a free lunch, t-shirt or even a thank you email directly to their manager or to a wider audience.
- Be a useful security advisor. If you are doing a security design review or a tech person has come to you for advice, listen to the problem they are trying to solve and the constraints they have to work with, so that you completely understand what they are trying to achieve, and only then should you suggest options to help secure their application. However make sure those options fit within the constraints of the problem. This might seem obvious but it involves keeping up to date with the technology stack in use at the company. It only seems fair that the security team is expected to learn about the capabilities of the frameworks, tools and languages used by the product teams, as we often expect them to learn about security concepts. In other words you need to learn how to speak “developer”. This will give you credibility and respect and will allow you to suggest solutions that better fit within the requirements while still solving the underlying security weakness.
- If you find a security issue and can write a simple fix, then do it and send the devs a PR. You could even write a test-case to go with it! This will earn their respect, make it faster for them to fix and is a good learning experience for both parties.
Dont’s
- Don’t redeem security points unless absolutely necessary. For example nagging the product team to fix all the low or even medium security issues in their app just because you’re an Inbox Zero type of person.
- A no blame culture. Developers are not taught security concepts at Uni and are usually not given time to focus on making the app more secure as they are getting pushed to “just get it out”. So never directly or publicly blame developers for making mistakes but instead encourage them to fix the issue and get them to explain why and how they fixed it. Also if you have regular Brown Bag style meetings, you can even encourage them to present about why and how the issue occurred so other teams don’t repeat the same mistakes. This way they also get to redeem themselves and it’s not coming off as a negative from the security team. It’s hard enough for a security person to stay on top of new attacks, you cannot expect developers to be at the same level.
- Don’t waste developers time. For example running a Burp scan and handing them the results without verifying the issues. Or handing a developer an issue to fix but they can’t replicate it because you haven’t given them enough detail. This shows that you don’t care enough and is frustrating as they have limited time to fix security issues in the first place. So make sure that every time you interact with tech teams you do the work up front making it as easy as possible for them to fix the issues.
- Don’t be a hermit. Get to know the developers you work with, if there is a new starter, introduce yourself and tell them how to contact you if they have any questions. If they know who to talk to about security issues then they are more likely to reach out when they have security related questions. One way to get notified of new starters is to set up a script that would monitor your company’s source code repositories for new contributors. Then you could either approach them directly or send them an email with your contact info, who you are and what you do.
- Don’t ignore questions. If a developer pings you via chat or email, no matter how silly a question don’t make them wait, try to prioritise a response. If you don’t respond or take weeks then they are likely to not reach out again. Spending 10min now responding to a question could mean preventing a bad design flaw getting into production in the future. As they might not have reached out to you about a new auth flow because they thought you would not respond in time to meet their deadline.
- Don’t put up security gates that require every change to production to go through the security team. Empower them to own security risks but let them know they can reach out to get advice. This helps security not become a blocker, reduces the security team workload and is the only practical way to scale security in a continuous deployment environment.
Measuring Security Culture
Building a good security culture takes time and to improve it can involve subtle changes that are sometimes hard to measure. But one way to get an indication of success is to measure how your goals are tracking. So for example you could:
- Record how many times (approximately) you are approached by the product teams seeking your guidance per week.
- When asking the teams to implement or fix a security related issue or initiative. Record how willing they were to participate, a number from 1 to 10 might help track this over time. A 10 being that they dropped everything and started immediately and a 1 being that they ignore you or get angry with your request.
- Randomly go and talk to people and ask for feedback (performance review time might capture this too) or as a last resort you could send out a survey asking for feedback.
Investing time building a good security culture and improving security awareness is a necessity for any successful application security programme. Apart from the above do’s and don’ts another way of improving security awareness further, is to get the tech teams through a web security training course that will teach them why security is important and introduce them to some common web security issues they might run into when writing web applications. Part 4 — Delivering an Application Security Training Course goes into exactly how to do just that.
Articles in this series
