Telcos in Europe are being asked to consider encrypting their subscribers' personal information as Brussels confirmed new rules on Monday about the industry's obligation to notify customers about data breaches. The European Union's unelected digital czar, “Steelie” Neelie Kroes, said that if ISPs agreed to shield the data with …
...who specifies the strength and type of encryption required? Not much use if something as feeble as DES-56 is mandated as satisfactory. Particularly as data can then be "leaked" to the authorities, who can then decode it, and then there's absolutely no debate about how to interpret the law, as it won't apply as the data was originally encrypted at the point of breach.
Forget about the 'type' of encryption required. The system is secure if only authorised persons have the key. If unauthorised persons can get the key, the cipher is irrelevant. The complicated part is the key management, so this is the most likely problem. If there's a single key, that all the systems that process the data have, then you just have to compromise one system, and you have both the key, and access to the data.
Irrespective of whether it's encrypted or not, I don't see why this removes the need to advise that my data has been potentially munched. It may be somewhat more secure, but if it's in the hands of the black hats then it's still susceptible, it seems.
What I want to know is not particularly whether the data has been illicitly accessed but how much I can trust the storing authority.
That wasn't the point of my comment: Good key management is possible, and it's far more important that that is mandated, than what cipher is used. For example, if you said - the exemption only applies to systems where key management is designed according to the principal of least privilege, that would provide consumers with good protection. If you just said - use AES256, and some idiot encrypted all the data with one symmetric key stored in lots of places, that would be next to no protection.
You seem to think that /all/ governments obey all of the rules, like those of good key management.
Or did I totally misunderstand your point?
Store the data in a database where all personal data is encrypted using FIPS140-2 equivalent standards as a minimum. Then configure the database so that only stored procedures have read (and the others) rights. To read the un-encrypted information, a hacker would have to run an application that called a stored procedure and ensure that the user/application had execution rights for that stored procedure.
This isn't easy to do. As a result, the loss of physical data is not significant and access to the information is complicated by the need to emulate a user with stored procedure execution rights and then know which stored procedure to execute.
There is a further level of Hierarchical Rights Management that is able to measure the appropriateness of the access request and the relative relationship of the user making the request and the subject of the information requested. Whilst this sounds complicated its easier to set up than might be imagined. Where entropic systems are concerned, pseudo hierarchies are just as effective.
Do you even know what FIPS140-2 is?
'know which stored procedure to execute' - so security through obscurity then?
You need to assume the attacker has a copy of the database, which they can load into their own database software and can discover and run any stored procedure they feel like running, and that they can use your HCM device to decrypt stuff, because they got root on your database server.
In your scheme, they can do all this and you wouldn't even know about it afterwards, because you haven't described how you audit the HCM.
Your knowledge of grown up databases is slight - having what you call 'root' on the database server does NOT give decryption rights, nor should it.
And as far as knowing about FIPS140-2 is - why wouldn't I know? Personally I would implement non-US encryption, that is open-sourced.
Frankly, Mr Ireland, you are shooting from the hip. With a grown up DMBS, you can give a copy of the database to an unauthorised user and they still wouldn't be able to access the encrypted information. And as far as Audit goes, its like CCTV, it discovers that something has happened but it doesn't deter the offender in the first place, any assumption otherwise is fallacious.
missing the point
Maybe i've been a bit spoilt in the companies that i've worked for recently but why the hell isn't personal information stored encrypted in the first place? Its really not that hard to setup and requires minimum overhead.
Aside from that I would still want to be notified if my personal data has been leaked regardless of its encryption state!
So if an attacker has gone through multiple layers of security in order to get read access to the data, we are to presume that they can't deal with the encryption as well? That is a very simplistic view of things.
Encryption provides another hurdle, but not a guarantee of security if the fox is already in the hen-house.
The providers should be obliged to report the breach regardless.
To use your analogy, if the fox is in the hen-house, he still has to acquire a 'personality' that has rights to execute the appropriate procedure.
It is standard practice to obfuscate personal information when returning the result of wide ranging queries, such as would be required to download bulk information.
I take your point that the fox still has hurdles to overcome. I'm sure that it is possible to design a system where a security breach will not give the attacker access to the unencrypted data. My concern is that the rules seem to gloss over the point that it is a whole-system solution that needs to be considered (and, to my mind, mandated).
If the providers latch solely onto the 'encrypt the data' provision, then I'm sure we will get the minimum standard necessary to comply, and not the security we really should have.
Re: "The providers should be obliged to report the breach regardless."
I think the proposal as it stands is a way to encourage data-storers to embrace encryption, but it is insufficient, and conflates (at least) two very different problems: loss of data and ability to read it. Both need reporting, as they refer to two aspects of a company's security that customers need to be aware of - I'm unlikely to go with a company that is losing data (even if encrypted) on a regular basis.
In addition, as others have said, there needs to be a minimum level of encryption specified, and yet we know that the minimum will become the standard. This means the black-hats will have incentive to break it within a very short time - and I'm not sanguine that they won't. Combined with unreported data-breaches (so I don't know to change passwords (or data-storer), this is not good for me as the consumer.
The idea is well-meant, I think, but it fails to address the issues properly.
This proposal will almost certainly drive down the overall standard of security at these institutions. If encryption is all that's required to stay out of the negative press spotlight then that's all they'll do. It'll start small but things that were on the roadmap to upgrade, improve or implement for security will get dropped from the plan. Putting a 'dodge public accountability card' on the table is really bad as it sets the bar loooow for everything else.
"unelected digital czar, “Steelie” Neelie Kroes". Would you not say she has been elected as both "Steelie" and "digital czar" by the press.
I must say this "unelected" bit is getting a bit tedious. Does the writer think that Kroes is self elected? Let's raise the bar a bit, shall we?
But make sure you leave the encryption key with the NSA or GCHQ!
I'm sure that will be inserted into the final regulation somewhere!
We now know there is no question of "If there is a data breech"
We now know there is no question of "If there is a data breech" if the data goes anywhere the UK or USA.
Hack in higher up
All this stuff about encrypted databases is all very well, but IMHO is looking at the wrong issue. If the assailant gains access to the application that is accessing the data, ie the layer above the database processes, then they will be able to read the database through the normal channels and will pass straight through the encryption transparently as would an authorised operator. The encryption, or indeed lack thereof is, in that case, completely irrelevant.
- Twitter: La la la, we have not heard of any NUDE JLaw, Upton SELFIES
- China: You, Microsoft. Office-Windows 'compatibility'. You have 20 days to explain
- Apple to devs: NO slurping users' HEALTH for sale to Dark Powers
- Is that a 64-bit ARM Warrior in your pocket? No, it's MIPS64
- Apple 'fesses up: Rejected from the App Store, dev? THIS is why