Research

Our last post described how to use Amazon EC2, S3, and IAM as a framework to securely and automatically download security policies and credentials. That’s the infrastructure side of the problem, and this post will show what you need to do to the instance to connect to this infrastructure, grab the credentials, install and configure Chef, and connect to the Chef server. The advantage of this structure is that you don’t need to embed credentials into your machine image, and you can use stock (generic) operating systems are on public clouds. In private clouds it is also useful because it reduces the number of machine images to maintain. These instructions can be modified to work in other cloud platforms, but your mileage will vary. They also require an operating system that supports cloud-init (Windows uses ec2config, which I know very little about, but also appears to support user data scripts). I will walk through the details of how this works, but you won’t use any of these steps manually. They are just explanation, to give you what you need to adapt this for other circumstances. Using cloud-init cloud-init is software for certain Linux variants that allows your cloud controller to pass scripts to new instances as they are launched from an image (bootstrapped). It was created by Canonical (the Ubuntu guys) and is very frequently packaged into Linux machine images (AMIs). ec2config offers similar functionality for Windows. Users pass the script to their instances, specifying the User Data field (for web interface) or argument (for command line). It is a bit of a pain because you don’t get any feedback – you need to debug from the system log – but it works well and allows tight control. Commands run as root before anyone can even log into the instance, so cloud-init is excellent for setting up secure configurations, loading ssh keys, and installing software. Note that cloud-init is a bootstrapping tool for configuring an instance the first time it runs – it is not a management tool because after launch you cannot access it any more. For an example see our full script at the bottom of this post. You can download and manipulate files easily with cloud-init, but unless you want to embed static credentials in your script there is an authentication issue. That’s where AWS IAM roles and S3 help, thanks to a very recent update to s3cmd. Configuring s3cmd to use IAM roles s3cmd is a command-line tool to access Amazon S3. Amazon S3 isn’t like a normal file share – it is only accessible through Amazon’s API. s3cmd provides access to S3 like a local directory, as well as administration of S3. It is available in most Linux repositories for packaged installation, but the bundled versions do not yet support IAM roles. Version 1.5 alpha 2 and later add role support, so that’s what we need to use. You can download the alpha 3 release, but if you are reading this post in the future I suggest checking for a more recent version on the main page, linked above. To install s3cmd just untar the file. If you aren’t using roles you now need to configure it with your credentials. But if you have assigned a role, s3cmd should work out of the box without a configuration file. Unfortunately I discovered a lot of weirdness once I tried to out it in a cloud-init script. The issue is that running it under cloud-init runs it as root, which changes s3cmd’s behavior a bit. I needed to create a stub configuration file without any credentials, then use a command-line argument to specify that file. Here is what the stub file looks like: [default] access_key = secret_key = security_token = Seriously, that’s it. Then you can use a command line such as: s3cmd –config /s3cmd-1.5.0-alpha3/s3cfg ls s3://cloudsec/ Where s3cfg is your custom configuration file (you can see the path there too). That’s all you need. s3cmd detects that it is running in role mode and pulls your IAM credentials if you don’t specify them in the configuration file. Scripted installation of the Chef client The Chef client is very easy to install automatically. The only tricky bit is the command-line arguments to skip the interactive part of the install; then you copy the configuration files where they are needed. The main instructions for package installation are in the Chef wiki. You can also use the omnibus installer, but packaged installation is better for automated scripting. The Chef instructions show you how to add the OpsCode repository to Ubuntu so you can “apt-get install”. The trick is to point the installer to your Chef server, using the following code instead of a straight “apt-get install chef-client”: echo “chef chef/chef_server_url string http://your-server-IP:4000” \ | sudo debconf-set-selections && sudo apt-get install chef -y –force-yes Then use s3cmd to download client.rb & validation.pem and place them into the proper locations. In our case this looks like: s3cmd –config /s3cmd-1.5.0-alpha3/s3cfg –force get s3://cloudsec/client.rb /etc/chef/client.rb s3cmd –config /s3cmd-1.5.0-alpha3/s3cfg –force get s3://cloudsec/validation.pem /etc/chef/validation.pem That’s it! Tying it all together The process is really easy once you set this up, and I went into a ton of extra detail. Here’s the overview: Set up your S3, Chef server, and IAM role as described in the previous post. Upload client.rb and validation.pem from your Chef server into your bucket. (Execute “knife client ./” to create them). Launch a new instance. Select the IAM Role you set up for Chef and your S3 bucket. Specify your customized cloud-init script, customized from the sample below, into the User Data field or command-line argument. You can also host the script as a file and load it from a central repository using the include file option. Execute chef-client. Profit. If it all worked you will see your new instance registered in Chef once the install scripts run. If you don’t see it check the System Log (via AWS – no need to log into the server) to see where you script failed. This is the script we will use for our training, which should be easy to adapt. #cloud-config apt_update: true #apt_upgrade: true packages: — curl fixroutingsilliness: – &fix_routing_silliness | public_ipv4=$(curl -s http://169.254.169.254/latest/meta-data/public-ipv4) ifconfig eth0:0 $public_ipv4 up configchef: — &configchef | echo “deb http://apt.opscode.com/ precise-0.10 main” | sudo tee /etc/apt/sources.list.d/opscode.list apt-get update curl http://apt.opscode.com/packages@opscode.com.gpg.key | sudo apt-key add – echo “chef chef/chef_server_url string http://ec2-54-218-102-48.us-west-2.compute.amazonaws.com:4000” | sudo debconf-set-selections && sudo apt-get install

Today I was mildly snarky on the Security Metrics email list when a few people suggested that instead of talking about cloud computing we should talk about shared infrastructure. In their minds, ‘shared’ = ‘cloud’. I fully acknowledge that I may be misinterpreting their point, but this is a common thread I hear. Worse yet, very frequently when I discuss security risks, other security professionals key in on multitenancy as their biggest concern in cloud computing. To be honest it may be the least interesting aspect of the cloud from a security perspective. Shared infrastructure and applications are definitely a concern – I don’t mean to say they do not pose any risk. But multitenancy is more an emergent property of cloud computing rather than an essential characteristic – and yes, I am deliberately using NIST terms. In my humble opinion – please tell me if I’m wrong in the comments – the combination of resource pooling (via abstraction) and orchestration/automation creates the greatest security risk. This is primarily for IaaS and PaaS, but also can apply to SaaS when it isn’t just a standard web app. With abstraction and automation we add a management layer that effectively network-enables direct infrastructure management. Want to wipe out someone’s entire cloud with a short bash script? Not a problem if they don’t segregate their cloud management and harden admin systems. Want to instantly copy the entire database and make it public? That might take a little PHP or Ruby code, but well under 100 lines. In neither of those cases is relying on shared resources a factor – it is the combination of APIs, orchestration, and abstraction. These aren’t fully obvious until you start really spending time using and studying the cloud directly – as opposed to reading articles and research reports. Even our cloud security class only starts to scratch the surface, although we are considering running a longer version where we spend a bunch more time on it. The good news is that these are also very powerful security enablers, as you will see later today or tomorrow when I get up some demo code I have been working on. Share:

Today on the Microsoft Security Response Center Blog: Under the policy, developers will have a maximum of 180 days to submit an updated app for security vulnerabilities that are not under active attack and are rated Critical or Important according to the Microsoft Security Response Center rating system. The updated app must be submitted to the store within 180 days of the first report that reproduces the issue. Microsoft reserves the right to take swift action in all cases, which may include immediate removal of the app from the store, and will exercise its discretion on a case-by-case basis. But the best part: If you have discovered a vulnerability in a store application and have unsuccessfully attempted to work with the developer to address it, you can request assistance by contacting secure@microsoft.com. Clear, concise, and puts users first. My understanding is that Apple is also pretty tight on suspending vulnerable apps, but they don’t have it formalized into visible policy, with a single contact point. If anyone knows Google’s policy (formal or otherwise), please drop it in the comments, but that is clearly a different ecosystem. Share:

Well, this is embarrassing: Blowing hash and signing functions so that the underlying code can be changed without the hash and sigs changing is horrifyingly atrocious. This is the code equivalent of impersonating a person with a mask so good nobody, not even the real person themselves, can tell the difference. … Google espouses 60 days to fix exploitable bugs and going public one week after private notification. According to Bluebox they told Google about this via bug 8219321 in February 2013. That’s a little bit more than 60 days ago. Seeing as it’s now July, I think (and I’m not very good at math, so bear with me here) that’s at least twice as many. It’s especially more than 7 days. I’m not sure how Google are following their own disclosure policy. I suspect the people motivated to publish Google’s disclosure policy were all or mostly on the web side. It is a much different problem when you are dealing with software updates, especially on a platform that often you cannot update. I have yet to find a ROM past Android 4.0 (current is 4.2) that I can get running on my test phone. HTC certainly isn’t providing it, which means many millions of phones will be vulnerable… forever. There was little doubt that publishing that policy wouldn’t eventually haunt them. Share:

An OpenStack Security Guide epub was released this week, and among the contributors was our friend Andrew Hay. Trying to find this info before was like locating a piece of hay in a haystack (not an Andrew Hay – he would be considerably easier to find in a haystack). We use OpenStack for the Cloud Security Alliance training labs, and I had to figure out a lot of this myself through painful reading of barely-legible documentation. The book was created in a 5-day sprint so it’s a little rough. Some sections are pretty light but they intend to improve it over time. The sections on hardening the Keystone identity service, picking a hypervisor, hardening core services such as the message queue, and secure networking, are pretty decent. You can’t secure OpenStack just by reading this – you need to understand the platform first – but this guide will definitely point you in the right directions. Share:

The FTC has issued new rules on data collection for minors: Now, the list of what counts as “personal information” has been expanded to include geolocation markers, IP addresses, pictures or audio of the child, and persistent cookies that can track users across sites. The rules also now apply to companies that make plug-ins or advertising networks, which often collect information but aren’t thought of as discrete sites that fall under the rules. I’m pulling my kids from daycare and having them do all my browsing. Then I can sue Google and anyone else who tracks me them. Share:

One of our favorite friends, Jack Daniels, has a new post on Active Defense: If you make the claim that “active defense” is only a euphemism for “hacking back”, you are either hyping an agenda, or selling a (probably outdated) security model. Or perhaps you’ve just been misled by the previously mentioned shysters. By my count that’s three flavors of wrong, although one may be slightly less bitter. … Let’s start with “active defense”. It is not a new idea, and it doesn’t necessarily mean hacking back. It may encompass counterattacks, but there are a lot of active defenses far short of attack. I refer you back to my post on active defense definitions last summer. I really don’t know where all the confusion is coming from – I meet almost no security professionals who don’t understand the difference. It seems to be more of a press/PR issue. Share:

Our schedules are already filling up for Black Hat this year, so if you want to meet please drop us a line. And for those who want a real schedule, [James Arlen put one together for easy import into your calendar].(https://www.google.com/calendar/ical/f9lvmur9pjc2r1oi7psi3li40s%40group.calendar.google.com/public/basic. Share:

Apple posted a page with some short details on the new business features of iOS 7. These security enhancements actually change the game for iOS security and BYOD: Data protection is now enabled by default for all applications. That means apps’ data stores are encrypted with the user passcode. For strongish passphrases (greater than 8 characters is a decent start) this is very strong security and definitely up to enterprise standards if you are on newer hardware (iPhone 4S or later, for sure). You no longer need to build this into your custom enterprise apps (or app wrappers) unless you don’t enforce passcode requirements. Share sheets provide the ability to open files in different applications. A new feature allows you, through MDM I assume, to manage what apps email attachments can open in. This is huge because you get far greater control of the flow on the device. Email is already encrypted with data protection and managed through ActiveSync and/or MDM; now that we can restrict which apps files can open in, we have a complete, secure, and managed data flow path. Per-app VPNs allow you to require an enterprise app, even one you didn’t build yourself, to use a specific VPN to connect without piping all the user’s network traffic through you. To be honest, this is a core feature of most custom (including wrapped) apps, but allowing you to set it based on policy instead of embedding into apps may be useful in a variety of scenarios. In summary, some key aspects of iOS we had to work around with custom apps can now be managed on a system-wide level with policies. The extra security on Mail may obviate the need for some organizations to use container apps because it is manageable and encrypted, and data export can be controlled. Now it all comes down to how well it works in practice. A couple other security bits are worth mentioning: It looks like SSO is an on-device option to pass credentials between apps. We need a lot more detail on this one but I suspect it is meant to tie a string of corporate apps together without requiring users to log in every time. So probably not some sort of traditional SAML support, which is what I first thought. Better MDM policies and easier enrollment, designed to work better with your existing MDM tools once they support the features. There are probably more but this is all that’s public now. The tighter control over data flow on the device (from email) is unexpected and should be well received. As a reminder, here is my paper on data security options in iOS 6. Share:

If you see any of these in a vendor sales/analyst presentation, run fast. They open with, “this is under NDA” or “this is confidential” and you have never signed an NDA. The word “unique”. Especially in the same sentence as “industry leader”. If you are unique, you are, by definition, both the leader and the worst piece of crap out there. You do not want to be Schroedinger’s cat; it never ends well. No screenshots of the product until slide 43, addendum 7, behind a slide that says, “stairs out, beware of tiger”. No slides describing how the technology works. Bonus points if they won’t tell you because a) they are in stealth mode, b) it is a trade secret, or c) their investors won’t let them talk about it until the patent is issued (expected August 12, 2046). How you see the industry or world. Just tell us what problem you solve – we decide whether it is more important than the other 274 items on our to-do list. Bonus points if you refuse to skip this section when asked. A slide of company logos you aren’t supposed to put on slides because it violates your contract. Always amusing when the same logo is in every competitor’s slide decks as well. Any reference to Katrina, Pearl Harbor, or 9/11. Use chaff if they append “digital” to any of those words. We stop the APTs. (Some grammar fails are worse than others). The term “insider threat”, unless you sell to prisons or proctologists. Any reference to Edward Snowden, Unless you are actually the NSA (or Booze Allen, but for other reasons). I’m not trying to slam any vendor, and for the most part both the product people and the smart marketing execs I spend most of my time with roll their eyes at all of this as well, but man, it sure is happening a lot lately. Share: