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.