Whatever Happened to Security For All?

Where have all your good words gone?
Where have all your stories gone?
From Where Have All Your Good Words Gone by Laura Gibson

Long, long ago, way back in December of 2011 the latest blog entry appeared in Security For All. What become of the author and his intrepid sidekicks Dr. Security and Captain X-Ploit has been the stuff of no small amount of speculation among the Information Security literati. Actually to my knowledge there has been no speculation at all. Small or otherwise. But I digress.

By way of excuses let me say that a whole bunch of stuff has happened since that last post around Christmas time. Primarily, in January I started  a new position as Software Architect for Trustwave. I could let you guess at my employer like I did back when I first started blogging while working at StillSecure, but anyone can look it up on LinkedIn so the thrill is gone. Also let me point out that Trustwave and Spiderlabs are quite well known in the blogosphere having several excellent corporate blogs. This is not one of them. Whatever I say here is strictly me and they have nothing to with it. Much less approve or disapprove. In any case I’ve been drinking from the firehose since January without much opportunity to do much of anything else.  Thus the reason for the 3 month hiatus of Security For All.

But I’m back. And so is the good Captain. So stay tuned.

Of screen doors and submarines – locking down your iPhone

It’s about as useless as
A screen door on a submarine
Faith without works baby
It just ain’t happenin’
From Screen Door by Rich Mullins

In a recent post, to the extent that any post here is recent, I wrote about the threat to personal privacy – yea even freedom posed by smart phones. Actually the threat was not so much from the smart phones themselves but the potential of exploitation of them by law enforcement contrary to your best interests. The obvious answer to this problem, as every portable computer using reader of this blog surely knows, is to fully encrypt the device. Locking that bad boy down tight will blow those law enforcement fishing expeditions out of the water. But alas, this is not a realistic option with most smart phones. There are several notable exceptions to this including the RIM Blackberry, mentioned in the earlier post,  which can be configured to be secure and some Linux-based smart phones such as the Nokia N900 described in this comment to that post by reader Gino.

There actually is a solution for full phone (filesystem) encryption: the Nokia N900, a Linux phone that supports Crypto LUKS. I know this for fact as I am typing this with one that has it :)

Albeit there is quite a bit of legwork needed and a fairly good bit of Linux knowledge required to set it up initially, it’s well worth the effort.

Unfortunately that excludes the many smart phone users, including myself, with iPhones. I did find some information in this article in Lifehacker entitled Common Sense Security for Your iPhone about locking down iPhones. To the extent that they can actually be “locked down”. Here are the high points.

Lock Your Phone
The most basic security precaution you can take is to make sure that your iPhone is using a passcode lock—and that the passcode lock will automatically engage after a brief period of inactivity.
Choose a Hard-to-Guess Passcode
On newer versions of iOS, you’ll have an additional option in the Passcode Lock settings labeled “Simple Passcode”. By default, “Simple Passcode” is on—and it essentially means that your passcode will need to be a 4 digit number that you’ll type when unlocking the phone. You can, and should, turn this setting off and enter a passcode that is more difficult to guess than the simple 4 digit pin.
Limit the Maximum Number of Unlock Attempts
To prevent someone from trying to break in to your phone if it’s stolen, take advantage of the setting at the bottom of the “Passcode Lock” settings page, labeled “Erase Data”. By default, this is set to off. Turning it on tells the iPhone to completely wipe the content of the device if 10 failed attempts to unlock the iPhone are recorded.
Take Advantage of the Free “Find My iPhone” App and Remote Data Wipe
Apple provides a great service called “Find My iPhone” that is available for free to any iOS device owner using their Apple ID (the same email address and password you use to purchase apps in the App Store). Complete instructions for setting up Find My iPhone are available on Apple’s Web Site. By default, the free Find My iPhone is only for 2010+ devices, but anyone can enable and use Find My iPhone on the 3GS and other pre-2010 devices. Here’s how.

While these are certainly valuable steps to take towards basic iPhone privacy, the efficacy vis-a-vis keeping out determined and well equipped snoopers is akin to locking the screen door on a submarine. This article by the oft-quoted [in this blog] Sharon Nelson of {ride the lightning} for the American Bar Association’s Law Practice Magazine entitled Why Lawyers Shouldn’t Use The IPhone: A Security Nightmare explains thusly.

The words iPhone and security do not belong in the same sentence, although you would never know it from the Apple marketing blitz. Some of the advertised features of the iPhone 3GS are the inclusion of encryption and remote wipe functions. As most folks know, encryption is a killer for computer forensic examiners and a fine way to protect your data. So what does encryption do for the 3GS? Not a heck of a lot. From my foxhole, it appears that encryption was an afterthought and not inherent in the iPhone design.

Jonathan Zdziarski has demonstrated how easy it is to gain access to a supposedly secure iPhone 3GS. Should we believe him? I certainly do, especially since I own his book on iPhone forensics and have personally seen the mountains and mountains of electronic evidence that is stored on an iPhone. The key to gaining access to the data is to extract a disk image from the device. First off you “jailbreak” the phone by placing it into recovery mode and installing a custom RAM disk to the iPhone. Jonathan mentions that the tools are only available to law enforcement (nice thought, but not so), but also acknowledges that it is fairly simple to develop your own. Several products like Red Sn0w and Purple Ra1n are freely available to “jailbreak” the phone. You then install a Secure Shell (SSH) client to port the raw disk image onto your computer.

Those of us in the forensic community know that sucking a disk image from an encrypted drive to a destination drive just gets you another encrypted image which is no earthly good to you. What makes the iPhone 3GS any different? This is the part where Apple is so very, very helpful. Even though the data on the iPhone disk is stored in an encrypted form, the iPhone actually decrypts the data as it feeds the zeros and ones through the SSH connection.

In order to secure your iPhone, make sure you configure an unlock code. Then again, perhaps you shouldn’t waste your time. Jonathan has another demo where he replaces the passcode file with one that contains a blank password, effectively removing the unlock code. How is this possible? Just like the previous explanation, putting the iPhone into recovery mode doesn’t require the passcode PIN.

Apple says losing your phone is not a problem, you just use the remote wipe feature to “kill” all of the personal data. There’s a problem with that too. The remote wipe feature requires that the iPhone be connected to the cellular network and removing the SIM card or placing the phone in a Faraday box would solve the network connection problem. Take the phone off the cellular network and you can take all day to retrieve the disk image (in an unencrypted form) from the iPhone.

Yep. Screen door on a submarine. In a follow up entry on {ride the lightning} Sharon finds even more reasons to declare “iPhone security” an oxymoron.

Most users are not aware that the iPhone conveniently creates a screenshot and saves it as a temporary file on the phone. Wired has an article that explains the how and why and is available at http://www.wired.com/gadgetlab/2008/09/hacker-says-sec/. The end result is that there is a very complete “audit trail” of activity that is done on an iPhone, even if the user doesn’t save any data. As an example, you can open a message that contains personally identifiable information and then immediately delete it. Guess what? All of that private data is on the phone until it is overwritten, which could be some time. As we mentioned in the article, the iPhone is an “evidence rich” device. These recoverable screenshots are one reason why and we’ve verified the existence of them through a ton of real world investigations. We’ve never seen this type of activity on any other phone.

Does all of this mean that the iPhone is the ONLY insecure cellular phone on the market? Obviously not, but it is at the top of our list, especially considering the hundreds of phones we get each year for evidence analysis. Any smartphone with a browser is subject to the same attacks and infection as any Internet user. We know many iPhone users are saying that security is the issue and is not unique to the iPhone. Perhaps the truth hurts. Security is a major issue for any law firm, but using a device that does not enforce PIN integrity is a little crazy in my book. I wouldn’t want to make that argument to a malpractice carrier.

Well so much for the delusions of privacy and security on the iPhone. I guess now we’re back to putting it in a bag in the trunk when we travel. At least in California. Or switching to Blackberry or N900 if we’re lawyers.

The dark side of post startup innovation

Todd at the Napera blog has two great articles here and here about how most of the innovation in network security comes from startups.

Breakthrough products like security appliances and virtualization were not pioneered by established industry behemoths, but originated with smaller companies willing to pioneer new product ideas and disrupt the status quo.

Startups are clearly much more agile than “established industry behemoths” and most of their mid sized brethren. The passion, drive and commitment of the small team offsets the capital, expertise and experience of the larger, older outfits.

startups spend an order of magnitude more time talking to customers and thinking about the challenges customers face. Ideally, interacting with and thinking about customers should happen at every level of a company. To add to that focus, a product team in a startup has a lot more autonomy in making product decisions.

Having worked across the entire spectrum in my career as a software engineer – from a small “mom and pop” DoD contractor (literally: Mom was the Controller and Pop was the CTO) all the way to a Fortune 50 computer manufacturer (truly one of those “established industry behemoths”) – I have definitely seen this in action. In a small startup everyone is intimately familiar with the customers, whereas large corporations have to make concerted efforts to allow a design engineer to even have marginal contact with a customer – and that’s usually second hand through either a sales or marketing initiative.

So being a startup is swell and you can innovate the pants off the big boys. The force is strong with startups. But there is a dark side. You didn’t really expect anything else now did you?

The conundrum which is faced by all startups (who don’t get snatched up immediately post initial product release by one of those big fish) is how to get new customers and still keep existing customers happy by providing a stable value added upgrade path. It’s really hard to innovate out of this one. But you have to in order to make that next step from being a startup to being an established concern that is in it for the long haul. From some things I’ve witnessed on the engineering side where this innovation actually happens, I present this cautionary tale.

Startup creates first product – brilliant idea, incredibly fast time to market. The chief engineer is now the CTO, but spends a fair amount of time addressing customer concerns (i.e. putting out fires). As a result the CTO is well loved and well rewarded by customers and executive staff alike. So now it’s time for the next big release of the product. The CTO has very precise ideas about what new features are important and what failings must be addressed. In fact the CTO knows that the largest customer is poised for a huge purchase when that killer feature is added. Unfortunately the CTO is way too busy and valuable an asset to the business to focus on the mundane tasks of development any longer so developers are hired to get the next version and next product out to the breathlessly waiting customers and potential customers.

So lets pause here and take stock of the new developers’ situation. They have to update an existing code base which has been field patched (remember those firefighting drills) with a technical lead (our CTO) who doesn’t have time to spend mentoring anyone. And they have to do it quickly. The CEO recalls that the first release came after 6 months and the following 2 releases came on 3 month cycles. Now granted the CEO knows that the now-CTO is a bona fide savant, a true code ninja, but surely these new mere mortal programmers can get the next rev out in 6 months. 9 months tops. Besides they’ve promised customers and there are some big deals riding on this next release. So the show must go on.

Fast forward 9 months and the vaunted next release is dangerously close to slipping the release date. The executive staff is not too worried as they recall the 160 hour weeks that the now-CTO put in to get the product out. So the pep-talks begin to motivate the new programmers to “take one for the team” and get this release done on time no matter what.

We’ll stop this tale here. The aforementioned allegorical startup can still make a happy ending, but not without recognizing the realities of the dark side.

  1. Brilliant innovative engineers are rare. The dark side of being brilliant is that they rarely value mundane necessities like documentation. They know the code inside and out, so from their point of view it’s self-documenting.
  2. Competent engineers are not so rare. They are also not so expensive. Or fast. They need mundane stuff like documentation to accomplish their job.
  3. The ramp up time it takes to come up to speed on a new product such that you can enhance and maintain it always takes at least twice as many engineering hours as it took to develop it in the first place. Don’t believe me? No problem, you can find out on your own.
  4. All engineers come to the realization (usually sooner rather than later) that firefighters get rewarded. So they look for fires to put out rather than doing the critical but boring and largely unnoticed jobs like configuration management or refactoring for maintainability.
  5. Executive management is always willing to oblige firefighters. They like it when the customer’s problem is solved quickly. That’s in the job description.
  6. The original founding members of the startup usually have an equity position in the company. So they know that at least the potential is there to be very well rewarded if the company is successful. So they are willing to work insane hours and make huge sacrifices for the company because of the potential rewards. Later members are employees or contractors with no real equity stake in the company. When they work insane hours and make huge sacrifices they get to keep their jobs. And have a party. Until they burn out.
  7. Customers who have your product expect to get new features before they are willing to pony up for the next version. They also expect a smooth and painless upgrade path – even when they decide to skip 3 or 4 releases. This is probably the most difficult part of software development. And one that most of us don’t consider until it steps up to brazenly bite our backsides.
  8. Customers really want the features they want. For them. Not for the entire customer base or potential markets. For them. And they are happy to drive your product strategy – where they want it to go.

Can a startup successfully address these dark side issues? Absolutely. To be successful you have to. Will you fall victim to most of these at least once? Of course. I’ve never heard of any company that survived the transition to post-startup unscathed. But the one edge that a startup can never afford to relinquish is that customer focus that Todd describes in his articles.

May the force be with you.

Sarah Palin and the great Yahoo! angst

I’ve really been trying to stay out of this one. I really have. Mostly because everyone, and I do mean everyone, has this story covered. While mainstream media, in stories like this, were concentrating on where to place blame, whether nasty sites like wikileaks are legal (while dutifully linking the prurient details) and whether Ms. Palin was a victim or villian (how about just clueless), the Security Bloggers Network, yea the entire blogoshere, has been alight with posts about what we can learn from this incident and how to make sure this doesn’t happen to you. Kindred spirit Alan Shimel even weighs in with words of advice and consolation for Ms. Palin.

So what’s the most important takeaway from this ugly, yet amusing, incident? That Yahoo!’s email security policies suck? I’m guessing that Alan would answer that with a resounding “yes! (albeit more emphatically and certainly more colorfully). Or is it that all web-based email services’ security sucks? Or maybe that there is a vast left-wing conspiracy to discredit our lovely GOP VP wannabee? (Oh! – I like that one).

Not to minimize or criticize the excellent analysis and advice proffered by fellow security bloggers, I think the most important takeaway was this:

Security is about managing risk. First you identify the assets that are exposed, then determine the threats that those assets will be exposed to, and finally determine how best to to manage that risk. This was yet another, albeit high profile, case of poorly managed risk.

Does Yahoo!’s mail security, particularly their password reset mechanism, introduce threats? Of course. Same with Google Mail or Hotmail. Can these threats be mitigated? Of course. Is it safe for me to use webmail? Ah, now we get to the question, however obliquely, that we should have asked first. So lets start at the beginning shall we?

  1. What is the benefit received from a web-based email/calendar/contacts system?
  2. What are the information assets that would be exposed?
  3. What are the threats to those assets?
  4. How can those threats be mitigated?
  5. Given the value of the exposed assets, can the threats be mitigated sufficiently such that the risk can be accepted?
  6. Do the benefits outweigh the cost in money and risk?

So if I’m me (which I was last time I checked) I would get a great deal of benefit from an online system like Yahoo! (disclaimer: I don’t actually use Yahoo!, I use something else), since I like to be connected everywhere and I make a point of keeping my work and personal stuff well separated.

In my case, the information assets that are exposed by my webmail are intentionally minimal. No important numbers or addresses and minimal Personally Identifiable Information.

The major threat to my assets is exposure due to data breach, with the most likely vector being a compromised password.

I’ve already written a blog entry about password security and I also use some of the stuff outlined here.

The value of my exposed information assets is pathetically low – my family weekend plans or my personal address list are, sadly, valuable only to me. So any common sense mitigation I can put in place will definitely make the effort required to compromise my data a very poor investment indeed.

Therefore, the convenience of having my todo list available on my iPhone far outweighs the risk of that data being exposed.

But then I’m not the Governor of Alaska and a vice presidential candidate. Ms. Palin should have gotten to #2 and started hearing all kinds of alarms going off. Barring that (hey, she only recently became a celebrity – er… high profile person) the answer to #5 is “no!” (actually “HELL, NO!“). Particularly since the data identified in #2 was not hers to risk – some of it belonged to the people of the sovereign state of Alaska. I can safely say that were I to expose my employer’s data via a personal online account, no matter what precautions I took and regardless if it were actually compromised, I would be fired. Immediately. Walked right out the door. And rightly so.

I’m pretty sure I wouldn’t get promoted to Vice President.

Nice stuff from DHS for your FDPP

In recent days the U.S. Department of Homeland Security (DHS) has been getting spanked pretty hard for being unprepared for cyberthreats. Since that mule has been pretty well beat to death, I’m not going to chime in on that. Instead, in the immortal words of the great philosopher sage Monty Python “And now for something completely different”.

I’d like you to know about something the DHS is doing right – the Ready Kids Campaign. From this press release on September 17:

Today the Department of Homeland Security’s Ready Kids Campaign announced with Sesame Workshop a new tool on emergency preparedness for parents of young children called “Let’s Get Ready!” This guide aims to get families planning together for emergencies through simple activities and games that focus on talking to young children about the people, places and things that will keep the family safe during an emergency.

“Emergencies can happen at any time with little or no warning and, as we’ve seen with recent natural disasters, personal and family preparedness are critically important,” said Erin Streeter, Director of the Ready Campaign. “‘Let’s Get Ready!’ gives parents the tools they need to talk to their young children in a very kid-friendly and non-threatening way and instill in them important information to help them deal with the unexpected.”

Specifically, the guide offers tips from Sesame Street’s and Rosita on how families can prepare their children for an emergency in age-appropriate ways such as:

  • Everyone, including young children, can play a role in planning for the unexpected.
  • Creating an emergency kit and plan that the entire family practices and shares is important.
  • Helping children learn personal information such as a phone number, their full names and the full names of their parents or caregivers, is helpful in case of any emergency.

If you have children you should definitely take advantage of this excellent resource. This is something that every family needs to consider seriously. Just like every business should have a Disaster Recovery Plan (DRP) and a Business Continuity Plan (BCP),  (I’ll bet you were wondering how I was going to relate this to security) you need to have a Family Disaster Preparedness Plan (FDPP). Except that your  FDPP is way more important than any DRP or BCP because this is your family, not some business that we’re talking about. It’s critical to note that no disaster plan (or any plan for that matter) has value if all of the players don’t know their parts. In the same way that it is critical for a business to make sure all employees, especially those in leadership roles, have and understand current copies of the DRP and BCP documents, all members of your family, must understand your FDPP. Furthermore, (and this is where many if not most businesses fall down) you must practice the plan. That’s right, it’s very well and good to have a plan that calls for tuning the weather radio to the correct station in case of a tornado warning, but it doesn’t work too well if you don’t know what station that is or where to find the radio.

So this is where you can really leverage the “Let’s Get Ready!” resources. It can help you devise, disseminate and practice your family’s FDPP. While this specific program is targeted at families with young children, there are links on this page to many excellent resources. I will admit that I learned a few things and picked up some ideas for my family’s FDPP. According to the site, this month, as part of Emergency Preparedness month, Sesame Workshop will be distributing 150,000 of the free kits to families. These kits include not only the downloadable materials on the site, but a DVD that is great for young kids.

So get going on your own FDPP, and definitely check out the resources at DHS. Seriously, they’re not just about fighting terrorism and cyberthreats. Which I guess is a good thing. Sorry couldn’t resist.

Information on “Let’s Get Ready!” is here. Materials are available in English and Spanish.

Losing our History

My wife and I spent the Independence Day weekend this year in Washington DC. In addition to watching the fireworks from the base of the Iwo Jima memorial we visited a number of other memorials and museums. But probably the most amazing place we visited was the National Archives. Aside from the U.S. Constitution and Declaration of Independence, the National Archives is in fact an archive of the U.S. government’s correspondent, business and legal transactions some of which are on exhibit. These exhibits include excerpts from the infamous Nixon Watergate tapes to (my person favorite) a letter from a 10-year-old Fidel Castro to President Franklin D. Roosevelt dated November 6, 1940, asking for a “ten dollar bill green American” (maybe Roosevelt should have sent him the 10 bucks – you never know). The fact is that the National Archive is a repository of everything the U.S. Government is involved in. Everything. The good, the bad, the ugly. The greatest achievements, the finest moments and the things we would like to forget. Especially the things we’d like to forget. This is everything from the most visible, substantial and important documents like the U.S. Constitution to mundane interoffice correspondence, which can in the long run be just as important historically.

You might think that the digital age has made the job of the National Archives quite a bit easier. Unfortunately nothing could be further from the truth as this article from the New York Times points out.

Countless federal records are being lost to posterity because federal employees, grappling with a staggering growth in electronic records, do not regularly preserve the documents they create on government computers, send by e-mail and post on the Web. Federal agencies have rushed to embrace the Internet and new information technology, but their record-keeping efforts lag far behind.

Moreover, federal investigators have found widespread violations of federal record-keeping requirements. Many federal officials admit to a haphazard approach to preserving e-mail and other electronic records of their work. Indeed, many say they are unsure what materials they are supposed to preserve.

This confusion is causing alarm among historians, archivists, librarians, Congressional investigators and watchdog groups that want to trace the decision-making process and hold federal officials accountable. With the imminent change in administrations, the concern about lost records has become more acute.

While those conspiracy theory fans among us (okay, I admit it – but the truth is out there) prefer a more tantalizing threat like a shadowy cabal that secretly removes and suppresses information embarrassing or threatening to their members, the reality is much more mundane – and insidious. And it’s a whole lot harder to address.

“The Achilles’ heel of record-keeping is people,” said Jason R. Baron, the director of litigation at the National Archives. “We used to have secretaries. Now each of us with a desktop computer is his or her own record-keeper. That creates some very difficult problems.”

That’s right – it’s those pesky end users. You know, those regular folks who are just trying to get their job done as efficiently as possible. Yeah, those people who we never have the time or budget to provide with decent hardware and software. And forget about education (no money for that in this year’s budget). Oh, and the folks who actually control the purse strings don’t have “keep a public record of the stupid things we do” at the top of their must-fund list. (Yes! I knew I could slide a conspiracy theory in there).

All this is really patriotic, and sufficiently alarmist to get some good hits on Google, but what does it have to do with security, Mr. Security For All?

Actually – everything. Remember the CIA triad: Confidentiality, Integrity and Availability. This issue is fundamental to both Integrity and Availability. From Wikipedia:

  • Integrity – In information security, integrity means that data cannot be modified without authorization. Integrity is violated when an employee (accidentally or with malicious intent) deletes important data files.
  • Availability – For any information system to serve its purpose, the information must be available when it is needed. This means that the computing systems used to store and process the information, the security controls used to protect it, and the communication channels used to access it must be functioning correctly.

I think we can all agree that not saving important information through neglect is the same thing as deleting important data. And when future generations – or a researcher today – can’t get access to an email that is germane to their research because it was never saved violates availability.

So how do we go about mitigating this threat? There is already a program in progress to bring the National Archives more fully into the 21st century, but it is not without it’s all too typical problems.

The National Archives is in the early stages of creating a permanent electronic record-keeping system, seeking help from the San Diego Supercomputer Center at the University of California, and from some of the nation’s best computer scientists.

The electronic archive is behind schedule and over budget. But officials say they hope that the project, being developed with Lockheed Martin, will be able to take in huge quantities of White House records when President Bush leaves office in January.

As a point of reference 32 million White House e-mail messages were preserved as records of the Clinton administration. The National Archives expects to receive hundreds of millions from the Bush White House. And since disputes over White House records have occurred at the end of the last three administrations, we can count on more litigation in January.

So here’s a bold idea: why not take the money that will be flushed down the litigation rat hole and put it towards the electronic record-keeping system? Oh, but wait, that would mean that politicians would have to be subject to the same laws, standards and directives that all government employees are. Or maybe Lockheed Martin could get some help from the IBM Almaden research guys on storing, indexing and accessing insane amounts of information since the Webfountain project went dark. Or underground. (Yes! another conspiracy theory reference).

In any case this is a risk that must be managed – and soon – before we lose what amounts to our civic cultural heritage.

NAC: answering the right questions

Let me start this off by setting a baseline. I know a lot about Network Access Control (NAC). A real lot. I  work on (as in design, develop and support) what is arguably the industry leading and undeniably the best NAC solution in the industry. I’ll let you guess, since I’m not a shill for my employer. Don’t get paid for it, don’t do it, don’t care. Just say no to marketing. In any case, I know a lot about NAC.

So I sign up for a videocast entitled “NAC: Answering the hard questions” which has this intriguing abstract (emphasis mine):

A recent survey showed that of the companies that already have NAC deployed, 36% said their networks became infected with malware anyway. Clearly, there are still plenty of questions about NAC that need to be addressed. In this video, Joel Snyder, one of the top NAC experts in the industry, will help viewers answer the most pressing questions surrounding this technology, including:

  • How do you handle lying endpoints?
  • How does NAC extend to branch offices?
  • How much does NAC’s effectiveness rely on the security of your network infrastructure?
  • And more

I’ve tried to find the source of this study because those afflicted 36% really need to check out my earlier posting “Security Ideas for your mom part 1”. Wherein I enumerate the most important ideas (in my humble opinion) that your mom needs to know about secure computing. Let me quote myself from idea #2:

“don’t use something you don’t understand.”

You see Network Access Control does not directly prevent your network from being infected by malware. What it does, when configured correctly, is verify the security posture of your network endpoints before allowing them access to your network. In other words, a good NAC system will check to see that a PC requesting access to your network has whatever Anti-Virus programs you require installed and that the engine and signatures are up to date, but it will not check to see if the endpoint is already infected with a virus or if the AV package itself is worthwhile. Furthermore, NAC systems have the facility to “white list” certain endpoints since it’s usually a career limiting move (CLM) to quarantine the CEO’s PC. But if your CEO likes to surf for porn on said PC, it might be a CLM, but it’s still not a bad idea for security. So the general statement you can make about NAC is that it will only validate and enforce compliance to your security policy. It will do nothing to make sure your policy doesn’t suck or that you haven’t swiss-cheesed it to allow unlimited access to clueless VIPs. So let me say this once and for all – NAC is not magic. It is not a silver bullet. It will only enforce your network access policies, regardless of how lame they are, and only then if you configure the system correctly.

So I watched the videocast. I’d actually recommend it. Dr. Joel Snyder is a very sharp guy even if he relies a bit heavily on vendor marketing. Since I couldn’t find a place to comment on the site that hosted the videocast (Bitpipe), I decided to comment here. Okay, I was planning on commenting here anyway.

How do you handle lying endpoints? Well, if you are one of the NAC products that Dr. Joel is familiar with, apparently rather badly. He references the Trusted Computing Group (TCG) Trusted Network Connect (TNC) architecture to point out that ultimately system health telemetry originates from sensors on the endpoint itself (Integrity Measurement Collectors (IMC) in TNC lingo). Yep, that’s a problem all right – with the TNC reference architecture. He correctly concludes that some other mechanism (e.g. TCG Trusted Platform Module (TPM)) must be utilized to assure the integrity of the client-based sensors. Okay, how about this idea instead: lets start by assuming that all endpoints are lying (or are capable of lying) and instead of relying on the endpoint to give us a statement of health, have our Policy Decision Point check for itself. There are NAC products (at least one) that do this today. And it works really well. And it can even be done without any kind of agent software installed on the endpoint. Is it magic? No – just really clever design (if I say so myself). Now there are clearly some advantages to the TNC take on this, most obvious is that the vendor of the endpoint security software you want to check for compliance is in the best position to know the health of their stuff and they can build their own IMCs. Problem is, when you have Vendor A’s AV and Vendor B’s firewall and Vendor C’s HIDS running on Vendor M’s platform you are trusting that these vendors will play nicely with each other. Even when they have competing products. You bet.

How much does NAC’s effectiveness rely on the security of your network infrastructure? Dr. Joel answers this one with an emphatic “a lot”. Thereby earning him the Security For All GOTO award for his outstanding Grasp Of The Obvious. Of course NAC’s effectiveness relies on the security of your network infrastructure – in fact, it is predicated on it. If your network infrastructure is not secure, NAC will certainly not make it so. In fact I would go so far as to say that slapping NAC into an insecure environment is no more than security theater – users see it and think they are more secure, while nothing (good) really happens securitywise. To be fair, Dr. Joel is mostly warning NAC implementers to be aware that in all likelihood you will have NAC enforcement at the edge of your network and that it does, in fact, become another attack surface. Of course, it was probably already an attack surface before NAC was added to the picture. The point is that if you are using old leaky routers and switches, or a bad network security architecture you should probably take care of that stuff before you even think about adding NAC into the mix.

Marketeer’s have done an outstanding job of overhyping NAC. The fact that Dr. Joel even has to make himself a candidate for the GOTO award (and my bothering to award it to him), is a testament to how successful NAC vendors have been at getting folks to breathe their exhaust. And it does everyone a disservice. NAC is not magic. There is no silver bullet. Period.