Compliance is a by-product of a Policy Driven Network

Alex Bakman has been really writing some good stuff lately. I was reading an article on his blog the other day and it triggered something in my head.  That is one of the nice things about reading the spliced feed from the Security Bloggers Network.  You are reading the combined output of over 50 blogs in one place.  Sometimes I don't even realize where the feed is from unless I take the time to look.  Anyway, back to the subject. Alex writes about an article by David Greene of BMC in itworld. Both Alex and David point out that rather than running a keystones cops firedrill every time a compliance audit or event takes place, wouldn't it be better to build compliance into your process or automate compliance.  David points out how much more really valuable this.  Rather than practicing good security for compliance sake alone, practice good security for security's sake and get compliance as an afterthought.  Makes perfect sense to me.

This is exactly what we are doing with one of our customers at StillSecure. Our customer is providing network and security services to another organization and the contract is governed by a number of SLAs. These SLAs include both network and security areas. Prior to working with StillSecure, each audit was essentially a fire drill for our customer. They would run around making sure that devices were all patched and shift people from one group to another to make up short falls, etc. Because of the nature of the contract, they became acutely focused on meeting compliance rather than building processes that allowed compliance to become a by-product of their daily operations. Our proposal which they have adopted calls for a "policy driven network". Under this plan, the network managers have at their fingertips a list of every device's status as of the last time they logged onto the network. This is true for managed and unmanaged devices, wireless and wired, remote and local.  Now when they are audited,  they just run reports of those devices and the latest status is right there.  No scrambling around, no keystone cops, no chaos.  Compliance with the audit is built into the policy driven network. Please don't mistake my message here - products are only one piece of the puzzle, albeit it an important if not frankly a large portion - they are just a means to an end. The real pony in here is the architecture / framework / approach to driving compliance. We worked with our customer to embed it into the fabric of their network through our policy driven network approach.

So, how did we help accomplish this?  Good question.  We started by using both our VAM vulnerability management solution and Safe Access, our NAC product.  How it works is that policies are set in Safe Access and VAM as to what profiles and configurations are allowed and not allowed.  VAM does its regular scanning on a scheduled basis.  On top of this, Safe Access detects every device as it comes on the network.  Unlike a normal NAC practice though, Safe Access alerts VAM to the presence of the device and VAM can initiate a full vulnerability scan in the background. Of course the network administrators also have the ability to initiate a NAC test at the time of log in as well.  All of this information, as well as other data such as IDS alerts and syslog are correlated and stored in VAMs on board database.  Of course, you could do this with similar technology to the StillSecure products, assuming they have similar interoperability.

In the future we will take this to the next level by combining the post-connect capability we have built into Safe Access and policing even more of the network activity.  This is a perfect example of providing real security and compliance by building it into the network process and not doing a compliance audit, for compliance sake alone.