The chief information officer (CIO) of a large utility provider had decided to move email, file shares, video sharing and the company’s internal web site to the cloud and needed to know the security requirements for this project within two weeks. The organization already had security requirements in place for traditional third-party vendors; however, these requirements were not a good fit for the cloud services the company was looking to adopt.
The director of security at the utility provider approached SecureState, a management consulting firm specializing in information security, with the problem.
Unlike traditional third-party solutions where the vendor is responsible for all, or most, of the security controls in the cloud, there are often cases where the client is responsible for managing and maintaining key security controls. For example, if a company was hosting a homegrown application at a Platform as a Service (PaaS) provider, the client would generally be responsible for the security of the application itself (figure 1). The cloud provider of the PaaS would be responsible for securing the platform and infrastructure supporting the application. However, if a company selected a Software as a Service (SaaS) application, the cloud provider would generally be responsible for all layers of the stack and the client would have very little responsibility or control over the security of the application (figure 2).
With that in mind when moving to the cloud, it is critical to clearly outline who is responsible for each component and have requirements that give the organization its desired level of security while being flexible enough to fit the different service models available from cloud providers.
For this utility provider, the move of these initial four services was part of a larger effort to eventually migrate all corporate IT services to the cloud, so in addition to quickly developing requirements for the applications listed previously, the director of security also needed a way to rapidly assess and categorize future cloud service providers to determine what minimum set of controls should be applied. This system also needed to be flexible enough to support new technology developments as cloud solutions mature. Further, a system would need to be put in place to track and monitor compliance of these key business partners to the required controls.
Building a Framework
To assist with this, SecureState created a program to review, approve and manage these cloud providers. The program was built around a custom cloud security framework (CSF) that the team developed. This framework was comprised of numerous components including:
- Data classification and cloud service provider categorization guidelines
- A control set
- Vendor questionnaires mapped back to the control set
- Federated identity management standards
To create this framework, the team met with stakeholders to gather business, technical and security requirements. The framework leveraged the utility company’s existing security policies, procedures and standards while adding requirements specific to cloud computing environments.
The controls in the framework were broken down by the classification of the data processed and/or stored by the provider (public, internal, confidential and regulatory). Each level added another layer of controls that needed to be present in the environment. To ensure that the controls were properly applied to various cloud models and use cases, a lookup table was created to show who is commonly responsible for managing each of the controls in the framework, depending on what type of cloud service model (e.g., SaaS, IaaS, PaaS) is being used.
Special attention was given to the regulatory requirements related to the data that would be stored and processed by the cloud providers, as the utility company needed to comply with several different regulations:
- North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) standards because the utility provides power generation and transmission
- Payment Card Industry Data Security Standard (PCI DSS) because the utility processes credit cards
- US Health Insurance Portability and Accountability Act (HIPAA) because the utility self-insures its employees for health benefits
Requiring all cloud service providers to meet these regulatory requirements would be onerous, if not impossible. Therefore, appropriate regulatory controls would be applied only in environments that required them.
For example, portions of the utility’s employee health insurance process would migrate to the cloud specifically related to the corporate file share. Because of this, additional steps needed to be taken to ensure that the provider of the file-sharing service could meet the related HIPAA requirements.
Once the framework was completed, the team met with executives at the organization to review the CSF. During this meeting, SecureState conveyed the importance of the framework to the business and outlined how the organization should align to it. Once executive management buy-in was obtained, the framework was adopted for use by all lines of business moving services to the cloud, not just IT. This provided the company with a unified approach to managing the security of cloud services, thus ensuring all corporate data moved to the cloud were appropriately secured.
Managing the Security of Cloud Services
The director of security also needed to develop processes to prioritize, review and track which cloud services were approved for use, as well as a program to manage and track what data were being stored and/or processed by these cloud services. Without a robust program in place, the security department would quickly lose control of where sensitive data were stored and which vendor had been approved or denied.
The SecureState team created an online portal where lines of business inside the utility can enter requests to have potential cloud service providers (CSPs) reviewed. Once a provider is entered for review, a questionnaire is generated based on the type of cloud service used and the data stored and/or processed by that provider. This questionnaire is then sent to the point of contact at the cloud service provider to gather information on what security controls are present in their environment. Once the questionnaire is complete, SecureState works with the CSP and client to snap the cloud service into the CSF. To ensure the lines of responsibility are clearly defined, each requirement in the CSF is assigned to either the CSP or client. Depending on the categorization of the data being stored or processed by the provider, additional testing or interviews outside of the questionnaire may be required to determine which controls are present and to verify that they are properly implemented. A similar process is also followed to ensure that the controls the organization is responsible for implementing internally are present and properly implemented for each new cloud service entering into the environment.
During this review process, risk posed by the proposed solution is enumerated and areas where the solution did not meet the CSF are outlined. Using this information, the utility’s security group can determine if the new solution poses an acceptable level of risk, if the solution would be rejected or if it requires additional controls.
This portal also provides an inventory of which approved cloud applications/providers are currently being used in the environment and any exceptions associated with each provider. Additional reminders are set up to reassess each CSP annually, at a minimum. The depth of the reassessment is determined by the type of data processed or stored by the provider and any control exceptions granted.
Lessons Learned
Since implementing the CSF, the utility has applied it to four initial cloud services and a handful of subsequent providers. While applying the framework, a number of lessons were learned:
- Getting in front of the providers before the contract is signed to gain the full support of the providers. The utility had a large challenge applying the CSF to the initial set of vendors, as the contracts with these vendors had already been signed by the time security was brought in to review them. Because of this, the team had little leverage to get the vendors to make changes to their environments to meet the utility’s security requirements.
- Ensuring the use and completion of the utility’s questionnaire. Many of the providers preferred to provide third-party audit reports such as Service Organization Control 2 (SOC2) reports or self-assessments such as the Cloud Security Alliance (CSA) Consensus Assessments Initiative Questionnaire (CAIQ) instead of completing the utility company’s questionnaire. In these cases, the team would map the results back to the framework manually. Unfortunately, in most cases the information provided in the SOC2 report or CAIQ did not contain enough detail and further interviews and assessments were required to fill in the gaps. These processes ended up taking longer than initially planned. As a result, it was determined that this process would go more smoothly if the questionnaire was completed first. Thus, the team focused on streamlining the questionnaire and warned the project team that if the vendor did not complete it, the time required to review the vendor would lengthen, possibly impacting the project timeline. With this concern in mind, often the line of business could pressure the prospective providers to complete the questionnaire.
- Prioritizing provider assessments based on services provided. Follow-up interviews and assessments took longer than initially planned, and a method to prioritize service providers had to be developed to ensure high-priority service providers were assessed first. In some cases, lower-priority providers that housed only public data received minimal follow-up interviews and assessments. This was done to ensure that providers could be reviewed and approved quickly with the resources available.
- Educating the line of business on the cloud provider review process and following that process. Large projects that went through the company’s central procurement, or project management, office were easily flagged for provider review. However, many smaller projects that were initiated by the lines of business were small enough that they did not require involvement from these groups. Therefore, the security team did not hear about some smaller projects until they were fully implemented and, in some cases, had been in operation for a few months. To address this, the security department now makes a concerted effort to reach out to all lines of business to educate them on the process while working to quickly review new providers so this review is not a bottleneck in the process.
Conclusion
By pulling together the right team, the utility was able not only to address its initial problem of providing security requirements for the first group of vendors, but also to develop a solution to manage future cloud vendors. This solution allowed the utility to quickly and easily review future providers and also provide a program to manage them, thus ensuring corporate information stored in-house or in the cloud is protected equally.
The best way to start this process in any organization is to inventory the existing cloud services already in use. Many organizations have already started to leverage cloud services, often without audit, IT or security’s knowledge. By generating an inventory of which service providers are currently being used and what data are being stored or processed there, the organization can get a handle on what corporate data may be underprotected in these environments and use this information as leverage to start its own internal project to create a CSF for the environment.
Matthew Neely is the director of strategic initiatives at SecureState (www.securestate.com). Neely uses his technical knowledge to lead the Research & Innovation team to develop threat intelligence tools and methodologies for the challenging problems of the information security industry. Previously, he served as SecureState’s vice president of consulting and manager of the Attack & Defense Team. With more than 10 years of experience in the area of penetration testing and incident response, Neely brings the ability to think like an attacker to every engagement. He uses this skill to find creative ways to bypass controls and gain access to sensitive information. Prior to working at SecureState, Neely worked in the security department at a top-10 bank where he focused on penetration testing, assessing new technology and incident response.
[Source: ISACA]
