Security Culture

What Works, What Doesn't, and Why

Good security culture can make or break a company. So how do you get it right?

I'm the CISO of a billion-dollar company and lead a large team of security engineers in a remote-first environment. Most of them I've never met in person. Most of them speak English as a second language, and many (including me!) live in countries other than the country of their birth.

As an American who's spent the majority of his life overseas, I'm sympathetic. I'm currently based on my fourth continent and am learning my seventh (human) language.

Sound familiar?

When you're leading culturally-homogeneous teams in fields other than security, then maybe you can play to that strength. I suppose it can be more efficient.

But in security that can be a major problem. Diversity of point of view is a huge plus in this field. We are being paid to see what others cannot see. A homogeneous group of "yes men" will unavoidably have serious blind spots, and results in inferior security.

Managing a group of linguistically- and culturally-heterogeneous security engineers, however, comes with challenges of its own. How do you lead such a team effectively to maximize their value to your employer?

If you're a security leader in a similar situation, I recommend you order a copy of Erin Meyer's, "The Culture Map," a pop culture business smash hit of a book that nevertheless includes some useful, actionable insights on how to manage cross-culture teams effectively.

There are specific quirks to managing an international security team that are important to get right. Let me break this down using Meyer's framework.

Communicating

In security, Low-Context wins over High-Context.

When security team members from different high-context cultures work together, their lingua franca needs to be explicit, direct communication that leaves little unsaid.

In a high context culture like Japan or Brazil, people "read the air" of what is left unsaid. But when a Japanese and Brazilian communicate, they are going to read different things in the air, and misunderstand each other.

Security engineers need to feel free, at least within the confines of my team, to explicitly discuss details of potential security issues without fear of being perceived as "too direct" or even "rude". I don't want you to hint there might be a problem, I want you to just flat out say it.

Evaluating

In security, Direct Negative Feedback wins over Indirect Negative Feedback.

A serious problem in security is the tendency to shoot the messenger. But shooting the messenger and leaving the underlying security problem unaddressed does not serve the security needs of my employer.

It is a critical part of robust security culture to 1) ensure that security team members are comfortable giving and taking direct negative feedback and 2) that the rest of the company doesn't "shoot the messenger" when the security team delivers their message that something is broken and needs fixing.

Persuading

In security, a balance between "Principles First" (deductive reasoning) and "Applications First" (inductive reasoning).

On the one hand, real-world security needs to be pragmatic, and not dogmatic--so "applications first" is a good starting point. What is actually happening, right now, on the ground, in our networks? What are our adversaries doing, based on public threat intel and our own telemetry? We are defending our employer from attack by militaries, gangsters, and spies.

But on the other hand, there are strong "rules of thumb" in cybersecurity that you ignore at your peril--the principle of least privilege, avoiding central points of failure and compromise, in complexity lurks risk, etc. Deploying strategic security controls based on deductive reasoning from these is a best practice.

Leading

In security, I veer away from Hierarchical and towards Consensual.

Security strategy, outside of crisis moments, benefits greatly from egalitarian criticism and brainstorming. I can't think of everything, and not every idea I have is the best idea. I have blind spots. I serve my employer by admitting that I am human, I can't see everything, and openly encouraging and accepting great ideas from any member of my team--or even outside of my team.

Diversity of points of view results in strong security. A lockstep, homogeneous "groupthink" results in blind spots that, if left undefended, can cause my employer serious harm.

Deciding

In security, a Consensual Approach is generally preferable to a Top Down Approach.

There are exceptions. During a crisis, a top-down "chain of command" is critical on a security team. The buck has to stop with someone. A decision has to be made, and quickly. In such a scenario, it needs to be clear who is in command, takes responsibility, and calmly makes decisions and issues orders.

But outside of crisis moments, ensuring clear buy-in for decisions is important to enable my security engineers to operate semi-autonomously. Security is a creative field that does not benefit from micro-management. Top professionals operate best when given a clear strategic objective and enough room to achieve that objective on their own. For that approach to work, team members need to agree on the overall strategic goals we are trying to accomplish.

Trusting

In security, Task-Based Trusting is ideal inside the security team, but Relationship-Based Trusting is important when working with the rest of the organization.

We all have a lot of work to do. Task-based work is more efficient--IF you all are in consensus and trust each other. But why would you hire someone you don't trust to work on your security team? And any trust granted should be paired with "and verify", by another team member, external auditor, or myself as team lead. Anyone working in security knows the limits of trust, and the need to be held accountable in a transparent fashion. So on a security team, task-based trust rules.

But driving security change across an organization requires building diplomatic relationships with other key stakeholders whose KPIs usually don't involve security. Those other stakeholders probably don't understand security as well as my team and I do, and those other stakeholders probably find security to be a speed bump slowing them down. Gaining their trust, seeking shared understanding to get their buy-in, is critical to driving security change company wide.

Disagreeing

In security, disagreements should veer towards Confrontational and away from Avoids Confrontation.

Security engineers over the last two decades have gained a poor reputation for being unpleasant and disagreeable. This is partly our own fault. We are essentially telling software engineers, executives, and other key stakeholders that their baby is ugly, with no additional actionable information or meaningful quantitative risk metrics.

But sweeping security issues under the rug, or pretending they are not there, or letting security be brushed aside--this also does not serve my employer well. So finding ways to diplomatically but persistently disagree with internal stakeholders is critical to driving security change.

How to solve this problem: Sweeten security reports with actionable remediation, when possible (often it is, but not always; maybe it's a novel problem and we don't yet know the solution). Attempt to offer meaningful risk metrics (yes, measuring cybersecurity risk is an unsolved problem in computer science, but we can try to make things a little less hand-wavy, by quantifying potential financial loss, for example).

Scheduling

In security, I tend to veer towards Linear Time but try to be flexible enough to accommodate Flexible Time.

I work for a US-based employer whose standard language is International Business English. So scheduling must also conform to US standards of scheduling--you make an appointment, you show up on time, not ten minutes late.

That being said, in security we are often juggling multiple asks with different priorities, and sometimes in a crisis we must be flexible with our notions of scheduling. If I'm in the middle of incident response, I'm not going to show up to a regularly-scheduled, re-occurring meeting.

Bottom line

A wide diversity of points of view results in stronger security. Even if your company is culturally- and linguistically-homogeneous and based in a single country, seeking out a diversity of views offers great value for a security team. However, because this runs the risk of culture-based misunderstandings, explicitly stating security team culture is important to ensure the security team works well together.