There’s been plenty written on t’interwebs about the HBGary/Anonymous hack: ArsTechnica have the best write up on how it was done plus, using the hacked emails for details, some of the gory details on how HBGary wrote custom rootkits/backdoors for various US three-letter orgs. If you haven’t read the details of how it was done, do so. It’s both sophisticated (rainbow tables), cunning (social engineering) and aiming at low hanging fruit (a SQL injection on an externally facing website).
So what does this have do with with organisations in more mainstream fields? Well, after the UEA hack I was asked “Could this happen here?”. I’m sure the questioner was hoping for a reassuring “Of course not: we have a/v, firewalls, polices, procedures, dogs AND ponies. Nope, definately not”. But of course it could.
HBGary brings that lesson into even sharper relief. This was a IT Security company, working on classified projects for the NSA. And they still got owned.
Now compare this to the situation in the average University:
- Q: Do we have any sql injection vulnerabilities? A: Not that I know of.
So far, so good. Now let’s keep going
- Q: Do you know which versions of applications are running for all externally facing servers? A: No
No, since in most older Universities, IT is decentralised and the centre doesn’t know exactly what the edges are doing or have any control over it except the big hammer marked “Firewall”. So…
- Q: How do you know you don’t have any SQL injection vulnerabilities in all the masses of custom code out there? A: Errrrr.
There’s no easy answer. It gets even worse in Universities where departmental IT can run up externally facing services with no oversight (*). Then we get to this situation:
- Q: Do we know how many webservers we have? A: Yes, Definitely. They all have to have holes in the firewall. Oh, except for those departments that have worked out mod_proxy. Oh.
Still, like HBGary, we can rely on our security cleared, Infosec expert users. Can’t we? Did anyone mention students? Oh.
So what can we do?
One option is to lock down everything: remove autonomy from Departments, lock down the desktop, ban personal equipment etc. Which all seems good (and it’s what most auditors want) but it has the minor disadvantage for a research-led University of destroying research productivity, especially in fields where software is commonly written/modified/mashed together (e.g. most sciences, maths etc.)
This leaves us with plan B. Segregate, firewall, least access. Don’t regard inside the outside as bad and the inside as good. It’s de-perimeterisation (as promoted by the Jericho group). It’s sometimes a hard sell, but it’s seems a very good match for the University environment. Which is ironic, since most of the founders of the Jericho group are banks :)
And if we’d reached this nirvana, would that make us immune to this type of attack? I know my answer.
(*) Of course, the centre never fecks up. Nope. Never.
