While the current vendor environment clearly poses significant challenges and risks to businesses entrusting them with their data, use of encryption can, at least in many cases, materially mitigate that risk. The devil, however, is in the details …
I previously wrote several posts about the somewhat dire state of the world with regard to information security in vendor and supplier relationships. In particular, I noted the growing trend by vendors to decline material liability for security breaches – even in cases of gross negligence and willful misconduct. I also wrote most recently about how vendors are subcontracting key elements of their services to third party cloud providers and then disclaiming all liability for them. In the past, the vendor would have simply agreed they are responsible for such cloud providers as their subcontractors. Today, however, a number of vendors are taking the position they will assume little or no liability for the cloud providers they choose to use. The foregoing trends have led to a significant diminution in information security protections for businesses in their vendor relationships.
The question before us today is “what can a business do in this new vendor environment to mitigate risk?” The answer is not very palatable. Let’s return to the old and well-worn acronym of “CIA.” It is one of the cornerstones of information security. CIA stands for Confidentiality, Integrity and Availability. In the current vendor environment, it is frequently not possible to achieve all three of these components, but the use of encryption may provide at least a partial solution to two of them: confidentiality and integrity.
Now I am well aware that many vendors offer encryption as part of their services. But, lets look a little closer at exactly what they are offering. The typical conversation with a vendor goes something like the following:
Customer: I am concerned that you are refusing to assume any real liability for data breaches. If there is a breach, your liability is limited to a trivial amount.
Vendor: Do not be concerned at all. We have structured our services so that there is no possibility of a data breach. We use encryption to protect all data stored on our service. In the unlikely event of an unauthorized access, the only thing compromised would be unreadable data. Your data is never placed at risk. It is always protected.
Customer: So you select the encryption algorithm, implement it, and handle key generation and management? Suppose one of those elements is mishandled and our data is breached in unencrypted form? What is your liability?
Vendor: While we certainly stand behind our industry-leading security measures, we don’t assume any heightened liability for failure of those measures. The good news is that our encryption is rock-solid.
Customer: But suppose you are negligent in your choice of encryption methodology and its deployment?
Vendor: That won’t happen. Trust us.
Bottom line: the customer has nothing but the vendor’s best intentions to rely on. If the vendor uses an outdated encryption methodology, fails to implement it properly, or mishandles key generation, they offer no real liability. As a result, the vendor’s offer of industry-leading encryption is, at best, “sales talk.” Businesses cannot rely on it.
What then are businesses to do? The answer is to handle encryption themselves. This allows the business to have greater confidence in the protection of its data. While this cannot be done in every instance for every service, it can be done for many.
There are three approaches:
The problem with this approach is that it generally only works for very rudimentary vendor services (e.g., cloud-based backup systems). It cannot be used for most interactive services furnished by vendors.
This provides a broader range of services for which the customer can take control of encryption. In addition, many vendors of these middleware applications are willing to assume material liability for security flaws in their products.
This is clearly the future and the most seamless means of mitigating risk. Already, several internationally recognized cloud providers are making this option available for some of their core services. I expect to see more vendors doing so in the near future. It is a competitive advantage to offer this functionality.
An issue closely related to encryption and one that is often overlooked is secure destruction of data on termination of the vendor contract. All too often, this key issue is relegated to a sentence along the following lines: “On termination of this Agreement, Vendor will delete the customer data.” Certainly, this is short on detail. If only a few words can be changed, we would recommend making clear the deletion must be “secure and irrevocable.” A better practice, however, is to expressly reference one or more of the recognized standards in the industry for destruction. For example:
On termination of this Agreement, Vendor shall ensure all Client Confidential Information has been “scrubbed” and irretrievably deleted from its systems and records using methods consistent with best industry practices (i.e., at least as protective as the DoD 5220-22-M Standard, NIST Special Publication 800-88, Guidelines for Media Sanitization, or NAID standards).
Note that in some industries there are clear preferences for one of these destruction methods over the others. Make sure to reference the appropriate standard.
While the current vendor environment clearly poses significant challenges and risks to businesses entrusting them with their data, use of encryption can, at least in many cases, materially mitigate that risk. The devil, however, is in the details. If the vendor controls the process and refuses any real liability for any flaws in that process, then the customer will have little additional protection. If, on the other hand, the customer can have a hand in controlling that process, far greater protection can be achieved.
This was originally published at CSOOnline.com.