How to build a security team without becoming the enemy

Unsurprisingly, a lot of people say they don’t like working with security teams. Security teams often have ridiculous requirements, and it can be painful for everyone when releases get delayed. I’ve been guilty of thinking the same thing, so when I was approached at my job at Doximity to build a security team (without prior experience doing so), I knew I wanted to take a different approach.

At Sensu Summit 2019, I spoke about my process building the team, and how the experience I have with Sensu helped inform my approach. (For some background: I’m a user, contributor and maintainer of Sensu plugins and Chef cookbooks — and I’m always open to hearing community feedback, so find me @majormoses on GitHub and the Sensu Community Slack.) In this post, I’ll recap my talk and share my perspective on how to build a security team without being seen as the enemy.

Where to start

There’s so much complexity when it comes to shifting to a security-first mindset, and you can start in any number of places: with security tools, knowledge or resource gaps at your organization, service ownership, triage risks, by creating red/blue teams to simulate attackers and defenders, etc.

I chose to first focus on culture since a team’s culture is embedded in everything it does. Plus, I don’t think enough people are talking about the cultural changes needed to bring security to the forefront.

The core cultural competencies of a successful security team

Here are the key cultural competencies that I think every successful security team needs:

1. Transparency & communication

From open Slack channels to more inclusive meetings, you need to be transparent with both internal and external customers about why you’re building a security team and what kinds of changes to expect.

You may have to communicate information differently to engineers versus product leaders, for example, but even if day-to-day responsibilities differ, everyone should be motivated by better outcomes and helping users.

Being transparent is, after all, one of the great differentiators in the open source world, and I’d like to think we can carry that value over to other aspects of work culture.

2. Simplicity

Wherever possible, default toward the simplest solution. Single sign-on (SSO) is a great example, and a core security requirement of any company over five employees. SSO makes it easier to onboard and offboard users, and easier access for team members means improved efficiency. At Doximity, we moved 40+ apps to single sign-on, and we have another 30+ to go.

3. Incremental improvement

It’s easy to get overwhelmed by all of the things you need to change, but remind yourself that you can’t fix everything at once. Maybe it’s not even about making things better. Just focus on making things less shitty, and things will be better by virtue of being less shitty!

4. Secure by default

The fourth cultural competency comes down to your team adopting this belief: The absence of security is not a feature; it is a bug. This attitude might be the most significant in ensuring that your security team isn’t seen as an adversary. Let’s dig into this further in the next section.

Security is a mindset

I believe that you’ve got to treat security as a first-class citizen, whether you’re in QA, operations, application, product management, data, or security. We’re all developers, and you’re all part of the equation, so we must all work together with a goal of building security into every layer.

Plus, there’s no such thing as a secure system. If it exists, it’s insecure, and the question is by how much, and to what extent are you willing to invest time and money to improve it? (This brings to mind why I love xkcd’s comics so much.) If we can think of security as a mindset, we can create — and automate — better systems to empower developers so they accept the mindset without having to pay attention to every nuanced technical detail.

Here’s an example: When making a call to AWS via a Terraform module, we often default to whatever’s easiest, even when easy is the antithesis of being secure. At Doximity, we decided to create modules for Terraform using sane defaults built in. Now, developers don’t have to worry about rotating KMS keys or securing Amazon S3 buckets.

Consumers of our modules do not need to think of what arguments they need to pass to be “secure,” they must think about how to make things less secure when a use case requires such. With this shift in mindset and engineering practices people are less likely to make easy mistakes configuring production environments because they don’t have to think about how to bolt security on top.

Finally, having a sane Sensu setup goes a long way in helping your teams realize that monitoring and auditing are not an afterthought. Again, it’s about enabling team members to get the information they need to make their work easier and better, without having to think too much about it.

We’re all part of the solution in creating security-first cultures. Let’s move away from blame and work together to create better (and, more secure!) experiences for our users.

Thanks, Ben, for sharing your experience with the Sensu Community! Have your own story to share? Join us on Discourse to share your tips for creating a security-first culture (as well as get answers from the Sensu Community).