Adsense

Running Adsense is more interesting than you would expect:

• I can speak freely, because I know that no-one -- literally nobody except me -- is reading this. That's not a gloomy observation based on absense of comments and feedback: It's hard fact taken from from the excellent hit records that Adsense provides. If I had a website (I don't), and I was lazy (I am) I'd put up an Adsense block just to get free analytics.
• The algorithm used to target ads is excellent. I know this because I keep wanting to click on them. In the same way that cannibalism ought to be the best diet, the adsense Ads on one's own blog ought to be consistently enticing, and they are (though I could do with a bit more hedging/forestry). It's really quite frustrating (Adsense subscribers know why).
  

That Google Account

Has anyone noticed how useful Google Docs has got lately? Obviously it's not Office 2003, nor Open Office 2, nor even Office 97. But I'm more and more finding it to be the natural home for my reference documents, drafts and other oddments. The collaboration features look interesting, and probably work well for all I know, but for me what counts is the accessibility from any of about half a dozen computers. Content search and tagging isn't a huge deal at the moment, but I know it'll save my bacon when the volume goes up, or when I upload all that stuff I used to keep on my Palm.

The limitations and problems are more and more obviously the consequence of hosting it in HTML. The tables reek (I do a lot of things in tables) but HTML tables do reek. Layout for paper is actually useless -- but I'm blaming the browsers.

And really, I find that there's a large slice of what I do where rough and ready is OK -- almost anything is OK -- if I can rely on getting at it from the computer I'm working on. That plan I'm working on in odd moments can only be a Google spreadsheet. I don't need a fair printable version of my CV, but I do need to be able to keep the copy up to date. And Blogger is a terrible place to hold draft articles like this one.

The security angle ought to be obvious. I set up my Google account so I could customise my searches, or something, and the password was some old joe job. (It isn't UMACF24, but you get the idea). By stages, stealthily, that same rotten password now defends:

• My email, calendar, and the management of my domain (Google Apps for Your Domain)
• A bunch of documents and plans (Google Docs)
• My Blog
• And probably other stuff I've forgotten.

I can change that. I'll have to allocate a "public site -- reputation/convenience" password now -- that's just one stage short of Paypal/banking. But, unfortunately, it's still just a password. And If I want to get the full benefit from Google, I'll have to use it on untrusted, bugged machines.

So, "Hey Google: It's time for a second factor!".

Christmas

Today I paid

UKL 50

to the cleaner

UKL 100

to the rat catcher

UKL 80

on a new gardening coat for Mrs U (Christmas present)

UKL 50

on Felco secateurs for Mrs U (Christmas present)

UKL 40

on petrol

UKL 20

as petty cash for Mrs U and a carer to take the darlings on an outing which they did not enjoy -- Mrs U will have paid a further UKL 60 to get in

Yesterday I paid UKL 600 for 1600 litres of heating oil.

The Rules

I turned down a system last month. It needed a user to be permanently logged on at the server console, which implies a password shared among the support team. The chances of that being tough and regularly changed are nil, so my vote was no.

We'll see if I can make that stick! But I'm content, because I've only applied a published policy. Project people think that security imposes strange and unnatural demands on system design, and I suppose it's true that the demands puzzle people. But they're not unnatural and they're not arbitrary -- just misunderstood. So as my contribution to public education, taken from the handout I send to project managers, support people and anyone I can find, here are the rules. They way I present them is a checklist -- tick every box and you're on the right track.

First we have the Exemption Checklist for changes and small implementations -- Tick every box here and I won't bother you:

• No file, folder, registry or mailbox permissions changed or created.
• System is explicitly permissioned by our standard groups and does not rely on “Everyone”, ”Authenticated Users”, ”All Users”, 0x??7, “Domain Admins” or ”Administrator” permissions to work.
• No Windows local or global or Unix security groups are created, deleted or changed in meaning.
• No impersonal domain user accounts (service accounts), or any local or Unix or special device user or admin accounts are a) created, b) get new group memberships or c) are admins.
• All human users and administrators use their regular personal Insight workstation or app/admin/Unix accounts, and there are no shared accounts, and no non-Insight users.
• No changes to external data transfers, network security configs (firewalls/acls) or external accessibility.

For larger changes, I need to hear about it earlier. Here's the standard advice for project managers contemplating a new system. Again, if you can't check every box, we need to talk:

First, how about Unattended Processing (UP)? That's any processing other than discontinuous console session on a user or administrator workstation.

• All UP is on a server platform?
  (Servers are physically inaccessible. Console access is only granted to IT support users.)
• All UP runs as a service or scheduled task?
  (Not on the console or in a terminal session.)
• All UP runs without administrative privilege?
  (Not as Domain admin member, nor as server local Administrators member, nor built-in administrator including Local System)
• All UP runs without a profile?
  (No requirement for logons using service a/c.)
• All UP credentials stored in Windows SC password store?

Then there's Authentication of Users and Administrators

• All work done with personal accounts?
  (No shared users)
• Users and administrators authenticate using Windows workstation domain logons?
• Users and administrators authorised by membership of domain global groups?
• No user or admin credentials stored?
  EG in scripts or config files. (DPAPI and SC list storage is permitted.)

And finally there's the Application Structure itself

• Admin privilege can be withheld from business users without impeding function?
  (Users are not admins -- we can keep admin functions on the support desk.)
• Conformable with our app access model?
  (Role/Environment groups allow us to manage permissions through the helpdesk, using standard tools)
• All resource access via application-specific group membership?
  (Excluding: Domain *, Everyone, Auth users…)
• Administrative and security events logged in a supported means?
  (syslog, ftp upload, Windows event log, text file)
• Will be supported on platforms kept patched up to date?
  (No vendor qualification of Windows patches)
• Documentation identifies all resource permissions, and sensitive locations
  (config files, private keys)?
• All Internet/external access via authenticated proxy?

Once every application can check off all these, we will be getting somewhere.

Hedging Strategies

This weekend, I have been mostly de-wiring.

The mad woman who lived here before us handled the increasing gappiness of the hedges by stapling stock fence on to the more solid stalks. Over time, the bark and wood grows over and through the wire, and new shoots tangle up in it. It becomes absolutely impossible to manage in the normal way: you can't lay the stalks over because they're tangled up in the wire, and you can't use the saw because it'll be blunted on wire or staple.

The only way out is to remove it and this is what I have been doing. You need to cut away the grown-through stalks (a terrible waste because they're the ones that would be easy and productive to lay) and lever out every staple and length of embedded wire.

I could have salvaged some of the stalks by cutting them out of the wire, but unfortunately the wire netting was in such good shape that my tightfistedness took over and I was determined to get it out intact. Which I did and in the process finally discovered how to use the staple remover on the fencing pliers. Instead of ineffectual whacking with the pliers in the hope of getting the hook under the staple, you position it carefully, and then smack the striking face of the pliers with a 3lb hammer. The hook leaps under the wire and you can lever the whole thing out.

Anyway, I've done a good old length, and while my arms are scratched up to buggery, I've salvaged some posts to weave into the lay, I'll be able to buy some chestnut pales to do the rest, and I can start laying next weekend. And I have the wire I'll need to keep the neigbour's horses from browsing on the new growth. (Why do horses prefer thorn bushes to lush grass? FIIK.)

Commuter 2

Today I found out how Champagne sales ladies sell lots of Champagne to restauranteurs.

The glamorous lady opposite me on the train home was working very hard and very loudly on her phone shifting cases of "Pol" and arranging visits. Normally I'm a bit irked by the louder sort of commuter, but she was charming: her blouse didn't even pretend to have any buttons above the bottom of her sternum, and her push-together bra was working as hard as she was. She leant forward every time she wrote down a sale or an appointment. Those visits must have been devastating.

Commuter 1

Today I popped out at lunchtime to buy a new raincoat. It was a bit cold, but I didn't really need it today.

During the afternoon it began to rain heavily. How splendid is that?

The Userid Con

Activity logs are good. We grant all sorts of access to staff "merely" because they can't do their jobs without it, and trust them not to abuse it. The way Ronald Reagan put this was "trust, but verify," and he was right. Audit logs are our verification. My first security effort here was to replace a shared admin userid with personal IDs, simply to make the logs mean something, and it's probably the most useful single thing I've done.

So, we configure the systems to generate logs, and we squirrel them away safely and the auditors and investigators are profoundly happy. But if we ever want to use them as evidence there's a little con trick we have to carry off first. That trick is called "User equals userID".

It's a con because it's untrue, and we depend on users not knowing it's untrue. Ask yourself, where you work, which has the worst career outcome a) "yes, I sent those emails" or b) "everyone knows I leave my password on a note under my keyboard"? If you're like my employers, admitting password sloppiness is going to go a lot better, especially if you've been doing the sort of thing people get investigated for. I sometimes wonder how many people have lost their jobs or reputation after assuming that logs with their name on were irrefutable evidence, when they could have hung on by saying that someone else was on their account. It must be a lot. I've seen this benign con work in environments where no-one even pretends to have a secret password.

Perhaps it's not totally grim. A single event may be deniable, but a pattern or a sequence of offending behaviours is much harder to walk away from. And a good evidence recovery can cause people to collapse when they are shown exact texts, pictures, times.

We can deal with this:

1. Let's look again at the rules on password sharing in the AUP. And,
2. I think it's time to dust off that plan for smartcard tokens -- they are hard to share accidentally.

But in the meantime, well now, I think we'd better keep this to ourselves. Otherwise, there'll be a password under every keyboard in your firm.

Authentically Spooky

Well, I was walking home along the lane last night -- I'd just passed a batch of trick-or-treaters -- when I heard a cat calling. I couldn't see it though, until we passed the neighbour's lamp.

I crouched down to stroke her and ask her name and she circled me, rubbing my legs and crooning. She was big, black and shiny, the blackest cat I ever saw, with yellow eyes and she liked me enough to follow me home.

She was through the door as soon as it opened and making herself at home nosing around the kitchen. Mrs U fed her but drew a line when she started to explore the beds updstairs. The kitten scarpered, the more mad cat maintained a glaring distance and Fleabag just kept out of the way. I canvassed the lane, but no-one knew where she came from. I made her a bed in the freezer room -- warmer than it sounds -- and put her in it so she knew where it was, but I don't know if she stayed.

For maximum Halloween effect, she ought to have vanished by morning, but at 05:10 she picked me up by the gate and follwed me down the lane and halfway across the field, calling all the way. I hope she goes back indoors.

Commuter

Just north of Sevenoaks this morning I was looking down to the southeast and I saw a rare sight: pre-dawn colours in a clear sky. The whole range from sodium orange at the horizon up to space-black in the zenith. I wanted to wake up the whole carriage, rip away their newspapers and tell them to look at the world. But then we went into the North Downs tunnel and when we came out the sky was was a rather tasteless cream and light blue, so I left it.

And anyway, it would have been eccentric.

Criminalise Your Enemies.

Is it strange that so much WAN traffic is unencrypted? That became a live issue for me when we were setting up a new recovery facility. Part of the project includes links between the machine rooms, and the service provider offered us a significant cost saving by using their network to replace a hop that would cost tens of thousands ordered from COLT. Everyone was happy except me. I saw it as a tap risk.

I hate taps. A network tap is one of the points where the balance tips in favour of the attacker. They are totally stealthy and very reliable. They can be serviced by a leave-behind -- a laptop running Ethereal or TCPdump with USB disks exchanged whenever the access can be had. The only real problem the attacker faces is getting access to a good network segment -- plugging in to a workstation LAN and risking an ARP spoof is going to get some user passwords, and that's not bad, but it's not the key to the domain.

But a trunk between machine rooms is another thing entirely. Modern domain traffic ought to be harmless if overheard, but console sessions on to the DCs, SNMP strings, enable passwords on switches ... One way or another, it's the place to be if you want passwords, not to mention seeing what the fileservers see.

So, OK, taps are bad. But is it any more risky to run our traffic over a service provider's network? The contract gives them a duty to keep our data confidential, and you won't find that in a service agreement from BT or COLT.

The short answer is the criminal law. Between the termination points of section 8 licensed telecoms providers like Colt and BT, special law applies: I think it's the Interception of Communications Act 1985, but anyway there are criminal penalties for tapping their systems without a warrant. They can't even do it themselves, and that's why there's no confidentiality in the contract.

The point here is not so much the penalties but the criminal liability. Evidence of a crime -- and an unexpected laptop stuffed with traffic logs is evidence -- lets the police investigate. Serious industrial spies always seek to operate below the radar of Babylon, and that makes for real protection.

IoCA is protection, but it's limited. It doesn't stretch beyond the endpoints. If we found a tap on the service provider's network, we could remove it, but no crime has been committed. To get any recourse we would have to mount our own surveillance and investigation, and that is a place I don't want to go.

We're sticking with the service provider's network, but some of the savings are going on hooking it through our firewalls with the encryption turned on.

Fingered by the Make-up Girl

It appears that Italian MPs have been tricked by a TV show into submitting sweat samples. The samples were analysed to show that a large minority had been taking what local law treats as drugs of abuse. The gimmick is that the swabs were taken as the dupes were being made up to quote opinions on camera for a fake documentary about the budget.

It would have been more fun to ask them their opinions on drug abuse. It doesn't take much insight into the political mind to speculate that those opinions would be pretty uniformly negative, regardless of the blood THC level.

If you live with integrity -- some degree of consonance between words and actions -- it's easy to laugh at those poor mugs. They must be sweating more than ever now. The trouble is that the effort that goes into keeping us honest drains the fun out. We're prigs and bores. There's no help for it. Each one of those men will be better company than me, and his children will love him more. We should protect them, not laugh.

And the question has to be, whether anybody other than the police has the right to gather that sort of history, the evidence that we are all scattering more widely and more unconsciously: DNA on the laundry, web browsing at the ISP, fibres on the trousers, drug abuse at the barber's, traffic histories and mast use on the mobile, spending on the card .... What will trip you up? Is being too dull to notice the only possible defence?

Commuter

Coming home yesterday evening I watched in the twilight as the mist off the river poured through gaps in the grown-out hedge and evaporated in the warm meadow. But now heading back the other way, everything is cool and there is a deep silvery blanket shining in the bright moonlight.

H. Sapiens

On Tuesday I was working with the owner of information risk on the information security policy. She's a jew and we were talking about her reflection on the day of atonement just gone. I was, and am still, upset by the stupid emails I've been reading as part of this current investigation. Jewish spirituality has that ancient focus on the ethical value of mindful compliance with God's law, and she compares that with the chaotic response of colleagues to our sane and reasonable policy, or even the idea of policy: "Everyone would much happier if we just obeyed the rules and got on with the fun stuff ....."

I know she's right, or at least I agree, but there's something else too, and as I groped for the words to express it, I looked around the open plan office and for a moment my vision changed. What I saw then was a colony of great apes, that third chimpanzee species, created by language and bipedalism on the journey from forest to office, but still the same animal: obsessed with rank and sexual display, endlessly inquisitive, endlessly communicating and endlessly systematising. And utterly unconcerned about rules that try to stop us being what we are.

When we accept law, we defy our own natures. Against resistance like that, the policy of the IT security ape is so much desert wind.

Chain, chain chain

I've been collecting MTA logs from one of our Exchange servers. They're one of my favourite logs -- a little forbidding at first, but yielding mountains of information if you put in the time. I forgive them for breaking the mapping between text line and event. Browse them on the tracking.log share, and view in a decent text editor with word wrap off.

Now these logs are valuable, at the moment. That's why I'm collecting them -- they may be required to prove a point in court. So I want to copy them off the share and put them in a safe place. But that's not enough. What's to stop me editing them after the fact to show anything I want to show? Enough care with dates and formatting would make it the devil's own job to prove that I'd fabricated the record, and it's that capacity to make a perfect forgery that lies at the heart of the problem with computer evidence.

What courts want is swearing, and plenty of it. Each step of the chain needs a claim that can be fairly made, on oath, that the data passed on, is the data received.

The traditional method would be to print out the file and sign and date every page. That signature isn't the oath that would be made in court, but it's the basis on which you could swear that oath: "yes -- I signed it that day, so that must be the printout I had on that day." If you didn't sign it, how could you be confident enough to swear? After all, one printout looks much like another. Computer people laugh at this as a defence against forgery -- if you were planning to fake it, surely you can lie about the date too? but in fact courts are using an important tool here. It's consistency that makes lying difficult and it's inconsistency that lawyers concerned about the quality of opposing evidence seek to expose. By signing and dating, you are offering up a hostage to fortune, secure in the knowledge that no inconsistency can arise because this is actually what did happen.

Now these log files are a hundred thousand events long and I am not printing them out a) because it would be nonsensical and b) because it wouldn't help anyone. Whoever's going to check?

This is what cryptographically secure hashes are for. If I can vouch not for the file, but for the hash value, the chance of a subsequent modification being meaningful and preserving the hash value is negligible. So, every day I use Microsoft File Checksum Integrity Verifier -- FCIV. In a command shell, I run:

FCIV -sha1 \\EX1\tracking.log
(this prints a line of hash for every archive)
copy \\EX1\tracking.log\*.* h:\myarchive
FCIV -sha1 h:\myarchive
(will give the same values above)

Then I print off the transcript and sign and date it, transforming a bunch of editable files into a record that is set as if in stone. Anyone who cares can take my copy of the data and check it against the printout theselves in a minute or so. All the colossal contingencies boil down to a single question: did I fake my signature? and if so how is that to be shown? Since I didn't fake it, I should be OK, and so will my evidence.

Business Continuity (Because it does continue)

It seemed appropriate to spend the day looking over the new DR site. Unlike the current site, it's a long way out of town and the reason for that is five years old.

No particular agenda. Joined in one of the project meetings, nosed about the machine hall, asked about the physicals. Really, all I need is for the team to know that I care, that I'm interested, and to hear me praise what I can.

Because I haven't been praising it all. I've been in this role two years, and still people offer me solutions which are absolutely barking. This lot wanted to run plaintext ethernet through the switched infrastructure of the DR supplier and install our servers and network in cabinets in the shared machine hall. We're getting a cage, screed to screed, and the supplier's LAN is a red network.

What Security Angle?

We're just starting a weekly reward scheme for the less mad son -- he gets a trip to the pool or the pictures, guaranteed, if the week's Kumon has been done without too much pain. So we went to see Cars.

It's good. Better than Nemo or The Incredibles As good as Monsters Inc. or Toy Story II though less dense than either, and perhaps that's just total confidence peeping through after fifteen or twenty years.

I'm a simple person, and I loved the jokes -- the scenery, the governor of California (was that a cameo?), casting Jeremy Clarkson as the odious Harv, and I suspect I missed a bunch of stuff in race organisation and commentary. And the story was heartwarming if somewhat daft -- my heart is perennially cold and I like it warmed up.

One thing that struck me was that the animators are just showing off now. There's a logical next step coming, though I don't know if Pixar will take it. Somebody's going to make a movie where animation is a detail of the production -- not chosen to create a fantasy world or to let the characters do impossible things, but simply because they can't be arsed to deal with real actors and locations, and the audience won't notice the difference. I wonder what it'll be? (Hope it's not porn -- that would be sad.)

The Cost of Secrecy

I've been keeping a secret for a few months now, but it's not a secret any more. All very banal -- just the sale of a division that needed a separation of of computer systems before the announcement day.

That day has come, and suddenly:

• I can talk to the technical staff instead of asking their bosses to guess
• I don't have to figure out compromises between approval policies and the need to keep the authorised approver in the dark.
• The helpdesk don't think I've gone mad.
• I don't find myself as the only person with the rights, skill and clearance to carry out a whole bunch of mundane tasks.

I know that there are sometimes good reasons for secrecy. And despite there being fifty-odd people on the list at the end, it didn't get into the press, so it was a success. But it was not cheap.

I'm guessing now, but I think that the human budget for a task that has to be carried out in an organisation that can't know what's going on needs something like a 50% uplift to cover confusion, error and unskilled staff. Try justifying that.

The UK is a Nest of Hardened Criminals

I'm not sure how many times I broke the law last week. It must be hundreds -- I did it eleven times just now.

I've bought a music player and I'm ripping my albums. (It's a Samsung -- Ogg Vorbis is definitely smaller than MP3.) The law in the UK specifically provides for sound recordings, a CD is universally acknowledged to be a copyright work, an OGG (or an MP3, or WMA) ripped from it is obviously a copy, and copying infringes the Chapter II rights of the copyright holder. None of the Chapter III permissions applies, and it looks like I'm bang to rights -- up to two years in the chowkey. I have checked and there's definitely nothing in the act about "unless everyone is doing it, in which case it's OK."

I could call the police but I'm afraid they'll laugh at me. I could call the BPI, but I don't think they'll care either.

There are two ways to look at this. We can go with the BPI and say that it's an anomaly that needs to be cleared up. Or we can face the fact that intellectual property, so called, is so different from property that concepts like theft just don't work, and change the law accordingly.

In the meantime, it's fun to watch Samsung, Microsoft, Dell and all the other keeping mousy quiet and hoping the whole issue will go away.

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.

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.

Infiltration

I finally got frustrated with the speakers on the attic PC, so I dug around in the garage to find an old Altec Lansing set -- two desktop speakers, and a floor-mounted powered subwoofer. It all smelled a bit mousy, but everything in that shed does. Got it indoors, wiped it down and set it up. The sound was no better, but the smell began to get much, much worse.

To cut a long story short, they were in the power supply. There were just the two corpses, and I think the rat poison got to them long before I powered it up, but piss, decay fluids, oak leaves, shredded rag and half eaten acorns made a fine combination. The sound tubes were a convenient mousy route in and out. I opened the box, cleaned it out with meths and an air duster, put it all back together with sticky pads to replace the anti-rattle composition and the smell is much better now.

Still have to fix the audio quality.

New Blog

Why UMACF24? Easy -- all the good names were taken. Classic late adopter syndrome.