Peter Relson wrote: >Isn't the answer really: no, it would not have prevented the breach but it >would have prevented the breach from having the undesirable effects (e.g., >exposing sensitive data)?
First of all, a strong, multi-layered defense can indeed prevent (inner) breaches even as you've (re)defined them. A successful breach often involves "leapfrogging." That is, the attacker penetrates the first (only?) line of defense, obtains unencrypted or too weakly encrypted credentials, then uses those credentials to penetrate the next layer. Indeed, this is precisely the reason why KDFAES support was added to RACF some time ago. (Please turn KDFAES, passphrases, and, preferably, multi-factor authentication on if you haven't already! And try to make sure that RACF or your other security manager is put back in charge of at least authorization. If RACF only knows about server-level IDs because authorization has been fully delegated elsewhere, that's probably bad.) In my view, your definition is not what most people mean with the word "breach." I agree with most people. I don't think a hyper technical definition is too useful here, and it could easily be misleading and take precious focus off what the planet really needs. If your definition of "breach" holds, then you have to clarify why sending sensitive data over a properly encrypted VPN connection, or discarding/recycling a properly encrypted and physically intact disk or tape, is not a "breach." Those patterns also involve someone potentially or actually able to intercept, record, and do whatever they wish with the encrypted data. The data, in encrypted form, is made public. But properly encrypted data, without access to the private key, is useless. Properly encrypted data could be burned onto CDs and mailed to every household -- AOL style -- and there'd be no breach in any sensible meaning of the word. Dictionaries appear to agree with me (and others): http://www.dictionary.com/browse/breach?s=t As an analogy, a police or military force will often, quite deliberately, allow an attacker entry into a particular zone. Even facilitate and encourage that entry. Is that a "breach"? No, it's not. The reason they do this is because it makes it easier to catch the attacker and to gather evidence, as in police sting operations. It is *then* possible for operational security to be breached if the attacker is more clever than expected, but that's rare. So I disagree with your definition of "breach." I would use words like "unauthorized copying of encrypted data with no security impact" to describe what you're describing. Elardus Engelbrecht wrote: >If breachers are insiders themselves, you're basically out >of luck and goodbye to your [sensitive and unencrypted] data. No, I disagree again. In my view we shouldn't perpetuate the myth that the "god administrator" is necessary. It's just not true. We know how to design, deliver, and operate systems that do not require operators and administrators to be deities, at least not solo deities. We know how to prevent insider attacks. The whole concept of "inside" versus "outside" is outmoded at best. It's "Maginot Line" thinking, and it demonstrably doesn't work. Many organizations have already adopted a non-god IT approach, quite successfully. z/OS Data Set Encryption, properly implemented, is one of the unique capabilities that can help. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
