As part of its enduring interest in LifeLock, Inc., the Federal Trade Commission issued the following statement on December 17, 2015, “PCI DSS certification is insufficient in and of itself to establish the existence of reasonable security protections … the existence of a PCI DSS certification is an important consideration in, but by no means the end of, our analysis of reasonable security.” This statement might be alarming to the business and security communities, but it’s important to understand their statement in context, and for you to know what to do about it.
First, let’s understand the reason why the FTC is interested in LifeLock. In 2010, the FTC filed a complaint against LifeLock stating that their advertisements for protecting their customers against identity theft were misleading. Moreover, the FTC complained, LifeLock was not protecting their customers’ personal information the way they advertised. Controls such as “need-to-know” access rights and encryption were not in place.
As a result, the FTC sued LifeLock in the U.S. District Court of Arizona, which issued a judgment and injunction requiring LifeLock to put in place a comprehensive information security program. That program required LifeLock to assign a responsible officer, conduct security risk assessments, implement “reasonable safeguards” to control their risks, regularly test and monitor the safeguards, and improve the security program in response to findings from their testing and monitoring.
If the stipulations in this judgment sound daunting or unfamiliar, then you have not been paying attention to how the federal government talks about information security. For more than a decade, these requirements have been the basis of the HIPAA Security Rule, the FTC’s consent orders against organizations that suffer data breaches (after falsely claiming to use security safeguards), the guidance for following the Gramm-Leach-Bliley Act’s Safeguards Rule, NIST SP 800-30, 800-37, and 800-53, and now the Cybersecurity Framework that NIST published at the behest of the White House in 2014.
When the Federal Trade Commission reviewed LifeLock’s progress in operating a comprehensive security program in 2015, they found that, despite their PCI DSS certification, LifeLock had not met the 2010 judgment’s stipulations. While the nature of LifeLock’s violations remain under seal, the FTC in their December 2015 statement compared LifeLock’s shortcomings to Wyndham Worldwide Corporation’s failure to conduct risk assessments, among other things.
So now with that background out of the way, let’s talk about why the FTC was not convinced that PCI DSS certification is substantive demonstration of a comprehensive information security program.
Risk Assessments Are Not Compliance Assessments
Put most concisely, compliance assessments focus on security controls. Risk assessments focus on security threats. Compliance assessments, like those that lead to PCI DSS certifications – and that most resemble audits and gap assessments – approach an organization with a list of security control requirements, and some sort of review process to determine whether those controls are in place. On the other hand, risk assessments determine how resilient an organization is to foreseeable threats. Risk assessors will use those security controls lists as a way to identify vulnerabilities. But really, risk assessors must think like thieves, neglectful employees, malware, and fires in order to determine the likelihood and impact that those bad activities will have.
Why does this difference matter? Because this is how lawyers think. For more than a century, lawyers have talked about negligence, due care, and the “reasonable person” to determine whether someone was at fault when someone else fell into harm. If a shop owner has an icy sidewalk and a customer slips and hurts himself on his way into the store, did the shop owner take appropriate care to prevent her customers from getting injured? If her shop underwent an annual safety certification audit, she might please the assessor and get her certification every July. But threats change over time. We may be pleased to know that under scrutiny she impressed an auditor. But her duty of care is to be aware of the dangers that could hurt others, and to be sure that she put safeguards in place to reduce the likelihood and impact of those dangers.
When the shop owner sees that it is raining and the temperature is dropping below 32 degrees, and she knows that her customers will be walking on a freezing, wet sidewalk, she is expected to think through the risk, and to do something like spread salts on the sidewalk to reduce the risk of harm to others.
Notice that there is no certification for the federal regulations and security standards that are listed above. HIPAA, GLBA, and NIST standards are not verified through certification bodies. That’s because certifications are not evidence that controls are appropriate to the risks as those risks are realized. They do not ensure that the appropriate risk analysis and risk treatment are regularly applied for situations when harm comes to others, and this is the foundation on which attorneys determine due care. More on that point later.
But Doesn’t PCI DSS Require Risk Assessments?
PCI DSS does require that certified organizations undergo risk assessments similar to ISO 27005, NIST 800-30, or OCTAVE. But ask the next PCI QSA you come across what a risk assessment looks like. They most likely cannot describe an actual risk assessment to you. QSAs will often accept technical vulnerability assessments, penetration tests, gap analyses and high-level interviews, such as, “What keeps you up at night?” as risk assessments.
Instead, a risk assessment should include a set of components to analyze, such as:
- Foreseeable threats
- The information assets that can be compromised
- Current controls in place to mitigate those threats
- Vulnerabilities that threats may take advantage of
- The likelihood and impact of those threats
- An evaluation of the risk (often expressed as ‘Risk = Likelihood x Impact’)
- Alternative safeguards that can reduce risks to an acceptable level
- A demonstration that the safeguards do not pose too great a burden on the organization.
There are many meaningful ways of assessing risk, so these components can vary and remain valid. Where possible, probability analysis is better than simple likelihood analysis. Considering a threat variable in the risk calculation is also useful. And time considerations, such as time-based response to certain risks is also very useful.
A risk assessment must somehow systematically and earnestly model threats and determine, based on an understanding of current safeguards, how foreseeable and impactful those threats are in a given environment. But risks that are unacceptably high must be met with a plan for safeguards that would reduce the risks to acceptable levels, and the plan must be acted on. When safeguards are in place, they must be monitored and tested to be sure that they are effective. If they are not effective, they must be improved.
If you read the PCI DSS standard and the guidance from the PCI Counsel, you will understand that the counsel does not expect that the controls listed in the standard are sufficient to prevent data breaches. Rather, the DSS represents, in their words, “a baseline of technical and operational requirements.” The risk assessment is meant to help you think through what there is left to be done to reduce risks to an acceptable level.
So maybe now you are starting to get the picture of what the FTC was talking about in the LifeLock case (and the Wyndham case as well). PCI DSS certification is a step in the right direction, but the regulator needs to see that we thought through the harm that could come to others, and we’ve implemented safeguards to be sure those things didn’t happen.
So What is a Reasonable Safeguard Then?
Since we are discussing how lawyers and regulators talk about reasonableness (duty of care), let’s delve into how they’ll recognize reasonableness when they come across it. For more than a century lawyers have talked about the “reasonable man” or more recently the “reasonable person.” The concept is used in negligence cases to determine whether a defendant in a lawsuit acted as any reasonable person would to ensure that others are not harmed. Leaving the decision up to a jury or judge, the idea of the “reasonable person” has been vague and often at the mercy of the court.
Many decades ago a 2nd U.S. Circuit Court judge by the name of Learned Hand tried to provide guidance for determining reasonableness by positing that the burden placed on the defendant for protecting others from harm should not be greater than the probability of the threat multiplied by the foreseeable liability. Much like the risk calculus ‘Risk = Impact x Likelihood’, Judge Hand’s calculus meant to estimate risk as a combination of foreseeability and harm. But further, he stated that nobody should be expected to take on a burden greater than the risk they are attempting to prevent. This guidance, known as the Hand Rule, or the Calculus of Negligence, has been variably informative, but it is very useful for providing a standard of care for information security. If we can compare a burden to a foreseeable liability, then we can show on paper whether a safeguard is reasonable.
It is up to us, then, to look at our environment (technical, operational, environmental, political, and physical) and consider what might go wrong in a way that can harm others. We then must review our safeguards – our controls and processes – to consider the likelihood and impact (at least) of those threats in our environment.
Moreover, we can demonstrate when recommended safeguards are not reasonable. If LifeLock had a risk register that showed that encryption in certain datasets created an undue burden on the service that their customers found value in, they would have a strong case against the FTC’s claims of unreasonable security. But alas … it appears they did not have such preparation.
HALOCK has been analyzing risk this way or many years, and the payoff to our clients has been large. Business managers and technical managers come to agreement on investment and priorities because risk is stated in business terms. Auditors and management agree on the relevance of audit findings when they are analyzed in terms of risk. Regulators find that they cannot argue with organizations who define risk the way regulations tell them to. And judges and attorneys find a compelling story about a company that was hacked despite their meeting their duty of care.
Where to Go From Here
PCI DSS and other information security certifications are very helpful in getting organizations to think through a standard set of cyber security controls that they should use to protect their systems and data. But these certifications are most useful for addressing contractual obligations for meeting minimum security requirements.
The courts and regulators have a different standard, however. When we use risk assessments to think through harm that may come to others, and the burden we may take on to protect them, we not only start speaking the language of law, but we avail ourselves of the opportunity to convert this legal model into a business-sensitive model for security management. We have a right (in fact an obligation) to apply safeguards that balance our mission and our objectives with the duty of care we owe others.
The language that the FTC uses to describe their standard of judgment, “the reasonableness of security will depend on the facts and circumstances of each case” seems like an unfair post-facto test until you realize what they mean by “reasonable” and “risk assessment.” And if you conduct your risk assessment before your breach … when the attorneys come knocking, you will own the conversation.
