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?

Obvious Really

I'm not interested in concealing my identity, exactly, but I don't put my real name on these because any security writing that uses real-life examples will sometimes be about Fail, even if it's Fail rectified, and who wants to go public about their own employer's Fail?

Even so, I've always been circumspect about what I say because I've felt that the intersection of the things I talk about -- Kent, Finance, Computer Security, Old man -- is going to be a pretty sparse set. Anyone who cares could find out who I am.

So it's interesting to see Schneier blogging about some research from PARC. Apparently the end-points of a regular commute are sufficient to identify a huge proportion of people. Pretty much all that required is that the granularity is fine enough for people to be working in a different zip, county or whatever from the one they live in.

I'll be more careful in future. I have a plan.

Classic Fail

Went to pick up my printout from the printer and there it was: The biggest secret in the firm, and one from which I am firmly excluded. Ninety colour pages which someone had collected, collated and left prominently displayed to be picked up.

A few minutes in the event log of the print server gave the answer -- the same document printed twice in succession: the signature of a user losing track of what they've done. He's back on track now.

The report had been out on display for thirty minutes when I found it. I imagine the person who tidied it up will be one of the three people who used that printer between me and the inadvertent leak. But who else saw it is much harder to tell.

How Sweet

This is mostly a funny story. "Now, boys, you are getting F grades at school for the exact same reason that you probably shouldn't bother trying to hack into the systems to change them..... "

Perhaps it's wrong to laugh. The Sumitomo hackers were prosecuted with evidence gathered by the spyware they left behind. Keyloggers are two-edged swords.

Chinese Hackers are Real, I Tell You...

... And they're planning to flood the world with cheap telephones.

Al sits close to the Head of IT -- a position that reflects his operational centrality, and the affection in which he is held. But he came to me with a puzzle about his Hotmail. It seemed that he'd managed to send himself, and all his contacts, an email advertising http://www.feixiangyu.com -- an electrical distributor.

Well, we looked at things like his spam folder, and whether it was just in fact a particularly artful non-delivery notice. But soon he had replies from his contacts congratulating him on his new business venture.....

Now the beauty of Hotmail is that it's easy to attribute. The X-Originating-IP header gives just that -- the IP address of the originating computer, which is the IP that Hotmail saw as the browser that "got" (GETed?) the send links. This one was 123.53.119.162 and Sam Spade plumps that in the middle of the Middle Kingdom. The ISP is Chinanet, and the PoP is Zhengzhou -- capital of Henan, a respectful distance from the Yellow River -- seven million people in a few square miles, and at least one dodgy marketing guy.

On the whole, I'd rather be hacked by Chinese shopkeepers than the Russian Mafia -- you're less likely to have your bank account emptied. I told Al to change his passwords, check his bank statement, and run an online AV check on his home PC. I sure hope that shows something, otherwise I'm going to have to wonder whether it happened on his office machine, and that's something I just don't want....

Grepping the IE cache

I had to do an investigation the other week. I'm not an investigator and so naturally I screwed up. Here's what I learned.

Complaint was that some abusive hotmail-sent mail had arrived quoting the outside address of our firewall. After a bit of to-ing and fro-ing, I was allowed to see the headers, and that told me a good deal:

• Hotmail does indeed quote an originating IP in the header. Who knew?

• The earliest relay in a hotmail relay list is a name like bay99fd.bay99.hotmail.msn.com. Any hotmail user knows that the bay appears in the URL on the hotmail home page and throughout the user interface. And for any particular account, that bay number is fixed.

• Timezones were going to be a problem. We were in local DST, the victim's mail infrastructure was in their DST and four hours behind, his MUA was working in another zone still and a lot of the Hotmail infrastructure is on Pacific time. Still, given headers, I could convert everything to UTC easily enough.

OK. Time to see if we can knock this out in a single step and get back to proper work. The Log appliance appliance has been gathering proxy logs all year. We're a pretty relaxed site and I've not been asked to report on usage of a named site before, so I have to code up a report with wildcards for client IP, domain-name and the page name. A bit of experimenting gives me a report of access to that Hotmail bay.

Now this is the first place a real investigator would have done it differently: First step should have been a summary report of all the users of the bay over the last three months. That might have been enough to get HR off my back. As it was, I spent a week dipping in and out of the proxy logs data to look at alternatives as the mails emerged from the complaining firm.

That initial set of headers fingered a single user. I could only see two users of the bay, and at the right time only one of them was active. And guess what? Within the two-minute precision of the log upload batch, he used pages on the bay called "compose" and "premail". A bit of experimenting with my own hotmail showed that that is the characteristic signature of sending Hotmail.

This is the second point I did the wrong thing. I've got a budget for investigations and I should have used it. For UKL 1,000 + expenses and VAT, Kroll Ontrack (it used to be Vogon) will send midnight engineer to take a swearable image of a workstation hard disk, leaving you with a handy USB disk copy for your own investigation and the user none the wiser. I was focussed on our local, more rough and ready process, which was a bit too public for HR. It wasn't a total screw-up though. I'd only looked at proxy logs through a read only interface -- I knew enough not to touch the workstation, and so the purity of its evidential status was preserved, even though the Internet cache timeout was ebbing away.

Part of the delay was at the far end. HR can't and won't do anything on a complaint like this without the offending text, and the complainer was a bit coy. HR's reason is good: it might not be offensive in our context. Still, I thought it was a bit silly -- the headers showed that the hotmail address was obviously a real name, and not the name of our user, and he is, or was, a regulated person.

In the middle of that argument, I got a second set of headers for a much more recent mail. Same accounts, same bay, same user matches.

It all went a bit off course at that point. What I got next were not proper headers with that incriminating source IP and lovely times plainly referred to UTC. It was the nesting of headers in the body of a reply/forward dialogue, and the "on" times there are converted into the time of whoever received the mail. By that time, I was so focussed on matching the time to activity on the proxies that I set to work trying to infer the timezone of each recipient and reconstruct the offenders side of the dialogue. A proper investigator would have realised that this exercise was difficult enough to make uncertain results, and insisted on headers or nothing. As it was, I made mistakes and spent a lot of time wondering how the original mail could have been sent when our target definitely was busy and wasn't on Hotmail. I went as far as trying to rope in the other user of the bay as an accomplice -- that didn't work either. Looking at the times again, I can se my mistake: It wasn't five PM, but seven, and the mail was sent from home.

I'm not privy to the discussion that went on in the business. It's called reputational risk and I guess we were asking the board to trade a reputational compromise with a non-customer against possibly losing an expensively-hired fund manager and telling his customers that their money had been in the hands of a stupid person with weak morals. Glad I don't have to make that choice, but they did the right thing and I was told off to get the dirt.

The Kroll visit was simplicity itself, mainly because I didn't have to stay up all night -- the HR guy did that!

Lunchtime next day I got an urgent package with a 40GB USB hard disk which mounted first time on my non-build laptop. That was another mistake -- if I'd used a Linux laptop, or a regedit fix, I could have controlled the mount to be read only. It didn't really matter as the forensic copy is on Kroll's servers -- the supplied disk is just a playpen. The idea is that you hunt around any way you like, but any defence witnesses or advisers can still work with a guaranteed untouched copy.

This is important -- a lesson I learnt long ago. Never give in to the temptation to take a quick look at a workstation via the admin shares or however. Unless you are collecting them automatically, don't even look at the event logs. Right at the beginning of any question, figure out -- ask -- if there's any possibility that anyone will be held to account for what you uncover. Consider whether (for example) you could work from restores, or with a reporting tool. Tell your interlocutor that if it's possibly going to get as far as swearing evidence, you are less likely to be overturned if you work throughout with a trained investigator.

If you really have no choice, make sure you get a crytographically secure hash of each and every file you access. Make it clear in your notes that you obtained the hash before looking at the file. Print the hash out, note the time it was obtained, sign it and date it. Make sure that the file you keep will generate the hash you print. That way you can swear that it was that way when you found it.

However. I had a scratch copy of a workstation disk and I could do what I liked. There are tools for this sort of thing and I ain't got aught of 'em. Not necessary at my level. You can download an excellent Windows grep from the FSF and anything else is overkill. Remember to put the GNUWin32\bin directory in the path.

With the disk mounted, you'll find the IE cache is at (name changed to incriminate the innocent)

\Documents and Settings\umacf24\Local Settings\Temporary Internet Files\Content.IE5

Make your way there in the command line and issue a carefully chosen grep:

grep -irl madeupname@hotmail.com *

will search for the address in all the cached files in that directory. That matters because hotmail puts the logged on account on every page, so you can see right away whether the user has actually been active on that account -- the one thing the proxy logs can't give you. Those options mean: -i case insensitive, -l list the matching files (as the content isn't much use, as text) and -r recurses down the directories.

I was surprised to find that the IE cache went back a lot further than I expected. It looks as the the "retain for n days" setting only takes effect if space is tight -- this man's cache went back months.

Now the beauty of the IE cache compared to Firefox is that there's no complicated database format. The files cached are the files downloaded. Names are modified, and there's a directory structure to avoid having one huge folder, but the pages can be displayed in the browser. I have an account which doesn't have Internet access, so using that account, I just started IE and browsed to the appropriate files. It was one of my happier moments to see a hotmail folder listing -- looking a bit dodgy, admittedly -- listing times and subjects of the complained-of emails. Access to compose pages actually gave me content of mails which the complaining party had been relectant to reveal. I gather that the colour prints of those pages were particularly unsettling when the confrontation occurred.

I can't write a story like this without a few lessons.

• Serious investigation would have been overkill. We didn't need deleted files, we didn't need to to search for concealled media or executable content. It was just those emails

• Think. Of course he was doing it from home.

• Ask for what you need. I needed headers.

• Don't be afraid to search a PC. I've bought an imaging machine so we can do our own. I could have got those unarguable Hotmail reconstructions much earlier and saved a lot of time.

• You want to keep proxy logs for ever. The depth of context is invaluable when you need to do a lot of learning about what your users get up to.

• Remember that users can't protect themselves. Using gmail over SSL would have made this offence effectively uninvestigatable without bugging his PC. But who knows that?

Good luck to you

Himmler Murder Memos in the NRO

This story in today's FT magazine is interesting in its own right, but it makes a good security story as well:

1. Don't despise paper. Everyone quoted in the fake memos is dead, the empire they served is one with Nineveh and Tyre, and the record-keeping system was obviously not designed to detect this fraud, but the fakes can still be totally discredited. There is no shadow of a doubt that those notes are inauthentic, and the rest of the bundles they came from are real. What's the IT angle? Well, consider what you can prove with a signed page of printed hashes....
2. The sideband rules. Laser printing on a document that purports to be twenty years older than xerography. Every suspect document having the file hole torn. These circumstances talk directly to the investigator.
3. Listen to the language. The public school types who ran the war didn't talk like that and they certainly didn't write like that.
4. Keep access records. One man only, ever, was recorded as accessing all those bundles....
5. And of course, follow the motive. He wrote a sensational book...

Terrorist Spies

I found out whether I believe in evil terrorists reconnoitring for their next target.

Rather to my surprise, it appears that I do.

At 06:50 I saw a clean-looking man in a hi-vis vest photographing an iconic tower, leaning back to get the upper parts in. After a few shots he hopped into a clean-looking, unmarked refuse lorry waiting at the curb and his mate drove him away. The photograph, the building just didn't hang together with the refuse lorry, and everything was really much too clean, so I noted the number of the lorry, and when I got to work, I wrote it all down.

I wasn't too happy with claiming that it was a terrorist planning exercise, though, so I tried it on a few people to see how it sounded. But I couldn't persuade myself it was even slightly normal and so I dropped it on the Met's reporting site.

Am I perhaps an hysterical old bat?

Swirl/Unswirl

Here's the Interpol (rare to see a .int domain) release on operation Vico. That's impressive work by the image experts, but I think the credit lies with the investigator who had the imagination to see that information was still there and the thing was worth trying. That's the leap I would have failed to take, and it's the difference between a proper investigator and the guy who looks at proxy logs.

After red-eye reduction, obscuring faces is probably the second most popular use for home image processing, the home porners generally botch it, and I've often wondered why packages don't include a better tool. Perhaps they can't find a suitably euphemistic name. Anyway, I suppose we'll now see a slew of unswirl tools.

More GNUWin32

Just a quicky. If you need to dump a raw disk on windows, you can do it with the GNUWin32 dd(1) program. But

dd if=d:

won't work. You need a little sprinkle of stardust with the device reference:

dd if=\\.\D:

seems to do the trick.

In the Raw

Just as a glimpse of on-the-fly development to satisfy investigation needs, here's a hack using James Macfarlane's Windows registry parser to get a timeline of registry key timestamps.

This is a source code module -- no DLLs -- and so even though I've never been able to get ActiveState PPM to install CPAN modules, it's easy to set up. Just download, open the package and drag the components into the corresponding directory locations under C:\perl. Why not use TieRegistry or something? Because we need this to work on "dead" files and the Windows API won't do that. The extra benefit is that this will run on Linux.

Only remaining frustration: there doesn't seem to be a timestamp on values as well.

use strict;
use warnings;
use Parse::Win32Registry qw( :REG_ );
my $time_fmt = '%04d-%02d-%02d %02d:%02d:%02d';

my $usage="$0: hive_file_name\n";
my $fn=shift or die $usage;

my $registry = Parse::Win32Registry->new($fn);
my $root_key = $registry->get_root_key;

my %keytimes=(); 

sub keyinfo
{
    my $key = shift or die "no key to recurse";
    my $nm = shift or die "no name";
    my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=gmtime($key->get_timestamp);
    $year+=1900;$mon++;
    my $ts = sprintf($time_fmt,$year,$mon,$mday,$hour,$min,$sec);
    $keytimes{$ts." ".$nm}=[$nm,$ts];
    my @subkeys = $key->get_list_of_subkeys;
    foreach my $subkey (@subkeys) {
        keyinfo ($subkey, $nm."\\".$subkey->get_name);
    }
}
# Main execution starts here
keyinfo($root_key,'.');
foreach my $keytime (sort keys %keytimes) {
    print "$keytime\n";
}

Dumphive and the unicode registry strings

The handy dumphive utility will list out registry and SAM files, but a lot of the content is left as unicode strings represented as octet sequences like this:

"\\DosDevices\\E:"=hex:5c,00,3f,00,3f,00,5c,00,53,00,54,00,4f,00,52,00,41,00,\
  47,00,45,00,23,00,52,00,65,00,6d,00,6f,00,76,00,61,00,62,00,6c,00,65,00,4d,\
  00,65,00,64,00,69,00,61,00,23,00,37,00,26,00,31,00,66,00,65,00,39,00,65,00,\
  35,00,63,00,34,00,26,00,30,00,26,00,52,00,4d,00,23,00,7b,00,35,00,33,00,66,\
  00,35,00,36,00,33,00,30,00,64,00,2d,00,62,00,36,00,62,00,66,00,2d,00,31,00,\
  31,00,64,00,30,00,2d,00,39,00,34,00,66,00,32,00,2d,00,30,00,30,00,61,00,30,\
  00,63,00,39,00,31,00,65,00,66,00,62,00,38,00,62,00,7d,00

Well, you can pick your way through that with an ASCII table, but here's a bone-headed script to get the gist out.

use strict;
use warnings;
my $av=join(',' , @ARGV) ;
foreach my $c (split(/,+/,$av)){
    if (my $a=oct("0x$c")) {
        printf "%c", $a;
    }
}

It would be cooler to read the blocks directly -- backslashes and all. Maybe next time. Anyway, all you have to do is figure out what

\??\STORAGE#RemovableMedia#7&1fe9e5c4&0&RM#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

means.

Computer Investigation is not about Images of Children. Mostly.

This is just a rant really. I can't justify what I'm going to say, but it's been growing on me for a long time, and some publicity material at Infosec tipped me over. (You'll have to forgive me some circumlocutions, as I don't want to skew Adsense towards the P-word.)

As far as I can see, the whole field of computer forensics is obsessed with sexual images of children.

Is that fair? The material exists, and is just as vile as it seems, or worse. It fuels hideous organised violence and abuse. And the investigators are, after all, sincerely trying to shut down the obnoxious trade. So what can I object to?

I object to the way the topic is used.

• Used to stifle argument: "We must accept any invasion of privacy, because otherwise an abuser might not be punished (which is definitely not a matter of police convenience -- oh no.)"
• Used to garner prestige: "My work helps to protect society from this filth (and is definitely not one of the duller branches of system engineering or forensic accountancy.)"
• Used casually -- it always seems to be the first example picked.

I'm not an experienced investigator. But I've done a few, and everything I've done has been related to the text, dates or addresses of documents or email, or activity from attack tools. I've never so much as once had call to open a JPEG (GIFs as web design elements are another matter...)

Bridget Jones called it mentionitis: when fascinating topics — even un-admitted ones — keep cropping up. That was fiction but the effect is real, and I think it's what's happening here. So this is the challenge: if you are writing about computer forensics, lay off that area.

This stuff exists. It's a danger to my children. We're all against it, and some people have to investigate it. But there's no need to let it take over our un-thought thoughts. It's never necessary. If you want to talk about file types and signatures, take examples from Excel accounts disguised as DLLs. If you want to talk about image content, talk about copyright violation, or even voyeurs. If you want to talk about the rewards of the job, talk about the email bully forced to apologise. You'll feel better for it.

Triple A

We have Authentication, Authorisation and Accounting. And the least of these is Accounting, because no-one bothers about computer time these days. But its presence in the triad reminds us that username and password authentication dates back to a time when the only reason to log on was to select the account to be billed for your FORTRAN session on the teletype.

Using a password to prove identity is a later loading of this basic idea. Which is why it doesn't work.

Going to Work in the Dark Again

You don't have to work with audit logs to be a GMT bigot. But it helps.

Light Feet on the Drive

OK -- the scenario is that you really, really want to know what's on a Windows workstation hard drive -- you plan to look in the IE cache, system logs, registry, SAM, etc. You can't/won't be arsed to image it and work on the image and you are not going to take this rather urgent moment to learn about excellent Linux based tools. But you do want to take all reasonable precautions. (What's reasonable? I'm less sure than I was after reading this document. It's a normally reliable source, but the example scenario contains an eyepopping amount of work on a live system. Maybe evidence rules are different in the States. My approach is to kill the disk and only ever read from it.) Here's the plan.

1. Prepare an investigation machine. You need a computer with Internet access where you can work privately. You also need a USB disk housing that will fit the disk in question. Maplin do an IDE/SATA for 3 1/2 inch disks, while 2 1/2 inch laptop disks still seem to be small format IDE and there are lots of housings for those. Since we really don't want to write to the evidence disk, run the Read Only registry file below, and test that you can't write to a scratch USB device. Load tweakui (Microsoft Powertoys) and make sure that you're not set to autoplay anywhere to reduce the risk of malwaring your investigation machine.
2. Give the job a name. The Remedy number, "2007 02 Hotmail Complaint" -- whatever.
3. Get a chain of custody log. The idea here is that you have a collection of evidence for the investigation, and as you collect each item, you sign it out and and back in when you return it. so that you can swear to where anything was at any future tribunal.
4. Get a log book. Or open a file, or something, anything where you can write everything down. Computer records are good here as you can paste in log entries and images. Finish each day with next steps so you don't forget, then print the day's record, and sign and date each page. Enter it into your evidence store.
5. Pull the power on the workstation. Record make model and serial number. Remove the disk, and record the make, model and serial. Put this diskless carcass into your evidence store with a label that says "2007 02 Hotmail Complaint Exhibit A". You shouldn't need to boot it, but you never know. Anyway it's evidence.
6. The disk is Exhibit B. Log it, and sign it out to yourself. Mount it in the USB housing. Check that you've run readonly.reg on your investigation machine. Plug it in and make sure it comes up on you're investigation machine. Don't let it auto play.
7. Where you go now is up to you. Check the tools below to look at Windows file contents, and there are others to look at file times.

Read Only.reg

Create a file called readonly.reg using notepad. Save it on your desktop. The file contains just these lines:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000001

Double click on the file and confirm you do want to load the settings. Then test on a scratch USB stick -- you should see a "Write Protect" warning come up when you try and save something. To get back to read/write you need another file with that last dword set to 00000000.

Read Event Log Files

The log files you want will be in d:\windows\system32\config\ assuming d: is where your disk is. Sometimes you can load the .evt files from the subject disk into the log viewer. I find that it always says they're corrupt though.

So I use Activestate Perl, add the Parse::EventLog module and a few lines of code to list them out into an easy text format. Here's the code -- you'll want to tweak it.

use strict;
use Parse::EventLog;
$|=1;

my $elogfn = 'd:\\windows\\system32\\config\\SecEvent.Evt';
print "Loading Event log: $elogfn .." ;
my $elog = Parse::EventLog->new($elogfn);
print "..loaded\n";
my %c = $elog->getOldestEvent();
while (%c = $elog->getNextEvent())
{
  my $str;
  if ($c{Strings})
  {
      $str = join('|', @{$c{Strings}}) ;
      $str =~ s/\t/\\t/g;
      $str =~ s/  / /g;
  }
  my $evt = $c{EventID};
  my $time = localtime($c{TimeGenerated});

  my $ msg = "$time: $evt <$str>\n";
  print $msg unless grep({$_ == $evt} (560, 576, 515, 600));
}

The good bit here, is that this will work from a Linux machine just as well as Windows.

Read Registry and SAM files

The most amazing thing thing I've learnt recently is that the SAM is in the same format as a registry hive. This means you can use this tool to print out the system registry and the SAM (from d:\windows\system32\config\) as well as user registry from ntuser.dat in the appropriate profile.

You should also be able to use Parse::Win32Registry though I haven't done that. It would work from Linux, too. There's scope for a useful script here, as the SAM is in a desperately unhelpful format.

Investigate That!

When you have to investigate a PC, there's the ideal approach, and the actual approach.

The ideal approach calls in a firm of investigators -- I use Kroll Ontrack as the sucessors to Vogon. They send in an engineer to take forensically sound images, and retain them on their systems until they can schedule an investigation to answer some of the basic questions. Two weeks to get there, and then further rounds of questions and answers ending in a report. Meanwhile you have managers wanting answers.

So there's the actual, otherwise known as DIY. Everyone does this sometimes, so here's a few pointers to protect your arse.

1) Give Babylon Her Due.

If this is one of the cases where the police need to be called, then you must do that. You can't be ordered to conceal it by your boss -- your duty as a subject trumps your duty as an employee. Definitely talk it over with a sane advisor who's familiar with the situation, but if it's ugly then you have to give the cops the option. Don't go mental about this: for certain spyware breaches the Computer Misuse Act, but what are the chances of some random piece of spyware originating from someone subject to the Act?

2) Get it Cleared.

You need a pretty explicit memo from your source of arse covering (your boss, HR) saying that the answers are wanted tomorrow, there is definitely no intention to rely on your investigation in any sworn proceedings, and that your advice to go the ideal route is not wanted or not practical in this case.

3) Take Care Anyway.

When you're half way into a DIY investigation and you realise that you are going to have to complain about the behaviour of an employee, or call the police, you do not want a sinking feeling that you've trampled on the only copy of the evidence. See the next post has basic tips for getting the data you need without booting the evidence disk or writing to it.

4) Keep it Locked Up.

One of the best reasons for working on images is that the record keeping to prove evidence is easy: you can keep the original locked away for long periods. If you're actually working on it, you have to sign it in and out, secure it when you leave your desk.... No fun, and not impressive when you have to swear a long chain on ins and outs, but better than no records kept at all.

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.

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.

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.