Research

Rich here, Holy crap, what a year! I have been in the security business for a while now. I wouldn’t say I am necessarily jaded, but… yeah. Wow. First, the news. This was the year of Target and Sony. Symantec finally breaking up. All sorts of wacky M&A. The year family members checked in for the first time in decades, after reading my quotes in articles with “celebrity nudes” in the headlines. Apple getting into payments. My guidance counselor totally left that out when we discussed infosec as a career option. Not that infosec was a career option in the late 80’s, but I digress. As I have often said, life doesn’t demarcate itself cleanly into 365 day cycles. There is no “year of X” because time is a continuum, and events have tendrils which extend long before and after any arbitrary block of time. That said, we will sure as hell remember 2014 as a year of breaches. Just like 2007/2008, for those who remember those ancient days. It was also a most excellent year for general security nonsense. Then there was the business side. 2014 was an epic year for Securosis on every possible level. And thanks to the IRS and our fiscal year being the calendar year, we really do get to attribute it to 2014. We cranked out a bunch of papers (mostly Mike) and engaged in some insanely fun projects (mostly me). A year or so ago I wasn’t sure there was enough of a market for me to focus so much of my research on cloud and DevOps. Now I wonder if there’s enough of me to support all the work. We were so busy we didn’t even get around to announcing a new research product: Securosis Project Accelerators. Focused workshops for end users and (for now) SaaS providers tied to specific project initiatives (like our Cloud Security for SaaS Providers package). On the upside, we sold a bunch of them anyway. The main thing that suffered was this blog. We mostly kept up with our scheduled posts and open research, but did drop a lot of the random posts and commentary because we were all so busy. I wish I could say that’s going to change, but the truth is 2015 looks to be even busier. Personally this has been my favorite work year yet, due to the amount of primary research I have been able to focus on (including getting back to programming), working more with end-user organizations on projects, and even getting to advise some brand-name cloud providers on technical aspects of their security. I am not sure whether I mentioned it on the site, but my wife stopped working after RSA due to an acute onset of “too many children”. We decided it was no longer worthwhile for both of us to work full time. And changes in the healthcare system meant we were no longer so reliant on her employee benefits. That reduced a lot of home scheduling stress, but also meant I was short on excuses to stay off airplanes. I was definitely away from home a lot more than I liked, but when I am home, I get to be far more engaged than a lot of parents. On the non-work front it was also an awesome year. We are done with babies (but not diapers), which means we are slowly clawing back some semblance of a life outside being parents. Our older two started in public school, which is like some kind of fantasy after years of paying a prison company to keep our children mostly alive and intact (daycare… shudder). We spent a month in Boulder, a week in Amsterdam, and a weekend in Legoland. I am running as fast as I was in my 20’s, over longer distances, and I am almost not embarrassed on the bike. (Remember, triathlon is latin for “sucks at three sports”). So on the overall good/bad scale I would mark 2014 as “awesome”. Mostly because I don’t work for a retailer or a film studio. And, without going into details, 2015 has some serious potential for epic. As I like to do every year before we close down for the holidays, I would really like to thank all of you for supporting us. Seriously, we are 3 guys and a half-dozen friends with a blog, some papers, and a propensity to sit in front of webcams with our clothes on. Not that many people get to make a living like this, and we can only pull it off due to the tremendous support you have all given us for over 7 years. I may not be religious but I sure am thankful. On to the Summary (our last this year): Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in the Guardian on the Sony breach Favorite Securosis Posts Mike Rothman: Firestarter: Predicting the Past. I can only hope you had half as much fun watching as we had recording the year-end FS. That’s right vendors – think twice before making those predictions. Even if you’re our friends, we will still call you out! Rich: Ditto. Natch. Other Securosis Posts Security Best Practices for Amazon Web Services: Third Party Tools. Security Best Practices for Amazon Web Services: Built-In Features. Security and Privacy on the Encrypted Network: Selection Criteria and Deployment. Firestarter: Predicting the Past. Summary: Nantucket. Favorite Outside Posts Adrian Lane: Analyzing Ponemon Cost of Data Breach. Jay Jacobs does an excellent job analyzing Ponemon’s breach cost calculation model. And I even learned a new word: heteroskedasticity. Mike Rothman: Analyzing Ponemon Cost of Data Breach. Don’t screw with Jay Jacobs on data stuff. Just don’t do it. This is a gem: “And in this analysis I will not only show that the approach used by Ponemon is not just overly simple, but also misleading and even may be harmful to organizations using the Ponemon research in their risk analyses.” Damn. Jay wins. Rich: I suppose I should choose something else.

Our Use Cases post ran through setting policies for decryption, and specific use cases driving decryption of network traffic. We also brought up human resources and compliance considerations when building policies. But that doesn’t address the technical nuances of actually figuring out where to decrypt, or how to select and deploy the technology, so here we go. First let’s talk a bit about whether you need a standalone device. Standalone or Integrated? Many network and security devices can terminate and decrypt network sessions – including firewalls, IPS, load balancers, UTM, and web & email security gateways. Obviously using an existing device is simpler, often the path of least resistance for decryption and inspection. You don’t have to add other boxes or risk messing up your network addressing scheme, and you can enforce policies right at the point of decryption/inspection. A security device can decrypt traffic, inspect it, apply policy, and re-encrypt – all within a single product. For environments with minimal network volumes and simple policies, integrated devices work well. But those who need to decrypt substantial network traffic tend to quickly crush the performance of existing security devices if they try to decrypt on existing devices. As we mentioned in our last post, onboard decryption may reduce performance of security devices by 33% to 80%. If you have plenty of performance headroom on your security devices that’s OK. If you don’t you need to look at another device to offload decryption load, in order to let your security devices do what they do best: inspect traffic, apply policies, and monitor or capture traffic. If you deploy complicated policies, such as multiple policy triggers across the entire network stream rather than limiting yourself to port 443 (HTTPS), an integrated device’s relatively simple decryption policies may be insufficient. Additionally, if you need to send decrypted traffic to multiple places, such as a SIEM or network packet capture device, an integrated solution may not be a good fit. We have nothing against the integrated option, but pragmatism and drives us toward the right tool for the job. If onboard decryption can meet your performance and policy requirements, do it. But if not you likely need a standalone decryption device. Selection Criteria Once you have decided to use a dedicated decryption device, what should you look for? Here are a few things to think about: Performance: Much of the value of dedicated hardware is its ability scale up with traffic volume. Make sure any device or devices you buy can scale to your current and future volumes. Don’t paint yourself into a corner by buying equipment that will need to be replaced when traffic volume grows. All Port Support: One of the easiest evasion techniques for attackers is to simply change the port number of their outbound traffic, sending encrypted traffic where it is not expected or monitored. Inspection devices cannot afford to trust port numbers – you need deep packet inspection looking at payloads to detect evasion. Accuracy: Decryption strategy is highly policy dependent, so success requires accurate categorization of traffic. Related to looking at the full traffic stream, you need to ensure your devices accurately find encrypted traffic and categorize it effectively. Policy actions: Once you have a policy hit, make sure your device supports a variety of different actions. You should be able to decrypt, not decrypt, drop the session, or reject the session (with a website failure code). You also want the ability to list sources or destinations as always decrypt (blacklist) or never decrypt (whitelist), by group or user. Website category/reputation support: A big chunk of our use case post talked about setting policies; they may include websites, IP addresses, and applications. Given how quickly website reputation and categories change (minutes – if not seconds), it is important to have a dynamic source of current information to base policies on. That usually means some kind of cloud-based website categorization service for whitelisting, along with dynamic reputation scoring for websites and applications. Multiple device support: Given the varied decryption use cases, these devices should be flexible in how they forward traffic, and to how many devices. For example you might want to send traffic to both an IPS for active control, and also a packet capture device for monitoring and forensics. It is also important for decryption devices to interoperates natively with security devices, so that (for instance) an IPS which detects decrypted attack traffic can drop that session without human intervention. Security: This is a security device, so you will want to ensure that decryption/resigning keys and data on the device are protected. You also want the ability to reject/drop sessions if their security is insufficient. For example a weak encryption cipher could data at risk; it might be forbidden to transmit encrypted data which cannot be decrypted by the security device, to prevent unknown data from leaving your environment. Transparency: It is also important to ensure decryption doesn’t impact application behavior or user interaction. End users should not need to concern themselves with security inspection. Further, the decryption device shouldn’t alter packet headers in any way, as that might impair other security devices’ inspection. Basically, nobody should know the device is there. Deployment flexibility: Decryption needs to be inserted into the flow of traffic, so you want a device that supports multiple deployment models, discussed below. For devices with multiple ports, you should have flexibility in assigning them to specific devices. You should also be able to apply policies both actively and passively. Deployment Decryption device deployment should be as non-disruptive as possible. You don’t want to mess around with IP addressing schemes, force every user to see a security warning every time they make an SSL connection, or have the device manipulate IP address headers and screw up your ability to monitor and analyze traffic. You want transparency, as mentioned above. Also make sure you are seeing all relevant traffic. Don’t make assumptions about what is relevant and what isn’t. Attackers frequently hide encrypted traffic on