crowmoor.se

Just read an interesting blog entry from Apache Infrastructure Team.
Apparently they had a breach in security that hit them with some downtime. What catched my eye was that they are very open with what have happened in contradiction to the ordinary secrecy in security where one is seldom even allowed to say that you work in the field of security and even worse who your customers are.

Lets take a look at the assumptions behind secrecy:
1. Avoid embarrassment
2. Not divulge any information
3. Not scare the shareholders
4. Mistrust

Any kind of breach does more or less always include a downtime. For a very frequently access site this means it WILL be noted. It is of course possible to say that a server malfunctioned but that will lead to demands from customers and partners to create failover functionality and other solutions that actually do not address the real problem. The embarrassment for the site being down will be there in any case. Is there an embarrassment for someone exploiting a vulnerability? Yes, in some cases there are but most of the time the reasoning goes: It happens, fix it. Most important is to contain the breach, not let it run its course.

As for not divulging information that is a flawed assumption. The attack has already happened, information of the attack is spread in the hacking community and all those that you don´t want to have the information of your setup already have it and even worse have access to the servers.

Not scare the shareholders (or the public in case it is governmental) is a tricky one. When looking at share holder psychology speculation is often the biggest threat and information is often the biggest remedy. That leaves us with: inform the shareholders. If there is a rumor that the site has been hacked you could be sure that the stock will go down and that is bad.

Mistrust is a difficult one. Who is to mistrust? Quite often I have run into that the security department mistrusts the people in the company instead of working as a support unit for them. So by not trusting them information of the incident is kept secret and a false shimmer of safety is put on top a raging fire. Real security is about trust. Information regarding incidents has to be available for the management so that they could assess the risk at hand.
So what are the lessons learned from the current incident? Trust in Apaches competence to fix incident have risen. It turned out that they were running Apache web servers (no-brainer). Confidence that there products are safe and stable as they provided exact information on who the attack was done (exact enough, not into every nitty-gritty detail).

So as long as you have a low amount of incidents, a good security architecture that mitigates the threats in the first place, and a good incident and follow-up routine you should inform about incidents.