Ensuring employees don't leak code or data [closed]

Question

How do you make sure that your private code repository/data files aren't leaked by your employees?

On their work device, they would need to simultaneously have sensitive code/data, along with internet access to be productive (ability to send emails/arbitrary POST requests). None of the solutions that occur to me are convincing:

• Disable data access ports (USBs, Optical Drives etc.). This gets complicated with USB-c charging ports, can't really disable them
• Network Monitoring Could be done with a VPN with request logs retained. Still wouldn't help with for eg. gmail, where everything is https encrypted
• Screen recording Overkill? How would one even analyze this
• WebSite blacklists/whitelists Seems quite difficult to get right

Since a number of firms would be strongly interested in protecting sensitive materials (Google etc.), I'm wondering if there are standard controls out there that I'm just not aware of.

Any pointers appreciated!

Answer 1

You cannot

Simply put, if you have people working on a product, you have no way to guarantee that they will not leak what they are working on.

Even if you fully restrict their ability to copy the data directly, they still have brains that are perfectly capable of memorizing confidential information and reproducing it various ways (including just shouting on an online forum; "Hey, did you know my company X are making product Y with features Z!")

---

What you can do, is reduce the chance of it happening, and mitigate the risks involved when it does happen.

Some things to consider:

• Limit the spread of information. New products should only be known by those directly involved, and even then - only the part of it that those employees need to know of. Discourage gossiping and reduce the internal spread of confidential information.

• Limit access to code and product. Within the actual project, not every developer should be able to see everything on every product. Access should be granted on a case-by-case basis, and revoked when not needed anymore. Again, the more somebody knows - the more they can leak.

  • Note, this in particular risks decreasing productivity. Many major companies even go the other direction and simply rely on their NDA and legal team - while providing full access to anybody that works with them. Do not make a decision on this in haste. It is a practice that does exist in some companies though.

• Build a culture of IP security. Train people to understand their role in keeping the data secure, and how it affects them and their colleagues jobs directly to have a leak of any kind.

• Improve employee morale. Far easier said than done, but people with "something to lose" are simply less likely to leak information. The worse the morale, the more chance of somebody becoming bitter and deciding to take the company out with them.

  • Conversely on this, be wary of anything you are doing that may decrease morale, such as adding too many anti-leak measures that your team see as bureaucratic. Adding frustrations to a developer's day will not only decrease their productivity, but does also increase the risk of them being discontented and leaking materials. Again, please always consider the actual damage of a leak, against the damage your anti-leak measures may cause to the team themselves.

• Implement technical solutions to ensure any leak can be traced back. This is explained better in detail in other answers. The goal is not just to make it harder to leak - but to make sure everybody knows that if they leak, they will be caught.

• Prepare a mitigation strategy. Be prepared that if data does leak, or more accurately - when data leaks - that you know what impact to expect and have a plan to mitigate it. Perhaps it's a product being announced days ahead of your big PR event - as a business, you need to determine what steps you can take to reduce damage in the case this information does leak; before it leaks.

No company that employs homo-sapiens has a foolproof way to prevent data leaking. Regardless of the technical solution; a determined employee will always be able to leak something you wish they couldn't. All you can do is focus on reducing the frequency of leaks, the scope of information in a leak, and preparing to mitigate the damage when it does happen.

Answer 2

Essentially you prevent this the same way the police prevents you from randomly knife stabbing strangers. They don't. There is just a law that makes it illegal and the police ensures that you are aware of the law and then you get caught and punished if you break it.

The same approach applies here. You write in the work contracts that employees are not allowed to leak code. Some version of this in proper legal speak is usually included in almost any work contract. You make sure that if an employee were to leak code, you would find out. 520s excellent answer provides a lot of detail how. If it happens anyway you have proof and the breach of contract gives you a way to punish the employee.

Answer 3

Security professional here. With regards to your points here, let me make a few suggestions:

• Disable data access ports - Set a group policy disabling writing to USB drives. Encrypt your hard drive via BitLocker and TPM, and BIOS-lock your systems so that LiveCDs aren't a concern and theft by hard drive removal can't score results by your average Joe.

• Network Monitoring - HTTPS monitoring is a thing. If you install a root certificate on these machines, you can inspect the traffic, repackage it, send it back and the receiving computer suffers no issues.

• Screen Recording - Definitely overkill and counter-productive. Do not do this. It's invasive as hell (meaning you are likely to make people resign), could hoover up data that is illegal for you to hold, is easily noticeable and, as you noted, isn't going to be easy to go through.

• WebSite blacklists/whitelists - Use a third party proxy provider. This will be nigh-on impossible for you to get right by yourself.

You should also implement:

• Training - Your average attacker is most likely to go after low-hanging fruit. That means unless you have Wannacry-susceptible machines on the internet, they'll go after you and your workers directly with legitimate-looking emails or other tactics.

• Email Monitoring - The possibilities for outbound communication are obvious, but you should also be careful of what you allow in-bound too. Executables delivered in this way are a good way to get remote access to a machine (and therefore pull data on/off it).

• Software Restriction Policy - This makes it much more difficult to run unapproved code. The implications of being able to run code made by any Tom, Dick and Harry should be obvious but if not, see my final point under email monitoring. This ensures that your employees cant run random code from any source.

• Logs - These should give you every bit of data that you were hoping to get from screen recording. Except it is searchable. And transparent. And not a drain on system resource. And won't hoover up details you shouldn't have. And won't make your employees leave en masse. You get my point, make sure you have a decent logging policy going for everything you want to protect.

  One thing I should point out (courtesy of Anthony in the comments below) - logs aren't useful if no-one is looking at them. Sure, you might be able to look at them after an incident, but that's only after you've been screwed over hard, and assumes you either have access to the data on the laptop or have been collecting logs remotely. Many organisations use a SIEM solution like Splunk or Alienvault to remotely gather logs and go through them to look for potential bad behaviour. In my experience, SIEM products need tweaking and a lot of setup work to get started, but once you're up and running, then maintenence should be fairly minimal

• Access Control (courtesy of Arthur Havlicek) - Chances are your systems and networks have the ability to dictate who can and can't access certain things. Use it. When setting these, use the rule of minimum requirements (aka: only set the minimum amount of permissions as needed for the job your employee/machine is going to do). Only have that access active for as long as you need them; if you let someone go or someone leaves, disable their accounts on the same day.

And on that note...

• Dev stuff should not touch production stuff - The dev environment should be a safe space where your developers can test out new features and ideas without risking your actual site going down. Treat it like a quarantine zone. The only time anything crosses over from 'Dev' into 'Production', is when it has been tested and you have deemed it safe to do so. Dev frontends must never touch production backends and vice versa. Bugs can and do happen in development environments and security bugs are no exception.

Answer 4

Ensuring employees don't leak code or data

Employee awareness is the only tool you can effectively make use to fight the accidental / sloppy behavior.

Make your employees aware of their roles and responsibilities. Provide proper training and guidance so that they knows what not to do, what could be the impact. Finally have them signed an NDA regarding the codebase, product and company business info.

Anything else that you try to do (from the list you suggested) would most likely annoy the people, as they tend to reduce the productivity and usability. Security (or whatever miniature part of it) comes at a cost of productivity and usability - is not sustainable anyways.

Answer 5

Although other answers are valid, I think that your software design could be improved to avoid implementing the rest of the suggestions. Example, by simply moving the sensitive code into its own library/repository, where other developers could use it without seeing its code, then you are done.

Unfortunately, each developer's work can not be controlled not to be leaked. At the end of the day, they wrote the code means they can write it again anywhere anytime.

Answer 6

As others have said, you cannot.

However,...

Sometimes you don't want to stop leaks

You want your developers to be able to perform to the best of their ability. This sometimes involves needing to look up things online, and in rare cases people might need to ask for help online. And in such cases, it tends to be tricky to ask for help without sharing code snippets.

For example, this very site has at least 3 major parts where people ask for help with their code: the main Stack Overflow site, Code Review and Software engineering. And even disregarding those sites, some specialized sites like Latex, Game Development, Server Fault, Database Administrators and most of the sites aimed at support for a single product also somewhat frequently see code snippets.

Beyond that, people might be able to share their own code snippets to solve problems for other users, giving back to the community. And if you're in any way using open source products and extending them yourself, you may even want to put in a pull request in order to push your changes upstream, helping the greater Open Source community at large.

Note that the above examples are all cases that are technically leaks, but in every case, it should only be done with the explicit permission of the business. And in such a case, it's not really a leak. I just want to point out that not every leak is negative. Sure, you don't want your secret ranking algorithm leaked, and you don't want credentials to external platforms leaked. But sometimes, there are tiny things like a list sorting algorithm that doesn't work in just the right way, or a bugfix for an important library that you developed internally. Things that won't destroy your business when exposed externally or may even have a positive impact on your public appearance when shared.