Previously, MetricStream’s David Williamson shared best practices for how companies can keep their cloud technologies secure, including:
- Prioritizing the value of your data (whether public or private).
- Considering the different ways a loss event may impact your organization.
- Monitoring and managing your third-party relationships with specific loss prevention protocols.
- Testing your network for weaknesses, and addressing them swiftly.
- Dedicating resources for information stewardship.
According to the Global State of Information Survey led by PwC US in conjunction with CIO Magazine and CSO Magazine, of 10,000 IT and security decision-makers in 127 nations, 69 percent of respondents use cloud-based security services. This number reflects that the cloud has not only proliferated, but has become a staple in the enterprise IT strategy. Given the survey results, which reveal increasing and continued growth of cloud adoption, Williamson has outlined five best practice guidelines for how companies can assess the capabilities of their critical cloud service providers (CSP).
Guidelines for Evaluating Cloud Providers
Click through for five best practice guidelines companies can use to assess the capabilities of their cloud providers, as identified by MetricStream’s David Williamson.
Define Clear SLAs: CIA
Step 1: Confidentiality, Integrity, Availability (CIA)
The first thing to keep in mind when defining a service level agreement (SLA) with a cloud service provider is to understand the respective rights and responsibilities for the confidentiality, integrity and availability (CIA) of company data. Also referred to as the CIA triad, this is a standard that guides information security policies within the organization. Confidentiality maps to breaches, integrity to corruption/malware, and availability to downtime issues. The CIA structure is how information security professionals recognize the responsibilities for protecting data.
Define Clear SLAs: RTO
Step 2: Recovery Time Objective (RTO)
During the legal agreement phase, it is critical that you outline the required service uptime criteria for the availability of your data. In other words, confirm that your service is going to be accessible for your audience as often as it needs to be, which should be 99.9 percent of the time, or more. Additionally, there need to be agreed remedies, typically financial ones, if the CSP does not honor this requirement. Also be sure to establish a Recovery Time Objective (RTO), which is the maximum amount of time that a system can be down without serious consequences, which is dependent on the business criticality of the service in question.
Define Clear SLAs: Data Location
Step 3: Data Location
Another important factor to keep in mind when negotiating an agreement is identifying the location of your data. Back when companies had physical assets (i.e., file folders), knowing the location of data was a non-issue. Now, a piece of information may start its life in a box, but as it goes through automation processes, it can be backed up to a server anywhere in the world. This presents an issue for many legal organizations, such as the European Economic Community (EEC), which does not allow confidential data about its citizens to leave the EU. Because this guarantee can be difficult for a CSP to provide, organizations must proactively inquire about and address this issue when developing the SLA.
Define Clear SLAs: Data Supply Chain
Step 4: Data Supply Chain
In today’s business landscape, supplier channels are vast, global, and continue to grow in complexity. Often, your vendor relies upon its own set of vendors, who rely upon more vendors, and so on, calling into question which entity is responsible for maintaining the integrity and security of your data. For instance, your organization, “Company X,” may have a relationship with a CSP like Amazon. Then, Amazon might be affiliated with “Company Y” who hosts the physical infrastructure or data warehouses. It is important that “Company X” recognizes that Amazon also depends on its third-party relationship, so in the event of failure, it can be difficult to fix responsibility on one party. With this gray area, it is highly recommended that any company that evaluates the security of a potential CSP read the fine print and ensure contractual agreements specifically say that it (the CSP) is responsible for the actions of all of its suppliers.
Define Clear SLAs: Compliance
Step 5: Communicate Your “Legs and Regs” to CSPs
It is also essential to communicate the legislation and regulations that your industry is subject to, in order to drive the best outcomes from your CSP relationship. If you must abide by standards like FISMA, NIST, or PCI-DSS, for example, relay to your CSP how these guidelines may impact certain factors of service delivery, like access to information, so that they are cognizant of the different legal restraints they must work around.
Define Clear SLAs: Termination
Step 6: Terminating the Contract
Companies often fail to think far enough into the future and consider how they will exit the relationship with their CSPs. Remember that many CSPs will say that as they are accountable for your organization’s data while it is under their management, at the end of the contractual period, they may assert that they still own the data. Thus, it is critical that you ensure that your contract has a clear clause stating that the CSP must return and expunge your data upon termination of the agreement.
Establish Proof of Security Testing
Once the SLA is established, it is important to make sure that both sides are clear about the nature, levels and frequency of independent security testing. As part of this, look to the CSP to provide specific documents that describe the security practices they utilize. These may include, for example, penetration of the CSP’s wired and wireless network, or its web applications. The frequency of testing should be determined based on your company’s specific needs, with quarterly or semi-annual checks as the most commonplace. Annual is not enough and leaves room for vulnerabilities to go unnoticed for too long. Likewise, monthly security testing is too frequent and would not show enough of a substantial change to identify risks or exposure points.
Define Notification Timeframes
Many regulatory requirements dictate that if a company loses consumer data (i.e., cardholder information, private transactions, social security numbers, etc.), the company is obligated under law to notify the affected customer. However, the CSP is the party that needs to be the first to recognize that information has been compromised and report it.
Unfortunately, CSPs tend to be cautious about notifying customers about lost PII (personally identifiable information), so it is vital that your company defines specific customer-notification timeframes and outlines exactly what should trigger these alerts. Warnings could include mishaps such as data found in a public space, unavailable systems, systems outside of trusted networks, and corrupted data. Notifications are critical, as virtually every type of data compromise companies experience today can lead to harrowing consequences for customers — fraud, identity theft, blackmail hacking, or worse. Additionally, it is important to explicitly dictate that the CSP must alert your company when there is even a suspicion of a breach or similar event. This can be an expensive and time-intensive, yet necessary process. Thus, the guidelines should be fair and state that this level of notification is only required when the CSP has a probable reason to believe data has been compromised.
Right to Audit
It is also imperative to include the right to audit within the CSP contract. The right to audit provides your company with another layer of trust in the CSP’s ability to suitably manage sensitive data. Specifically, your service agreement should include two clauses: 1) The right to inspect physical infrastructure and data facilities in person, and 2) The right to test (including security scanning). Note that many CSPs do not favor the latter form of auditing as it reveals how difficult (or easy) it would be to break into their networks. Third parties also commonly conduct independent CSP audits, and it should be noted in your service agreement that your organization be given complete access to those reports.
In the event that the CSP fails any of these audits, they should be granted a period to improve. If there is no progress following this timeframe, your company has the right to terminate the relationship and retrieve your data.
There will always be some degree of residual risk when working with a third party. Because of this, it is important to take a holistic view of the relationship and apply traditional risk management and risk assessment techniques to determine potential threats. For example, what would happen to your organization if the CSP goes out of business, or if data is exposed in a public space? How you size and rank these risks can and will impact the likelihood of its influence. Further, your organization’s ability to quantify the loss of data’s CIA (confidentiality, integrity, availability) can help inform your decision-making process related to the CSP’s role in the event of data loss.
As more companies embrace innovative cloud technologies, it is imperative that data security be a top priority and part of CSP delivery, day-in and day-out. With customer/employee information at risk and corporate reputations on the line, companies must play an increasingly active and scrutinizing role in the development of service level agreements with their CSPs. Putting security-related issues on the table upfront during the contract negotiation phase enables all parties to clearly understand the expectations, limitations and responsibilities related to information security before the engagement begins. In a world where hackers and other threat actors are eager to penetrate some of the most sophisticated applications and systems of our time, data security will never be a clause that organizations can afford to overlook.