Creating a Culture of Security

As a CISO, one of the most common questions I get is, “How do you build a culture of security?” My short answer is: culture is what you repeatedly do. Building a culture comes through when: (1) you take action, (2) in a programmatic way, (3) that prioritizes security as a practice.

‍

Here are some tactical practices I’ve learned.

Practice #1: Start somewhere

‍

Building a mature security program of any size is a process, and ideally it becomes a flywheel that will start to turn. 

‍

Start somewhere. Don’t get hung up on perfection, start putting in the architectural templatizing that you need to scale. Start writing down (and enforcing) policies like MFA everywhere, observe a cadence for patching and updates, and take a look at compliance requirements including regular security awareness training.

‍

It will streamline your operations to have these kinds of practices in place–and will also create a repeatable, defensible approach, which is critical. This approach is important because you want to minimize actual risk, but also because you will need to provide attestations to your leadership chain, which includes the Board. 

‍

And in the event that you come under scrutiny by your regulator (this could be the SEC, the FTC, an international entity, or etc–and even CISA, who asks for pledges like secure by design that are not required but may defray likelihood of inviting governmental scrutiny), it will also become highly important that you have a programmatic approach to security team practices–and that you represent those accurately.

‍

I find that the best way to get folks to be empathetic to the security team’s requirements is to make them as fair and seamless as possible for the end user/customer (employees are your internal customers) and to be as transparent as possible about why you’re putting in place those requirements. It’s less annoying to deal with MFA requirements during your own login if you’re part of the effort to do MFA everywhere. It doesn’t feel like a failure of the product team to give you what you want, if they explain why it can’t do something because it won’t interoperate as written. Transparency breeds empathy, and democratizing security ownership means no one gets to complain about it.

‍

Practice #2: Mechanize it

‍

To scale your security shop you need to codify and mechanize wherever possible. This includes literally coding away the resolution to trouble tickets so you don’t need to solve the same problem twice, but also prescribing automation wherever possible. For example, let’s stick with the trouble ticketing example. You should have a fully API-driven, low-latency trouble ticketing system (which inherently implies some authentication measures). And then you script—wherever possible—for problems to automatically remediate, or to go to judgment calls (and you can continuously narrow down which decisions you human-decide). And then, bots can increasingly sense when it has been remediated– and close the trouble ticket.

‍

Mechanizing best practices also involves creating workflows to better streamline human processes like filling out security questionnaires other folks vend with compliance information, by keeping it in a library that folks can access. Add to that document/library when you get approved language for those compliance questionnaires, because it will need to be a living document that updates over time but you also don’t want to step on any wires that trigger higher scrutiny by the reader.

‍

Practice #3: Democratize it

‍

When I was at AWS, we started a program to train developers in security architecture and engineering. We did not start with developers that had security experience, we simply trained them in security best practices and considerations (something every dev can use), and tasked them with wearing the security “hat” on their team.

‍

We invested in this because we found that it resulted in 22% fewer medium and high severity vulnerabilities in code than we had before.

‍

Democratizing security by teaching security to devs is a win for your employees’ professional development. Many devs have an interest in security as a field and it never hurts to add to one’s skill set. 

‍

As a CISO, your role is to enable the business while maintaining visibility over a broader set of requirements than any one engineer is likely to see.

‍

Sometimes, design principles demand that we choose between two “goods”– for example, cost and latency. But sometimes, you don’t have to choose– for example, you cache at the edge and you get reduced latency and reduced cost (and if you’re using something like open-source protocol bacalhau, you can also get better security and privacy because you don’t have to move the underlying data to do the transaction). 

‍

Democratizing security—whether that means training your devs in security or other shared ownership practices—can help folks to better understand some of these trade-offs and any “inconveniences” that you might need to accept, related to a security requirement.

‍

Practice #4: There's no finish line, but you can (and should) get better over time

‍

Is there ever a time when a CISO can look up, sigh contentedly, lean back, and say, "I have finally and fully achieved a Culture of Security™"?

That being said, metrics matter– even if there is no customer-facing impact on your most recent bad day, mature security shops track metrics like time to respond. Be conscious of the metrics you choose– for example, you can track time to resolve, but it is harder to say what an ideal TTResolve is, since some issues are more difficult than others. Also tracking TTResolve might allow some folks to gamify the stats, for example entering already-resolved issues to get the time down.

‍

Pick some metrics to start with and make sure you aren’t turning the metrics conversation into something overly gamified, but rather something that will genuinely show whether you are getting better over time. If you don’t already have one, institute a policy of forced, blameless escalations, especially for higher-severity trouble tickets (i.e. any trouble ticket that is unacknowledged after 15 minutes goes up to that employee’s manager, and so forth, until someone responds with an “ACK”). This will keep the time-to-respond down appropriately.

‍

A key piece of your security maturity is visibility–you need to know what’s in your environment so you can protect it. As the CISO of a SaaS security company, trust me when I tell you that most CISOs estimate that they have between 15 and 100 apps, and in practice they have hundreds or thousands.

Practice #5: Some hills are worth dying on

‍

To build an effective security culture, you need the political will to enforce some of the policies and practices–even when they create some inconvenience. 

‍

Also, folks say not to “die on that hill,” but sometimes you need to pick battles and stay the course. I remember when I first started at AWS, they refused to say the word “ransomware” out loud (I know it sounds silly, but big corps will have all the rules–trust me!). I knew that it was the right thing for me to use the language that customers would understand. In something like SaaS security, it’s also part of the work I do to connect the dots for folks–the reality is that most attackers are using valid credentials when they access your stuff. So, if we’re willing to talk about issues in a cohesive way, a conversation about identity security or SaaS security can also be one about ransomware.

When you acknowledge these realities, you get better at deciding which battles we need to push for and which ones we can hold off. This mentality also prepares you better when discussing budgets and policy approvals with other company leaders and board members.

‍

Most mature security programs aren’t born beautiful. They are an amalgam of behaviors, iterated over time. This means you codify automations, you track security metrics like time to respond, you review bad days with an eye that is both unflinching, and yet forgiving of individual behavior. By that I mean the question someone should ask is not, “Why did you do this, Chad?” but “Why did Chad have the ability to take this action?” Solve big problems by solving small problems. 

‍

Conclusion:

‍

Lots of shops say they want to build a culture of security, but culture isn’t just something in the air–it takes tangible forms. It means that the CISO has the right—and even the obligation—to make security an elemental practice not just for the security shop but for the business. Sometimes a feature or product release may hit a delay because it doesn’t pass security review. Sometimes a customer may be frustrated that they can’t escalate their way out of a security requirement when they want to bypass it. Sometimes the CEO may be frustrated because they have to give news to the Board about the remaining security work that needs to be done.

‍

Building a culture of security is something that comes out when you practice it, in big ways and small. Start somewhere.