Engineering Security in the Context of Threat

20view_CA0.600At the time when the 9/11 committee was trying to investigate “What went wrong?”, we decided at 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 blog post describes some of the fundamental elements and assumption of security engineering that have yet to be introduced or implemented in the United States.

The concept of “Security 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 security engineers out there building security systems only a few of them are actually developing and implementing threat mitigation solutions. Building a security 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 security 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 scarcity 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 security 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 security objective. The security objective is vital for the effectiveness of the threat mitigation solution. Not articulating a security objective based on the following parameters will ultimately result in gruesome waste of resources and ineffectiveness of the security apparatus.

The parameters for the articulation of the security 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 security 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 security 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 possibility for theft, vandalism or robbery at the Bank.
  • To prevent the leaking of information from the agency.

You can see that articulating this type of security objective dictates different allocation of resources. For instance, making the second objective a priority 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 security 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 security objective must have a proactive stand. Do not articulate a security 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 security decorations such as cameras and screening machines and adding more overtime for police officers around the U.S. This is done because security engineers are trying to beef up security instead of mitigating threat and developing solutions based on a defined security objective. The concept of “Beefing up security” 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 fifty 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 security design is not done in the context of threat.

2 Comments

  1. GM on November 13, 2013 at 7:40 pm

    Excellent.

  2. Michael wright on September 29, 2017 at 8:48 pm

    Very interesting. Especially appreciate the last sentence.

Leave a Comment



15 + fourteen =