Introduction

This is part 1 of creating shared understanding for security leaders. More from this series:

• Part 2: Adversary Journey Mapping

Being a Staff+ Security engineer is not only about being technically sharp. That’s just a baseline requirement. You also need to drive change across teams and organizations, aligning them. That means it’s crucial that you can create shared understanding and communicate effectively.

Over the years I’ve built a communication toolset. I’m still learning a lot, but I hope this article is already helpful.

In this post I’m describing:

• sharing intent in addition to actions,
• communicating clearly using the pyramid principle,
• creating strategy documents,
• and how to find alignment using the 3-draft tactic.

Sharing Intent

How often have you asked for a specific change to achieve a security outcome, but it didn’t work? Often I find myself describing the intent of controls, in addition to the controls themselves. If it then turns out that the original idea is not feasible, the team can simply use an alternative approach to achieve the same thing. Maybe even more effectively, because they have more context about their system.

This idea is called Commander’s Intent, and has been used extensively by the military. Simply put: Provide additional context and constraints around the goals. So that when something unexpected happens (communication is always imperfect), there’s enough to keep the team executing independently in the right direction. It requires a bit of practice to find the sweet spot between under sharing and micromanagement.

Communicating Clearly

I have two main approaches for communicating in presentations and written from:

• following the pyramid principle: start with conclusions, then iteratively provide more details
• following the “scientific” form: start with observations (details) and end with conclusions.

Both are good ways to communicate, but it really depends on the audience. The first approach works well with executives, the second usually not.

My favorite guide to presenting to executives is StaffEng’s guide, but the framework of situation, complication, question and answer does not yet feel natural to me.

My own approach is more along the lines of:

• set context what are we talking about? what do I want from you, the listener or reader?
• diagnosis what is the problem? and why should you care?
• answer what should we do about it?
• details more details, and background. Starts high-level, then iteratively digging into details.

When presenting to an executive I generally assume the discussion might go off-track in interesting ways. So getting to the point in the first few minutes (and slides) is key. The details are sometimes just a backup, to aid my memory and provide additional structure if needed. The same technique can be applied to writing documents, that then become easier to read.

Editing your presentations and documents can take a lot of time, but depending on the stake at hand it might be time well spent: Review it from the perspective of someone reading it for the first time. Is the information presented in the right order? Is a high-level conclusion given early? Are details provided in ever increasing detail, iteratively addressing gaps in the reader’s understanding?

Creating a Strategy

Strategies are useful, because they make alignment much simpler: Write them down, collaborate to find agreement and align on a path forward. Then delegate execution, constrained by the strategy.

But I’ve struggled for years to deeply understand what a strategy is, until I’ve read on Rand’s Leadership Slack the simple answer: A strategy is a diagnosis, a set of guiding principles (or policies) and a consistent set of actions. It’s not only about the target state, but really about getting from where you are to where you need to be, while being subject to constraints. A good strategy captures the “why”, while providing high level guidance to make tradeoff decisions.

So, how do you create strategy?

Write a diagnosis describing the problems you are facing, the context, and what you are trying to solve for. Figure out the current “from” state, and constraints that limit the execution space. Provide any necessary context to the reader, often in the form of external and internal influences that must be considered. Make sure to gather data and feedback from peers, stakeholders and team members to get the diagnosis right. End with a description of the target state, though this part is still fuzzy in my mind and overlaps with the next step. Overall the diagnosis is the foundation of the overall strategy.

Design guiding principles that describe how to move from the current “from” state to the target “to” state. They are inherently derived from the diagnosis, and I keep double checking that they actually solve the challenges I’m facing while following and setting constraints. My strategies that have a small scope (well, tactics) tend to be more prescriptive (do X so that Y), larger strategies focus more on tradeoffs (prefer A over B).

Identify high level actions that need to executed to implement the strategy. Consistent actions follow the guiding principles and, once implemented, bring you closer to the “to” state.

Review by working backwards: Do the actions follow the guiding principles? Do the guiding principles fit the diagnosis? What new problems will executing the strategy lead to? What is the strategy missing? Then share and gather feedback and iterate, until you are in alignment and can execute.

Generally, I find it helpful to write the strategy alone and gather data and feedback in groups. Iterate. Keep it simple.

Example Security Strategy

• Diagnosis
  • we have multiple web apps, based on different tech stacks,
  • too many injection issues (XSS, SSRF, SQLi, …) are found via our bug bounty program,
  • we have 2 employees doing manual code reviews and lack automation,
  • implementing CSP or migrating to a secure by default framework is not feasible, because it would break customer provided extensions, thus leading to significant market share loss.
• Guiding Principles
  • support at least 80% of our tech stack with automation,
  • prioritize SAST for most impacted web apps in terms of flaw density (estimated number of flaws per thousand lines of code)
  • provide SAST feedback before deployment for every code change,
  • prefer a SAST tool that is easy to rollout over customizable,
  • prefer a SAST tool that has less noise (low false positives) over coverage (low false negatives),
  • limit manual work to 10% riskiest changes, invest 90% into automation; accept temporary increase in security misses.
• Actions
  • re-assign 2 employees to SAST automation and rely on escalations for manual code review requests,
  • buy a SAST tool,
  • roll out the SAST tool and integrate it into the source code management system’s code review step,
  • train developers in reviewing SAST findings and remediation steps.

3 Drafts for Alignment

You’ve got a strategy or other plan of action. But how do you get people to support and execute it? You need to seek alignment. The challenge with aligning on security concerns is often that there are too many stakeholders, and their opinions might differ wildly - especially in large enterprises that build hundreds of different products.

So you need to control the feedback loop both in time and volume.

A simple tactic is to ask for feedbacks over 3 drafts:

1. write a document
2. identify stakeholders
3. share a draft with stakeholders asking for feedback
   • does this solve your problem?
   • do you agree with the ideas (ignoring cost)?
   • working towards: do you agree with executing the proposal?
4. gather feedback within a set time frame (days / weeks, depending on complexity)
5. update the document, and repeat twice more for a total of three reviews
6. release the final document

By the end you’ve either got alignment. Or you’ll at least know why you can’t achieve it and adjust your plans accordingly.

It’s simple. It works. Small scale (align two teams) or large scale (agree on standards and policies for an enterprise).

Additional Resources

I’ve learned a lot from the following sources:

• StaffEng
• The Staff Eng’s Path
• Rand’s Leadership Slack
• Monastic Strategy
• Writing an engineering strategy

Discussion

• LinkedIn
• Hacker News