Research

Ah, the silly season of predictions. Rothman has a round up of the early entries, and I’ll have more to say on that particular subject in my monthly Dark Reading column (should be up next week). Stiennon was a little different this year- he blogged his methodology, took a few days off to ruminate, then blogged the results of his analysis. Chris Hoff described his methods to me over IM (it involves Guiness, a keyboard, and about an hour), and came to very similar results. Me? I’ve been spending a lot of time talking to clients (mostly on the vendor and investment side) about various data security markets and predicted growth rates. There’s been a ton of acquisition activity in the areas I spend most of my time on and I’m being frequently asked to predict the next “hot” market. I guess with the RSA conference delayed until April people are getting a little impatient. I won’t be making any predictions today, but like Stiennon it never hurts to share my secret sauce for making educated guesses. When I look at security markets I generally divide them into three categories which tend to correlate to hype, adoption, and investment trends. Threat/Response: These markets are driven by a rapid rise in a threat that demands an immediate response in order to effectively continue to engage in business. A jump in worm activity (around Code Red) drove firewall investments. Viruses like Melissa and LoveLetter forced wide adoption of enterprise antivirus. Huge jumps in spam forced a dramatic increase in antispam. And so on. In each case, the threat increased at a rapid enough pace to disrupt normal business operations, forcing a response. These are the markets that creep along, then suddenly explode, resulting in big numbers and year over year revenue increases in the hundreds of percent. Compliance Driven: In compliance markets the threat driving investment isn’t one of external attack, but of regulatory fines, disrupted business operations due to an inability to meet industry standards, or fears of material negative public perception due to press related to an inability to meet a standard (e.g. HIPAA). Compliance rarely, if ever, drives the same adoption rates as threat/response since daily business operations aren’t disrupted, but these markets see steady growth with increases ranging from 75% to over 100% year over year. Examples include Data Loss Prevention, Security Information and Event Management, Identity Management, and Database Activity Monitoring. More rapid growth rates are tied to solutions for problems leading to audit or compliance failures, then followed by solutions that reduce the cost of compliance, then followed by solutions that are only sometimes required for compliance or otherwise not explicitly required (like DLP). Internally Motivated: These are tools we buy to improve security, which aren’t demanded by an immediate external force. They often address threats that don’t necessarily disrupt daily business operations but often result in higher losses when they hit. The bad news is these are often the most important tools for improving security and preventing material losses, but since those incidents aren’t as “in your face” as spam or loss of services, the adoption rate is much lower. This is, of course, only part of the market evaluation process. The real trick is to predict when these market drivers will hit and markets will switch to the next (or previous) category. But if I gave everything away, no one would hire me, I’d end up just a full time blogger, and I’d have to move in with my Mom and learn to speak Klingon. Share:

I was amused to get this in the mail today. Since I’m not a total bastard, I’ve removed the header and sender’s name. From: xxxxxxx@dimacc.com Subject: Seeking an ad on your windows security page Date: December 6, 2007 2:45:09 PM GMT-07:00 To: rmogull@securosis.com Thanks for your great page on OSX vs. windows security over at http://securosis.com/2006/11/20/mac-vs-windows-security-its-a-whole-new-game-and-doesnt-matter/. I think you’ve built a great security resource and I am writing to ask if I could buy a text ad on that page for a security website. I can pay 35 dollars for the ad. Do you do paypal? Cheers, xxxxxxxxxx xxxxxxxxxx Wow. A whole $35!!!! That could like pay for almost like a few months of my web hosting!!! I could, like, buy 1/3 of a nice dinner for a girl!!!!Maybe even my wife!!!! Looking up their site I find the following: David Robertson CEO and Founder When only the best will do, DIMACC is here for you! Specializing in Website Advertising As you may already have guessed, we’re in the marketing business. The company’s founder and CEO, David Robertson, is a 1989 Harvard graduate. While attending Harvard University working towards his MBA, a class project made Dave realize what his life calling was – Advertising. He was required to set up a mock business detailing every aspect including plans to make and keep it a success. He chose to create an advertising company for his project and enjoyed it so much that he wanted to pursue it in real life. Five years later, in Maplewood, Minnesota, this dream became a reality when DIMACC took on its first client. The company’s main goal, which remains #1 today, was to do anything and everything for the client so they get the results they are after. The advertising business can be a cut-throat and hectic business to get into, but with the knowledge and experience found at DIMACC mixed with the positive atmosphere found in the work environment, it’s no wonder this company has become such a success. Well darn, Harvard! I’m impressed. What a success! They should be so proud!!!! Oh well, it’s still better than Facebook’s Beacon garbage. Share:

This is just awesome. The MPAA illegally used GPL licensed code in their University Toolkit (the license required release of the source code for any derivatives). They refused to respond to requests to comply with the license, and a developer issued a DMCA takedown notice to the MPAA’s internet service provider, who shut down the site. Share:

Adrian Lane, frequent commenter on this blog, wrote about the desire for real case studies of breaches. I’ve been spending a lot of time digging through breach statistics and all the public information on some major breaches in order to come as close as possible to root cause analysis. While I love the Attrition database and the Privacy Rights Clearing House, they are only able to enter what little data makes it into the public light. It makes for a nice Star Wars spoof, and is absolutely helpful, but it’s time we took it to the next step. In order to make really intelligent decisions on how to protect ourselves we need to perform root cause analysis on real world breaches. I’ve done the best I can on this, and have a fairly decent presentation on it, but there are serious limitations when relying on nothing but press reports, which is pretty much all we have. I’m in discussions with a very trusted organization about potentially running a detailed survey focused on how breaches really occur. The goal is to provide the community with hard data on where the bad guys are succeeding, where they are failing, what defenses work, and what defenses don’t. Real root cause analysis, on a statistically significant scale. I’m not going to ask if you think this would be useful- we all know the answer. What I’m going to ask is if you would be willing to participate. One potential poll format is an open, anonymous survey. The next option is an invitation survey (thus we’ll know you participated) but where your answers are totally anonymous. Next is participating in a focused study with interviews, but without releasing who you are or what organization you work for. The final option is a public case study (and only answer if you think the lawyers will sign off, and we know they won’t). These results will help us design our model and how to approach the security community. We all know the bad guys share techniques and information (even if it’s stupid bragging w1th a l0t 0f w31rd wr1t1ng); now it’s our turn to take charge and figure out what works. This isn’t just a random blog poll; your answers could affect a major research project. Updated : There’s a bug in the polling software when I embed it in a post, so please vote over on the sidebar until I figure it out. Share:

Today, in cooperation with SANS, Securosis is releasing Understanding and Selecting a Data Loss Prevention Solution. This is a compilation of my 7 part series on DLP, fully edited with expanded content, just like one of those DVD boxed sets! The paper is sponsored by Websense, but all content was developed independently by me and reviewed by SANS. It is available here, and will soon be available in the SANS Reading Room or directly from Websebse. It was a fair bit of work and I hope you like it. The content is copyrighted under a Creative Commons license, so feel free to share it and even cut out any helpful bits and pieces as long as you attribute the source. As always, questions, comments, and complaints are welcome… Share:

On Monday I’m giving a presentation on data breaches at the SANS Encryption Summit (only a couple of hours after I keynote the DLP Summit). I decided to have a little fun, and created a Star Wars opening crawl listing every public data breach in the Attrition.org database since 2000. Needless to say, it gets a little more crowded after 2005 (when people started reporting under California S.B. 1386, even though it went into effect in July of 2003). It’s over 6 minutes long, which even George Lucas wouldn’t subject an audience to. And if you’re down at the event, drop me a line… Share:

I was talking with someone recently who rolled out whole-disk encryption to meet a compliance need. Someone told them they needed to encrypt, so they encrypted. They do, of course, automatically log in users so they don’t have to enter their passwords. I asked, “Isn’t password authentication, never mind strong authentication, also a compliance requirement?” “Oh yeah, it is. They all get passwords, they just don’t have to type them in themselves. Someone went down the list for compliance and checked all the boxes, but if you open a PC and turn it on it boots right up and you don’t have to log in. There wasn’t a checkbox for that.” Classic. Simply classic. Share:

Yesterday I published a quick TidBITS article on the QuickTime RTSP vulnerability. It’s a true 0day, with exploit code in the wild and no patch available. At the time, the proof of concept code was only for Windows, but over at Milw0rm it’s been updated to include Macs. The original CERT advisory is here. Windows users can follow the CERT advice to disable QT, but us Macheads don’t have it so easy. My recommendation right now is to watch where you browse, and use Little Snitch or another outbound firewall with application awareness (just blocking port 554 and the UDP ports isn’t enough). I suspect we’ll have a patch soon. This is a great example of why Apple should finish off the new security features of Leopard. I suspect that the combination of QuickTime sandboxing, full ASLR (Library Randomization), and adding outbound blocking to the Application Firewall could stop this exploit before it starts. Anti-exploitation is the future. We’ll always have vulnerabilities, but we can sure make them harder to exploit. Share:

Iron Mountain has lost their fair share of backup tapes over the years. Enough to end up in the headlines more than once, but it hasn’t seemed to affect their business. Heck, they even issued a press release calling for their clients (and everyone else) to encrypt their tapes. According to this article (picked up via SANS NewsBites), after another tape loss leading to a public disclosure the State of Louisiana is switching to an alternate provider and may sue Iron Mountain. Look, we all know mistakes happen and tapes will fall off the backs of trucks. Even in New Jersey. But in cases like this one there is clearly shared responsibility. I’ve heard Iron Mountain isn’t always as diligent about handling tapes as they should be. When you have hundreds, maybe thousands, of trucks roaming the country not every driver will stick to the standard. On the other hand, if you’re playing with Social Security or credit card numbers, and you aren’t encrypting, you’d better make darn sure you have some other risk mitigation in place. Did the Louisiana Student Financial Assistance Commission evaluate and audit Iron Mountain’s procedures? Did they consider the risk of a lost tape? Did they have Service Level Agreements guaranteeing no lost tapes? Iron Mountain clearly has some responsibility, but I suspect there’s nothing in the contract to allow their customers remediation. On the other hand, their customers need to recognize that despite the marketing, Iron Mountain will lose a certain percentage of their tapes. My recommendation is if you’re handling data that, if lost, will land you in the headlines, you need to encrypt it or keep it off the tapes. I get asked a lot about all those tapes in archives, and I think diligent asset management is more realistic than trying to encrypt everything already locked away. If you can’t afford encryption or to change your practices, understand you are implicitly accepting a level of risk. Even if you find someone willing to guarantee you they’ll never lose a tape, when they do it will be your company’s name in the headline and theirs in the second paragraph. Share:

I’ve been a little slow on blogging due to a couple of killer deadlines, but things should be getting back to normal here over the next few days. Much to my surprise, this independent consulting thing is actually working out! This week on the NetSec Podcast, Martin and I asked my old co-worker, Amrit Williams, to join us. Amrit is the CTO of BigFix and blogs over at TechBuddha. It was more an informal discussion on a Saturday morning among a bunch of security geeks than a formal interview, and we took a bit of a holiday flavor with it. As always, full show notes and comments are over at NetSecPodcast.com. Show Notes: The Best Gift for Non-Geeks that isn’t on their list MPAA University ‘Toolkit’ raises privacy concerns – You better believe it does! UK Government in uproar following data loss Network Security Podcast, Episode 85 Time: 46:59 Share: