Philosophy: Never depend on security through obscurity. | ||
| --Michael Howard, author of Writing Secure Code | ||
If you are considering or have considered outsourcing your development, one of the first questions you will probably ask yourself is, “How will I secure our company’s intellectual property (IP) from potentially malicious offsite developers in the United States or abroad?” I answer those questions in the following pages, using Microsoft’s methods as an example.
Even if you don’t plan to outsource your development or have developers work offsite, unless you’re writing freeware or running a software development charity, this subject is important to your software business. It’s such a delicate subject that I was told that there are some secret security projects at work at Microsoft; furthermore, if the person I spoke to talked about the projects, it would be considered a breach of security and would be grounds for termination. I guess part of being secured is being a little paranoid.
Thus far, the chapters in this book have focused on the build process without regard to where your development work is done. What we have really been talking about up to this point is having the ability to track source changes to the owner and holding the owner of the code accountable for his/her work. Now, we look at how to secure that process.
Security is a broad subject, and I can’t cover everything in this brief chapter. Instead, I focus on the following topics:
Securing your source code from software pirates
Supporting multiple site developers and teams or outsourcing your development
Providing stability to your application
Improving your Software Configuration Management (SCM) process
Figure 9.1 shows the typical track that a piece of source code follows at Microsoft. If you configure your shipping process to what is outlined in this book, your source life cycle will look like this, too. The illustration looks more complicated than it really is. Reading from left to right, the source code can reside in four places: anywhere, source lab, build lab(s), and release lab. In some groups and companies, the three labs are in one location, but they don’t necessarily have to be. What is important is adequate security for each group.
The best way to provide adequate security is to take a multilevel approach:
Physical security—. Doors, locks, cameras, and so on.
Tracking source changes—. The build process.
Binary/release bits assurance—. The tools process.
IT infrastructure—. Company-wide policy and security.
Taking this four-pronged approach to security is what has evolved over the years at Microsoft. This might sound like a naïve statement, but in all the time I have spent working with developers and architects, I truly believe that their approach was (and still is to some extent) that they were working in a trusting environment. I also believe that a lot of companies I work with start with this position. Unfortunately, enough “bad apples” out there force Microsoft to take all of these security measures to protect its code. It’s never too early for a company to take the same approach.
Physical security should be the first line of defense in trying to protect your sources. Too many groups and companies take this for granted until they get burned by their lack of security.
In Chapter 4, “The Build Lab and Personnel,” I outlined how to set up a build lab. Now, I’d like to expand that setup to source and release labs (if they’re at different locations) and add the following elements:
Video cameras that are visible and hidden. Having cameras where people can see them is good because it deters possible thieves. It’s also good to hide some cameras. As the previous sidenote implies, you don’t know who you can really trust.
Limited card key access to the lab and machines, with the lab locked 24×7. Only build personnel need access to the lab all hours of the day and night. If you feel the need for other people to have access, limit it to regular hours such as 8 AM to 5 PM.
Central location for all machines. It’s a good idea to keep all the build machines together, not spread around sites or labs.
Biometrics. This is a new technology that is proving to be safe and convenient, especially biometric fingerprint keyboards.
Not allowing laptops to check in or check out sources. At the very least, laptops should go through some kind of security scan before being allowed to log in to the network.
Physical security is more of a deterrent than a means of actually catching criminals, but it is important because it sends a message that your company values the work your development team does and is conscious about keeping it secure. It provides the illusion of being secure just like the wand searches at every U.S. airport.
There’s a misconception among software companies that every line of code that they write must be protected like it’s gold, but it’s time for a reality check: Little source code is patentable or of real intellectual property (IP) value (see the “Richter on .NET Security” sidenote later in this chapter), so you should worry more about securing the source code control process and the build process rather than the individual source files.
Some companies go to extreme lengths to try to secure their source code via physical means, including locking developer machines in a secure development lab. These companies don’t allow the developers to carry hardware or bags in or out of the lab. I don’t know many developers who can work in that type of environment, though. Also, if you can’t trust a developer not to steal your code, how can you trust him to write it?
There’s a better way to secure your development:
Track all check-ins to a secured, locked-down, golden source tree.
Create triggers to ensure that check-in rules, such as buddy build and code review, have been followed.
Reject check-ins that do not comply.
Schedule atomic check-ins from different groups.
Set up development sponsors at the central and offsite location. These persons are ultimately responsible for the integrity of the code being checked in. This is probably the most critical step.
Automatically check the developer’s user network logon to whatever headcount tracking tool you use. Verify the developer’s identity with network logon and machine name.
Run security checks on check-ins and all sources that are released. You can do this with scripts or tools that search for any known holes in architecture or unsafe API calls.
Limit access to “new” source code. Some groups or companies allow offsite development teams to work only on hotfixes and service packs, not to develop new features or code.
These suggestions are representative of how we are able to track source code changes back to the original owner and how we are assured that only the changes necessary to fix the bug or add a feature are checked in. If you combine these steps with the VBL process in Chapter 2, “Source Tree Configuration for Multiple Sites and Parallel (Multi-Version) Development Work,” you will have an incredibly reliable and dependable system of maintaining your sources and their changes.
Unless you are working with open-source software, it is usually in everyone’s best interest to be 100 percent sure that all the release bits (the binaries and files) in your product came from your development team. Therefore, you need some kind of mechanism to verify or enforce this condition. Several tools are available that can modify binaries after they have been released. A malicious person does not need access to the source code. He can just use this tool, which is usually easily accessible via the Web, and “hack” the binary to perform some unwanted behavior. The best way to prevent this from happening is to integrate software restriction policies. Software restriction policies are a new feature in Microsoft Windows XP and Windows Server 2003. This important feature provides administrators with a policy-driven mechanism for identifying software programs running on computers in a domain, and it controls the ability of those programs to execute. Software restriction policies can improve system integrity and manageability—which ultimately lowers the cost of owning a computer. As a result, no one will be able to copy a hacked or modified binary over the original product.
You should also make sure that you have a good versioning scheme so that you can track the build number associated with a particular release. We talked about this in great detail in Chapter 8, “Versioning.”
Using your IT department’s technologies to provide protection from unauthorized users is a great “free” line of defense for your source code or builds. This defense is free because it is maintained and provided by your IT department and should not come out of your group’s budget.
The following is a list of inherited security you can get from your IT department:
Create secured domains and user profiles—one-way trusts.
Use Microsoft operations manager (MOM) or similar technology to ensure that everyone has the latest security fixes and firewalls running on his machine.
Limit VPN connections to only company-approved hardware and software.
Limit VPN access to source trees to machines that are members of the proper domain.
Prohibit remote access to source servers to everyone except administrators.
Prohibit Web access or check-ins/check-outs to the source servers.
Turn on and use IPSec—Internet Protocol Security, the use of encryption at the network layer protecting and authenticating IP packets between IPSec devices.
If you work with your IT department, you should also be able to automate a lot of security measures, such as these:
The process of granting access to valid users via a Web tool and adding them to the appropriate security group.
The use of group polices to restrict users from running batch jobs using domain credentials, which can be a big security leak. Also, these policies can ensure that only valid users are allowed to access the source control servers.
Running anti-virus programs on your source control servers and protecting them from the outside Web via firewalls, proxy servers, and domain restrictions.
Randomly auditing developer desktops to make sure they are not a security hazard.
I mentioned in Chapter 4, that it is better if your IT department does not maintain your build machines. I still think this should be the case, but rely on your IT department to maintain and control your corporate network, including restricting how users log in remotely or onsite. This is the security area outlined in this section.
If you feel that everything we discussed in this chapter is still not enough security for you, do a code reset of your product and rewrite it for the .NET Framework. In fact, when I’m asked to describe .NET in one word, my answer is security. .NET is secure for many reasons, including these:
Strong-named assemblies (DLLs or EXEs) provide certificates that guarantee their uniqueness and authenticity.
The garbage collector manages memory, so leaks are virtually impossible. This eliminates malicious virus or worm attacks.
You have the ability to confine code to run in administrator-defined security contexts, which is another safeguard against worms and viruses.
Code access security revolves around the identity of source code, not user identity. This eliminates impersonation attacks.
The .NET security system functions atop traditional operating system security, adding another layer of security that is already present.
The topic of build security seems to come up only when companies are starting offsite development or outsourcing their development to outside countries. This is really not a good topic to be considered as an “afterthought” or “closing the gate after the horse already ran out of the barn.” The sooner you can integrate security, the better off your company will be in the long run. Also, many public corporations and governments mandate a certain level of security. If this is the target audience you are after, I would start integrating these processes as soon as possible. The processes here are Microsoft’s approach. Feel free to use or develop your own tactics.
With all the talk about security on the Internet and in the applications that are out there, we must not forget about keeping company “jewels” safe. Here are some recommendations that were covered in this chapter:
At a minimum, use the four-layer approach talked about in detail in this chapter:
Physical security—. Doors, locks, cameras, and so on.
Tracking source changes—. The build process.
Binary/release bits assurance—. The tools process.
IT infrastructure—. Company-wide policy and security.
Consider the .NET platform as a means of security.
Look into software restriction policies that are in Microsoft Windows XP and Windows Server 2003.
Start worrying about security before a breach occurs.