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

Securitysource

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.

Best Answer

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.

Related Solutions

Security – Corporate Wireless policies

Our corporate laptops are restricted to only allow internet access through our proxy (connection profile in Internet Explorer pushed through a GPO).

Pushing settings to a connection profile in IE, you don't only allow internet access through your proxy. You just make a notion about internet access through your proxy, and increase accessibility.

If I understand correctly what you want is to have users connect to your VPN in order to access the internet thus using your proxy. If that's the case you have to be carefull because now all potential malware/attacks get routed through your network.

By default in most Windows after XP when you connect to a VPN you are using the default gateway on the remote network. Thus you have to ensure that this setting stays like this. You can accomplish that through your GP or CMAK or by a script or by even doing it manually as a leveraged user once for every machine.

But on web-based logins your users have to access some random website (and thus the internet) ! This is where the Network Location Awareness kicks in

The Group Policy client will apply policy settings whenever domain controller availability returns. Examples of connection events that trigger Group Policy processing include establishing VPN sessions, recovering from hibernation or standby, and the docking of a laptop. This benefit can potentially increase the level of security on the workstation by more quickly applying Group Policy changes.

So if your user establishes a connection to a network other than your work network you will trigger your VPN connection and all is good.

I have to admit not an easy job especially when there is client diversification.

The other way of going around it is locking everything down disabling the lot of it and making another user account for usage outside your VPN and forcing other kinds of limitations (e.g. no videos,audio,specific domains,etc.)

Yet another way is to block certain ports from a specific connection or limit the access to your VPN e.g. no access to internal servers

Ssh – What are best practices for managing SSH keys in a team

At my company we use LDAP to have a consistent set of accounts across all of the machines and then use a configuration management tool (in our case currently cfengine) to distribute authorized_keys files for each user across all of the servers. The key files themselves are kept (along with other system configuration information) in a git repository so we can see when keys come and go. cfengine also distributes a sudoers file that controls who has access to run what as root on each host, using the users and groups from the LDAP directory.

Password authentication is completely disabled on our production servers, so SSH key auth is mandatory. Policy encourages using a separate key for each laptop/desktop/whatever and using a passphrase on all keys to reduce the impact of a lost/stolen laptop.

We also have a bastion host that is used to access hosts on the production network, allowing us to have very restrictive firewall rules around that network. Most engineers have some special SSH config to make this transparent:

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

Adding a new key or removing an old one requires a bit of ceremony in this setup. I'd argue that for adding a new key it's desirable for it to be an operation that leaves an audit trail and is visible to everyone. However, due to the overhead involved I think people sometimes neglect to remove an old key when it is no longer needed and we have no real way to track that except to clean up when an employee leaves the company. It also creates some additional friction when on-boarding a new engineer, since they need to generate a new key and have it pushed out to all hosts before they can be completely productive.

However the biggest benefit is having a separate username for each user, which makes it easy to do more granular access control when we need it and gives each user an identity that shows up in audit logs, which can be really useful when trying to track a production issue back to a sysadmin action.

It is bothersome under this setup to have automated systems that take action against production hosts, since their "well-known" SSH keys can serve as an alternative access path. So far we've just made the user accounts for these automated systems have only the minimal access they need to do their jobs and accepted that a malicious user (who must already be an engineer with production access) could also do those same actions semi-anonymously using the application's key.

Best Answer

Related Solutions

Security – Corporate Wireless policies

Ssh – What are best practices for managing SSH keys in a team

Related Topic