Generally, only scanty details are available when an organization is hacked.  However, some organizations have proactively positioned themselves to get it write and limit the effects and damage of a successful attack.  Here are what some hacked organizations have done right:

• Proactively planning for breach response
• Prompt notification
• Effective messaging and communication
• Limiting sensitive data retention
• Effective password management

Proactively planning for breach response makes sense

Companies that have effective breach response plan will come out faster with less cost. In other word, the maturity of breach response plan represented another interesting opportunity to either increase or reduce the cost of a breach. Companies that provided quick, less coordinated announcements and response activities that did not follow a clear protocol incur management costs of 7% above the mean. But those with a clear incident response plan reported average costs around 8.5% below the mean. Invariably, the difference in response approach represents entails either lowering the costs due to an incident. In the finally analysis, organizations that are proactive in planning for breaches come out swinging better.

Prompt notification

The minutes, hours and days after a breach is discovered are incredibly hectic, and there will be powerful voices both attempting to delay public announcement and attempting to rush it. When users’ information may be at risk beyond the immediate breach, organizations should strive to make an announcement as soon as it will do more good than harm. An initial public announcement doesn’t have to have all the answers, it just needs to be able to give users an idea of how they are affected, and what they can do about it. While it may be tempting to wait for full details, an organization that shows transparency in the early stages of a developing story is going to have more credibility as it goes on.

Effective messaging and communication

Affected organizations should explain in clear terms what was and was not affected and gave straightforward actions for users to follow as a result. The logging and access control groundwork for making these strong, clear statements at the time of a breach needs to be laid far in advance and thoroughly tested. Live penetration testing exercises with detailed post mortems can help companies decide if their systems will be able to capture this critical data.

Limiting sensitive data retention

One of the first questions in any breach is “what did they get?”, and data handling policies in place before a breach are going to have a huge impact on the answer. Thinking far in advance about how we would like to be able to answer that question can be a driver for getting those policies in place. For example, for organizations that handle or process credit card transactions should not store full credit card numbers, a choice that is certain to save them some headaches when they are hacked. Not all businesses have quite that luxury but thinking in general about how to reduce the retention of sensitive data that’s not actively used can reduce costs in protecting it and chances of exposure over the long term.

Effective password management

Any security conscious organization must be proactive and do a pretty good job in handling user passwords, though not perfect. Password reuse across different websites continues to be one of the most significant threats to users, and a breach like this can often lead to ripple effects against users if attackers are able to obtain account passwords.

In order to protect against this, user passwords should always be stored in a hashed form, a representation that allows a server to verify that a correct password has been provided without ever actually storing the plaintext password. Passwords should be uniquely salted and digested with SHA-1 multiple times. More recent passwords are hashed with tools such as bcrypt.” When reading breach reports, the level of detail shared by the organization is often telling and these details often reveal if the hacked organization did their homework beforehand.

A strong password hashing scheme must protect against the two main approaches that attackers can use: hash cracking, and rainbow tables. The details of these approaches have been well-covered elsewhere, so the focus should be on how to make an organization’s users’ hashes more resistant to these attacks.

To resist hash cracking, defenders want to massively increase the amount of work an attacker has to do to check each possible password. The problem with hash algorithms like SHA1 and MD5 is that they are too efficient; they were designed to be completed in as few CPU cycles as possible. We want the opposite from a password hash function, so that it is reasonable to check a few possible passwords in normal use but computationally ridiculous to try out large numbers of possible passwords during cracking. An effective means is the use of “multiple” iterations of the SHA1 hash, which multiplies the attacker effort required for each guess (so 5 iterations of hashing means 5 times more effort). Ideally, it is desirable to see a hashing attempt take at least 100 ms, which is a trivial delay during a legitimate login but makes large scale hash cracking essentially infeasible. Unfortunately, SHA1 is so efficient that it would take more than 100,000 iterations to raise the effort to that level.  Even if that level is not attained, it’s safe to assume that the use of multiple iterations of SHA1 is an improvement over many practices we see.

To resist rainbow tables, it is important to use a long, random, unique salt for each password. Salting passwords removes the ability of attackers to simply look up hashes in a precomputed rainbow tables. Using a random, unique salt on each password also means that an attacker has to perform cracking on each password individually; even if two users have an identical password, it would be impossible to tell from the hashes.

Finally, a move to tools like bcrypt and other more recent ones for more recent passwords is particularly encouraging. Bcrypt is a modern key derivation function specifically designed for storing password representations. It builds in the idea of strong unique salts and a scalable work factor, so that defenders can easily dial up the amount computation required to try out a hash as computers get faster. Bcrypt and similar functions such as PBKDF2 and the newer scrypt (which adds memory requirements) are purpose built make it easy to get password handling right; they should be the go-to approach for all new development, and a high-priority change for any codebases still using MD5 or SHA1.