Decoding Security Jargon

If you pick up just about any security textbook it will begin by describing security using terms such as threats, risks, vulnerabilities, exposures, agents, and so on.  These terms are fine for discussions between security professionals who agree on the definitions.  However, I find they are often too technical when striking up a conversation with a non-security savvy next-door neighbor, marketing business partner, or mother-in-law.  Oftentimes security professionals even have a difference of opinion on the true meaning of some of the terms.  So I’ve spent some time thinking about ways to simplify what the term “Security” really means in a simple, generic way that can be used in every-day conversation without requiring CISSP-level knowledge of security jargon.

 

I have come to the conclusion that “security” is almost always in reference to assumptions about trust.  There are many forms of trust that may apply.  Trust may be formed between people, between systems, between organizations, or any combination thereof.  There are “good” assumptions (more secure) and “poor” assumptions (less secure) about trust.  Therefore whenever we are making something more secure, what we usually mean by this is that we are trading one or more poor assumptions about trust for better assumptions about trust. 

 

Consider the owner of a store.  She could choose to have no security on the store and just assume that everyone can be trusted not to enter the store after hours (a poor assumption).  If she puts a lock on the door, she shifts her trust from “everyone” to a lock.  There is now an assumption that the lock will dissuade more honest people from entering the store after hours (a good assumption) and that it may even be sufficient to prevent thieves from entering in the night (a poor assumption).  Instead of putting all her trust in a lock, she may add an alarm that will make noise and notify the police.  So now instead of only trusting the lock, she has moved to several “better” assumptions such as trusting that the alarm will sound if an intruder evades the lock.  During business hours she could just assume she can trust everyone who enters the store to pay for merchandise (maybe poor depending on where you live).  Or she can effectively reduce the likelihood of shoplifting by trading that assumption for deterrents such as cameras and anti-theft sensors.  This does not make the store 100% secure.  Someone may still evade cameras and socially engineer their way out of a beeping sensor; meaning, there are now new assumptions about trust.  But they are “better” assumptions.

 

The same terminology works in the context of computer systems.  The programmer can assume that all input coming from a browser to his web application can be trusted or he can shift that assumption to trusting firewall (WAF) rules or validation.  Doing so doesn’t mean the program is 100% secure.  It just means that he has traded one really bad assumption about trust for some better ones.  The same goes for confidentiality.  The network administrator may assume that he can trust that nobody is going to eavesdrop on the applications he supports or he can properly configure TLS (or SSL) to ensure all traffic between the users and the application is encrypted.  Once again, this does not make the solution 100% secure but it trades a poor assumption about trust for a better one, as he now trusts the effectiveness of TLS.

 

Confidentiality, Integrity, and Availability (i.e. the fundamentals of security) all involve assumptions about trust.  And the act of improving any of these involves trading bad assumptions for better ones.  You may be wondering how can we better describe the level of “badness” of an assumption.  There is one word for that: “risk”.   This word is so popular that some organizations fund entire departments called “Risk Management” to handle it.  Depending on the environment or business, there may be many types of risk that need to be managed.  If you ever find yourself wondering if one of them qualifies as a “Security Risk”, you need only ask yourself: “does it involve an assumption about trust?”  If yes, then it most likely is a Security Risk.