For the past five years Great Bay Software has been carefully stating our belief that there are real IT Security threats associated with the non-windows computing devices in the enterprise network.  We’ve been mentioning this carefully because this information has been largely met with eye rolling and snickers; the most common feedback being “our concern is with the Windows-based user devices; our printers, SCADA, UPS’, HVAC, IP Phones, IP Cameras, etc. do not pose a threat”.  

As evidenced by two recent items in the press, the light is beginning to shine on these devices and their role in the IT security threat landscape.  The first one is about an enterprising young man who hacked into the HVAC systems (among other things) in a hospital:

The article is here:

http://www.darkreading.com/insiderthreat/security/attacks/showArticle.jhtml?articleID=218300006

and there’s loads more information here:

http://www.mcgrewsecurity.com/2009/06/30/ghostexodus-the-eta-and-a-control-systems-incident-at-carrell-clinic-part-1/ 

Note - be sure to check out the videos of our brave little superhero installing a botnet on an XP machine and later showing off his myriad of toys; you’ll laugh, you’ll cry, you’ll run home and make your kids work harder in school.  My favorites are 1) when he logs into the PC he’s about to attack bare handed and then puts on latex gloves so he doesn’t leave any fingerprints and 2) when he conceals his face during the “tools” video only to show an up-close of his fake FBI ID with his real picture on it. 

Although some folks have been quick to point out that changing the temperature in a room isn’t immediately life threatening, it certainly isn’t funny either, especially for folks that are in surgery or seriously ill.  Further, health care facilities have a myriad of patient care system on the network and if this person had targeted those there could have been a real threat to the health of patients.  I’ve seen a number of posts that defend his actions by stating that he technically never changed anything, but really, simply messing around with these systems should be considered highly illegal.  Patient care systems in particular are frequently older Windows OS devices that cannot be patched or updated due to federal regulations about who can change what and when on them.  In the wide range of systems attaching to the enterprise network today I would think securing unpatched, outdated, patient care systems would be a much higher priority than securing the managed, patched, updated, back office machines.  Yes, I know they have PHI on them, but preserving lives should take priority over preserving data.   Many IT professionals in health care are aware of this and continue to fight the good fight in trying to get this prioritized, but their pleas continue to be met with that same eye rolling and snickers. 

I recently wrote a blog post at the request of the good folks at the Trusted Computing Group.  After initial confirmation of receipt and acknowledgement that it would be posted, it seems there was some sort of intervention and it was never posted.  I figure the most likely reasons are:

• it just wasn’t good enough
• it wasn’t centered enough on TGC/TNC specific matters
• it didn’t include the requisite amount of TNC cheerleading
• it lacked tact and was irresponsibly forthright 

In any event, I’ve waited a few weeks to see if it would be posted but it hasn’t been, so I thought I’d post it here and you can be the judge.

~~~~~~~~~~

Confessions of an industry standards antagonist

I’m a fan of proprietary solutions.  Being first to market, creating a solution to a problem that had, until then, not been solved is what innovation is all about.  Watching potential customers get excited because someone finally has brought to market a novel approach that solves a real problem they have; that’s what gets the blood pumping.

The problem is, of course that the forces of ‘do more with less’ and the ‘zero day’ IT security landscape make this proprietary chaos incredibly destructive to the folks managing enterprise IT systems.  Consider that the vast majority of IT security systems implemented over the last 10 years (Firewalls, IDS/IPS, Anti-Virus, Anti-SPAM, Anti-everything else, Encryption, Web Proxy, SIM, SEM, 802.1X, NAC etc.) barely communicate with one another and when they do, its most frequently because one of the products can ingest syslog or retrieve and interpret text files.  The resulting system is often one that instead of doing more with less, forces the customer to simply do less.

Industry standards can be a slow process, and from what I’ve seen it requires the patience of Job to navigate the process while balancing a very diverse set of opinions and the requirement to make progress.  However, if industry standards were available and leveraged by vendors in IT Security for information sharing alone, enterprises would experience fewer audit findings, the operation of the IT system would be dramatically more efficient, new technologies would be deployed with less risk, and in a fascinating turn of events; customers would be able to dedicate more time to new and emerging technologies (that’s code for - they’d buy more stuff from the vendors that adopted the standards).

Over the last 15 years the phrase “nobody was ever fired for implementing...”  has been used frequently in a myriad of situations.  My first recollection of this was when folks used to say it about IBM (they don’t anymore), and over the last 8-10 years its Cisco whose name is inserted as the company most likely to help someone not lose their job.  I would say, however that looking back over the last 15 years it’s ultimately even more accurate to say that nobody has ever been fired for implementing industry standards.

~~~~~~~~~~ 

802.1X has been around for 9 years now yet it remains sparingly deployed in the wired network.  Despite its poor market penetration on the wired network thus far, I believe 802.1X is nearing a time of wide spread deployment.  Here are two top level reasons why its way to early to give up on 802.1X, and why I think it will flourish.

1. Organizations genuinely need it 

Many large organizations have known they need 802.1X for years, but have been waiting for vendors to provide a more mature system.  This leads me to reason number two. 

2. Vendors still want to sell it 

Despite the fact that 802.1X itself is quite simple, there are numerous areas of complexity in 802.1X deployments that provide opportunities for companies to differentiate themselves.  The more these features can be built into other products like switches and servers well, you know the deal...

802.1X also uniquely creates ‘stickiness’ with other components of the IT system and allows vendors to position our beloved ‘solutions’ instead of ‘products’.  Here are a few quick examples:

• Having a supplicant (client) that is tightly integrated with the authentication server and provides extensions such as NAC attributes
• Guest Access products that allow guest/contractor provisioning as well as device provisioning that can also be integrated with the switches and/or authentication server
• RADIUS accounting information that can provide a more robust troubleshooting and administrative system by providing detailed information from switches and RADIUS servers and be aggregated and summarized in a SIM product

Whichever vendor is the first to deliver a comprehensive 802.1X solution inclusive of 802.1X supplicant, switches capable of authenticating EAP and non-EAP endpoints, AAA, and management/administration is going to win big; not just with client software, RADIUS and management servers, but with large network upgrades.  The major vendors have all made 802.1X-centric acquisitions 802.1X including Cisco (Meetinghouse), Juniper (Funk Software), and Symantec  (Sygate) and they’ve all completed the first phases of integration between these components and other peripheral systems or associated products.  It will be fascinating to see how they all fare in the next 12-24 months.

Granting network access based on the MAC address is not new; it’s been around since the days of LAAs in Token Ring and Ethernet hubs (probably before that too, but that’s as far back as I go).  Secondly, it is not terribly secure when compared to other network access methods like EAP, and SSL but the increased deployment of MAC authentication in enterprise networks is definitely happening and for some good reasons.

Instead of locking MAC addresses to Ports, which has proven to be administratively cost prohibitive MAC Authentication leverages a database of MAC addresses either on a discreet system like Great Bay’s Beacon Endpoint Profiler or a white-list of MAC addresses that reside on the RADIUS server itself.  On switches its called MAC-Auth-Bypass in Cisco speak, but the major networking vendors all have their own flavor of MAC Authentication on their switches

The primary motivators we’re hearing from enterprise organizations for deploying MAC authentication are:

For increased security - 

Although not as strong as supplicant-based 802.1X, if you subscribe to the locked door theory (you know - the one that says most criminals will check the door and if its locked they’ll move on without ever checking to see how strong the lock is) then MAC authentication is a meaningful addition to the security of the enterprise LAN.  If you can detect MAC Spoofing, which is the way to defeat MAC authentication, then MAC authentication is that much more secure.

As a precursor to stronger authentication or NAC - 

MAC authentication is an important first step in a phased approach to NAC and/or 802.1X.  In some cases, customers are using MAC authentication to vet the 802.1X control plane prior to enforcing authentication or to overcome challenges such as PXE boot or login scripts that prove difficult to accommodate in an 802.1X deployment.  In addition, it remains the method for granting network access for devices such as printers, phones, UPS, WLAN APs, etc for the life of the deployment.

To provide an answer to the question “do you know what is attached to your network?” - 

This question, and the ones related to it, such as “how do you know when a new device is plugged in?”, “how do you maintain a history of endpoint addressing and locations?” and “how do you know which endpoints in the network are actually yours?” can all be answered through the deployment of MAC authentication.  Depending on how you gather and maintain the database of endpoints this can be a system that provides important contextual data beyond the MAC such as identity, IP address, and location.

Too much diversity for a client based approach -

It isn’t uncommon for companies to research the deployment of 802.1X and/or NAC and realize that the endpoint landscape in their network is just too diverse to make the deployment of client meaningful.  Although this can be true in any network the most common candidates for making this decision are health care (due to patient care systems), Energy (really anyone with SCADA systems), and manufacturing all of which have highly diverse endpoint types 

There are those that will look down their nose and proclaim that MAC authentication isn’t secure, but I would argue that it’s a meaningful addition to enterprise network security and dramatically easier and less risky to deploy than many of the alternatives.

Gartner (Lawrence Orans)recently published a paper entitled “Introducing the Identity Aware Network”, which can be found here if you subscribe to Gartner’s services or are willing to pay to read it:

http://www.gartner.com/DisplayDocument?ref=g_search&id=834420  

Alternately, you can read Tim Greene’s article about it here for free:

http://www.networkworld.com/newsletters/vpn/2009/011209nac1.html  

Although it's tempting to lament the points in the paper that I disagree with or feel needed more consideration in the paper, the central theme that Mr. Orans is highlighting is so compelling to the management and administration of the enterprise network that I’d like to focus on that instead.  Since the ratification of 802.1X and subsequent emergence of NAC, the vast majority of vendors and customers have missed the fact that identity, one of the most readily available by products of a deployment of 802.1X/NAC, can unlock numerous efficiencies, support compliance initiatives, and improve IT security.   

The ability to map connectivity and device attributes such as IP address, MAC address, Machine Name, etc to the name of a person is a huge leap forward in troubleshooting IT systems, incident response processes, and compliance initiatives.  To highlight this, consider the following scenarios:

1.     Someone calls the help desk because they can’t print or can't reach some network resource.  The help desk technician, instead of asking for the users MAC Address, IP Address, Ethernet Jack, Printer Name/Queue they’re trying to print to, etc, they can simply ask “what username do you use to login in the morning?”.  Because of the authenticated session, the additional information required to initiate this troubleshoot, such as the items I mentioned, are already associated withthe username and if they don't provide an immediate resolution, they certainly provide a meaningful start to finding a resolution.

2.     A security incident is received where an IP address has been detected doing something or other that is either undesirable or impacting network availability.  Instead of going through the usual hoops of locating the IP, looking up the current assignment in DHCP and/or ARP tables, scouring SAT tables to find the port to which the device is attached, tracing the cable to the patch panel, finding the jack, etc. the person working on that incident could simply search for the IP and learn which person was using the machine.  Instead of all the aforementioned gymnastics you could simply call the person and tell them to knock it off.  <reality check> ok, so the person would really email them and CC his/her boss –people don’t call each other anymore.

3.     Given that there is a real migration away from traditional ‘phones’ (I only use a Blackberry and Skype and I don’t think I’m terribly unique in doing so) the concept of E911 is in real need of an overhaul.  My recollection is that when I signed up for Skype voice calling it said “not for 911” or something similar. So, why can’t a person get help when they’re incapable of speaking, but can somehow dial 911, click “call” in Skype, send a text, or even (I can't believe I'm writing this) send a tweet.  I admit, it seems hard to believe that someone would text rather than call, but if you think about it, a call either connects or not whereas a text endures until the person sees it and if you can't speak a voicemail isn't an option.  While this scenario is admittedly more obscure than the aforementioned, one can easily see that the raw materials for such a system being a strong IP-to-Identity binding.

Additionally, although not mentioned in the Gartner paper, the notion of Identity also needs to be expanded beyond the person.  Everything connected to the network has an identity (printer, WLAN AP, VOIP phone, etc.) and those values are often as important as the person-centric identity.  I’ll stop that thought right there before it becomes a Great Bay product pitch, but the applications for identity are definitely wider than people and organization.

So, the idea of the Identity-Aware Network is pretty important from my perspective.  Enterprise organizations will determine whether the cost/benefit is compelling enough, but my sense is that once customers fully understand the value it will quickly make its way up the priorities list on more than a few whiteboards.