Engineering Securi ty in the Context of Threat

At a time when the 9/11 committee is trying to investigate "What went wrong?", we decided in Chameleon to focus on what should be done in the future, trying to cover holes that are not yet exposed instead of covering the holes that we already fell into. The following newsletter describes some of the fundamental elements and assumption of securi ty engineering that have yet to be introduced or implemented in the United States.

The concept of "Securi ty Engineering" is quite new to U.S. audiences at least in the context of threat mitigation. That is to say that although there are a lot of securi ty engineers out there building securi ty systems only a few of them are actually developing and implementing threat mitigation solutions. Building a securi ty system is mostly done to solve one, two or several vulnerabilities. Building a threat mitigation solution means building a system that is constantly adapting to the method of operation of the aggressor.

Many people talk about adopting a new mindset that will make securi ty and law enforcement more aware and vigilant. However, when it comes to threat mitigation it is the procedural and structural design of the system that drives the skill and the mindset and not the other way around. The arguments made by critiques and pessimists concerning threat mitigation processes were refuted with results in the field. Whether it's the lack of resources argument, the legal ramification argument, or the scarci ty in terrorist events argument.we heard them all and we designed an engineering process that provides a solution that answers all of these concerns.

When trying to develop threat mitigation solutions some working assumptions must first be made in order to insure the effectiveness of the system. The most important assumptions must be made by articulating the differences between THREAT, RISK and SUSPICION. These terms that are usually used interchangeably but they are actually very different and their definition in relation to one another is crucial in the securi ty engineering process.

THREAT should be defined as SUSPICION that was not refuted. RISK should be defined as quantifiable THREAT based on the occurred incidents. And THREAT should be defined as the method by which an aggressor will attack.

The only time where RISK will be considered in the threat mitigation process is in the articulation of the securi ty objective. The securi ty objective is vital for the effectiveness of the threat mitigation solution. Not articulating a securi ty objective based on the following parameters will ultimately result in gruesome waste of resources and ineffectiveness of the securi ty apparatus.

The parameters for the articulation of the securi ty objective are:

• THE PROTECTED ENVIRONMENT - Defining the jurisdictions of your environment.
• THE OPERATIONAL ENVIRONMENT - Defining all the features of the protected environment that provide access points for an aggressor.
• OUR RESOURCES - Define what the organization is willing to spend and what securi ty resources the organization already has in place.
• AGGRESSOR'S CAPABILITIES - The potential methods of attack of the aggressor on the protected environment.
• THE CALCULATED RISK - The things you can or cannot lose from having an attack on the protected environment.

The securi ty objective should be a one-liner that includes all the above definitions for example:

• To minimize the potential of bombing or commandeering of a train in transit.
• To prevent the hijacking of an airplane in midair.
• To reduce the possibili ty for theft, vandalism or ro bbery at the Bank.
• To prevent the leaking of information from the agency.

You can see that articulating this type of securi ty objective dictates different allocation of resources. For instance, making the second objective a priori ty for DHS or TSA would have dealt with the actual 9/11 method of attack - hijacking. It also would have resulted in more money being spent on air marshals and bullet proof cockpit doors on airplanes, and not on implementing technologies that could hardly detect nail clippers in a purse.

The action verb and the protected environment definition in the securi ty objective also reflect the calculated risk that the organization is willing (or not willing) to take. "Prevention" means no calculated risk is taken and mitigation means some risk are assumed and expected. The securi ty objective must have a proactive stand. Do not articulate a securi ty objective by saying: "Minimize the EFFECTS of a terrorist bombing". This type of an objective is in the realm of doctors and emergency systems responsible for counting the dead and healing the wounded.

Billion of dollars are being spent on buying securi ty decorations such as cameras and screening machines and adding more overtime for police officers around the U.S. This is done because securi ty engineers are trying to beef up securi ty instead of mitigating threat and developing solutions based on a defined securi ty objective. The concept of "Beefing up securi ty" is not effective in threat mitigation. A well-trained individual with the right technologies, the right skill-set and the procedures to tie it all together in the context of threat can do the work of fif ty well-paid, under-skilled and unguided officers.

In conclusion, threat is always assumed as a constant in a threat mitigation framework. This means that the design and the maintenance of the system are done from the eyes of the aggressor and not the eye of the protector. Regretfully, most threat mitigators today are not experienced in building an effective bomb, conducting surveillance, or casing a potential target and therefore their securi ty design is not done in the context of threat.

Amotz Brandes
Managing Partner
Chameleon Associates LLC

<< Return to Newsletters | Print this page