I. INTRODUCTION

Operations Security methodologies and techniques have evolved in response to the needs and requirements of the OPSEC customer. The application of OPSEC methodologies and techniques has been dependent upon the technical skills and experience of the individual OPSEC practitioner in the customer environment. As a result, these methodologies and techniques are not uniformly utilized. The purpose of this paper is to: Argue variability in applying OPSEC methodologies and techniques is undesirable Offer a quantifiable methodology for structuring the OPSEC process; and Initiate dialog within the community to address structuring of the OPSEC process and the use of concepts from the risk analysis community to support Step 4 of the OPSEC process.

 II. HISTORICAL PERSPECTIVE

Operations Security can be traced to communications security (COMSEC) assessment activities of the early 1960's. COMSEC assessments relied on monitoring to determine the vulnerability of communications to analytic exploitation. While monitoring provided a sampling of U.S. communications. it did not satisfactorily identify vulnerabilities. As a needed alternative to monitoring, the COMSEC survey was initiated. The COMSEC survey was a process of interviewing operational and communications personnel to identify vulnerabilities to existing threats. These interviews sought the operational requirements and modus operandi of the communicating parties.

During the middle 1960's PURPLE DRAGON teams refined the COMSEC survey methodology for application to the military environment in Southeast Asia. These teams had a focus: Identify operational activities which could serve as indicators of ongoing or pending U.S. military operations. PURPLE DRAGON combined the COMSEC survey techniques of interviewing and open-source exploitation with operational research methodology to examine operational activities and patterns which could provide foreknowledge and forewarning of U.S. military activities.

After the Vietnam era, OPSEC support to the military community continued but with a major difference. Robert (Sam) A. Fisher, at the National Security Agency, perceived that the focus of OPSEC should be the adversary. To facilitate this, Fisher developed two concepts to refine the OPSEC process. The first was "critical information," information that is critical in the sense that it could help an adversary achieve an objective. The second of Fisher's concepts was assessment of risk. Risk gives an understanding of how each vulnerability actually helped an adversary achieve an objective. The Five-Step OPSEC Process, incorporated by National Security Decision Directive (NSDD) 298, was now in place.

During this transition period, there was discussion about the need to automate and quantify the process. Consequently, Fisher and others developed an automated tool, VULTURE//PROBE, to incorporate all these ideas for OPSEC support. Designed to support the OPSEC survey, VULTURE/PROBE requires an OPSEC practitioner to decompose an activity into a three-level tree using expert knowledge and experience. The top of the tree is the Adversary's "objective." The second level documents the sequential "steps" that an Adversary would use to achieve the "objective." Together, these steps are sometimes referred to as a Hostile Intelligence Service (HOIS) Collection Strategy. The third level decomposes the "steps" into "ways" that the steps can be accomplished. For each "way" there is an associated number. These numbers are the probabilities that the "way" will accomplish the "step.' Once the OPSEC practitioner provides these third-level numbers, the tool then calculates the top-level numbers to yield the probability that the Adversary would achieve the "objective." Contributions made by VULTURE/PROBE were:

á Use of hierarchical systems theory (three-level trees).

á Forcing structure on the OPSEC practitioner. The practitioner must develop the HOIS Collection Strategy and "ways" to achieve the "objective."

á Providing a quantitative result. VULTURE/PROBE produces one number which is the probability that the Adversary will achieve the "objective."

The quantification in VULTURE/PROBE allows for "sensitivity analysis." Sensitivity analysis -- or "what if?" games -- is the technique of changing the value(s) of an independent variable(s) (like the probability that an Adversary completes a "step" by a particular "way") and seeing what changes occur in a dependent variable (like the overall probability that the Adversary will achieve the "objective"). Arguments for quantification are in a later section.

In 1990. LAVA/OPSEC was developed by the Los Alamos National Laboratory, United States Secret Service (USSS). and the National Security Agency. This tool uses the Los Alamos Vulnerability and Risk Assessment (LAVA) system, which was developed for complex systems and automated initially for Computer Information Systems (LAVA/CIS). LAVA/OPSEC users are cognizant persons who answer pertinent parts of a series of questionnaires. The tool provides risks for generic asset categories and is well-suited for system security. Contributions made by LAVA/OPSEC are:

á Brings proven concepts from the risk analysis community. The principal investigator of the LAVA system, S.T. Smith, incorporated state-of-the-art risk analysis technologies in the LAVA mathematics and the software engine and LAVA/OPSEC, in particular.

á Quantifies threat, vulnerability, and the severity of impact when assessing risk. In the LAVA system and in LAVA/OPSEC, the risk of a successful threat attack depends (among other things) on the weakness of the safeguards system (vulnerability), the strength of the threat, and the severity of the impact to the organization of a successful threat attack.

á Expands the use of hierarchical systems theory (trees). LAVA/OPSEC uses a set of very complex trees for modeling the safeguards system. A similar set of trees are used for threat and impact.

á Incorporates specific OPSEC issues into the methodology. The LAVA/OPSEC application addresses OPSEC issues in the questionnaires which are used for data collection.

NSDD 298 articulates OPSEC as a process of five steps: "Identification of Critical Information; Analysis of Threats; Analysis of Vulnerabilities; Assessment of Risks; and Application of Appropriate Countermeasures." A literature search defines OPSEC in several ways, usually in terms of the process. Samuelson states OPSEC is "...a logical way that an individual would think and act in a competitive or adversarial situation so not to disclose his intentions." Pattakos talks about "...a process by which potential adversaries can be denied information..." Also, Davis addresses OPSEC as a "...process of analyzing business operations to identify potential intelligence indicators..." Again Samuelson, "Because of this diversity and its inherent pragmatism, it has been difficult to capture the OPSEC concept in a single definition.', These definitions, while imprecise, serve to underscore that Operations Security is dependent upon the application of experience by the practitioner, for example, Fisher, Samuelson, Pattakos, and others.

Reliance on the OPSEC practitioner to apply the OPSEC process and the inherent subjectivity has been of concern to the OPSEC community for some time. Based on the authors' research, interviews, and review of the literature. the OPSEC practitioner individually structures the data-gathering process and analyzes the gathered data instead of using a common structuring mechanism. Furthermore, human nature dictates that a practitioner strong in one discipline because of education and background will steer application of OPSEC in support of planning and ongoing activities toward that background and expertise.

Otway and von Winterfeldt confirm this concern. In particular they compare the results of ten teams of experts doing data gathering for a complex risk analysis. In the initial exercise, the experts use individual ('informal judgments") structuring; in the next exercise, common ( formal Judgments") structuring is used. The teams' risk estimates had much wider variation in the initial exercise. In fact, in a later exercise when the teams of experts used common structuring and the same data, they reported almost identical risk values. Hence, common structuring of the data-gathering process yields more reliable results than individual structuring when assessing risks.

This concern is emphasized when one acknowledges the change in the OPSEC customer base. The customer environment of the sixties and seventies was oriented toward military operations. Today's environment is broader -- technology theft and anti-social issues such as narcotics trafficking, as examples. Also, the authors believe that today's customer, both military and civilian, require concrete data on which to base hard decisions. Furthermore, revision of the Department of Defense (DoD) 5000 series of directives for acquisition will demand that OPSEC develop realistic and supportable programs -- realistic in that OPSEC programs must address threat and vulnerability issues such as technology transfer and sophisticated adversaries, and supportable in that these programs apply available and affordable resources to OPSEC issues. Risk assessment and benefits gained from the application of OPSEC countermeasures must be quantified in order to be justified and projected over the life cycle of a program or activity. Operations Security must be prepared to adapt to this environment.

As noted by the authors, the OPSEC practitioner is a consumer of data while applying the OPSEC process. The OPSEC practitioner collects information relative to the activity. analyzes the data from the perspective of the adversary, and reports the results to the customer. To accomplish this the OPSEC practitioner:

á Decides what data to gather;
á Decides the format in which the data needs to be:
á Uses abilities and acquired expertise to gather this data;
á Decides how to store the data:
á Aggregates the data;
á Analyzes the aggregated data: and
á Reports the data.

Fundamental to this paper is that the structuring of these processes varies with each OPSEC practitioner. A common structure is needed to ensure quality, consistency, and responsiveness to the needs of the OPSEC customer. The remainder of the paper is a candidate.

This section discusses the philosophy and premises used to produce the methodology in Section V. The Five-Step OPSEC Process, as articulated in NSDD 298, has been successfully used by practitioners for decades and is fundamentally sound. It is consistent with risk analysis principles used in other security and safety disciplines. However, the authors' investigations indicate that the structuring of this process is more complicated than five steps. The philosophy in this section and the methodology in the next is based on (1) structuring techniques currently used by practitioners and (2) techniques derived by applying principles from the risk analysis community. The ideas in this paper integrate principles from both the OPSEC and risk analysis communities. New terms are defined as they are introduced throughout the discussion.

Premise 1 The task of the OPSEC practitioner is to offer the customer a 'best' and "acceptable" set of countermeasures.

An acceptable set of countermeasures stays below the resource limitations of the customer and causes less disruption to the sensitive operation or program than the customer's toleration limits. A countermeasure will not be applied if it costs too much or if it excessively disrupts operational activity. A risk-taking customer is willing to live with more risk than a risk averse customer. Therefore, the risk-taker's value judgments about resource limits and disruption may be lower and, hence, may exclude sets of countermeasures considered by the risk averse customer. On the other hand, a best set of counter measures provides the most net benefit: benefit due to countermeasures (discussed in Premise #2) minus the costs of the countermeasures (discussed in Section V).

The eventual task of OPSEC is to enhance operational effectiveness. This is accomplished by thwarting adversaries' achieving objectives. Each of the adversary's objectives has two features:

á Acquisition of information (critical information) is necessary to achieve the objective, and
á Achievement of the objective will diminish operational effectiveness.

OPSEC's specific objective is accomplished by preventing, confusing, or delaying the adversaries' acquisition of this critical information. The OPSEC practitioner provides the customer with OPSEC measures, or countermeasures, designed so that each counters critical information acquisition and collectively they neutralize adversaries' achieving of objectives.

Premise 2 The benefit of a set of countermeasures is reduction in the risk that adversaries will achieve objectives.

The general assumption is that the benefit gained by an application of any security countermeasures is the reduction in security risk to the customers programs and operations due to these countermeasures. In particular, for the OPSEC discipline, benefit is the reduction in the risk that adversaries will achieve information-dependent objectives.

Premise 3 The best possible acceptable set of countermeasures is provided by the best possible risk assessment.

A key to providing the best possible set of countermeasures is the ability to assess and analyze the application of countermeasures to OPSEC issues. This can be accomplished through the utilization of proven risk analysis techniques. Premises # 1 and #2 are taken from the risk analysis community.

Premise 4 Data collection to support Steps 1, 2, and 3 of the OPSEC Process -- Critical Information, Threat, and Vulnerabilities -- must be structured by the requirements of Step 4÷ Assessment of Risks.

Structuring of the OPSEC process facilitates uniform data gathering quantification, aggregation, and documentation of information. Otherwise, time and effort may be wasted by gathering useless or incomplete information. Even worse, necessary information may not be gathered. The result is that collection of data may not be focused and may have an undesirable effect on the assessment of OPSEC risks (Step 4).

Premise 5 OPSEC risks must be assessed by considering and using all the following "data categories" during the application of the OPSEC process. Furthermore, the quantifiable (asterisked) categories are related to OPSEC risk by the hierarchy in the OPSEC risk hierarchical decomposition tree (Figure 1).

á Identity of adversaries
á Adversaries' objectives
á Steps that an adversary must take to achieve each Objective
á Actual impact on operation of Adversaries' objectives being successful [discussed later]
á Critical information components (CICs) [defined later]
á Adversary capability to use acquired ClCs to achieve each step
á Locations that contain ClCs [discussed later]
á Functional areas containing ClCs [discussed later]
á Media, things, or events from which the adversary may acquire or infer each CIC [discussed later]
á Acquisition methods which allow each adversary to acquire ClCs from media, things, and events [discussed later]
á Vulnerabilities of each media or event to CIC acquisition by each adversary method
á Threat of each adversary to use each acquisition method against ClCs
á Adversary motivation to acquire ClCs
á Adversary opportunity to acquire ClCs
á Adversary capability to acquire ClCs.

This premise says that each category of data contributes to the risk that the sensitive operation or program will be adversely affected due to adversaries achievement of objectives. As a result, if one of these categories of data is not considered, the risk to the operation may be incorrectly assessed. The selection of countermeasures then would be based on incorrect information and might be less than optimal.

As stated, the quantifiable (asterisked) data categories also form a hierarchical decomposition tree of OPSEC risk to the operation. These categories actually provide a basis for defining the OPSEC posture of a sensitive operation or program. The remainder of this section is a discussion of this tree.

The risk to the operation [Box A in Figure 1 I depends on the likelihood, or possibility, that the adversaries" objectives will be achieved [Box B] and the impact of these objectives [Box C] (this risk is also called expected impact because it depends on a likelihood and an impact). Adversaries are agents who could use information about an operation or program to render that operation or program less effective. An adversary's objective is what the adversary wants to accomplish that could undermine the operation's effectiveness (discussed after Premise #1). The impact on the operation of an adversary's objective is a measure of how much operational effectiveness is diminished by the successful completion of the objective. If an adversary objective is successful but the impact on the operation is minimal, there is not much of an OPSEC concern.

The likelihood that an objective will be achieved [Box B] depends on the likelihood's that each of the steps of the objective will be completed [Box D]. To achieve an objective an adversary may have to complete several steps along the way. As an example, storming a fort may be decomposed into two steps: getting infantry in the best places outside the fort and attacking at just the right moment. Completing the last step is achieving the objective.

The likelihood that a step of an objective will be achieved [Box D] depends on the likelihood's that the Critical Information Components (ClCs) will be acquired [Box E] and the adversary's capability to use the ClCs to complete the step [Box F]. Critical information is the specific information required by the adversary to achieve a step in an objective. ClCs are derived by logically subdividing the critical information (required for a step) as far as possible-yielding information such as WHO, WHERE, WHEN, and WHATs. The result of combining steps and ClCs together is similar to the HOIS Collection Strategy.

Once the adversary has acquired a CIC, several processes may occur before the adversary completes the step. The acquired CIC is reported to adversary intelligence analysts to be processed and analyzed. The analyzed CIC is aggregated with other analyzed CICs. After the aggregation, the adversary decision maker makes a decision. Resources are allocated and action is initiated to complete the step. The degree to which all these processes are successful affect the adversary's capability to complete the step.

The likelihood that a CIC will be acquired [Box E] depends on the likelihood's that the CIC will be acquired in the individual locations [Box G] at which personnel or machines work on the sensitive operation or program.

The likelihood that a CIC will be acquired in a location [Box G] depends on all the likelihood's that the CIC will be acquired in the individual "functional areas' [Box H] such as personnel, logistics, operations, etc.

The likelihood that a CIC will be acquired in a location and functional area [Box H] depends on the likelihood that the CIC will be acquired by each medium, thing, or event IBox 1]. An adversary can acquire ClCs from information media such as paper, software, emissions, radio transmission, and conversations. ClCs can also be acquired by observation of things such as physical signatures or observation of events such as predictive and unusual activities. Using this context an indicator may be described as a specific medium, thing, or event from which a CIC may be directly acquired or indirectly inferred.

The likelihood that a CIC will be acquired in a location and functional area from a medium, thing, or event [Box 11 depends on the likelihood that the CIC will be acquired by each acquisition method [Box J]. There may be several different acquisition methods an adversary can use to acquire a CIC from a medium, thing, or event. For instance, a physical signature may be acquired by overhead satellite, visual observation, or infrared camera.

The likelihood that a CIC will be acquired in a location and functional area from a medium/thing/event by a particular method [Box J]. depends on the vulnerability of the CIC to acquisition [Box L] and the threat that the adversary will acquire the CIC [Box K]. A vulnerability is a weakness in the measures used by the customer to safeguard or protect the CIC from acquisition by the particular method. For a particular medium, vulnerability involves the availability of the medium, detectability of the medium, and the ease of extracting the CIC from the medium. For an event or thing that is observed, vulnerability involves the observability, identification of function, and the ease of inferring the CIC from the observation. Each of these factors affect vulnerability. A vulnerable CIC against which there is no adversary threat to acquire is not much of an OPSEC concern.

The acquisition threat by an adversary [Box K] against a CIC depends on the motivation [Box M|, opportunity [Box N], and capability [Box O] of the adversary. An adversary's willingness to accept the risk inherent in acquiring ClCs and willingness to expend resources affect motivation. Adversary opportunity is being able to get near media or to observe events or things in order to acquire ClCs. The adversary has to have access to acquire the CIC. This often requires additional information like existence of the CIC in the functional area and the timing of when the CIC is in the functional area. If the adversary has motivation and opportunity but no capability, then the OPSEC risk to the CIC from that particular acquisition method is minimal. Capability actually depends on resources allowing the adversary to acquire media and to analyze the media to extract CICs.

V. PROPOSED METHODOLOGY

This section presents a methodology to structure the data gathering and analysis required for assessment of risks, Step 4 of the OPSEC process. The proposed methodology may be used for either planning or survey activities -- applications which are consistent with established risk analysis concepts. This paper, as a point of departure, discusses use of the methodology in support of surveys.

This methodology is intended to support a customer who has the authority and resources to implement countermeasures. The actual user of the methodology is expected to be (1) an OPSEC practitioner, or (2) an OPSEC trainee guided by a practitioner. The rationale for this expectation is that the methodology pre-supposes experience and training in applying the OPSEC process, particularly within the customer environment.

The description of the methodology has four phases: input that collects information for the data categories, computation that fills the hierarchical tree with values, investigation of possible countermeasures, and computation to choose an optimal set of countermeasures.

The proposed methodology takes advantage of activities usually undertaken during the OPSEC process. Pre-survey research and study, on-site interviewing, and data collection in the field are all inherent in the process. While performing these functions, data is assigned into the data categories discussed in the previous section, and values are assigned to the data categories at the lowest levels of the tree (all asterisked categories except THREAT, discussed in the next section).

After assignment of values to the lowest data categories during the Input phase, quantities (like THREAT) are calculated upward toward the top part of the tree. This is done by appropriately aggregating the numbers branching from one node as the value of the information on that node. For example, the values of MOTIVATION, CAPABILITY, and OPPORTUNITY are aggregated to provide the value for THREAT. By continued aggregation, the value of the top node of the tree, RISK (EXPECTED IMPACT) TO OPERATION, is calculated. The result of this analysis and processing is:

á A structured record of input information together with comments about data category entries for future reference.

á A list of different sources' (location, functional area, media/thing/event, and method) likelihood's that each adversary will successfully acquire and report each CIC to adversary intelligence analysts -- call each of these outputs a "acquisition source table." The advantage of having acquisition source tables is that they are valuable for deciding which vulnerabilities have the highest possibility of adversely affecting the operation and, thus. assisting in the choice of countermeasures.

á Risk (expected impact) to the operation relative to all adversaries successfully achieving their objectives. This number reflects all data categories. When impact is given in dollars, this risk (expected impact) will also be in dollars. This is an actual number not a relative number. A risk (expected impact) of $40,000 is twice as bad as one of $20,000.

From experience, interviews, and research, each possible countermeasure is documented by indicating:

á A description of the countermeasure.

á The reduction in vulnerability value for each pertinent source (location, functional area, media/ thing/event, and method) due to the countermeasure,

á The additional vulnerability to CIC acquisition for each pertinent (possibly different) source due to the countermeasure,

á The cost of the countermeasure.

The cost of a possible countermeasure may be monetary and may also include non-monetary costs such as reduced operational efficiency, adverse publicity, unfavorable working conditions, and political consequences.

The purpose of this last phase is to recommend to the customer a set of countermeasures using the criterion from Premise # 1: best acceptable. First the upper cost limits that the customer is willing to commit for countermeasures are determined. For example, these limits could be:

A set of countermeasures is acceptable if the aggregate costs do not exceed the customer's limits. Only acceptable sets of countermeasures are considered.

For each acceptable set of countermeasures, sensitivity analysis is performed yielding:

á Post-countermeasures likelihood that each adversary will successfully acquire and report each CIC to adversary intelligence practitioners -- acquisition source tables.

á Reduction in the likelihood of each critical information component's acquisition due to the set of countermeasures.

á Post-countermeasures risk (expected impact) to the operation relative to all adversaries successfully achieving their objectives.

á Reduction in risk (expected impact) to the operation due to the set of countermeasures -- benefit as described in Premise #2.

Finally, a recommendation is made for a set of countermeasures:

á Whose costs stays within the cost limits -- acceptable -- and

á For which the difference" between the benefit [reduction in risk (expected impact) to the operation due to the countermeasures] and the total cost of the countermeasures is the largest possible

á best as described in Premise #1.

The output of this structuring methodology is available to support preparation of a final report to the customer. The advantages are detailed in the next section. VI.

There are several advantages of the proposed methodology. The methodology considers an extensive set of data categories. The result is a risk analysis based on an expanded view of the OPSEC posture of the operation. Because the methodology forces structure and record keeping, the results are less biased, not dependent on the memory of the expert. An audit trail is readily available for future analyses. The customer is provided credible and defensible recommendations that are based on objectively collected data. This is crucial when resources are scarce and need to be judiciously applied against critical OPSEC issues.

Because the methodology is quantitative, there are additional advantages. One advantage is that it promotes structured analysis through mathematical formulas. Another advantage is that it allows flexibility in supporting decision making, especially by sensitivity analysis. Sensitivity analysis can be used to test the effect of variations in vulnerabilities to assess a set of countermeasures. Sensitivity analysis will also enable OPSEC analysts to examine and make comparisons of:

á Different operations or programs competing for resources, and
á The same operation across time to assess improvement in OPSEC posture.

The authors believe a third advantage of quantification is that it forces deeper thinking by the OPSEC analyst.

The final advantage is in the area of justification of an OPSEC program. The Adkinson Security Project advocates that security function as a profit center. That is, the security staff should Justify the monies received (cost) by demonstrating the saved monies due to security (benefit). Such an argument could apply to an OPSEC program. The proposed methodology shows what, where, and how resources are being expended in support of OPSEC objectives [COSTS OF COUNTERMEASURES and what operational resources are being impacted by OPSEC countermeasures [NET BENEFIT]. With OVERHEAD, these are the quantities needed to articulate OPSEC as a profit center:

OPSEC PROFIT = NET BENEFIT DUE TO COUNTERMEASURES FOR ALL PROGRAMS - COSTS OF COUNTERMEASURES FOR ALL PROGRAMS -OVERHEAD COSTS OF RUNNING AN OPSEC PROGRAM

The structuring of the OPSEC process as detailed in this paper is obtained by applying risk analysis techniques to the OPSEC process. This approach can be extended to include concerns of the traditional security disciplines. The risk analysis community uses methodologies to support the protection of any asset against threat agents that might produce any outcome. The proposed methodology satisfies the following schema:

That is, the only asset being protected (directly) by OPSEC is critical information, and the only outcome to critical information that OPSEC tries to prevent is adversary acquisition of the critical information.

This methodology can be extended in two ways. First, assets other than critical information can be considered. Second,

more than one outcome can be considered. For instance. when protecting information, one may try to prevent not only adversary acquisition but also denial of use and destruction. Full extension in both ways -- a goal the authors believe is possible ÷would be a risk analysis methodology designed for full program protection. It would allow a single risk analysis of one or all security disciplines including OPSEC. Moreover, it would preserve structuring and quantification of risk allowing sensitivity analyses.

The OPSEC process has been and will continue to be driven by customer needs and requirements. To date, application of the process has been subjective and reliant upon the expertise and experience of the practitioner. Today's customers have more sophisticated needs. The authors believe these customers increasingly require more objective data than currently provided by the OPSEC community. This paper's methodology confronts these issues by providing a structure for OPSEC thought processes that meets the needs of today's customer.

At this writing, there are no standards for OPSEC structuring known to the authors. The contention of this paper is that there is a need for standards that ensure levels of quality, consistency, and responsiveness to the needs of the OPSEC customer. The structuring methodology in this paper is a candidate standard and should serve as a departure for discourse within the OPSEC profession.