Can you have too much security?

Where organizations rely on application-aware security policies for their network security devices, or rely on Data Loss Prevention (DLP) products to prevent leakage of sensitive corporate material outside the network perimeter, the use of encrypted traffic means that those devices are suddenly blinded to the content, rendering deep packet inspection to the application level impossible. Cybercriminals are aware of this, and often make use of encrypted channels for covert command and control communications for botnets, as well as data exfiltration from the corporate network.

Given the risk that encrypted channels may be used by malicious entities for botnet command and control or data exfiltration mechanisms, enterprises are faced with an unpalatable choice – leave traffic in the clear or lose visibility into the encrypted data stream. Of course, there are solutions to the problem – there always are! – such as ensuring that network monitoring and security products can handle decryption, inspection and re-encryption of traffic on the fly.

The only issue is, how much of your already straining-at-the-seams security budget can you allocate to add SSL inspection capabilities to your infrastructure?

And while this may seem the obvious solution, on-the-fly SSL inspection can have a number of issues that need to be considered, not least of which privacy and performance. Vendor data sheets usually do not reflect accurately real-world impact on performance, forcing organizations to perform their own testing to ensure network security devices are fit for their intended purpose.

NSS Labs has a group test report in the pipeline covering SSL inspection capabilities of network security devices, and in the mean time, we have published a useful piece of research on What CIOs Need to Know About SSL and its Effect on Network Traffic Inspection Capabilities (subscription required).

Follow me on Twitter (@bwalder) to keep informed as new research is released.

Firesheep: Should CISOs Ban Employees From Using Unsecured Public Wireless Networks?

The release of the Firesheep plug-in for the Firefox browser has made it trivial for even unskilled attackers to intercept and interfere with private data on unsecured public wireless networks.

Since attackers can use the tool to send messages and make posts on behalf of the victim, organizations using social networks for marketing, support or brand enhancement may suffer serious consequences as a result.

Chief information security officers (CISOs) need to make employees aware of the risks and provide them with the necessary tools to counter them, but should they be banning the use of unsecured wireless networks for any company-related communications?

This note (for subscribers only), entitled "What CIOs need to know about SSL and its effect on network traffic inspection capabilities" answers that question and provides action plans for both employees and software developers to combat the threat of session hijacking, in addition to covering how IT departments can balance the need for enhanced security with the need to inspect encrypted traffic on the corporate network.

Don't forget to follow me on Twitter (@bwalder) to be kept informed of new research.

Like Lambs To The Slaughter - What Is Firesheep?

As with Advanced Evasion Techniques (AET), Firesheep has garnered significant publicity recently by rejuvenating interest in an old security problem via the creation of a slick new tool. Unlike AETs, however, the tool at the centre of this publicity storm has been released to the general public, for good or ill.

HTTP session hijacking, or "Sidejacking" as it is sometimes called, is nothing new. Papers exist discussing the technique as far back as 2004. Several applications have also been written in the past (Ferret, Hamster, Cookie Monster and FBcontroller to name a few) to take advantage of the technique. However, Eric Butler, a Seattle-based freelance software developer, has rekindled interest in the issue via the release of a simple-to-use Firefox plugin called Firesheep.

Either on its own on a Mac, or coupled with Winpcap (or Ettercap) on a PC, Firesheep can capture traffic on any unsecured wireless network to which you are connected and extract details from session cookies used by any of the web sites configured within the Firesheep application. These cookies are used by web applications such as Twitter or Facebook to register the fact that you have successfully authenticated to the host site. They do not contain your password details, but they do not need to. By using the cookie to piggyback on your unencrypted communication, the attacker running Firesheep can impersonate you and gain access to the application you are using.

It couldn't be easier to use. The attacker just fires it up, turns on packet capture, and waits for the sidebar to populate with account details it has detected on the network. He clicks on your details, and hey presto - he sees on his screen exactly what that you see on yours. And he can interact directly with the host application. He could post status updates on Twitter or Facebook on your behalf, for example. OK, that might not be too serious for some, but for those whose job it is to represent the public face of a major corporation then the potential for mischief is significant.

Should you stop using all public, unsecured wireless networks? Well, no. That would be overkill.

At the end of the day, the real solution is for providers of web applications like Facebook and Twitter to use secure connections for all their operations. In the mean time, there are a number of precautions you could, and should, take, and these (and other key points) are the subject of a research note I have just completed (subscribers only).

Don't forget to follow me on Twitter (@bwalder) to be kept informed of new research. Just don't do it from an unsecured wireless network - you never know who might be watching!