1

Are there any security mechanisms that can protect a company from malicious employees (think database administrators, sysadmins responsible for authentication etc) trying to steal the customer data?

To give an example: Suppose a company allows customers to upload valuable data to their site. Customers can then log in to the company's website and download/delete previously uploaded data. Are there any mechanisms that the company can use to prevent an employee from copying/deleting/stealing the customers data?

(I originally started thinking of this issue when I transferred my Bitcoins to an online exchange site. I don't intend for this question to be about bitcoin, because the bitcoin protocol is obviously not geared towards these type of threats, but it may be useful as a background context/example scenario. How could a bitcoin exchange company prevent employees from running away with customer assets?)

Improve this question
4
  • 1
    There are a number of things that an organization can do. This question in its current form is very broad however. I'm thinking that maybe we should make it a canonical question.
    – S.L. Barth is on codidact.com
    Commented Dec 2, 2016 at 11:11
  • 1
    I would love some help to reformulate it. As long as it settles my curiosity (and in best case increase my trust in such sites). I'll make it a community wiki to begin with. (edit: can't seem to make it a CW for some reason)
    – aioobe
    Commented Dec 2, 2016 at 11:20
  • it's all about segmented access; no CEO should have "superuser" perms.
    – dandavis
    Commented Dec 2, 2016 at 21:35
  • Yes, you can search for User and Entity Behavior Analysis (UEBA)
    – Houcine Amraoui
    Commented Jun 30, 2020 at 18:34

2 Answers 2

Reset to default
2

Are there any security mechanisms that can protect a company from malicious employees (think database administrators, sysadmins responsible for authentication etc) trying to steal the customer data?

Database admins, pretty much by definition, have administrative access to a database. So, technically, no, preventing that would only work if the data within the database was encrypted – and even that would still leave a lot of information that could still be pieced together (like: Oh, I see an entry for an order from anonymous customer nr. 14 ever monday at 1pm, and I know we have a phone call with customer "jack labs" every monday at 11am, soooo...).

The only thing preventing this kind of thing would be policy and monitoring. There would need to be a database access log that the database admin couldn't disable, and that would raise an alarm whenever a non-standard usage of the database happened – but in effect, that would mean you'd need a second database admin to just understand and monitor what the first one is doing.

What you have is the evil maid scenario. Bad luck.

your example is an especially easy one, however. Simply let the user's browser encrypt the file with the user's own key prior to uploading. Not much to be gained by stealing, then. Unless, of course, and that's kind of probable, the user uses actually helpful file names like "contract with jack labs.doc" or "employment offer for Troy McLure.pdf".

That's why you don't store confidential data "in the cloud" if you can't trust the cloud provider's employees (and also, the employees and governments of those running the servers of that cloud provider).

the bitcoin concept is exactly geared towards this. All transactions are logged, otherwise they didn't happen, and any wallet is cryptographically secured with a passphrase.

Improve this answer
1
  • Thanks. New to this and greatful for the "evail maid" search term. You can run bitcoins through a tumbler, then the transaction records are pretty much useless.
    – aioobe
    Commented Dec 2, 2016 at 11:23
1

To prevent unauthorized access to sensitive data by IT administrators, including database admins, one method I've seen in practice that works is data encryption. It can be achieved at the application logic layer or at the database level (e.g. using a technology such as Always Encrypted for MSSQL databases, although this still requires small changes to the application logic).

Of course, depending on how encryption implemented, an advanced and malicious privileged IT administrator could still be able to recover the private key, and then access your data, but this would require a more advanced level of motivation and attack sophistication and was considered as extremely unlikely by business and data owners.

You could also look at other security controls such as limiting access to very few trusted individuals, limiting access to privileged credentials, monitoring their actions in real-time, enforcing 4-eyes for sensitive actions/access etc.

As a second layer of security, you could also add capabilities of detecting unauthorized access to sensitive data, such as reviewing audit logs, data-loss prevention software etc.

Improve this answer
4
  • This is pretty much the type of answer I'm interested in. What complicates the question I have, is the fact that customers are able to log in and access their data 24/7 which means (if I understand correctly) rules out "4-eyes", right?
    – aioobe
    Commented Dec 2, 2016 at 12:25
  • I was referring to "4-eyes" for privileged IT activities (e.g. DB maintenance, support etc.), i.e. you need 2 IT admins to complete the action. The risk of collusion between these 2 individuals can be reduced by constantly changing the team members associated. The typical issue with 24/7 is that you then need to double your "on-duty" capability for support activities, which has a significant cost, and you need a technical solution for implementing 4-eyes with remote workers.
    – ack__
    Commented Dec 2, 2016 at 12:32
  • ok. I thought you ment 4-eyes as in all database access, which would be problematic when a customer must be able to log in at any time and look at his data. Limiting access to just a few individuals would be good of course, but kind of avoids the question. Same with privileged credentials. Monitoring usage is of course good, but downloading a few hundred private keys for instance can be done in a matter of seconds (after which the harm has already been done). Maybe it's just an problem that's impossible to solve?
    – aioobe
    Commented Dec 2, 2016 at 12:47
  • @aioobe Restricting access to few persons and protecting access to privileged accounts credentials do not avoid the question, these controls precisely address it, though this is true that they are not enough to reduce the risk to an acceptable level by themselves. For monitoring, I was more thinking of monitoring access to sensitive passwords (e.g. domain admin) and recording administrators' session. Data monitoring is typically achieved with DLP solutions that can actively block the data flow before it happens (hence protecting and not just detecting things).
    – ack__
    Commented Dec 2, 2016 at 15:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .