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.

Solution 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.

Solution 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

Comments

[Admin]

What is it about your source code that you're actually trying to protect, and what makes that protection valuable to your customers? Are there proprietary algorithms that give your customers a competitive advantage? People can get that looking at binaries as well. Are they worried about security vulnerabilities? Crackers don't even need to see binaries to poke holes! You'd do better here to have high development standards and regular external audits.

[Admin]

We don't think that having closed source protects us against crackers figuring out what our binaries do. However, having the source thoroughly locked away does make it simpler to explain "here's why we don't believe anyone has tampered with this since we wrote the code, built it, and signed the binary". Then there's the whole "protecting intellectual property" angle (with the property being more than just the algorithms)... but I'm wary of commenting too much for fear of mis-representing some part of my company's position/rationale.

[Admin]

It sounds like they key thing to your organization is being able to vouch for the integrity of the code that you deliver to your customers. You have at least one part of that down, in that you sign your binaries. The general security measures you describe can help support a claim of integrity, but there's more that can be done to address this concern directly. I've started addressing this more directly over at StackOverflow: stackoverflow.com/questions/3974075

[3dinfluence]

If you have any questions about how this stuff works contact Fortigate they will host a demo session with one of their expert system engineers who should be able to walk you through all their technologies and how they could apply to your situation.

[Admin]

That's interesting, we hadn't really talked about using DLP or device control as part of our security policy. Thanks for the Fortigate suggestion: I'll look at their stuff, although I think at this point we're more concerned with figuring out the broad strategy than choosing tools to implement the strategy.

[Franchu]

That's basically what we do today. We're frustrated with the status quo, however, because of all the friction it creates -- for example, if QA runs into a problem outside of the development network, we can't attach with a remote debugger from within the development network.