How Security Policies Fail (1)

Policy: Users must choose a new secret complex password every thirty days.

Failure: Users create passwords in sequence, or write them down, or wangle exemptions to the requirement...

This one is robust -- the compliance situation doesn't get any worse as time goes on, and correcting it is relatively simple, but it's not lazy -- it's easier to ignore than to obey.

To make this one work, we would have to

• Crack passwords 24x7 and disable any that didn't reach some bar.
• Patrol the floors destroying dodgy-looking Post-It (tm) notes.
• Report the list of exempt users, and require them to re-certify their exemption every week.

That would give an incentive to pick gooduns and keep them secret. Of course, we would piss off the 50% of users -- some bright, some not -- for whom picking and remembering a good password is totally alien. So while it's enforceable, it's still a bad policy.

Creating Liability, or Doing the Job?

OK: you block phishing websites, and that's a good thing. Your users won't be giving their banking passwords to the mafia, because they can't reach the sites.

So you're a hero. Except: every week, on the blocked accesses report, there's one or two people failing to reach sites that Websense says are phishing. Fair enough -- whatever http://www.barclays.co.uk.crzyhosting.tm is, it's not a legitimate bank. Everything is working, but maybe you are in trouble.

Those users have PCs at home. They get email at home. You know -- you've got the evidence on the report -- that they are prone to click through phishing emails. It's just as easy to be robbed at home. Should you educate them about the risk?

No. It'll take up forty minutes a week that you just don't have.

Yes. Of course you should. The firm has a duty of care to its staff.

No. Staff's management of their own bank accounts is their own business. We permit personal use of the web, but it's not consequently our job to protect them from every possible problem.

Yes. In stopping access from work, when there's no actual risk to the firm, we've acknowledged that we do have a liability. If we know that a staff member is putting themselves in danger, and we let them go ahead without a warning, their loss could be ours.

No. It's too ridiculous. How can my starting to receive a report oblige me to spend my time on my user's private affairs?

Yes. Come to think of it, what about the sites that Websense hasn't categorised yet? Suppose people get the idea that the site is safe if it's not blocked? Oh, and did I mention that one of those names is your boss's boss's boss?

This one calls for a compromise. I'm not going to construct a personalised security awareness program for anyone who reads spam mail -- among other reasons, it just doesn't work. But I will, illogically, change the "you have been blocked" message to remind people that their safety is in their own hands. And the Director? Well, it turns out that he loves a good phishing site as much as the rest of us -- he was a bit disappointed that that we were blocking them now. So much for heroism.

Time for SubInACL

Do we script because we are old enough to remember when the command line was all there was? Or are we so old that we don't feel that there's time to muck about any more?

Either way, I've been trying to find a way to make bulk changes in file server permissions. These are typically volumes of a few hundred GB with something like one to ten million objects. I need to apply Chinese Walls (a term of art, not an architectural reference), apply them now, and the helpdesk is only halfway through the permissioning process implementation that would have let me do this properly.

Well, it's time to use the dreaded Deny permission. Easy to say, but tougher to apply to millions of objects past unpredictable inheritance, Creator Owner permissions and distinctly dodgy admin permissions. I've tried a good many approaches:

• It's obviously got to be a script.
• To convince the auditors, the permissions have to go on to the filesystem roots of "all" servers, and adjust the denied groups on the way down. A file of UNCs and allowed business units is being prepared as I write.
• I don't like that hourglass up for hour after hour. I like it even less, knowing that the changes I'm making will be silently abandoned every time it encounters a break in inheritance
• I already have alldisks.pl to enumerate the UNC of every disk on every (matching) server from a domain or a list, and run a command against it....
• And ultimately, I'll want to take it off, once we have the permissioning process up and running properly and honestly

I can't find a perl module that lets me do this. Win32 Security looks good, but I'm too stupid to make it work -- it boggles without builtin admin/Full. Filesystem Object is not really my area, but it seems to completely lack DACLs

The obvious tool is is [X]CACLS, except that I can't make it go past inheritance breaks, so the script has to chase it down the tree, testing each layer to see if the applied ACE has got there. And that's no joke when the output is SDDL.

SubInACL is about editing ACLs, not adding new ACEs. Isn't it? Oh.

Yes. SubInACL has grown up. The latest version (and believe me, you really need the latest version -- the one in the 2K3 resource kit doesn't even work) provides a robust, tree-oriented structure to report, grant or deny permissions at 100,000 objects per hour on any remote or local server where you are a local admin. Sure, the command language is a bit bonkers, the report output needs serious digestion to be useful for people, and the management of the ACL inherit flag preserves that same maddening ambiguity. But that's why we have Perl, and I can live with it all, just for the sake of knowing that my changes will be applied the way I write them. The fact that I can fix some stupid global admin access control, and do it for free in the same pass as my deny permissioning is just a huge bonus.

Almost for certain, SubInACL will do what you want, and if it won't, I'll bet that what you want isn't legitimate. If you couple it with Win32::NetAdmin for remote management of local groups, you can be in a better place for scripted permissioning than you would ever have believed.

The ten-year-old administrator -- your partner in securing your network

Everyone wants SSL VPNs. Apparently they eliminate the risk from malware on the remote workstation -- "It's just a browser window! What can go wrong?"

The question deserves an answer. Here are several:

1. Hardware or software keylogger can compromise passwords used to access systems within the VPN
2. Software keylogger can steal one-time passwords and use them in real-time to gain access from an unauthorised site
3. Configured incorrectly, you can deliver local drives to the Citrix session or vice versa
4. You can end up with confidential data cached on the insecure remote machine
5. You have to support a remote machine you know nothing about. Don't bother trying to contact the site admin -- he's at school. He's ten. He really likes animated cursors and he's willing to press "OK" as many times as as it takes to get them.

The SSL VPN is still the lesser risk, if the alternative means giving alien machines IP addresses on your network. And this isn't technology you can ignore: it's too useful to pick up your email from a home PC. So you have to set tiers:

1. Specially built apps can be delivered to absolutely any browser that can rock up to an external address on port 443. Webmail is the classic. OWA is not as terrible as it used to be. Authentication is by a typed one-time password from a token. It's nothing to do with a VPN, but it is SSL, and it might make the users happy all by itself.
2. Home machines that can install a client that can do basic validation are allowed to see the VPN. The Cisco client can check a Windows machine for surprises in the GINA, XP firewall on, SUS on, and it can create an encrypted desktop cache. Authentication is via the token.
3. Your own build machines which have current AV and patching are allowed to map drives and use local copies of data. Authentication is via a certificate on the same USB smartcard that unlocks the disk encryption....

And the old IPSEC VPN? That's moved over to a need-to-use basis only. We spent all that money, and now only the admins use it!

Memories

Less mad son wanted some company at bedtime this evening. He was in tears thinking about lost opportunities and moral failings in the past -- truly hideous unforgiveable errors:

• Two years ago: Leaving a teddy bear -- originally his mother's -- to be chewed by the dog. (It was rescued. It was in bed with him as we spoke.)
• Four years ago: Losing some plastic sandals on the beach at Paignton
• Five years ago: Deliberately crushing snails while riding his bike
• Six years ago: Losing a ballon inadequately tied to his pushchair

These are the things he remembers. Key points are a) There are no people in any of them, and b) someone (less mad son, me or his mother) got a little het up. So we talked about learning from errors, being kind to animals and not worrying about minor stuff that can't be changed and he was a little consoled.

He says he's been having these thoughts for a few days, but I think the real reason for this evening is that he dropped and broke his plasma ball lamp this afternoon. He was so frightened about what his mother would say that he ran outside to find me so that we could hide the evidence before she found out -- which we did.

Memo to self: go easy on warning less mad son of hideous consequences of leaving CDs out for Comedy Dave to find. 1) He knows, and 2) he's already torturing himself about it.