Thursday, November 26, 2009
#
Scott McIntyre, the security officer of XS4ALL, had in his presentation at HAR2009 some hilarious words on cloud security:
Manager: Where is the data?
Sysadmin: In the cloud
Manager: But WHERE is the data?
Sysadmin: In the cloud
Manager: Just tel me, WHERE is that?
Sysadmin: It is in the cloud
Last week ENISA published a report on cloud security. The report makes clear why Scot McIntyres objection is still going strong: a security policy requires clarity over what data is stored where, what protections and controls are in place and how the data is disposed at the end of its lifetime. Many vendors of cloud-services don't tell much about these issues. And if you are working in an environment that requires certifications, then you are totally left alone: these certifications usually aren't applicable to SaaS or cloud computing. Let alone that there are any cloud computing vendors out there that are certified.
But there is hope: the report is co-written by a lot of these vendors. So they acknowledge the problem and they are even asking for certifications for cloud computing. Great! At the next Hxx conference in 4 years, the conversation Scott made up can continue:
Sysadmin: I finally know where the data is and how it is protected!
Manager: Thanks, but get the data out of the cloud. We have something better by now.
At this years SecTor conference a security firm accommodated a 'wall of shame', a site were the details of attendees that didn't connect securely to the outside world, were published. Although this was announced on forehand (and has been done before on other conferences), it caused quite an outrage. See Andrew Hays blog for more details.
The complainers gave several arguments why this was wrong:
- It was illegal.
- The conference tries to interest more executives to the field, this scares them of.
- The network suggested the attendees could protect themselves, but were 'lured' into it, there was a false sense of privacy.
- The wall of shame was accomodated by a private firm, the conference organisers should not trust a third party with something like this.
Well I think these arguments are a bunch of crap and the bottom line is: a lot of security experts were caught with their pants down and are unable to deal with it.
Let me explain that a bit:
- Bad guys don't care if something is illegal or not. Laws can't replace security.
- This was a perfect showcase why network security is so important and I can't imagine a better way to educate executives.
- Security experts should not be fooled by a false sense of security, they should know what is really secure and what isn't.
- And once your data has been breached, you should be happy you were told it was breached: usually you have to find out the hard way. Who breached it doesn't change the fact that your data was breached at least once.
Anyway: anybody who connects while on the road, should have the security measures against exactly this attack already in place.
The reaction of the complaining security experts is very disappointing. There are only two sensible reactions to something like this: lick your wounds and make sure it never happens again or say the risk isn't big enough to mitigate it. Security experts should know better then start crying over the injustice done.
The real problem is that conferences like these are crowded with vendors of magical boxes that should mitigate exactly this problem and a lot of the visitors make their living out of implementing network security. And now they are caught with their pants down: they aren't protected themselves! So either the products they sell don't mitigate the problem they are supposed to mitigate, or their products are so user unfriendly that they don't use it themselves or they make their business out of mitigating a risk they don't really regard a risk themselves. Either way, this incident is showing there is something fundamentally flawed with the security that is sold on conferences like these. And more severe: these "security experts" aren't up to admitting it.
(old post written on 2009-10-21 for another forum)
Q: Well, what to do when you want to avoid police-detectives who are demanding ip-addresses in your apache logs?
A: Don't log them, use mod_removeip.
And of course the reality is harder then that: you still want to be able to distinguish different users, maybe for statistics, maybe for blocking abuse. So better use a salted hash for it. And that is exactly what mod_anonstats does. But while experimenting with I wasn't fully satisfied: can the shared memory used for the salt be swapped to disk? Why use a fake-ip, replace it with a hash to make directly visible this is not an ip. why use md5 and not sha-2? Can it be configured per virtual host? And once it crashed quite nasty. I did: "killall -9 apache2", when trying to restart apache2 right after it, it failed because the shared memory file was still open. It should protect against situations like that...
Anyway, if anybody can help out improving it, please let it know, the author of mod_anonstats is very open for suggestions. And mod_anonstats is too close to being very useful to discard it.
(Old post written on 2009-09-08 for an other site)