A Use for Security Theatre

Just lately in the UK we've had Red Mercury, Forest Gate, Ricin and the Liquid Explosive plane bombers. But red mercury is a con, home-made binary explosives are hard to believe (as a weaponised, deliverable threat -- and so is ricin), and Forest Gate saw 250 Babylon fail to find the cyanide bomb they knew was there...

It looks worrying:

• British security forces are so gullible they think that mugs pursuing non-existent weapons are dangerous
• British security forces are so gullible they think it's practical to manufacture explosive from harmless-looking liquids
• British security forces are so gullible, they think that cyanide and ricin are practical weapons

Or really worrying:

• These threats actually exist, and are definitely more likely than jiggering an Li-ion laptop battery to burn through the cabin wall, swallowing remote-detonated explosive packages like a cocaine smuggler, or any of the obvious infrastructure attacks
  [Updated years later, 24/10/2010 with helpful links: http://xkcd.com/651/ and http://www.theregister.co.uk/2009/09/21/bum_bombing/]

Happily, there's at least a third possibility, and it's this: The activity is security theatre designed to send a message to radicalised muslims that loose talk costs careers and long periods on remand in gaol.

A lot of lightly-educated male muslims in the UK are flaming away to each other about the war against Islam, the punishment that the West deserves, and the luscious fantasy glamour targets that can be conjured up by someone who doesn't actually have to plan and execute a terrorist attack.

These men are on a continuum. Some just blether. Some go a stage further and do something really dorky like buying a tonne of fertiliser -- ending up incriminated as can be, but no nearer the ANFO bomb they seek. And some have the capability, intention and a target.... and since speech is free, it's only these last who really matter. And, in the nature of things, they're rare -- colossally outnumbered by the tens and hundreds of thousands who agree, but won't go beyond ugly talk. So why arrest and prosecute people who were unlikely to achieve subtantial acts? The answer is the source of the "intelligence" which is identifying these nutters: communication intercepts. If GCHQ isn't automatically scanning at least some emails, IMs and blogs for dodgy words and links, I'll eat my hat. And if these automatic scanners can distinguish between real threats and radical show-offs, I'll eat my knickers.

Here's the problem -- a real, valuable source of hard intelligence is being undermined by noise. Too many hits to use. What's needed is a way to ensure that the only people sending incriminating commumunications are those prepared to risk arrest. And here's the solution: arrest, and prosecute, to send a message:

MI5 to loudmouth radical muslims: "Shut the fuck up so we can listen to the good stuff. Or we will wreck your life."

The Man in the Middle for All Purposes

I love simple ingenuity, and FormSpy is ingenious. From the McAfee writeup:

... a malware that is installed as a Mozilla/Firefox component extension.

Upon execution, it registers Mozilla event listeners to the malware and sends information submitted by the victim in the web browser to a malicious website. These information can include, but is not limited to, credit numbers, passwords, e-banking pin numbers etc. The main executable is also capable of sniffing passwords from ICQ, FTP, IMAP and POP3 traffic.

This malware was modified from the "NumberedLinks 0.9" which is an open source Mozilla component available off the Internet. To the victim, he or she would only notice the "NumberedLinks 0.9" extension being installed

Minimum effort, maximum effect. Nice.

Saving the Appearances

News like this is a bit puzzling. The basic story is straightforward: nasty Chinese government wants to keep its people in ignorance to preserve the despotism, and nasty western (in this story, given the source, read American) firms are way too ready to help.

Except. Except.... I don't believe there's the slightest hope of it working. I can't see that anybody can believe it'll work. It's just bollocks. For certain Skype can censor keywords like "Falun Gong" and "Dalai Lama" and those words won't get through. But unless they are using something a lot better than our spam filters (among the best that money can buy), "F4lun G0ng" and "Da1ai L4ma" will work just fine. Is this just quaint? And for sure google.cn can slant its results (but not that much). The great firewall (it must actually be transparent proxy) can even put up polite panels explaining that such and such a site conflicts with government policy and is therefore blocked. But it doesn't matter.

The effect of the Internet is not to link poor confused foreigners to proper liberal western thought. I wish it was sometimes, but it's not. And I'm sure that there are plenty of people in the middle and upper levels of provincial and national PRC Party and government who imagine that a nice Middle Kingdom Internet without alien pollution and troublemaking would give all of the benefits and none of the trouble. They're wrong too. The Internet puts people in touch -- terrorists, racists, grey-haired security bores and the rest. It's such powerful communication that you can cut and hack away at it, and unless you shut it off entirely it'll pass ideas, rumour, gossip and news better than the world ever saw before.

The last twenty years of the Soviet Union were run in a state of hysterical denial. Everyone from factory foreman up all the way up to the all-union politburo was aware of the choice between muffled giggles and bare-faced lies. The self-confidence of the national intelligentsia had been undone in the sixties by a few hundred dissidents writing and circulating hand-copied and roneoed samizdat publications. Pretty much everyone in that key group went to prison and all that did was keep the lid on for a while.

Agile Deng, the octagenarian contortionist, dodged the fate of the USSR. The focus on economic development, dropping socialism while retaining the central position for the party, has diverted, as it was intended to, the art and skill of the whole nation. And a cultural entity as big as Han+Mandarin doesn't need to look outside much. Nonetheless, the basic battle has been lost. There is a middle class with weak or absent Party affiliations. Those people know they're smart, they know they've done something amazing, and they know the Party needs them more than they need it. And their communications are slicker than rubber stencils and biros.

They hardly need outside thought -- their own is dangerous enough. The corrosive, indelible idea: people like them should choose their own rulers, is there already. The rest, as they VoIP, email and blog, will emerge from their side of the great firewall, not ours. They may act this year. It may have to wait for a big shock: the coming bank failures, a corruption & incompetence scandal like SARS, too big to hush up, or even a failed military adventure. It may be a polite handover, stage by stage. It'll be Chinese, but the end result will be a multi-party state and a bigger and more frightening democracy than India.

And the Chinese network perimeter? It's just saving appearances. I doubt if anyone who works on it really believes that they can freeze or channel political thought. Sure sells a lot of firewalls though.

The Scent of 1995

This summary is not available. Please click here to view the post.

How Security Policies Fail (5)

Policy: No plain text password storage.

Failure: The real failure here is my failing to find words able to describe this. Maybe I should have written: "no encryption technology more than a thousand years old...."

Private Function Encrypt(strPlain As String) As String
    Dim i As Integer, j As Integer, n As Integer
    n = Len(strPlain)
    Encrypt = ""
    For i = 1 To n
        j = Asc(Mid$(strPlain, i, 1))
        j = (j + 33) Mod 256
        Encrypt = Encrypt & Chr$(j)
    Next i
End Function

Public Function Decrypt(strCode As String) As String
    Dim i As Integer, j As Integer, n As Integer
    n = Len(strCode)
    Decrypt = ""
    For i = 1 To n
        j = Asc(Mid$(strCode, i, 1))
        j = (j - 33) Mod 256
        Decrypt = Decrypt & Chr$(j)
    Next i
End Function

Why Perl?

It's looks like line noise, and if it was ever in fashion it's dropped out now. But Perl suits me, and I think this is why:

• Some people see the world as tables or XML -- I see it as text files with easy to parse lines
• Security does a lot of work with "fairly regular" data. (It doesn't seem possible to get the admins to stick to strict group naming conventions.) Putting regular expressions at the heart of the language acknowledges that the data are a bit dodgy.
• Security has many command line utilities that do roughly what you want. Perl runs external code, gathers output, skips the irrelevant bits and tidies up the good lines, all without too much pain.
• I've never written a right-first-time program in any other language. (I don't think I've ever written a right-at-all program in any language where I have to do my own garbage collection.)
• Languages that let me say what I want get my vote:

  $a++ unless ($its_time);

  foreach ( <STDIN> ) {reformat($_)};

Perhaps I'll grow out of it. Perhaps I'll just get frustrated with weak Windows integration. Perhaps I'll write that integration the way it should be done. Perhaps the Active State port will blow up once too often. We'll see.

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?

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.