How to protect my code from “insider” threats when hiring my first employee?

Question

I quit my job to start my own SaaS product. I’m now looking to hire my first employee (another developer).

I will be taking appropriate legal precautions to protect my IP, but I’m wondering what other reasonable actions that I can take to further protect my code / data. The last thing that I want happen is what happened to Tesla where someone dumped the source code onto iCloud and ran off with it to a competitor.

I know that it is practically impossible to prevent this 100% from happening and that I need to make sure that I hire quality people and offer meaningful pay and have the appropriate legal documents signed. Apart from this, what else can I do to protect myself from inside threats? I am pouring in my entire life’s savings into this and I will be devastated to lose what I spent the better part of 2 years coding.

Here’s what I’ve thought of so far:

• Buy a work laptop for them
• Encrypt the hard drive (like with Bitlocker)
• Disable all USB ports
• Create a non-admin / limited user account with no install permissions and just the IDEs (e.g. Visual Studio) installed. I use Windows 10 for most development with the exception of a Mac for the iOS portion of the app development.
• Install some kind of employee logging software.
• Disable access to file hosting websites.
• Somehow detect and stop when a certain folder is being uploaded or copied somewhere?
• Somehow make the git repository only accessible from that machine.
• Install some kind of remote admin management system? Azure Active Directory or something?

This must be a common problem for businesses but I must be searching for the wrong thing because I can’t seem to find a guide anywhere on this issue.

Answer 1

For the most part this is not a technical problem but a human problem. So while technology has a role to play it has limits.

If the employee will be working from home supervision is more difficult. If you'll be monitoring his/her activity you don't want to be in breach of applicable privacy laws.

The computer has to be secured obviously but the rest of the environment is important too. If you have a corporate LAN there should be adequate protections like an IDS/firewall. But the equipment is often useless without somebody keeping an eye on the logs and the alerts.

Since you mentioned Visual Studio, the developer may need to be at least a local admin to work in optimal conditions. If you cripple their environment they may be tempted and even forced to find workarounds and defeat your security measures which is what you want to avoid.

I'm afraid we all have to trust other people and take risks. The more you monitor your employees, the more you make it obvious to them that you don't trust them and make them feel untrustworthy. At some point the surveillance effort becomes counter-productive because you frustrate and demotivate them. They may become less productive, less loyal.

Security training may be beneficial too. The employee could be honest and acting in good faith but vulnerable to social engineering, and unwittingly jeopardize the company and its assets. Naïveté can be as dangerous as malicious intent. I would say that many developers lack cybersecurity awareness.

Perhaps you should order a penetration test against your company and learn from it. Thus your security posture will improve and you'll be better equipped to fend off attacks.

Employees are often the weakest link but you should also consider the threat of hackers and unethical competitors. In other words don't focus too much on your employees, but develop a 360° security approach for your company.

Physical security is important too. A lost laptop should be no big deal if the hard drive is encrypted and has a strong password. But your backups should be in a safe place. Consider the risk of burglary.

Yes backups are extremely important. Make sure you have a solid backup plan in place, test it from time. Prepare a disaster recovery plan. What would happen if your office burns with all your computer equipment ? You need to protect your source code but also plan for business continuity. Hint: insurance.

If you have valuable IP you could consider applying for patents. Again, this is a lawyer's job here.

Probably you can find insurance to cover the risk. The question is whether it's worth paying for a low risk.

I would also offer shares or some equity in the company. Then your employees have less incentive to go rogue and sabotage your enterprise.

To sum up: there are so many possible risks, I think you are putting too much emphasis on the insider threat. You are more likely to get hacked, than sack someone for misconduct. Your employees must be your allies and considered as such - not as potential foes.

Answer 2

Don't do this:

Create a non-admin / limited user account with no install permissions and just the IDEs (e.g. Visual Studio) installed.

Disable access to file hosting websites.

Install some kind of remote admin management system? Azure Active Directory or something?

A lot of developers, myself included, are not going to work for you on this machine unless you're willing to really make it worth their while. It will offer little security, but will be incredibly frustrating to work on.

Here's a simple rule of thumb:

A malignant developer will be able to hack their way into to anything (data, source code, network) used by the product they are working on. They will also hack the laptop you gave them. Thus, protecting and securing your IP in this context is not a technical matter, it is an organisational matter.

I need to make sure that I hire quality people and offer meaningful pay and have the appropriate legal documents signed.

This is your answer.

Answer 3

The last thing that I want happen is what happened to Tesla where someone dumped the source code onto iCloud and ran off with it to a competitor.

And after that Tesla failed and were never heard of again? Or Valve after the Half-Life leak?

Or, in reality, mere source code isn't all that valuable. It's generally a pain to integrate with other projects, so unless someone's going to clone the business entirely (which is very obvious and can be dealt with by legal action), having a copy of your source is much less helpful than you think.

The important thing to secure is credentials and customer data. Secure the live servers, access to them, and any AWS or similar accounts. Getting hacked on AWS is far more likely to destroy the business than a source code leak. Even accidentally failing to control costs on AWS could destroy you. Leaking customer data can expose you to GDPR liabilities.

Two-factor authentication is probably a sensible baseline. This can be integrated with Active Directory when you get that (I don't recommend it below 10 employees).

For especially sensitive systems, having segregated "test", "staging" and "production" areas where only you (or cleared employees) have access to "production", and only production has the real customer data, is a good idea.

Answer 4

First I'd suggest you to estimate the real value of the software that you are going to develop. Is it really the most valuable asset that you will have? What would it cost you if somebody obtains the source code?

Think of Facebook or Linkedin. They were not the first ones in their field. And their software was not the most valuable asset (yes, they developed and later on open sources Bootstrap, React, Kafka, Samza, to name a few).

After estimating the risks and the costs in case somebody get the code, estimate how much money you can invest into securing it.

Here are just a few points to consider:

1. One task would be to know what exactly is sent from computer to the internet. The most sites use HTTPS. You cannot decrypt it. One option might be to force all connections to use your VPN, to force install your CA certificates and tom implement man-in-the-middle. Another option might be using some spy software on the computer.
2. Another task would be to classify the data sent to the Internet. If some encryption or obfuscation is used, it can be very hard to prevent it.
3. Technical implementation may be very complicated. A developer, to perform its daily work, may need several messengers, several browsers, Email. You would need to control everything.
4. Even if you would have such tools, still it is possible to make pictures of the screen with the contents of the the most important classes, config files, etc.

Preventing leakage via Internet connection may be pretty expensive and only few companies can afford it.

Considering this, disabling USB does not help much. The main advantage of disabling USB may be preventing the laptop from being infected by malicious code via USB.

Encryption doesn't cost anything and make sense. If the developer is loyal and does not distribute your code, then encryption can help if case the laptop is stolen or lost.

Answer 5

I once had a job interview at a prop trading company that was worried about insider risks. The mitigations they used were:

• All work conducted on-premises
• No bags, phones or cameras allowed into the offices
• No e-mail
• Corporate network not connected to the internet
• No laptop computers, only thin clients
• All thin clients in locked cupboards, only screen keyboard and mouse accessible
• No local admin access
• Approved-software-only rule strictly enforced.
• Metal detector and guard at every entrance
• No out-of-hours working allowed

I didn't take the job because I thought I'd take a big productivity hit from all those restrictions. But they did manage to hire quite a few people, because they offered exceptionally high pay.

Answer 6

Let's break this down into 3 sections: Digital, Physical, and Human

Digital

I'd recommend giving them a company computer, whether they're working on- or off-site. This will allow you to restrict and monitor some of their activities. However, don't go so far as to install a keylogger. No one wants a keylogger on their system, even if it's a company PC. They'll need to use logins with passwords, which don't go well with keyloggers.

Most of your monitoring should be on the server-side. Monitor traffic from and to the server. Activities should be logged, whether or not they're an employee, if it tries to interact with your server. You can go as far as logging every single request (which is not that uncommon I believe), or just logging things that interact with the important parts of your system like direct access to the database.

Usual traffic may indicate malicious activities. For example, if you see 1GB of outbound data, you may wanna check it it's just your employee retrieving some data for work or someone trying to export your data. Seeing 500GB of data flow from/to a single IP should be an immediate red flag.

Any and all administrative work should be done from your internal network. This means they should have to be from inside to even see your admin portal. If you want to allow them to work remotely, I'd suggest you set up a VPN to allow your employee(s) to connect to your internal network remotely.

Physical

There are 2 main things you'll have to watch out for: access to the physical office and the work computer. I'll only discuss the company computer.

Well, actually, there's not much you can do when they have the physical computer in their hands. The best you can do would probably by to put seals on the computer, such that any attempt to open up the computer hardware would be visible to you or at least detected by a forensics professional.

This is law 3 of security:

If a bad guy has unrestricted physical access to your computer, it's not your computer anymore

Human

This is the main factor here. As mentioned by @Anonymous, this is mostly a human problem.

First of all, hire someone you can trust. We have penetrations testers trying to break into systems all the time on purpose. One of the main reasons they're allowed to do this is because they have little reason to do bad things to your system. In order to qualify, we have to be thoroughly vetted by the hiring company. Trust and interest are the main things keeping people with access to your system from intentionally doing damage.

Notice I said intentionally. Insider threats aren't always intentionally malicious. The TSA keys were leaked no because someone wanted to do harm, but because of blunders by internal and third parties. An untrained employee can easily wipe out your entire database by mistake with a single command. Untrained employees are often vulnerable to social engineering attacks and can let an outsider in when they shouldn't.

To avoid such problems, you have to train your employees on both in system administration and security. Training will help with little accidents, but only thorough vetting can keep malicious actors from becoming part of your company.

Now to address your suggested ideas

Buy a work laptop for them

Good idea

Encrypt the hard drive (like with Bitlocker)

This will protect data at rest. Great idea, but not gonna help much against an employee with access to the computer and the password(s).

Disable all USB ports

We use USB ports all the time. USB mouse, keyboards, webcams, etc. This will also be the main means of conveniently transporting data for most people. Instead of disabling them all, use software to prompt the user every time a USB device is plugged in. You'll also have to train your employee(s) not to plug some random USB they found on the street into the work computer. The most you can realistically do is train and whitelist their USB devices such that only registered devices can connect to the computer.

Create a non-admin / limited user account with no install permissions and just the IDEs (e.g. Visual Studio) installed. I use Windows 10 for most development with the exception of a Mac for the iOS portion of the app development.

Again, software preference is personal. This will be entirely your choice to restrict their work performance should you not allow them to use their preferred tools. Restricted non-administrative accounts is advisable, though you'll have to manage installing tools for them yourself.

Install some kind of employee logging software.

Most of this should be on the server-side rather than the employee's computer. Logging their local activities will make it easier to monitor them and sue them for malicious activities but be careful not to go too far. Children don't like their parents watching everything they do, and neither do your employees. Server-side logging shouldn't make them uncomfortable so it's a great way of monitoring.

Disable access to file-hosting websites.

This may be difficult to do, but I'm not sure how you can do this yourself.

Even if you can do it, they may need to access their personal drives for some work, but it's your choice to be restrictive.

Somehow detect and stop when a certain folder is being uploaded or copied somewhere?

Monitor traffic to and from your server. It's their choice to copy your files to a USB stick and upload it elsewhere. You can only monitor to detect unusual/suspicious traffic from/to your server.

Somehow make the git repository only accessible from that machine.

Use a VPN for this, as well as all your administrative portals.

Install some kind of remote admin management system? Azure Active Directory or something?

I mainly use Linux so I'm not well-versed on Windows, but Active Directory should be accessible only from the internal network. Again, use a VPN for remote access.

Answer 7

Your focus seems to be on protecting yourself from adversarial insiders, i.e., those who are consciously and deliberately trying to breach your security.

As others have pointed out, it's probably impractical to have significant protection against deliberate attacks via technical means. mjt's excellent answer gives a typical set of restrictions, but even these can't prevent people from taking information out in their heads. And as others have pointed out, these have a large negative impact on productivity. In particular entirely disallowing any Internet access from development machines is likely to be troublesome in this day and age. (You'd probably at least want to provide a second "air-gapped" machine connected to the Internet so that people can look up documentation and the like, though this now exposes you to someone reading code from the secure system and typing it in on the insecure system.)

However, when looking at internal technical security measures, what you do want to focus on is mitigating the risk of inadvertent security breaches. These are far more common than deliberate attacks and much more easily preventable.

The most important part of the approach for doing this, and the one that many companies get quite wrong, is to make it easy for the developers to securely do what they want to do. Often technically this isn't too difficult and most of the work is in support and training.

Important aspects of this approach are:

1. Be willing to take short-term productivity hits in order to do training and security fixes. For example, if you have a policy that developers' ssh keys must remain only on the system into which they log in, and the developer is having difficulty with ssh-agent, make sure you're clear in both your words and actions that getting her working smoothly and correctly with ssh-agent is a higher priority than getting feature X done.

2. When a developer says she wants to do X, work with her immediately to figure out the core thing he wants to achieve and a way to do that both securely and easily. You want the developer to go away happy that she has a good solution to this problem, rather than looking for work-arounds because she finds the solution you offered to be inconvenient or, worse yet, is being penalized for lower productivity when trying to work securely.

3. Ensure you're able to provide training and immediate support for doing work within your security policies. If a developer is having trouble getting file X to system Y while following your policies, you need to show her right then and there your easy and secure way to do this, rather than leaving her frustrated and looking for other ways to do it.

4. Follow your own security policies and fix problems pointed out by developers. If you have a policy that you should never be moving sensitive data over HTTP, and a developer points out that she tried using an internal system that they thought should be using HTTPS but wasn't, get that fixed immediately rather than telling her just to ignore the problem. If you do the latter, they'll learn that ignoring things that look wrong is the correct thing to do. If the company policies say otherwise, they'll learn that ignoring company policies is the correct thing to do in some circumstances.

In short, you need not only to set up security-conscious systems and policies, and tell developers about them, but also demonstrate that these are important to you by a) being willing to put in the work to make doing things securely easy, and b) prioritizing them over getting features done. If you do this well it won't slow you down in the long run, but if your actions don't match your words in this area, your security systems and policies will be a cost with little benefit.

Answer 8

Ok, let's play this through: I want to steal your code.

I plug in devices, nothing works. I then make some zip-files and mail it home. No, you blocked all mail webclients? Ok, so I go ftp / ssh/whatever. You blocked those too? So I upload it to a website. You blocked thousands of them? As a developer I own some domains anyways, so I just upload it to one of them. Those you can stop you don't want to hire.

Here is a solution: Give them access on a need to know basis. Only let every dev work on a part of your project, and no-one has the full code. Create multiple repositories, and parts that are high-value and little-change go into a restricted one. You can still share documentation for the API.

I don't know your field of work, but in most SaaS projects, the secret is not how you do something - that's mostly straight forward. What you want to protect is your advantage over competition, as they would need to put in the work you already have. So even if they know how your stuff works (or how they could make it work anyways), having them to develop instead of copy is all you need.

Answer 9

I am surprised I haven't seen the answer that most start ups use.

Give the employee equity. Make them a co owner, doesn't have to be 50-50 but give them an incentive to make the business succeed. Many start ups do this with equity or profit sharing etc.

Instead of trying to restrict them. I guarantee if you give your employee the promise of 10% profits (assuming this is significant) and gave them a open non restricted laptop that they will work really hard to make sure the business succeeds.

Source: I have worked at small start ups and large tech companies. I can guarantee you none of them restricted the laptops like you mentioned and the ones that did do not hire top tier engineering talent.

Answer 10

There are two possibilities here, you hire someone trustworthy or you hire someone untrustworthy. If you want someone trustworthy, the job needs to be attractive to someone trustworthy, and the work conditions of the job need to be such that you keep the trustworthy employee.

If you hire someone untrustworthy they are going to do whatever they want regardless of what steps you take. They will always be for sale to the highest bidder.

If you lock things down to make sure whoever you hire will be frustrated at every turn, you are making it hard for the trustworthy employee to do their job and at the same time sending the message you don't trust them. The trustworthy employee is likely to be less money oriented, and more about doing a quality job, but they will want a quality work environment. Lack of trust does not make a quality work environment, neither does having to code on a very locked down machine.

Abandon the technical solutions and focus on making the job conditions and work environment attractive to the trustworthy employee.

Answer 11

A bit of a mean answer but think about it this way. If they really want to steal your code they could just take photos of the screen. As such I would advise you to lock the screen brightness at 0% so that they can't see what they are working on.

... Or you might want to make sure that they don't have an incentive to steal from you, like taking care of your employees and treating them like a friend. Sooner or later when your business gets big enough you will need to trust a lot of people, like finances, IT department. Better get used to trusting people sooner, rather than later.

To add to this, if someone with sufficient knowledge wants to get your code they will. There is nearly no way of stopping that. What's way more likely to happen is an outsider attack via social engineering or a direct hack. Insider attacks are way too dangerous (in legal and financial terms) and time-consuming in most cases. If you are just starting out as a company your legal protection should stop such an attack. That's a different case is your a billion-dollar company, but you don't seem to be a billion-dollar company yet, so probably not the one thing you need to worry about most.