Maxims

These (http://www.ne.anl.gov/capabilities/vat/seals/maxims.html) from the security team at the US Argonne National Laboratory are worth a three-day seminar...

Ouch!

As Fail goes, this one is a) personal and b) embarrassing.
Four years ago, just as I was starting this position, I met a recent contractor leaver on the train. In our conversation it emerged that he was getting email from his work account. I asked him how and he wouldn't tell me. Playful, but definite, refusal. I think he wanted to impress me with his skills. I checked -- with some difficulty, our logging is better now -- and his account was definitely disabled, the VPN accesses made sense, and I had a hundred other holes to fix, so I let it go. He was an honest man, so I was annoyed rather than fearful.
Now one of the things we fixed, as four years roll by, is the leaver process. Accounts are disabled on departure and deleted after three months and we have two independent cross checks to confirm that. Home drives and mailboxes are kept for three months for reference, archived, and deleted with the account.
So now, in 2009, we're looking at data leakage. I wrote a report to identify top correspondents to specific mail addresses -- looking for a John Smith sending two hundred mails a week to johnsmith8209@yahoo.com. To cut a long story short, I found what I was looking for, but I also found, way up that list, a leaver: left a couple of months ago. She shouldn't have been sending anything, but there it was -- all off to personal accounts -- several of them, apparently.
And this is my problem. We disable the accounts and log-off or re-build the workstations, but that doesn't -- contrary to all the assumptions of auditors and provisioning experts, stop leavers from running code. You can't disable an Exchange mailbox and so any server-side rules -- and yes, that includes forwarding rules -- will continue to run.
I don't quite know what to do about this.

• It's quite laborious to set up to remove rules from someone else's mailbox as outlook only displays ruls from the primary mailbox.
• The MAPI Editor lets you remove rules if you attach the box to your profile, but it's a complex tool with a huge capacity for mischief or misfortune, and anyway I'd really rather disable them.
• There are some gateway options, but they're very global, and I don't want a global ban (I might go for it though, if it's all I can do.)
• We could do the box early in the leavers process, but not instantly, and that's when I want the rules to stop.

It seems like there should be a utility -- point it at a mailbox and it unchecks the "enable" on every rule that forwards mail -- ideally, every rule that forwards mail to a non-local address. I can find documentation for Exchange 2K10 which has Get-inboxRule and Disable InboxRule. But twenty minutes with MAPI Editor shows me it may not be that easy.....

In Favour of Delinquency

Anti Virus software doesn't work if it's not installed, running, and updating signatures. What with one thing and another, it's hard to keep AV installed and running on every machine, and so we need a metric to manage by.

It's conventional to measure coverage: "90% of our machines have updated their signature file within the last week". The number and the age are arbitrary -- it could be 80% or 99% or whatever within a day or a month. (But it certainly seems hard to stay above 90% with McAfee....)

But I think coverage is an inadequate target, especially for servers. You have to watch it, certainly, but it's not enough. The problem is that a coverage report says nothing about how long machines are out of compliance -- you risk being satisfied that some machines never, ever, have current AV scanners. Imagine a network with a thousand machines -- if everything is up to date except for two file servers and and the DCs, then your coverage is over 99%, but your overall situation is not at all pretty.

Worse, coverage isn't a good guide to the best next action. Are you going to fix the agent on that critical server with its rare maintenance window? or patch up a couple of workstations? If you just want to get the coverage up you're going to choose the workstations, and you'll be wrong to do so.

Delinquency is a different metric. It measures the proportion going unfixed. It's the percentage of the non-compliant machines in the latest snapshot that were also unfixed at an earlier one, and haven't been fixed in between. The lower the delinquency the better -- a high delinquency means that AV installs are breaking and not getting fixed, a low one means that you are keeping up with the workload.

The levels I like are these:

• For servers, I think the delinquency should be zero, but the lookback period should allow for the time taken to get a maintenance slot on a server. For us, that's seven weeks. It's simply a claim that everything should be fixed in one maintenance cycle, so you can't leave those DCs without current AV.
• For workstations, some delinquents are acceptable. So we say 10%, with a lookback of one week.

It's not ideal. It's harder to compute as you need historical data. But it does tell you what to do first.

And coverage? Well, if you're fixing the breaks, it hardly matters. Like all metrics, delinquency can be gamed if it's your only target, so the best plan is to set something easy like 90% and leave it at that.

I Read Your Mail Headers

Nobody comments on the most obvious feature of the Interception Modernisation Programme -- the scheme to put intelligent sniffers in every ISP, funnelling anything GCHQ wants back to Cheltenham.

It's totally unauthenticated. Sniffers are purely at the network level. It identifies IP addresses, but not users. Without getting into the great "IP is [not] Personally Identifiable Data" debate, it seems pretty clear that this material will have to work pretty hard to prosecute anyone.

So it's just intelligence gathering? Pure snooping?

If You've Done Nothing Wrong, You've Got Nothing to Fear

So we're told. But it didn't work for Jacqui Smith.