On a peaceful Cloud Island, law-abiding citizens use their mobile devices to:
- Run a Software as a Service (SaaS) application on demand as individuals or in groups.
- Develop an application with the Platform as a Service (PaaS) as a team.
- Check the health of Infrastructure as a Service (IaaS) via dashboards of performance indicators.
At work, the islanders tweet, blog, and use other social networking tools, usually without issues to:
- Achieve near real-time communication on cloud data they are accessing.
- Build a collaborative culture of public cloud developers at remote locations.
- Share cloud service knowledge and current cloud practices.
- Assess cloud service migration progress more regularly.
The islanders are happy; cloud and social networking services are always available as guaranteed in the service level agreement (SLA). This SLA specifies a failover plan to a healthy data center somewhere on the island just in case performance falls below guaranteed levels of availability. The algorithms used in measuring performance are numerically stable.
But every person is not always as they seem.
Cybercriminals masquerading as tourists
On a bright sunny day during lunchtime, three cloud service workers walk a couple of blocks to the island's main port to take pictures of a large cruise ship cautiously approaching port. On this ship are about 1,000 tourists who are not aware that a few cybercriminals are among them. The security personnel at a another island forgot to check these cybercriminals' backgrounds before they boarded the ship.
A few minutes before the ship docks, the cloud service workers take a pause from picture-taking to read the December 13, 2012 issue of InfoWorld, the Trend Micro report, that talks about hackers exploiting cloud services via social networking tools. According to the report, hackers would blog, tweet, or use Facebook to transmit malicious codes from a command and control center to a mobile device. Once the hackers get the data (they are not supposed to have), they would drop the stolen date in Google Docs or Dropbox or Pastebin or even Amazon EC2.
Then the hackers from the command and control center would look at:
- What highly critical data they've collected.
- How they would maliciously change the data.
- How they would gain higher privileges.
- Whether they would resend the data back to the source or move forward to the target destination.
As soon as the ship successfully docks, the cybercriminals quickly set foot on the island, bypassing the three cloud service workers and then disappear into the flag-waving crowd. By the time the cloud service workers return to work, they begin social networking with their mobile device. They discover too late they cannot access the SaaS application, connect with other PaaS developers, or check the health of the IaaS.
Cloud services suddenly shut down. The cloud service workers groan and moan that:
- Threshold policies are not in place.
- A failover plan to a healthy data center is excluded from the SLA.
- The algorithms used to measure performance are numerically unstable.
Islander model users
Before discussing a plan to reduce risks of cloud service abuse, let's find out what the model users have been using with mobile devices to get SaaS on demand, build SaaS application with PaaS, and check the health of IaaS. What they can communicate with one another using social media tools is limited by how much control they are allowed over the resources for the SaaS, PaaS, and IaaS. The provider sets the resource, user, data request and social media threshold levels.
All users are bound by the company's bring-your-own-device policy (BYOD), that each mobile device has a password or biometric-secured partition for company-approved data and applications. This partition is separate from the second partition for personal use on the same device. All mobile devices are remotely controlled by the company's mobile device management solutions, including IBM®'s Endpoint Manager for Mobile Devices (that works with IBM's other Endpoint Management offerings).
Get SaaS on demand
The SaaS mobile user has the least control while the provider has the most control of mobile use.
- End user mobile control: The only control end users have is to access the SaaS application from a partition on a mobile device whether they are private individuals, businesses (small or medium), or government agencies. Examples of SaaS applications include ship arrival and departure schedules, customer relationship management, human resource, and spreadsheet.
End users use the same mobile device to tweet or blog with a select group of users on the progress of accessing a SaaS application. If the user is allowed to download the data from the application in the company-protected partition, she drops it off the data remotely in secured Dropbox for later retrieval or discussion with other twitters or bloggers.
- SaaS provider control: At a minimum, the provider manages access controls by limiting the number of authorized users who can concurrently access the application as set forth in a user threshold policy (see previous articles on threshold policies in Resources). The provider limits the number of users who can use social media tools as set forth in a social media threshold policy. The provider controls operating systems, servers, and network infrastructure needed to run the SaaS application. The provider also controls what social media tools to download to the mobile device or to use with the device.
Build a SaaS application with PaaS
The PaaS user has more control over the applications than the SaaS user has.
- Developer mobile control: The developer controls and protects all the applications found in a full business life cycle created and hosted by independent software vendors, startups, units of large businesses, or government agencies. The developer builds, deploys, and runs a custom ship arrival and departure management application for example. As part of the business life cycle, the developer uses social media tools, spreadsheets, word processors, billing, payroll processing, and invoicing.
The developers use the same device to tweet, blog, or use Facebook to form knowledge networks. These networks can help developers get information about development processes and technologies, share innovative practices and receive answers in timely ways. Developers as a team can assess more regularly through social media postings by providing near real-time feedback on how well the developers are doing.
- PaaS provider control: At a minimum, the provider controls operating systems, servers, and network infrastructure needed to run the SaaS application. The provider also controls what social media tools to download to the developer's mobile device. The provider sets the user, resource, data requests, and social media threshold levels.
The IaaS security policy focuses on accessing and protecting data and managing virtual machines.
- Network specialist mobile control: The infrastructure or network specialist controls the operating systems, network equipment, and deployed applications at the virtual machine level. The infrastructure specialist can scale up or down virtual servers or blocks of storage area and can use social media tools to communicate with other infrastructure specialists on IaaS and developers on PaaS that sits atop the IaaS.
Infrastructure or network specialist can use the same device to tweet, blog, or Facebook to other IaaS specialists or PaaS developers to form knowledge networks. These networks can help the specialists and developers get information about IaaS technologies and receive answers in timely ways.
- IaaS provider control: At a minimum, the provider controls the infrastructure of traditional computing resources underlying virtual machines and what mobile applications are needed to access the IaaS. The provider controls what social media tools to use in a collaborative environment. The provider sets the user, resource, data requests and social media threshold levels.
Cloud attack scenarios
Let's take a look at some scenarios on how hackers could use social media tools to abuse cloud services that SaaS users, PaaS developers, and IaaS infrastructure specialists access from their mobile devices.
End users use their company-approved BYOD to connect securely with an SaaS accounting application that is always available on demand. To form sort of a virtual group, they tweet, blog, or use Facebook locally (in the same location) or remotely (at different locations) who are concurrently accessing the same SaaS application.
The users put sensitive information on Facebook for all, including the hackers, to see. They did not change default settings when they first enrolled for a Facebook account.
Unknown to the end users, Facebook acquired a face recognition software that allows hackers to use data from Facebook to identify SaaS end users in photos uploaded to Facebook. The SaaS end users forget to change Facebook settings.
The hackers put the stolen data in a drop zone and infect them. They send malicious code to their targets and flood the back-end databases with them.
Suddenly the SaaS application is inaccessible.
To develop a complex SaaS application with the PaaS platform, a large team of PaaS developers is formed. This team is an aggregate of smaller teams with varying relationships with one another based on the prominent skill sets of each team. One team has proficient skill sets in an area that another team doesn't.
Since the delivery date of the SaaS application is tight, it is necessary for the teams to be able to tweet with one another in real time regarding how well the application development is progressing. The developers are able to get the latest progress reports from teams at different locations.
As the developers are approaching the delivery date, the PaaS crashes. Most developers forget to secure their Twitter accounts. Those few who secure their accounts get hacked. The hacker copies the personal information, changes it, stores it in Dropbox, and then gets it for malicious attack against the access controls to the clouds.
Mitigate cloud abuse risks
Here are five practical steps for reducing risks of cloud abuse. You will need to repeat these steps if the threat priority changes. When the priority changes, safeguard requirements and costs change as well.
- Identify assets
- Analyze critical information
- Analyze threats and vulnerabilities
- Assess risks
- Fix the problem with safeguard defense layers
When you perform risk assessment for the first time, identify the components of each company-approved mobile device. This should include the operating system, any associated mobile security policy, media cards, contact information, and corporate mobile applications. Other assets to identify should include:
- Type of cloud service that the device is used to access and the purpose of cloud access (for example, to check the health of IaaS).
- Enterprise server (usually a mobile device management server) that is used to control the devices remotely, either individually or by group.
- Company-approved social media tools that approximate near real-time communication among the mobile device users.
- Threshold policies for each cloud service type — user, data request, resource, and social media.
- Type of service level agreements that guarantees the level of availability to mobile devices, social media tools and enterprise servers: External, internal, or internalized.
Analyze critical information
Identify how critical the information is on each company-approved mobile device that is used to access an SaaS application, develop the application with the PaaS, check the health of the IaaS, and communicate via social media tools. The criticality of corporate data downloaded from the SaaS application and enterprise network is usually high. This includes the company's accounting records and C-level executives' contact information.
Analyze threats and vulnerabilities
For cloud abuse threat, make a list of vulnerabilities that could be exploited. Qualitatively rate each vulnerability as high, medium, or low. For example, the threat of cloud abuse via a mobile device has, at a minimum, five vulnerabilities:
- Device password is not set.
- Social media threshold is not applied.
- Remote data wiping is not enabled.
- Data encryption is not turned on.
- Performance monitoring is inadequate.
Each vulnerability is rated as high. By exploiting the vulnerabilities, a hacker can get into the device without a password and/or a biometric authentication (such as fingerprinting or iris scanning) and see critical and unencrypted information downloaded from one of the following:
- SaaS application on demand
- PaaS application development dashboard
- IaaS health dashboard
The hacker could use newly discovered information to harm the organization.
However, if the vulnerability priority changes or new vulnerabilities emerge for the same threat, IT must repeat this step of analyzing threats and vulnerabilities. For example, if as a result of changes in mobile technology or users' perceptions of social media tools, a different type of cloud abuse threat emerges, IT must re-evaluate and mitigate risks, beginning at the first step of identifying assets.
Assess the likelihood (risk) of a hacker taking advantage of a vulnerability and the business impact (loss of corporate revenue and reputation). The value of the likelihood is somewhere between 0 and 1. When high likelihood approaches the value of 1, there is a very high chance of the vulnerability being exploited. A value of 0 means there is no risk (which is not likely for cloud abuse or cloud shutdown). The lower the likelihood value is, the better chance to mitigate the risks of cloud abuse would be using cost-effective safeguards.
Fix the problem with safeguard defense layers
Even the best available information assurance products for social media tools and cloud services have inherent weaknesses. Technologically sophisticated adversaries will find exploitable vulnerabilities in these products. As a countermeasure, deploy multi-defense mechanisms between the adversaries and their targets. Each cost-effective mechanism must present unique obstacles to the adversaries. This helps to better detect the adversaries while mitigating the adversaries' chances of successful penetration.
Five tips that, at a minimum, will set up layers of defenses include:
- For the passive class of attack:
- First line of defense: Network layer encryption.
- Second line of defense: Social media traffic threshold for mobile devices.
- For the insider class of attack:
- First line of defense: Physical and personnel security.
- Second line of defense: Audit, access control, and associated security policies.
- For the exploitation class of attack:
- First line of defense: Physical and personnel security.
- Second line of defense: Technical surveillance countermeasures for cloud services and social media tools.
- For the distribution class of attack:
- First line of defense: Trusted software distribution.
- Second line of defense: Runtime integrity and protected storage controls.
- For the active class of attack:
- First line of defense: Defend the enclave boundaries (such as the outside firewalls).
- Second line of defense: Defend the computer environment (such as the inside firewalls) and/or to failover to healthy, secure data centers within the borders of the United States.
In reality, there are more classes of attacks against social media tools, cloud services, and physical infrastructure underlying virtual machines; and more lines of defense for each class. Each line of defense can be further broken down into lower-level lines of defense with relationships of varying complexity among them. You need to go beyond the basics in the National Security Agency's "Defense in Depth" article.
In planning for reducing risks of cloud abuse, consider best practices for developing a risk mitigation policy that SaaS end users, PaaS developers, and IaaS infrastructure specialists can use. Terminologies such as user, data request, resource and social media thresholds should be considered for use in determining risk mitigation of cloud abuse. We need to build a team of developers, managers, business analysts, system engineers and make it easier for them to do their jobs of mitigating risks of cloud abuse for each deployment type: SaaS, PaaS, and IaaS. Consider exploring IBM Connections Suite that provides real-time social communications and document management.
- Browse the author's developerWorks series on threshold policies.
- Browse the author's developerWorks series on service level agreements.
- Browse the Judith M. Myerson's series, Use SLAs in a Web services context, has details on service-level agreement.
- Bring your organization into the future with RFID in the Supply Chain, which explains business processes, operational and implementation problems, risks, vulnerabilities, and security and privacy. Find out how RFID is to interact real objects to virtual ones.
- Read Judith M. Myerson's The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
- Get the business insight and the technical know-how to ensure successful systems integration by reading Enterprise Systems Integration, Second Edition.
- Learn more about cloud computing technologies at cloud at developerWorks.
- Follow developerWorks on Twitter.
- Watch developerWorks demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
Get products and technologies
- Access IBM SmartCloud Enterprise.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
Dig deeper into Cloud computing on developerWorks
Exclusive tools to build your next great app. Learn more.
Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.
Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.