Cloud Computing: The First Trip to the Cloud

Article
08/31/2016

Bringing the very first line-of-business project to the cloud requires a series of critical decision points, including staff and process changes.

Dan Griffin and Tom Jones

The financial model for cloud computing seems like an irresistible option for meeting budget pressures. After consuming services, you’re billed on a monthly basis. So the cloud computing services are considered an operational expense, not a capital expense.

You can reduce overhead by consolidating resources into large shared datacenters. This creates efficiencies in staffing and power consumption. You can scale your service usage up or down as you need—no overcapacity and no lost opportunity.

Finally, there are multiple ways that broadly deployed cloud-based applications can support your business needs. You can prepare for and account for an increasingly mobile workforce, a diverse collection of business partners and a worldwide supply chain.

While the cost and collaboration benefits might be obvious, the road to the cloud is not without its potholes, many of which are hidden. You’ll have to retrain your IT staff, create new requisition and operations processes, and update data security and compliance policies. Fortunately, you can address these challenges in a systematic way. Here’s a look at the major decision points a typical organization will face in taking its first line-of-business (LOB) project to an Internet-based cloud provider.

Get Started

Business managers are always looking for applications to help them run their businesses more efficiently—whether it’s for analyzing data for faster decision making or getting greater visibility into business operations. And whether those capabilities come from commercial or customized apps, the burden is on IT to deliver and operate an ever-expanding set of services under continuous budget pressure.

When a business application is completely stand-alone with no compliance or security constraints, the consideration for cloud hosting is greatly simplified to cost of deployment and operation. Most business applications will require a more careful risk-and-benefit analysis before deciding how to manage cloud hosting:

Authentication for both public and private (enterprise) users.
Security threats and mitigations when using the public cloud.
Compliance regulations, and how to simplify them with the right architecture.

The first two considerations have common solutions for most deployments. Compliance regulations depend on the location and type of data to be handled by the app. The major compliance issues—roughly in order of decreasing complexity—are:

Government regulations prohibiting personal or national secrets from crossing international boundaries.
Health information protected by HIPAA or similar regulations.
Identity theft, in particular release of access to financial accounts.
Public disclosure of a user’s Personally Identifiable Information (PII).
Internal requirements for handling of business-sensitive data.

Authentication Issues

Some cloud service users won’t be part of a corporate directory like Microsoft Active Directory. In that case, the cloud service needs to aggregate users from different identity providers (IdPs). These will have potentially different access rules to the cloud resources.

When there are both public and private (within the enterprise) users, cloud apps will require access to access and policy data. Thus, you could conveniently deploy that data to the cloud. This type of deployment will permit access from any type of device, even if that device isn’t part of the enterprise directory.

You’ll probably end up moving old data into the new database for cloud hosting, but handling the schema mapping and data migration should be no different than any other migration. There are tools that make the identity federation process easier. However, there could also be compliance issues associated with the data in either the database or the cloud resources.

The Windows Azure Access Control (AC) Service is a convenient cloud service that can aggregate claims from an on-premises Active Directory Federation Services (ADFS) server and an external IdP provided by Windows Live, Facebook or other social networking sites. Using cloud services for identity aggregation gives you support for many programming languages and many existing IdPs.

Using AC, you can easily map claims generated by ADFS, for example, to claims customized for a given on- or off-premises application. This approach reduces application complexity and maintenance costs. AC can also mediate the relationship of on-premises users, cloud resources and users accessing the data from the Internet (see Figure 1).

Figure 1 WindowsAzure Access Control Service can mediate between on-premises and cloud resources.

Public Cloud Security Threats

Few organizations can afford the same critical mass of IT personnel, expertise and processes as the major cloud infrastructure providers. And experience has demonstrated that you can run some apps more securely in the cloud than on-premises.

However, there will be new threats introduced as a result of public Internet connections. These types of threats are introduced by network de-perimeterization, so you’ll need to address them eventually anyway. Still, new public cloud deployments should be subject to security review. You should take the following considerations into account.

Within the enterprise domain, only domain-joined computers are permitted. You can use mechanisms like Network Access Protection (NAP) and IPsec to ensure that all machines are well-known and managed against security threats. However, you can also extend these mechanisms into the cloud.

Plus, cloud-based servers are covered by service-level agreements (SLA) which you must include in a security review. You need to ensure that uptime, security, privacy and compliance certifications are satisfactorily addressed.

Here are some of the specific attack points you should cover within the scope of a security review:

Information disclosure or denial-of-service attacks on public traffic
Man-in-the-middle spoofing of either cloud or on-premises servers
Hijacking existing connections on the public Internet
Replay of cloud credentials

These types of attacks have all been seen in prior generations of enterprise services. You can use the data flow to analyze threats introduced when a public cloud is used with on-premises services (see Figure 2). Here are the three basic types of connections you’ll have to analyze:

Neither end of the connection is at a trusted location. There’s no way to evaluate the connection, so any claim from the IdP in this example must be signed in to the service to ensure integrity of the message.
One end of the connection is in the cloud. The other is at a user site not managed by the enterprise. In this case, you can protect the connection with an SSL (TLS or HTTPS) link where credentials can be provided to either (or both) ends of the link to ensure some level of authentication, as well as data protection while transiting the cloud. Without a verifiable identity at each end, man-in-the-middle attacks are possible.
Both ends of the connection are in a trusted location. Because the cloud might not be under control of the enterprise, strong identity at both ends is also required. In this example either SSL or IPsec (VPN) connections will provide the protections needed.

Analyze the threats to your data flow before taking action

Figure 2 Analyze the threats to your data flow before taking action.

Architect for Compliance

You might not be able to determine how auditors will classify data before an application is ready for deployment. Even worse, data classification could change, even after the app is deployed. Compliance auditors prefer to conduct a finished app audit before it’s deployed, but that can be expensive.

Instead of holding up a deployment waiting for clarity, it’s easier to institute compensating controls to avoid compliance problems. These methods can help you avoid compliance issues with cloud deployments:

Ensure a good separation of control. This suggests that any process that can access sensitive data should not also be accessible to the Internet. If some Internet-facing process needs the data, try to locate the sensitive data separately from the non-sensitive data, even if they’re accessed by the same key.
Make sure data protocols between the apps that handle sensitive data and the public-facing apps are designed so they can’t accommodate sensitive data.
Use encryption to protect sensitive data. Decryption keys shouldn’t be accessible to public-facing apps. You can deploy sensitive keys and apps in the cloud or on-premises, but they should never have the same access permissions as publically accessible apps.

When you have to release data to users on the public internet, separate the LOB app from the compliance engine that will handle all the access and audit checks for sensitive data. These data flows illustrate that architecture (see Figure 3). This might appear complex, but there are only two major concepts you need to understand regarding separation of control:

You can aggregate user authentication with a claims mapping service like Windows Azure AC Service. This collects user credentials from an on-premises federated Active Directory and a cloud-based IdP, such as Windows Live or Facebook.
Separate the components of the LOB application that handle protected data from those that don’t, so compliance auditing efforts can focus on the former.

Figure 3 Any compliance checks should be handled independent of the line-of-business apps.

Now you’ll need to determine where you’ll locate the compliance access engine. You could have the compliance engine hosted in the cloud for operational efficiency, or on-premises for enhanced security. You have to protect all connections that carry sensitive data.

We’ve explored four solutions here for moving into the cloud. Each solution addresses specific application needs or vulnerabilities. Your first step is to understand what data you’ll have to expose on the public internet. If that’s sensitive data, user authentication is critical. If it isn’t, then separating data and control might avoid any compliance issues. Once you make these choices, draw out a preliminary data flow diagram and look at the attack points. Taken together, this preparation should give you the confidence you need to tackle an LOB cloud deployment.

Email Dan Griffin

Dan Griffin is the founder of JW Secure Inc., a software security consultancy based in Seattle. Follow him on Twitter at twitter.com/JWSdan.

Email Tom Jones

Tom Jones is a software architect and author specializing in security, reliability and usability for networked solutions for financial and other critical cloud-based enterprises. His innovations in security span a full range from mandatory integrity to encrypting modems. He can be reached at tom@jwsecure.com.