Network Self Defense

This Musing and the next one (volume 7, No. 12) aren’t all that insightful.  Almost all of the information contained here-in can be gleaned from literature available on the Cisco web site (if you have a printer that can handle 1000s of pages and a few weeks time to go through it).  But this is necessary background information for a series of Musings I will publish starting in February 2005 (after a sidebar Musing in January to kick-off 2005), analyzing LAN security more in depth, using Cisco’s NAC as the poster child for one approach to the problem in order to weigh the pros and cons of other approaches. 

I greatly admire when a large and successful vendor remains pro-active in driving technology to satisfy more needs and meet more challenges.  Internally, it’s often a difficult thing for successful vendors to do this. There are always people running around with spreadsheets showing how cost reducing or incrementally improving the existing products could provide a quicker ROI, there are others concerned about opening up opportunities for competition by recognizing the existence of new issues, and still others who presume that the formula for success in the past always applies to the situation of today.  And, even if you can overcome all that, there remains the difficult management challenge of re-directing a big ship.  I would say that creating an internal culture that counterbalances such inertial forces so that a company can continually refresh itself and move forward is what separates the Ciscos and Microsofts of today from the DECs and Wangs of the past.    

This is relevant because this Musing and the next few are about securing the LAN, which is an area that Cisco has endeavored to drive not only themselves, but the whole industry, in an attempt to solve some very real and difficult problems (refer to my previous Musing titled “A Long Conversation About Security”).  

So, in the time-honored style of Marc Antony… I come here to praise Cisco, not to bury them.

To understand Cisco’s approach to LAN security requires understanding their Self Defending Network (SDN) initiative.  Understanding SDN, in turn, requires a lot of patience because there are so many components to it, they are all delivered in phases and sub-phases, and the story is continually evolving. But this is what you’d expect when you are talking about a major aspect (security) of the network architecture of the future.

As best as I can tell, Cisco uses the following taxonomy to talk about the components of SDN that exist to some degree or another today:

Almost all of the components of the 1st column above (Secure Connectivity) and many of the components of the 2^nd column (Threat Defense) were in existence in some form or another before anyone with-in Cisco even knew they had a Self-Defending Network initiative.  Having performed a lot of architectural and solutions marketing myself in the past, I can tell you that this is part of the game. When talking about your solutions framework and where you are headed in the future, you have to claim that what you’ve done in the past creates the foundation for the future, and it was all part of a grand master plan.  If you don’t do that, you marginalize your existing shipping products, which is where the revenues are coming from that allow the company to afford solutions marketing people. 

I don’t want to harp too much on that.  The stand-alone VPN devices, firewalls, and IDS’s, and all of Cisco’s router features in those security categories, are widely deployed and hugely valuable to end users.   But if that were all it was about, there would be no SDN.  There would just be continual upgrades to those point products.  The need for SDN, which is to say the need for Cisco to have an over-arching umbrella term for a set of delivered value propositions, is really driven by the 3^rd column – Trust and Identity Management.  And this is true because few, if any, of these values are delivered simply as a feature with-in a point product, but instead via architected cooperation among many system elements, both across the Cisco product line as well as from other ”ecosystem partner” vendors. 

It is that aspect of SDN I want to focus on.

In some Cisco literature, they define three distinct Phases of SDN deployment which are all related to protection against end systems attack, both directed and undirected (worms, viruses, spyware, malware):

1.      Host Protection:  Cisco Secure Agent (CSA)

2.      Host Configuration Policy Enforcement (NAC)

3.      Network Infection Containment (NIC)

Cisco rolled out CSA for both servers and desktops more than a year ago.  I think it is largely based on technology they acquired when they bought Okena. 

The CSA is an anomaly-based detection technology designed to prevent both known and unknown attack types.  It acts as a software “wrapper” around the host Operating System and intercepts OS systems calls to file, network, and registry sources, as well as to dynamic, run-time resources such as memory pages, shared library modules, and Component Object Model (COM) objects. The agent makes real-time “allow” and “deny” decisions based on rules that define inappropriate or unacceptable behavior for specific applications. 

In other words, CSA attempts to render infections powerless right at the end system.  That way it doesn’t affect that end system, and (probably more importantly) can’t use that end system as a base of operations to attack other devices on the network. 

I will discuss SDN Phase 2 (NAC) and Phase 3 (NIC) in more detail in my next Musing.