Fog Creek Software
Discussion Board




Security in your developer workplace

hi,

I work for a company with around 15 developers. the current situation is that all developers are admins on their machines, and have full access to all project sourcecodes and databases.

I'm curious how other companies manage restrictions for source codes, development databases, etc.

What are the must haves and what are the ones which is stupid and annoying.

Thanks,

na
Wednesday, September 10, 2003

The system is locked down so you can't check mail/surf without going through the normal corporate firewall.

Users must lock their pc when leaving for any reason.

W force workstation/domain password changes every 3 weeks.

Although people can install software with admin like rights, they can't subvert domain special privilages, these rights extends only to the stations.

All files are stored on network shares and unless there's a very good reason no projects files are stored on hard drives.

We still haven't adopted any of the more fancier policies other firms are trying now days like:

1. Encrypted filesystems
2. Fingerprinting

Anonymous
Wednesday, September 10, 2003

Number 1 assumption:  You've hired good competent people and we're all on the same team.  If that is not the case, correct this first.

After that, within these walls, my colleagues know my password.  If they need something for any reason, they can get it.

All product related source, documentation, project plans, everything, is in checked in to source control.  Source control is incrementally auto-backed up nightly.  Full backup weekly.  Weekly backups are stored offsite.

No restrictions are placed on the source tree.  Everyone has read/write access to everything.

just coffee black (egg white to you)
Wednesday, September 10, 2003

Actually, most cases of computer crime are at least partially inside jobs.  So you really shouldn't have explicit trust for your fellow developer.

Flamebait Sr.
Wednesday, September 10, 2003

Tsk, tsk. Sharing passwords is poor practice even when people can be trusted. It increases the likelyhood that the password can be known by people who can't be trusted.

There is no way that accountability can be determined if multiple people use the same password.

Also, one should be able to change a password quickly. If multiple people share the password, the coordination needed to communicate the new password makes changing the password take too long.

It might make sense to keep things "open", just give everybody a different key.

njkayaker
Wednesday, September 10, 2003

I've got a good reason to put my "project files" on my computer.  It takes forever to build over the network.  I don't think you could do much more than toy projects with out having source files on your local machine, unless you have a really trick build environment where developers can compile on demand.

christopher baus
Wednesday, September 10, 2003

Regarding: I don't think you could do much more than toy projects with out having source files on your local machine, unless you have a really trick build environment where developers can compile on demand.

Just out of curiosity.. could you elaborate a little about your environment? What's the dominate programming languages used? What sort of software do you write? What's the software cycle? How many team members?

Anonymous
Wednesday, September 10, 2003

C++
4-8 developers
desktop software for the financial industry
something like 300k lines of code

but with that said I would want to build even 50 source files over the network.  I wanted to put my source tree out on the network, but it was just way to painful to build.

christopher baus
Wednesday, September 10, 2003

Ours wouldn't work over the network either, we have nearly a gigabyte of source files (not just code, but help files, images, mergemodules etc.) in VSS and if it isn't local it takes an age to compile (this is in VFP).

Imagine how long it would take to check out from the VSS on serverA to your Z: drive that is located on ServerB?

Although I see no reason to have a rule of "no project files on desktop machines" when you (presumably) have your sourcesafe database on a server that is backed up nightly and you have well over 80GB of free space on your desktop machines.

But documents etc are all kept on a server and not locally. And one thing we do is redirect everybodies "My Documents" folder to a server share so that if somebody accidentally keeps important docs in there at least it will be backed up. Another trick we have done is to limit the profile sizes to 30MB to prevent certain sales people from storing 2GB of company documents on their desktops (I kid you not!)

Chris
Wednesday, September 10, 2003

Perhaps you need a better version control system.  On a raw build machine, I deleted the top level source control directory and re-sync'd against our server.

Total time: 11 minutes
Total bytes: 3076340

Source control courtesy of perforce.  I don't think project size has anything to do with it.

just coffee black (egg white to you)
Wednesday, September 10, 2003

Sorry, size is in KBytes.

just coffee black (egg white to you)
Wednesday, September 10, 2003

Oh how I wish we could use Perforce. A dream to work with honestly, but when VSS comes in the MSDN that they already paid for we can't really justify it.

Chris
Wednesday, September 10, 2003

Pretty simple, really - find a good security review paper that points out what a hugely massive security hole shared drives are (one of the top virus vectors, after email).

Then challenge them to find a way to set up VSS without using shared drives.

Problem solved.

Philo

Philo
Thursday, September 11, 2003

Also, try to use Visual SourceSafe in such a way that you can (1) quickly see a list of the files you have checked out
(2) avoid losing change history when your server's disk gets full
(3) check in multiple files transactionally.

Exception guy
Thursday, September 11, 2003

CVS is free, and not bad either.

just coffee black (egg white to you)
Thursday, September 11, 2003

*  Recent Topics

*  Fog Creek Home