Binney: Part of his job as the system administrator, he was to maintain the system. Keep the databases running. Keep the communications working. Keep the programs that were interrogating them operating. So that meant he was like a super-user. He could go on the network or go into any file or any system and change it or add to it or whatever, just to make sure — because he would be responsible to get it back up and running if, in fact, it failed.
>
> So that meant he had access to go in and put anything. That's why he said, I think, "I can even target the president or a judge." If he knew their phone numbers or attributes, he could insert them into the target list which would be distributed worldwide. And then it would be collected, yeah, that's right. As a super-user, he could do that.
I have a feeling that the NSA deals with access control just like the rest of us...very poorly. Even more egregious is that Snowden was a contractor...if we're going to leave open the possibility of the NSA targeting us at their whim, can't they at least do that in-house?
Securing data against a systems administrator however is difficult on the best of days. I have done some of this for Efficito (http://www.efficito.com). Even with the best of care there are ways an administrator can get the info no matter what you do. All you really can do is restrict it to ensure that casual access is not an issue.
For example, we store virtual machine root passwords in an encrypted database for last resort purposes (so that someone can log in using virsh console as root when nothing else is working). There are three layers of encryption and as far as casual access goes (assuming nothing is reconfigured), mere root access to the box is not enough to reveal the information. However if you can change what is logged by PostgreSQL and reconfigure PostgreSQL's authentication options you could grab enough information to effectively read this data.
People with the sort of access required to make sure things are secure can effectively get the data off the system that they want, and the alternative in designing a system is to have one with no superusers and the possibility that information is irrevokably lost when someone forgets a password. The most secure systems end up somewhere between them.
It comes down to physical access (in the sense as they can log into the box as root) - if you value security someone (single or "multiple person user") must be able to log in as root. Someone must be able to access the data hardware that contains the data, otherwise you'll might as well not store it and save the headache. Once you have admins with the ability to be root on the box, they can get the data. There is no way around it. What you can (and should do) is have access logs saved at least at one location where noone can delete anything. I suppose you could encrypt the data and save the key on a dedicated tamperproof box (are IBM still the main provider of these?), but someone must manage this box. Trust is inevitable, at best you can divide it in such a way that the combined entity is unlikely to go rogue.
It's actually more complex than that. One of the things that really gets in the way of encrypted storage, when you think about it, is the reality that key management involves tradeoffs too. For example, we could divide things up that you could get the encryption key only on a separate system and so only a public key and the public key encrypted symmetric key are stored. In this model you only get either symmetric key-encrypted data, or the public key-encrypted symmetric key.
The problem though is that someone still has to have the right to rotate keys and this process can be attacked too. For example, one could rotate keys to a known value thus giving the attacker access to the plain text. Worse, the person who can rotate the keys has to have the right to access both old and new keys in an unencrypted state.
Now, given that reality, it isn't clear to me that the fact that someone could set up the database to log all queries, and allowing passphrases for encryption to be passed in in the query poses a real added danger.
Another option is just not to allow key rotation but that allows for attacks on the key itself. You can get aroudn this by having a different key for each piece of data and thus limit the utility of cracking each piece.
However if you go that route, then you have two computers to secure instead of one, and it is vulnerable to more types of attacks than before since you are now trusting the client.....
You hint at it: There are certainly ways to spread the trust. Require a physical key to allow root logins, and keep it in a monitored safe in the data centre. Require logs of who pulls the key, and entrust access to that physical key only to a separate group of people from those with the root passwords.
Of course the problem is that methods like this takes a lot of effort, and so it is a tradeoff between safety and the cost and convenience, and in reality very little data.
Just a spur of the moment thought, but can you encrypt the master password such that you need passwords from three of four (or any N of M) people to decrypt it?
Yeah, everything I've been seeing seems to be that they seriously threw out everything about being competent in the 1990s, and then blew up into something huge (and incompetent) in the post-9/11. Hayden does not seem to have been a good director at all, at either NSA or CIA, and was responsible for the big push toward contractors as well.
Probably in the 1990s when they moved operational systems from timeshare/unix/etc. multiuser to a bunch of networked Windows desktops for all use, not just office automation (which is how they brought them in originally).
Sure, and SELinux itself can be poorly configured. Security measures in general need to be thought through in the context of the actual deployment. I just meant that mandatory access control of the general sort needed here has obviously been historically on the NSA's radar (moreso than the rest of the world, even) and here they are failing at it, and that's a little bit sad and a little bit funny in addition to everything else that's going on.
Does the fact that they're contractors and not employees absolve the contractee of some/any liability/culpability? Perhaps, further, even recursively as the contractors themselves wouldn't be able to discuss the contractee's business to the extent a direct employee could?
It does seem absurd if there isn't politico-judicial rationale.
Comments
I have a feeling that the NSA deals with access control just like the rest of us...very poorly. Even more egregious is that Snowden was a contractor...if we're going to leave open the possibility of the NSA targeting us at their whim, can't they at least do that in-house?
Securing data against a systems administrator however is difficult on the best of days. I have done some of this for Efficito (http://www.efficito.com). Even with the best of care there are ways an administrator can get the info no matter what you do. All you really can do is restrict it to ensure that casual access is not an issue.
For example, we store virtual machine root passwords in an encrypted database for last resort purposes (so that someone can log in using virsh console as root when nothing else is working). There are three layers of encryption and as far as casual access goes (assuming nothing is reconfigured), mere root access to the box is not enough to reveal the information. However if you can change what is logged by PostgreSQL and reconfigure PostgreSQL's authentication options you could grab enough information to effectively read this data.
People with the sort of access required to make sure things are secure can effectively get the data off the system that they want, and the alternative in designing a system is to have one with no superusers and the possibility that information is irrevokably lost when someone forgets a password. The most secure systems end up somewhere between them.
It comes down to physical access (in the sense as they can log into the box as root) - if you value security someone (single or "multiple person user") must be able to log in as root. Someone must be able to access the data hardware that contains the data, otherwise you'll might as well not store it and save the headache. Once you have admins with the ability to be root on the box, they can get the data. There is no way around it. What you can (and should do) is have access logs saved at least at one location where noone can delete anything. I suppose you could encrypt the data and save the key on a dedicated tamperproof box (are IBM still the main provider of these?), but someone must manage this box. Trust is inevitable, at best you can divide it in such a way that the combined entity is unlikely to go rogue.
It's actually more complex than that. One of the things that really gets in the way of encrypted storage, when you think about it, is the reality that key management involves tradeoffs too. For example, we could divide things up that you could get the encryption key only on a separate system and so only a public key and the public key encrypted symmetric key are stored. In this model you only get either symmetric key-encrypted data, or the public key-encrypted symmetric key.
The problem though is that someone still has to have the right to rotate keys and this process can be attacked too. For example, one could rotate keys to a known value thus giving the attacker access to the plain text. Worse, the person who can rotate the keys has to have the right to access both old and new keys in an unencrypted state.
Now, given that reality, it isn't clear to me that the fact that someone could set up the database to log all queries, and allowing passphrases for encryption to be passed in in the query poses a real added danger.
Another option is just not to allow key rotation but that allows for attacks on the key itself. You can get aroudn this by having a different key for each piece of data and thus limit the utility of cracking each piece.
However if you go that route, then you have two computers to secure instead of one, and it is vulnerable to more types of attacks than before since you are now trusting the client.....
You hint at it: There are certainly ways to spread the trust. Require a physical key to allow root logins, and keep it in a monitored safe in the data centre. Require logs of who pulls the key, and entrust access to that physical key only to a separate group of people from those with the root passwords.
Of course the problem is that methods like this takes a lot of effort, and so it is a tradeoff between safety and the cost and convenience, and in reality very little data.
Just a spur of the moment thought, but can you encrypt the master password such that you need passwords from three of four (or any N of M) people to decrypt it?
Yes. See http://en.wikipedia.org/wiki/Secret_sharing; if you know a bit of mathematics, Shamir's method is particularly elegant.
You can, but then key management is a bitch.....
Which is funny, because I thought mandatory access controls was the key feature that the NSA added in SELinux.
Yeah, everything I've been seeing seems to be that they seriously threw out everything about being competent in the 1990s, and then blew up into something huge (and incompetent) in the post-9/11. Hayden does not seem to have been a good director at all, at either NSA or CIA, and was responsible for the big push toward contractors as well.
Right? What happened to "No read up and no write down" and all the other gnarly things from the orange book and its colorful friends.
Probably in the 1990s when they moved operational systems from timeshare/unix/etc. multiuser to a bunch of networked Windows desktops for all use, not just office automation (which is how they brought them in originally).
SELinux is no match for a poorly set-up database.
Sure, and SELinux itself can be poorly configured. Security measures in general need to be thought through in the context of the actual deployment. I just meant that mandatory access control of the general sort needed here has obviously been historically on the NSA's radar (moreso than the rest of the world, even) and here they are failing at it, and that's a little bit sad and a little bit funny in addition to everything else that's going on.
Does the fact that they're contractors and not employees absolve the contractee of some/any liability/culpability? Perhaps, further, even recursively as the contractors themselves wouldn't be able to discuss the contractee's business to the extent a direct employee could?
It does seem absurd if there isn't politico-judicial rationale.