« CERT coding standards | Main | Why I like RC5 and RC6, Part 3 »

Thursday, 22 January 2009

Security by default

OpenBSD is designed to be secure by default. After you install an OpenBSD system, you need to explicitly make any changes that allow things that could cause security problems. The system administrators at a place that I once worked seemed to have a similar philosophy when it came to security, but it ended up not working quite as well as it does with OpenBSD.

At one time, I worked in the west coast office of a research institution whose main office was on the east coast. Oddly enough, our default printer was one that was in the east coast office, which was over 2,700 miles from our desks. Due to security concerns that I still don't quite understand, we couldn't change our default printer. Instead, we had to manually select the local printer every time that we printed something. If we didn't, our stuff would end up in Princeton, New Jersey instead of La Jolla, California. This happened fairly often.

Because we were working on classified government projects, all of the documents that we printed out were classified because they came off a classified system. This meant that the unlucky guys in New Jersey had to treat all of our printouts as if they were classified when they showed up on their printer, even if it was just directions to lunch. Because of this, every few days we'd get an email from the annoyed people on the east coast reminding us to be careful about our printer settings. This system might have been secure by default, but I don't see what good it did in this particular case.

So security by default may be a good idea, but you should probably make sure that your settings at least make sense before making them the defaults.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e55375ef1c8833010536e32824970b

Listed below are links to weblogs that reference Security by default:

Comments

Post a comment

If you have a TypeKey or TypePad account, please Sign In.

Voltage Data Breach Index

  • Grab the Voltage Data Breach Index

May 2012

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31