August 13, 2010

memes in infosec III - Perimiter defences against the unknown, invisible, unmeasurable...

Clive Robinson writes in comments, and I can do little more than post it as a special Friday 13th edition. Good luck:


The problem of spend too little, get hurt, spend too much, waste resources unprofitably is older even than money.

It is the basic problem with all defensive behaviour. If you go back to the times of the "hunter-gather" the gathers had an issue (as do all prey): if you put all your resources into gathering then you will not see the predator stalking you. If all gathers spend their time looking for predators, then no gathering will occur and they will starve. Thus there is some trade-off towards an optimum value of lookouts for any given predator, terrain or group size of gathers.

Interestingly the optimum is usually less than four, for all predators and group sizes that fit within a moderate shout range in open terrain. For larger groups, it is usually the number of watchers that will go around the edge of the group and remain within moderate shout range in open terrain. In closed terrain it depends not on shout distance but visual distance. Which is why you get very large groups (antelope, etc) in the open savanna, but much smaller-sized groups (monkeys) in closed areas such as scrub and forest, etc.

Now the important thing to notice is that the number of watchers goes up at a very very small fraction of the number of gathers.

All of which is why traditionally we have looked at perimeter defence. However it has a "physical assumption" underlying it which is "locality" which further assumes "visibility". In a network environment with 0-day attacks, everywhere that is connected is local. Thus perimeter defence only works with visible attack vectors (i.e. those that are known or exhibit behaviour that is sufficiently different from the norm to be detected).

Thus there are three basic classes of attack vector,

  1. Known (i.e. known knowns).
  2. Visible (i.e. unknown knowns).
  3. Unknown (unknown unknowns).

Within reason the Known Class can be correctly defended against with up-to-date Anti-malware, without effecting the day-to-day activities of a host (within the network perimeter). A simple measurand for this class is the number of attacks stopped.

Again within reason, the Visible Class may be mitigated against using various probabilistic techniques. This however may well involve considerable delay (with respect to attack time, not human time) and require "isolation" or "quarantining" hosts within the network perimeter which will usually negatively impact day-to-day activities of a host (within the perimeter). A simple measurand for this class is the number of events detected, a more difficult but more useful measurand is to distinguish between the "positives" (i.e. those that are seen and are proven to be attacks, those that are seen and assumed to be attacks and those that are seen and proven to be false alarms).

At first sight the Unknown Class cannot be defended against because there is "nothing to see" thus detect. Therefore the only perimeter possible is a "perfect air gap" which in current times makes a significant impact on some day to day activities of the hosts on such networks. Because there is "nothing to see" it could be argued that there is no measurand.

Setting the resource line should place it between the Visible and Unknown classes, but in most cases, resource restrictions actually puts it between the Known and Visible classes.

The question then arises, is the Unknown class really unknown?

The answer is probabilistic or a "Qualified No".

If an attack does not copy any host data and does not modify any host or its data and does not impact a hosts day-to-day activities, then its impact inside the perimeter is negligibly small at that point in time (it might for arguments sake use spare CPU cycles and memory to crack password files from another location).

Such activity might be very difficult but not impossible to spot. Currently, with monolithic executable files and current operating systems, it is effectively not possible to spot.

However there is a way that this problem can be resolved but it requires a different computing platform methodology both in hardware and software.


At which point, Clive stopped, leaving us dangling :)

Posted by iang at August 13, 2010 01:03 AM | TrackBack
Comments
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.