Loosening control, freedom from ego, growing with your top talent

In all but the smallest endeavors, a leader's primary contribution is not doing the work required to achieve the goal. Instead, they are responsible for everything required to enable that work be done easily and well. - Rewiring the Winning Organization

It's easy to give security engineers tasks to get {name the system} in line with an external benchmark like CIS or NIST for any given thing (workstation, server, cloud service, etc). The work is clear. The entity behind the benchmark has done the research on what "secure" looks like. Customers (auditors) expect adherence. And it's actually pretty simple to show measurable impact or at least the appearance of measurable impact. They tie nicely into SMART goals and quarterly roadmaps. Reports often come out of the box and you have your continuous compliance monitoring checkbox marked.

So what's the problem?

Motivation.

Work defined by other and not self.

Not really understanding the "why" behind the settings in a visceral, convinced way. Security engineers not having "faith" in the standard.

Without faith it's hard to evangelize others in slack, jira, and cross team meetings to prioritize the work.

The work of security hardening being others to do and security teams not being empowered to do the actual work to drive the result other than nagging.

No one signs up to be a security engineer to be a nagger. They sign up cause they want to engineer shit. They want to figure out risk and do something about it. They want to make attacker math hard.

So what's the path forward?

There is a good book on parenting called change-able. In it the author describes three ways of dealing with a difficult child. I don't think of my team members as difficult children but do think the three ways of dealing map pretty cleanly to managing people and the ongoing work of security health of an organization.

You can:

1. Impose your will
2. Collaboratively problem solve
3. Subdue your will (for the time being)

Sometimes it's necessary to impose your will. Circumstances like a huge customer is requiring something done by a specific date, a critical vulnerability being actively exploited that needs to be prioritized and patched, or misconfigurations so egregious if they are left alone you are a sitting duck for {name the ransomware actor}.

Most of the time it is not.

So I've been trying to explore options 2 and 3.

Option 3 - Subdue your will

Option 3 looks like letting some CIS / NIST compliance maturity work take the back seat to different security work the team is really passionate about. Sometimes the work the team is really passionate about isn't even primarily about security, its about better partnership and collaboration with other teams in the business like our IT colleagues or Infrastructure as Code teams.

We value the security benefits of well run IT processes and healthy infrastructure as code pipelines.

Healthy team dynamics and cross team collaboration are as important to security as meeting any given compliance benchmark. It's in the context of relationships and genuine trust, we learn about serious security loopholes and long forgotten skeletons.

I still care about the security benchmark work and compliance standards but I choose not to press them for the time being and give the team room prioritize some work that feels really important to them and that they believe (rightly) will benefit the business.

Option 2 - Collaboratively Problem Solve

The heart of collaborative problem solving is

• empathize - let your people clarify their concerns
• voice - share your own concerns
• invite - ask your people to brainstorm mutually satisfactory and practical solutions

Let me share an example of what this might look like with a security team.

The issue is vulnerability management broadly speaking. There are way to many high severity vulnerabilities being discovered by all the tooling in place for vulnerability scanning. SLAs that are baked into contracts, security policies, and procedures shared with auditors aren't being met which adds a good amount of both security risk and customer relationship risk.

As manager of the team you come to the team saying something along the lines of "We need to get more tickets cut for these high findings and figure out a better way to automate the ticket creation and pinging of the owners of these resources to do the needful."

The team gets slightly upset (most likely quiet) and perhaps weeks go by without the work being truly prioritized and worked.

You take a step back and empathize.

You ask your people what's going on and they proceed to tell you about how toilsome ticket creation is, how much of a barrage it feels to the teams receiving the tickets, and they share how the real issue is that teams aren't proactively keeping their dependencies up-to-date which makes patching the latest critical or high vulnerability really hard because of the gap between the version running and the version that is needed.

You listen to this. Take it in. Don't go into solving the problem for them. Don't jump right into the but.....

Instead, You show them you heard them by rephrasing what they've communicated to you and then voice the real reason you care about the vulns getting patched. The business impact of a breach. The customer relationship harm of violating contractual commitments.

And then you shut up and listen. You invite the team to bring ideas on how the work might be done in ways practically and in ways that both concerns are met.

In this situation it might look like the team recommending a shift of focus away from being obsessed with vulnerability discovery and remediation and to patch management health regardless of if the patch has a vulnerability remediated or not. It might look like better tooling and processes to help patch merge requests be auto created and potentially auto-merged as testing coverage increases in adequacy. It might mean tracking which services do a really good job maintaining their dependencies and learning from them what processes they use to do this and helping other teams of other services learn about these processes.

Point is, it can mean a lot of things, and at the end of the day teams who know they helped create the solutions will be a lot more motivated to execute on them and often come up with better ways of working that factor a lot more of the nuance and complexity into the task at hand and create a more sustainable solution.