Security enforcement is the traditional way of thinking about security, in which security teams are set as a gate to pass before software is allowed to be released. Because of this, development teams see security requirements as hurdles to pass instead of valuable insights. This isn’t unreasonable, most security teams have set themselves up this way, standing as the last bastion of security. I’ve heard security colleagues even say things like “every vulnerability must be fixed before ship!” With an attitude like that it’s no surprise that development teams aren’t excited to work with security.
Don’t get me wrong, enforcement is important, but it should be seen as a backdrop for the other security work that is done up front. Each person on the team should understand that it is their responsibility to build secure software. They should feel proud that their software is secure, in the same ways that they feel proud that their software is feature rich, usable, fast, or beautiful.
There has been a concerted effort to shift security thinking left. The thinking is that if we think about security earlier we can minimize the effort it takes to build secure software and be able to reduce the number of architectural issues that are discovered late. This is good thinking and shifting to the left is hugely important. I like to teach people to ask simply “what is the security/privacy/safety implication of this feature?” Keep in mind that while shifting left is good, it is still a form of security enforcement:
- Did you get your requirements OK’d by security?
- Have you had your architecture review?
- Did you build a threat model?
If we’re in the business of slowing development down, developers and others will expend time sidestepping security requests. Time that could be better spent developing security controls or fixing security issues.
The solution is to inspire every member of the team to see security as an aspect of software quality and empower them to make good decisions throughout. Like flour, eggs, milk and sugar are important ingredients in baking a cake, education, tooling, and awareness, are important ingredients in building a proactive security program. The ingredients alone don’t make a cake, you need heat. In the security space the heat is a commitment to security throughout. That commitment goes beyond a decree or a single initiative, it’s a sense that security is a cornerstone to the quality of the software that the team wants to build, it’s a point of pride and a group dedication to a goal. Getting there can be difficult.
I was lucky enough to be at Microsoft the summer after Bill Gates announced the Microsoft Trustworthy Computing initiative. This was one of the first, and is still possibly the best example of a large organization undertaking a huge effort to change behavior across the entire organization to improve security in a fundamental way. It required the forethought, dedication, and serious commitment to shift how software was built within Microsoft. The change was slow, but the goal was clear and the changes were consistently positive. Seventeen years later Microsoft has built some incredible tools, processes, methodologies and research that are massively beneficial to the security community, not to mention drastically improving the security of all the software they build.
Being a pioneer in any industry is more difficult than following a leader. So shifting your organization’s dedication to security doesn’t need to be as overwhelming as it was for Microsoft in 2002, but it does require commitment and strong leadership from the top.
If you want to make a holistic commitment to security there has been cohesive and consistent message and commitment across the entire organization. It could start with an announcement from the CEO stating the company’s commitment to security. For the right company, I’ve seen this approach be very successful. Each team or organization may have a budget allocated to the security push for tools, training, or other support. Then scrum masters or dev leads are asked to allocate time into their development timelines to make time for code and security reviews, threat modeling and more. The organization’s leaders may make security training and awareness available throughout the organization. This wholesale change in culture can get an organization on security track quickly, but sometimes requires a commitment that is not feasible on a large scale. If this sounds difficult to pull off, you’re right, it often is!
Another way I really like is what I call the “guru” model. Imagine if you went to a guru to get fit and the guru listed off all of your flaws and everything you need to change. You need to: sleep more, eat better, exercise, meditate, take your vitamins, drink more water, and drink less coffee and alcohol. Trying to change nearly every aspect of your life may be difficult, only people in very dire straits would be motivated to follow through with that. Instead of changing everything in the guru model you measure your biggest challenges, improve those things, and repeat. The goal isn’t to fix everything all at once, or even to fix each thing perfectly, the goal is to make one thing better, then to pick the next most important thing and improve that.
It can be difficult to find and prioritize the things that need to be fixed. Sometimes it’s important to make progress anywhere, even if it’s not the most important thing. One way I’ve seen security teams, especially new ones, be successful is to hold “Security Sins Confessionals.” These are judgement free listening sessions for people outside the security team to tell a security liaison what they’re concerned about. Maybe they’re using a bad hashing algorithm to store passwords (or, gasp, no hashing at all!), or maybe they’re concerned about an upcoming architecture review. Whatever it is, the purpose of the session at this point is not to pass judgement, but just to get a lay of the land. Certainly the security team can help if asked, but try to resist the urge to say they’re doing something wrong.
Working this way you can build trust and show early wins with the security team which will make later conversations easier. Over time teams will start to talk about how easy and helpful working with the security team is and may start to seek out their help in an ad-hoc way. Breaking down the barriers between the development teams and security teams is an important first step to creating a culture of security. One in which the security team is seen as an enabler instead of an enforcer.