Research

This is the first post in a series on the future of information security, which will be the basis for a white paper. You can leave feedback here as a blog comment, or even directly submit edits over at GitHub, where we run the entire editing process in public. This is the initial draft, and I expect to trim the content by about 20%. The entire outline is available. A Disruptive Collision At the best of times, the practice of information security is defined by disruption. We need to respond to business and technology innovations – not only from those we defend, but also from their attackers. Security is never really in control of our own destiny – we are tasked with managing the risks of decisions made by others, in the face of entire industries (and economies) dedicated to discovering new ways of stealing or hurting them and us. We are reactive because those we protect and those who attack are never fully predictable – not because of an inherent failing of security. But the better we predict these disruptions, and the better we prepare our response, the more effective we are. As analysts, we at Securosis focus most of our research on the here and now – on how best to tackle the security challenges faced by CISOs and security professionals when they show up to work in the morning. Occasionally as part of this research we note trends with the potential to dramatically affect the security industry and our profession. We currently see what appears to be the largest combination (collision) of disruptive forces since the initial adoption of the Internet – with implications for security far beyond our first tentative steps onto the global network. Additionally, we have identified six key trends which are currently altering the practice of security. This combination of external and internal change is fundamentally transforming the practice of security. This paper starts with a description of the disruptive forces and the native security trends, but its real objective is to lay out their long-term implications for the practice of security – and how we expect security to evolve for security professionals, security vendors, and cloud and other infrastructure providers. Through the report we will back up our analysis with real-world examples that show this transformation isn’t a vague possibility in a distant future, but is already well under way. But although these changes are inevitable, they are far from evenly distributed. As you will see, this provides plenty of time and incentive for professionals and organizations to prepare. Two Disruptive Innovations Clayton Christensen first coined the term “disruptive technology” in 1995 (he later changed the term to “disruptive innovation”) to describe new business and technology practices that fundamentally alter, and eventually supersede, existing ones. Innovation always causes change, but disruptive innovation mandates change. Innovation creates new opportunities and disrupts old ones. The technology world is experiencing a combination of two disruptive innovations simultaneously colliding and reinforcing each other. Cloud computing alters the consumption and delivery models for technology at both economic and technical levels. Advances in mobile technology are changing our access and consumption models, and reinforcing demand for the cloud – particularly at scale. Cloud Computing Cloud computing is a radically different technology model – it is not simply the latest flavor of outsourcing. It uses a combination of abstraction and automation to achieve previously impossible levels of efficiency and elasticity. This, in turn, creates new business models and alters the economics of technology delivery and consumption. Sometimes this means building your own cloud in your own datacenter; other times it means renting infrastructure, platforms, and applications from public providers over the Internet. Public cloud services eliminate most capital expenses, shifting them to on-demand operational costs instead. Private clouds allow more efficient use of capital, may reduce operational costs, and make technology more responsive to internal needs. Cloud computing fundamentally disrupts traditional infrastructure because it is more responsive, more efficient, and potentially more resilient and cost effective than our old ways of doing things. These are the same drivers that pushed us toward application service providers and virtualization. Public cloud computing is even more disruptive because it enables organizations to consume only what they need without maintaining overhead, while still rapidly responding to changing needs at effectively infinite scale (assuming an adequate checkbook). Every major enterprise we talk with today uses cloud services, and even some of the most sensitive industries, such as financial services, are exploring more extensive use of public cloud computing. We see no technical, economic, or even regulatory issues slowing this shift. Many security professionals focus on the multitenancy risks introduced by cloud, but abstraction and automation are more significant than shared infrastructure or services. Many security controls today rely on knowing and managing the physical resources that underpin our technology services. Abstraction breaks this model by virtualizing resources (including entire applications) into resource pools managed over the network. We give up physical control and shift management functions to standard network interfaces, creating a new management plane. This separation and remote management challenge or destroy traditional security controls. Abstraction is central to virtualization, and we are at least nominally familiar with its issues. But this kind of automation is specific to the cloud, and adds an orchestration layer to efficiently utilize resource pools. It enables extreme agility, such as servers that exist only for hour or minutes – automatically provisioned, configured, and destroyed without human interaction. Application developers can check in a piece of code, which then runs through a dozen automated checks and is pushed into production on a self-configuring platform that scales to meet demand. Security that relies on controlling the rate of change, or that mandates human checks, simply cannot keep up. Virtualization is the core enabling technology of abstraction, and Application Programming Interfaces (APIs) are the core enabler of automation. The elasticity and agility they together provide enable new operational models such as DevOps, which consolidate historically segregated management functions to improve efficiency and responsiveness. Combined with greater reliance on public cloud computing, the Internet itself becomes the interconnected platform for our applications and workloads. Defining DevOps

Update: Here are links to the series as we post it: Post 1 Post 2 Post 3 Post 4 Post 5 Back in 2012 I wrote a post titled Inflection. It was a collection of ideas and trends I have been watching, with the implications for the practice of security. This year I submitted it to the RSA Conference and it was accepted. I will be giving an updated presentation based on that post Tuesday afternoon. I thought that would be the end of it, because this isn’t the sort of research someone is usually interested in licensing and so it stays on the blog. But I was contacted by the folks at Box who were looking for something different that focuses more on where the industry is headed than our usual papers on helping you manage a current security issue. As an analyst I believe the majority of my published research should focus on day-to-day management of security, but it is also important to push the edges a bit and spend time thinking about the bigger picture. I am particularly excited about this paper because it isn’t being licensed by a traditional security vendor. The call from Box came out of left field, and shows that cloud and content providers are seeing security as a competitive differentiator. That isn’t an endorsement – no one can ever pay us to say nice things about them, but I can honestly say we are doing more work this year outside the traditional security market than I have ever seen before. To wet your whistle as I start writing the content, here’s a graphic of the outline. I will also be putting the content up on GitHub as I write and edit it for public feedback and review. I’m finding I like that better than the blog for the people who want to provide feedback, but this feed is better for getting the draft content out to a wide audience. We’ll take feedback on either side. Oh, and I could really use some help with a better title! This one feels a little pretentious to me, but I am struggling for something better and “Inflection” doesn’t translate well to a paper. Thanks, and here’s the outline: Share:

In this week’s Firestarter Rich, Mike, and Adrian (until his computer died) discuss the importance (or lack thereof) of the security industry and community in influencing government. Adrian drops out part-way through due to his frugal laptop choice, but rumor is he whipped out the credit card and payed homage to Apple shortly after the conclusion of this week’s recording. Share:

I realize this will shock many of you, but I hated beer in high school and the first couple years of college. I know, I know, this destroys your image of me, but it’s the truth. I blame it on orange soda. My parents weren’t big soda drinkers, so I wasn’t really exposed to it. The first time I tried an orange soda at a birthday party in elementary school, the carbonation freaked me out and that was the end. My anti-carbonation stance carried over when we started on beer in high school (don’t tell the cops). Plus, beer back then sucked. I was still a young male and would drink beer when nothing else was around, but I tended towards kamikazes. Until the night I got so drunk that when my friends dropped me off at home I freaked out over someone stealing my car. You know, the one I drove to the bar earlier that night and (wisely) left there. The hangover lasted three days – so much for the immunity of youth. But then I discovered Buff Gold. In 1990 the Walnut Brewery, the first brew pub in Boulder, opened up. Shortly afterwards I was hired as a 19 year old 140 lb (wet) bouncer. It was a mellow crowd. I couldn’t drink there as an underage employee, but a couple other bars owned by the same guy carried the beer. Buffalo Gold was the first ale I ever tried, and started me down a path of refined malty (and responsible) consumption. As a side note, Frank Day, the owner, later opened the first Rock Bottom brewery in Denver (same franchise, different name). He also started the Old Chicago’s chain. Rock Bottom is all over the place, and merged with Gordon Beirsch a few years ago, which also owns Big River Brewery, the only brew pub at Disney World (on the Boardwalk). I keep showing my Walnut Brewery nametag at Disney, but they still make me pay for my beers. When they let me in the door. Anyhoo… after Buff Gold came Fat Tire, which migrated down from Fort Collins an hour north of Boulder. Then all sorts of craft beers exploded, which explains why the American Homebrewers Association offices were around the corner from my old Boulder condo. Turns out I didn’t hate beer, I just hated bad beer. After I moved to Phoenix a Yard House opened up near us and my (now) wife and I started spending most Friday happy hours there. That’s when I met The Bastard. Arrogant Bastard, if you are being formal, and it is about as serious a beer as you can find. After that anything short of an IPA seemed almost tasteless, and I became obsessed with California hops. I also loved the naming and marketing used by the Stone Brewing company. Beers like Ruination and Sublimely Self Righteous. Tag lines like, “You’re Not Worthy” and “you probably won’t like this beer”. When my wife was pregnant with our first child she deigned to take the Stone Brewery tour when we were out in San Diego, despite being unable to drink. That’s when I realized the marketing genius of their aggressive, no-nonsense approach. After… a few pints… I emailed Adrian and informed him I had our new corporate branding. “No B.S. Research”, “If you want to feel good about yourself, call your mom. If you want a security program, call us”, and the rest of our site and attitude. It has been five years since that trip, and our distinct divergence from traditional professionalism. And you know what? People like honesty. And the ones who don’t aren’t the sorts we want to work with anyway. It’s a nice filter that drives the kinds of clients and engagements that make this such an awesome job, and save us from endless piles of lapdogging and paperwork. And it all started with a beer. Like anything else worth a damn. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on DBaaS. Dave Lewis in The Atlantic: This Little House in Wyoming Didn’t Just Get Flooded With Web Traffic From China. Favorite Securosis Posts Adrian Lane: The Catalyst. Someone sent me the book this week. Care to guess who? Rich: The SIXTH Annual Disaster Recovery Breakfast (with 100% less boycott). Yes, it’s a repost, but RSVP anyway. Other Securosis Posts Mindfulness Works. Firestarter: Target and Antivirus. Eliminate Surprises with Security Assurance and Testing [New Paper]. Favorite Outside Posts Adrian Lane: Metadata for beginners 😉. My favorite of the week was not a post, but a tweet. It only takes a couple fat-fingered cell calls from a ‘suspect’ to make you part of their social circle. Chris Pepper: More security is always better, right? Domain registrar auto-enrolls customers into $1,850 security service. Er. Dave Lewis: The death of Windows XP. Rich: Increased Cyber Security Can Save Global Economy Trillions. Funny numbers, but once again we see security hitting the mainstream. Research Reports and Presentations Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Top News and Posts Chinese Internet Traffic Redirected to Small Wyoming House. Huh. Notes from Shmoocon 2014. Office.com Defaced by Syrian Electronic Army. RootCloak Hides Root Access From Specific Applications. Chrome hack lets websites keep listening after you close the tab. “70,000 healthcare.gov records hacked” claim turns out to be Google results. Oops; press fail. Again. Blog Comment of the Week This week’s best comment goes to DS, in response to A Very Telling Antivirus Metric. “We stop 0 day* attacks” *in this sense 0 indicates the number of attacks we successfully stop. Always gotta read the fine print. Share:

In this week’s Firestarter Rich, Mike, and Adrian discuss the latest in the Target relevations and whether over-reliance on antivirus is to blame once again. We aren’t out to blame the victim. We also pick our top prevention strategies for this sort of attack. Ain’t hindsight great? Share:

From Brian Krebs’ awesome reporting on the Target breach (emphasis added): The source close to the Target investigation said that at the time this POS malware was installed in Target’s environment (sometime prior to Nov. 27, 2013), none of the 40-plus commercial antivirus tools used to scan malware at virustotal.com flagged the POS malware (or any related hacking tools that were used in the intrusion) as malicious. “They were customized to avoid detection and for use in specific environments,” the source said. That source and one other involved in the investigation who also asked not to be named said the POS malware appears to be nearly identical to a piece of code sold on cybercrime forums called BlackPOS, a relatively crude but effective crimeware product. BlackPOS is a specialized piece of malware designed to be installed on POS devices and record all data from credit and debit cards swiped through the infected system. I swear I’ve been briefed by a large percentage of those vendors on how their products stop 0-day attacks. Let me go find my notes… Share:

I am currently polishing off the first draft of my Data Security for iOS 7 paper, and reached one fascinating conclusion during the research which I want to push out early. Apple’ approach is implementing is very different from the way we normally view BYOD. Apple’s focus is on providing a consistent, non-degraded user experience while still allowing enterprise control. Apple enforces this by taking an active role in mediating mobile device management between the user and the enterprise, treating both as equals. We haven’t really seen this before – even when companies like Blackberry handle aspects of security and MDM, they don’t simultaneously treat the device as something the user owns. Enough blather – here you go… Apple has a very clear vision of the role of iOS devices in the enterprise. There is BYOD, and there are enterprise-owned devices, with nearly completely different models for each. The owner of the device defines the security and management model. In Apple’s BYOD model users own their devices, enterprises own enterprise data and apps on devices, and the user experience never suffers. No dual personas. No virtual machines. A seamless experience, with data and apps intermingled but sandboxed. The model is far from perfect today, with one major gap, but iOS 7 is the clearest expression of this direction yet, and only the foolish would expect Apple to change any time soon. Enterprise-owned devices support absolute control by IT, down to the new-device provisioning experience. Organizations can degrade features as much as they want and need, but the devices will, as much as allowed, still provide the complete iOS experience. In the first case users allow the enterprise space on their device, while the enterprise allows users access to enterprise resources; in the second model the enterprise owns everything. The split is so clear that it is actually difficult for the enterprise to implement supervised mode on an employee-owned device. We will explain the specifics as we go along, but here are a few examples to highlight the different models. On employee owned devices: The enterprise sends a configuration profile that the user can choose to accept or decline. If the user accepts it, certain minimal security can be required, such as passcode settings. The user gains access to their corporate email, but cannot move messages to other email accounts without permission. The enterprise can install managed apps, which can be set to only allow data to flow between them and managed accounts (email). These may be enterprise apps or enterprise licenses for other commercial apps. If the enterprise pays for it, they own it. The user otherwise controls all their personal accounts, apps, and information on the device. All this is done without exposing any user data (like the user’s iTunes Store account) to the enterprise. If the user opts out of enterprise control (which they can do whenever they want) they lose access to all enterprise features, accounts, and apps. The enterprise can also erase their ‘footprint’ remotely whenever they want. The device is still tied to the user’s iCloud account, including Activation Lock to prevent anyone, even the enterprise, from taking the device and using it without permission. On enterprise owned devices: The enterprise controls the entire provisioning process, from before the box is even opened. When the user first opens the box and starts their assigned device, the entire experience is managed by the enterprise, down to which setup screens display. The enterprise controls all apps, settings, and features of the device, down to disabling the camera and restricting network settings. The device can never be associated with a user’s iCloud account for Activation Lock; the enterprise owns it. This model is quite different from the way security and management were handled on iOS 6, and runs deeper than most people realize. While there are gaps, especially in the BYOD controls, it is safe to assume these will slowly be cleaned up over time following Apple’s usual normal improvement process. Share:

Last week I wrote up my near epic fail on Amazon Web Services where I ‘let’ someone launch a bunch of Litecoin mining instances in my account. Since then I received some questions on my forensics process, so I figure this is a good time to write up the process in more detail. Specifically, how to take a snapshot and use it for forensic analysis. I won’t cover all the steps at the AWS account layer – this post focuses on what you should do for a specific instance, not your entire management plane. Metadata The first step, which I skipped, is to collect all the metadata associated with the instance. There is an easy way, a hard way (walk through the web UI and take notes manually), and the way I’m building into my nifty tool for all this that I will release at RSA (or sooner, if you know where to look). The best way is to use the AWS command line tools for your operating system. Then run the command aws ec2 describe-instances –instance-ids i-5203422c (inserting your instance ID). Note that you need to follow the instructions linked above to properly configure the tool and your credentials. I suggest piping the output to a file (e.g., aws ec2 describe-instances –instance-ids i-5203422c > forensic-metadata.log) for later examination. You should also get the console output, which is stored by AWS for a short period on boot/reboot/termination. aws ec2 get-console-output –instance-id i-5203422c. This might include a bit more information if the attacker mucked with logs inside the instance, but won’t be useful for a hacked instance because it is only a boot log. This is a good reason to use a tool that collects instance logs outside AWS. That is the basics of the metadata for an instance. Those two pieces collect the most important bits. The best option would be CloudTrail logs, but that is fodder for a future post. Instance Forensics Now on to the instance itself. While you might log into it and poke around, I focused on classical storage forensics. There are four steps: Take a snapshot of all storage volumes. Launch an instance to examine the volumes. Attach the volumes. Perform your investigation. If you want to test any of this, feel free to use the snapshot of the hacked instance that was running in my account (well, one of 10 instances). The snapshot ID you will need is snap-ccd3e9c6. Snapshot the storage volumes I will show all this using the web interface, but you can also manage all of it using the command line or API (which is how I now do it, but that code wasn’t ready when I had my incident). There is a slightly shorter way to do this in the web UI by going straight to volumes, but that way is easier to botch, so I will show the long way and you can figure out the shorter alternative yourself. Click Instances in your EC2 management console, then check the instance to examine. Look at the details on the bottom, click the Block Devices, then each entry. Pull the Volume ID for every attached volume. Switch to Volumes and then snapshot each volume you identified in the steps above. Label each snapshot so you remember it. I suggest date and time, “Forensics”, and perhaps the instance ID. You can also add a name to your instance, then skip direct to Volumes and search for volumes attached to it. Remember, once you take a snapshot, it is read-only – you can create as many copies as you like to work on without destroying the original. When you create a volume from an instance it doesn’t overwrite the snapshot, it gets another copy injected into storage. Snapshots don’t capture volatile memory, so if you need RAM you need to either play with the instance itself or create a new image from that instance and launch it – perhaps the memory will provide more clues. That is a different process for another day. Launch a forensics instance Launch the operating system of your choice, in the same region as your snapshot. Load it with whatever tools you want. I did just a basic analysis by poking around. Attach the storage volumes Go to Snapshots in the management console. Click the one you want, right-click, and then “Create Volume from Snapshot”. Make sure you choose the same Availability Zone as your forensics instance. Seriously, make sure you choose the same Availability Zone as your instance. People always mess this up. (By ‘people’, I of course mean ‘I’). Go back to Volumes. Select the new volume when it is ready, and right click/attach. Select your forensics instance. (Mine is stopped in the screenshot – ignore that). Set a mount point you will remember. Perform your investigation Create a mount point for the new storage volumes, which are effectively external hard drives. For example, sudo mkdir /forensics. Mount the new drive, e.g., sudo mount /dev/xvdf1 /forensics. Amazon may change the device mapping when you attach the drive (technically your operating system does that, not AWS, and you get a warning when you attach). Remember, use sudo bash (or the appropriate equivalent for your OS) if you want to peek into a user account in the attached volume. And that’s it. Remember you can mess with the volume all you want, then attach a new one from the snapshot again for another pristine copy. If you need a legal trail my process probably isn’t rigorous enough, but there should be enough here that you can easily adapt. Again, try it with my snapshot if you want some practice on something with interesting data inside. And after RSA check back for a tool which automates nearly all of this. Share:

Okay, we have content in this thing. We promise. But we can’t stop staring at our new title video sequence. I mean, just look at it! This week Rich, Mike, and Adrian discuss Target, Snapchat, RSA, and why no one can get crisis communications correct. Sorry we hit technical difficulties with the live Q&A Friday, but we think we have the kinks worked out (I’d blame Mike if I were inclined to point fingers). Our plan is to record Friday again – keep an eye on our Google+ page for the details. Share:

Over the past few years I have spent a lot of time traveling the world, talking and teaching about cloud security. To back that up I have probably spent more time researching the technologies than any other topic since I moved from being a developer and consultant into the analyst role. Something seemed different at such a fundamental level that I was driven to put my hands on a keyboard and see what it looked and felt like. To be honest, even after spending a couple years at this, I still feel I am barely scratching the surface. But along the way I have learned a heck of a lot. I realized that many of my initial assumptions were wrong, and the cloud required a different lens to tease out the security implications. This paper is the culmination of that work. It attempts to break down the security implications of cloud computing, both positive and negative, and change how we approach the problem. In my travels I have found that security professionals are incredibly receptive to the differences between cloud and traditional infrastructure, but they simply don’t have the time to spend 3-4 years researching and playing with cloud platforms and services. I hope this work helps people think about cloud computing differently, providing practical examples of how to leverage and secure it today. I would like to thank CloudPassage for licensing the paper. This is something I have wanted to write for a long time, but it was hard to find a security company ready to take the plunge. Their financial support enables us to release this work for free. As always, the content was developed completely independently using our Totally Transparent Research process – this time it was actually developed on GitHub to facilitate public response. I would also like to thank the Cloud Security Alliance for reviewing and co-branding and co-hosting the paper. There are two versions. The Executive Summary is 2 pages of highlights from the main report. The Full Version includes an executive summary (formatted differently), as well as the full report. As always, if you have any feedback please leave it here or on the report’s permanent home page. Executive Summary: What CISOs Need to Know About Cloud Computing (PDF) Full Report: What CISOs Need to Know About Cloud Computing Share: