Infosec: Frame it positively! Part 2

Be positive security model edition

 

Ten years ago, Marcus Ranum  made us think about the two most major dumbs, ‘Default-Permit’ and ‘Enumerating Badness’ in his paper “The Six Dumbest Ideas in Computer Security“. He said that enumerating badness dumb was really also default-permit but that it was in a special class of its own. In the paper Marcus wrote that there isn’t software support at the OS level in COTS systems for the cures or opposites of those dumbs, which are default-deny and enumerating goodness. I remember the overall reaction to his ideas generally being that they were great in theory, but they would be too hard to implement. Neither Marcus or many others seem to think there has been much change or progress since his paper a decade ago.

It should interest you to know then, that KSE DOES facilitate and do default-deny and whitelisting extensively, supporting this at the OS level.  This is where KSE (kernel security enforcer) rises to the occasion. KSE is not an OS itself, it’s a security sub-system and wrapper technology that is easily installed, on existing COTS systems, and delivers needed additional OS level controls to their operating systems.

I’ve been advocating the use of KSE as a user-centric, default-deny system for insider threat protection for a number of years. So yes, it is here and available now! There have been numerous references to this in past blog posts and in our literature.

 

Whitelisting applied to the insider threat

Trustifier looks at solutions from the insider threat perspective. Aside from firewalls, we see smatterings of whitelisting around but mostly hear about enumerating goodness through application whitelisting. This kit may prevent internal staff from inadvertently downloading suspicious apps onto corporate networks. Application whitelisting might also protect against the deliberate introduction of malware for the purpose of sabotage into the network, but the devil is in the details. The malicious insider tends to have multiple opportunities besides malware for malicious abuse, while operating under cover of authorized access privilege. Whitelisting for the insider threat must consider user operational privileges and the set of behaviors that are enabled by various user credentials.

When it comes to setting per user boundaries for the rules of engagement, one should ask, “What is someone’s intent when using an application, (or a device)?”

A question to ask is,

“what behavior or action is a person trying to execute while using a particular application?”

 

Since the insider most likely has access the keys to the kingdom using approved business applications such as MS Office etc., it makes the choice of application somewhat less relevant. For this reason, it’s necessary to  keep in mind that in order to whitelist end user behaviors that are enabled by insider credentials, technical controls would have to be much more fine-grained than the application level. App level controls are just too crude and blunt for the purposes of filtering end user behaviors. They are not designed for this purpose, so let’s leave app whitelisting aside for the malware myopic.

Right from the start, the cornerstone Trustifier message has been that the only truly effective way to protect against insider threats is to use a “positive” security model, which denies access by default and enforces only the minimum necessary access granted to users. 

 

KSE enables one to whitelist user end behaviors and executables.

 

Despite so many people thinking that this capability can’t really exist because it would be so hard to do. (John Pescatore’s Cult of the Difficult Problem is alive and well.) It happens to be part of KSE design and it’s pretty straight forward and intuitive to use. You may or may not know that KSE is based on unique algebraic modelling and does not work the same way as other technology, so it’s okay to leave the usual assumptions about complexity at the door. So whether one terms it a positive security model, default-deny, enumerating goodness, or whitelisting, KSE provides it. This can be for a single system, or a zone or whole network working in sync.

The most important point though, is that Marcus was and still is, correct that default-deny and enumerating goodness is a much superior way to do security. Anyone with a shred of common sense will agree.

Next post will discuss applying default-deny and whitelisting using KSE further, along with a few examples or use cases.

 

 

“The Predeterminator” custom art work courtesy of Scott Lewis

 

Related

How Hard Is Cybersecurity Exactly?

The Six Dumbest Ideas in Computer Security

By |September 6th, 2015|Insider threat, KSE|

About the Author:

2 Comments

  1. […] Home/Insider threat, KSE/Frame it positively 3. “What about Bob?” edition ­ iframe { visibility: hidden; opacity: 0; } Previous […]

  2. […] recent posts explain why to use math,  KSE algebraic modelling and advanced kernel protections, here, and here, which are the basis for KSE trusted computing, we can use protecting legacy XP as an […]

Leave A Comment