Research

It’s the holiday season and I should be taking some time off and relaxing, watching some movies and seeing friends. Sounds good. If only I had that ‘relax’ gene sequence I would probably be off having a good time rather than worrying about security on Giftmas eve. But here I am, reading George Hulme’s Threatpost article, 2011: What’s Your IT Security Plan?. I got to thinking about this. Should I wait to do security work for 2011? I mean, at your employer is one thing – who cares about those systems when there is eggnog and pumpkin pie? I’m talkin’ about your stuff! One point I make in the talks I give on software security is: don’t prioritize security out in favor of features when building code. And in this case, if I put off security in favor of fun, security won’t get done in 2011. So I went through the process of evaluating home computer and network security over the last couple days. I did the following: Reassess Router Security: Logged into my router for the first time in like two years to verify security settings. Basically all of the security settings – most importantly encryption – were correct. I did find one small mistake: I forgot to require the management connection to be forced over HTTPS, but as I had not been logged in for years, I am pretty sure that was not a big deal. I did however confirm the firmware was written by Methuselah – and while he was pretty solid coder, he hasn’t fixed any bugs in years. It was good to do a sanity check and take a fresh look. Migration to 1Password: I have no idea why I waited so long to do this. 1Password rocks! I now have every password I use secured in this and synchronized across all my computers and mobile devices. And the passwords are far better than even the longest passphrases I can remember. Love the new interface. Added bonus on the home machine: I can leave the UI open all the time, then autofill all web passwords to save time. If you have not migrated to this tool, do it. Deploy Network Monitoring: We see tons of stuff hit the company firewall. I used to think UTM and network monitoring was overkill. Not so much any more. Still in the evaluation and budgetary phase, but I think I know what I want and should deploy by year’s end. I want to see what hits, and what comes through. Yes, I am going to have to actually review the logs, but Rich wrote a nice desktop widget a couple years ago which I think I can repurpose to view log activity with my morning coffee. It will be just like working IT again! Clean Install: With the purchase of a new machine last week I did not use the Apple migration assistant. As awesome and convenient as that Mac feature is, I did a fresh install. Then I re-installed all ,u applications and merged the files I needed manually. Took me 8 hours. This was a just-in-case security measure, to ensure I don’t bring any hidden malware/trojans/loggers along for the ride. The added beneft was all the software I do not have set to manually update itself got revved. And many applications were well past their prime. Rotate Critical Passwords: I don’t believe that key rotation for encryption makes you any safer if you do key management right, but passwords are a different story. There are a handful of passwords that I cannot afford to have cracked. It’s been a year, so I swapped them out. Mobile Public Internet: Mike mentioned this in one of his Friday Favorites, but this is one of the best posts I have seen all year for general utility: Shearing Firesheep with the Cloud. What does this mean? Forget Firesheep for a minute. General man-in-the-middle attacks are still a huge problem when you leave the comfy confines of your home with that laptop. What this post describes is a simple way to protect yourself using public Internet connections. Use the cloud to construct an encrypted tunnel for you to use wherever you go. And it’s fast. So as long as you set it up and remember to use it, you can be pretty darn safe using public WiFi to get email and other services. That’s six things I did over the course of the week. Of course you won’t read this anywhere else because it’s six things, and no other security information source will give you six things. Five, or seven, but never six. Some sort of mythical marketing feng-shui numbers that can’t be altered without making some deity angry. Or maybe it was that you get cramps? I forget. There is probably a Wiki page somewhere that describes why that happens. This is the last Friday Summary of the year so I wanted to say, from Rich Mogull, Mike Rothman, Chris Pepper, David Mortman, Gunnar Peterson, Dave Lewis, and Melissa (aka Geekgrrl), and myself: thanks for reading the blog! We enjoy the comments and the give-and-take as much as you do. It makes our job fun and, well, occasionally humiliating. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich was quoted so many times on Wikileak DDOS that he DDOSed all media outlets with the sheer volume of his quotes. They had to shut him down. The rest of us were too far gone as slackerly curmudgeons (or was that curmudgeonly slackers?) to speak to anyone. Favorite Securosis Posts We all loved [Dealtime 2010: Remembering the Departed](Dealtime 2010: Remembering the Departed as the best post of the week. Except for Mike, who was unhappy we would not let him graph the specific hype cycles. Other Securosis Posts Incite 12/22/2010: Resolution. 2011 Research Agenda: Quantum Cloudiness, Supervillan Shields, and No-BS Risk. React Faster and Better: New Data for New Attacks, Part 1. NSA Assumes Security Is Compromised. 2011 Research Agenda: the

As we approach Christmas time, quite a few folks will have gold bullion under their trees, courtesy of the security industry M&A machines. Of course, the investment bankers and lawyers had a banner year, but let’s also hear it for some fortunate entrepreneurs, their VCs, and even some public company shareholders who were able to share in the wealth this year. You forget how long 12 months are, until you go back and start to revisit what happened in 2010. CRN helped me out a bit by doing one of their silly slideshows (page view hos) listing the Top 10 deals in security this year. Let’s take a quick run through each and think about the longer term impact (though we covered many of these during the year). Intel/McAfee: Obviously having the biggest pure-play security company taken out is a big deal. We did some analysis of the deal (and here), and our perspectives haven’t changed. Though with the EU scrutinizing the deal, there is still some risk of not closing. If it does we expect business as usual, though McAfee may be a bit more acquisitive (and spend bigger $$’s) leveraging Intel’s balance sheet. Symantec/PGP/GuardianEdge: Symantec had a huge hole relative to encryption, and they filled it. Twice. Why buy one, when you can buy two at twice the price? It’s the SYMC way! Though the initial integration ideas we’ve seen on the roadmap are promising, we are still talking about the Big Yellow here, so we remain cautious. Here is our deal analysis. Symantec/VeriSign: This high dollar deal was a surprise and clearly there is lots of risk. It does make sense and provide some leverage, especially relative to the enterprise authentication business. And this one requires less integration than most of SYMC’s deals. So this could end up being a net positive if the SYMC field teams can figure out how to sell it. SonicWall goes private: Thoma Bravo acquired SonicWall (our analysis here) and saved them from the quarterly scrutiny of being a public company. Big whoop. The real question is what are they going to fold into the operation (and no, Entrust is not a clean fit), because the company will need some additional heft and excitement to warrant another public offering or higher value deal to a strategic acquirer. Sophos goes private equity: Despite how ineffective traditional AV is at pretty much everything (except maybe passing PCI), it’s still a multi-billion-dollar market. We were reminded of that when APAX partners acquired Sophos for $830 million. Basically a 2nd tier player in AV is bigger than the entire DLP market, though probably not for long (WIKILEAKS WIKILEAKS WIKILEAKS). Like SonicWall, Sophos will need to keep buying stuff to be able to generate excitement for an IPO. HP/Fortify: HP got the application security bug and added Fortify to SPI Dynamics and folded it all into its application tools business. Which is exactly where it belongs, because without tight linkages to IDEs and dev tools, developers won’t do much. Not that they will even with tight integration, but at least there is a chance. This also showed HP’s need to buy the biggest dog in any space, because you cannot move a needle that weighs more than $120 billion, $10 million at a time. HP/ArcSight: HP also swallowed up the big dog of the SIEM space in 2010. We’ve been saying for a long time that SIEM and Log Management are going to be part of the big IT ops management stack, and this kind of move facilitates that. Of course integration won’t be easy, but in the meantime we’re pretty sure an army of EDS services folks will keep very busy making ArcSight work. McAfee/Trust Digital: McAfee did a few deals last year, and this one – acquiring Trust Digital to add some mobile security technology – may pay dividends when we see weaponized mobile attacks go mainstream. At some point it will happen and folks will have to pay attention to what’s on those pesky smart phones and how to protect it all. IBM/BigFix: After screwing the pooch on the ISS deal, IBM went back to the well to acquire BigFix, which is as much a big IT ops play as a security play. It fits nicely with Tivoli and thus will be a lot cleaner to integrate and leverage than ISS. That doesn’t mean there won’t be a run for the exits by the BigFix brain trust, or that IBM won’t screw this one up too, but you can at least make a case that BigFix is a much better fit. Trend Micro/Mobile Armor: Oh, yeah, Trend had a big hole in mobile encryption as well. So they filled it, but only once. How silly. Though it’s not clear they could have filled it twice if they tried. Bonus Round The CRN folks left out a couple that bear mentioning. RSA/Archer: This deal was announced on Jan 5, so it hardly feels like a 2010 deal. Given EMC’s move to drive more of their own services and push to solidify CIO level relationships, buying Archer’s toolkit, I mean ‘platform’, makes a lot of sense. The question for next year is whether RSA will buy something to supplement EnVision, which continues to fall behind technically in the SIEM/Log Management space. Juniper/Altor: This one is fresh in our minds because it went down recently, but buying Altor was probably as much about Juniper getting access to the VMSafe API as about buying a spot in a market that isn’t yet. How else do you justify paying in the neighborhood of 30x bookings? You can check out our pithy Incite on the deal (it’s bullet #3). I’m sure by this point you want to know what’s going to happen in 2011. So let’s bust out the Magic 8 Ball and figure it out: Will there be more deals in 2011 than 2010? My sources say no. Will there be a bunch of fire sales? Without a doubt.

Pretty much every year, I spend the winter holidays up north visiting the Boss’s family. I usually take that week and try to catch up on all the stuff I didn’t get done, working frantically on whatever will launch right when everyone returns from their December hangover. But as I have described here, I’m trying to evolve. I’m trying to take some time to smell the proverbial roses, and appreciate things a bit. I know, quite novel. I have to say, this has been a great year on pretty much all fronts. There was a bit of uncertainty this time last year, as I had left my previous job and we were rushing headlong into announcing the new Securosis. There were a lot of moving pieces and it was pretty stressful, with legal documents relating to the new company floating around, web sites to update, and pipelines to build. A year later, I can say things are great. I’ve told them each collectively, but I have to thank Rich and Adrian for letting me join their band of merry men. Also a big thanks to our contributors (Mort, Gunnar, Dave, and Jamie) who keep us on our toes and teach me something every time we talk. I won’t forget our editor Chris either, who actually helps to make my ramblings somewhat Strunk & White ready. I also want to thank all of you, for reading my stuff and not throwing anything at me during speaking gigs. I do appreciate that. Mentally, I’m in a good place. Sure I still have some demons, but who doesn’t? I keep looking to exorcise each one in its turn. Physically, I’m in pretty good shape. Probably the best shape I’ve been in since I graduated college. Yes, I had dark hair back then. The family is healthy and they seem to still like me. I have nothing to complain about on that front. Yes, I’m very lucky. I’m also very excited for 2011. Rich alluded to our super sekret plans for world domination, and things are coming together on that front. No, it’s not fast enough, but when we get there it will be great. I’m looking forward to fleshing out my research agenda and continuing to work with our clients. Since this is the last Incite of 2010, I guess I’ll divulge my 2011 resolution: Don’t screw it up. No, I’m not kidding. There will be ups and there will be downs. I expect that. But if I can look back 12 months from now and feel the way I do today, it will have been a fantastic year. I hope you have a safe and happy holiday season, and there will be plenty of Incite in 2011. Until then… -Mike Photo credits: “Resolution” originally uploaded by sneeu Incite 4 U Gawking at Security 101: Oh how the PR top spins. After spending last week washing egg off their faces due to the massive pwnage Gawker suffered, now they are out talking about all the cool stuff they’ll do to make sure it doesn’t happen again. Like requiring employees to log into Google Apps with SSL. And telling them not to discuss sensitive stuff in chat rooms. Yeah, that’s the answer. Just be thankful that sites like Gawker don’t collect much information. Though we should commend folks like LinkedIn and Yahoo, who used the list of suckers, I mean commenters, and reset their passwords automagically. I’ve had issues with LinkedIn’s security processes before, but in this case they were on the ball. – MR Fear the PM: Do project managers managers need to “lighten up” and give away some control over development projects? Maybe. Are they being forced to provide transparency into their projects because SaaS management tools allow access to outsiders? Mike Vizard and LiquidPlanner CEO Charles Seybold seem to think so. Personally I think it’s total BS. With Agile becoming a standard development methodology, the trend is exactly the opposite. Agile with Scrum, by design, shields development efforts from outside influencers, leaving product managers more in control of feature sets than ever before. They are the gatekeepers. And when you manage tasks by 3×5 card and prioritize with Post-It notes, you don’t exactly provide transparency. Collaboration and persuasion are interpersonal skills, not an app. I recommend that project managers leverage software for task tracking over and above task cards, but don’t think some cloud-based nag-ware is going to subjugate a skilled PM. – AL Not your daddy’s DDoS: – I’ve spent a heck of a lot of time explaining denial of service attacks to the media over the past few weeks for some odd reason. While explaining straightforward flooding attacks is easy enough, I found it a bit tougher to talk about more complex DDoS. To be honest I don’t know why I tried, because for the general press it doesn’t really matter. But one area I never really covered too much is application level DDoS, where you dig in and attack resource-intensive tasks rather than the platform. Craig Labovitz of Arbor Networks does a great job of explaining it in this SearchSecurity article (near the bottom). Definitely worth a read. – RM No slimming the AV pig: Ed over at Security Curve makes the point (again) that the issues around AV, especially performance, aren’t going to get better. Sure the vendors are working hard to streamline things and for the most part they are making progress. Symantec went from a warthog to a guinea pig, but it’s still a pig. And they can’t change the math. No matter how much you put into the cloud, traditional AV engines cannot keep up. Reputation and threat intelligence helps, but ultimately this model runs out of gas. Positivity, anyone? Yes, I’m looking for white listing to make slow and steady inroads in 2011. – MR Live with it: – This Incite isn’t a link, but a note on a call I had with a vendor recently (not a client) that highlighted 2 issues.

In my last post I covered the more practical items on my research agenda for the coming year. Today I will focus more on pure research: these topics are a bit more out there and aren’t as focused on guiding immediate action. While this is a smaller percentage of where I spend my time, overall I think it’s more important in the big picture. Quantum Datum I try to keep 85-90% of my research focused on practical, real-world topics that help security pros in their day to day activities. But for the remaining 10-15%? That’s where I let my imagination run free. Quantum Datum is a series of concepts I’ve started talking about, around advanced information-centric security, drawing on metaphors from quantum mechanics to structure and frame the ideas. As someone pointed out, I’m using something ridiculously complex to describe something that’s also complex, but I think some interesting conclusions emerge from mashing these two theoretical frameworks together. Quantum Datum is focused on the next 7-10 years of information-centric security – much of which is influenced by cloud computing. For me this is an advanced research project, which spins off various real-world implications that land in my other research areas. I like having an out-there big picture to frame the rest of my work – it provides some interesting context and keeps me from falling so far into the weeds that all I’m doing is telling you things you already know. Outcomes-Based Risk Management and Security I’m sick and tired of theoretical risk frameworks that don’t correlate security outcomes with predictions or controls. I’m also tired of thinking we can input a bunch of numbers into a risk framework without having a broad set of statistics in order to actually evaluate the risks in our context. And if you want to make me puke, just show me a risk assessment that relies on unverified vendor FUD numbers from a marketing campaign. The idea behind outcomes-based risk management and security is that we, to the best of our ability, use data gathered from real-world incidents to feed our risk models and guide security control decisions. This is based on similar approaches in medicine which correlate patient outcomes to treatments – rather than changes in specific symptoms/signs. For example, the question wouldn’t be whether or not the patient has a heartbeat when the ambulance drops them off at the hospital, but whether or not they later leave the hospital breathing on their own. (With the right drugs you can give a rock a heartbeat… or Dick Cheney, as the record shows). For security, this means pushing the industry for more data sets like the Verizon and Trustwave investigation/breach reports, which don’t just count breaches, but identify why they happened. This needs to be supplemented by additional datasets whenever and wherever we can find and validate them. Clearly this is my toughest agenda item, because it relies so heavily on the work of others. Securosis isn’t an investigations firm, and lacks resources for the kinds of vigorous research needed to reach out to organizations and pull together the right numbers. But I still think there are a lot of opportunities to dig into these issues and work on building the needed models by mining public sources. And if we can figure out an economically viable model to engage in the primary research, so much the better. The one area where we are able to contribute is on the metrics model side, especially with Project Quant. We’re looking to expand this in 2011 and continue to develop hard metrics models to help organizations improve operational performance and security. Advanced Persistent Defense Can you say “flame bait”? I probably won’t use the APD term, but I can’t wait to see the reactions when I toss it out there. There are plenty of people spouting off about APT, but I’m more interested in understanding how we can best manage the attackers working inside our networks. The concept behind advanced defense is that you can’t keep them out completely, but you have many tools to detect and contain the bad guys once they come in. Some of this ties to network architectures, monitoring, and incident response; while some looks at data security. Mike has monitoring well covered and we’re working on an incident response paper that fits this research theme. On top of that I’m looking at some newer technologies such as File Activity Monitoring that seem pretty darn interesting for helping to limit the depth of some of these breaches. No, you can’t entirely keep them out, but you can definitely reduce the damage. I’m debating publishing an APT-specific paper. I’ve been doing a lot of research with people directly involved with APT response, but there is so much hype around the issue I’m worried that if I do write something it might spur the wrong kind of response. The idea would be to cut through all the hype and BS. I could really use some feedback on whether I should try this one. In terms of the defense concepts, there are specific areas I think we need to talk about, some of which tie into Mike and Adrian’s work: Network segregation and monitoring. When you’re playing defense only, you need a 100% success rate, but the bad guy only needs to be right once – and no one is ever 100% successful over the long term. But once the bad guy is in your environment, with the right architecture and monitoring you can turn the tables. Now he needs to be right all the time or you can detect his activities. I want to dig into these architectures to tighten the window between breach and detection. File Activity Monitoring. This is a pretty new technology that’s compelling to me from a data security standpoint. In non-financial attacks the goal is usually to grab large volumes of unstructured data. I think FAM tools can increase our chances of detecting this activity early. Incident response. “React Faster

I always find it a bit of a challenge to fully plan out my research agenda for the coming year. Partly it’s due to being easily distracted, and partly my recognition that there are a lot of moving cogs I know will draw me in different directions over the coming year. This is best illustrated by the detritus of some blog series that never quite made it over the finish line. But you can’t research without a plan, and the following themes encompass the areas I’m focusing on now and plan to continue through the year. I know I won’t able to cover everything in the depth I’d like, so I could use feedback on to what you folks find interesting. This list is as much about the areas I find compelling from a pure research standpoint as what I might write about. This post is about the more pragmatic focus areas, and the next post will delve into more forward-looking research. Information-Centric (Data) Security for the Cloud I’m spending a lot more time on cloud computing security than I ever imagined. I’ve always been focused on information-centric (data) security, and the combination of cloud computing adoption, APT-style threats, the consumerization of IT, and compliance are finally driving real interest and adoption of data security. Data security consistently rates as a top concern – security or otherwise – when adopting cloud computing. This is in large driven part by the natural fear of giving up physical control of information assets, even if the data ends up being more secure than it was internally. As you’ll see at the end of this post, I plan on splitting my coverage into two pieces: what you can do today, and what to watch for the future. For this agenda item I’ll focus on practical architectures and techniques for securing data in various cloud models using existing tools and technologies. I’m considering writing two papers in the first half of the year, and it looks like I will be co-branding them with the Cloud Security Alliance: Assessing Data Risk for the Cloud: A cloud and data specific risk management framework and worksheet. Data Security for Cloud Computing: A dive into specific architectures and technologies. I will also continue my work with the CSA, and am thinking about writing something up on cloud computing security for SMB because we see pretty high adoption there. Pragmatic Data Security I’ve been writing about data security, and specifically pragmatic data security, since I started Securosis. This year I plan to compile everything I’ve learned into a paper and framework, plus issue a bunch of additional research delving into the nuts and bolts of what you need to do. For example, it’s time to finally write up my DLP implementation and management recommendations, to go with Understanding and Selecting. The odds are high I will write up File Activity Monitoring because I believe it’s at an early stage and could bring some impressive benefits – especially for larger organizations. (FAM is coming out both stand-alone and with DLP). It’s also time to cover Enterprise DRM, although I may handle that more through articles (I have one coming up with Information Security Magazine) and posts. I also plan to run year two of the Data Security Survey so we can start comparing year-over-year results. Finally, I’d like to complete a couple more Quick Wins papers, again sticking with the simple and practical side of what you can do with all the shiny toys that never quite work out like you hoped. Small Is Sexy Despite all the time we spend talking about enterprise security needs, the reality is that the vast majority of people responsible for implementing infosec in the world work in small and mid-sized organizations. Odds are it’s a part time responsibility – or at most 1 to 2 people who spend a ton of time dealing with compliance. More often than not this is what I see even in organizations of 4,000-5,000 employees. A security person (who may not even be a full-time security professional) operating in these environments needs far different information than large enterprise folks. As an analyst it’s very difficult to provide definitive answers in written form to the big company folks when I know I can never account for their operational complexities in a generic, mass-market report. Aside from the Super Sekret Squirrel project for S Share:

I saw an interesting news item: the NSA has changed their mindset and approach to data security. Their new(?) posture is that Security Has Always Been Compromised. Debora Plunkett of the NSA’s “Information Assurance Directorate” stated: There’s no such thing as ‘secure’ any more. The most sophisticated adversaries are going to go unnoticed on our networks. We have to build our systems on the assumption that adversaries will get in. We have to, again, assume that all the components of our system are not safe, and make sure we’re adjusting accordingly. I started thinking about how I would handle this problem and it became mind-boggling. I assume compartmentalization and recovery is the strategy, but the details are of course the issue. Just the thought of going through the planning and reorganization of a data processing facility the size of what the NSA (must) have in place sent chills down my spine. What a horrifically involved process that must be! Just the network and security technology deployment would be huge; the disaster recovery planning and compartmentalization – especially what to do in the face of incomplete forensic evidence – would be even more complex. How would you handle it? Better forensics? How would you scope the damage? How do you handle source code control systems if they are compromised? Are you confident you could identify altered code? How much does network segmentation buy you if you are not sure of the extent of a breach? To my mind this what Mike has been covering with his ‘Vaults’ concept of segmentation, part of the Incident Response Fundamentals. But the sheer scope and complexity casts those recommendations in a whole new light. I applaud the NSA for the effort: it’s the right approach. The implementation, given the scale and importance of the organization, must be downright scary. Share:

As we discussed in our last post on Critical Incident Response Gaps, we tend to gather too much of the wrong kinds of information, too early in the process. To clarify that a little bit, we are still fans of collecting as much data as you can, because once you miss the opportunity to collect something you’ll never get another chance. Our point is that there is a tendency to try to boil the ocean with analysis of all sorts of data. That causes failure and has plagued technologies like SIEM, because customers try to do too much too soon. Remember, the objective from an operational standpoint is to react faster, which means discovering as quickly as possible that you have an issue, and then engaging your incident response process. But merely responding quickly isn’t useful if your response is inefficient or ineffective, which is why the next objective is to react better. Collecting the Right Data at the Right Time Balancing all the data collection sources available today is like walking a high wire, in a stiff breeze, after knocking a few back at the local bar. We definitely don’t lack for potential information sources, but many organizations find themselves either overloaded with data or missing key information when it’s time for investigation. The trick is to realize that you need three kinds of data: Data to support continuous monitoring and incident alerts/triggers. This is the stuff you look at on a daily basis to figure out when to trigger an incident. Data to support your initial response process. Once an incident triggers, these are the first data sources you consult to figure out what’s going on. This is a subset of all your data sources. Keep in mind that not all incidents will tie directly to one of these sources, so sometimes you’ll still need to dive into the ocean of lower-priority data. Data to support post-incident investigation and root cause analysis. This is a much larger volume of data, some of it archived, used to for the full in-depth investigation. One of the Network Security Fundamentals I wrote about early in the year was called Monitor Everything because I fundamentally believe in data collection and driving issue identification from the data. Adrian pushed back pretty hard, pointing out that monitoring everything may not be practical, and focus should be on monitoring the right stuff. Yes, there is a point in the middle. How about collect (almost) everything and analyze the right stuff? That seems to make the most sense. Collection is fairly simple. You can generate a tremendous amount of data, but with the log management tools available today scale is generally not an issue. Analysis of that data, on the other hand, is still very problematic; when we mention too much of the wrong kinds of information, that’s what we are talking about. To address this issue, we advocate segmenting your network into vaults and analyzing traffic and events within the critical vaults at a deep level. So basically it’s about collecting all you can within the limits of reason and practicality, then analyzing the right information sources for early indications of problems, so you can then engage the incident response process. You start with a set of sources to support your continuous monitoring and analysis, followed by a set of prioritized data to support initial incident management, and close with a massive archive of different data sources, again based on priorities. Continuous Monitoring We have done a lot of research into SIEM and Log Management, as well as advanced monitoring (Monitoring up the Stack). That’s the kind of information to use in your ongoing operational analysis. For those vaults (trust zones) you deem critical, you want to monitor and analyze: Perimeter networks and devices: Yes, the bad guys tend to be out there, so they need to cross the perimeter to get to the good stuff. So we want to look for issues on those devices. Identity: Who is as important as what, so analyze access to specific resources – especially within a privileged user context. Servers: We are big fans of anomaly detection and white listing on critical servers such as domain controllers and app servers, so you can be alerted to funky stuff happening at the server level – which usually indicates something that warrants investigation. Database: Likewise, correlating database anomalies against other types of traffic (such as reconnaissance and network exfiltration) can indicate a breach in progress. Better to know that early, before your credit card brand notifies you. File Integrity: Most attacks involve some change to key system files, so by monitoring their integrity you can pinpoint when an attacker is trying to make changes. You can even block these attacks using technology like HIPS, but that’s another story for another day. Application: Finally, you should be able to profile normal transactions and user interactions for your key applications (those accessing protected data) and watch for non-standard activities. Again, they don’t always indicate a problem, but do allow you to prioritize investigation. We recommend focusing on your most important zones, but keep in mind that you need some baseline monitoring of everything. The two most common sources we see for baselines are network monitoring and endpoint & server logs (or whatever security tools you have on those systems). Full Packet Capture Sandwich One emerging advanced monitoring capability – the most interesting to us – is full packet capture. Rich wrote about this earlier this year. Basically these devices capture all the traffic on a given network segment. Why? In a nutshell, it’s the only way you can really piece together exactly what happened, because this way you have the actual traffic. In a forensic investigation this is absolutely crucial will provide detail you cannot get from log records. Going back to our Data Breach Triangle, you need some kind of exfiltration for a real breach. So we advocate heavy perimeter egress filtering and monitoring, to (hopefully) prevent valuable data from escaping

Apparently we are supposed to fear the supercomputer of the future. According to Computerworld, the clock is ticking on encryption. Yes, you guessed it, the mythical “quantum computer” technology is back in the news again, casting its shadow over encryption. It will make breaking encryption much, much easier. “There has been tremendous progress in quantum computer technology during the last few years,” says Michele Mosca, deputy director of the Institute for Quantum Computing at the University of Waterloo in Waterloo, Ontario, Canada. “It’s a game changer” And when they perfect it, the Playstation 37 will rock! Unfortunately it’s powered by leprechauns’s gold and Unicorn scat, so research efforts have been slowed by scarcity of resources. Seriously, I have been hearing this argument since I got into security 15 years ago. Back then we were hearing about how 3-DES was doomed when quantum technology appeared. It was, but that has more to do with Moore’s Law and infant encryption technologies than anything else. I think everybody gets that if we have computers that are a million times faster than what we have today Flash will run reasonably fast we’ll be able to break existing encryption technology. But how much data you encrypt today will have value in 20 years? Or more likely in 40 years? I am still willing to bet we’ll see 100” foldable carbon nanotube televisions or pools of algae performing simple arithmetic before quantum cryptography. And by that time, maybe all government laptops will have full disk encryption. Share:

In the first three posts of my 2011 Research Agenda (Positivity, Posturing and RFAB, Vaulting and Assurance) I mostly talked about how we security folks need to protect our stuff from them. You know, outside attackers trying to reach our stuff. Now let’s move on to people on the inside. Although most of us prefer to focus on folks trying to break in, it’s also important to put some forethought into protecting people inside the perimeter. Whether an employee loses a device (and compromises data), clicks the wrong link (resulting in a compromised device and giving attackers a foothold on the internal network), or even maliciously tries to exfiltrate data (WikiLeaks, anyone?) all of these attack scenarios are very real. So we have to think from the inside out about protecting endpoint devices, because nowadays that is probably the most common way for attackers to begin a multi-faceted attack. They’ll pwn an endpoint and then use it to pivot and find other interesting stuff. Yet, we also have to focus a bit on breaking one of the legs of Rich’s Data Breach Triangle – the egress leg. Unless the attackers can get the data out, it’s not a breach. So a lot of what we’ll do as part of the egress research agenda is focus on content filtering at the edge to ensure our sensitive stuff doesn’t escape. Endpoints The good news is that we did a bunch of research to lay the foundation for endpoint security in 2010. Looking at 2011, we want to dig deeper and start thinking about dealing with all of these newfangled devices like smartphones, and examine technologies like application white listing which implements our positivity model on endpoint devices. Background: Endpoint Security Fundamentals Endpoint Protection Suite Evolution: Using the Endpoint Fundamentals content as a base; we need to delve into what the EPP suite looks like moving forward; and how capabilities like threat intelligence, HIPS, and cloud services will remake what we think of as the endpoint suite. Application White Listing: Where, When, and Why? We’ve written a bit about application white listing concepts, but it’s still not necessarily a general purpose control – yet. So we’ll dig into specific use cases where white listing makes sense and some deployment advice to make sure your implementation is successful (and avoid breaking too much). Mobile device security: There is a lot of hype but not much by way of demonstrable weaponized threats to our smartphones, so we’ll document what you need to know and what to ignore, and discuss some options for protecting mobile devices. Quick Wins with Full Disk Encryption: Everyone is buying FDE, but how do you choose it and how do you get quick value? Again, lots of stuff to think about for protecting endpoints, so we’ll be pretty busy on these topics in 2011. Egress Egress filtering on the network will be covered by the Positivity research. But as Adrian mentions in his research agenda, there is plenty of content that goes out of your organization via email and web protocols, and we need to filter that traffic (before you have a breach). Understanding and Selecting DLP, v2: Rich’s recent updated to this paper is a great base, and we may dig into specific endpoint or gateway DLP to prevent critical content from leaving the organization – which plays directly into this egress theme. Web Security Evolution: Web filters and their successors have been around for years, so what is the future of the category and how can/should customers with existing web security implementations move forward? And how will SaaS impact how customers provide these services? Email Security Evolution: Very similar conceptually to web security evolution, but of course the specifics are very different. So there you have it. Yes, I’ll be pretty busy next year and that’s a good thing. I’m still looking for feedback on these ideas, so if one (or more) of these research projects resonates please let me know. Or if some things don’t, that would be interesting as well. Share:

In our introduction to this series we mentioned that the current practice of incident response isn’t up to dealing with the compromises and penetrations we see today. It isn’t that the incident response process itself is broken, but how companies implement response is the problem. Today’s incident responders are challenged on multiple fronts. First, the depth and complexity of attacks are significantly more advanced than commonly discussed. We can’t even say this is a recent trend – advanced attacks have existed for many years – but we do see them affecting a wider range of organizations, with a higher degree of specificity and targeting than ever before. It’s no longer merely the defense industry and large financial institutions that need to worry about determined persistent attackers. In the midst of this onslaught, the businesses we protect are using a wider range of technology – including consumer tools – in far more distributed environments. Finally, responders face the dual-edged sword of a plethora of tools; some of them are highly effective, and others that contribute to information overload. Before we dig into the gaps we need to provide a bit of context. First, keep in mind that we are focusing on larger organizations with dedicated incident response resources. Practically speaking, this probably means at least a few thousand employees and a dedicated IT security staff. Smaller organizations should still glean insight from this series, but probably don’t have resources to implement the recommendations. Second, these issues and recommendations are based on discussions with real incident response teams. Not everyone has the same issues – especially across large organizations – nor the same strengths. So don’t get upset when we start pointing out problems or making recommendations that don’t apply to you – as with any research, we generalize to address a broad audience. Across the organizations we talk with, some common incident response gaps emerge: Too much reliance on prevention at the expense of monitoring and response. We still find even large organizations that rely too heavily on their defensive security tools rather than balancing prevention with monitoring and detection. This imbalance of resources leads to gaps in the monitoring and alerting infrastructure, with inadequate resources for response. All organizations are eventually breached, and targeted organizations always have some kind of attacker presence. Always. Too much of the wrong kinds of information too early in the process. While you do need extensive auditing, logging, and monitoring data, you can’t use every feed and alert to kick off your process or in the initial investigation. And to expect that you can correlate all of these disparate data sources as an ongoing practice is ludicrous. Effective prioritization and filtering is key. Too little of the right kinds of information too early (or late) in the process. You shouldn’t have to jump right from an alert into manually crawling log files. By the same token, after you’ve handled the initial incident you shouldn’t need to rely exclusively on SIEM for your forensics investigation and root cause analysis. This again goes back to filtering and prioritization, along with sufficient collection. This also requires two levels of collection for your key device types – the first being what you can do continuously. The second is the much more detailed information you need to pinpoint root cause or perform post-mortem analysis. Poor alert filtering and prioritization. We constantly talk about false positives because those are the most visible, but the problem is less that an alert triggered, and more determining its importance in context. This ties directly to the previous two gaps, and requires finding the right balance between alerting, continuing collection of information for initial response, and gathering more granular information for after-action investigation. Poorly structured escalation options. One of the most important concepts in incident response is the capability to smoothly escalate incidents to the right resources. Your incident response process and organizations must take this into account. You just can’t effectively escalate with a flat response structure; tiering based on multiple factors such as geography and expertise is key. And this process must be determined well in advance of any incident. Escalation failure during response is a serious problem. Response whack-a-mole. Responding without the necessary insight and intelligence leads to an ongoing battle where the organization is always one step behind the attacker. While you can’t wait for full forensic investigations before clamping down on an incident to contain the damage, you need enough information to make informed and coordinated decisions that really stop the attack – not merely a symptom. So balancing hair-trigger response with analysis/paralysis is critical to ensure you minimize damage and potential data loss. *Your goal in incident response is to detect and contain attacks as quickly as possible – limiting the damage by constraining the window within the attacker operates.** To pull this off you need an effective process with graceful escalation to the right resources, to collect the right amount of the right kinds of information to streamline your process, to do ongoing analysis to identify problems earlier, and to coordinate your response to kill the threat instead of just a symptom. But all too often we see flat response structures, too much of the wrong information early in the process with too little of the right information late in the process, and a lack of coordination and focus that allow the bad guys to operate with near impunity once they establish their first beachhead. And let’s be clear, they have a beachhead. Whether you know about it is another matter. In our next couple posts Mike will start talking about what information to collect and how to define and manage your triggers for alerts. Then I’ll close out by talking about escalation, investigations, and intelligently kicking the bad guys out. Share: