Guest Post @ The Security Catalyst
“Is Cloud Computing Right for Your Business?”
Read it here…
Cloud Investigation – Part Deux
As “the cloud” becomes an architectural operation for businesses to leverage, many questions arise that — given what security pros have been through over the last 10 years — seem basic:
- How is data protected?
- How is data accessed by my applications or those of a business partner?
- If there is an incident, how can I investigate and what evidence can I collect?
Questions #1 and #2 will likely get the most initial attention as “the cloud” matures and is embraced. However, once the move to the cloud is made and an incident occurs, question #3 will jump in priority.
I’d like to share some thoughts related to the differences of investigations within “the cloud” versus those that have a more traditional tone (i.e. a server that is on premise and under full control, or a single laptop computer where you can quickly obtain a hard drive and memory image).
First, there’s an important distinction to be made. In some cases — especially in consumer-focused services — very little investigation can be performed (that is, unless you have subpoena power). Providers simply don’t offer such interfaces because consumers (a) generally don’t perform investigative activities and (b) many privacy issues arise. For example, it’s difficult to determine who has actually browsed photos that are being stored online via a photo management service. This makes sense, because most consumers aren’t very paranoid about who is browsing their photos and the security controls that the providers offer tend to be straightforward. However, with a service such as e-mail, some consumers would like to know if an outsider is gaining access to their information. For example, within Google’s Gmail, one can see a list of the last few IP addresses (and the client type) that has accessed a mailbox. Basically, you are given what the application provider wants you to have. It’s difficult — if not impossible — to peel back the onion and access the data that is often needed to foster technically accurate conclusions. Also, the services are usually low-cost (or free), so the phrase “you get the support that you pay for” usually rings true.
Next, if we look at the enterprise scenario, access to low-level data within the security investigation process is quite important. The enterprise wants to peel back the onion and obtain low level information for how the application is behaving, even if it is running “the cloud.” When a security incident occurs, enterprise security teams want to be empowered to perform their own investigation without dependency on the provider. From a provider perspective, “self-service” is an important element to achieve product scale. So, we have to figure out how to do investigate, and where we can (a) determine what information we can get, and (b) where/how we can obtain it.
Let’s rewind a bit — when a business decides to adopt cloud computing, it’s likely in one of the following deployment options:
- Software as a service (SaaS): Microsoft Online BPOS, Google Gmail, etc. High in the stack. You consume the software, and can’t programmatically alter how it behaves (however, it’s likely there are a few knobs to change configuration).
- Platform as a service (PaaS): Microsoft Azure, Google Apps, etc. You consume a platform, and upload applications that run within the provider’s “hosted sandbox.” In this model, there’s little access to the underlying OS, but you can upload code that runs at the provider’s site.
- Infrastructure as a service (IaaS): Amazon AWS, GoGrid, etc. Full access to virtual machines running on the provider’s site.
In each of these scenarios, data has different states:
- Data is at rest, written on the disk within an application-specific or OS-specific file format. This state may contain de-allocated data (i.e. deleted files) that may not be used by the application or operating system, but is still accessible since it has not been reallocated and overwritten.
- Data is in motion, being transmitted from a source to a destination over a network via numerous protocols, all encapsulated within each other, and each with different types of security (or, frequently within old protocols and applications, none at all)
- Data is in execution, loaded into memory as a process, which contains series of executable steps that the processor is going to execute (threads). A process may need to reference data (such as a file), so it loads it into memory. Therefore, if you look at a snapshot of the memory of a server at any given time, you’d find process information, machine instructions, and allocated/de-allocated data. In this state, data may be de-allocated (i.e. memory that has been de-allocated by a process and not yet reallocated/overwritten), but is still accessible.
Within each deployment option, the accessibility of data within each state differs. In addition, so do the primary and collateral investigative sources of data.
I’ve tried to build out a few matrices to further understand the intersections, and how to focus investigative & evidence collection activities.
Certainly a work in progress, but you may find them helpful..
Infrastructure-as-a-Service (click to enlarge)
Platform-as-a-Service (click to enlarge)
Software-as-a-Service (click to enlarge)
Cracking in the Cloud
Looks like password cracking is moving to the cloud. In this case, it’s cracking WPA Wireless encryption from a simple protocol sniff. In this case, the attacker only needs about $17 and the ability to intercept some network packets. Not difficult..
A cloud-based password “auditing” service clearly makes sense.. of course, only for auditors and testers… since modern password cracking is based upon the attacker having (a) access to hashes, encrypted values, or handshake data, (b) knowledge of algorithm (c) enough cpu to do something with it and/or/if needed (d) large enough datastores to use precomputed tables [rainbow tables].
quote:
WPA Cracker is a cloud cracking service for penetration testers and network auditors who need to check the security of WPA-PSK protected wireless networks.
WPA-PSK networks are vulnerable to dictionary attacks, but running a respectable-sized dictionary over a WPA network handshake can take days or weeks. WPA Cracker gives you access to a 400CPU cluster that will run your network capture against a 135 million word dictionary created specifically for WPA passwords. While this job would take over 5 days on a contemporary dual-core PC, on our cluster it takes an average of 20 minutes, for only $17.
That said, we’ll likely see the magic of the cloud challenge many of the past security assumptions and tasks which have been infeasible due to resources or lack of ability to execute.
On this note, another interesting article arose this week. It involves wireless, but not our home networks. Instead, it’s about cracking GSM and telephone conversations.
quote:
The problem was highlighted in August when German hackers announced a project to create a code table that cracked the standard GSM cell phone A5/1 encryption. Then, Cellcrypt CEO Simon Bransfield-Garth claimed that the development was worrying, as it marks a massive lowering of the bar for criminal organisations to illegally tap mobile phone conversations.
Here he claimed that the ‘lack of security is particularly worrying’. He said: “Businesses must plan now for the eventuality that their mobile voice calls will come under increasing attack within the next six months. A ‘policy of hope’ towards mobile phone security is not adequate, voice is another data service and should be afforded the same security considerations as email and other corporate communications.”
Will we see an analogous service that focuses on GSM conversations rather then wireless networks?
For my home network, I have the ability to use encryption that’s higher in the stack (TLS/SSL) to help ensure security (well, perhaps with TLS v1.3 that addresses the recent vulnerabilities to to session protocol renegotiation).
For my GSM phone, I don’t have this luxury (well, not without making the phone unstable and dependent on various VOIP apps/availability of wireless networks). So, cell phone interception may be soon available to the masses.
Windows Azure PDC 2009 Videos Posted
Just in time for the long drive home from your Thanksgiving retreat (available in WMV and Mp4 formats for your iPod or Zune), the Microsoft PDC team has posted videos and presentations related to Windows Azure. Although these are more focused on general developer concepts, I find that plenty of relevant material to our quest to learn about security/compliance/risk implications of cloud-based computing.
Starting with the intro videos is always a nice step — I’d then recommend the logging, single-sign-on, and storage sessions.
- Craig
Introduction
- Lap Around the Windows Azure Platform
- Windows Azure Present and Future
- Introduction to Building Applications with Windows Azure
- The Business of Windows Azure: What you should know about Windows Azure Platform pricing and SLAs
Learn to Develop for Windows Azure
- Tips and Tricks for Using Visual Studio 2010 to Build Applications that Run on Windows Azure
- Patterns for Building Scalable and Reliable Applications with Windows Azure
- Developing Advanced Applications with Windows Azure
- Windows Azure Monitoring, Logging, and Management APIs
- Automating the Application Lifecycle with Windows Azure
- Building Hybrid Cloud Applications with Windows Azure and the Service Bus
- Enabling Single Sign-On to Windows Azure Applications
- Bridging the Gap from On-Premises to the Cloud
Windows Azure Storage
- Storing and Manipulating Blobs and Files with Windows Azure Storage
- Windows Azure Tables and Queues Deep Dive
Windows Azure as an Open Platform
- Developing PHP and MySQL Applications with Windows Azure
- Building Java Applications with Windows Azure
SQL Azure Sessions
- Enrich your Applications with Data from Microsoft Project Code Name “Dallas”
- SQL Azure Database: Present and Future
- Using the Microsoft Sync Framework to Connect Apps to the Cloud
- The Future of Database Development with SQL Azure
- Microsoft SQL Azure Database: Under the Hood
- Scaling out Web Applications with Microsoft SQL Azure Databases
- Petabytes for Peanuts! Making Sense out of “Ambient” Data
- Development Best Practices and Patterns for Using Microsoft SQL Azure Databases
Showcases
- Lessons Learned: Building Scalable Applications with the Windows Azure Platform
- Lessons Learned: Building On-Premises and Cloud Applications with the Service Bus and Windows Azure
- Lessons Learned: Building Multi-Tenant Applications with the Windows Azure Platform
- Lessons Learned: Migrating Applications to the Windows Azure Platform
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
Wittfield Diffie interview by MIT Technology Review – How Secure is Cloud Computing?
leave a comment »
MIT Technology review recently posted a interview with crypto-hero Whitfield Diffie.
Although the entire interview is great, one stands out…
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:
However, in the meantime (and with the constant media attention focused on “cloud failures”) it will be a turbulent ride.
- Craig
Written by Craig
November 17, 2009 at 6:31 pm
Posted in FUD, Risk Management, Security
Tagged with Cloud Security, Comments on News