How Security Policies Fail (4)

Policy: No application data may be permissioned to Everyone, to Domain Users, Authenticated Users or to any specific user. All permissions must be on non-builtin groups.

Failure: There are ways almost without number to end up with ACEs referring to Everyone or some other uncontrolled group. The most pernicious is simply inheritance of wrong permissions -- the most annoying is the shamelessness of external staff contracted to install an application. Similarly, the easiest way to grant access is to grant it to the particular user -- no need to log on and off. It really does seem as though permissioning is the area where natural human laziness is exactly opposed to security.

So this policy is certainly not lazy -- the choices required are always harder and sometimes require an unpleasant confrontation. And it's the classic non-robust policy -- unpicking the permissioning scheme of a working app, without wrecking it, is hard. It doesn't help that there's no permissions register: you have to read ACLs directly off every file and resource.

In a harsher world than mine, any server admin who set an extra-policy permission would lose his access. Either he chose to breach policy -- it surely can't be that -- or he didn't know better in which case it's improper to allow him to be a machine admin until he's been retrained.

I've spent too much time casting around for a solution. The only approach is to dump permissions regularly, pick out the nasties and watch for deltas. That requires some heavy scipting.

Ten Presents.

Comedy Dave is nine today. He's still a bit vague about age, but he has definitely grasped the concept of presents.

Starting about a month ago, with "One Present -- Piccadilly Line DVD" he has built up a gruffly declarative recitation which reached a climax of "12 Presents....". I think he genuinely began to wonder whether he had over-reached himself, anyway it stabilised at ten and he committed it to a printed list.

David being David, it was mostly driver's eye train videos and train sets. What he did put in was some Leap Pad books. He's had them for years, he's completely destroyed the printed templates, but he still plays the cartridges, placing the stylus from memory. He's so skillful, but he's well aware that the experience is missing something and he wants it back.

This has been the most consistently intentful communication that the more mad son has ever made. We got him everything possible. We've rewarded his communication -- and taught him pester power.

Apparently he was a bit shocked to discover that some presents weren't on the list, and the list itself wasn't entirely fulfilled. But he kept his composure, and settled down with the Flying Scotsman.

Party -- another surprising request -- tomorrow.

A Secure Way with the Rabbits

The rabbit situation has got worse over the last two years. They used to be based in the brambles on the boundary, and stayed decently in the orchard. But increasingly frequent incursions have developed into a permanent problem -- there's a new warren under the garden hedge, and they've been all over the garden this season.

Rabbits aren't very bright, but they have a gourmand's appetite for the carefully tended, well-loved specimen. When they've eaten all the leaves, they did up the roots and eat those. There's plenty of grass if they're hungry -- it's just lust for variety.

When they dug up Mrs U's geraniums, they pushed her over a line. She got a specialist in. He said to leave it for the moment. He'll come back in the winter when it's easy to gas them in their burrows. In the mean time, we must get a terrier with the speed and turning circle to catch them and break their fragile rodent necks.

This sheds no light at all on dealing with Internet-hosted attackers. But I wish it did.

How Security Policies Fail (3)

Policy: Only our trusted workstation build may be attached to the LAN

Failure: Contractors and visitors need Internet action, sometimes at very short notice. The easy way to let them have it is to plug into one of the DHCP LANs.

This policy is fairly robust: it's not that hard to spot non-domain machines with an IP address, and the price of disconnecting is a brief argument about priorities, project objectives and timescales. But it is not at all lazy: it's incomparably easier to snaffle a cable from the desk next door, or even try outlets at random, than it is to order and pay for an ADSL outlet.

So we have to make a lazy route to Internet access. I see a three stage plan:

• Deliver a "contractor convenience" VLAN through your switching infrastructure. This would have no internal routing -- just a cheap firewall direct to your Internet red side, with no inbound access, and outbound permits for browsing and VPN only.
• Make sure there's no Internet from your internal DHCP LANs or printer LANs -- all attempts to browse direct fail at the firewalls
• Make sure you can account for all outlets which do have unproxied Internet.

That will tip the balance of convenience your way: you should start to see all those laptops requesting access to the contractor LAN quite soon.

Stay on top of the risks, though. You want to make sure that your own users won't be hooking up to unfiltered Internet. You should probably arrange the workflow around contractor convenience to include an expiry date to ensure that the outlets get re-certified from time to time.

Is that a Server? Or: Why you can't use domain service accounts on workstations!

What's a server? A server is a computer that you keep in the machine room. Why is that?

• Well of course there can be a host of operational reasons. If you want to keep it running all the time, better install your box where the cleaner won't unplug it
• And there are the security reasons. What are they? From the security PoV, what's a server?

The point really is that access to the physical console of a PC carries a risk that we accept in the case of workstations, but don't accept for other machines. The risk is controlled by controlling access and that's why we have cards, combinations, access logs etc on machine rooms.

I think it's interesting to take the components that traditionally make up that risk and look at the consequences for the machines we DON'T put in the machine room:

1. The contents of the hard disk are confidential or valuable. Apart from the normal confidentiality of a fileserver or application server perhaps the build or install is hard to replicate. So we keep the box in a safe place. Implications for workstations kept in their dangerous places are:
   • Filing on the workstation C: is never right. Users should not be able to write to WS local drives, OR (the laptop solution) local drives should be encrypted with explicit backup responsibility transferred to the user.
   • You should be able to replicate any WS build, or you are hostage to any user who declines to give up their PC
2. Local admin is available to anyone prepared to do a reboot. (You do so know how!) You definitely don't want attackers making themselves admins on your servers, so you lock them away. Workstations can't be locked away, and so their administrator accounts must each have a different, unpredictable password. Then, if I crack my own WS, I'm still not admin on any other, remote, WS. The same goes for any other local account -- so on workstations you probably shouldn't have any.
3. The local admin can run as any domain account used for a service account or task scheduler processing. So our attacker now has access to some domain accounts. (You know how to do that too, without cracking the SC database password list). For workstations, where you know it's possible that an attacker may make themseleves admin, this means that you can't use any system that uses a domain account to run agent services. That was a surprise to me, but it's inescapable.
4. Some applications require a console session to work to be permanently open. It is our solemn duty to mock the designers of these nightmares, but we have to accomodate them, and the right place is in the machine room. For workstations, the implication is that we can only allow processing that can be shut down.

Those last points makes the simplest definition of a server. It's a server if it does unattended processing a) under a domain service account or b) on the console.

The biggest surprise for me was the service account problem. It knocks out some agent-based management tools. Instead, we get to choose the trade-off:

• Agentless tools pass (the same) admin credentials across the network for each machine it manages -- a terrible choice for network security
• Agent-based has to use its own secure channel to report results --duplicating effort and potentially introducing obscure insecurity.

How Security Policies Fail (2)

Policy: Only support or development users may be admins of their own workstation.

Failure: Hard pressed support or development staff discover that applications can be fixed by making users into local admins. So they do.

This policy is not robust -- it's hard to rectify after the fact as users prefer working apps to non-working and you can't guarantee what's going to fail when you do fix it. The policy isn't lazy either -- it's easier for the desktop support person to make the change, move on to the next call and get rid of a troublesome issue than it is to obey the policy.

To make it lazy we have to make the people who break the policy prefer not to break it next time:

• Check membership of Administrators group on each WS -- review new entries
• Extract the username of the desktop staffer who made the change from the workstation security audit log.
• Make sure that the trouble ticket system shows a risk assessment and approval for that change
• or the person who made the unauthorised change has to get it undone.

To make it more robust this has to run every day, so that unapproved changes can be can be undone before they bed in. To make it really robust you need real time alerts for group membership events on your workstations, but that's not easy.

Oh, and you need a way to stop logons as the builtin local admin -- a random password for each WS should do it. But that user should be inacessible anyway.

Doing business over email

This story is much more important than it looks. Rochdale Council probably didn't think at all before filtering email. If they did, they were probably comforted by the conventional wisdom: "of course we filter email -- everyone else does".

If you're installing mail filters, you need to think a bit harder. You need to know all the addresses that engage in any legal or regulatory role and make sure that their mail is reviewed by someone who understands the business. You need HR cover for the review team to ensure that they are all hardened pornography users who won't sue their employer for showing them dirty pictures.

If you want to filter your other addresses, you'd better know your business. "Hardcore" is a construction by/waste product, as well as a property valuation method. Swedish language appears to contain all sorts of forbidden character sequences. Equity analysts get really uptight if you stop them getting news about Pfizer. A list of South American copper mines contains more hate speech than a KKK manifesto. Language, especially the language of email and news is not simple to parse: Most of the unwanted meanings happen in our heads, not in the text.

And if you you think I'm being neurotic about this, perhaps you'll tell me what's the legal status of an email trade confirmation dumped by a filter? How much of an FSA fine would you want to pay?