Building a Great Security Culture

Perception and history

It doesn't come as a surprise to anyone that the word 'security' comes with some negative experiences to a lot of people. When you think of information security what are the first things that come to mind? In a lot of cases memories of missed deadlines, slowed progress, and a restricted set of tools/computing power to properly do your job. This is the perception problem that is blocking us from building great security cultures in our organizations. How many of you have dreaded meeting with the security team because you just know that it means your product won't ship on time? On the flip side, how many of you have dreaded meeting with the development team because you know that they are going to fight with you to the bitter end about pushing something 'vulnerable' out the door. We have become an industry divided; us against them instead of just being US. With all of the conversations about building great culture, why isn't a great security culture part of the discussion?

I'll give you a hint. You can't create a real culture with scooters, free food, arcade machines, or any of the plethora of perks that comes along with a 'cool' place to work. This is a people issue through and through. You have to work at it. It is about building a culture where everyone chips in, no matter what their 'role' or 'title' is. It is about building a culture where everyone respects each other and listens to what others have to say. It is about putting our egos aside and getting things done.

Security is about finding creative ways to say yes

The old standard for security was all about saying no. As long as you don't allow it, it can't happen, right? People will just have to find a different way to get their job done. This was, is, and will be the way a lot of security teams operate. From a security standpoint this can be a highly effective approach. From a business standpoint it is a complete disaster. It destroys productivity and prevents you from operating at peak efficiency. It is important to remember that if a business can't make ends meet, there is no more security team. If you are part of a security team and looking to find more money for your security budget, start finding creative ways to say yes instead of no. Especially when there is a huge return for a little risk. If there is more money to be made, there is more money to invest back into the business. This is a functional shift from bivalency to multivalency. From secure or not secure to a state of risk tolerance. It becomes more about quantitative analysis and making choices based on information rather than feeling. To any of you reading this from other industries (insurance, finance, medicine, academic research, etc) there is nothing new here. It is just the application of successful techniques already used in other industries to one that is suffering greatly under the weight of its own authority complex.

No such thing as secure

Sometimes unexpected things happen. It is inevitable that you will be put in the position of making a difficult choice around security and business productivity. The important thing to realize is that there is no such thing as 'secure'. If that is your goal, then you have already lost. Security is a state of risk management and tolerance. Show me a company that claims to be completely secure and I will show you a liar. For some, this information is not very comforting. For others, it is liberating. It means not having to spend days chasing down machines and patching them because someone released a security update an hour ago. It means that we can evaluate our control strength and the likelihood that a threat will be able to come into contact with, and exploit the flaw that the patch fixes, and how large the impact will be if it is compromised. We can decide if we want to spend the time to patch right now and be confident in our choice either way. We might be doing something much more important to the overall success of the business. There aren't many more things as disruptive as these kinds of fire drills. Context and time is lost, and it doesn't always have to be. I have seen many smart people lose sight of the forest for the trees, and this is a quick route to missing important details that could lead to an eventual compromise.

If at all possible, don't slow progress

In the software world, forward progress is of the utmost importance. If you don't move forward, someone else will. And just like the Chicago restaurant scene, everyone is going to flock to the hottest, newest, coolest thing. There is no loyalty and you should never expect it. You are providing a service or good in exchange for money. If someone does a better job or can do the same thing for less money, you will find yourself out in the cold in pretty short order. It is this fact that drives us to constantly move forward, sometimes making compromises in the quality or even the security of our software in order to capture or maintain a market. It is decisions like this that can make or break a business. Now typically a normal day doesn't put you in this position, but it is something you should be prepared to face. And you should get really good at it.

The hard part is the balance between keeping your business and your customers information safe, and moving your product forward. It is difficult to move forward when you have information that says you should wait. What do you do? Let's pause for a minute and think about the typical security review flow. If you examine it, you will see the very same things you have fought so hard to get rid of. This is the security waterfall process. Build, build, build, throw over the wall to the security team. Wait for review. Security team throws review back over the wall to you (usually in a terrible format like PDF) and you discuss/fix. Wash, rinse, repeat. If we did a value chain assessment we would see a lot of inefficiency here. This process alone slows progress. In larger organizations this tends to be much more pronounced.

There is something in the process that presents a larger challenge though. It shouldn't come as a surprise at this point, but it is again a people problem. As humans, how do we react to a large amount of potentially bad news? Ok, that's not fair. Let me narrow this down. As security professionals, how do we react to a large amount of bad news? We pause, panic for a minute, collect ourselves, and put things in a state of lockdown until we can make a choice. This includes shutting down a product release if it contains major bugs. There are certainly times when this decision is the right move to make, but a lot of times there are ways to protect information and get your product out the door on time. This shouldn't come at the cost of a 48 hour 'bender' from the development team, but rather an effort to minimize exposure and mitigate risk. It also comes from the security team sitting with the development team and helping them fix the issues. If someone comes into your organization and looks at your team, they should have a hard time picking out the application security team from the product development team. They should be one in the same.

Moving from us-vs-them to US

When you move from the security team and the development team to 'The Product Team', relationships start to shift. When everyone works together every day and all facets of the product development lifecycle are treated the same way, the net effect is very powerful. It is good to have specialists, I am not advocating against that by any means. But creating separate teams with explicit boundaries creates a natural divide in responsibility. A team will only do the things it is supposed to, and let the other teams handle the rest. This effect is amplified when all of the teams are busy. It also tends to create cliques, and the perception about which team is the best. This is a nasty downward spiral that leads to a toxic environment. A very common example is security team versus development team. When you have a single team, there isn't a power struggle between teams, specialists operate as specialists, and everyone has an equal say. The focus is the product and what we need to do as a team to make that product exceptional. When you remove the soapbox(es), everyone is on equal ground and nobody is more important or taxed than anyone else. We all have work to do, and we do that work based on our ability and expertise.

For a long time I looked for good execution of these ideas. When I came to Braintree it was immediately apparent to me that this culture exists. I saw it on day one, and it just keeps getting stronger as I continue my adventure here. Our business dictates a strong sense of security. This accounts for the necessity of good security practices. But it is important to go way beyond that. Stop building security programs and practices and start building security culture.

Aaron Bedra Aaron Bedra was previously an Application Security Lead at Braintree. More posts by this author

You Might Also Like