Research

From the Economist: TRADITIONALLY, business associates would get to know each other over a round of golf. But road cycling is fast catching up as the preferred way of networking for the modern professional. A growing number of corporate-sponsored charity bike rides and city cycle clubs are providing an ideal opportunity to talk shop with like-minded colleagues and clients while discussing different bike frames and tricky headwinds. Many believe cycling is better than golf for building lasting working relationships, or landing a new job, because it is less competitive. Oh, biking is definitely competitive, but not as directly competitive. Anyway, call this one wishful thinking on my part – I would rather ride than golf any day. Then again I have only ridden once in a business context, and it blew away every other team building/networking/whatever exercise in my entire professional history. Share:

From Macworld: iOS app contains potential malware: The app Simply Find It, a $2 game from Simply Game, seems harmless enough. But if you run Bitdefender Virus Scanner–a free app in the Mac App Store–it will warn you about the presence of a Trojan horse within the app. A reader tipped Macworld off to the presence of the malware, and we confirmed it. I looked into this for the article, and aside from blowing up my schedule today it was pretty interesting. Bitdefender found a string which calls an iframe pointing to a malicious site in our favorite top-level domain (.cn). The string was embedded in an MP3 file packaged within the app. The short version is that despite my best attempts I could not get anything to happen, and even when the MP3 file plays in the (really bad) app it never tries to connect to the malicious URL in question. Maybe it is doing something really sneaky, but probably not. At this point people better at this than me are probably digging into the file, but my best guess is that a cheap developer snagged a free music file from someplace, and the file contained a limited exploit attempt to trick MP3 players into accessing the payload’s URL when they read the ID3 tag. Maybe it targets an in-browser music player. The app developer included this MP3 file but the app’s player code isn’t vulnerable to the MP3’s, so exploit nothing bad happens. It’s interesting, and could easily slip by Apple’s vetting if there is no way the URL could trigger. Maybe we will hear more when people perform deeper analysis and report back, but I doubt it. I suspect the only thing exploited today was my to do list. Share:

I was weirdly interested in Paul Miller’s year off the Internet. Paul is a writer for The Verge, and they actually paid him to keep writing (offline) through the year instead of kicking him to the curb like most publications would have. Spoiler: in retrospect the entire thing was a mix of isolating and asinine. And now I’m supposed to tell you how it solved all my problems. I’m supposed to be enlightened. I’m supposed to be more “real,” now. More perfect. But instead it’s 8PM and I just woke up. I slept all day, woke with eight voicemails on my phone from friends and coworkers. I went to my coffee shop to consume dinner, the Knicks game, my two newspapers, and a copy of The New Yorker. And now I’m watching Toy Story while I glance occasionally at the blinking cursor in this text document, willing it to write itself, willing it to generate the epiphanies my life has failed to produce. I didn’t want to meet this Paul at the tail end of my yearlong journey. Paul is still just as happy or miserable as he was a year ago, except now he doesn’t know who Honey Boo Boo is. Or maybe he does because, without the Internet, he probably watched entirely too much bad cable television. Or local news. Technology doesn’t move backwards. At least not until we blow the planet up, create a life-eliminating disease, the robots convert us to fuel, or the nanobots ingest every organic molecule and turn the planet into grey goo (pick one – maybe two). The Internet is here to stay, and disconnecting is more likely to make you less happy because you would lose one of the few communications channels that works in our distributed society. As Paul learned, the Internet is merely an enabler. If you’re lazy and procrastinate, it isn’t like you need the Internet for that. If you get too wrapped up in Facebook or Twitter, odds are you were the same way with memos and water coolers – and could be again. The Internet does allow some people to bypass certain psychological and social limitations around face to face interaction, but the Internet isn’t what actually made them assholes in the first place. But yes, the Internet can most definitely exacerbate certain behaviors, it weakens social herd immunity, and it enables nut jobs to congregate more freely. I have personally found great value in moderating my Internet consumption, but I’m not so foolish as to think its total elimination would buy my anything. Especially because I now have kids, I try to make sure they know I’m focused on them and not a screen in my hand. Mostly it’s a matter of not letting myself get caught up in a bunch of garbage that doesn’t matter (especially on Twitter), obsessing over the news, or spending countless hours reading things that really don’t affect my life or improve my education. It’s all a balance. I’m far from perfect, but I suppose my extreme lack of leisure time makes it easier for me to focus. So I am proud to announce, much to your relief (yeah, right), that I am not leaving Twitter, Facebook, email, or the Internet in general. On the other hand, I reserve the right to check them when I want, not respond to every email, and not apologize for missing that blog post. The Internet is a big part of my life, but my life is much more than the Internet. –Rich On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in Macworld on an iOS app which includes a malware string. Favorite Securosis Posts Mike Rothman: Twitter security for media companies. These are good tips for every company, but more urgent for media companies given the recent Twitter hacks. This is a big deal for companies that provide shared access to corporate Twitter accounts. At some point we would like to see Twitter support federation (perhaps as a subscription service) so companies can define who can do what with their account, and enforce those entitlements. Details, details. (Editor’s note – Twitter supports OAuth, so it does allow this -Rich) Adrian Lane: Trailblazing Equality. Rich: Socially engineering (trading) bots. Other Securosis Posts Off topic: Cycling is the new golf. Malware string in iOS app interesting, but probably not a risk. Getting Logstalgic. Security Analytics with Big Data: Use Cases. Gaming the pirates – literally. Google Glass Has Already Been Hacked By Jailbreakers. Security Funding via Tin Cup. IaaS Encryption: External Key Manager Deployment and Feature Options. IaaS Encryption: Encrypting Entire Volumes. Favorite Outside Posts Mike Rothman: 102 hours in pursuit of Marathon suspects. Unbelievable story detailing the hunt for the Boston Marathon suspects. Really great reporting to produce a full account. Adrian Lane: It’s time for a Chief API Officer. While I don’t think a development trend warrants its own C-level executive, the importance of APIs to development is hard to overstate. David Mortman: Cryptography is a systems problem (or) ‘Should we deploy TLS’. Rich: One security equation to rule them all. I would like to see the formal proof but this looks accurate. Research Reports and Presentations Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. The Endpoint Security Management Buyer’s Guide. Top News and Posts McAfee Patents Technology to Detect and Block Pirated Content. Sound like a bad idea to anyone else? Pirates hate piracy (when it happens to them). How long before we see Greenheart’s data on Pastebin? Syrian Electronic Army Hijacks Guardian Twitter Accounts. Army? It’s probably three guys living in the Bronx. Samsung Delays Android Security Software. Blue For The Pineapple. Step by step tutorial on turing the Fon AccessPoint into a stealthy WiFi hijacker. Defense contractor pwned by

Deployment and topology options The first thing to consider is how you want deploy external key management. There are four options: An HSM or other hardware key management appliance. This provides the highest level of physical security but the appliance will need to be deployed outside the cloud. When using a public cloud this means running the key manager internally, relying on a virtual private cloud, and connecting the two with a VPN. In private clouds you run it somewhere on the network near your cloud, which is much easier. A key management virtual appliance. Your vendor provides a pre-configured virtual appliance (instance) for you to run in your private cloud. We do not recommend you run this in a public cloud because – even if the instance is encrypted – there is significantly more exposure to live memory exploitation and loss of keys. If you decide to go this route anyway, use a vendor that takes exceptional memory protection precautions. A virtual appliance doesn’t offer the same physical security as a physical server, but they do come hardened and support more flexible deployment options – you can run it within your cloud. Key management software, which can run either on a dedicated server or within the cloud on an instance. The difference between software and a virtual appliance is that you install the software yourself rather than receiving a configured and hardened image. Otherwise it offers the same risks and benefits as a virtual appliance, assuming you harden the server (instance) as well as the virtual appliance. Key management Software as a Service (SaaS). Multiple vendors now offer key management as a service specifically to support public cloud encryption. This also works for other kinds of encryption, including private clouds, but most usage is for public clouds. There are a few different deployment topologies, which we will discuss in a moment. When deploying a key manager in a cloud there are a few wrinkles to consider. The first is that if you have hardware security requirements your only option is to deploy a HSM or encryption/key management appliance compatible with the demands of cloud computing – where you may have many more dynamic network connections than in a traditional network (note that raw key operations per second is rarely the limiting factor). This can be on-premise with your private cloud, or remote with a VPN connection to the virtual private cloud. It could also be provided by your cloud provider in their data center, offered as a service, with native cloud API support for management. Another option is to store the root key on your own hardware, but deploy a bastion provisioning and management server as a cloud instance. This server handles communications with encryption clients/agents and orchestrates key exchanges, but the root key database is maintained outside the cloud on secure hardware. If you don’t have hardware security requirements a number of additional options open up. Hardware is often required for compliance reasons, but isn’t always necessary. Virtual appliances and software servers are fairly self-explanatory. The key issue (no pun intended) is that you are likely to need additional synchronization and orchestration to handle multiple virtual appliances in different zones and clouds. We will talk about this more in a moment, when we get to features. Like deploying a hardware appliance, some key management service providers also deploy a local instance to assist with key provisioning (this is provider dependent and not always needed). In other cases the agents will communicate directly with the cloud provider over the Internet. A final option is for the security provider to partner with the cloud provider and install some components within the cloud to improve performance, to enhance resilience, and/or to reduce Internet traffic – which cloud providers charge for. To choose an appropriate topology answer the following questions: Do you need hardware-level key security? How many instances and key operations will you need to support? What is the topology of your cloud deployment? Public or private? Zones? What degree of separation of duties and keys do you need? Are you willing to work with a key management service provider? Cloud features For a full overview of key management servers, see our paper Understanding and Selecting a Key Management Solution. Rather than copying and pasting an 18-page paper we will focus on a few cloud-specific requirements we haven’t otherwise covered yet. If you use any kind of key management service, pay particular attention to how keys are segregated and isolated between cloud consumers and from service administrators. Different providers have different architectures and technologies to manage this, and you should to map your security requirements agains how they manage keys. In some cases you might be okay with a provider having the technical ability to get your keys, but this if often completely unacceptable. Ask for technical details of how they manage key isolation and the root of trust. Even if you deploy your own encryption system you will need granular isolation and segregation of keys to support cloud automation. For example if a business unit or development team is spinning up and shutting down instances dynamically, you will likely want to provide the capability to manage some of their own keys without exposing the rest of the organization. Cloud infrastructure is more dynamic than traditional infrastructure, and relies more on Application Programming Interfaces (APIs) and network connectivity – you are likely to have more network connections from a greater number of instances (virtual machines). Any cloud encryption tool should support APIs and a high number of concurrent network connections for key provisioning. For volume encryption look for native clients/agents designed to work with your specific cloud platform. These are often able to provide information above and beyond standard encryption agents to ensure only acceptable instances access keys. For example they might provide instance identifiers, location information, and other indicators which do not exist on a non-cloud encryption agent. When they are available you might use them to only allow an instance to

As we mentioned in our last post, there are three options for encrypting entire storage volumes: Instance-managed Externally-managed Proxy We will start with the first two today, then cover proxy encryption and some deeper details on cloud key managers (including SaaS options) next. Instance-managed encryption This is the least secure and manageable option; it is generally only suitable for development environments, test instances, or other situations where long-term manageability isn’t a concern. Here is how it works: The encryption engine runs inside the instance. Examples include TrueCrypt and the Linux dm-crypt tool. You connect a second new storage volume. You log into your instance, and using the encryption engine you encrypt the new storage volume. Everything is inside the instance except the raw storage, so you use a passphrase, file-based key, or digital certificate for the key. You can also use this technique with a tool like TrueCrypt and create and mount a storage volume that’s really just a encrypted large file stored on your boot volume. Any data stored on the encrypted volume is protected from being read directly from the cloud storage (for instance if a physical drive is lost or a cloud administrator tries to access your files using their native API), but is accessible from the logged-in instance while the encrypted volume is mounted. This protects you from many cloud administrators, because only someone with actual access to log into your instance can see the data, which is something even a cloud administrator can’t do without the right credentials. This option also protects data in snapshots. Better yet, you can snapshot a volume and then connect it to a different instance so long as you have the key or passphrase. Instance-managed encryption also works well for public and private cloud. The downside is that this approach is completely unmanageable. The only moderately secure option is to use a passphrase when you mount the encrypted volume, which requires manual intervention every time you reboot the instance or connect it (or a snapshot) to a different instance. For security reasons you can’t store the key (or passphrase) in a file in the instance, or use a stored digital certificate, because anything stored on the unencrypted boot volume of the instance is exposed. Especially since, as of this writing, we know of no options to use this to encrypt a bootable instance – it only works for ‘external’ storage volumes. In other words this is fine for test and development, or to exchange data with someone else by whole volumes, but should otherwise be avoided. Externally-managed encryption Externally-managed encryption is similar to instance-managed, but the keys are handled outside the instance in a key management server or Hardware Security Manager (HSM). This is an excellent option for most cloud deployments. With this option the encryption engine (typically a client/agent for whatever key management tool you are using) connects to an extermal key manager or HSM. The key is provided subject to the key manager’s security checks, and then used by the engine or client to access the storage volume. The key is never stored on disk in the instance, so the only exposure is in RAM (or snapshots of RAM). Many products further reduce this exposure by overwriting keys’ memory when the keys aren’t in active use. As with instance-managed encryption, storage volumes and snapshots are protected from cloud administrators. But using an external key manager offers a wealth of new benefits, such as: This option supports reboots, autoscaling, and other cloud operations that instance-managed encryption simply cannot. The key manager can perform additional security checks, which can be quite in-depth, to ensure only approved instances access keys. It can then provide keys automatically or alert a security administrator for quick approval. Auditing and reporting are centralized, which is essential for security and compliance. Keys are centrally managed and stored, which dramatically improves manageability and resiliency at enterprise scale. Externally-managed encryption supports a wide range of deployment options, such as hybrid clouds and even managing keys for multiple clouds. This approach works well for both public and private clouds. A new feature just becoming available even you to encrypt a boot volume, similar to laptop full disk encryption (FDE). This isn’t currently possible with any other volume encryption option, and it is only available in some products. There are a few downsides, including: The capital investment is greater – you need a key management server or HSM, and a compatible encryption engine. You must install and maintain a key management server or HSM that is accessible to your cloud infrastructure. You need to ensure your key manager/HSM will scale with your cloud usage. This isn’t less an issue of how many keys it stores than how well it performs in a cloud, or when connecting to a cloud (perhaps due to network latency). This is often the best option for encrypting volume storage, but our next post will dig into the details a bit more – there are many deployment and feature options. Share:

Twitter is worried about all the media company accounts being hacked, and has released some guidance. These aren’t exploits of Twitter itself, but of media companies, typically through phishing. Twitter suggests that companies employ a pretty standard set of password security practices in response: changing current passwords, using new ones that are at least 20 characters long and are made up of either randomly-generated characters or random words, and to never email said passwords, even internally … Given that email accounts are used to reset passwords, Twitter also suggests users change those passwords and implement two-factor authentication on their email accounts if available Here is what I suggest on top of Twitter’s suggestions: Use a dedicated email account for your Twitter account, and don’t make it public. Disable all Twitter email updates to that account, and rely on in-app notifications. Use strong authentication for that email account, and limit access. If you need to authorize a new app or employee for Twitter, change the Twitter account password to a new random password after every time you use it to authorize an app. Check your app authorizations daily. You are a media company, and this is one of your biggest channels. I don’t make this recommendation for everyone, but if you are the AP you need to take super extra precautions. Have an incident response process for suspicious tweets or account access, and make sure you pre-contact Twitter with the right contact info for those authorized to check on the account. Again, if you are a big media company, use a designated device for tweeting that isn’t used for other things. Notice I said “device”. An iPad is great because you don’t need to worry about background malware. I’m sure people have other good ideas to add in the comments… Share:

Courtesy of Forbes: Freeman, who goes by the hacker handle “Saurik” and created the widely-used app store for jailbroken iOS devices known as Cydia, told me in a phone interview that he discovered yesterday that Glass runs Android 4.0.4, and immediately began testing previously-known exploits that worked on that version of Google’s mobile operating system. Within hours, he found that he could use an exploit released by a hacker who goes by the name B1nary last year to gain full control of Glass’s operating system. As David Mortman said in our internal chat room: Love that it’s a slightly modified year old exploit. Google couldn’t even bother to release an up to date version of android with the device. Here is why it matters – Glass will be open to most, if not all Android exploits unless Google takes extra precautions. Glass is always on, with a persistent video camera that isn’t blacked out when you drop it in your pocket. This offers malware opportunities beyond even the risks of a phone. Since every jailbreak is a security exploit, this is a problem. Share:

This is too good not to share, albeit only tangentially related to our usual SMB and enterprise focus: A software development company posted a cracked version of their new game to pirate sites, but with a twist: However, in the pirated version, the in-game developers begin to run into crippling piracy that eventually drives them into bankruptcy. In-game CEO’s receive this message: “Boss, it seems that while many players play our new game, they steal it by downloading a cracked version rather than buying it legally.” If players don’t buy the games they like, we will sooner or later go bankrupt. Players who downloaded the game illegally then began posting questions in the game’s support forums asking how to better fight the pirates. After the first weekend, the company had 3100 gamers playing the cracked version, with 214 playing the genuine edition. Pay for your f-ing software, people, that’s all I have to say. Heck, I have even started paying for things I can get free review licenses for, when they are something I use on a regular basis and want to support. Share:

This summer James Arlen and I are teaching the recently updated cloud security class we developed for the Cloud Security Alliance (CCSK Plus). We are pretty excited to teach this at Black Hat, and will be bringing a few extra tricks to handle the more advanced audience we expect. The class runs two days and covers a huge amount of material. The first day is mostly lecture, covering: Introduction to cloud computing and cloud architectures. Securing cloud infrastructure (public and private). Governing and managing risk in cloud computing (yep, we have to cover compliance, but we also include incident response). Securing cloud data. Application security and identity management for cloud. Selecting and managing cloud providers. This gives you everything you need to take the CCSK test if you want. The second day is where the real fun starts – we spend pretty much the entire time in labs. Including: Assessing cloud risk. This is a tabletop risk management exercise focused on practical scenarios. Launching and securing public cloud instances. You’ll learn the ins and outs of Amazon EC2 as you launch and secure your first instance. This includes a deep dive into security groups, picking AMIs, and using initialization scripts to auto-update and configure instances. Encrypting cloud data. We encrypt a storage volume using dm-crypt and dig into different key management scenarios and encryption options. We may have some new demos here of products just hitting the market. Building secure cloud applications. We expand on what we have created to build a multi-tier secure application, focusing on proper use of hypersegregation by splitting application components. Federated identity and using IAM to harden the management plane. We add a little OpenID to our application. Up to this point everything builds out into a complete stack and all the exercises tie together. We also work with AWS IAM and how to use different kinds of credentials and templates to segregate things at the management plane. Securing a private cloud. Using your laptops and our virtual machines we build a running OpenStack cloud in the classroom and run through the security essentials. But here is the trick for Black Hat. Aside from teaching a very recently updated version of the class, we are preparing for a more technical audience. We will be bringing more advanced exercise options (on top of the basics so people with less experience can still get something out of the class), and even a demo attack tool PoC. We will feel the audience out but we already have some advanced (self-guided) exercises together. If you’re interested you can sign up now. Also, although this isn’t an instructor class, anyone who takes this (and contacts us ahead of time) will be eligible to complete additional, web-based instructor training free of charge after Black Hat. We aren’t a training organization, and we care more about getting more teachers out there than keeping it all to ourselves. Hope to see you in Vegas! Share:

There are two ways to respond to criticism of your security product, especially when encryption is involved. Respond cautiously, openly, and positively as demonstrated last week by AgileBits, the folks behind 1Password. Do what CipherCloud did. The TL;DR is that some people over on StackExchange were trying to figure out how CipherCloud works (specifically its homomorphic encryption, which CipherCloud states isn’t actually part of the product). Some public materials were posted, and then the CipherCloud legal team smacked StackExchange with a DMCA takedown notice over screenshots of the product as people tried to figure out how it works. They also issued a takedown request based on “false and misleading statements”, which does little more than fully engage the Streisand effect. CipherCloud has since issued a kinda-sorta apology and an update that, judging from the few comments doesn’t satisfy anyone. They apologize for the takedown requests and blame their legal department, but barely address the actual issue. First of all from what I have seen they have a good product which does what they claim it does. I have been briefed and know some large organizations evaluating or using it. The problem here isn’t the product – it’s their approach. When someone posts potentially unfavorable information about you on the Internet, trying to squash it always backfires. Also, if the posts are mostly trying to cut through your marketing material to see how the product works, that means people are interested in your product and you should treat them with respect. CipherCloud’s response to the DMCA takedown criticism is to state that the conclusions coming out of StackExchange were wrong and based on an older video demo. That’s totally fine, but they fail to actually fill the information gap with accurate information. There is a little about what they don’t do, the usual platitudes about FIPS-140, and that’s about it. They say they will provide this information to customers, prospects, and partners, but want to keep their IP otherwise out of the public eye: I understand and appreciate the interest in the market to better understand our technology, and I am happy to discuss additional details around our encryption implementation with our customers, prospects and partners. If you are interested in learning more, please contact CipherCloud directly via our website at info@ciphercloud.com This isn’t how to respond. I know their competitors, and trust me, they all have a good idea of how CipherCloud works. The ones who care set up straw buyers/prospects to get their hands on demos, however unethical that is. I don’t think they need to reveal everything, but this was a great opportunity to get some additional attention, explain why they feel they are better than the competition, and generate some goodwill among those interested in the product. Instead they look like they are hiding something. 1Password nailed it with their reasoned response to a security concern, and the industry is well trained to be skeptical of security vendors – especially in encryption – who aren’t transparent about their technology. Also, when you make a mistake like letting loose the legal dogs, you need to sound truly apologetic, not defensive. Anyway, big companies can get away from this, but now CipherCloud has to deal with negative coverage as the second result on their Google search. I am not a marketing exec, but that coverage is not good, and they will have to live with it for a while. Share: