Research

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:

Usually at security events like the RSA Conference there isn’t much buzz about Identity and Access Management. Actually, identity is rarely thought of as a security technology; instead it is largely lumped in with general IT operational stuff. But 2013 feels different. Over the past year our not-so-friendly hacktivists (Anonymous) embarrassed dozens of companies by exposing private data, including account details and password information. Aside from this much more visible threat and consequence, the drive towards mobility and cloud computing/SaaS at best disrupts, and at worst totally breaks, traditional identity management concepts. These larger trends have forced companies to re-examine their IAM strategies. At the same time we see new technologies emerge, promising to turn IAM on its ear. We will see several new (start-up) IAM vendors at this year’s show, offering solutions to these issues. We consider this is a very positive development – the big lumbering companies largely dominating IAM over the past 5 years haven’t kept pace with these technical innovations. IDaaS = IAM 2.0 The most interesting of the shiny new objects you will see at RSAC is identity-as-a-service (IDaaS), which extend traditional in-house identity services to external cloud providers and mobile devices. These platforms propagate and/or federate identity outside your company, providing the glue to seamlessly link your internal authoritative source with different cloud providers – the latter of which generally offer a proprietary way to manage identity within their environment. Several vendors offer provisioning capabilities as well, linking internal authorization sources such as HR systems with cloud applications, helping map permissions across multiple external applications. It may look like we are bolting a new set of capabilities onto our old directory services, but it is actually the other way around. IDaaS really is IAM 2.0. It’s what IAM should have looked like if it had originally been architected for open networks, rather than the client-server model hidden behind a network firewall. But be warned: the name-brand directory services and authorization management vendors you are familiar with will be telling the same story as the new upstart IDaaS players. You know how this works. If you can’t innovate at the same pace, write a data sheet saying you do. It’s another kind of “cloud washing” – we could call it Identity Washing. They both talk about top threats to identity, directory integration, SSO, strong authentication, and the mobile identity problem. But these two camps offer very different visions and technologies to solve the problem. Each actually solves distinctly different problems. When they overlap it is because the traditional vendor is reselling or repackaging someone else’s IDaaS under the covers. Don’t be fooled by the posturing. Despite sales driod protestations about simple and easy integrations between the old world and this new stuff, there is a great deal of complexity hiding behind the scenes. You need a strong understanding of how federation, single sign-on, provisioning, and application integration are implemented to understand whether these products can work for you. The real story is how IDaaS vendors leverage standards such as SAML, OAuth, XACML, and SCIM to extend capabilities outside the enterprise, so that is what you should focus on. Unfortunately managing your internal LDAP servers will continue to suck, but IDaaS is likely the easier of the two to integrate and manage with this new generation of cloud and mobile infrastructure. Extending what you have to the cloud is likely easier than managing what you have in house today. Death to Passwords Another new theme as RSAC will be how passwords have failed us and what we should do about it. Mat Honan said we should Kill The Password. Our own Gunnar Peterson says Infosec Slowly Puts Down Its Password Crystal Meth Pipe. And I’m sure Sony and Gawker are thinking the same thing. But what does this mean, exactly? Over time it means we will pass cryptographic tokens around to assert identity. In practice you will still have a password to (at least partially) authenticate yourself to a PC or other device you use. But once you have authenticated to your device, behind the scenes an identity service that will generate tokens on your behalf when you want access to something. Passwords will not be passed, shared, or stored, except within a local system. Cryptographic tokens will supplant passwords, and will transparently be sent on your behalf to applications you use. Instead of trusting a password entered by you (or, perhaps, not by you) applications will establish trust with identity providers which generate your tokens, and then verify the token’s authenticity as needed. These tokens, based on some type of standard technology (SAML, Kerberos, or OAuth, perhaps), will include enough information to validate the user’s identity and assert the user’s right to access specific resources. Better still, tokens will only be valid for a limited time. This way even if a hacker steals and cracks a password file from an application or service provider, all its data will be stale and useless before it can be deciphered. The “Death to Passwords” movement represents a seismic shift in the way we handle identity, and seriously impacts organizations extending identity services to customers. There will be competing solutions offered at the RSA show to deal with password breaches – most notably RSA’s own password splitting capability, which is a better way to store passwords rather than a radical replacement for the existing system. Regardless, the clock is ticking. Passwords’ deficiencies and limitations have been thoroughly exposed, and there will be many discussions on the show floor as attendees try to figure out the best way to handle authentication moving forward. 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 talk shop with good folks in a hype-free zone? Nowhere, so make sure you join us… Share:

The early stages of the Internet felt a bit like the free love era, in that people could pretty much do what they wanted, even if it was bad for them. I remember having many conversations with telecom carriers about the issues of consumers doing stupid things, getting their devices pwned, and then wreaking havoc on other consumers on the same network. For years the carriers stuck their heads in the sand, basically offering endpoint protection suites for free and throwing bandwidth at the problem. But that seems to be changing. I know a few large- scale ISPs who put compromised devices in the penalty box, preventing them from doing much of anything until the device is fixed. This is an expensive proposition for an ISP. You, like me, probably end up doing a decent amount of tech support for less sophisticated family members, and you know how miserable it is to actually remediate a pwned machine. But as the operating systems have gotten much better at protecting themselves, attackers increasingly target applications. And that means attacking browsers (and other high-profile apps such as Adobe Reader and Java) where they are weakest: the plug-in architecture. So kudos to Mozilla, who has started blocking plug-ins as their default setting. It will now be up to the user to enable plug-ins, such as Java, Adobe, and Silverlight, according to Mozilla director of security assurance Michael Coates, who announced the new functionality yesterday in a blog post. Mozilla’s Click to Play feature will be the tool for that: “Previously Firefox would automatically load any plugin requested by a website. Leveraging Click to Play, Firefox will only load plugins when a user takes the action of clicking to make a particular plugin play, or the user has previously configured Click To Play to always run plugins on the particular website,” he wrote. Of course users will still be able to get around it (like the new Gatekeeper feature in Mac OS X), but they will need to make a specific decision to activate the plug-in. It’s a kind of default deny approach to plug-ins, which is a start. And more importantly it’s an indication that application software makers are willing to adversely affect the user experience to reduce attack surface. Which is good news from where I sit. 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:

Got an interesting link from my friend Don, who prefers to stay behind the scenes, pointing out an interesting perspective on Jared Diamond, an older guy evaluating the risks of his daily activities. Consider: If you’re a New Guinean living in the forest, and if you adopt the bad habit of sleeping under dead trees whose odds of falling on you that particular night are only 1 in 1,000, you’ll be dead within a few years. In fact, my wife was nearly killed by a falling tree last year, and I’ve survived numerous nearly fatal situations in New Guinea. Most folks won’t bat an eyelash about a 1 in 1,000 event. But Jared hopes to have 15 years of life left, so if he averages one shower per day that’s 5,475 showers. If he were to fall once every thousand showers, he would still take 5 or more spills. Obviously falling in a confined area is problematic for the elderly. So the small risk is quite real. But the real point isn’t to forget about personal hygiene – it’s to be constructively paranoid. Build on-the-fly threat models, and mitigate those risks. Regardless of what you are doing. My hypervigilance doesn’t paralyze me or limit my life: I don’t skip my daily shower, I keep driving, and I keep going back to New Guinea. I enjoy all those dangerous things. But I try to think constantly like a New Guinean, and to keep the risks of accidents far below 1 in 1,000 each time. Can you see the applicability to security? Photo credit: US 12 – White Pass – Watch for falling trees #2, originally uploaded by WSDOT 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:

The PCI Security Standards Council released a Cloud Guidance (PDF) paper yesterday. Network World calls this Security standards council cuts through PCI cloud confusion. In some ways that’s true, but in several important areas it does the opposite. Here are a couple examples: SecaaS solutions not directly involved in storing, processing, or transmitting CHD may still be an integral part of the security of the CDE …the SecaaS functionality will need to be reviewed to verify that it is meeting the applicable requirements. … and … Segmentation on a cloud-computing infrastructure must provide an equivalent level of isolation as that achievable through physical network separation. Mechanisms to ensure appropriate isolation may be required at the network, operating system, and application layers; Which are both problematic because public cloud and SecaaS vendors won’t provide that level of access, and because the construction of the infrastructure cannot be audited in the same way in-house virtualization and private clouds can be. More to the point, under Logging and Audit Trails: CSPs should be able to segregate log data applicable for each client and provide it to each respective client for analysis without exposing log data from other clients. Additionally, the ability to maintain an accurate and complete audit trail may require logs from all levels of the infrastructure, requiring involvement from both the CSP and the client. And from the Hypervisor Access and Introspection section: introspection can provide the CSP with a level of real-time auditing of VM activity that may otherwise be unattainable. This can help the CSP to monitor for and detect suspicious activity within and between VMs. Additionally, introspection may facilitate cloud-efficient implementations of traditional security controls–for example, hypervisor-managed security functions such as malware protection, access controls, firewalling and intrusion detection between VMs. Good theory, but unfortunately with little basis in reality. Cloud providers, especially SaaS providers, don’t provide any such thing. They often can’t – log files in multi-tenant clouds aren’t normally segregated between client environments. Providing the log files to a client would leak information on other tenants. In many cases the cloud providers don’t provide customers any details about the underlying hypervisor – much less access. And there is no freakin’ way they would ever let an external auditor monitor hypervisor traffic through introspection. Have you ever tried negotiating with a vending machine? It’s like that. Put in your dollar, get a soda. You can talk to the vending machine all you want – ask for a ham sandwich if you like, but you will just be disappointed. It’s not going to talk back. It’s not going to negotiate. It’s self service to the mass market. In the vast majority of cases you simply cannot get this level of access from a public cloud provider. You can’t even negotiate for it. My guess is that the document was drafted by a committee, and some of the members of that committee don’t actually have any exposure to cloud computing it does not offer real-world advice. It appears to be guidance for private cloud or fully virtualized om-premise computing. Granted, this is not unique to the PCI Council – early versions of the Cloud Security Alliance recommendations had similar flaws as well. But this is a serious problem because the people who most need PCI guidance are least capable of distinguishing great ideas from total BS. And lest you think I regard the document as all bad, it’s not. The section on Data Encryption and Cryptographic Key Management is dead on-target. The issue will be ensuring that you have full control over both the encryption keys and the key management facility. And the guidance does a good job of advising people on getting clear and specific documentation on how data is handled, SLAs, and Incident Response. This is a really good guide for private cloud and on-premise virtualization. But I’m skeptical that you could ever use this guidance for public cloud infrastructure. If you must, look for providers who have certified themselves as PCI compliant – they take some of the burden off you. Share: