Research

History is a funny thing. It’s amazing that what many children see in early schooling as a boring collection of facts is neither boring nor factual. On a good day we might get some dates correct, but there isn’t a “fact” in history that isn’t open to interpretation. This is as it should be; think about all the factors that went into a major life decision- say a marriage or picking your college. Now distill everything involved in that decision into a paragraph, stick it in a drawer for a couple decades, pull it out, and see if it still matches your memories and accurately reflects the situation. If you don’t have a few decades to spare, the answer is, “it doesn’t.” The main problems with history are actually those we see in computer science- bandwidth, compression, indexing, and search. We can’t possibly collect and store all the bandwidth of human interaction, so we drop into “sampling mode” and further compress it for long-term storage. We then rely on imperfect indexing to organize the data, and flawed search protocols to find what we need. We don’t collect everything, lose large amounts of data in compression, poorly index it, and rely on primitive search tools. No wonder history is open to interpretation. Take the Maginot Line. And Encryption. For those of you who aren’t military history buffs, the Maginot Line was a series of interlocking defenses, sometimes 25 kilometers deep, that the French built after WWI to keep the Germans out. In popular security culture the term is often used as an analogy to describe a misguided investment designed to fight the last war that’s easily circumvented. In marketing films of the time the Maginot Line was promoted as being an invincible defense for France. A folly painfully realized when the German invasion succeeded in only a month. A metaphor for a failure of hubris. Reality is, of course, open to interpretation. Another interpretation of the Maginot Line is that it completely succeeded in its defined task, preventing a frontal assault along the Franco-German border. The Maginot Line held, but the other defensive layers- the Ardennes and the French Army along the Belgian border- failed. The Maginot Line was designed for a mission it effectively met, but other design flaws in the defense in depth of France lead to the German occupation. Which brings us to encryption. The first version of the PCI Data Security Standard called encryption, “the ultimate data security technology”. Wrong. Encryption is a powerful technology, but probably the most-misunderstood in the context of what it provides for data security. With the McAfee acquisition of SafeBoot for $350M, encryption is in the headlines again. A while ago I wrote the Three Laws of Data Encryption to help users get the most value out of encryption. I really do think of encryption as the Maginot Line of data security. It’s powerful, nigh invincible, if used correctly, but easily circumvented if your other security controls aren’t properly designed. For example, if you have a large application connected to a large database full of encrypted credit card numbers, and that application is subject to SQL injection, odds are your encryption is worthless. Laptop encryption protects you from stolen laptops, but is useless against malicious software running in the context of the user. As I keep walking through the Data Security Lifecycle you’ll see a lot of posts on encryption; it’s a fundamental technology for protecting content. But when big companies start throwing around hundreds of millions of dollars I think it’s an opportune time to step back and remind ourselves of the problem we’re trying to solve, and how the different parts of the solution fit together. If we want a real-world example we need to look no further than TJX. Rumor has it that cardholder data was encrypted, but the attackers sniffed an unencrypted portion of the communications to perform transactions. The encryption worked perfectly, but the breach still succeeded. Share:

Jeremiah posted these questions on dealing with website vulnerabilities. Here are my quick answers (I have to run- sorry for the lack of links, but you can Google the examples): Lets assume a company is informed of a SQLi or XSS vulnerability in their website (I know, shocker) either privately or via public disclosure on sla.ckers.org. And that vulnerability potentially places private personal information (PPI) or intellectual property at risk of compromise. My questions are: 1) Is the company “legally” obligated to fix the issue or can they just accept the risk? Think SOX, GLBA, HIPAA, PCI-DSS, etc. Definitely no for intellectual property. Definitely no for SOX- SOX says you’re free to make as many dumb mistakes and lose as much money as you want, as long as you report it accurately. Other laws are a toss-up, but generally there is no obligation unless there is evidence that a breach occurred. For PCI-DSS you have to remediate or document compensating controls for any network vulnerabilities at the time of your audit (and this expands to applications with 1.1), but there is no definitive requirement for immediate remediation. California AB1950 is the big question mark in this area and I’m unsure on enforcement mechanisms. The regulations are very unclear and unhelpful here, and it’s quite likely a company can accept the risk. But if a breach occurs, they may be held negligent. Take a look at the PetCo case where the FTC mandated a security program after a breach, and Microsoft/MSN. The companies were held liable for losing customer data, but not because of any of the usual regulations. There is almost no case law that I’m aware of. 2) What if repairs require a significant time/money investment? Is there a resolution grace period, does the company have to install compensating controls, or must they shutdown the website while repairs are made? No. Most regulations only require breach notification or remediation of flaws discovered through auditing. Reasonable person theory probably applies if there is a breach with losses and it goes to court. I’ve read all of the regulations- none mention a specific time period. 3) Should an incident occur exploiting the aforementioned vulnerability, does the company bear any additional legal liability? They may carry liability due to negligence. See the cases I mentioned above. 4) If the company’s website is PCI-DSS certified, is the website still be considered certified after the point of disclosure given what the web application security sections dictate? Unknown because there are no public cases that I can find. I believe you remain certified until the next audit. In the case of Cardsystems, they were PCI certified when the breach occurred and immediately re-audited and de-certified following public disclosure of the breach. That’s one problem with PCI-DSS- it’s very audit-reliant and changes between audits don’t directly affect certification. 5) Does the QSA or ASV who certified the website potentially risk any PCI Council disciplinary action for certifying a non-compliant website? What happens if this becomes a pattern? No known cases of disciplinary action, but an audit insider might know of one. Disciplinary action will most likely only take place if the audit failed to follow best practices and a large breach occurs, or if there is (as you mention) a pattern. None of this is formalized to my knowledge. I’ve spent a lot of time researching and discussing all the various data protection and breach disclosure regulations. Organizations generally only face potential liability if they either falsify documentation for auditing or certification, or suffer a breach and are later shown to be negligent. I am unaware of legal enforcement mechanisms if there is a known vulnerability, but no definitively unapproved disclosure of information. This is an inherent risk of audit-based approaches to data protection. Share: