What are best practices for securing source code on a development network?

Question

At my company we are very protective of our source code. We have satisfied our paranoia by setting up a development LAN that we air-gap off from the Internet and the rest of our company networks. Within the development network, we have a few secured machines (the source control server, the build server, the domain controller), and all source is required to be kept either encrypted or in a locked room. Being able to explain such a simple security policy to our customers has been a competitive advantage for us, but as our company grows the costs of maintaining this network have also become greater. To deal with the pain over the last year, we have stepped away from our strict air-gap policy by allowing two-factor-authenticated RDP-only VPN access to the network.

However, the lack of connectivity between our development network and the rest of our corporate network continues to be a serious impediment to cooperation between teams that work inside the network and teams that work outside the network. We’d like to consider dramatic reform of our network architecture, but we’re not sure what industry best practices are for securing source code. What we might consider would be:

• Connect our development network to the rest of our corporate network, and allow unrestricted communication between any two hosts on this network. Also allow relatively unrestricted outbound connections to the Internet.
• Allow full VPN access to the corporate network for remote employees.
• Carve out a separate “test sandbox” network that wouldn’t hold source code, wouldn’t be patched, and would only allow inbound connections from the rest of the corporate network.
• Require that development machines be managed with the assumption of hostile network traffic: require up-to-date patch levels, don’t allow unauthenticated remote debugging, set strong passwords, etc.
• Continue to require that all code at rest either stay in a locked room (for old platforms that don’t have a satisfactory encryption solution) or be encrypted
• Continue to require that all developers with access to the code sign appropriate documents stating that they will not remove any code from the network

Would this be considered a satisfactory security policy at major software development organizations you have worked for? What other practices do software development organizations follow to protect their source? For example, are intrusion detection systems a common part of source security?

The "how do we secure our source code?" question is closely related to ours, but we are more concerned about the network architecture than the employee policy or the backup strategy.

Answer 1

Company policy is often more effective than a technology solution for some of these things. That's not to say that technology can't play a role in helping enforce the policies.

I suggest that you look into a Fortigate from Fortinet. They have a few things that you can leverage to help you. They have the ability to quarantine any computers that don't meet your policies, aka patch levels, A/V, etc. It also has the ability to do both application protection and data leak prevention. So you would just need to setup a data leak prevention rule to block anything that resembled code. So if your company has a standard header that is put at the top of the files you could look for that and block and report it. If you add the FortiClients to the mix you can lock down the USB ports on the local machine as well as enforce firewall, A/V, data leak prevention, and Intrusion Prevention policies at each client.

So to talk to your points.

• The firewall with VLANS should be able to take care of your first point.
• Fortigate's also act as a VPN so that point is pretty simple as well.
• VLAN of some sort could be your Sandbox.
• ForitClient in combination with Group Policies and the Fortigate you should be able to control everything you need.
• This one is a bit tougher to deal with. But company policies that state that not following these policies will result in termination is the best approach. However the FortiClient can lock down the USB ports so as long as you lock down the network sufficiently this should give you the control you require.
• This last one is more of a policy thing as well.

Answer 2

Well, it's more of an answer about design philosophy than actual architecture, but you seem to have a decent idea of what you want to accomplish. I find it's best practice to not only have a written policy, but to design the system to make violating the policy difficult (if not impossible). For example, if only certain machines are allowed to connect directly to a critical server, then surround the critical server with ACLs or a server-local firewall to only allow connections from those machines.

Regarding your bullet points:

• I advise against allowing unrestricted internet access. At a minimum, use a firewall enforced proxy requirement or WCCP. Default deny with a whitelist is best.
• VPNs are great if you truly want to allow (or want to manage) unfettered access from the outside of your network; if you really only want to allow specific types of connections, then I consider VPN overkill and unnecessarily hazardous
• I'm a fan of sandboxes for developers to play in, ours connects to a separate internet access and is on the other side of a production level firewall from the rest of the network
• patching and secure passwords should be a minimum in any and all environments...period
• encryption is fine, but you will need to manage the encryption method with an eye towards failure; i.e., what happens when you absolutely have to get access to the code but the guy who has the passwords is on vacation? If you need suggestions here, let me know and I'll add how I manage this...it's kinda convoluted, but effective.
• you might be interested in a NAC type solution for the last point as a method of forcing authentication and allowing you to audit who copies what where. You can also do things like disallow USB devices, which are proving to be a real danger to private data

Answer 3

I am a bit confused. You already have VPN connectivity into the secured network, which suggests the following

1. Obtain two sets of computers for the people who require access to both networks. Not necessarily on the same desk.
2. Require VPN connections into the secure network, for any development type work.

The source code and all development work can continue on the secured network, and be performed through RDP, while the terminals are on the external network, and can run other tools in parallel.