Re: [JOB / Recommendation] Evil documentation
On Tue, Jul 16, 2002 at 02:37:55PM +0100, Chris Benson wrote: > On Tue, Jul 16, 2002 at 01:24:22PM +0100, Jonathan Peterson wrote: > > My company needs some security policies and procedures documentation. > > > > I have no intention of reducing my own sanity by actually sitting down > > to write all this. So, does anyone know of any freelancers or cheap > Good move :-) A few years ago (maybe ~10 :-() There was a package on the > net that provided a canned best-practice AUP There's a canned security policy somewhere on securityfocus. I have it bookmarked at home if nyone wants it. Doing that sort of thing is one of the areas I'm looking for a permie job right now. -- David Cantrell | Benevolent Dictator | http://www.cantrell.org.uk/david Longum iter est per praecepta, breve et efficax per exempla. -- Seneca Philosophus, Epistulae
Re: [JOB / Recommendation] Evil documentation
* Richard Clyne ([EMAIL PROTECTED]) wrote: > Having been involved in producing these sort of policies for my company, > I think it will take a lot longer for them to be produced, unless you > don't mind having unenforceable policies from an HR perspective. > One of the ways to get around the enforcing of the policy from the viewpoint of the IT department can be to simply not enforce it outside of your department. Instead, produce a monthly one page report for distribution to senior management that shows a fairly arbitrary set of security statistics broken down by department, this theoretically should encourage senior managers to enforce the policies within their department. For instance if a password needs to be changed every 30 days, set the lockout to 45 days and record the departments with 30-45 day old passwords on the report. Record any department who have employee's leave and IT equipment (laptops) unaccounted for. You can go as big brother as you want, scan pc's registry's for machines without a passworded screensaver setup. Scan HD's for .mdb's, .xls's and .doc's that are stored locally instead of on the fileserver (hence they are not backed up and are more subsceptible to physical theft). Record machines found to have viruses on them. This way you avoid having to argue with Joe in Accounts Receivable about why he likes to use his big brother screensaver that does not support passwords. HTH, YMMV, IMHO, Greg -- Greg McCarroll http://www.mccarroll.org.uk/~gem/ jabber:[EMAIL PROTECTED] msn:[EMAIL PROTECTED]
RE: [JOB / Recommendation] Evil documentation
Having been involved in producing these sort of policies for my company, I think it will take a lot longer for them to be produced, unless you don't mind having unenforceable policies from an HR perspective. There are boilerplate versions on the SANS site that can act as a start point. Richard -Original Message- From: Jonathan Peterson [mailto:[EMAIL PROTECTED]] Sent: 16 July 2002 13:24 To: [EMAIL PROTECTED] Subject: [JOB / Recommendation] Evil documentation My company needs some security policies and procedures documentation. You know, the kind of thing that says in writing "Users must change passwords every 30 days" and "Changes to firewall configuration must be approved in writing by the CTO" and so on. I have no intention of reducing my own sanity by actually sitting down to write all this. So, does anyone know of any freelancers or cheap agencies who do this kind of thing? We're more than happy for it to be mostly boilerplate stuff, but prior experience is required. I think it's a few (i.e. less than 6) grands worth of work. -- Jonathan Peterson Technical Manager, Unified Ltd, +44 (0)20 7383 6092 [EMAIL PROTECTED]
Re: password expiry (was Re: [JOB / Recommendation] Evil documentation)
On Tue, 16 Jul 2002, Michael Stevens wrote: > On Tue, Jul 16, 2002 at 01:34:19PM +0100, Nicholas Clark wrote: > > I'm not convinced that frequent password changing is good, because I find > > it seems to lead to either frequent password resetting by administrators > > (with inherent social engineering vulnerability) or passwords written down, > > which also isn't secure. I guess the security idea is that the password on a > > Or people generating passwords based on a predictable base and a > changing element that changes just enough to fulfill the requirement > to change one's password. > Indeed. I know of a certain finiancial institution that every employee in the office incre,mented the number on the end of their password by 1 each month. Worse still the passwords were guessable so half the employees were able to guess the managers password in two guesses or less. Policy is nothing without the associated training and buy-in. People have to be encouraged to go with the program and blanket polcies without buiy-in and training will result in worse security and people digging their heels in. A. -- http://termisoc.org/~betty";> Betty @ termisoc.org "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: [JOB / Recommendation] Evil documentation
On Tue, Jul 16, 2002 at 01:24:22PM +0100, Jonathan Peterson wrote: > My company needs some security policies and procedures documentation. > > I have no intention of reducing my own sanity by actually sitting down > to write all this. So, does anyone know of any freelancers or cheap Good move :-) A few years ago (maybe ~10 :-() There was a package on the net that provided a canned best-practice AUP, with some tools (shell scripts) to ensure new users read-and-confirmed the AUP and recorded their acceptance. It was written by the MD of a small company to save him explaining things over and over and thrown open for all to use and extend. I've just been Googling for it without success: I thought it had a snappy acronym, but can't find it now ... http://www.eff.org/CAF/ (in the Archives section) has some notes about policies. -- Chris Benson
Re: password expiry (was Re: [JOB / Recommendation] Evil documentation)
Michael Stevens wrote: > On Tue, Jul 16, 2002 at 01:34:19PM +0100, Nicholas Clark wrote: > >>I'm not convinced that frequent password changing is good, because I find >>it seems to lead to either frequent password resetting by administrators >>(with inherent social engineering vulnerability) or passwords written down, >>which also isn't secure. I guess the security idea is that the password on a > > > Or people generating passwords based on a predictable base and a > changing element that changes just enough to fulfill the requirement > to change one's password. Actually I agree - I'm not a fan of frequent password changing. I think it mainly protects against people who have shared their password. This is a big problem. People in offices are always doing things like phoning a colleague from home saying "I need to see if I've got an email from [client] today, but my modem's not working, can you just go into my email and check for me?" and then telling their password to the colleague. For those of us who don't share passwords, a good, long, random password that we finally manage to memorise is much better. The real solution is of course two factor authentication. Go SecurID!!* -- Jonathan Peterson Technical Manager, Unified Ltd, +44 (0)20 7383 6092 [EMAIL PROTECTED] *Expensive but works well.
password expiry (was Re: [JOB / Recommendation] Evil documentation)
On Tue, Jul 16, 2002 at 01:24:22PM +0100, Jonathan Peterson wrote: > My company needs some security policies and procedures documentation. > You know, the kind of thing that says in writing "Users must change > passwords every 30 days" and "Changes to firewall configuration must be Personally I find that my brain interprets that as "users must forget passwords every 30 days". What goes wrong is that $^O says "your password will expire in $n days, would you like to change it?" and I go "oh bugger", make something new up that I think I'll remember, change it to that, and then promptly forget it. I'm not convinced that frequent password changing is good, because I find it seems to lead to either frequent password resetting by administrators (with inherent social engineering vulnerability) or passwords written down, which also isn't secure. I guess the security idea is that the password on a piece of paper is now only valid for 15.5 days on average, so the system is now more secure than it used to be, when pieces of paper remained valid for months. I just wonder if it creates more paper users. Nicholas Clark
