Research

For a football fan, there is nothing like the New Year holiday. You get to shake your hangover with a full day of football. This year was even better because the New Year fell on a Sunday, so we had a full slate of Week 17 NFL games (including a huge win for the G-men over the despised Cowboys) and then a bunch of college bowl games on Monday the 2nd. Both of my favorite NFL teams (the Giants and Falcons) qualified for the playoffs, which is awesome. They play on Sunday afternoon. Which is not entirely awesome. This means the season will end for one of my teams on Sunday. Bummer. It also means the other will play on, giving me someone to root for in the Divisional round. Yup, that’s awesome again. Many of my friends ask who I will root for, and my answer is both. Or neither. All I can hope is for an exciting and well-played game. And that whoever wins has some momentum to go into the next round and pull an upset in Green Bay. The end of the football season also means that many front offices (NFL) and athletic departments figure it’s time to shake things up. If the teams haven’t met expectations, they make a head coaching change. Or swap out a few assistants. Or inform the front office they’ve been relieved of their duties. Which is a nice way of saying they get fired. Perhaps in the offseason blow up the roster, or search to fill a missing hole in the draft or via free agency, to get to the promised land. But here’s the deal – as with everything else, the head coach is usually a fall guy when things go south. It’s not like you can fire the owner (though many Redskins fans would love to do that). But it’s not really fair. There is so much out of the control of the head coach, like injuries. Jacksonville lost a dozen defensive backs to injury. St. Louis lost all their starting wide receivers throughout the year. Indy lost their hall of fame QB. And most likely the head coaches of all these teams will take the bullet. But I guess that’s why they make the big bucks. BTW, most NFL owners (and big college boosters) expect nothing less than a Super Bowl (or BCS) championship every year. And of course only two teams end each year happy. I’m all for striving for continuous improvement. Securosis had a good year in 2011. But we will take most of this week to figure out (as a team) how to do better in 2012. That may mean growth. It may mean leverage and/or efficiency. Fortunately I’m pretty sure no one is getting fired, but we still need to ask the questions and do the work because we can always improve. I’m also good with accountability. If something isn’t getting done, someone needs to accept responsibility and put a plan in place to fix it. Sometimes that does mean shaking things up. But remember that organizationally, shaking the tree doesn’t need to originate in the CEO’s office or in the boardroom. If something needs to be fixed, you can fix it. Agitate for change. What are you waiting for? I’m pretty sure no one starts the year with a resolution to do the same ineffective stuff (again) and strive for mediocrity. It’s the New Year, folks. Get to work. Make 2012 a great one. -Mike Photo credits: “drawing with jo (2 of 2)” originally uploaded by cuttlefish Heavy Research We’ve launched the latest Quant project digging deeply into Malware Analysis. Here are the posts so far: Introduction Process Map Draft 1 Confirm Infection Build Testbed Static Analysis Given its depth we will be posting it on the Project Quant blog. Check it out, or follow our Heavy Feed via RSS. Incite 4 U Baby steps: I have been writing and talking a lot more about cloud security automation recently (see the kick-ass cloud database security example and this article. What’s the bottom line? The migration to cloud computing brings new opportunities for automated security at scale that we have never seen before, allowing us to build new deployment and consumption models on existing platforms in very interesting ways. All cloud platforms live and die based on automation and APIs, allowing us to do things like automatically provision and adapt security controls on the fly. I sometimes call it “Programmatic Security.” But the major holdup today is our security products – few of which use or supply the necessary APIs. One example of a product moving this way is Nessus (based on this announcement post). Now you can load Nessus with your VMWare SOAP API certs and automatically enumerate some important pieces of your virtualized environment (like all deployed virtual machines). Pretty basic, but it’s a start. – RM Own It: It seems these two simple words might be the most frequently used phrase in my house. Any time the kids (or anyone else for that matter) mess something up – and the excuses, stories, and other obfuscations start flying – the Boss and I just blurt out own it. And 90% of the time they do. So I just loved to see our pal Adam own a mistake he made upgrading the New School blog. But he also dove into his mental archives and wrote a follow-up delving into an upgrade FAIL on one of his other web sites, which resulted in some pwnage. Through awstats of all things. Just goes to show that upgrading cleanly (and quickly) is important and hard, especially given the number of disparate packages running on a typical machine. But again, hats off to Adam for sharing and eating his own dog food – the entire blog is about how we don’t share enough information in the security business, and it hurts us. So learn from Adam’s situation, and share your own stories of pwnage. We won’t

We spent the first two posts in this series on the why (Introduction) and how (Detecting Today’s Malware) of detecting malware on the network. But that all assumes the network is the right place to detect malware. As Hollywood types tend to do, let’s divulge the answer at the beginning, in a transparent ploy. Drum roll please… You want to do malware detection everywhere you can. On the endpoints, at the content layer, and also on the network. It’s not an either/or decision. But of course each approach has strengths and weaknesses. Let’s dig into those pros and cons to give you enough information to figure out what mix of these options makes sense for you. If we recall the last post Detecting Today’s Malware, you have a malware profile of something bad. Now comes the fun part: you actually look for it, and perhaps even block it before it wreaks havoc in your environment. You also need to be sure you aren’t flagging things unnecessarily (the dreaded false positives), so care is required when you decide to actually block something. Let’s weigh the advantages and disadvantages of all the different places we can detect malware, and put together a plan to minimize the impact of malware attacks. Traditional Endpoint-centric Approaches If we jump in the time machine and go back to the beginning of Age of Computer Viruses (about 1991?), the main threat vector was ‘sneakernet’: viruses spreading via floppy disks. Then detection on actual endpoint made sense, as that’s where viruses replicated. That started an almost 20-year fiesta (for endpoint protection vendors, anyway), of anti-virus technologies becoming increasingly entrenched on endpoints, evolving three or four steps behind the attacks. After that consistent run, endpoint protection is widely considered ineffective. Does that mean it’s not worth doing anymore? Of course not, for a couple reasons. First and foremost, most organizations just can’t ditch their endpoint protection because it’s a mandated control in many regulatory hierarchies. Additionally, endpoints are not always connected to your network, so they can’t rely on protection from the mothership. So at minimum you still need some kind of endpoint protection on mobile devices. Of course network-based controls (just like all other controls) aren’t foolproof, so having another (even mostly ineffective) layer of protection generally doesn’t hurt. And keeping anything up to date on thousands of endpoints is a challenge, and you can’t afford to ignore those complexities. Finally, by the time your endpoint protection takes a crack at detection, the malware has already entered your network, which historically has not ended well. Obviously the earlier (and closer to the perimeter) you can stop malware, the better. Detecting malware is one thing, but how can you control it on endpoints? You have a couple options: Endpoint Protection Suite: Traditional AV (and anti-spyware and anti-everything-else). The reality is that most of these tools already use some kind of advanced heuristics, reputation matching, and cloud assistance to help them detect malware. But tests show these offerings still don’t catch enough, and even if the detection rate is 80% (which it probably isn’t) across your 10,000 endpoints, you would be spending 30-40 hours per day cleaning up infected endpoints. Browser Isolation: Running a protected browser logically isolated from the rest of the device basically puts the malware in a jail where it can’t hurt your legitimate applications and data. When malware executes you just reset the browser without impacting the base OS or device. This is more customer-friendly than forcing browsing in a full virtual machine, but can the browser ever be completely isolated? Of course not, but this helps prevent stupid user actions from hurting users (or the organization, or you). Application Whitelisting: A very useful option for truly locking down particular devices, application whitelisting implements a positive security model on an endpoint. You specify all the things that can run and block everything else. Malware can’t run because it’s unauthorized, and alerts can be fired if malware-type actions are attempted on the device. For devices which can be subjected to draconian lockdown, AWL makes a difference. But they tend to be a small fraction of your environment, relegating AWL to a niche. Remember, we aren’t talking about an either/or decision. You’ll use one or more of these options, regardless of what you do on the network for malware detection. Content Security Gateways The next layer we saw develop for malware detection was the content security gateway. This happened as LAN-based email was becoming pervasive, when folks realized that sneakernet was horribly inefficient when the bad guys could just send viruses around via email. Ah, the good old days of self-propagating worms. So a set of email (and subsequently web) gateway devices were developed, embedding anti-virus engines to move detection closer to the perimeter. Many attacks continue to originate as email-based social engineering campaigns, in the form of phishing email – either with the payload attached to the message, more often as a link to a malware site, and sometimes even embedded within the HTML message body. Content security gateways can detect and block the malware at any point during the attack cycle by stopping attached malware, blocking users from navigating toa compromised sites, or inspecting web content coming into the organization and detecting attack code. Many of these gateways also use DLP-like techniques to ensure that sensitive files don’t leave the network via email or web sessions, which is all good. The weakness of content gateways is similar to the issues with endpoint-based techniques: keeping up with the rapid evolution of malware. Email and web gateways do have a positive impact by stopping the low-hanging fruit of malware (specimens which are easy to detect due to known signatures), by blocking spam to prevent users from clicking something stupid, and by preventing users from navigating to compromised sites. But these devices, along with email and web based cloud services, don’t stand much chance against sophisticated malware, because their detection mechanisms are primarily based on old-school signatures. And once