32

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!

94

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.

  • 28
    Big tech companies rarely limit developer's access to code. Google for example gives all developers access to all code even allowing developers to work on parts of the company that the developer is not involved in in their spare time. But they restrict access to live customer data. The main way big companies solve this issue is with an NDA – slebetman Jan 27 at 23:37
  • 16
    .. Microsoft for example would even allow other companies/agencies to download the Windows source code protected mainly by an NDA and their team of lawyers - microsoft.com/en-us/sharedsource – slebetman Jan 27 at 23:43
  • 12
    in fact, not having the original repo but remembering how they wrote it... can surely get people to just REWRITE the code far better than the original repo, because they can throw out cruft that they did not have the authority to throw out during their employment. those are the kinds of situations where open-source solutions severely surpass their commercial predecessors. – Rob Jan 28 at 1:47
  • 5
    Limiting access is a valid approach to reducing leakage of code, but it needs to be balanced against reduced production of new and better code. There ain't no graceful way. – Ross Millikan Jan 28 at 5:15
  • 4
    Nice balanced answer on an abstract enough level imho; one possible addition as a warning might be that all technical security measures have an associated likelihood to disgruntle workers and increase the likelihood that they actually want to leak something. So you need to make sure they are onboard and understand the need for security and it's not just you trying to annoy them with useless restrictions. I'd argue especially developers and other "smart" professions that know "you cannot (absolutely) prevent stuff" with these measures are prone to that, because of that binary attitude. – Frank Hopkins Jan 28 at 9:04
37

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.

20

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.
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Lilienthal Jan 28 at 12:21
  • I believe that one should check whether it's legal under their particular jurisdiction to force employees to use specific root certificate. – shabunc Jan 28 at 12:30
  • 1
    Fellow infosec professional here. Excellent answer covering the many technologies available for DLP. I think this answer can be strengthened though by including the need for timely MONITORING of log files and setting up alerts when potentially anomalous data movement is detected. Do you mind editing? +1 from me – Anthony Jan 29 at 0:28
  • @Anthony Edited and credited. That's a great addition :) – 520 says Reinstate Monica Jan 29 at 11:38
11

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.

  • 1
    This. Other answers give good tips on preventing or detecting, but number one is making sure your employees know what is and isn't acceptable and are on-board with/agree to policy. Number one is having, and communicating/getting agreement to, policy. – mattumotu Jan 28 at 9:23
  • 2
    This, in flashing capitals. When i worked at a hospital my lead took me for coffee and stressed that we deal with sensitive data that belongs to actual people (patients). It's not that you just want to prevent employees from leaking, you want them to actively think about possible leaks and how to prevent them. – Ivana Jan 28 at 10:22
1

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.

0

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.

-1

Common practices adopted in the software industry (especially big firms):

  • Install CCTV on each and every computer screen. Watch very closely whenever your developer comes to the computer. Record them. Monitor them continuously.
  • During a busy schedule, order in-premise accommodation for developers, so they don't have to go home. Disable network access and all physical access. Work, go back to sleep, wake up in the same building and keep working.
  • Hire more developers. Split the tasks so that nobody knows what exactly they are doing. Assign some of them fake tasks (Apple does that a lot).
  • Developer can only do programming while a project manager sits beside. Known as "pair programming".
  • Promote a few talented developers into senior position, such as "principal software developer" or "technical manager". Pay them lot of money. Well over the market average. Make sure they have everything to lose if they commit a crime. Only assign the core tasks to them. The rest of the team will be given unimportant tasks like sorting an array.
  • Don't allow any electronic device into the building. Scan everybody coming in and out.
  • All developers must change to standard uniform, like a jail. There won't be any space in the clothing to keep devices. Common in high security and military applications.
  • Companies like Apple and Google do frequently. Create a new independent company, but secretly owned by your company. Don't let anybody know the new company develops a software solution for your company. Make it totally absolutely independent. A new company name, a new management team, a new team. A new office location. All your software developers will technically employed by the new company, not your original one. When the software is ready, you "buy" the software from the new company. Super common tactic. If the project doesn't work, you'd fire everybody in the name of the new company. Much harder to leak when you're the one person who knows what the new company is doing. Everybody else will just think it's another small startup.

Not the answer you're looking for? Browse other questions tagged or ask your own question.