mailing list archives
Re: Deny access to copy files
From: MaddHatter <maddhatt+securitybasics () cat pdx edu>
Date: Mon, 2 Jun 2008 17:21:33 -0700
and their requirement is to restrict programmers to take the code out of
office premises due to company policy.
... denies access to copy files to external storage devices
connected to USB. ...
How can I block such thing?
Any help would be highly appreciated.
The following may not be easy to implement, but if you are SERIOUS about
source code security, this about all you can do:
1) All software development activities should be done on a dedicated,
isolated, secure network that is fully encrypted. ...
2) All computers on the secure development network must have all forms
of removable media disabled in the BIOS. ...
3) Systems should have multi-factor authentication...
4) Servers storing source code must be in a controlled area ...
5) Do rigorous background checks ...
And even if you do all of this, a malicious employee can still bring
in a camera, take pictures of his/her screen, then go home and OCR the
data to regenerate the source code. Or print out the source code and
do the same thing. Are you going to strip-search every employee as they
arrive and leave work? Even that only catches the stuff that's obviously
identifiable as contraband. Some prisons attempt to control communication
and data flow much like you're attempting to do, and they have a very
limited success. That illustrates how restrictive your environment has
to be if you hope to gain the degree of control you apparently desire.
Maybe you don't want absolute prevention. Rethink what you're really trying
to prevent, and why. Are you scared of source code leaving the premises
or are you scared of a competitor/outside entity getting a copy of your
code? Are you really mistrusting of your employees (in which case, get
rid of them), or are you trying to prevent mistakes? Those are different
problems, and solving the wrong problem is going to be wasteful and
frustrating all around. (Sorry if I'm being patronizing here; sometimes
it helps to refocus on the real issue.)
You can prevent mistakes and deter the non-determined attacker/employee
with some simple policies and basic controls. Don't grant employees access
to (read) code they don't need to modify. Make sure your source code is
encrypted at least when it's at rest, and maybe also when in flight. Make
sure access is terminated as soon as an employee leaves. Ensure
strong passwords. Use multifactor authentication where feasible. Make sure
contractors that handle your data are bound by the same policies... all
that good stuff. Make sure employees understand the importance of your
policies and "get them on board" with you so they help you (enforce your
policies). That stands in contrast to throwing obstacles in employees'
path so they perceive your policies as antagonistic, which sounds like
what you're doing.
Part of getting your employees psychologically "with you" instead of
"against you" is to meet their needs and desires. For example, rather
than prevent your employees from taking code home, give them a secure
and supported method to work from home. (That may mean giving them
company laptops.) Now they can use your secure, controlled method when
they want to work at home instead of inventing their own uncontrolled,
insecure workaround. Within reason, just because IT says "no" doesn't
mean it won't happen; it just means it'll happen without the benefits IT
governance could have brought to bear. You're dealing with humans here,