Clark Morris wrote: >In looking at the news, I'm wondering if encryption would have >prevented any of the known data breaches. I'm thinking of Equifax, >Anthem, Target and Yahoo for starters.
The Anthem breach was the result of a phishing attack, and an internal machine was compromised. At that point, the bad guys are so far inside the tent that it's not clear what would have helped. See https://www.bankinfosecurity.com/new-in-depth-analysis-anthem-breach-a-9627 Target was more interesting: the POS terminal software was compromised, and so it was stealing data that was being passed through the payments path in the clear. Encryption *in the terminal* would have stopped that. See http://www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/ and lots of others (since this is an older one, there's lots out there if you search "target breach analysis"). Finally, Yahoo has been breached repeatedly. A bit of Googling finds focus on why the most recent breach was fruitful: the bad guys stole unsalted MD5-hashed passwords, thus allowing a rainbow table to be used against the data. This is so basic and obvious in the security business that I think most people at that point said "It doesn't matter how exactly the data was exfiltrated-Yahoo was just asking for it". But I'm sure there are more detailed discussions out there. The key to making encryption be as effective as possible is to only decrypt the data occasionally. That means that transparent encryption, such as whole-file encryption in z/OS, isn't that effective. It's not useless, but it's not as effective as application-level encryption, simply because it means that things "below" the application in the stack can be breached and allow data theft (as opposed to what I might call "byte theft", i.e., stealing encrypted data, which is of no value). Of course if the application is truly breached, all is lost-if the application has rights to cleartext data. <puts on vendor hat> Using format-preserving data protection means that many applications can operate on the data in its protected state, without changes. Simplest example: a credit card number (PAN). However many applications you have that touch PANs, the only ones that ever need the cleartext are the ones that ingest them from the outside world (web pages, customer service applications, et al.) and the one that passes it to the processor for authorization/settlement. And *maybe* some folks in fraud prevention. Otherwise, it's just a magic 15- or 16-digit number (soon to be more digits, o boy): all you care about is that it's consistent and unique, and that it looks like a PAN. So if you protect the middle six digits (all that PCI DSS requires) *as soon as you acquire it*, then several good things are true: 1) All of the other applications are safer (note that "r"!) because they will never touch cleartext 2) All of the other applications are out of PCI scope 3) All of the other applications need no changes 4) Data is interoperable with other systems, including ASCII systems, without requiring decryption before transmission 5) The attack surface for PANs (assuming proper control of key access, etc., of course) is limited to the acquiring applications and the application that does authorization/settlement So with relatively little effort, you've protected a lot of the system. Again, as others have noted, defense-in-depth means you also want DASD encryption, you also want encrypted backups, you also may use whole-file encryption in cases where data has to be stored as cleartext. <removes vendor hat> >If one steals a database, they >need to be able to steal the means to read it which would mean they >have a computer compatible with the target company and the >corresponding software. While dumps of tape files can give probable >hits, if the record descriptions aren't available, there is at least >some difficultly in guessing which fields are what. How did the >thefts work and to what extent did the thieves appear to the system as >valid users? True, but any protection you're imputing there is "security by obscurity". If I had managed to get into Equifax and acquired a raw dump of a 10TB database, I think I could find a z/OS system somewhere (or build one) and figure out how to read it so I could monetize that dump. Or maybe I'd just do analysis and make some guesses. >Are test systems, even with data masking applied to production data, >of use to thieves? If they have improper access to real data, sure; and if they provide a way to understand data flows and connections to enable attacks on production, also yes. That is, if a test system isn't secure "because it's just a test system", and that lets bad guys bang on it unnoticed until they find a hole that they can then use on the production system, then definitely. >What are the risks of encryption? Loss of password or keys seems a >noticeable risk as does compromise of same. Encryption mantra: "Encryption is easy; key management is hard". So definitely. Performance is another issue-done badly, it can be a killer, especially (obviously) in real-time processing: if adding encryption means that web "Buy" button now takes 30 seconds, folks will stop using that site. If adding encryption means the nightly batch window now takes 36 hours... All good questions, and obviously you pushed some of my favorite buttons! I'll stop now :) -- ...phsiii Phil Smith III Senior Architect & Product Manager, Mainframe & Enterprise Distinguished Technologist Micro Focus (Voltage) phs...@microfocus.com T 703-476-4511 M 703-568-6662 Herndon, VA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
