DarkReading has a good article on the overarching challenges facing security administrators today (bonus alert: it has an I Love Lucy reference!), including mentions of recently "revealed" vectors around both clickjacking and Cross-site Request Forgery attacks. I quote revealed since, even though the Princeton researcher's work on CSRF is well documented, we'll have to wait until the Hack in a Box conference to get the full scoop. The downside of this is that it sure sounds and smells a lot like the Kaminsky thing, and I'm not sure even he would do it that way again. The upside is that it's a chance/excuse to go to Kuala Lampur, which is a beautiful city with amazing food (the latter being an obvious requirement for the former). But I digress.
It's easy to come away from the series of darkreading articles with a, well, dark impression of the state of endpoint secuirty these days. With continually morphing combinations of browser vulnerabilities, infected emails, user gullibility and malware-laden
websites, it's difficult to see how any security manager can keep his endpoints malware-free for any window of time. And all of this is made even worse by the fact that many of the new vulnerabilities aren't bugs per se, but rather dependencies on the very things that help make today's web cool. So, never mind, one might argue. We've failed and the cause of malware-free computing is lost.
But perhaps what we need is to change our thinking about what failure is (which is different than re-thinking what is is). Perhaps we've spent too much time so far putting our collective eggs in the basket of avoiding endpoint infection, when, really, at least some that attention is better spent on the idea of containing infections that are, in the end, inevitable. Put another way, it's not an engineering failure to have a router (or WAN card, or FRAD, or whatever) failure in the Bogota office. It is an engineering failure for that equipment failure to result in a services outage for the people in the Bogota office or anywhere else (I'm not intending to pick on Bogota, by the way. They have fine food too). We accepted long ago that what equipment does is fail. That acceptance didn't stop global data networking, obviously; it simply drove best practices around the notion of engineering for that failure.
My thinking of late, then, is that we've so far put too much attention on the single point of failure that is infection avoidance. That means (yes) having mechanisms in place to (a) detect the infection and (b) affect the network access of the endpoint in a timely way. But it also means things beyond just NAC, like the ability to clean/restore the system without having to put a help desk person on a plane. Not easy, perhaps, but it seems an answer that is at once more in keeping with the traditions of IT, and, well, more hopeful.
Comments