SUFO - Save Us From Ourselves

Security topics involving software usually have more to do with protecting the code from the people who are granted access to it rather than protecting it from the outside world.  Sure, you don't want your code to fall into the hands of your competitors, but common sense practices such as locking your doors at night, using password protected file systems, and protecting your internal networks with a firewall will keep most of the outside riff-raff from walking away with your intellectual property.  What about the insiders, the users who have legitimate access to your files?  How do you protect your code from them?

I know what your thinking.  "My people would never intentionally do anything to harm or steal the code!"  I'm not suggesting they would!  The key word here is ‘intentionally'.  No one ‘intentionally' deletes files by mistake, or makes changes that break the build, or spills coffee on their machine, or adds features that aren't in the requirements. OK, maybe the last one is intentional, but most people do what they think is the right thing and do not intend to cause damage.  Unfortunately, however, bad things can happen to good people, which is why insurance companies have enough cash to buy Europe.  What kind of insurance can you buy that will protect you against unintentional error and loss when it comes to your software?  I'm not sure of actual insurance companies that can help you with this, although I do know this guy that deals in swampland and bridges that might help...

The best you can do to protect yourself is to have a well thought out development process and use a software configuration management tool that is designed to help you reduce risk.  That's it!  Have a nice day and thanks for reading.

OK, OK, I'll elaborate.

Unless you enjoy overtime, pain, and massive coronaries, use a version control tool.  Even if you're a one-person shop, you need a secure, controlled environment to store your software code.  Storing your files in a traditional file and folder system won't cut it.  Eventually you're going to lose something, probably your sanity.

There are a wide variety of tools to choose from and some are even free, but you generally get what you pay for.  Most provide the basic elements for security, such as requiring password-protected logons.  This way only people who are allowed access can get access.  Most tools record history of who did what, so you can see what user changed what file and when.  Also, every version control tool keeps multiple versions of each file. This way you can always get back to a previous version of any file if needed and it helps you to move ahead incrementally and stay organized.  Most tools also allow you to check changes between the different versions of any file.  The better tools allow you to control different levels of access to the files.  This way you can allow some users to read certain files and not make changes, while others can read and write.  Only special users have the ability to delete files, so most users can't mistakenly delete anything.  It's also important to have a way to preserve entire configurations (a defined set of file versions) that only administrative users can delete or modify without some kind of traceability.

Some of the more sophisticated tools allow you to preserve different configurations at the same time.  This is especially helpful if you have groups of people changing the same code, or if you have to go back and patch a previous release.

So you have your nifty source control tool that's the envy of configuration management geeks everywhere.  Will this solve all your problems?  If you answered ‘yes', either your name is Pollyanna or you're a source control tool salesperson.  As good as the tools available today are, you still need to rely on a method of using the tool.  Your users need to follow certain guidelines, like when should they check in a file?  When is it OK to make a change to a file?  What kinds of files should be placed under source control?  The answers to these types of questions depend on your own situation, but they should be answered.  They should also be documented in writing so they can be properly referenced and followed.  This will help with the "no one told me" syndrome and the "because that's the way I did it on my previous project" excuse.

Just because you have a secure database to store your code, what about recovering from things such as hardware failure, and what if the building burns down overnight?  As part of your software process, you should make sure you are properly backing up your database.  Back ups should be created on a daily basis, depending on how much loss you can tolerate if you had to do a restore.  Maybe you are already making daily backups, but can they be properly restored?  Make sure you can safely restore your backups so you know they are working.  The boss will probably stop buying you Friday donuts if you are forced to do a recovery and you find out the hard way that they're no good.  You should also be rotating a copy of your backups off site to make sure you can recover your files if something should happen to the structure that houses your business, especially if you are working out of a trailer in any of the plains states.

There's one back up that many software shops neglect.  What about the files that the developers have checked out?  Most software work is done on local workstations, and even though the file is under source control, the version that is checked out is completely unprotected.  Have you ever had a developer work for three weeks on a problem just to lose it all because his hard drive crashed? Ouch!  Make sure that local workstations have some kind of backup.  This can be somewhat of a challenge because each local workspace probably also contains the entire software project, and the user might only have several files checked out at one time.  Depending on how many users you have, you could be potentially making backups of hundreds of files that are already protected under source control.  It is better to err on the side of safety and back up the whole thing, but there are ways to identify the checked out files and so you aren't backing up hundreds of redundant files.  One simple way is to use a batch script to identify or copy files that are not read-only to a special backup location.  You can refine this process further by filtering out common intermediate files created by builds that you don't need to save.  Your version control tool might also have command line options that can be used to identify checked out files.

A favorite saying of one of our more colorful developers is "Security is the enemy of usability".  There's a lot of truth in this statement, and it certainly holds true when it comes to software development.  The tighter your controls are, the more the users will fight the system, and the harder it can be for them to do their job.  Tight controls and restrictions enforced by your version control system will be named as a scapegoat when bad things happen, like when schedules slip, when the weather turns sour, when the user's favorite team loses the Super Bowl, etc.  It's important that users understand why certain restrictions are enforced, but it's also true that too much security can cause more pain that it's worth.

Some environments have to employ extra tight controls to make sure that only approved changes can be made, no matter how small.  These include situations where a software bug could cause the loss of a huge financial investment or even the loss of life (i.e., things that fly, things that fly to other planets, etc.).  Other environments can tolerate a certain level of error without having to employ a drastic policy of control.  Like most things in life, your level of security and control needs to be in balance with the price tag that comes along with it.  Make security decisions that make sense for your environment.

So, go forth and implement CM security, and don't tell your developers that you heard any of this from me.  I have enough personal security concerns when it comes to my own disgruntled developers, which is why I'm going to now risk another attempt at seeking the relative safety of the executive washroom.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment