Research

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.

In response to this SC Magazine article (thanks @pauljudge), I tweeted: An important distinction to keep in mind when you read these articles. Share:

Yep – we are doing our very best to overload you with research this year. Here’s my latest. From the paper’s home page: Between new initiatives such as cloud computing, and new mandates driven by the continuous onslaught of compliance, managing encryption keys is evolving from something only big banks worry about into something which pops up at organizations of all sizes and shapes. Whether it is to protect customer data in a new web application, or to ensure that a lost backup tape doesn’t force you to file a breach report, more and more organizations are encrypting more data in more places than ever before. And behind all of this is the ever-present shadow of managing all those keys. Data encryption can be a tricky problem, especially at scale. Actually all cryptographic operations can be tricky; but we will limit ourselves to encrypting data rather than digital signing, certificate management, or other uses of cryptography. The more diverse your keys, the better your security and granularity, but the greater the complexity. While rudimentary key management is built into a variety of products – including full disk encryption, backup tools, and databases – at some point many security professionals find they need a little more power than what’s embedded in the application stack. This paper digs into the features, functions, and a selection process for key managers. Understanding and Selecting a Key Manager (PDF) Special thanks to Thales for licensing the content. Share:

Thanks to your friends at Accuvant labs. Very worth reading for security pros. Peter Morgan, Ryan Smith, Braden Thomas, and Josh Thomas did an excellent job breaking it down. Here’s the security risk: One important point to make is that unlike the previous jailbreakme.com exploits, which could be used against an unwitting victim, jailbreaks that require USB tethering have a lower security impact, and are usually only useful to the phone’s owner. Attackers are less interested because iPhones with a passcode set will refuse to communicate over USB if they are locked, unless they have previously paired with the connecting computer. So your phone is stolen and it’s locked, attackers won’t be able to jailbreak it. Therefore, only malicious code already running on your computer can leverage USB jailbreaks nefariously. In case you didn’t know, iOS devices that pair with a computer will re-pair with other user accounts on that computer. It is device-based, not user account based. Share:

Evad3rs releases an iOS 6.1 jailbreak for all devices. Update: According to @drscjmm this will not work when a passcode is set, which means we are still in pretty good shape from a security standpoint. Untethered, which means you still need to plug the device into a computer, but the jailbreak lasts across reboots (this is not remotely executable at this time). This means all iOS devices are exposed to hands-on forensics, even with a passcode. Data protection still needs to be broken, but an attacker can jailbreak and install a back door to sniff your password if they have physical control of the device for long enough. if you lose your phone and recover it, wipe it and restore from a known unjailbroken backup. From the jailbreak notes: Please disable the lock passcode of your iOS device before using evasi0n. It can cause issues. I can’t test right now, but will be interesting if a passcode prevents the jailbreak, or is sometimes just an obstacle. Please leave comments if you know or find out. Update: As we said above, a passcode appears to block this jailbreak, which is good. (Hat tip to The Verge for the link). Share:

What’s the over/under on this one working? Mac users – this means XProtect won’t block it in your web browser, so if you don’t want it active be careful. I actually feel bad for the team that has to clean Java up. I’d hate to be in that mess. Share: