Research

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:

Back in April I published a slightly different take on DLP: Low Hanging Fruit: Quick Wins with Data Loss Prevention. It was all about getting immediate value out of DLP while setting yourself up for a full deployment. On Wednesday at 11:30am EST I’ll be giving a free presentation on that material. If you’re interested, you can register at the Business of Information Security site. Share:

Over the weekend I glanced at Twitter and saw a bit of hand-wringing inspired by something going on at (I think) the Baythreat in California. This is something that’s been popping up quite a bit on Twitter and in blog posts for a while now. The core of the comments centered on the problem of educating the unwashed security masses, combined with the problems induced by a compliance mentality, and the general “they don’t understand” and “security is failing” memes. (Keep in mind I’m referring to a bunch of comments over a period of time, and not pointing fingers because I’m over-generalizing). My response? You can probably figure it out from the title of this post. I long ago stopped worrying about the big picture. I accepted that some people understand security, some don’t, and we all suffer from deformation professionnelle (a cognitive bias: losing the broader perspective due to our occupation). In any risk management profession it’s hard to temper our daily exposure to the worst of the worst with the attitudes and actions of those with other priorities. I went through a lot of similar hand-wringing first in my physical security days, and then with my rescue work. Ask any cop or firefighter and you’ll see the same tendencies. We need to keep in mind that others won’t always share our priorities, no matter how much we explain them, and no matter how well we “speak in the language of business”. The reality is that unless someone suffers noticeable pain or massive fear, human nature will limit how they prioritize risk. And even when they do get hit, the changes in thought from the experience fade over time. Our job is to keep slogging through; doing our best to educate as we optimize the resources at our disposal and stay prepared to sweep in when something bad happens and clean up the mess. Which we will then probably be blamed for. Thankless? Only if you want to look at it that way. Does it mean we should give up? No, but also don’t expect human nature to change. If you can’t accept this, all you will do is burn yourself out until you end up as an alcoholic passed out behind a dumpster, naked, with your keys up your a**. Fight the good fight. But only if you can still sleep well at night. Share:

It’s been about 11 months since the first time I ever spoke with Joshua Corman. He had this idea for a Rugged Software movement and wanted some feedback. After he filled me in on the concept, I told him I thought it was a good idea, and told him I was in. A few weeks later the Rugged Manifesto was published. There were a flurry of blog posts, and a bunch of email discussions, which ended February this year. Since then, I have heard … crickets. New stuff on RuggedSoftware.org? No. OWASP? Nada. Twitter? Presentations? Chat groups? Pretty much not a damned thing. So what’s up, guys? Where is the movement? What problems have been solved? Don’t ask what is missing from software security; ask what’s missing from Rugged! Josh, David, and Jeff … I am calling you out! When the Agile Manifesto was originally published, there were a lot of frustrated software engineers who had specific problems, gripes, and issues that they wanted to address. They did not necessarily have the right answers, nor did they know what tools and techniques would work (either for themselves or for others), but they identified specific problems to address (lack of planning, fear, outside influencers, periodic validation, people’s inability to estimate, etc.), and had a bunch of stuff in their bag of tricks (peer programming, task cards, stories, test driven development, etc.). The Rugged Software movement has some of the same ingredients: a bunch of frustrated security professionals want code to be secure. And many very public security failures illustrate the need. And we have the same piss-poor failure analysis and finger-pointing that looks very familiar as well. But I don’t think we have adequately identified the problems that contribute to insecure code, and we definitely don’t have a bag of tricks ready to go. If you look closely at Agile techniques, most are actually process changes, without much to do with actual code. The processes were designed to address issues of complexity and lack of metrics, and to minimize negative human interaction. Do we have a similar set of guidance for Rugged? Nope. What’s missing? At this stage, at least three things: Clear, concise, no-BS descriptions of the problems that lead to insecure code. Some simple techniques, tricks, and ideas to help people get around these problems. Some people to help get this rolling. I am not trying to shove all this onto the backs of the three gents who started this movement. They need help. I want to help. And I know that there are many security pros and coders who will help as well. And I really don’t want to see another year of inactivity on this (sorry) ‘non-movement’. Ultimately I think Rugged is the right idea. But just like 11 months ago, there is a concept without direction. We don’t need a complete roadmap – early extreme programming sure wasn’t complete – but we do need to start moving the effort forward with some basics ways to solve problems. I push. You push back. Or not. Your call. Share:

The Securosis team is here in San Francisco, meeting with vendors and presenting at the TechTarget Data Protection event. Weather has been reasonable and the food was awesome. But since it’s been going non-stop since something like 3:00am to (What is it now? 11:01pm) – this summary will be a short one. I got to talk to a lot of people today. The common questions I get when meeting with vendors are, “What are you seeing? What are you hearing? What are the new technologies?” I had to stop and think about that last one for a minute. I am not really seeing any new technologies or innovation. I am seeing lots of platforms consolidating multiple technologies under a single umbrella. I am seeing configuration and vulnerability assessment vendors redefine their spaces, seeing web application security vendors bundle their products in different ways, hearing more interest in how to develop secure code, witnessing DAM go from misunderstood platform to well regarded feature, hearing lots of interest in taking advantage of fast and cheap cloud resources, and getting even more questions about what cloud security actually means. But new technologies? Not really. Yet this is one of the most interesting times in security that I have seen in the 15 years since I started working in the field. APT, Stuxnet, skimming, money mules, spam kings, and hacktivism all together make for fascinating reading. And there are tons of really good software conferences around the world with lots of great presentations. But not a lot of problems that we don’t have some solutions for. Have we reached a point where the flood of innovation has created enough tools, and now we just need to use them properly? On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s paper on Oracle database security. (PDF; registration required). Adrian’s article on Database Password Crackers. Rich speaking at the Cloud Security Alliance Congress next week. I’m co-presenting with Hoff again, and premiering my new Quantum Datum pitch on information-centric security for cloud computing. Haven’t been this excited to present new content in a long time. Favorite Securosis Posts David Mortman: Where Are We? Nowhereville.. Mike Rothman: My 2011 Security Predictions. Rich is so funny. Especially lampooning this ridiculous season of predictions. Adrian Lane: What Amazon AWS’s PCI Compliance Means to You. Rich Mogull: Edge Tokenization. Other Securosis Posts Adrian Speaking at NRF in January. Infrastructure Security Research Agenda 2011 – Part 1: Positivity. Incite 12/8/2010: the Nutcracker. RIP Marty Martian. React Faster and Better: Introduction. Incident Response Fundamentals: Index of Posts. What Quantum Mechanics Teaches Us about Data Leaks. Favorite Outside Posts Mike Rothman: Shearing Firesheep with the cloud. Great step by step tutorial for building an OpenVPN server in Amazon AWS. Literally anyone can do this. Even me! David Mortman: Unpeeling the mystique of tamper-indicating seals. Coincidentally, Defcon now has a tamper-evident seal contest….. Adrian Lane: Comment Induced Follow-up post. The comments are the post. Rich: One Click Application Security – How did we get here? Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. NSO Quant: Manage Metrics–Process Change Request and Test/Approve. Research Reports and Presentations The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. Top News and Posts Basics of History Sniffing. JavaSnoop Analysis Tool Released. Amazon Receipt Generator Scam. Cloud Vulnerability Scanner Launched. Cloud WAF launched. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Daniel, in response to My 2011 Security Predictions. 15 The Hoffachino becomes an official Starbucks drink and secures their public wireless by it’s pure awesomeness Yeah, there are that awesome! Share:

Someone will predict a big cyberattack someplace that may or may not happen. Someone will predict a big SCADA attack/failure someplace that probably won’t happen, but I suppose it’s still possible. Someone will predict that Apple will do something big that enterprises won’t adopt, but then they will. Someone will predict some tech will die, which is usually when a lot of people will buy it. Most people will renew every security product currently in their environment no matter how well they works (or don’t). Someone will predict that this time it’s really the year mobile attacks happen and steal everyone’s money and nekked photos off their phones. But it probably won’t happen, and if it does the press headlines will all talk about ‘iPhone’ even if it only affects Motorola StarTACs. Vendors will scare customers into thinking 20 new regulations are right around the corner – all of which require their products. There will be a lot of predictions with the words “social networking”, “2.0”, “consumerization”, “Justin Bieber”, and whatever else is trending on Twitter the day they write the predictions. Any time there’s a major global event or disaster, I will receive at least 8 press releases from vendors claiming bad guys are using it for spam/phishing. Some botnet will be the biggest. And a bonus: #11. The Securosis Disaster Recovery Breakfast at RSA will totally rock. I miss anything? Update – 12. Someone will predict cloud computing will cause/fix all these other problems (via @pwrcycle) 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