Two-PERSON authentication

[lordsegan]

My company recently came into possession of some data which will require two-PERSON authentication as the risk of a rogue employee is simply not acceptable with this data.

What sort of products are available to secure linux/Solaris with two person authentication for privileged access?

 

[jjeff1]

Split the password in 1/2, give each half to one person.

For more security, split a long password into 3 pieces and give 2 pieces each to 3 people. Then you can access the data with any 2 of the 3 people present.

 

[dave99]

or some sort of token/smart card system, one guy has the password, other guy has the token.

 

[Thuleman]

How is two-PERSON authentication mitigating the risk of a rogue employee?

If the data is really that sensitive you are far better off creating an environment that doesn't allow for any attached devices, doesn't do wifi or bluetooth, doesn't allow printing to a physical or software (PDF, XPS, etc.) printer, doesn't allow users to install anything, has the ability of screen capture removed, isn't on the regular but an isolated physical network, doesn't allow employees to enter the terminal room with any electronic device (i.e. smartphone), yadda yadda yadda.

Two-PERSON authentication adds a lot of complexity but only perceived (vs. actual) security.

 

[Red Squirrel]

How is two-PERSON authentication mitigating the risk of a rogue employee?

If the data is really that sensitive you are far better off creating an environment that doesn't allow for any attached devices, doesn't do wifi or bluetooth, doesn't allow printing to a physical or software (PDF, XPS, etc.) printer, doesn't allow users to install anything, has the ability of screen capture removed, isn't on the regular but an isolated physical network, doesn't allow employees to enter the terminal room with any electronic device (i.e. smartphone), yadda yadda yadda.

Two-PERSON authentication adds a lot of complexity but only perceived (vs. actual) security.

Well I can't imagine anyone wanting to risk the other person telling on them so it would help unless both people have the same motive.

When I worked at the help desk we had a customer that was setup in a similar way, we were the 2nd part of the authentication. We had a RSA token in a locked drawer and they would call us for the number, they only had the pin. They could not get into the system without us and we could not get in the system without them.

 

[lordsegan]

How is two-PERSON authentication mitigating the risk of a rogue employee?

If the data is really that sensitive you are far better off creating an environment that doesn't allow for any attached devices, doesn't do wifi or bluetooth, doesn't allow printing to a physical or software (PDF, XPS, etc.) printer, doesn't allow users to install anything, has the ability of screen capture removed, isn't on the regular but an isolated physical network, doesn't allow employees to enter the terminal room with any electronic device (i.e. smartphone), yadda yadda yadda.

Two-PERSON authentication adds a lot of complexity but only perceived (vs. actual) security.

Ultimately, some human has to have "root" on the machines. In the situation we face, we cannot trust a single human with that. With root you can wipe any log or other traces of your malfeasance.

That's why we need two person authentication. I think I've found some software that enforces that. I also have found software that does remote logging so you can track in real-time what "root" is doing and put those logs on a third-party controlled box for safe audit.

 

[Thuleman]

Ultimately, some human has to have "root" on the machines. In the situation we face, we cannot trust a single human with that. With root you can wipe any log or other traces of your malfeasance.

While what you are saying is true when it comes to what root can do I do have a hard time with the premise of "we cannot trust a single human". The data didn't magically appear on your system, one particular individual put it there by either transferring it from somewhere else or by creating it. In boot cases 'root' isn't your only single source of contact.

With data this sensitive there's going to be data versioning, replication to an off-system or off-site location, any number of ways additional people will come in contact with the data and any number of additional ways that issues that creep up can be backtracked.

It's not really clear to me what you are trying to protect yourself from. Dual-human authentication for root won't protect you from accidental or malicious data disclosure to 3rd parties. Dual-human authentication may protect you against accidental or malicious data destruction, but so does backup and replication, both of which are a lot easier and less complex to implement.

I still think that this two-part authentication provides you with a false sense of security because just knowing who-dun-it doesn't prevent 'it' from actually happening.

 

[lordsegan]

While what you are saying is true when it comes to what root can do I do have a hard time with the premise of "we cannot trust a single human". The data didn't magically appear on your system, one particular individual put it there by either transferring it from somewhere else or by creating it. In boot cases 'root' isn't your only single source of contact.

With data this sensitive there's going to be data versioning, replication to an off-system or off-site location, any number of ways additional people will come in contact with the data and any number of additional ways that issues that creep up can be backtracked.

It's not really clear to me what you are trying to protect yourself from. Dual-human authentication for root won't protect you from accidental or malicious data disclosure to 3rd parties. Dual-human authentication may protect you against accidental or malicious data destruction, but so does backup and replication, both of which are a lot easier and less complex to implement.

I still think that this two-part authentication provides you with a false sense of security because just knowing who-dun-it doesn't prevent 'it' from actually happening.

You raise valid points. We have two types of data in the same data center(s). Type 1 is a disaster if it is lost, but not so terrible if it is copied. Type 2 is a disaster if it is lost OR if it copied.

Both types of data were aggregated over approximately 100 years, representing millions of man hours of total effort. This will be the first time either data type is stored in "one" place. It was previously stored around the world in various formats.

I think our clients are interested in preventing data destruction and punishing anyone who copies data.

 

[Dogs]

I think our clients are interested in preventing data destruction

Frequent backups to cold-storage (like tapes) will prevent total loss, since they wouldn't be able to just 'truncate' or delete that. Redundant hot storage is also a good thing. If it's a database, put an SQL trigger on deletes that fires some sort of notification to an appropriate team (individuals who should be aware if an approved delete is expected or not)...if a rogue delete does happen, you'll know right away and chances are you can still recover most of it from the disk.

and punishing anyone who copies data.

You should be able to set up a security group that has permission to deal with the data but not permission to delete the logs or otherwise cover their tracks. If not, send the logs to another box that they can append data to, but not remove data from. There's plenty of practical solutions to prevent deletions and detect copies that don't involve complex multi-factor or multi-user authentication systems.

Even if you still plan on using 'multi-user' authentication (like if the client or your superior insists), you need to be aware that this won't solve any problems...it will only server to add some extra layer of protection that makes it inconvenient to do harm. There are other things, like making sure the data is properly made redundant and making sure events are properly logged, which are far more important.


You have to keep in mind that there's no amount of security that will make this data completely impervious to harm or theft. Obviously you don't have this data sitting around for no reason. There has to be someone or some thing consuming it. If there's an ETL app taking data out or putting data in, that's a possible failure point...if someone can compromise that, they can do malicious things to the data. If you have ops-analytics doing reporting on the data (maybe through SAP, maybe through direct queries), that's a possible failure point. If you've got Hadoop digging through the data, that's a possible point of failure. There's any number of ways things can go wrong, and it's impossible to prevent all of them effectively while still allowing the business users to actually use the data. Your best shot is to minimize possible harm and make it so anybody with bad intent feels certain they will be caught...let the consequences of trying and failing be large enough to deter would be rogue-wrongdoers. If you follow a lot of the best practices, the act of looking for vulnerabilities will likely be easy to detect.