Archive for the ‘Security’ Category
Wittfield Diffie interview by MIT Technology Review – How Secure is Cloud Computing?
MIT Technology review recently posted a interview with crypto-hero Whitfield Diffie.
Although the entire interview is great, one stands out…
Technology Review: What are the security implications of the growing move toward cloud computing?
Whitfield Diffie: The effect of the growing dependence on cloud computing is similar to that of our dependence on public transportation, particularly air transportation, which forces us to trust organizations over which we have no control, limits what we can transport, and subjects us to rules and schedules that wouldn’t apply if we were flying our own planes. On the other hand, it is so much more economical that we don’t realistically have any alternative.
There’s another dimension to his analogy that we need to consider. When airplanes fail (i.e. hijacked), human lives may be lost and panic ensues. We haven’t yet, to my knowledge, have had a visible electronic attack that has such significant consequence (albiet the “Cyberterror” concern has been felt by Estonia). We’ve seen a few headaches, but nothing life theatening.Clearly, given the amount of control computers have over our lives, it’s only a matter of time. When that unfortunate time comes, what will occur? New laws and regulations? Direct government oversight? Will the industry police itself into innovating new technologies as a competitive advantage?
Let’s hope the latter. One of the key differences is that it’s hard to sell airline security. Would a consumer fly on Airline A rather then Airline B, knowing that the pilot of airline A could carry a gun, or had a more secure cockpit door? Do these things even really make us more secure?
The other difference is that air travel is a commodity and there’s not that much growth left. In fact, most businesses (the sweet spot customer of the airline industry) are cutting back travel. The airline industry is focused on taking share from each other, and the primary factor is “who can supply at the lowest price.” It’s hard for the airline business to change, since profits are scarce and growth is inhibited (new continents don’t seem to be popping up on the planet earth anymore).
In the IT/Internet/technology arena, there’s a few big differences:
- First, the computer security industry has proven that you can sell security to the end user — and you can certainly sell it to the business market. If I were building a company on a cloud platform, I’d pay a premium for the provider who could offer better security features.
- Second, with the cloud movement, the “right things” (storage, compute, network) are reverting to a commodity posture, which will lower the barriers for new, higher level, services to be built at scale. Lowing the barriers will ignite opportunity, and a rush to use cloud-based applications. Putting it another way, a few entrepreneurs can build a company on a cloud provider without buying datacenters, servers, power, gigantic network connections, and even hiring IT staff to build the servers out. In the cloud, all of this is done with a credit card and a few clicks of the mouse. If security issues emerge, the profit-motive will drive the cloud provider to quickly retool an offering to respond to a threat, or, they’ll be passed by.
However, in the meantime (and with the constant media attention focused on “cloud failures”) it will be a turbulent ride.
- Craig
Security Investigation & Forensics in the Cloud
As security professionals, we are tasked with securing data and investigating situations when a security breach occurs. However, as the cloud becomes a mainstream architectural option that businesses will undoubtedly embrace, there’s a bit of a problem for security practitioners: part of the business proposition of “the cloud” is all about losing control and abstracting the complexities and implementation details associated with infrastructure and applications.
This loss of control will present challenges for investigators, and will require a retooling of the traditional approaches that have been accepted by the computer forensic community. Investigators need control to obtain the appropriate knowledge of technical resources, process, and ability to interview associated individuals to digest a situation. In many forensic cases, we need to reconstruct the environment to recreate scenarios and test hypothesizes. Otherwise, our conclusions may not be trusted.
Before we dive into how “the Cloud” will monkey wrench the modern-day computer investigator mindset, we need to reflect on a few of the basics of investigation and forensics:
- Data has to be collected in a manner that maximizes its integrity.
- Preserving chain of custody for the “best evidence” is critical to admissibility in a court of law.
- Conclusions that are derived from evidence should be reproducible by peers through well-accepted methods, within a controlled, similiar environment.
If we take these tenets to a cloud context, many questions immediately come to mind…
- In the heavily virtualized/abstracted world of cloud computing, how can I identify and obtain the data that I need?
- In the distributed cloud model, what collateral data can I identify and collect to help me prove/disprove a hypothesis?
- What data does my provider log? How long do they keep it?
- What data will my provider give to me?
- What knobs can I turn up to get the data that I need?
- Does my provider expect me to do this in a self-serve fashion so they are not involved in the interpretation of data? Do they expect me to use an API that I can use to gather it?
- If I need to ask my provider for data, how long will it take them to produce it?
- How/will they vouch for the integrity of the data?
- How/will they transfer it to me in a way that preserves integrity?
- What/where exactly is the “best evidence”?
- What methods and procedures are accepted?
The answer to these questions are complex, and are not based upon “the cloud” itself. Why? Because “the cloud” itself isn’t uniform. Each provider will have their approach to their cloud offerings, and each will enable a different form and depth of investigation.
THE CLOUD -vs- US
Let’s set the context: thus far, mainstream cloud offerings are based on the Infrastructure as a Service (IaaS), Platform as a service (PaaS), and Software as a Service (SaaS) model. Let’s take a look at each, and the respective good/bad news in the context of investigation…
Software as a Service (SaaS): What is it? The SaaS model is the easiest to digest. A SaaS provider invokes an instance of an application for your organization. There are knobs that can be turned up and down, and basic configuration can be applied. The consumer may be able to interface with the application via an API, but you won’t have deep programmatic control that will modify the core application. Examples of this model: Google Gmail, Microsoft Online BPOS, the popular Less packages [http://lesseverything.com/solutions], and the Zoho suite [http://www.zoho.com].
- SaaS Good news: You might be able to get high level application logs. This data might log success and failures, and might reflect the actual activities within the environment. It will depend on what the provider decides to log, and how long they store it. In some cases, some services – such as federated authentication – may be handled by a separate service. This separate service (which may be operated by a completely separate provider) might have “collateral” data that you may find of interest, but you’ll have to figure out how to get it. The best news of this scenario is that you’ll be able to recreate the environment with a high level of accuracy* (of course, many disclaimers apply here). For example, in the SaaS email deployment, many providers of messaging solutions have an option for “message journaling.” This feature tells the provider to transparently forward a “carbon-copy” of all messages to archive service. This service can be used to gather evidence that sits in the organization’s email activity. However, to use it, you need to ensure that (a) it’s been purchased, (b) it is configured right (i.e. retention policy), and, in the case that you choose a different provider, (c) your email service is configured to send data to it.
- Bad news: Low level disk imaging? Very unlikely. Installing forensic tools to obtain system state information? Even more unlikely. Interpreting information? Difficult. You’ll need to know a lot about the application, and all of the scenarios that it can be used. For example, many SaaS accounting applications have (a) a web interface, (b) a client application, and (c) an web service API (that’s usually invoked with an API key (aka “shared secret authentication”). Will you be able to interpret log entries properly across these code paths? And, by the way, you may not have a version of the server-side software that you can deploy in your lab for low-level analysis.
Platform as a Service (PaaS): In this model, the consumer deploys application packages to a runtime environment that is hosted by a cloud provider. For example, if you use Microsoft Windows Azure, you build applications in Visual Studio, compile, and publish a package through the Azure developer portal . This package (and a respective configuration file) is uploaded to Azure, where it is executed within a uniform Windows/.NET runtime environment. Similarly, with Google applications, you can build Python or Java applications which can be uploaded to Google’s Application engine for execution. In this model, you own the core application, and programatically dictate how it will interacts with other dependencies (such as calling Database resources).
- PaaS Good news: Your dev organization controls the core application. Thus, you can log information as you desire (to both a location, such as blob storage, an external database (even at another Cloud provider!), or even SYSLOG to your SIEM solution). Since you have programmatic control of the platform, you can likely invoke custom code that interrogates system state and pulls logs. You just need to invest the time to configure it, and convince your development team that this feature is worth their time.
- PaaS Bad news: You may or may not be able to get logging information from the underlying runtime environment. This will depend on how the provider has it configured, and what they’ll allow you to query. In this model, there are two important elements of the platform that need to be considered. In the Microsoft stack, it’s (a) the virtualized OS, (b) IIS, and (c) the .NET runtime environment. The Google model is similar. There’s an OS, a web server, and a runtime environment (either Java or Python).
Infrastructure as a Service (IaaS): What is it? The consumer deploys virtual machines, in which they have administrative access. In some cases (GoGrid), the virtual machines use persistent storage (if a VM is rebooted, bits written to the disk will remain). Others, such as Amazon ECS, do not have persistent storage – when a VM is rebooted, it is “reset” back to the base VM image. In Amazon AWS, persistent storage is derived from writing bits to Amazon EBS (Elastic Block Storage), or other data repository (such as an Amazon SimpleDB).
- IaaS Good news: Although I haven’t tried it, I suspect that enterprise forensic software, such as Encase Enterprise, can be installed. You also have the ability to connect to the underlying VM (i.e. Linux console or Windows Terminal Services) to perform deep interrogation of the machine. Therefore, many of the “traditional” processes associated with forensics can be observed (such as querying system state). I’d also suspect that you can obtain low level disk access via iSCSI interface.
- More Good news: Many of the IaaS providers support snapshoting a running VM. So, you can capture the state of a running host quickly (and, for the ultra paranoid, perhaps via API that snapshots a host after system monitoring detects an abnormality).
- IaaS Bad news: To do this level of investigation, you’ll need some robust connectivity to the Internet (or provider’s network). It’s plausible that you can have a similarly hosted “security cloud” that has loose coupling (and robust connectivity) to your “production cloud” where you can pull disk images, system state, etc, etc.
BLOCK STORAGE
There is a storage concept “in the cloud” that span a few of these offerings. To enable “infinite” storage on a pay-per-use business model, many cloud providers are building “block storage.” Why does this matter? It’s because block storage isn’t the traditional file system that forensic practitioners hold close to their hearts and toolsets. In most cases, we grab a disk image and carve through the image looking for data. The evolution of “grabbing a disk image” is interesting — when most IT was on site, we’d just remove the disk, hook it up to an imaging environment, and grab a bitstream image. When IT became distributed, quite a few tools and techniques allowed us to remotely image machines. With a mere copy of dd and netcat, our world was only limited by bandwidth. However — in the cloud — the next step is unclear.
Cloud-based block storage contains a level of data abstraction that is great for the business folks (who write checks based on what is actually used), developers (cloud based storage is heavily abstracted through flexible APIs), and architects (who no longer need to worry about site-level, and in some cases, global fault tolerance).
However, for our forensic mindset, all access to block storage is via a platform-specific API, and there is no ability to “image” cloud-based block storage to “carve” through unallocated data, looking for remnants of activities. Access to this storage is purely logical — and completely focused on allocated space. [Note: This is my current understanding on the APIs available at the time of this writing. If anyone knows otherwise, please contact me..]
NEXT STEPS…
In conclusion, I’m not ready to throw away my traditional investigation tools quite yet. But, I do believe that the cloud is driving many macro factors that will require a massive recalibration of our tools, techniques, and understanding. The rate at which systems can be rebuilt (since one only needs a credit card to provision new service) will be fast – and the tidal wave of new technologies to master will be daunting.
However, the super optimistic, revolution-through-evolution perspective is also clear — SaaS and PaaS cloud offerings will poise some opportunity for us to push better security logic and logging higher in the stack — into our applications. It may also ignite the opportunity for SIEM providers to have cloud offerings, and publish some standardized APIs to allow us to easily and programmatically push log data into their platform – and perhaps more importantly – into a more standardized taxonomy (if you’ve configured a SIEM solution for custom applications, you know what I mean!).
Craig
Cloud404 Blog Kickoff
We are entering another major cycle of information technology. Let’s call it “the cloud” cycle. The world is faced with many economic woes, and technology can often play a key role in fueling a comeback by increasing productivity, opening new arenas of innovation, and bringing increased value from each dollar spent. In order to get businesses and consumers spending again, the tech world needs to come up with the next big thing.. and that big thing seems to be “cloud computing.”
This technology offers unlimited scale, and uses resources as they are needed. There are plenty of articles about the wonders of the cloud , so I won’t take up valuable bytes on the Internet to rehash them.
Software providers are racing to build new products that leverage the cloud paradigm. There is also considerable effort to “retool” current software to embrace the various principles associated with “the cloud.” At the same time, product marketing is figuring out how to convince the marketplace that cloud hosted resources are less complex, more secure, cheaper, and a requirement to survive in the globally connected and hyper-competitive marketplace of the future (as if it isn’t already!).
From a personal computing perspective, each of us has that “gut feeling” that makes us peer through the marketing and ask common sense questions before we move our digital lives into the cloud… is the risk too high? Will the odds of my identity being stolen increase if my data is stored across multiple providers, across the planet, operated by who-knows-who? Will one of these providers crash, and never come back? Will I lose my cat pictures?
From a business perspective, there’s a bigger problem. The last era of IT was marked by (a) new laws that drove (b) huge spending which created a (c) ton of enterprise jobs that (d) established a long list of best practices related to computer security and IT audit. Can the cloud meet their requirements? These very investments may have helped build the foundation that has taken us to a point where we can peer over the edge and consider cloud computing.. but, are we ready to jump? Even if we aren’t ready to jump, are we going to be forced to jump because everyone else — who you are collaborating and competing with — is?
The intense media attention to cloud failures and uncertainty will drive many new and interesting conversations. I’d also suggest that the rate at which these conversations are occurring illustrates that the mass market is in touch with the realities of the cloud, and there’s a pretty firm understanding of the underlying concepts even though the respective technologies that fuel the concepts are quite complex. But, since the cloud is all about abstracting complexity, we don’t need to understand the technology.. right? Or must we take the time to ask the right questions to make effective decisions and use the cloud appropriately? For example:
- Goal: Lower costs (capital and operational) related to data storage. Increase failure resilience (i.e. disk crash).
- Market Offering: Cloud Based Data Store. Unlimited. Pay per Gigabyte. Backups performed.
- Solution: Put it in the cloud using provider XY
- Question: How is it secured? Is it encrypted? If so, how
- Answer: Secured with password (or API access key). Not encrypted.
- Risks: Bad guy could get the password and get the data. Inside employees at the provider could read the data. Various legal issues related to subpoenas. Provider gets hacked, and data is compromised…List goes on and on..
- Mitigation: Implement a layer of encryption on all data written (likely via client software or middleware) to the cloud provider. Do not give cloud provider keys.
To solve this simple scenario, one must understand the goals, ask the right questions, quantify the risks, and ensure that mitigation is feasible. Fortunately, this scenario has been well thought out and we can see that the market has developed quite a few great solutions. There’s plenty of other, much more complex, scenarios to tackle.
I’d also suggest that we instinctively understand that the assumptions we’ve had for the last few years regarding our “trust” of our computing environment are ready to change. In 2002, Bill Gates sent the infamous Microsoft “Trustworthy Computing” memo, where he claimed that a trustworthy computing platform doesn’t exist. In 2002, most of us considered the “technology platform” to be the individual PC that we use. I don’t think many people trusted their computer in 2002. However, in 2009, I’d argue that the trust of the computer has risen significantly.
As I write this blog post, I reflect on a few key differences in how I compute now versus in 2002. In 2002, I had all of my documents on a PC or a network share. I fondly recall the release of SharePoint 2003 with great Office integration, which allowed me to easily store my Office documents “somewhere else.. on the SharePoint server.” This gave me assurance that they’d be safe if my PC was lost or suddenly thrown out of the window (I have a medical condition known as “buggy 32-bit device driver rage”). For other resources, I had a daily battle syncing content across my various PCs that didn’t share a common network drive.
Now, I build PCs with 32 gigabyte drives (I’ve standardized on power friendly, speedy solid state drives). I simply don’t need much local storage (with the exception of the occasional 1TB drive for video editing). I store all of my files online – “in the cloud” (although, most are just hosted services by various providers that don’t likely apply cloud principles). I read RSS feeds, store photos, sync bookmarks, build mind maps, store office documents, create presentations, backup documents, and even do my taxes with a “cloud” provider. I’ve stepped up to the reality that I don’t have time to administer my own mail server anymore, and I use an external provider for personal email. Perhaps I’m getting too old to have the passion to run my own mail server, or, perhaps it’s commodity infrastructure that I don’t have to deal with so I can focus my time elsewhere. Regardless, I can access everything — from my phone to multiple PCs I use — from anywhere, from my various platforms, and not battle with data replication issues.
The context of the Bill Gates “Trustworthy Computing” memo is going to change in the cloud era. It’s time to look beyond the trustworthiness of the individual computing platform and start to digest the realities of trusting “the cloud” platform, too.
The following trust-oriented questions tend to arise across other blog postings and conversations that pertain to cloud computing. Most of these “common sense” questions focus on the reality that control of traditional IT infrastructure will be lost as the cloud paradigm is adopted:
- When I choose a vendor, what happens if they suddenly “go away?”
- What happens if the vendor increases the price that I need to pay to use the service? Am I locked in? What is the difficulty in migrating?
- Does the vendor run their offerings with operational sanity? What are the chances of pilot error?
- If I need to convince my family or management (and auditors) that our data is secure, what proof can I provide?
- Where is the data stored? How is it backed up?
- How strong is the business continuity plan of the provider?
- How do I know if my data is breached?
- What do I do if my data is breached? How do I investigate?
- What will my provider tell me about the scope and nature of the breach? Who is liable? Who is culpable in the customer breach notification (note: congress is currently considering Federal breach notification laws!)?
Behind the scenes and at a high level, providers still practice change control, monitor and investigate security events, and perform operational incident management. Given the scale that providers deal with, will they take the time to explain what they do? Is the explanation a “one off” explanation to appease you, or is it applied to all of their customers (which makes the process more predictable)? Alternatively, the response could be a Jedi hand wave diverting your attention back to the “it’s cloud, so you don’t need to worry about it” panacea. Or, “don’t worry about it because we have an SLA with financial consequences and that certainly isn’t in our best interest” reply. According to Gartner, cloud computing providers who refuse to undergo scrutiny are “signaling that customers can only use them for the most trivial functions.” I don’t disagree with this, but I expect it will take time for service providers to getting the story right — especially since the scale, tenancy, and internal factors within a service provider scenario differ from running enterprise IT. So, even if the answer isn’t perfect at this time, the market will demand clarity and evidence over time.
So, this is likely a good entry point for the blog, and will drive our hypothesis that the most important — yet difficult to quantify — decision associated with your adoption of cloud computing revolves around risk.
From now on, we’ll zoom into specific topics associated with security, privacy, compliance, and … risk.. within the cloud.
Until then, doveryai, no proveryai.
- Craig
