Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
A newly joined software engineer in our organization uploaded one of company's proprietary git repository on his personal Github public account, likely without nefarious intent.
How do I ensure this won't happen again in future? Apart from formal code of conducts, signing NDA etc. Are there any technical measures that can help (like firewalls etc)?
If a user attempts to push code to one of their repositories, thinking it's theirs (and not the company's), then any error saying the push request failed will likely cause them to try and "fix the issue" and not realize they are being protected from a mistake.
Discuss the incident with the programmer in question and ask them how it came to the circumstance. Keep in mind that the newly hired guy will likely feel extremely nervous, because joining and already causing a security incident doesn't make a good look. So make sure to make it known that it's not them getting investigated, it's the incident that is being investigated.
Then identify what factors lead to this incident. Is the onboarding process broken? There have been several incidents where newly hired developers attempted to bootstrap their dev environment and ran the setup script on the prod server instead of their local machine, wiping it completely. Or does the company workflow include personally-owned GitHub repositories? Is it perhaps "lived workflow" that employees want to work on their projects at home, so they clone them to private(?) GitHub repositories to bring their work home?
Next, develop mitigation strategies for these factors. If people feel like they have to circumvent company security controls to "get their work done", then you need to re-work your security controls. If the onboarding process makes sense only to the person who developed it, but not to new hires, then rework that process to prevent future mistakes.
Furthermore, while the technical mitigations mentioned in Todd A. Jacobs' answer are worth implementing, I believe they should be seen as a secondary measure and not as something to be relied upon.
Address the issue within your current incident response process. Then do a post-mortem to see if there were any additional controls that may have been applicable and could be implemented in the future.
Additionally, since the original question was edited—the original post posited an intentional breach by an active internal threat actor—it's worth noting that:
but neither is operationally effective as an automatable detective or preventative control. While tools can't substitute for human judgment, human beings are often the weakest link in continuous operational enforcement. That is why continuously-operating automated controls to enforce policies and standards are often more effective in addressing this kind of accidental exfiltration issue than policies, non-disclosure agreements, or routine awareness training.
This isn't really "data leakage" as the original post (before it was edited) expressed it. This is really more within the domain of applying appropriate controls to your source code management system, as well as endpoint protection and data loss prevention (DLP) on your company-owned equipment.
If you're allowing people to use their own equipment, then you may have to apply other compensating controls, but the bottom line is that while you can limit accidental exposure you can never completely eliminate the risk of deliberate exposure from an active threat actor. That's just the reality of the information security domain.
Per GitHub's page on inherited fork permissions:
Private forks inherit the permissions structure of the upstream or parent repository. This helps owners of private repositories maintain control over their code. For example, if the upstream repository is private and gives read/write access to a team, then the same team will have read/write access to any forks of the private upstream repository. Only team permissions (not individual permissions) are inherited by private forks.
There is also a page dedicated to explaining how to manage the forking policy for private repositories hosted by an organization or for specific repositories.
If you haven't set any controls on your organization's repositories, or your repositories are public, then focus on implementing those controls. If you have already implemented those controls, then you need to re-evaluate your threat model and design operationally-effective controls that address your real workflow. You may even need to change your workflows if adequate controls can't be applied.
Just remember that no individual control or set of controls is 100% guaranteed. You are mitigating risk by applying appropriate controls. There's no such thing as perfect security, especially when faced with deliberate insider threats or a failure to apply basic controls in the first place.
While not really a preventative control, you might also consider applying detective controls such as scanning publicly-accessible code repositories on sites like GitHub or GitLab for specific SHAs, either directly or via a search engine. That won't prevent people from making a private repository public, but it can at least provide some insight into whether a specific commit, blob, or tree is publicly available.
For example, given a recent commit on the Ruby 3.1 branch, you might search for the short or long SHA of the commit like so:
Finding a good search on search engines (which may treat SHA hashes as stopwords or otherwise choose not to index them) is harder, but one supposes it would be possible if you invest the time. However, even within Git web-based user interfaces there are lots of caveats to this type of approach, including (but not limited to):
However, this may be useful within an organization's self-hosted repositories, or within common public repositories using their own search features. You may find other ways to perform OSINT as well, but avoid tinfoil hat territory. Your best bet is still to apply basic controls and data-loss prevention techniques, and then address policy violations in accordance with your organization's incident response process.
Depending on the size of the organization, you can do things like purchase a Cloud Proxy solution. ZScaler, McAfee and there are others. Various cloud proxies often install an agent on the desktop that redirects web requests out through a cloud from individual machines. Once those requests go out through the cloud you can enforce policies as to whether the user can browse too... and block things. So one of the things you could deny access to is public or private github instances. That's one solution there are others.
