CTO Chronicles

Clickjacking, CSRF, Social Networking, Oh My

2008-10-07T11:12:47-07:00

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.

Hotel Hacks

2008-09-21T05:53:52-07:00

There's an interesting, if unsurprising, article up on darkreading about the security of hotel networks. I think we've all been to a hotel or two before that had, say, SNMP community strings that were easily guessable. In general, it seems that "Broadband" Inernet access at hotels has morphed from being an ammenity to simply being a given. However, it does not appear that most hotels take any real steps to manage that resource, or the people using it.

So, first, it seems from the study that hotels should look to technologies like Network Access Control to protect themsevles. Second, we should all be mindful of just how open these networks are when our users come back from them.

SCADA Exploit Released

2008-09-10T10:03:12-07:00

SC Magazine has an article up that a security researcher has "released" an exploit for the CitectSCADA vulnerability announced earlier this summer. I've written about the challenges around SCADA systems before, and we continue to monitor this space, so the article caught my attention.

I have little doubt that the original vulnerability was serious, and all indications are that it was taken seriously, if not by the press then at least by Citect and their customer base. This newly released "exploit" seems a bit over the top to me, as do a couple of quotes in the article. Here's an example:

"As a result of the need for real-time business information, it is becoming increasingly popular for the plant network to connect with enterprise networks and the open internet."

I don't know Brian Ahern, and far be it from me to say that companies, industrial or otherwise, shouldn't secure their networks. But is Mr. Ahern truly making the allegation that power companies are giving their industrial control systems unfettered access to the public Internet? Seems a bit of a stretch. The stretch gets even broader when a look at the code shows a high ephemeral port related to ODBC connectivity. Is there really any company that allows incoming connections on ephemeral ports to internal systems? Much less industrial control systems running SCADA applications? None of the utility guys that I've had the opportunity to meet does.

Given today's landscape, what seems a more likely vector is a bot or otherwise malware-infected host already inside the company's perimeter. Put another way, given that we're in an election year, "It's the Inside, stupid."

By all means, take this vulnerability seriously. By all means, leverage perimeter security devices (if you don't already) to protect critical infrastructure devices from the public Internet. But you should also secure your network from the inside out, not just from the outside in.

The Anti-Social Network

2008-09-05T10:35:45-07:00

DarkReading has an interesting article up on a proof-of-concept attack leveraging social networking sites (FaceBook in this case). I've written about this recently; and we've seen an uptick recently in the field of infections that were ultimately traced back to social networking sites. I continue to believe that attacks centered around social networking will continue to grow. Be careful out there; practice safe browsing whenever possible; and remember that it's all about the layers.

Knock Knock

2008-08-26T08:30:00-07:00

What's there?

We recently commissioned a survey of IT staff on network security concerns generally and NAC adoption plans specifically. What we found, interestingly enough, was that 86% of the respondents had controlling network access as a priority, but 45% of them were not sure what was connecting to their networks at any given time. I feel a bit like a political spin machine on this, since the basic visibility components of NAC implementation has often been a topic for me, but it seems to just keep coming up in its own right. 802.1x can help authenticate the endpoints in your network (and that seems to be on peoples' list, at least according to Gartner), and may help judge the posture of devices as we move forward. However, failing back to MAC based authentication for MAC addresses you know little to nothing about seems too circular to be useful. Any meaningful policy springs from at least basic knowledge of what you have connecting today.

I think this is a particular challenge for NAC vendors, since (a) it's basic blocking-and-tackling of NAC implementation so it needs to work; and (b) it's not really a huge business bang for your NAC buck. However, there has to be opportunity here as well, since it appears none of the current tools in the IT toolbox is stepping up to do a satisfactory job at this.

You can read the full study here.

Another Patent Born

2008-08-13T08:28:14-07:00

Actually, birthing. We've received a notice of allowance from the USPTO for our patent application around address resolution based restriction of devices post-admission to the network. Ironically or no, this was pretty much the first patent the company filed; yet it remains extremely relevant. I've written recently on the importance of post-admission controls, as well as the reasons and (some of the) methods of our ARP based approach to quarantine. Our initial patent protects ARP based quarantine for the purposes of enforcing authentication of devices onto the network. Once issued, this one will protect ARP based quarantine of devices as a result of threat detection at any time during the device's network lifecycle.

We're excited about this. Two down, 8 more to go.

SCADA and NAC

2008-08-12T17:55:07-07:00

I thought I would take somewhat of a break from beating the standards and post-admission drums, and share some thoughts on how companies might bring embedded OS devices (generically) and SCADA devices (specifically) under a NAC umbrella. The move away from serial communications and towards Ethernet and TCP/IP is not a new phenomenon for SCADA devices, nor are the security vulnerabilities and concerns that come as part of the move.

In May of this year, the GAO conducted an audit on the Tennessee Valley Authority, with less than stellar results. The North American Electric Reliability Council now has a set of ratified "Critical Infrastructure Protection" (CIP) standards designed to address these and other concerns. The CIP standards end up setting up roughly as one would expect: Identify critical assets, segment and protect them, control physical access, patch machines, manage security events, etc.

NAC should be able to help with at least some of those. Given the specialized function of these devices, though, as well as the specialized nature of their OS, care must be taken. To wit:

First Do No Harm

What's generally true about network security engineering is doubly true here. Any "security" apparatus that causes lights to go out, or a cooling plant to shut down, is quite obviously bad. In essence, this is a two-fold model change for NAC. First, it is a view that is geared more towards protecting the critical devices, as opposed to protecting the environment from them. Second (and somewhat related), access to the network is presumed as a normal case and restricted only in an extraordinary case.

Passive Device Fingerprinting

Some identification mechanism is necessary to fingerprint these devices and classify them correctly (see below). Given specialized OS platforms, though, performing that fingerprint via agent software seems unworkable.

On-Segment Protection

The segment containing these devices must be protected from all threats, foreign and domestic: malware-infected hosts, mal-intentioned users, mis-informed users, unauthorized hosts, etc. Of course, this includes ongoing protection of the segment, not just protection from device entry.

MAC-Based Authentication for 802.1x

At some point, organizations likely want to meld this under an overarching 802.1x umbrella. Given the likely lack of 802.1x supplicants for these devices, MAC based authentication is required. This is also where the fingerprinting piece comes in to plug the holes inherent in MAC based network admittance.

Generically, of course, this governance problem is applicable to any number of other devices (medical, HVAC, badge readers, etc.) that now have Ethernet connections and IP addresses. The set of Critical Infrastructure Protection standards for the utility industry just provides an additional driver for the IT and Security teams in that industry to do something (or a set of somethings). It is both a challenge and opportunity for NAC vendors to find a way to help, but help in a way that takes into account the specialized nature of these devices.

Malware Survey

2008-08-06T15:39:26-07:00

Blackhat's underway, and while Kaminsky's DNS vulnerability continues to garner the lionshare of attention, there are other interesting malware-related developments that I thought would be worth surveying here. This is not an exhaustive list, of course. Just ones that caught my eye for one reason or another.

For all the Facebook/MySpace lovers out there, blackhat researchers are due to demonstrate a file that the web server treats as a Gif, but the endpoint processes as a jar archive. Kaspersky as also identified a worm that is spreading through MySpace and Facebook.

Storm continues to chug along and find ways to add people to its botnet. The latest is attempt is via an "FBI vs Facebook" spam. Given Storm's history of looking to capitalize on events around the world, I'd look for more as the Summer Olympics gear up.

In a development that surprises none of us, but is a bummer for all of us, Information Week has an article on a recent Websense survey that 75% of sites serving malicious code are legitimate sites that have been compromised. According to the article this is a 50% jump over the previous 6 months.

Finally, Twitter has apparently reached a level where it is now also worthy for use as an attack vector, prompting users to download malware disguised as an updated codec for Adobe Flash player.

What's any of this to do with NAC? It highlights two points that I've drummed on before: (1) the critical importance of a post-admission security and detection strategy, and (2) the importance of isolation and cleanup of infected hosts.

The NAC Unbeliever

2008-07-28T15:22:33-07:00

If you didn’t tune in for the NAC debate between Joel Snyder and Richard Stiennon you should check it out here. It was a good exchange but Snyder was clearly speaking from stronger ground. This was one of Stiennon’s comments in the debate (talking about NAC):

Richard_Stiennon: I agree that it is turning into a religion, which makes me an atheist.

I knew he hated apple pie. I knew it. Actually, that was just Richard being Richard, but even when discussing the real issues he seemed to be all over the place. Here’s my take on a couple of other nuggets of wisdom he shared in the NAC debate.

Stiennon's historically wrong:

Richard_Stiennon: “MSBlaster was essentially a zero day [exploit] for most enterprises. If they had had NAC fully deployed they still would have gotten hit.”

The CERT advisory on blaster was issued on August 11, 2003. The security bulletin and the patch were available on Microsoft's web site on July 16, 2003. Roughly 30 days. Nowhere near zero-day. Indeed this works against Stiennon's other argument about patch and software distribution management solving this problem long ago. SMS was ubiquitous three years prior to the Blaster outbreak.

Stiennon's philosophically wrong:

phreno: Richard, some NAC products offer behavioral policy enforcement. I can get identity, endpoint checks, and behavioral policy enforcement that stops botnets, DDoS attacks, etc. that do find a way onto the network. What other technology offers that?

Richard_Stiennon: “Great question. This is where the IPS/AV industry is heading. Allow an infected end point to connect, but do not allow it to harm me. Filter out attacks at the edge. The capability you refer to in some "NAC solutions" is what they call post admission control. That is good but the action should be to drop packets, not end point connections.”

13th chime of the clock. This statement, in itself, is just wrong-headed. The notion of blocking bad traffic but leaving an otherwise useful connection was folly 5 years ago. Much less today with, as Richard alludes to earlier in the debate, threats that blend SPAM, bot, keystroke logging and the like. And we haven't even scratched the surface of malicious users. What possible good comes from continuing to grant network access to a malicious user? It is difficult for me to conceive of an answer that could be more wrong, more naive in its arrogance, than "just drop the bad stuff."

The ARP Lowdown

2008-07-24T15:04:32-07:00

Likely the single most controversial part of the Mirage NAC product involves its use of ARP. Stiennon referred to "ARP twiddling" as our means of quarantine during our recent, er, discussion on the usefulness of NAC. As tempting as it was to respond to the comment in the thread, I thought perhaps it was better to leave it for its own post. So, what's up with our use of ARP? Why do we do it this way and why haven't we moved more quickly to one of the more common means of quarantining endpoints? Here's the lowdown that before has been kept more on the down-low.

More than just quarantine.

One of the first discussions we (at least I) end up having with prospects surrounds the notion of device state. The knowledge of network entry and exit forms the bookends of the NAC process. Any NAC solution must have this basic notion in order to provide the necessary governance. To be sure, many options exist. Some solutions take alerts from the switching infrastructure (SNMP traps, Syslog messages, whatever) based upon either the link state of the port or the population of the bridging tables. Others may have a RADIUS hook, on the assumption that any device that's connecting is authenticating in one way or another. Still others may have a DHCP hook and use address assignment as the state trigger. Finally, some of the inline solutions simply wait to see traffic flow through them. There are three basic reasons we like ARP for this: First, and most importantly, it's immediate since it's part of the initial stack initialization. Second, it's independent of the switching infrastructure, in that it works the same way regardless of downstream switches, whether the switches can send traps, etc.) Third, it's independent of endpoint characteristics, such as OS type and whether the address is statically assigned or dynamically assigned.

But also quarantine

Yes, we use ARP for quarantine. The marketing side of the house prefers "ARP Management" to "ARP Poisoning" or "ARP Twiddling." I don't especially care. The best way to enumerate why we do it this way is to back up and review, at a slightly higher level, what we think quarantining should be and mean:

Quarantining should be fast

This almost seems like it could go without saying. Whether effected for the purposes of device-specific remediation or more generalized network protection, time is both money and risk. A quarantining method that takes, for example, seconds to put in place is, at least to us, a non-starter.

Quarantining should be holistic

One of the fundamental disagreements I have with Stiennon's notion of network security (rant alert) is that packet (as opposed to endpoint connection) dropping is sufficient as a mitigation method. With a threat blended into, say, a bot (with an https control channel), a file-sharing based worm, a keystroke logger that may be logging data but not sending it, and a spam relay, the very notion of separating "good" traffic from "bad" traffic is silly. Take even one of the highly outdated threats (and quaint, by today's standards) threats like Blaster and Welchia. The "bad traffic" in those cases was Windows networking traffic, whose primary usage was *inside* the infrastructure. So then a "good traffic/bad traffic" policy removes windows networking functions from the connection, which removes access to both file shares and (assuming Exchange) corporate email. Now then, how useful, really, is that endpoint's connection? Well, they can get their stock quotes. And they can get to internal portal-based applications. Boy, there's a great idea. "I see, Mr/Ms user that you're infected with malware; welcome to my Oracle Financials application." How does that idea pass muster with anyone?

Quarantining should be full-cycle

This may or may not be a point of debate, but we continue to believe that a quarantine mechanism that is only available at admission time is wholly inadequate. This is the "main" thing keeping us from leveraging 802.1x as a quarantine mechanism (the lack of this capability in 802.1x environments has been a rant of mine before, since the RFC that would allow for this is 5 years old). As much as I like the idea of enforcement at the point of access, I simply do not see how it's workable unless and until it's possible to revoke previously granted access based on policy.

Quarantining should be transparent

I put this last since I think it's one with the largest amount of wiggle room. The thing I always liked the least about SNMP and CLI based VLAN moving is that there remains the need to get the endpoint to go request a new address as a result of the VLAN change. Similarly, the best that DHCP can offer is to play around with the timing elements, but that's not the same as the ability to do quarantine on-demand per policy. Not to beat a dead horse or anything, but RFC 3576 would get us there if the switch vendors would just implement it. Did I mention that the RFC is 5 years old?

So, there you have it. We use ARP for state because it's fast, robust and hard to bypass. We use ARP for quarantine because, quite frankly, we've yet to see any other quarantine mechanism that can fit the bill.

I almost forgot. The main knock against our "ARP twiddling" approach, beyond just the philosophical objection, is that it's easy to bypass. Is it? Some methods may be. Ours is not. Not from our own internal testing, and not from installations spanning 550 customers across 38 countries. And, yes, we thought of the static cache-entry trick already.