The Power of Process in Creating a Successful Security Posture

Ian Campbell, Senior Security Operations Engineer, DomainTools

November 7, 2024

5 Min Read

Source: Andreas Prott via Alamy Stock Photo

COMMENTARY

The quality of information security guidance has increased in recent years — especially regarding the focus on fundamentals — but our industry often fails to emphasize establishing those fundamentals as replicable processes.

Fundamentals, policies, training, tabletop exercises, and technology are resources that are limited in their respective usefulness — each is a finite and frequently subjective piece of a puzzle. In an industry epitomized by the executive phrase “Learn to do more with less,” achieving consistent end goals requires recognizable, replicable, and flexible processes from start to finish.

In order to adopt a common lexicon, let us define “process” as instituting, training on, evaluating, and rehabilitating a series of practitioner-defined expected actions a person may take in response to a stimulus. Examples of stimuli include a 911 call, endpoint detection, or an onboarding ticket from HR. Importantly, the process provides a framework for activity, is replicable, generalizable, and is driven by the practitioner’s physical, mental, and digital capabilities.

Psychology professor and human error expert James T. Reason first formally proposed the “Swiss Cheese Model” of causation in 1990. His model theorizes that the breakdown of complex systems often involves weaknesses across multiple defenses (slices) aligning across a moment of opportunity that results in the breakdown. Writer and technologist Cory Doctorow recently illustrated an excellent example of this in the alignment that results in a successful financial scam. In the context of security, the Swiss Cheese Model tells us that one cannot reliably anticipate how and when the weaknesses in your systems will line up to present an attacker opportunity without maintaining focus from the start on integrating replicable, dependable processes into your workflows.

As a nascent technologist working technical support in Congress, my daily commute into Washington, DC, often centered around podcast listening. One favorite was the defense-themed podcast Bombshell, often repeating mid-episode the tagline “Process is my Valentine,” analogizing the criticality of process to something as important and unpredictable as national security. The phrase resonated with me not only due to autism (after all, we love our self-imposed routines) but also because of my decade of experience in emergency services response prior to my career in tech.

As a 911 dispatcher responsible for responding to thousands of people myself, the process became necessary. I had to work out:

• Order of actions: What needs to happen and when?

• Kinetics of actions: Does the order line up with the environment? Are the suitable radios and keyboards in the right places? Are the right tools within reach and in the right direction?

• Laterality of actions: What can I parallelize, moving from initiating one to the next, that will then develop alongside each other with minimal direct interaction and minimal viable attention diverted?

• Assessment: What can I measure? How can I evaluate the systems that interact here? How well did they adopt the process or warp it into a one-off? What needs improving?

Figuring this out was the only way to move forward in an unpredictable environment with countless important elements demanding simultaneous attention. Tech security, like dispatch work, requires one to master the process. Hurtling into the Capitol from suburban Virginia to pound the marble amidst a never-ending ticket queue, and later helping to stand up a robust and thriving security program from scratch in private employment, process became my valentine once again.

The Policy Is Prescriptive, the Process Is Kinetic

Consider it a stimulus response through muscle memory. The process directly considers the physiology, neurology, biases, and capabilities of the practitioner it seeks to guide. It can’t be a product of the back office. Process is necessarily practitioner-centric; sit in their chair, see it with their eyes, run it with their tools, and most of all, challenge the process with practitioner’s fatigue. Can someone on their 13th hour of a double shift carry it out effectively?

Although forming process is also interactive and not necessarily consensus-based, it is at least consensus informed. It requires stakeholder input and buy-in from both the immediate team and from those who touch the scenario around it.

Once the first iteration of the process is constructed, document it in a way that emphasizes revision. Build the living nature of it into the documentation, including after-action assessment around specific and measurable elements. Do not discount the subjective, as it invariably affects how any situation plays out. How your practitioners encounter the process determines how successfully the process survives reality.

Then revise, take a breath, and start all over.

Establishing a realistic, practitioner-driven process wherever possible is critical for running a successful security program. It prevents employee burnout, standardizes experiences, and closes many of the gaps exposed by repeated one-offs. By centering practitioners, evaluating environments, and instituting flexible frameworks alongside attention to fundamentals and proactive communications schemas, we can all move toward a more secure posture. Let’s make it harder for the bad actors out there.

About the Author

Senior Security Operations Engineer, DomainTools

Ian Campbell is a senior security operations engineer with DomainTools, with previous experience in the US House of Representatives and Silicon Valley. Before working in technology, he spent a decade in emergency services, a period that continues to inform his evolving perspective on security.