Trying to improve security should not have an us-vs.-them dynamic to it, but it often does. When a security-minded person asks teams on a regular basis for something that feels like an inconvenience, it’s hard for people to resist feelings of resentment.
The key to culture change is finding the win-win option. You don’t want security at the expense of fast product delivery. You want both good security practices and fast delivery. If you can speed up some existing process in exchange for improved security, then everybody can be happy. You might even look like a hero for helping to reduce everyone’s pain.
With hard work, you can make a change that results in a more secure product and happier teams. A solution is to build tools and automation that give the teams what they want when your security goals are met. What keeps it from happening in many companies is the work it takes.
If you are interested in improving the security of your organization, it’s important to define “teams” as any group that produces something that needs to be secured. There is a way to work that dissolves the negative dynamic and helps everyone remember that they are one team working together against other competitors.
You have to make the tough choice to make your company different. Will you invest the time and effort to reach the better situation? Are you willing to slow down now so that you can move faster for years to come?
Here’s how to put automation to work to improve your security posture.
Know the goal
Most likely there are many practices that you wish the teams in your organization would follow. Before you start on automation, make a list of the ideas that are the highest priority for you. Perhaps you have specific requirements for some compliance matter that you constantly have to remind teams about. Or maybe there is a history of forgetting one good practice, such as adopting OS and package security updates. Here is a list to get your ideas flowing:
- Are known security bugs getting fixed?
- Are security scanning tools getting used?
- Are changes being reviewed by peers?
- Are lists of changes and requirements being documented?
- Are architectural diagrams up to date?
The most useful ideas are ones that currently take up your time and are also mechanical to check. Those will be perfect candidates for automation.
Don’t forget the incentive
To get teams excited about your new tools and automation, they should benefit from the changes. You need to understand what is currently causing them pain and have a plan to fix it. The introduction of security as a requirement probably brought extra processes that were not there before. Perhaps a new security requirement is going to add even more work. Here is a list of things that might be good incentives:
- Reduce the frequency of security reviews.
- Skip human review of production changes.
- Reduce the time for creating compliance documentation.
Ask teams what is slowing them down the most and make a list. If you ask and listen without judgment, you will have no shortage of things to improve.
When having the discussion, it’s important to frame the automation you’d like to put in place as an improvement and not a punishment. The idea is to present the new process as “if you can work like x then we can skip doing y”. If the teams don’t like x or make a mistake, they aren’t punished; instead they are left with the process that is already in place. You are only working to make things better.
Look back at the lists of things both groups want and find a win-win plan. Involve somebody from the team to help make the plan fair and to engage the team in the change. Find ideas that can be checked or executed with automation and do not involve ambiguity. Here are some examples:
If → the team has fixed a security bug in the last week or have no open issues
Then → security review meetings can be once a month instead of once a week
If → all changes have been peer-reviewed
Then → you can push changes into production without human approval
Be creative, work together, and I’m sure that a good tradeoff can be found.
Automate to reduce disagreement
Now that you have a plan in place, make the effort to make it automated and impersonal. You want the tool to enforce the agreement, and not become another source of disagreement between teams. For instance, if you will trade “push changes into production without human approval” for “all changes have been peer-reviewed,” then you should automate both of those steps.
Luckily, almost all tools now used in software development can be automated with APIs. Some examples of common tools with APIs available are GitHub, Bitbucket, Jira, Jenkins, and Travis-CI. Some automation will be easier, some harder, but you should be able to automate your process checks.
Since the outcome of the automation will be a win-win, you should be able to get help from both teams. If everyone stands to see an improvement, then everybody will be motivated to help build it. If people are not excited about helping to make it real, then perhaps the balance isn’t even between the teams and you should re-evaluate.
Some ideas will be easier to implement than others, so start with the easy ones first and show everyone that trading automation for improved processes is worth the effort. With proof of success, you’ll have an easier time convincing people to invest in automation that requires more effort but can yield even better results.
One advantage of automation for some tasks is that it can be much more accurate than humans. For example, if you want to see every change peer-reviewed, then a human trying to enforce that will take a very long time to ensure that nothing has slipped past the process. People get busy, and over time, the human checking will become sloppy. Automation can be faster, more accurate, and it’s never inclined to take a shortcut due to deadlines.
Make sure to automate the incentive as well as the process checking. If you agree to skip human review of production changes, then automate the approval when the right process has been followed. If you agreed to fewer meetings, then automate canceling meetings when the agreement has been met. Seeing the automated incentive is critical to induce a cultural change.
Keep your eye on culture change
At this point, your organization has already made a huge step forward. Security processes can be checked faster and more accurately. The security team will have more time to explore the next level of security. On top of that, the teams are working together to build more tools for more improvements.
After the tools have been in place for a while, you’ll start to notice more subtle changes. Teams will start self-enforcing good practices so that they can keep their incentives all the time. Because the tool is enforcing the process, frustration is guided away from the security team who used to enforce the rules to people who did not follow the agreed upon practice. If you are giving review-free production changes, then each member of the development team wants to avoid being the one who slows down their team with human review of changes.
The results are worth the investment. Your organization will get it all back by being able to move faster than the competition. Everybody will have less tedium in their days, and that frees you to build the innovative ideas that sets your organization apart.
This content was originally posted on Tech Beacon in support for the DevSecCon 2019 talk I gave