Ultimately it has very little to do with Sobig-F and a lot about efficient distribution of viral code updates.

The concept of an IPS was born when Gartner, in the person of the renowned security expert John Pescatore, declared to the world that IDS was dead because it was too cumbersome to configure, didn’t deliver, etc. etc. etc. The firewall was rapidly provided with “intelligence” directly from Pescatore’s own private stash and promoted to IPS or “Intrusion Prevention System”, an oh-so-more-catchy term.

Let us imagine, for sake of argument, that this poor client happens to have a 100% Linux-based infrastructure and that it is a minor variation on the classic LAMP site and that it also uses the highly subversive sendmail MTA.

Let us further imagine that these raving loonies happen to have customers who willingly subscribed to a weekly newsletter and a monthly in-depth variant of the latter and that they would be so bold as to require that weekly newsletters be delivered the same day they are sent and not a month later.

Enter the “managed firewall service” which decides unilaterally that the volume of outbound traffic produced by sendmail couldn’t possibly be legitimate and thereby classes the originating system as an Windows system infected by a trojan or worm¹. To protect the Internet it therefore blocks all outbound SMTP traffic until the connection rate drops. This happens when sendmail notices the lack of connections and throttles itself by placing differing retry timeouts.

The co-lo “managed security helpdesk” when queried immediately replies with the terrible Internet infection scenario and the white knight, in the form of their IPS, coming to the rescue.

This is not all, it also detects outbound traffic as Teardrop² attacks prompting claims that the machines have been compromised with the explanation that the servers are “sending out malformed packets which have the potential to crash certain un-patched servers”³.

The list goes on and on.

The final straw is marking every outbound GIF as an attack against Internet Explorer⁴ with no actual attempt at determining whether the image in question was an attack or not.

We asked for the packet dumps in pcap format and I started to go through them and here is the outcome of my research on the first of the files sent containing malicious traffic (with some inevitable censorship).

First of all I filtered out all the ARP requests and packets that had nothing to do with the client’s network, that cut the number of packets by 50%, so obviously the IPS alerts on ARP and irrelevant traffic too…

1. DNS requests for MX, A6 and AAAA records over udp/53 (IPv6 name resolution attempts): sendmail on the system has IPv6 support enabled and therefore after MX lookup it checks for A6, AAAA and A records for the required mail exchanger,

   09:25:10.647868 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 76)
   		w.x.y.z.53 > j.k.l.m.53: [udp sum ok]  27809 [1au]
   		AAAA? pool.domainsite.com. ar: . OPT UDPsize=4096 (48)
   
   09:25:25.639925 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 73)
   		w.x.y.z.53 > j.k.l.m.53: [udp sum ok]  29390 [1au]
   		A6? ns1.netscape.com. ar: . OPT UDPsize=4096 (45)
   
   09:26:47.907197 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 76)
   		w.x.y.z.53 > j.k.l.m.53: [udp sum ok]  46858 [1au]
   		MX? pool.domainsite.com. ar: . OPT UDPsize=4096 (48)
   



2. Quite a few tcp/25 carrying the “QUIT” keyword and having the PSH flag set which is perfectly normal sendmail operation,

   09:25:31.763296 IP (tos 0x0, ttl  64, id 28349, offset 0, flags [DF], length: 46)
   		w.x.y.z.55750 > j.k.l.m.25: P [tcp sum ok] 0:6(6) ack 1 win 5840
   
   		0x0020:  5018 16d0 ab8e 0000 5155 4954 0d0a       P.......QUIT..
   



3. Some tcp/25 with the FIN flag set, that’s basic connection teardown,

   09:25:31.763384 IP (tos 0x0, ttl  64, id 28350, offset 0, flags [DF], length: 40)
   		w.x.y.z.55750 > j.k.l.m.25: F [tcp sum ok] 6:6(0) ack 1 win 5840
   

   Note how the above packet is the TCP teardown packet for the connection which was terminated at the protocol level by the packet in 2) above.
   

Nobody deserves more than this amount of torture: out of 4000+ packets there wasn’t a single malicious packet of any kind save for two connection attempts inbound to the Linux boxes on port 445 (Windows RPC services) which were obviously sent packing. The missing analysis was for the dangerous HTTP packets sending GIFs, “ident”, and sendmail connection setup. I am sure you will thank me for not posting the “analysis” to those too…

Needless to say I didn’t look at the other pcap dumps nor did I ever get a reply to my e-mail, they continue filtering the traffic and the client is going to cancel the contract for the managed firewall service.

There is little to comment about here besides the obvious hype about IPS removing the configuration and maintenance issues of IDS (frankly, if you believed that then I’d be honoured to sell you shares in the Leaning Tower of Pisa and the Fountain of Trevi, Rome).

Sticking a box on a network looking at packets can never be a substitute for training a human on how to respond: if you are incompetent the boxes you manage will be incompetent too.

Not only, these fashionable “auto-reacting” IPS are far from infallible (unlike Mr. Pescatore who is apparently never wrong in his IT security predictions) and, in the specifc case of this co-lo site, will bring them loss of customer revenue (I did recommend asking for damages too).
__
¹ There is a subtle difference between the two: a trojan normally gains access to systems by masquerading as something legitimate, e.g. an e-mail, and requires a modicum of end-user interaction whereas a worm spreads from machine to machine making use of holes in the operating system and therefore independently of the end-user’s cooperation.
² You should follow the link, observe the date of the attack and the vulnerable systems.
³ Do go and read the link provided, please. Then compile a list of systems still running vulnerable software to Teardrop, your answer should comfortably fit in a page of A4. Then highlight any well-known site from the list. Your highlighting pen should remain capped throughout the exercise.
⁴ Yes, it is possible to attack Internet Explorer with GIF images, see this discussion on SecurityFocus if you have been living under a rock in the past few months.

On cue the news that in Italy the Post Office was ready to be defrauded of 20 million euro thanks to an employee in the Naples area. The article is sadly in italian but I've put together a quick translation for the benefit of curious english-speakers.

Secondo la polizia postale di Pescara che ha svolto le indagini la banda, con il concorso di un impiegato postale del napoletano, era riuscita a entrare nel sistema informatico che gestisce il deposito e i movimenti di denaro delle Poste attraverso l'intercettazione abusiva di codici e password riuscendo a simulare operazioni di cassa in favore di conti correnti postali appositamente aperti da diversi complici negoziatori in altrettante zone d'Italia.

which translates roughly to (again my emphasis):

According to the postal police in Pescara, which was responsible for investigating the crime, the band gained access to the IT system which manages the deposits and transfers of the Post Office with the help of an employee in the Naples area. Access was gained via unauthorised sniffing of user ids and passwords thereby managing to simulate cashier operations in favour of other postal accounts which were opened by accomplices in a number of italian regions.

Besides the relief for the fine work of the postal police we should focus on the fact that user ids and passwords were allegedly sniffed off the wire. This is not your "Joe Average" shoulder surfing the passwords of colleagues but someone with a certain amount of skill.

The obvious question which should be asked is: why exactly where the user ids and passwords being trasmitted in the clear? This is 2004, SSL has been around for a few years now (not to mention many other encryption protocols).

My reaction is almost invariably to explain that the moment you bring a criminal organisation into the fold then the issue becomes, like every business with an MBA at their service, one of Return On Investment.

So let us think about how a criminal organisation goes about its business. For the sake of argument let us decide that we want to get rich very quickly and that selling medication to idiots via spam isn't fast enough. The best alternative is to hit a site which moves money. What are they? Well, a bank is a good start, an even better start is a mediator between banks (for example SWIFT, overnight settlement institutions, VISA processing services, etc.).

Alert readers at this point will jump up and mention that as of 2004 the best ROI must be had with DDoS attacks and I would tend to agree: the DDoS attacks against online betting shops during Euro 2004 were an excellent idea. A quick blackmail phone call and an even faster calculation by the accountants working out how much every minute of punters unable to reach the website cost meant that the criminal organisations probably raked in loads of money. The cost circulating in the underground for a network of DDoS drones is about $3,000 for a lot of 10,000. Make the call for $1M and the ROI is pretty decent.

But let us take the longer term view. DDoS works a few times but risks taking the victims out of business, raketeering is a difficult art to master because if you strangle your victims then your ROI rapidly hits zero. So what is a better alternative? Surely it must be to enter a suitably large money switching organisation and start syphoning money out. You cannot really play the blackmail card as that would only work a few times, you need subtlety and elegance here.

So the plan is simple: get yourself an insider. Why? Obviously because the focus is so strong on the threats from the Internet that most organisations don't even know what their internal traffic looks like. Start by looking at job advertisments and have someone win. No need to be in the IT department as long as they have a PC on their desk. At which point you start "working the inside", that nice soft shell made up of lack of ACLs, lack of IDS, mainframes controlled via plain telnet sessions, etc. which distinguishes most locations, sufficiently starved for IT resources that they can barely watch the perimeter.

Now that we have our trojan horse we can slowly map the network, no need to rush here, remember that we are in for the long run. Then these possible targets can be reported to the controller outside the organisation who has all the time to analyse them and decide the next moves. Notice how the classic steps of a hack are still there: we are doing reconaissance and scanning but internally. What should the reconaissance focus on? The mainframe of course. Have that and you have everything.

This is where it gets even more irritating. Why? Because most mainframe vendors insist that since very few people know their systems they are secure from the occasional hack. Indeed, perhaps from the occasional hack but remember that now we have criminal organisations coming into play. They have the resources to send their people off to training courses perhaps purchase a second-hand entry-level mainframe to perform target practice, etc. etc.

Clearly the financial outlay to the criminal organisation is substantial, well above the $3,000 forked out for the DDoS drones, but the ROI is far more interesting. A few ideas? Clone credit cards by seeing the transactions fly past, access bank accounts of large corporations and move funds by taking the details from their SWIFT transactions, play the age-old idea of "take a penny from every account".

Perhaps it is time that so-called "risk analysis" on the external perimeter started to include an ROI calculation for the hacks which would be possible via that route and then followed by an ROI calculation for the cost of an insider job like the one described above.

Suddenly HIDS and NIDS on the internal network would look a lot cheaper.

The definite trend is towards turning these fake websites into very high quality imitations of the originals. Gone are the shoddy graphics obviously lifted at random from the real one, the slow link to a site in the middle of China and the lack of SSL certficate (or a self-signed certificate). The latest sport a fast link, often at a co-lo site in Europe or the USA, perfect graphical imitation and an SSL certificate which raises no warnings (we shall leave the obvious rant against the quality of verification by the issuers for another time).

So why are they successful? Well, I think that it is high time that the banks took part of the blame.

You might think: you idiot, no e-bank ever sends you e-mail. Well, you would be mistaken and gravely so: there is at least one UK e-bank which sends e-mail regularly, Egg. So, there is at least one ideal phishing candidate.

So what, you continue, if you are stupid enough to believe that you should re-enter your details then you deserve to have your account emptied. Indeed, normally the people who say so claim to have "never" fallen for any scam. Of course not.

How many pensioners get robbed of their money every year by fake council workers, phone company engineers, electricity meter readers, etc.? Are they all stupid? No, they are quite simply targeted because their defences are lower than the average person for a number of perfectly valid reasons: their eyesight might have deteriorated to the point that they find it difficult to distinguish photos on fake id cards, for example, or they are so lonely that the idea that someone would actually care for them is reason enough to open their door wide.

Similarly, how many people click on virus-infected attachments every day? Thousands if not millions including some of the same people who claim "never" to have fallen for a scam...

So it is time to consider how various states have dealt with the problem of pensioners being robbed of their money: by educating them. It isn't such an amazing idea if you think about it. By giving enough information to a pensioner so that he can distinguish between a fraudster and a real meter reader you have allowed him to protect himself. You need not give a three-hour course on uniform recognition with yearly updates whenever uniforms change, you simply need to advise them on a few simple tricks like not opening the door immediately, ringing the electricity company if there is any doubt whatsoever and so on.

Enter the media by which this education is delivered. It is pretty clear to everyone that a simple leaflet in the mail will not do the trick so you send out instructors to various aggregation points, be it churches, social and recreational clubs or day clinics. Why does this work better? Because you have immediate feedback: how do you check if someone has read your leaflet?

Now let us return to our original subject. What do banks do to attempt to prevent phishing? Have a look at HSBC, they have a banner on the main page, centered above the box where the login identifier is entered which states:

"Customers are reminded that we will never send you an email with a link asking you to enter or confirm your bank details. Such emails should be ignored and deleted."

A link from the words "more information" just after the quote above takes you to a useful and well-written page about how to protect yourself on the Internet.

Is this enough? No, it isn't.

First of all I'd love to know how many HSBC e-banking customers have actually clicked the link which sits where normally HSBC flogs its mortgages with a banner advert. Secondly I would really appreciate knowing if any of the recommendations are implemented by the few who do read it.

What should really happen is that on one login you should be taken to a concise online course on how to recognise and avoid phishing scams. Then, at the end of it, there should be a short questionnaire to judge how well the material has been absorbed. This should not be phrased as a test but as a teaser: "how well would you fare against the best phishing scams?". You would then be recorded as having taken the course and allowed to continue using your online banking.

How much effort could this be? Not much judging by the amount of effort put into the automated mortgage calculators or presentations about the latest financial products.

Why do banks not do it? Simple, if you read the fine print on your e-banking contracts it invariably says something along the lines of "if you hand your e-banking details to third parties, willingly or unwillingly, you are responsible for it".

End of story: an online course costs the bank money, you being defrauded doesn't.

It appears that BT (British Telecom) intends to move its current phone network to an IP-based network by 2009 thereby sending the circuit-switched technology off to the attic.

The real question is: can we guarantee the same level of reliability on VoIP as we had on circuit-switched telephony when the stated aim is to carry both voice and data traffic down the same cables (or fibres more likely)?

At least in my very own personal experience I can recall each and every occurrence of a phone outage which has affected my private phone: there were two in London, one due to a "high order fault" at the Nine Elms Lane exchange for about three hours, another was due to a backhoe taking up my wire in the road. A tad further back in time there were two in Milan, one was due to a thunderstorm hitting the building and blowing the telco fuses and the second was due to my exchange being moved from electro-mechanical to digital. There was one recent one in Geneva due to some unspecified fault at my exchange but which strangely coinceded with the day Cern moved from Swisscom to Sunrise as their main phone operator and we share the same exchange...

Surely that's a pretty impressive record if, over the space of approximately 15 years I can recall each outage with precision.

Where does one start with IP outages? From the DSLAM mis-configurations which plague my current "el-cheapo" provider and the upstream monopoly wholesaler, or to the frequent routing hiccups, or the DNS timeouts?

To be perfectly honest I am not really that worried about emergency calls: from the little I have seen of the setup in the UK they are smart enough that they are going to be routed out of the IP network as soon as possible and, I would be prepared to bet, on a private IP network for emergency services. I am actually concerned about everyone's daily use of the phone which we've come to rely upon as a dependable household good, a bit like the toaster.

People expect a phone to work at any time of the day or night and this is simply not the case with IP. There are too many variables: routers, IP routing tables, proper working of QoS settings are just a sample. Can we really trust IP routers as much as we trust switchboards? I think not.

So far we've only really talked about the infrastructure, we haven't even started discussing about malicious use of it. Switchboards aren't immune to malicious use, far from it (phreaking has been around for ages) but there seems to be a different rationale at work: getting free phone calls. If you break the switchboard you get no calls so there's a sort of built-in incentive against DDoS'ing the phone system. When you have convergence between the phone system and the data network then the line becomes blurred, if I DDoS that website do I take down the phone service too? Do I know? Not only, let us assume I do take down the phone service: do I now care? "What about QoS on VoIP?" shout the proponents of VoIP... well, are your routers safe? If I can get to the routers I can reprogram the QoS parameters, not only, if you DDoS a network the load on the routers goes through the roof so there might be no CPU available to route your precious VoIP traffic.

I really don't think that these problems, which are inherent in the design of IP, will magically disappear by 2009.

It has been a phenomenal start of the week for the various news agencies, all falling over each other to try and find quotable quotes and disaster-struck companies to cite in their "end of the world" articles.

The lack of understanding of what sasser is and why it spreads has meant that nobody actually focused on the fact that this alleged disaster could have been avoided by pretty much every large company admitting to being hit with a modicum of effort and planning.

Let us assume that all the companies cited in the BBC's article were real victims of sasser (I have no independent means of verification), if they weren't then they can serve as useful examples nonetheless.

Let us begin with a Finnish financial institution, Sampo, which allegedly closed 130 branches due to the sasser outbreak. The very first question you should ask yourselves is "how on Earth did the worm get to the branches?" followed closely by "surely they are not connected to the Internet?" followed by inevitable dispair. How can a financial instution possibly allow a cash-handling system to be connected to the Internet even via firewalls?

Alternatively, if the systems are not connected to the Internet, how did the worm spread? Well, the only possibility is that an infected system was placed on the same LAN because, suprisingly enough to some people, Internet worms can't jump out of one machine and magically appear onto another without them being connected. At which point the next question is "surely you can't just plug in any old system on the branch network?" and the answer to that can only be a resounding "yes" to explain the spread on their internal network.

The above example has nothing to do with Microsoft, patching or worms and everything to do with atrocious security policies. If you are a financial institution then your primary concern should be the preservation of the integrity of the network handling financial transactions not making sure that your employees at branches can read their Yahoo! mail or surf the web.

Are they alone? No, according to an article on the italian newspaper "La Repubblica", the italian Home Office ("Ministero dell' Interno") was affected. Of course we don't know the details: it could have been external hosts only (although their website is running Apache, normally a good sign) but still the fact that they were affected at all is not impressive. This is the ministry which controls the police force in Italy. Or what about Dubai International Airport? Australian Railways? Goldman Sachs? Deutsche Post and Taiwan's national post office reverting to pen and paper?

This is pure madness: how can a worm which spreads from the Internet and via the Internet possibly shut down the whole national post office network with branches reverting to pen and paper? There is only one answer: incompetence at the highest level.

Allow me to give an extreme example in the opposite direction: a friend of mine used to work for a bank in the City of London. This bank had a very simple policy: thou shalt not have physical access to anything connected to the network. If you wanted your Palm synchronisation program installed they would take your sync cable, bolt it to the machine, install the software and return it to you. If you wanted access to the corporate network from home they would install a leased line and an office-standard locked-down system. By locked down I mean: no floppy, no CD-ROM, ports at the back bolted and locked, case under lock and key. So yes, it is very expensive but they knew that there was no trivial way that someone could bring a worm into their network.

So it can be done at some expense but how much did a day of virtual shutdown cost to the affected companies, not to mention the public relations disaster?

It is pretty clear that most virii are "successful" by subverting some part of the system they are about to infect and gain their entry mainly via social engineering. We can discuss to our heart's content whether the techniques are getting any better but the bottom line is that "oops, I clicked on the attachment" is still leading the pack.

Instead of a pointless long rant on anti-virus software let us consider how the problem could be at the very least mitigated.

To begin with let us consider systrace (by Niels Provos, originally surfaced in OpenBSD) which verifies that the system calls made by an application match those defined in its "profile". Despite sounding difficult this mechanism is in production use on many OpenBSD and NetBSD systems. In practice this means that if your Outlook tries to write to the registry a systrace equivalent will terminate it and print a suitable message. Where are the profiles? Well, that's simple, when you certify your application to run on Windows you also submit a profile for inclusion with the OS release or you add it to your installation disk.

That is already a good start, what next? Well, systrace can of course be circumvented so we need multiple layers of defence. So let us consider a limited form of "real-time Tripwire". This is a system which would very simply protect a small number of files from alteration. Allegedly this is already available under Apple's Mac OS X and is a brilliant idea. Writing to these protected files can only take place if the user authorises it, not just with an "OK" button, which is often pressed without reading the warning which accompanies it, but by typing in the user's password.

Now what is really missing is some sort of "process watcher". This would simply check that any process started belongs in a whitelist of allowed processes, not just via the process name (too easy to falsify) but also via checksumming techniques, perhaps linked in with a full version of Tripwire and friends.

Of course there is a downside to all of the above: what about the so-called power-users? Well, they will complain about the "performance hit" to which the obvious answer is "buy a bigger box". It isn't like CPU power is an expensive factor in today's PCs. The only real losers from the above are developers: for them each compiler run will produce an executable which is not recognised by the system, which they will have to register and profile.

Are we there yet? Well, the tools are mostly there, the "miracle security cure" offered by Windows XP SP2 (aka: non-executable stack) is a start in the right direction but clearly not enough. It protects from buffer overflows but not much else and the current crop of fashionable virii are not going to be affected by it.

To tie it all together one could argue that the above functionality is really beyond a HIDS and closer to anti-virus system but there is a rather striking difference: all the above is based on white-listing, allowing only what is trusted, this means that you need not download new signatures on an hourly basis but on the contrary define what is acceptable and sit back.

As a final aside one should really mention the much-hated Trusted Computing Platform Alliance which got it all wrong by associating their work with so-called "Digital Rights Management". An overview is available on the Wikipedia, for discussions of how a much needed idea was turned into a nightmare see Ross Anderson's FAQ on the subject and the EFF's white-paper titled "Trusted Computing: Promise and Risk".

What is needed is a push, on the part of users, towards OS developers to implement some basic security features which would make life much easier for all of us.

It should be noted that by HIDS I don't mean your ever so pointless anti-virus software (as previously discussed in these pages) or your fashionable "personal firewall" but software designed to detect intrusions at the host-level. Anti-virus software and "personal firewalls" fit in a very very loose definition of HIDS: they both protect you from external attack, not attacks perpetrated on your own system.

Modern company security practices seem to overlook internal security (see also a separate rant) because it involves lots of unfashionable effort. Amongst the victims is HIDS often maligned as being impractical, "trigger happy" and heavy on the configuration side. The usual excuse surfaces: "I have to put work into it so it is not worth my time". The actual truth is that it isn't exciting to check for modification of key system files except as a forensic exercise later. The official motto is: "Prevention? No thank you".

Let us consider Tripwire: like all software it can be installed and configured in many pointless ways. For example you could monitor your whole hard-disk for file changes, guaranteed to fill your logs with false alarms, or you could have the file checksum database on the same disk as the one being monitored ready to be modified by the wily hacker. A more sensible configuration such as limited monitoring of key system files (how about /etc, /boot, /vmunix, /lib and /sbin to start with?) with the database on read-only media (a floppy disk with the write-protect tab set is an ideal choice - the database isn't very big) can already help quite a bit. SImply run tripwire via cron at suitable intervals, say hourly, and have the results mailed to you.

The side-effect of an "instrumented" server is that not only can you detect malicious changes to your filesystem but also those clumsy-handed sysadmin days when "I thought I was editing on machine x but actually it was machine y" takes place.

Clearly Tripwire alone isn't enough, you need to instrument your systems a bit better. Once upon a time full system accounting was relatively common for reasons which had little to do with security, i.e. charging on a per-cpu cycle basis, although it did give rise to a famous "catch the hacker" story when an accounting discrepacy was found. It is difficult to advocate full accounting in 2004 as the volume of data has become prohibitive (it is worthwhile remembering that full accounting means that every single command typed is recorded for posterity) but there is value in limited accounting. This already takes place in the various log files which litter a modern system which contain a wealth of very useful information.

How do we detect an "insider job" on a modern Unix system? Well, let us assume that we do have Tripwire installed but little more. Let us further assume that no files have been modified but our log watcher (there are ample choices here) has detected that the volume of logs is increasing above the usual rate. An example? The mail log is twice the size of a usual day or perhaps the database access log has grown excessively. What happens next? Instead of crying wolf the first requirement is an in-depth analysis of the logs in question. Perhaps it is end-of-year and the database is burning away for the accountants or there is a new virus on the loose which is killing sendmail.

This is just the beginning but how many locations actually realise what wealth of information about system misuse lies in their logs? Very few sadly. A remarkable amount of analysis can be done with a "poor man's HIDS", also known as syslog. It might not be hacker-resistant (it doesn't take much to wipe logs) but it can definitely be used as an early warning mechanism.

And once we've re-learned how to use logs how about giving HIDS another whirl?

Of course the beauty of all this is that companies are looking at their perimeter as if it was the only chance of survival they had in the dark woods of the Internet. They believe anything their firewall or IDS vendor tells them, stare in awe at highly secure Windows-based firewall solutions (or indeed fancy webserver-based firewall products) and bask in the sunshine knowing that their enterprise is safe.

Apparently not.

A few basic concepts are a complete mystery to many companies: separation of duties (or: "why should the engineering department see the finance servers?"), document tracing (or: "how the heck did this document get out?") not to mention basic IT security (or: "how did they break into this totally unpatched, wide-open, system?").

The reason for this internal debacle is simple: a combination of laziness and fashion. What makes you look like a digital hero? Fighting the wily hacker or securing the internal servers? The fact that the ever so dangerous wily hacker is more often than not a script kiddie barely out of elementary school is irrelevant, it is still more interesting than actually thinking about the real dangers for a company.

So what happens is that people comfortably log into key servers, prowl databases of confidential information and then walk off with the data. Managers often deny this takes place as their workforce is always invariably honest, happy and well-managed until they discover the inevitable "companyzsucks.com" website run by disgruntled employees... This is then followed by ample management chest thumping, sacking of the disgruntled employees and total disregard for the security of the data they might have had access to.

Some people argue that pentesting is the answer to evaluating internal security but think about it for a second: how could it possibly be the answer? What you have is an external team trying to get to valuable data.

Why don't you try asking your top systems manager to walk out with as much valuable data as possible and see what he does? Then try doing the same with some closet geek in accounts. If you follow this up with some sums about the cost of the wily hacker versus this exercise you might discover that installing a HIDS and proper inter-departmental firewalling is more cost-effective than spending millions on the latest fad in perimeter protection.

She diligently updates the anti-virus each and every time it askes her to, she even runs the occasional Windows Update which I recommended doing as often as possible despite her slow dial-up line. The outcome of all this is that I get continuously asked: "why do I have to do it?".

That is actually a very good question, why exactly is the default configuration not good enough? Why is it so that her Outlook Express as delivered will happily execute any possible rubbish entering her inbox? Not only, why is it that after numerous runs of the update facility it still executes any possible rubbish? Did nobody take notice of the somewhat recurring viral techniques regarding attachments?

This could well become a long rant against Microsoft but this behaviour is not limited to Windows, far from it: I will never forget the maintenance nightmare of RedHat 5 "default installs" which people all over Imperial College were installing on their PCs when Linux was becoming fashionable. These installations had everything possible running, there were more DNS servers within Imperial College than you can imagine, Samba servers listening to anyone willing to talk not to mention Apache servers offering the standard RedHat index page and the full man pages of the system. Do you know of many stand-alone workstations requiring a DNS service running on the host? Or indeed a Samba server?

Just recently I allowed myself to be pulled into a discussion with someone trying to convince me that OpenBSD is "secure by default" only because it runs no services by default otherwise it would be as insecure as Windows (yes, a somewhat inflammatory remark). As I listened to his arguments I was thinking that perhaps he had never noticed that the average user does not actually need to run Apache, DNS and sendmail. There was no way to explain to him that by forcing people to turn on services rather than turning them off was a rather good idea. Even the analogy of allowing people to decide whether or not Outlook should execute attachments was lost on him, it was all a matter of "freedom of choice". Apparently the "choice" to have your system turned into a lump of useless plastic and metal is an important one.

So, have users forsaken security for a badly "freedom of choice"? Or have they been led to believe that allowing a computer to do all the "thinking" is the equivalent of "freedom"?

The idea in itself isn't exactly novel: PVM and Condor have been offering some of its capabilities for a long time.

One of the issues in the EU DataGrid which I find particularly interesting is the security aspect which has in some ways been addressed.

I'd like to offer a different slant to the security issue: not so much who is allowed to use the DataGrid but where the data flows are.

It should be pretty clear that the security of the Grid as a whole depends on the security of individual systems and also that it is sadly the case that any system connected to a network cannot be guaranteed to be secure. In particular what concerns me most is that for computations to take place you have to ship some data off to systems which you do not control so if one of these is compromised then the data is wide open.

The argument which is often put forward is that this is scientific data so it doesn't really matter if someone obtains access to it. This is akin to the justification for universities having lax security and we shall leave it at that but the difference here is that the Grid is being offered for use in other fields, for example, medical research.

Here we hit a problem: it is no longer physicists working with the consitituents of matter but medical research which could possibly contain either patentable information or clinical trial information. In theory data could be encrypted and decrypted on the fly during job runs but once you have control of a system it doesn't take much work to access the decrypted data.

I would agree that it requires a certain amount of dedication to enact the above but this dedication has been definitely shown recently by the spamming community...

It is becoming one huge joke: a new virus is unleashed, thousands of systems are infected, anti-virus software companies scramble to produce a signature and then tell you in their virus encyclopaedia that you should always have the latest set of signatures.

What about all the systems which were infected before the anti-virus companies produced a signature?

It is pretty obvious really: the anti-virus companies cannot produce a signature before seeing the virus in action. By the time the virus is "in action" it has often spread far and wide. Take Sobig.F or indeed Mydoom: if the anti-virus software was doing its job it wouldn't have spread so far and so deadly.
All that remains is the insult of being told that to stop the virus you need a certain revision of the anti-virus signatures which simply wasn't available when you got hit, even if you were to attempt an update every 10 minutes.

Why don't users demand better? Why do they still accept software which will happily execute an attachment "no questions asked"? In an era when you can't bring on board of a plane something that remotely resembles a blade we have people continuing to accept dangeous attachments as if nothing had ever happened before, including people who have already been hit by virii!

Wouldn't it be the anti-virus software's job to stop the execution of these attachments outright, perhaps mentioning that it isn't normal for a document to be called "document.doc.exe"?

It would but unfortunately there would then be little incentive to keep updating the signatures and finance the business model of the anti-virus companies...

Today a subject on the ISN mailing list caught my attention: "Bagle e-mail virus slows, fuels naming debate". The first half of the title is pretty self-explanatory but the second half had me wonder what the "naming debate" could possibly be. So I read on, and what a terrible idea that was.

Quoting from the article gives an immediate feel for the depth of the issue being faced by anti-virus firms:

"Personally, I would have called it Beagle rather than Bagle, for the
sole purpose of avoiding all these support calls asking, 'Why did you
call it bagle?' " said Graham Cluley, a senior technology consultant
at Sophos PLC, a U.K.-based software firm specializing in virus and
spam detection.

I would have thought that the majority of support calls should have been: "why didn't your advanced heuristic analyser pick it up?". But no, this is not of concern, it is acceptable for the anti-virus software you pay for to be only useful if you are lucky enough to download the correct signature before being hit. The big issue is the name being given to the virus.

It is clearly heresy to suggest that anti-virus firms should organise themselves into the equivalent of CVE and forget about the naming issue to concentrate on trying to prevent unknown virii from entering computers. Everyone and his dog is able to detect a signature for something that has been seen before and block it - the real issue is what research is being done to try and stop unknown attacks from being successful (and no, "uninstalling Windows" is sadly not the correct answer).

Apparently not much or not as much as the work into names.

They alternate between a rather good Internet banking service, an excellent card fraud department and a hopeless card issuing mechanism.

The Internet banking service is not as stellar as ones using one-time pads but it offers passable security and a simple, clear interface.

Where they continue failing me is their physical card issuing service.

The first time my ATM card was cloned I recieved an identical card on which the only change was the so-called "issue number" (incremented by one) and the expiration date which was defined exactly as "re-issue month + 36 months". That's it. So if you had my previous card it wouldn't be rocket science to know what the new one would be like, in fact trivial: just see when the old one stops working (that gives you the "re-issue month") and add 36 months. Guess what? That is exactly what happened. What is the solution to this? New bank account, totally different number, close the old one: the ideal solution to minimise your customer's distress.

I had thought that it was a "feature" of the ATM card until a problemette appeared wth my credit card: the signature had become unreadable, the regulations mandate that you cannot re-sign your card so I ask for a new one to be issued. The new card is identical except for the expiry date which is (no prizes for guessing) "re-issue date + 36 months ".

Must be a habit... so instead of cutting the card up I burned it as I'd rather not discover more creative uses for rubbish rummaging, sellotape and card swipe readers.