I heard a nice analogy about engineers and basketball players recently that well describes the role of security: what it is at its best and at its less-than-best.
Some folks approach security as though it were an engineering project. Security managers map out regulations and protocols to be adhered to by the letter. Like an engineer designing a car or a building they consider budget and costing, throughput and appearance. In this approach, there may be a security team but there is no clear opposing team.
In basketball, as this analogy goes, there is a clearly defined opposing team. Indeed, the adversary is at the top of the coach and players’ mind at all times. They spend hours upon hours studying the adversary’s every move and trait in order to understand and therefore best anticipate how they will play and how to win against them.
Team players are expected to make their own split second decisions – in the moment – based on the strategic outlines the coach has provided them. They play based on how they believe their rival might attack. They recognize that although there are rules in basketball and referees to enforce them, their opponent may well try to take advantage and yes, break the rules, if they can get away with it. Basketball coaches and players are realistic. They are highly motivated as a team intent on winning against their opponents. Isn’t this attitude perfectly appropriate in Security?
I wish the basketball approach to security was more prevalent. Clearly, the consequences of winning or losing are more dear when instead of a league championship, it’s a game of life or death.









A good analogy, but with the wrong analog. An engineer creates systems that work by experimentation, data collection and analysis, and comes up with a new way to make something work –for instance how might we build a better and more useful mass spectrometer for airport inspections, or pattern analysis of whatever data we might have regarding the movements of terrorists tracked or captured in an airport, and especially the need to describe the limits of the system when there are insufficient data.
Your basketball team analogy is a very good one, but basketball is played on a defined area, with referees, and you have videos of the specific actors. Studying the opposing team’s behavior is a great idea, but to apply the basketball analogy you have to expand it to include far more variables –number of players, surprise substitutions, size and shape of court, quality of the defense, and rules of engagement and the penalties for fouls.
We need both sets of talents. The players who must engage the other team should study all the imaginable variations as you suggest, but some engineers could help in several ways.
The idea behind the flexible, trained team approach is what actually works! The bureaucratic, mapped out protocol and unit should never be mistaken for an actually functioning security team.
Flexible, trained and creative teams or units who can apply their vast knowledge and imagination to the challenge of the moment in a myriad different ways will win the day. It’s just hard to quantify sometimes and that is what upper management just can’t wrap their minds around.