The key to success is planning.

Since I live in Seattle, it's only fitting that I discuss the preparations you need to make prior to moving to the cloud. One requirement for living in Seattle is to be prepared for changing weather. It may be bright and sunny, and an hour later be overcast and raining. Native Seattleites know to carry an extra fleece and Gore-Tex rain jacket—in other words, we're prepared. In terms of moving part of your business to the cloud, you must also be prepared. This article discusses preparations you need to make prior to moving to the cloud.

Considerations

Just as you do when you take advantage of any new technology, you have to decide if you're considering it just because everyone else is or if it actually meets your business needs. When it comes to cloud computing, you have the potential to save significant money over hosting your own computing resources in terms of hardware, support of that hardware, and software licenses. It can also be more cost-efficient using Software as a Service (SaaS)—think SalesForce.com. But just because using cloud technologies has the potential of saving money, it doesn't mean that it will meet your business requirements. Specifically, you must examine both the technology and the technology provider to ensure they can meet your organization's process requirements as well as security policy requirements, legal requirements for issues such as discovery of information when in a lawsuit, and the compliance requirements of all of the laws and regulations with which your organization must comply.

To perform this analysis, you must first examine your current policies and internal processes as well as the legal and compliance requirements for the data your organization processes and retains. It's possible that your current processes are not adequate and that's one reason you're considering moving to the cloud. It's important to be able to understand your requirements so that you can articulate them and ensure these are reflected in your contract with the cloud provider.

The determination of whether cloud computing meets your business requirements depends on the type of data you intend to place in the cloud. If you're thinking of using the cloud to manage Personally Identifiable Information (PII), healthcare information, Payment Card Industry (PCI, aka credit card) data, or data that's highly confidential or valuable to your organization, you must examine the requirements your organization's security policy places on this type of data. For example, if you store credit card numbers, your security policy will reflect the PCI requirements that cardholder data be encrypted when it flows over a public network, as well as the requirement that data be encrypted while "at rest"—in other words, when stored in a file, spreadsheet, or any other data type available. If you're going to send PCI or any other data that is required to be encrypted to the cloud, you'll want to question the provider to determine if it can meet your encryption needs. And don't forget about the encryption key management requirements. Make sure that access controls can be set on these objects and that, by default, the access controls are set to "deny by default."

You'll also want to question the provider's security practices. Again, depending on the legal and regulatory requirements surrounding your data, you must ensure that administrator (root) access is limited to only those people requiring that power and administrators must access servers only via encrypted sessions. If these are your requirements, they must also be your cloud provider's requirements. Also, don't focus solely on the processes you've implemented. If you are moving to the cloud to ensure compliance, you must be able to clearly articulate the specific requirements so you can effectively search for a cloud provider that will be able to fulfill all of your compliance requirements.

In discussing a move to the cloud with our clients, we make sure to discuss the effect on business processes. Several business processes are often forgotten about or taken for granted, and these need special consideration in the cloud. Many of these processes are audit-driven, and the processes have been in place for a long time. Because of this, I thought it might be helpful to mention them to ensure they're on your requirement list.

Authentication

The most basic form of proving your identity is logging on with a user id and password. Think about these questions when considering a move to the cloud:

• If you're planning to use SaaS, will your organization's authentication requirements be met? If you require two-factor authentication, will the cloud-based application require it as well?

• Even more basic, do the password composition rules for the application match your organization's password complexity rules?

• If passwords are in use, how are they re-set? How do users validate their identity so someone else isn't able to use their user id?

• If you're considering hosting your entire environment, password rules are probably not an issue. But what if you're using single sign-on (SSO) and only part of your infrastructure has moved? Will your single sign-on implementation continue to work?

User Administration

Most organizations have strict processes for users requesting access to a system or application and for granting users access to specific data.

• You'll want to understand who administers access to the cloud-based server or application. Is it someone within your organization or someone administering the application in the cloud? How will those processes need to change with SaaS? Will the SaaS provider be able to support the tracking these processes usually require?

• Most organizations' security policies address the actions that are to be taken should a person's employment with the organization be terminated or someone is made redundant. Within your organization, these actions are typically taken simultaneous to the employment action. You'll want to ask the cloud provider whether they have a method to quickly identify and shut down the accounts used by these former employees to ensure their access can be removed immediately.

Logging (Auditing)

I see the scope of what's logged only increasing. More organizations are not just reviewing logs from the IBM i audit journal but they're also sending at least some audit entries from IBM i along with logs from UNIX and Linux systems, routers, and firewalls to their security information and event management (SIEM) software.

• How will moving to the cloud affect your ability to send information to your SIEM?

• Another question to ask the provider is what logging is performed and how long these logs are saved. Compliance with many laws and regulations usually requires some level of logging (auditing) to be performed. Your security policy may require the logging of administrator functions, authority failures, reading of healthcare data, failed login attempts, and more. Depending on the type of data, retention requirements for the logs may be as short as one year or as long as seven.

Data Retention

In addition to log retention, you'll want to understand the cloud provider's data retention policies.

• Depending on the type of data, the data itself may need to be retained to comply with various laws and regulations. Does the SaaS you're planning to use comply with your data retention policies?

• On the flip side of retaining data, you may have a policy of deleting data after a certain period of time. For example, organizations often have a data retention policy for deleting email after 1-2 years. When using an online email application, you'll want to make sure the provider can comply with this policy, for example.

• If your organization is found in the unfortunate position of being a party in a lawsuit, part of the discovery process may require that some of your organization's electronic data be submitted for review. This is typically called "e-discovery" and can include data such as email, databases, documents, and instant message chats. You'll also want to understand the process you'd have to follow if your data had to be retrieved, including any additional charges that might be levied to retrieve the information.

Data Privacy Requirements

Some states have specific data privacy requirements, and if your organization operates in Europe you have to worry about whether storing your data is going to violate the EU Data Protection Directives. Remember, when you send your data to the cloud, the server on which it actually resides could literally be anywhere in the world. Having data cross country boundaries may be a violation of privacy laws.

Incident Response

This is an area where most organizations fall short. Only rarely do I see organizations with a formal incident response plan and cyber insurance. The good news is that most cloud providers are well-equipped in this area. Most have the resources to hire specialized security professionals and implement a Security Operations Center (SOC). A SOC will aggregate events and information, perform real-time analysis, and take action to protect the organization before and during an attack. They also typically have dedicated security experts to oversee their operations. With these resources, they are more able to keep up-to-date with the latest threats and security patches. However, when considering a cloud provider or SaaS, you'll want to be sure of the following:

• Agree on the definitions of incidents and the actions to be taken for each. For example, different actions are required to fend off a Distributed Denial of Service (DDoS) attack than to detect and remove malware, but each is considered an incident.

• Determine whether the provider carries cyber insurance and whether you also need to be covered under a separate policy.

Audit Requirements

I highly recommend that you look at the reports that your auditors—both internal and external—require and determine whether moving to the cloud will affect those reports. You may even want to consult with them prior to moving to the cloud or subscribing to a cloud-based application to determine if they have concerns or will require additional or different reports.

Technology

Before moving an application (and its data) to the cloud, you need to determine all of the processes that use the data as well as all of the processes that feed into these databases. Most of our clients have multiple applications on their IBM i, and it's rare that they don't interact with each other. For the majority of clients who have moved an application to another platform, there's still a process running on IBM i that receives information from the other application or sends information to it. In other words, just because one application moves off of the IBM i doesn't mean that its data isn't still needed by another IBM i application. When subscribing to a cloud-based application, you must determine whether the interaction between your applications will be able to continue; if not, determine what business processes have to be changed to account for the discontinued integration. And don't forget your mobile apps when determining which processes use your data.

In addition, it may not be other applications that are using this data; it may be business users using the data. Perhaps they're downloading the information directly from the server to their Excel spreadsheets. This is another example of the need to understand how the data is currently being used and to determine—prior to moving to the cloud—whether the data will still be accessible to the business user.

Another area of technology that needs to be understood is security technology. You need to inventory the list of security technologies in place to determine whether they will continue to work or whether the cloud-provider's technology is a sufficient replacement. One prime example is the use of Data Loss Prevention (DLP) technology that tracks movement of data throughout an enterprise. DLP can examine the movement of data, looking for specific types (for example, credit card numbers) and volumes of data flowing around a network. This examination can include data going through desktop USB ports and email. If you are considering using a cloud-based email service and have DLP implemented, you'll want to understand whether DLP will continue to work.

Service-Level Agreements (SLAs)

Prior to moving your entire IT infrastructure to the cloud or subscribing to a cloud-based application, you need to understand the SLAs your organization currently has in place. For example, as an IT organization you may have an SLA with your business users regarding how quickly you'll respond to an outage. But if your infrastructure is no longer under your direct control, can you be assured of meeting that SLA? If you are a supplier and you subscribe to a cloud-based inventory control application, can the terms of your SLAs withstand the cloud provider coming under a DDoS attack such that their application is not available for a period of time? Will your SLAs withstand the cloud provider's outage and maintenance schedule?

Not the Golden Ticket

One misperception many organizations have when moving to the cloud—especially when they're moving to a solution to solve specific compliance requirements, such as handling credit card transactions—is that the organization is totally absolved from all compliance requirements and all liabilities should a breach occur. This is usually not the case. It's your data, and you're still responsible for it in some way. Again, if you have PCI requirements, you should consult with your auditor and/or QSA to understand what responsibilities will remain with your organization. Also, it's critical that your legal department reviews the terms and conditions of the contract so that you understand your organization's legal liabilities with the move to the cloud.

Summary

The key to a successful cloud deployment is planning. Part of planning is understanding your current processes and knowing whether they will continue to be accommodated or will need to be changed. Another part of planning is understanding your current compliance, regulatory, and audit requirements and determining how they will be fulfilled in the cloud. Finally, you must make sure that your requirements are covered in the Terms and Conditions of the contract you sign with the cloud provider. Moving to the cloud is not impossible, but it takes planning—just like living in Seattle.

Additional Resources

Security and compliance concerns led to the organization of at least one group dedicated to defining and driving implementation of best practices for secure cloud computing. The Cloud Security Alliance offers guidance as well as cloud certifications for the security professional.

The National Institute of Standards and Technology (NIST) has published several guidelines for cloud technology.

The European Union Agency for Network and Information Security (ENISA) offers cloud computing guidance.

The PCI council formed a special interest group dedicated to cloud technology and published guidelines.