23 Apr 2008 09:15 PM EDT

Autonomic security, AKA, self-healing, self-defending, situation aware security, or feedback-based security management, has long been a dream in distributed IT computing.  It could be the reason that this dream was not realized is that it is too hard to do in distributed computing.

 Enter virtualized computing, with centralization and much greater control over the [wily careless security-ignorant only-cares-about productivity] user.  Now does that change the complexion of the problem?

 The enemy is the usual: malware, such as worms, viruses and trojans, plus future attacks we don't even know about now.   Malware designers unfortunately have the upper hand, with ever stealthier approaches to evil.  Most security countermeasures are simply responses to known threats.  Thus the bad guys are controlling the game.

With virtualized computing, IT asserts more control.   Might it not be possible to realize autonomic security more effectively?  One of the problems distributed computing has is relentless complexity and lack of control.  With distributed computing, the end user is in the driver's seat!  Maybe if all end users were very diligent about security this would be fine.  This is sadly not the case.

 Autonomic security affords the luxury of not relying on a human to notice things are stealthily going amok.  It is possible to monitor what is going on in the network, applications, OS's, processors, and so on.  With a virtualized environment, does this not become easier?

To be clear, it is possible autonomic computing actually creates additonal security challenges, dong things automatically like changing system configurations, interconnections and so on, creating interesting entrees for malware designers.

I'd very much enjoy a dialog on the following thought: in a centrally controlled virtualized environment, is security innovation possible?  Given that we can get better information about what is going on, for example anomolous behavior such as a processor being hit abnormally, or other anomolies such as buffer overflows or abnormal accesses or sensitive data being touched in any way, could we not modify the enterprise security policy on the fly?  Could we have software to look at the collective of information now at our fingertips and change security policy appropriately? 

 The model I have in mind is human behavior.  If you are walking down the street and it's daytime, and it's a cheerful sunny day, and nothing suspicious is going on, we behave in a way to maximize productivity and pleasure.  In contrast, if you're walking down the street and it's dark and late, and there are strange- looking people about, and they are looking at you with too much interest, your security posture changes and security becomes more important than productivity and pleasure (until you get out of the situation.)

So could we not use that model and have an adaptive security policy that intelligently changes, based on the information available.  Not attacks per se, as there is software that does that already.  What if we could look at the health of the network and applications and decide that situation is not normal and a more restrictive security policy is now required?  Productivty and pleasure take a back seat when it's "code red".

I'd like to hear from folks with thoughts in this area!

Permalink | Comments (6) |

Kate,

This sounds very similar to the Application Firewall for NetScaler. This is how the "Positive Security Model" used by the App Fireewall for web applications is described on our site -

The positive security model:

  • Models Application Behavior
  • Verifies Best Practices
  • Ensures RFC Compliance
  • Enforces Security in Real-Time
  • Is not Signature-Based

Of course, the App Firewall focuses on protecting external web apps. I am not aware of any product that uses the same "Positive Security Model" principles for Windows apps running locally (or virtually). Does this line up with what you envision? It certainly sounds like an intriguing idea.

Barry, great thoughts.  If there are products out there doing this for virtualized environments it would be good to know - especially if they do "baseline" normal behavior tracking and react when there are deviations.

Kate,

I don't think that centralized vs decentralized is the issue at hand.  Whether a system in sitting two feet from you or 3000 miles doesn't change your management capability per se.  What needs to start happening is better profiling of users and their applications.  Simply relying on known bad signatures or attempting to holistically determine what XYZ user is attempting to do isn't going to cut it.  As an aside, I consult for a very large bank that had a managed IPS system that happened to shut off a nodes ability to send SMTP because it was sending tens/hundreds of thousands of SMTP messages.  Shortly after it being shut off, the organization discovered that their outbound internet mail gateway wasn't delivering any messages.  In this circumstance the safeguard system actually disrupted business because it wasn't aware that this was normal behavior.  You see behavioral problems don't do any good unless the system is aware of baseline behavior.  On the other hand, if the IPS system is aware that this particular asset has always sent large amounts of SMTP traffic, then it would have ignored this otherwise glaring problem.  If a workstation PC all of the sudden started trying to send bulk volume of SMTP traffic where it otherwise normally would not have, then it's a condition that could be alerted/escalated.  Besides, often times the greatest threat is the one that doesn't fit aggressive obvious behavior.  Take for example data theft through a DNS subchannel.  Almost all auditing systems, etc. will allow such communications to tunnel just about anything through DNS queries completely unlogged and unnoticed.  HTTP, HTTPS, SMTP are all other methods, but most organizations do a pretty good job of at least logging their activity.

Shawn

http://www.shawnbass.com

The notion of "remembering" healthy baseline behavior and only reacting when there is a significant deviation is a good point.  I also liked the point about the less-obvious activities being more effective (from a malice standpoint) than the obvious aggressive activities.

 On centralization versus decentralization, I'd still contend the decentralized can be trickier to secure.  IT tends to have less control - users can download their own apps, use any media they can put their hands on, customize, muck around with things like registry settings, set up Kazaa as a favorite app - there's no madcap antic that some users won't try.

 Thanks much for the comments, great ideas

Posted by Anonymous at Apr 24, 2008 17:06 | Reply To This

Oops, sorry, forgot I wasn't signed-in yet.  Last comment was mine.

Virtualization will bring greater security control to end-user decisions, endpoint devices, and the datacenter - but different design and operational considerations must drive the architecture for this to be realized.  There will be much opportunity to automate workflows within the user to applicaiton chain to provide for dynamic security.  First of all, though, the protectors must understand what needs to be protected and redefine the architecture to support appropriate protection of sensitive data.  This is the big security failure of distributed computing - IT tried to protect everything and continued to suffer from compromise and loss because of the extensive security requirements of the distributed computing model.

Enter virtualization as a security control measure.  Virtualization allows isolation and compartmentalization that were never truly possible in distributed computing.  By compartmentalizing only the essential components of an operating system, patching it to recommended levels, and hardening this minimal OS, a "golden build" can be produced.  The notion of a "golden build" really helps redefine a baseline level of security for server and endpoint operating environments.  This foundation can then have isolated applicaitons dynamically delivered or streamed into it - without the applications being "installed".  Bypassing the installation of the applicaitons means that the applicaitons are not natively intwined with the registery and file system, which isolates the applicaiton from a security perspective and allows granular definition of what features can interact with the host.  Many of the security problems we experience today result from applications being interwined with the OS, filesystem, registry, and other applicaitons.  Virtualization technologies allow us to define and control these interactions in ways that were never before possible.

And, of course, golden builds for the applicaitons can be produced and delivered.  This is just one example of how virtualization can break apart the architecture we've been trying to secure and allow IT to better define security interaction at every layer of the applicaiton stack.

Once the security foundation has been built, and the associated business processes understood, automation of key security decisions will enable greater security control and results.  Virtualization will finally allow for both static and dynamic decision-oriented security decisions, a set of capabilities that has been sorely needed to protect sensitive data.