Research

It’s Wednesday, and if my doctor’s predictions are correct I might be in front of the keyboard for an hour at a time today. Odds are I’m now in a recliner, watching bad TV, staring wistfully at my Guitar Hero Les Paul leaning against the entertainment center. You may think you’ve won Slash, but once my recovery is complete I’ll be more powerful than you can possibly imagine. And I’m not even on the meds yet. Yesterday Mike and I talked about his 2008 predictions around network security. Today we’ll talk about my favorite area, information-centric security, and educating consumers. This brings us to another step-child of the security world, Data Loss Prevention (DLP). You’re predicting a stall, although I’d argue it’s been stalled for years with only about $70M in revenue in 2007. What’s your unva ished opinion of DLP- do you think it provides value other than preventing those accidental emails? What if we include content discovery? You could probably make a case that the DLP business never even got started. The fact is it had the law of small numbers working in its favor. The entire market could grow at 80-100% when it was small. Now it’s a bit bigger and it’ll be a lot harder to show accelerating growth. Also combine that with the number of deals we saw last year and the fact that it does take time for small nimble start-ups to find their sea legs in the morass of a big security or storage player, and things look pretty dark for DLP in 2008. Your second question is a bit more interesting. I do believe that there is value in the promise of DLP. We need to start thinking about the data and how it’s used and where it goes. I just don’t think the current deployment models really reflect the answer to the customer problem. Sure, if you are worried about an account number or a SS# being sent out, the existing products work fine. But they don’t give you persistent control of your data assets, and I think that’s really the problem that customers need to address. Unfortunately this may be the biggest problem in all of IT. There are no simple answers to solve that one. DLP is one of the few tools that focus on data security, or “information-centric” security, depending on who you talk to. You do predict greater focus on database security in 2008, but what’s your opinion for the long haul? Will we migrate away from networks and hosts as the focus of security? Or is there too much momentum with too many big companies tied to our current model to expect changes anytime within the next 3-5 years? Database security is a feature. If the databases weren’t so security tone-deaf, there wouldn’t be a need for this technology at all. But they are, so there is. Over time, a portion of the functions get subsumed into the DBMS, a portion into the security management platform (log analysis and monitoring) and some into the network (intelligently blocking direct database attacks). Though that is truly a long term vision. 5-7 years, best case. The existing database security market has a lot of running room as these other things fall into place. I don’t think we’ll ever be able to neglect network and host security. A layered security model is really the only way to protect yourself from attacks we can’t even envision. That being said, we need to do a lot better job securing the data. The fundamental element of data, in terms of how it’s used and where it goes. As I mentioned before, that is a really big problem. Looking at the database traffic is a start. It’s not the long term answer, but it adds another layer of protection. Last year you published the Pragmatic CSO. I think one thing that’s always made you stand out as an analyst is this focus on practicalities. I find myself recommending the book to someone almost weekly since there are so few just-get-it-done approaches to security. Why do you think we make our lives so much more complicated than they need to be, and what inspired you to finally write the P-CSO? I wrote the P-CSO because I was frustrated. Security folks just don’t understand basic business realities and practices and it is hurting them. They can’t relay the value of what security does and they don’t understand how to play the game to get things done. If anything, I’ve screwed up a lot of things in business and I thought I could provide some perspective that someone who spent their entire career managing firewall rules could appreciate. Especially as they are about to get in front of the Board of Directors and tell them why they aren’t going to be the next TJX. That’s the thing about the P-CSO. It’s not a technology book. It’s a philosophy book. How security professionals need to think about the business of security moving forward. I really believe it’s the difference between success and failure. You’re trying to do something similar for consumers with Security Mike; how’s that project going? Security Mike is going well, but I haven’t put the cycles behind it that it deserves. I’ll be spending a lot more time with that project throughout this year. Security Mike is a big idea. If we can train the consumers out there to protect themselves more effectively, we cut off the oxygen that the hackers breathe. Yes, that’s a long term goal, but you have to start somewhere. The first hundred, then the next thousand, then ten thousand. If we can remove the low hanging fruit, the economic model of Internet fraud changes. The bad guys need to work a lot harder to make the same income. That’s the vision. Thanks a lot for your time today. One last question, is it true someone sent you a holiday card addressed to “Mike Rothman and The Boss”? How did THAT

Right now I’m probably lying in bed with some weird motorized ice pack strapped to my shoulder, and (hopefully) some pain meds running amok in my system. I suspect most of you are a little more comfortable at the moment, but hopefully on fewer drugs. Before diving under the knife, Mike Rothman agreed to an email interview. I’ve known Mike for something like 5-6 years now (I think). If you read this blog, the odds are pretty darn high you also read Mike’s Security Incite. It’s the best nearly-daily analysis of what’s going on in the security world. Rather than providing a simple list of links, Mike includes his own analysis on 3-4 news stories and 3-4 blog entries a day. Mike is also author of the Pragmatic CSO– a must-read for every aspiring security manager. He’s also the crazy SOB that convinced me you can make it as an independent, so I might be a little biased in his favor. Here’s the first half of the interview, and we’ll finish it off tomorrow… Thanks for joining me today, Mike, especially since it’s actually a week before today, and right now I’m probably drugged up with my arm in a sling, sitting on the couch watching Knight Rider. Who knew that the Rich Mogull has a time machine? If you patented that you really would be a Mogull. Anyhow, I hope you are feeling better and on your way to a speedy recovery. [It seems Mike doesn’t realize Knight Rider is coming back. What’s old is new, Mike.] Rather than having you talk about your past, I’d rather use this time to talk about some of your predictions for the future. Every year you publish your “Security Incites”, a mixed bag of predictions for the coming year. Some of them seem very specific and measurable, while others are, shall we say, a little fluffier. Is there a method to the madness? In fact there is. I’m constantly synthesizing information. From everything I read, every question I get, every conversation I have. Through the year I am assessing and re-assessing my positions. I go back and revisit the Incites in July and December, and by February I have a pretty good idea how they should evolve for the next year. Then I sit in a dark room, meditate for a while, and the Incites just come to me. The reality is that some of the Incites lend themselves to firm, quantifiable predictions and others not so much. Some I use to make a specific point that I think is important. Let’s talk about a few of the predictions that really stand out (for me at least). You’re predicting that 2008 will be the year network security crosses the line and finally becomes just part of the network fabric. A lot of pundits have been predicting this one for years now- what’s going to make 2008 so special? I believe that customers are voting with their dollars. They don’t want overlay solutions for network security anymore. They want their networking provider to get it right, and with the macro-economic headwinds a lot of folks expect, these customers are in no rush to roll out the technology. They have been willing to wait thus far and sooner or later the products from Big Networkers won’t totally suck. If anything, those folks are persistent and they throw a ton of money at it. They will get it right and I think 2008 is the year the security capabilities built into switches are good enough to meet most of the customer requirement. In that same prediction you bring up Network Access Control, the red headed step-child of network security. You’ve been one of the more lukewarm voices on NAC; is it a failure of the technology? Or just the market reality that big vendors see this as a way for greater lock in? To be clear, I don’t have anything against red-heads. 🙂 NAC’s issues in the market stem from two issues. First, it doesn’t solve a problem that customers think is important or urgent enough to solve. The big NAC vendors are talking about having maybe 1500 customers or something like that. And they are probably lying about that. Let’s take a market like anti-spam – which was a REAL problem – Barracuda sold to 30,000 companies in two years. If it was that big of a problem, more customers would be buying the solutions. It’s as simple as that. The second issue has to do with expectations. The NAC vendors did themselves a huge disservice by promising the world to customers. They set an expectation they couldn’t possibly meet and now you’ve got customers that are disappointed and they are telling their friends to hold off until the technology matures. Who knows when that is going to happen? So, will any NAC vendors survive on their own over the next, say, 3 years? The NAC business will suffer a severe shake-out. Quite a few will get bought, with maybe the first 1 or 2 selling for a big multiple. And no, I don’t know which 1 or 2 that will be. We will see a lot more like Caymas, just going away. Or Vernier, which got out of the NAC business altogether. That’s life in the big city. Come back tomorrow to hear Mike’s views on DLP, consumer security, and holiday card pranks. Share:

This is very amusing. Everything you need to know about negotiating with Microsoft for $44B. I’m off for the weekend and in surgery on Monday (a minor shoulder thing). I have some guests on the site next week and some other surprises to keep the content running. Have a great weekend… Share:

A strange thing happened Tuesday night. Martin and I logged into Skype for our regular podcast recording session and we noticed two different, but familiar, voices on the line babbling about being Still Secure After All These Years. Yes folks, we combined SSAATY and the Network Security Podcast. I couldn’t tell if Alan and Mitchell crashed our party, or if we crashed theirs, not that it matters. We spent a fair amount of time talking about the privacy issues related to Facebook and other online sites. From employment issues to the political process, it’s clear that having your… youthful indiscretions saved for posterity on a search engine may cause some changes in how society views these things. We also discussed HP’s ridiculous claim that they employ 9 of the world’s 11 best hackers, and talked about the new Adobe exploits. Overall a fun time for all, and sorry about some of the audio issues. These 4 way calls are always a little more challenging. As always, the episode is available at netsecpodcast.com. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Network Security Podcast Share:

I have a moderately complex network at home, with multiple WiFi base stations (running at 5 GHz and 2.4 GHz), a hacked WRT54G gateway router for firewall/VPN, and a couple of AirPort Express units for music streaming. Starting a couple of weeks ago I started having all sorts of erratic behavior with the AirPorts, which was extremely annoying since I was trying to evaluate Airfoil, an audio streaming application, for TidBITS. Lost connections, disappearing access points, and other nonsense. It hit the point yesterday afternoon where I reconfigured my entire network, yanked out the VPN, and, in the process, killed everything. Waking up with a little 4 am insomnia I tries a quick fix I’d forgotten about- changing WiFi channels. A couple of years ago I had similar problems and after doing a site survey with Kismet I realized my access point was on the same channel as a neighbor. This time I skipped Kismet and just swapped channels on my 2.4 GHz (802.11g) access point. All is good. I’m going to bed now. One of our new neighbors must have been on channel 8, and everything is happily connected on channel 7 now. If you find yourself dropping connections or having other weirdness, just go into your access point configuration panel and hard code different channels until things start working better. < p style=”text-align:right;font-size:10px;”>Technorati Tags: WiFi Share:

I normally make fun of predictions, but two sets issued this week are well worth the reading. The first come from Mike Rothman, who just issued his 2008 Security Incites. Mike mixes in both technical and general market trends. Some predictions are clearly measurable, and others are there just to make a point. Mike covers everything from metrics and audits, to NAC and DLP. On the other side are the more-technical predictions by Nate Lawson and Thomas Ptacek. These two researcher powerhouses range from digital watermarking and DRM, to NAC and new vulnerability classes. And let’s not forget Hoff’s double–sized predictions, and Stiennon’s. These aren’t the kinds of things will will drive your security spending (unless they come true), and plenty of predictions overlap or contradict each other. But the point is to get you thinking about the year to come, especially as you make tactical decisions. My predictions? I don’t really play that game, but if you aren’t looking towards better ways to protect yourself from web application attacks and clientside vulnerabilities, you’ll probably have a bad year. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Mike Rothman, Nate Lawson, Security Predictions, Thomas Ptacek Share:

Database encryption is like a home repair project- either it’s really easy and goes exactly as planned, or about five minutes in you realize you might not want to make any weekend plans for the next 2-3 years, and perhaps you should take a trip to the flower store before trying to explain why your family will be living with exposed wall studs and dangling wires for a while. Database encryption (and encryption in general) was one of the first technologies I covered when I first became an analyst. Early on I realized something didn’t smell right; I had vendors talking about using encryption to prevent attacks and to “enhance” access controls. But their products were completely linked to access controls, which didn’t really add any value. Also, most attacks against databases involve compromising user accounts or running queries within the privileges of the user, so how would encryption add any value? Encryption doesn’t do a darn thing against many SQL injection attacks or abuse by authorized users. This led to a lot of introspection and the eventual development of the Three Laws of Data Encryption. We can thus divide database encryption into two categories: Encryption for Separation of Duties: In this case we will almost always use encryption to protect against our own administrators or other privileged user access, since we can more easily and efficiently use access controls for everyone else. The example is encryption of credit card numbers, with the keys stored outside of the database, to allow stored numbers for credit card processing but to eliminate the possibility of administrators or users accessing the numbers. Encryption for Media Protection: Here we encrypt database objects (tables/columns), database files, or storage media to prevent exposure of information due to physical loss of the media. As you can imagine, encrypting for media protection is much easier than encryption for separation of duties, but it clearly doesn’t offer the same security benefits. Thus, the first thing we need to decide when looking at database encryption is what are we trying to protect against? If we’re just going after the PCI checkbox or are worried about losing data from swapping out hard drives, someone stealing the files off the server, or misplacing backup tapes, then encryption for media protection is our answer. I’ll discuss it more in a future post, but it’s a fairly straightforward process with manageable performance implications. If we want to encrypt for separation of duties, then life gets a little more complicated. Databases are complex beasts; far more complex than most people give them credit for. Just go try and teach yourself relational calculus or indexing. They like structured data, and once we start mucking with that by randomizing our data through encryption we start messing with performance. That’s not even counting the normal performance impact of encryption itself. As with encryption for media protection I’ll talk more specifically about encryption for separation of duties in future posts, but as a general rule of thumb it’s not overly difficult to build encryption into a new database, but if you are encrypting a legacy database accessed by applications (legacy or otherwise) you are sometimes looking at a 2-3 year project due to the required database and application changes. We run into problems with indices, range searches, referential integrity, application integration, connection pooling, key management, and … well, there’s a lot to talk about here. To close this post out, the first thing to look at when considering database encryption is what threat you are trying to protect against. If it’s loss of the database files and media, look towards media protection. If you want to limit regular user access, look to access controls or other internal database security features. If it’s separation of duties for discrete data (again, we’ll talk more later) then consider column/field encryption, and make sure you can store the keys outside of the database. As you’ve probably figured out by now, this is one of those multiple-post series things I like to do. In the next one we’ll talk about encryption for media protection and why you might want to combine it with database activity monitoring. After that, I’ll dig into field (or other object) encryption for separation of duties, then we’ll close with more detailed recommendations and a discussion of key management. BTW- I’m going in for some minor shoulder surgery on Monday which will slow me down for a little while. I’ll have some guest posts for next week, and should be back up and running fairly soon. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Database encryption, Database Security, Encryption, Tutorial Share:

I’m sitting in a Starbucks in Vegas (on my EVDO card, not some risky open WiFi, of course) and nearly snort my coffee when I read the latest assault against reason by desperate vendors. (Via Slashdot, adding their own FUD). The title of the article is, “Encryption could make you more vulnerable, warn experts”. In short, a few vendors describe new “key management” attacks, where an attacker, should they steal the keys and lock you out, can hold your data hostage. However, experts from IBM Internet Security Systems, Juniper, nCipher and elsewhere said that data encryption also brings new risks, in particular via attacks – deliberate or accidental – on the key management infrastructure. … “Organizations experienced with encryption are standing back and saying this is potentially a nightmare. It is potentially bringing your business to a grinding halt.” Encryption is also as big an interest for the bad guys as the good guys, warned Anton Grashion, European security strategist for Juniper. “As soon as you let the cat out of the bag, they’ll be using it too,” he said. “For example, it looks like a great opportunity to start attacking key infrastructures.” “It’s a new class of DoS attack,” agreed Moulds. “If you can go in and revoke a key and then demand a ransom, it’s a fantastic way of attacking a business. Folks, I think we ALL agree that key management is important and needs to be secure. Does anyone see the need to create BS headlines about new kinds of attacks we’ve never once seen in practice? No? Not you in the back of the room? Good, I guess we’re all rational here. I realize we’ll never get rid of FUD in our industry and I use it myself from time to time, but if you’re so desperate you basically just make sh*t up, maybe you need to consider alternative marketing approaches. There are more than enough justifiable reasons to invest in appropriate key management. Josh Corman of IBM (full disclosure, I know Josh) offers a more reasonable risk: “One fear I have is that we’re all going to hide all our information, but companies are information-driven, so we take tactical decision and stifle ability to collaborate,” he said. Too bad he had to be quoted in this hack job. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Encryption, Key Management, FUD Share:

Email me. Share:

This week’s question comes from Rob, who works for a security vendor. It’s one that comes up a lot on both the vendor and the end user sides. I recall that sometime before Xmas you said that only certifications greater than EAL 5 were worth anything, and that you would write about that later. … Can a mickey mouse protection profile, or the TOE chosen effect the end value of the cert, in your opinion ? I’ll be honest, I’m not the biggest fan of Common Criteria. For those of you who don’t pay attention to these sorts of things, Common Criteria is an international standard to certify security products (or security features). Wikipedia has a reasonable entry for more details. More specifically, it is a standard for specifying and evaluating the security assurance of computer products and systems. It is a core part of the certification and accreditation process used by government agencies. I don’t want to get into the nitty gritty details of Common Criteria, but basically you certify products at one of 7 different Evaluation Assurance Levels (EAL 1-7), with 1 being “functionally tested”, and 7 being “formally verified design and tested”. To avoid any more acronyms, you basically document your security functions (usually against a common protection profile), and then certify to the degree your product meets those requirements. And there’s the rub. First, the system doesn’t evaluate the security of a product- it is a certification as to security features matching their documentation, at least at EAL 1-4. At those levels it’s pretty much, “here’s a list of features, and assurance, from an outside lab that charged us WAY too much money, that our features meet those requirements.” When you see EAL 4+ it usually means some more advanced criteria were pulled in as part of the evaluation. Many MANY EAL 4+ products are just as full of holes and bugs as anything else. The functions documented work as advertised, but that’s about it. That’s what Rob was asking about the protection profile and the TOE (Target of Evaluation; what part of the product is tested). With a weak protection profile and limited TOE you can still achieve high assurance, since the scope of the evaluation is limited. It’s the same beef I have with those worthless SAS70 evaluations. At EAL 5-7 life is more interesting, at least here in the US. The NSA gets involved at that point and you come closer to certifying the entire security of the product and the development process. Very cool, and very time consuming and expensive. Very few products certify at 5+ because of the cost. There are other problems with CC, including keeping a product certified as it changes over time. My advice? As an end user, unless you’re in government where this is mandated, ignore Common Criteria. Instead, ask your vendor for documentation of their security development process and what tools they use to test the code, or any independent lab evaluations as to the security of the product (vulnerability analysis and testing). CC is essentially meaningless to you if it’s under 5. As a vendor, if you want to sell to the government you’ll have to pony up for an evaluation. Keep it as low as you can to reduce costs, but if you want to play with classified agencies you’re looking at a minimum of 4+, and probably higher. I expect comments on this one will be either non-existent, or very interesting… < p style=”text-align:right;font-size:10px;”>Technorati Tags: Common Criteria Share: