Long ago and not so far away, but in what sometimes seems like another lifetime, I worked as a police officer and taught others law and procedure at the police academy. The career switch to IT, specializing in security, was in some ways a big change. On the other hand, many of the tactics and techniques that I practiced as a cop and many of the concepts that I taught as an instructor turned out to be directly or indirectly applicable to my new field of endeavors. The ways of thinking that kept me physically safe on the mean streets can help you to keep your network safe in cyberspace.

Dictionary.com defines “security” as “freedom from danger,” “something that makes [you] safe.” Synonyms include protection and defense. It’s easy to see the analogy between the dangers to life and limb faced by a police officer and the dangers to our networks and data that we deal with in the IT world. In both cases, by venturing into a place – whether corporeal or virtual – that is also inhabited by miscreants and mischief-makers – we take very real risks.

The good news is that, in both cases, there are measures that we can take to protect ourselves and make it less likely that we’ll become victims of the criminals who lurk there. And while the implementation is necessarily different, the basic principles upon which those measures rely are surprisingly similar.

Mental states of awareness

An important concept in police firearms and officer safety training is that of the color-coded mental states of situational awareness that were popularized by Col. Jeff Cooper. These alertness levels are broken down as follows:

  • Condition White: Relaxed and oblivious, not on the lookout for danger.
  • Condition Yellow: Relaxed but paying attention to what (and who) is around you, being observant but not paranoid.
  • Condition Orange: Alert to possible danger, closely evaluating the status of potential threats and positioning yourself to deal with them if they do in fact prove to present a risk.
  • Condition Red: Focused on an identified threat and prepared to respond immediately to an imminent attack.

Some police trainers, in an effort to expand on the idea, have added Condition Black to this list. This represents a state of panic and paralysis in the midst of an attack, and is the direct result of operating in Condition White. When an attack comes as a total surprise, many people will go instantly from White to Black instead of moving through the continuum one step at a time.

When it comes to cybersecurity, just as in a physical confrontation, both White and Black are the wrong conditions to be in. When going about our jobs on a routine day, we should at least be operating in Condition Yellow, keeping an eye on the type of traffic on the network and on the lookout for any indications of something out of the ordinary that could mean an attacker is probing the network or beginning the launch of a full-scale attack.

If we detect unusual activity, that should move us to Condition Orange, which means more closely examining what’s going on to determine whether an attack is, in fact, underway or there are other, more benign explanations for the increased traffic or other suspicious activity. Once we’ve identified that an attack is in progress, we shift to Condition Red and start taking steps to protect our critical assets before they can be compromised (incident response).

Condition Black – doing nothing in the face of an attack, whether out of panic, lack of policy/procedure or lack of skills or resources – can make the difference between an attempted compromise and the loss or exposure of data (which could result in compliance issues, reputation issues, and monetary losses) or a network outage that could impact productivity and inconvenience employees, customers and others.

If/then thinking (a.k.a. when/then thinking)

In discussing Condition Orange above, we mentioned the need to position yourself to deal with threats even before you’re certain that there is a threat. In police training, we called this if/then or when/then thinking. The concept is simple but vital and it boils down to this: Don’t wait until you’re under attack to come up with a plan for responding.

Instead, you should already have steps mapped out for common situations. In IT, this begins with an incident response plan that takes into consideration all the different types of attack or intrusion scenarios that you might face: denial of service, a “backdoor” intrusion, use of legitimate credentials obtained through social engineering or technological means, elevation of privileges resulting in an attack using administrative credentials, insider attacks, and so forth.

The key is to imagine all the attack scenarios you can and ask yourself: If (or when) this happens, then how can I most quickly and effectively shut it down and prevent damage? But it’s not enough to do this once, come up with good answers, type it up in a policy and distribute it to security admins. The last thing you need to be doing if/when you come under attack is paging through a printed policy manual or trying to find the right digital file that outlines the procedure.

All members of the incident response team should have the procedures memorized and should regularly practice them so that the response is automatic when the game turns real. You should also be constantly reviewing and revising the plans in light of new attack types and techniques. The bad guys are masters at anticipating what we’ll do and coming up with ways around our security measures. In fact, assessing and revising are important parts of the process that some police trainers refer to as SARA.


The SARA problem-solving model has been incorporated into what law enforcement trainers call Problem-Oriented Policing. This is a way of looking at police work as the addressing and solving of a series of problems, and it emphasizes that this means not only fixing the immediate problem but also addressing the conditions that give rise to the problems.

Anyone who has worked in cybersecurity knows that this is an apt description of what we do, as well. Security vulnerabilities – whether in software code, network or system configuration, data encryption (or lack thereof) or even in the users of those resources – present as problems that we need to solve, both in the short term and in the long term.

SARA stands for the four steps of the process:

  • Scan
  • Analyze
  • Respond
  • Assess

Each of these steps involves a number of substeps, which you can read about on the Center for Problem-Oriented Policing’s website. Briefly, scanning begins with identifying the problems and prioritizing them, and gathering basic information about them. Analysis includes researching and developing a theory as to the reasons for the problem. Response involves identifying alternative means of dealing with the problem, choosing among them and carrying out the chosen response. Assessment means determining whether the plan worked, identifying what could or should have been done differently or better and revising the plan as needed.

Leaving the law enforcement analogy for a moment and borrowing terminology from the medical world, both police problems and IT security problems can be acute or chronic. The SARA method can be used in both cases, but obviously the scan/analyze/respond/assess process will go much more quickly (and leave out some sub-steps) when addressing an acute problem (an attack that’s underway) vs. a chronic problem (a less than optimum network configuration that could be exploited but isn’t under immediate attack).


Although as cybersecurity pros, we might not be putting our lives in danger when we go to work every day, we do face serious threats that must be addressed lest they endanger our organizations’ users, its bottom line, and even our own jobs. Many of the tactics and rules of engagement that are used in law enforcement to defend against violent criminals can also be adapted to the IT world to defend our networks and systems against cybercriminals. In this article, I’ve touched on just a few of those.

If you want to get your house in order, check out our network security checklist!