Research

One of the issues of being a high achiever (at least in my own mind) is that you’re always in a rush. Half the time we don’t know where we’re going, but we need to get there fast. And it results in burn-out, grumpiness, and poor job performance – which is the worst thing for someone focused on achievement. A mentor of mine saw this tendency in me early on and imprinted a thought that I still think about often: “It’s not a sprint, Mike, it’s a marathon.” Man, those words speak the truth. Rich’s post on Monday urging us to Get over it is exactly right. It made me think about sprints and marathons and also the general psyche of successful security folks. We are paranoid, we are cynical, we expect the worst in people. We have to, it’s our job. But do this long enough and you can lose faith. I think that’s what Rich is referring to, especially at the end of yet another year where the bad guys won, whatever that means. So this is the deal. Remember this is a marathon. The war is not won or lost with one battle (unless you take a spear to the chest, that is). The bad guys will continue to innovate. Assuming you are a good guy/gal, you’ll struggle all year to catch up and still not get there. Yes, most of sleeping at night as a security person involves accepting that our job is Sisyphean. We will always be pushing the rock up the hill. And we’ll never get there. It’s about learning to enjoy the battle. To appreciate the small victories. And to let it go at the end of the day and go home with no regret. I know folks like to vent on Twitter and write inflammatory blog posts because they can commiserate with all their cynical buddies and feel like they belong. Believe me, I get that. But I also know a lot of these folks pretty well, and most love the job (as dysfunctional as it is) and couldn’t think of doing anything else. But if you are one of those who can’t get past it, I suggest you spend some time over the holidays figuring out whether security is the right career path for you. It’s okay if it’s not. Really. What’s not okay is squandering the limited time you have on something that makes you miserable. Photo credits: “Day 171” originally uploaded by Pascal Incite 4 U Anti-Exploitation works. Who knew? Rich has been talking about anti-exploitation defenses on endpoints for a long time. I added a bit in Endpoint Security Fundamentals, but the point has been that we need to make it harder (though admittedly never impossible) for hackers to attack memory. Now Microsoft itself has a good analysis of the effectiveness of DEP and ASLR and their value – both alone and together. Clearly these controls will stop some attacks, but not all, so don’t get lulled into a false sense of security because you leverage these technologies where possible. They are a good start, but you aren’t done. You’re never done, but you already know that. – MR Out with the old: Gunnar Peterson asks: Is your site more secure than Gawker? – covering the iceberg of password reuse across sites, but also stating that passwords are intrinsically unsafe. Sure, they provide all or nothing access, but I don’t think the discussion should center on the damage caused by bad passwords. I’d say we know that. Instead we should use alternatives we could actually implement to fight this trend. Passwords are like statistics in baseball, in that they have been around so long they are taken for granted; and additionally because most IT professionals can’t wrap their heads around the concept of life without passwords. Bill Cheswick gave a great presentation at OWASP 2010 in Irvine, with evidence on why passwords are unnatural devices, tips on improving password policies, and most importantly alternative methods for establishing identity (26:30 in) such as Passfaces, Illusion, Passmaps, and other types of challenge/response. Many of these alternatives avoid storing Gunnar’s proverbial land mine. – AL IE9 puts a cap in the drive-by: We all know Microsoft Internet Explorer security sucks, right? I mean that’s what I read in all the Slashdot comments. Too bad the latest NSS Labs report shows exactly the opposite. NSS hired some alcoholic, porn, and gambling obsessed rhesus monkeys to browse all the worst of the Internet for a few days and see which browsers showed the best defenses against drive-by and downloadable malware. The winner? IE9 (beta) with a 99% success rate, followed by IE8 at 90%, then Firefox at… 19%. They did test Firefox without our recommended NoScript and other security enhancing plug-ins, but that accurately reflects how the great unwashed surf the web. Despite being a Mac fanboi, for a couple years now I’ve been doing all my banking on a Win7 system with IE8/9. It’s nice to see numbers back up my choice. – RM Fox in the henhouse alert: Speaking of anti-malware tests, it seems the endpoint security vendors are banding together to reset the testing criteria, with the willing participation of ICSA Labs. To be clear, this is a specific response to the tests that NSS Labs has been running which make all the endpoint vendors look pretty bad. So why not work with a respected group like ICSA to redefine the testing baseline, since the world changed? Conceptually it’s a good idea, in practice… we’ll see. I have a lot of friends at ICSA, so I don’t want to be overly negative out of the gate, but let’s just say I doubt any of the baseline tests will make mincemeat out of the endpoint security suites. And thus they may not reflect real world use. You can quibble with NSS and their anti-malware testing methodology, but whatever they are doing is working, as demonstrated by the EPP vendors uniting against

Getting back to our Infrastructure Security Research Agenda for 2011 (Part 1: Positivity, Part 2: Posturing and RFAB), let’s now turn our attention to two more areas of focus. The first is ‘vaulting’, a fancy way of talking about network segmentation with additional security controls based on what you are protecting. Then we’ll touch on assurance, another fancy term for testing your stuff. Vaulting As I described in my initial post on the topic, this is about network segmentation and designing specific control sets based on the sensitivity of the data. Many folks have plenty of bones to pick with the PCI Data Security Standard (DSS), but it has brought some pretty good security practices into common vernacular. Network segmentation is one; another is identifying critical data and then segregating it from general purpose (less sensitive) data. Of course, PCI begins and ends with cardholder data, and odds are there’s more to your business. But the general concepts of figuring out what is important (‘in-scope’, in PCI parlance), making sure only folks who need access to that data have it, and then using all sorts of controls to make sure it’s protected, are goodness. These concepts can and should be applied across all your data, and that’s what vaulting is about. In 2011, we’ll be documenting a lot of what this means in practical terms, given that we already have lots of gear that needs to evolve (like IDS/IPS), as well as additional device types (mobile) that fundamentally change who has access to our stuff and from where. We can’t boil the ocean, so our research will happen in stages. Here are some ideas for breaking down the concepts: Implementing a Trusted Zones Program: This project focuses on how to implement the vaulting (trusted zones) concept, starting with defining and then classifying the data. Next design the control sets for each level of sensitivity. And finally implement network segmentation with the network ops team. It also includes a discussion of keeping data definitions up to date and control sets current. IDS/IPS Evolution: Given the evolution towards application aware firewalls (see Understanding and Selecting an Enterprise Firewall), the role of the traditional network-based IDS/IPS must and will clearly evolve. But the reality is there are millions of customers using these capabilities, so they are not going away overnight. This research will help customers understand how their existing IDS/IPS infrastructure will play in this new world order, and how end users need to think about intrusion prevention moving forward. Protecting Wireless: Keep in mind that we are still dealing with the ingress aspects, but pretty much all organizations have some kind of wireless networks in their environments, so we need to document ways to handle them securely and how the wireless infrastructure needs to play with other network security controls. There are many compliance issues to deal with as well, such as avoiding WEP. Yes, combining the Positivity and Vaulting concepts does involve a significant re-architecture/re-deployment of network security over the next few years. You didn’t really think you were done, did you? Security Assurance One of the areas I’ve been all over for the past 5 years is the need to constantly be testing our defenses. The bad guys are doing this every day, so we need to also. If only to know what they are going to find. So I’m a big fan of penetration testing (using both humans and tools) and think we collectively need to do a better job of understanding what works and what doesn’t. There are many areas to focus on for assurance. Here are a few ideas for interesting research that we think could even be useful: Scoping the Pen Test: Many penetration tests fail because they aren’t scoped to be successful. This research project will focus on defining success and setting the ground rules to get maximum impact from a pen test and if/when to pull the plug if internal buy-in can’t be gained. Automating Pen Testing: We all seem to be fans of tools that automate pen tests, but why? We’ll dig deeply into what these tools do, how to use them safely, what differentiates the offerings, and how to use them systematically to figure out what can really be exploited, as opposed to just vulnerable. As you can see, there is no lack of stuff to write about. Next we’ll turn the tables a little and deal with the egress research ideas we are percolating. Share:

One advantage of my background is that I’ve used and marketed/sold security products, as well as followed the industry for a long time, so I see patterns over and over again. But before I jump into that, you all need to head over to Lenny Zeltser’s blog. He’s doing a lot of writing, and given the general lameness of the rest of us security bloggers, it’s nice that we have a new victim thought leader to peruse. Lenny is doing a series now on defining Competitive Advantage for Security Products. The posts deal with Ease of Use and Price. As you would expect, I have opinions on this topic. I see both as indications of product/category maturity. I don’t necessarily want to delve into the entire adoption curve for security products, but suffice it to say most innovative products are narrowly defined and targeted towards an enterprise-class customer. Why? Enterprises have the money to pay way too much for way too little capability, which half the time doesn’t even work. But they’ve got small problems on large enough scales that they’ll write big checks on the faint hope of plugging in a box and making the issue go away. Over time, products/categories either solve problems or they don’t. If they make the cut, interest starts to develop in smaller companies that likely have the problem (though not at the same scale), but not the money to write big checks. Smaller companies also tend to be less technically sophisticated than a typical enterprise. Of course that is a crass overgeneralization, but at minimum an enterprise has resources to throw at the problem. So a product with a crappy user experience usually doesn’t deter them. They’ve got folks to figure it out. Smaller companies, not so much. Which is why as a product/category matures, and thus becomes more applicable to a smaller company market segment, the focus turns quickly to ease of use and price. Small companies need a streamlined user experience and don’t want to pay a lot. So they don’t. I lived through this in the anti-spam business. In its early days, customers (mostly on the enterprise) wanted lots of knobs and dials to tune their catch rates (and keep their people busy and employed). At some point customers got tired of endless configuration, so they opted for better user experience. Early leaders which couldn’t dumb down their products suffered (yes, I still have road rash from that). At the same time, Barracuda introduced a device for about 10% of the typical price of an anti-spam gateway. Price wasn’t just a differentiator here, it was a disruptor. $50K non-competitive deals because $10K crapfest. It’s hard to grow a business exponentially when you have to compete for 20% of the revenue you previously got. Right, not a lot of fun. And now managed anti-spam services provide an even easier and more cost effective option, so guess where many customers are moving their spending? I agree with Lenny that ease of use and price can be used for competitive advantage. But only if the market is mature enough. A low-cost DLP or SIEM (as opposed to log management) tool won’t be successful because the products are not easy enough to use. So for end users buying a lot of this technology, keep your expectations on price and ease of use in alignment with market maturity and you can find the right product for your environment, regardless of what size you are. Share:

The first of my Infrastructure Security Research Agenda 2011 posts, introducing the concept of positivity, generated a lot of discussion. Not only attached to the blog post (though the comments there were quite good), but in daily discussions with members of our extended network. Which is what a research agenda is really for. It’s a way to throw some crap against the wall and see what sticks. Posturing So let’s move on to the next aspect of my Ingress research ideas for the next year. It’s really not novel, but considering how awful most organizations are about fairly straightforward blocking and tackling, it makes sense to keep digging into this area and continue publishing actionable research to help practitioners become a bit less awful. I’m calling this topic area Posturing because it’s really about closing the doors, battening down the windows, and making sure you are ready for the oncoming storm. And yes, it’s storming out there. We did talk about this a bit in the Endpoint Security Fundamentals series under Patching and Secure Configurations. There are three aspects of Posturing: Vulnerability Management: Amazingly enough, we haven’t yet written much on how to do vulnerability management. So we’ll likely focus on a short fundamentals series, and follow up with a series on Vulnerability Management Evolution, because with the advent of integrated application and database scanning – combined with the move towards managed services for vulnerability management – there are plenty of things to talk about. Patching: No it’s not novel, but it’s still a critical part of the security/ops guy’s tool box. As the tools continue to commoditize, we’ll look at what’s important and how patching can & should be used as a stepping stone to more sophisticated configuration management. The process (laid bare in Patch Management Quant) hasn’t changed, but we’ll have some thoughts on tool evolution for 2011. Configuration Policy Compliance: Pretty much all the vulnerability management players are looking at auditing device configurations and comparing reality to policy as a logical extension of the scans they already do. And they are right, to a point. In 2011 we’ll look at this capability as leverage on other security operational functions. We’ll also document the key capabilities required for security and an efficiency – beyond managing configuration changes for policy compliance. To be honest I’m not crazy about the term Posturing, but I couldn’t think of anything I liked better. This concept really plays into two aspects of our security philosophy: Reduce attack surface: A configuration policy with solid vulnerability/configuration/patching operations help close the holes used by less sophisticated attackers. Positivity falls into this bucket as well, by restricting the types of traffic and executables allowed in our environments. React faster: By watching for configuration changes, which can indicate unauthorized activity on key devices (generally not good), you put yourself in position to see attacks sooner, and thus to respond faster. Yes, we are doing a lot of research into what ‘response’ means here, but Posturing can certainly be key to making sure nothing gets missed. React Faster and Better We beat this topic to death in 2010, so I’m not going to reiterate a lot of that research beyond pointing to the stuff we’ve already done: Understanding and Selecting SIEM/Log Management Monitoring up the Stack Incident Response Fundamentals We’re also working on the successor to Incident Response Fundamentals in our React Faster and Better series. That should be done in early January, and then we’ll focus our research in this area on implementation and success, which means a few Quick Wins series. These will probably include: Quick Wins with Network Monitoring: You know how I love monitoring, and clearly understanding and factoring network traffic into security analysis can yield huge dividends. But how? And how much? Quick Wins with Security Monitoring: Deploying SIEM and Log Management can be a bear, so we’ll focus on making sure you can get quick value from any investment in this area, as well as ensuring you are setting yourself up for a sustainable implementation. We have learned many tricks over the past few years (particularly from folks who have screwed this up), so it’s time to share. Once much of this research is published, we’ll have a pretty deep treatment of our React Faster and Better concept. Share:

Ah yes, it’s that time of year. Time for predictions and pontification and soothsaying and all sorts of other year-end comedy. As I told the crowd at SecTOR, basically everyone is making sh*t up. Sure, some have somewhat educated opinions, but at the end of the day nobody knows what will kill us in 2011. Except for the certainty that it will be something. We just don’t know what that something will be. As the Securosis plumber, I cover infrastructure topics, which really means network and endpoint security, as well as some security management stuff. It’s a lot of ground to cover. So I’ll be dribbling out my research agenda in 4-5 posts over the next week. The idea here is to get feedback on these positions and refine them. As you’ll see, all of our blog series (which eventually become white papers) originate from the germs of these concepts. So don’t be bashful. Tell us what you think – good, bad, and ugly. Before I get started, in order for my simple mind to grasp the entirety of securing the infrastructure, I’ve broken the topics up into buckets I’ll call ingress and egress. Ingress is protecting your critical stuff from the bad folks out there. Now that the perimeter is mostly a myth, I’m not making an insider/outsider distinction here. Network security (and some other stuff) fits into this area. Egress is working to protect your devices from bad stuff. This involves protecting the endpoints and mobile devices, with device-resident solutions, as well as gateways and cloud services aimed at protection. Ingress Positivity I’m going to start off with my big thought, and for a guy who has always skewed toward ‘half-empty’, this is progress. For most of its existence, security has used a negative security model, where we look for bad things – usually using signatures or profiles of known bad behavior. That model is broken. Big time. We’ll see like 25+ million new malware samples this year. We can’t possibly look for all of them (constantly), so we have to change the game. We have to embrace the positive. That’s right, positivity is about embracing a positive security model anywhere we can. This means defining a set of acceptable behaviors and blocking everything else. Sounds simple, but it’s not. Positivity breaks things. Done wrong, it’ll break your applications and your user experience. It’ll keep your help desk busy and make you a pariah in the lunch room. But it’s probably your only chance of turning the tide against many of these new attacks. This isn’t a new concept. A lot of folks have implemented default deny on their perimeters, and that’s a good thing. Application white listing on the endpoint has been around for a while, and achieved some success in specific use cases. But there are lots of other places we need to defend, so let’s list them out. Perimeter Gateway: We discussed this in the Enterprise Firewall paper, but there is a lot more to be said, including how to implement positivity on the EFW or UTM without getting fired. We also need to look critically at the future of IDS/IPS, given that it is really the manifestation of a negative security model, and there is significant overlap with the firewall moving forward. Web Application Firewall (WAF): The WAF needs to be more about a positive security model (right now it’s mostly negative), so our research will focus on how to leverage WAF for maximum effect. Again, there is significant risk of breaking applications if the WAF rules are wrong. We will also examine current efforts to do the first level of WAF in the cloud. The Return of HIPS: HIPS got a bad wrap because it was associated with signatures (given its unfortunate name), but that’s not how it works. It’s basically a white listing approach for app servers. Our research here will focus on how to deploy HIPS without breaking applications, and working through the inevitable political issues of trying to work with other IT ops teams for deployment, given how much they enjoy the security team starts mucking around with things. Database Positivity: One feature of current Database Activity Monitoring products is the ability to block queries/commands that violate policy. We will delve into how this works, how to do it safely, and how layering positivity at different layers of the infrastructure can provide better security than we’ve been able to achieve previously. Notice I didn’t mention application white listing specifically here, because we are focused on ingress. Application white listing will be a key topic when I talk about egress later this week. To be clear, the path to my definition of positivity is long and arduous. It won’t be easy and it won’t be widespread in 2011, but we need to start moving in that direction now – using technologies such as DAM, HIPS, and application aware firewalls. The old model doesn’t work. It’s time for a new one. Stop surrounding yourself with negativity. Embrace the positive and give yourself a chance. I’m looking forward to your comments. Don’t be bashful. Share:

When I see the term ‘nutcracker’, I figure folks are talking about their significant others. There are times when the Boss takes on the role of my nutcracker, but usually I deserve it. At least that’s my story today because I’d rather not sleep in the doghouse for the rest of the year. But that’s not what I want to talk about. Let’s discuss the holiday show (and now movie) of the same name. To open up the book of childhood angst, I remember Mom taking me to see a local production of the Nutcracker when I was about 8. We got all dressed up and I figured I was seeing a movie or something. Boy, was I terrified. The big mouse dude? To an 8 year old? I still have nightmares about that. But as with everything else, I’m evolving and getting over it. At least when it comes to the Nutcracker. Both of my girls dance at a studio that puts on a big production of the Nutcracker every winter. They practice 3-4 times a week and have all the costumes and it’s quite a show. All building up to this weekend, where they’ll do 5 shows over 3 days. I’m actually looking forward to the shows this year, which I think may correlate to getting past my fear of a 14 year old with a big mouse head. This will be XX1’s third year and XX2’s first. They start small, so XX2 will be a party girl and on stage for about 5 minutes total. XX1 gets a lot more time. I think she’s a card and a soldier during the mouse battle. Though I can’t be sure because that would require actually paying attention during the last month’s 7×24 Nutcracker preparation. They just love it and have huge smiles when they are on stage. But it brings up the bigger idea of year-end rituals. Besides eating Chinese food and seeing a movie on Xmas Day. This year I’m not going to be revisiting my goals or anything because I’m trying to not really have goals. But there will be lots of consistency. I’ll spend some time with my family on our annual pilgrimage up North and work a lot as I try to catch up on all the stuff I didn’t get done in 2010. I’ll also try to rest, as much as a guy like me rests. 2010 was a big year. I joined Securosis and did a lot of work to build the foundation for my coverage areas. But there is a lot more to do. A whole lot more. We are working hard on an internal project that we’ll talk more about after the New Year. And we need to start thinking about what we’ll be doing in Q1. So my holidays will be busy, but hopefully manageable. And I’ll also leave some time to catch up on my honey-do list. Because the last thing I need is to enter 2011 with a nutcracker on the prowl. Photo credits: “Mouse King and Nutcracker” originally uploaded by Mike Mahaffie Incite 4 U The (R)Snake slithers into the sunset: We need to send some props to our friend Robert Hansen, otherwise known as RSnake. I’ve learned a lot from Robert over the years and hopefully you have too. As great a researcher as he is, he’s a better guy. And his decision to stop focusing on research because it isn’t making him happy anymore is bold, but I’d expect nothing less. So who picks up the slack? The good news is that there is no lack of security researchers out there looking for issues and hopefully relaying that knowledge to make us better practitioners. And if you weren’t sure what to start poking, check out RSnake’s list. That should keep all of you RSnake wannabes busy for a while. – MR The price of vanity: Is WikiLeaks doing what it is supposed to do? I was reading about the shakeup after the WikiLeaks incidents and how it has caused shuffling of U.S. diplomats and intelligence officers, in essence for reporting on what they saw. But I don’t have sympathy for the US government on this because the leaks did what leaks do: spotlight the silliness of the games being played. I understand that comments like these reveal more than just the topics being discussed; and that and who, how, and why information was gathered tells yet another story. But it seems to me that the stuff being disclosed is spotlighting two kids passing notes in high school rather than classified state secrets. Unless, of course, you really think Muammar Gaddafi seeing someone on the side is an issue of national security. Sure, it’s an embarrassment because it’s airing dirty laundry rather than exposing state secrets. There is no doubt that WikiLeaks will drive security services. People who consider themselves important are embarrassed, and in some cases their reputations will suffer, and being embarrassed will make it harder for them to maintain the status quo (if WikiLeaks is successful, at least). Care to bet on what will drive more security sales: data security requirements/regulation or political CYA? – AL That cloud/virtualization security thing is gonna be big: Early on in the virtualization security debate a lot of vendors thought all they needed to do was create a virtual appliance running their products, toss them into the virtual infrastructure, set up some layer 2 routing, and go buy a Tesla. It turns out the real world isn’t quite that simple (go grab a copy of Chris Hoff’s Four Horsemen presentation from a couple years ago). Juniper recognizes this and has announced their acquisition of Altor Networks. Altor provides compliance and security, including a hypervisor-based stateful firewall, for virtualization and private cloud. But even if the tech is total garbage (not that it is), Juniper scores a win by buying themselves a spot in the now-defunct VMSafe program. Unlike the VShield zones approach, with VMSafe participating vendors gain

One of the cool things about Securosis is its transparency. We develop all our research positions in the open through our blog, and that means at times we’re wrong. Wrong is such a harsh word, and one you won’t hear most analysts say. Of course, we aren’t like most analysts, and sometimes we need to recalibrate on a research project and recast the effort. Near the end of our Incident Response Fundamentals series, we realized we weren’t tracking with our project goals, so we split that off and get to start over. Nothing like putting your first draft on the Internet. But now it’s time for the reboot. Incident response is near and dear to our philosophy of security, between my insistence (for years) of Reacting Faster and Rich’s experience as a first responder. The fact remains that you will be breached. Maybe not today or tomorrow, but it will happen. We’ve made this point many times before (and it even happened to us, indirectly). So we’ll once again make the point that response is more important than any specific control. But it’s horrifying how unsophisticated most organizations are about response. This is compounded by the reality of an evolving attack space, which means even if you do incident response well today, it won’t be good enough for tomorrow. We spent a few weeks covering many of the basics in the Incident Response Fundamentals series, so let’s review those (very) quickly because they are still an essential foundation. Organization and Process First and foremost, you need to have an organization that provides the right structure for response. That means you have a clear reporting structure, focus on objectives, and can be flexible (since you never know where any investigation will lead). You need to make a fairly significant investment in specialists (either in-house or external) to make sure you have the right skill sets on call when you need them. Finally you need to make sure all these teams have the tools to be successful, which means providing the communications systems and investigation tools they’ll need to find root causes quickly and contain damage. Data Collection Even with the right organization in place, without an organizational commitment to systematic data collection, much of your effort will be for naught. You want to build a data collection environment to keep as much as you can, from both the infrastructure and the applications/data. Yes, this is a discipline itself, and we have done a lot of research into these topics (check out our Understanding/Selecting SIEM and Log Management and Monitoring up the Stack papers). But the fact remains, even with a lot of data out there, there isn’t as much information as we need to pinpoint what happened and figure out why. Before, During, and after the Attack We also spent some time in the Fundamentals series focused on what to do before the attack, which involves analyzing the data you are collecting to figure out if/when you have a situation. We then moved to the next steps, which involve triggering your response process and figuring out what kind of situation you face. Once you have sized up the problem, you must move to contain the damage, and perform a broad investigation to understand the extent of the issue. Then it is critical to revisit the response in order to optimize your process – this aspect of response is often forgotten, sadly. It’s Not Enough Yes, there is a lot to do. Yes, we wrote 10 discrete posts that barely cover the fundamentals. And that’s great, but for high-risk organizations.. it’s still not enough. And within the planning horizon (3-5 years), we expect even the fundamentals will be insufficient to deal with the attacks we will see. The standard way we practice incident response just isn’t effective or efficient enough for emerging attack methods. If you don’t understand what is possible, spend a few minutes reading about how Stuxnet seems to really work, and you’ll see what we mean. While the process of incident response still works, how we implement that process needs to change. So in our recast React Faster and Better series, we’ll focus on pushing the concepts of incident response forward. Dealing with advanced threats requires leveraging advanced tools. Thank you, Captain Obvious. We’ve had to deal with new tools for every new attack since the beginning of time. But it’s more than that. RFAB is about taking a much broader and more effective perspective on dealing with attacks – from what data you collect, to how you trigger higher-quality alerts, to the mechanics of response/escalation, and ultimately remediation and cleaning activities. This is not your grandpappy’s incident response. All these functions need to evolve dramatically to keep up. And those ideas are what we’ll present in this series. Share:

OK, before you start leaving flowers and wreaths at Looney Toons HQ, our favorite animated Martian is not dead. But the product formerly known as Cisco MARS is. The end of life announcement hit last week, so after June of 2011 you won’t be able to buy MARS and support will ebb away over the next 3 years. Of course, this merely formalize what we’ve all known for a long time. The carcass is mostly decomposed by the time you get the death notice. That being said, there are thousands of organizations with MARS installed (and probably thousands more with it sitting on a shelf), which need to do something. Which raises the question: what do you do when a key part of your infrastructure is EOL? You may be SOL. Don’t be on the ship when it goes down: The first tip we’d give you is to get off the ship well before it’s obvious it’s going down. There have been lots of folks talking about the inevitability of MARS’ demise for years. If you are still on the ship, shame on you. But it is what it is – sometimes there are reasons you just can’t move. What then? Follow the vendor path: In many cases when a vendor EOLs a product, they define a migration path. Of course in the case of MARS, Cisco is very helpful in pointing out: “There is no replacement available for the Cisco Security Monitoring, Analysis, and Response System at this time.” Awesome. They also suggest you look to SIEM ecosystem partners for your security management needs. Yes, they are basically handing you a bag of crap and asking what you’d like to do with it. So in this case you must… Think strategically: Basically this is a total reset. There is no elegant migration. There is no way to stay on the yellow brick road. So take a step back and figure out what problem(s) you are trying to solve. I’d suggest you take a look at our Understanding and Selecting a SIEM/Log Management Platform paper to get some ideas of what is involved in this procurement. Just remember not to make a tactical decision based on what you think will be easiest. It was easiest to deploy MARS way back when, remember? And how did that work out for you? Don’t get fooled again: Speaking of easy, you are going to hear from a zillion vendors about their plans to move your MARS environment to something else. Right, their something else. The MARS data formats are well understood, so pulling your data out and levering in a new platform isn’t a huge deal. But before you rush headlong into something, make sure it’s the right platform to solve your problems as you see them today. You can’t completely avoid vendors pulling the plug on their products, but you can do homework up front to minimize the likelihood of depending on something that goes EOL. Buy smart: Once you figure out what you want to buy, make the vendors compete for your business. Yes, a zillion companies want your business – make them work for it. Make them throw in professional services. Make them discount the hell out of their products. MARS plays in a buyer’s market for SIEM, which means many companies are chasing deals. Use that to your advantage and get the best pricing you can. But only on the products/services that strategically solve your problem (see above). Good thing you bought that extra plot at the cemetery right next to CSA, eh? Image credit: “MAN IS FED UP WITH EARTH…GOING BACK TO SPACE…” originally uploaded by Robert Huffstutter Share:

As we mentioned a few weeks ago, we are in the process of splitting out the heavy duty research we do for our blog series from the security industry tips and tactics. Here is a little explanation of why: When we first started the blog it was pretty much just Rich talking about his cats, workouts, and the occasional diatribe against the Security Industrial Complex. As we have added people and expanded our research we realized we were overloading people with some of our heavier research. While some of you want to dig into our big, multi-part series on deep technical and framework issues, many of you are more interested in keeping up to date with what’s going on out there in the industry, and prefer to read the more in-depth stuff as white papers. So we decided to split the feed into two versions. The Complete feed/view includes everything we publish. We actually hope you read this one, because it’s where we publish our research for public review, and we rely on our readers to keep us honest. The Highlights feed/view excludes Project Quant and heavy research posts. It still includes all our ‘drive-by’ commentary, the FireStarters, Incites, and Friday Summaries, and anything we think all our readers will be interested in. Don’t worry – even if you stick to the Highlights feed we’ll still summarize and point to the deeper content. One of the things we didn’t do was summarize the Incident Response Fundamentals series. This started as React Faster and Better, but we realized about midway that we needed to have a set of fundamentals published before we could go into some of the advanced topics that represent the RFAB philosophy. So here is a list of posts of the Incident Response Fundamentals series: Introduction Data Collection/Monitoring Infrastructure Incident Command Principles Roles and Organizational Structure Response Infrastructure and Preparatory Steps Before the Attack Trigger, Escalate, and Size up Contain, Investigate, and Mitigate Mop up, Analyze, and QA Phasing It In We think this is a good set of foundational materials to start understanding incident response. But the discipline clearly has to evolve, and that’s what our next blog series (the recast React Faster and Better) is about. We’ll start that tomorrow and have it wrapped up nicely with a bow by Christmas. Share:

We are a full disclosure shop here at Securosis. That means you get to see the good, the bad, and yes, the ugly too. We’ve been pretty up front about saying it was just a matter of time before our stuff got hacked. In fact, you can check out the last comment from this 2007 post, where Rich basically says so. Not that we are a high profile target or anything, but it happens to everyone at some point or another. And this week was our time. Sort of. You see, we are a small business like many of you. So we try to leverage this cloud thing and managed services where appropriate. It’s just good business sense, given that many of these service providers can achieve economies of scale we could only dream about. But there are also risks in having somewhat sensitive information somewhere else. A small part of our email list was compromised, as a result of our service provider being hacked. I got an email from a subscriber to the Incite mailing list on Monday night, letting me know he was getting spam messages to an address he only uses for our list. I did some initial checking around and couldn’t really find anything amiss. Then I got another yesterday (Wednesday) saying the same thing, so I sent off a message to our email service provider asking what was up. It seems our email provider got compromised about 6 weeks ago. Yes, disclosure fail. Evidently they only announced this via their blog. It’s surprising to me that it took the bad guys 6 weeks to start banging away at the list, but nonetheless it happened and proves that one of our lists has been harvested. There isn’t anything we can do about it at this point except apologize. For those of you who share your email addresses with us, we are very sorry if you ended up on a spam list. And that’s one of the core issues of this cloud stuff. You are trusting your sensitive corporate data to other folks, and sometimes they get hacked. All you can do is ask the questions (hopefully ahead of time) to ensure your information is protected by the service provider, but at the end of the day this happens. We are on the hook for violating the trust of our community, and we take that seriously. So once again all of us at Securosis apologize. Share: