Kenneth G. Hartman bio photo

Kenneth G. Hartman

Security Consultant,  
Forensic Analyst & 
Certified SANS Instructor

Email Twitter GitHub

For today’s post, I am delighted to have an entry written by Jack Emanuelson. Jack Emanuelson is an independent contractor specializing in OPSEC and information assurance. He earned his BS in Business Administration from the American University and an MBA from George Washington University, and is a graduate of the U.S. Army Command & General Staff College. He previously occupied the David G. Boak Operations Security Chair at the National Cryptologic School. Jack is retired from the U.S. Civil Service and is a Lieutenant Colonel, AUS (Ret). Currently, Jack serves as a member of the board for the national OPSEC Professionals Society (OPS).


I’m going to first address what OPSEC is and then speak to how the term has morphed and now has many meanings. What do I mean by “OPSEC is really not OPSEC?” The OPSEC (Operations Security, not Operational Security) of military planning is derived from a program during the Viet Nam era to find out why so many of our missions, especially air attacks, were not succeeding.

OPSEC is a five-step risk management process that focuses on only the most sensitive or critical information that, in the hands of an adversary, could limit success or give an adversary a decisive advantage. OPSEC follows the common risk management format but employs several unique steps:

  1. Identification of the asset to be protected;
  2. Analysis of the threat in terms of the opponent’s intent and capabilities;
  3. A search for vulnerable information that could lead the adversary to piece together or infer critical information through open sources and observation;
  4. Leadership analysis of the acceptable level of risk and, if necessary, approval of OPSEC measures to lower risk; and
  5. Implementation of the approved OPSEC measures and continuous monitoring of all risk components to detect change and respond accordingly.

First and foremost, OPSEC is a risk management process. It begins with identifying what it is that you, or your organization wants to accomplish. This is usually a program or activity. Examples of this could include:

  • successfully take out an enemy target without suffering undo loss of life or equipment;
  • bringing a new product to market without a competitor interfering or beating you to market with a similar product; or
  • protecting your home and valuables when you are away on a two-weeks’ vacation.

The next part of the OPSEC process is to determine if there is an adversary that would and could prevent your from accomplishing your objective or benefit themselves to your detriment. If there is such a potential adversary, think about their capabilities to do you harm and their supporting intelligence to allow them to take action. This is the OPSEC focus. For example, think about a new product in development. You would not want a competitor to even know about the existence of such project. Let’s call this information ‘critical information,’ mark it COMPANY CONFIDENTIAL, and limit the number of people in the company that are in on the secret. How then could your competitors become aware of the project?

Think of a normal competitive intelligence effort. If one wants to find out what a competitor is up to they use open sources and the powers of observation. Bribing an employee or breaking into the company offices are not concerns of the OPSEC process – these are security’s problems. OPSEC is counterintelligence. If one cannot get to the critical information itself, the alternative is to identify ‘indicators’ that could lead to deducing the critical information. Sales personnel are constantly probing their clients and the sales forces of competitors for information about what the competition is doing and what intelligence the competition is seeking. If material is involved, the manufacturers are constantly tracked; if component products are involved, the producers are quietly queried; a new facility might mean a new project. A well developed intelligence program will know exactly where to go to gather indicators and put them together to get the full story.

The final parts of the OPSEC process are to determine the risk to the project/activity if the adversary collects the indicators and correctly deduces the critical information, and then to perhaps take counter measures.

If the risk is substantial, OPSEC counter measures must be undertaken to control the indicators. This may use a combination of real and made-up indicators to get the adversary to respond as you desire. For example, your goal may be to lead your competitor to infer that your ‘new’ product is nothing but a slight improvement on an existing product. Of course, this all must be within the legal limits of commercial deception.

So, that is the true description of OPSEC as it was conceived by the DoD and is currently practiced by military planners. Recall that OPSEC was established as a program in the 1960s, when military record communications were primarily via teletype machine and computers were exclusively centrally located mainframe units.

Operations Security

The IT folks treat OPSEC more as operational security and expand it to include all possible vulnerabilities that could threaten an information system and its contents. For example, refer to the Operations Security domain, in the CISSP Common Body of Knowledge. Also note that the Official (ISC)2 Guide to the CISSP CBK does not use the OPSEC abbreviation to refer to Operations Security.

Nothing wrong with calling operations security “OPSEC,” but the true OPSEC process is a niche risk management tool with a specific purpose and should be considered part of the overall protection effort. Now here is where “my” OPSEC (at least as I described it above) and IT OPSEC can coalesce. My OPSEC allows the identification of the most critical information sought by adversary/competitor intelligence, as well as the little bits and pieces (i.e., indicators) that could compromise the critical information. Critical information must be appropriately marked and protected through IT separation and authentication, e.g., encrypted in transit and at rest, behind the firewall, continual monitoring of the system and files. The ‘indicators’ that have been identified are also given preferential security treatment and all users are made aware of the importance of protecting these seemingly unimportant pieces of information. “My” OPSEC now becomes part of the overall operational security program.

Another aspect of how OPSEC has morphed from a five-step risk management process is the wide-spread believe that all sensitive information (such as FOR OFFICIAL USE ONLY and CONTROLLED UNCLASSIFIED INFORMATION) is an OPSEC problem – It is a security issue. “My” OPSEC only protects unclassified information that could lead an adversary to deduce the most critical information.

Protecting everything that is ‘sensitive’ unclassified information is fine, but if that information leads to critical information, it deserves special recognition and protection. We can only identify these indicators by starting with the mission/objective, identifying a creditable threat, and progressing to the information that the adversary needs to act, and how that adversary might obtain that information through exploitation of indicators. The formal OPSEC process is only used for programs and activities that are super important (to the program owner) and are worth the analysis effort necessary to apply the five-step OPSEC risk management process. However, a basic understanding of the Five Step OPSEC Risk Management Process is valuable to all organizations that protect sensitive information, even if it is not rigorously applied, because it highlights the danger of leaking information that could be of value to an adversary. It also emphasizes that multiple indicators, which may seem trivial in and of themselves, can be correlated to reveal secrets.

Regards, John (Jack) Emanuelson, OCP, CISSP, CAP, GSLC

Read Jack’s two part article on OPSEC in the Febuary and March, 2012 editions of the Newsletter of the Security Analysis and Risk Management Association:

Operations Security (OPSEC) at a Crossroads: Part I

Operations Security (OPSEC) At A Crossroads: Part II