Research

Major Update: I got a core fact incorrect, in a big way. Thanks to @ivanristic for catching it. It’s an obvious error and I wasn’t thinking things through. ECC is used at a different point than RC4 in establishing a connection, so this doesn’t necessarily affect the use of RC4. David Mortman seems to think it may be more about mobile support and speeding up SSL/TLS on smaller devices. My apologies, and I will leave the initial post up as a record of my error. In a rambling press release that buries far too much interesting stuff, Symantec announced the release of both ECC and DSA digital certificates for SSL/TLS. On the surface this looks like merely an attempt to speed things up with ECC, and hit government requirements for DSA, but that’s not the entire story. As some of you might remember, a total d*ck of a patent troll operating under the name of TQP Development has been suing everyone they can get their hands on for using the RC4 cipher in TLS/SSL. We know of small businesses, not merely big guys, getting hit with these suits. This is important because RC4 was the best way to get around certain attacks against SSL/TLS. Which brings us back to ECC. I wouldn’t bet my personal fortune on it, but I suspect it avoided both the security and legal issues in question. Pretty interesting, but I suppose the Symantec lawyers wouldn’t let them put that in a release. Share:

This morning, not even thinking about security, I popped off a tweet on cycling:   I have been annoyed lately, as I keep hearing people write off cycling while ignoring the fact that, despite all its flaws, cycling has a far more rigorous testing regimen than most other professional sports – especially American football and baseball. (Although baseball is taking some decent baby steps). Then I realized this does tie to security, especially in our very current age of selective information sharing. The perception is that cycling has more cheating because more cheaters are caught. Even in Lance’s day, when you really did have to cheat to compete, there was more testing than in many of today’s pro sports. Anyone with half a brain knows that cheating via drugs is rampant in under-monitored sports, but we like to pretend it is cleaner because players aren’t getting caught and going on Oprah. That is willful blindness. We often face the same issue in security, especially in data security. We don’t share much of the information we need to make appropriate risk decisions. We frequently don’t monitor what we need to, in order to really understand the scope of our problems. Sometimes it’s willful, sometimes it is simply cost and complexity. Sometimes it’s even zero-risk bias: we can’t use DLP because it would miss things, even though it would find more than we see today. But when if comes to information sharing I think security, especially over the past year or so, has started to move much more in the direction of addressing the known unknowns. Actually, not just security, but the rest of the businesses and organizations we work for. This is definitely happening in certain verticals, and is trickling down from there. It’s even happening in government, in a big way, and we may see some of the necessary structural changes for us to move into serious information sharing (more on that later). Admitting the problem is the first step. Collecting the data is the second, and implementing change is the third. For the first time in a long time I am hopeful that we are finally, seriously, headed down this long path. Share:

2012 was a tremendous year for cloud computing and cloud security, and we don’t expect anything slowdown in 2013. The best part is watching the discussion slowly march past the hype and into the operational realities of securing the cloud. It is still early days, but things are moving along steadily as adoption rates continue to chug along. On the downside, this steady movement is a total buzzkill when it comes to our tendency toward pithy deconstruction. Much of what you see on the show floor (and in all marketing materials for the next couple quarters) represent mere incremental advancements of the trends we identified last year. Cloudwashing is alive and well, the New Kids on the Cloud Security Block are still chugging along patiently waiting for the market to pop (though their investors may not be so patient), data security is still a problem for cloud computing, and ops is handling more security than you realize. What is old is new again. Again. SECaaS: Good for More Than Cheap Laughs We realize we sometimes push the edge of acceptable language during our presentations and blog posts, but nothing seems to garner a laugh better this year than saying ‘SECaaS’. The thing is, Security as a Service is maturing faster than security for cloud services, with some very interesting offerings hitting the market. Some security operations, including inbound email security, web filtering, and WAF, demonstrate clear advantages when implemented outside your perimeter and managed by someone else. You can provide better protection for mobile users and applications, reduce overhead, and keep the easily identified crud from ever hitting your network by embracing SECaaS. One of the most interesting aspects of SECaaS (we know, so juvenile!) is the far-reaching collection of security data across different organizations, and the ability to feed it into Big Data Analytics. Now that we’ve attained our goal of writing Big Data Analytics at least a few times each day, this isn’t all smoke and mirrors – especially for threat intelligence. Pretty much every anti-malware tool worth a darn today relies on cloud-based information sharing and analysis of some sort, along with most of the monitoring and blocking tools with cloud components. We will also touch on this tomorrow for endpoint security. We all know the limitations of sitting around and only getting to see what’s on your own network, but cloud providers can pull data from their entire customer base, so they get a chance to recognize the important bits and react faster. Admittedly, a few neighbors need to get shot before you can figure out who pulled the trigger and what the bullet looked like, but as long as it’s not you, the herd benefits, right? Other areas, such as network monitoring (including forensics), configuration management, and key management, all demonstrate creative uses for the cloud. The trick when looking at SECaaS providers is to focus on a few key characteristics to see if they are really cloud-based, and if they provide benefits over more traditional options. The first acid test is whether they are truly architected for multi-tenancy and security. Throwing some virtual appliances into a few colocation data centers and billing the service monthly isn’t quite good enough to make our personal SECaaS list. Also make sure you understand how they leverage the cloud to benefit you, the customer. Some things don’t make sense to move to the cloud – for example certain aspects of DLP work in the cloud but many others don’t. Will moving a particular function to the cloud make your life easier without reducing security? Skip the marketing folks and sales droids (wearing suits) and find the most anti-social-looking guy or girl you can in a scruffy logo shirt. That’s usually a developer or engineer – ask them what the service does and how it works. SecDevOps or SecByeBye DevOps refers to the operational model of increasing the communications and agility between operations and development to increase overall responsiveness and technology velocity. It relies heavily on cloud computing, agile/iterative development processes, automation, and team structures to reduce the friction normally associated with creating, managing, and updating software applications (internal or external). DevOps is growing quickly, especially in organizations leveraging cloud computing. It is the reason, for example, that many self-service private clouds start as tools for developers. DevOps is more than just another overhyped management trend. Cloud computing, especially IaaS and PaaS, with APIs to manage infrastructure, draw DevOps like a moth to flame. One benefit is that developers don’t need to ask IT ops to provision a server for a new project, and it is irresistible to many developers. If it reduces developer and operations overhead, what’s not to love? Oh, right. Security. Security has a reputation for slowing things down, and while at times that is the right approach, it is often the wrong one. For example, it just doesn’t work well if security has to manually update the firewall for every cloud instance a dev spins up for external testing. Fortunately DevOps also brings some security advantages, such as extensive use of automated configuration scripts and pre-set platforms and applications that can start from a secure state. But what does this all have to do with the RSA Conference? Keep an eye out for security options that tie into agile DevOps approaches if you are evaluating cloud security. These products will typically consume, and even deliver, APIs for automation and scripting. They rely on security policies more than manual operations. Frequently they tie directly into the leading cloud platforms, such as your private cloud or something up on Amazon, Rackspace, Microsoft Azure, or HP. When looking at security tools for cloud computing, definitely talk DevOps with reps on the show floor to see if the tool is as agile as what it’s protecting. Otherwise it’s deader than a red shirt on Walking Dead. (We like to mix analogies). And don’t forget to register for the Disaster Recovery Breakfast if you’ll be at the show on Thursday morning. Where else can you kick your hangover, start a new one, and

My very first Macworld op-ed: It’s hard to imagine an idea more inane than passwords. That we protect many of the most important aspects of our lives with little more than a short string of text is an extreme absurdity. These collections of–admit it–eight characters are the gateways to everything from our bank accounts and medical records to our family photos to the most sensitive thoughts we’ve ever let slip via keyboard. To say merely that I loathe passwords would be to lump them with myriad other things in this world that deserve of a good loathing–whereas passwords deserve their own very special throne of infamy. And the worst part of it all? There isn’t a single, viable alternative. This piece is oriented towards consumers but the enterprise issues are extremely similar. I really don’t see any alternatives that work at scale, especially because most employees are ‘consumers’ (what a crappy word). CAC cards for gov/DoD are the closest to an exception I can find, and that’s a pretty specific audience (admittedly a large large one). Share:

Today I popped off a quick tweet after yet another email from LinkedIn: Please please please… … stop endorsing me. Seriously. I barely use LinkedIn. For me it is little more than a contact manager, and otherwise lost most of its other value long ago. Perhaps thats my own bias, but there it is. As for endorsements… this is LinkedIn deliberately social engineering us. Reciprocity is one of the most common human behaviors used for social engineering, because it is one of the most fundamental behaviors in building a social society. From Wikipedia: With reciprocity, a small favor can produce a sense of obligation to a larger return favor. This feeling of obligation allows an action to be reciprocated with another action. Because there is a sense of future obligation with reciprocity it can help to develop and continue relationships with people. Reciprocity works because from a young age people are taught to return favors and to disregard this teaching will lead to the social stigma of being an ingrate. This is used very frequently in various scams. LinkedIn uses endorsements and reciprocity to draw people into logging into the service. You feel you need to return the endorsement, you log in, endorse, and then maybe endorse someone else, spreading it like Chinese malware. If LinkedIn wasn’t so obnoxious about the notification emails I wouldn’t consider this such a blatant attempt at manipulation. But the constant nags are crafted to elicit a specific return behavior. In other words, clear-cut social engineering. Share:

My latest TidBITS piece on Mac security: Under normal circumstances, we recommend updating immediately whenever an important security patch is released, but in this case, we have a somewhat different recommendation. Instead of leaving Flash on your Mac, you can instead isolate it and thus reduce the attack surface available to the bad guys. This is both easier and require far less fuss going forward than you might think, and it is how I’ve been using my Mac for the past year or so. This may not work for those of you in enterprise environments (my TidBITS writing is all for consumers), but you should consider it. The technique should work on Windows, not just Macs. Some people also like ClickToPlugin, which blocks all plugins on a page until you click to enable them. I deliberately left this out of the TidBITS piece because it is more advanced users. Then again, if you are in enterprise security I suggest you take a hard look at Bromium, Invincea, or any competitors who crop up. They can give fairly good results without interfering with user experience at all. Share:

First reported by Brian Krebs (as usual), security vendor Bit9 was compromised and used to infect their customers. But earlier today, Bit9 told a source for KrebsOnSecurity that their corporate networks had been breached by a cyberattack. According to the source, Bit9 said they’d received reports that some customers had discovered malware inside of their own Bit9-protected networks, malware that was digitally signed by Bit9’s own encryption keys. They posted more details on their site after notifying customers: In brief, here is what happened. Due to an operational oversight within Bit9, we failed to install our own product on a handful of computers within our network. As a result, a malicious third party was able to illegally gain temporary access to one of our digital code-signing certificates that they then used to illegitimately sign malware. There is no indication that this was the result of an issue with our product. Our investigation also shows that our product was not compromised. We simply did not follow the best practices we recommend to our customers by making certain our product was on all physical and virtual machines within Bit9. Our investigation indicates that only three customers were affected by the illegitimately signed malware. We are continuing to monitor the situation. While this is an incredibly small portion of our overall customer base, even a single customer being affected is clearly too many. No sh**. Bit9 is a whitelisting product. This sure is one way to get around it, especially since customers cannot block Bit9 signed binaries even if they want to (well, not using Bit9, at least). This could mean the attackers had good knowledge of the Bit9 product and then used the signed malware to only attack Bit9 customers. The scary part of this? Attackers were able to enumerate who was using Bit9 and target them. But this kind of tool should be hard to discover running in the first place, unless you are already in the front door. This enumeration could have been either before or after the attack on Bit9, and that’s a heck of an interesting question we probably won’t ever an answer to. This smells very similar to the Adobe code signing compromise back in September, except that was clearly far less targeted. Every security product adds to the attack surface. Every security vendor is now an extended attack surface for all their clients. This has happened before, and I suspect will only grow, as Jeremiah Grossman explained so well. All the security vendors now relishing the fall of a rival should instead poop their pants and check their own networks. Oh, and courtesy our very own Gattaca, let’s not forget this. Share:

Adobe just released a Flash update due to active exploitation on both Macs (yes, Macs) and Windows: Adobe is also aware of reports that CVE-2013-0634 is being exploited in the wild in attacks delivered via malicious Flash (SWF) content hosted on websites that target Flash Player in Firefox or Safari on the Macintosh platform, as well as attacks designed to trick Windows users into opening a Microsoft Word document delivered as an email attachment which contains malicious Flash (SWF) content. Instead of patching, do the following: Uninstall Flash from your computer (WIndows, Mac). Download Google Chrome. Profit! Use Chrome’s internal Flash sandbox, so you can uninstall Flash at the OS level. Not perfect, but much better than using Flash through other browsers and having it available on your system for things like those nasty embedded Word attachments. Share:

Game on! It’s hard to imagine, but this year we are hosting the Fifth Annual RSA Conference Disaster Recovery Breakfast, in partnership with SchwartzMSL and Kulesa Faul (and possibly one more surprise guest). When we started this we had no idea how popular it would be. Much to our surprise it seems that not everyone wants to spend all their time roaming a glitzy show floor or bopping their heads to 110 decibels in some swanky club with a bunch of coworkers wearing logo shirts and dragging around conference bags. (Seriously, what is up with that?!?) As always, the breakfast will be Thursday morning from 8-11 at Jillian’s in the Metreon. It’s an open door – come and leave as you want. We’ll have food, beverages, and assorted recovery items to ease your day (non-prescription only). Remember what the DR Breakfast is all about. No marketing, no spin, just a quiet place to relax and have muddled conversations with folks you know, or maybe even go out on a limb and meet someone new. After three nights of RSA Conference shenanigans, it’s an oasis in a morass of hyperbole, booth babes, and tchotchke hunters. Invite below. See you there. To help us estimate numbers please RSVP to rsvp (at) securosis (dot) com. I (Rich) won’t actually be there this year (probably) or at RSA at all. It seems my wife decided to have a baby that week, so unless the little bugger comes pretty early I’ll be at home for my first RSA in many years. So have one or two for me on Wednesday night, then a few aspirin and Tums for me on Thursday morning at the breakfast. Share:

Between WikiLeaks imploding, the LulzSec crew going to jail, and APT becoming business as usual, you might think data security was just so 2011, but the war isn’t over yet. Throughout 2012 we saw data security slowly moving deeper into the market, driven largely by mobile and cloud adoption. And slow is the name of the game – with two of our trends continuing from last year, and fewer major shifts than we have seen in some other years. You might mistake this for maturity, but it is more a factor of the longer buying cycles (9 to 18 months on average) we see for data security tools. Not counting the post-breach panic buys, of course. Cloud. Again. ‘Nuff Said? Yes, rumor is strong that enterprises are only using private cloud – but it’s wrong. And yes, cloud will be splattered on every booth like a henchman in the new Aaarnoold movies (he’s back). And yes, we wrote about this in last year’s guide. But some trends are here to stay, and we suspect securing cloud data will appear in this guide for at least another couple years. The big push this year will be in three main areas – encrypting storage volumes for Infrastructure as a Service; a bit of encryption for Dropbox, Box.net, and similar cloud storage; and proxy encryption for Software as a Service. You will also see a few security vendors pop off their own versions of Dropbox/Box.net, touting their encryption features. The products for IaaS (public and private) data protection are somewhat mature – many are extensions of existing encryption tools. The main thing to keep in mind is that, in a public cloud, you can’t really encrypt boot volumes yet so you need to dig in and understand your application architecture and where data is exposed before you can decide between options. And don’t get hung up on FIPS certification if you don’t need FIPS, or will you limit your options excessively. As for file sharing, mobile is the name of the game. If you don’t have an iOS app, your Dropbox/Box/whatever solution/replacement is deader than Ishtar II: The Musical. We will get back to this one in a moment. There are three key things to look for when evaluating cloud encryption. First, is it manageable? The cloud is a much more dynamic environment than old-school infrastructure, and even if you aren’t exercising these elastic on-demand capabilities today, your developers will tomorrow. Can it enable you keep track of thousands of keys (or more), changing constantly? Is everything logged for those pesky auditors? Second, will it keep up as you change? If you adopt a SaaS encryption proxy, will your encryption hamper upgrades from your SaaS provider? Will your Dropbox encryption enable or hamper employee workflows? Finally, can it keep up with the elasticity of the cloud? If, for example, you have hundreds of instances connecting to a key manager, does it support enough network sockets to handle a distributed deployment? If encryption gets in the way, you know what will happen. Is that my data in your pocket? BYOD is here to stay, as we discussed in the Key Themes post, which means all those mobile devices you hate to admit are totally awesome will be around for a while. The vendors are actually lagging a bit here – our research shows that no-one has really nailed what customers want from mobile data protection. This has never stopped a marketing team in the history of the Universe. And we don’t expect it to start now. Data security for BYOD will be all over the show floor. From network filters, to Enterprise DRM, with everything in between. Heck, we see some MDM tools marketed under the banner of data security. Since most organizations we talk to have some sort of mobile/BYOD/consumerization support project in play, this won’t all be hype. Just mostly. There are two things to look for. First, as we mentioned in Key Themes, it helps to know how people plan to use mobile and personal devices in your workplace. Ideally you can offer them a secure path to do what they need to solve their business problems, because if you merely block they they will find ways around you. Second, pay close attention to how the technology works. Do you need a captive network? What platforms does it support? How does it hook into the mobile OS? For example, we very often see features that work differently on different platforms, which has a major impact on enterprise effectiveness. When it comes to data security, the main components that seem to be working well are container/sandboxed apps using corporate data, cloud-enhanced DRM for inter-enterprise document sharing, and containerized messaging (email/calendar) apps. Encryption for Dropbox/Box.net/whatever is getting better, but you really need to understand whether and how it will fit your workflows (e.g., does it allow personal and corporate use of Dropbox?). And vendors? Enough of supporting iOS and Windows only. You do realize that if someone is supporting iOS, odds are they have to deal with Macs, don’t you? Shhh. Size does matter Last year we warned you not to get Ha-duped, and good advice never dies. There will be no shortage of Big Data hype this year, and we will warn you about it continually throughout the guide. Some of it will be powering security with Big Data (which is actually pretty nifty), some of it will be about securing Big Data itself, and the rest will confuse Big Data with a good deal on 4tb hard drives. Powering security with Big Data falls into other sections of this Guide, and isn’t necessarily about data security, so we’ll skip it for now. But securing Big Data itself is a tougher problem. Big Data platforms aren’t architected for security, and some even lacking effective access controls. Additionally, Big Data is inherently about collecting massive sets of heterogenous data for advanced analytics – it’s not like you could just encrypt a single column.