The database view was a bit confirmed from the data they selected to explain their point, from a study about data breaches conducted by Verizon Risk team together with U.S. Secret service.

In this report, the two standout types of hacking responsible for the majority of breaches and stolen records in 2009 are SQL Injection and Stolen Credentials. Both are involved in a very large proportion of breached records (i.e., really successful hacks).

In addition, the report outlines that high value target systems are databases and file servers, rather than Web Apps or mail servers. The presenters also pointed at www.datalossdb.org, which actually looks quite interesting.

Now, here is the part of the presentation I liked most, delivered as almost raw notes:

The main issue is that business people don’t realize the potential costs of security breaches, because of classical fallacies:

• No breaches will affect us
• Regulations don’t move
• Data breaches don’t hurt the brand

The first problem is that high-level managers often have never experienced a problem directly. They think that their data is safe. But their data is not safe.

The second problem is ROI is hard to prove for security. We get stuck in potential losses, and probabilities, which are a hard sell.

Let’s start by the first problem. On a personal basis, we contract insurance, we install burglar alarms, etc. We do that because we can visualize a house burning down or a burglar coming in. That’s why we will do what it takes. But organizations don’t visualize. People visaulize. So, the first step is to make it personal.

The first question about data breaches used to be: “what would happen if you had an information breach”? Now, it is “What would you do personnally if you have to deal an information breach? To your job, your life?”. Get the guys thinking about potential effects on themsleves.

For the second problem, remember who the enemy is. The enemy is not the hacker at that time; the enemy is ignorance, confusion, doubt, complacency, ROI.

In the art of war, Sun Tzu says “to defeat the enemy, you have to defeat their plan”. To the ignorant and confused, education is the key, and there is a lot of material our there. Complacents and doubters are more difficult, and they can’t be taken directly. You need to find allies, figure out who else cares about data security. For instance, internal audit can be powerful; the owners of the data can also be concerned. And remember, take them personnally. And when you have the army, you can confront your complacent/doubter. This can work on everybody, because everybody, even a CEO, listens to someone; you just need to find the right person.

Now, for ROI, we need to look at the ways in which an investment may be rewarding.

• The easiest case is compliance, when there is a standard. There may also be cutting costs, increasing revenue, improving processes, or reducing risks. How do we do it?
• Increase revenue. Possibly by better leverage data, share it with partners, add more confidential data. Security is needed there.
• Cutting costs, or increase efficiency. Things can go better if payment information is readily available, which means abiding to more compliance standards.
• Improving processes. For instance, by outsourcing IT: f your data is sourced in the EU, you better be able to prove that you respect EU privacy policies.
• Reducing risk. This is our usual favorite, still present. Breaches are costly, so this gets back to cost reduction.

Finally, three reminders:

• We need to escape from strict ROI, because if we don’t, we are missing four out of five reasons that justify investments.
• We also need to make things personal, to make people visualize potential issues.
• Finally, we need to remind that many processes can be slowed down/hampered by missing data security. Associate security with real projects.

The last part of the presentation was about mitigating the problem. There has been many Oracle product references, which are not mentioned here.

It started with stolen credentials: keyloggers/spyware, social engineering/guessing, network sniffer, … What can we do about these attacks?

• Frequent password rotation. Come on, we wll know it doesn’t work, at least not by itself.
• Strong and/or multi-factor authentication. Will work, but often unpractical, and sometimes expensive, especially is specific hardware is required. I guess that the smart card industry has some communication to do about the benefits of smart cards; maybe that the business part of this presentation can help us.
• Stronger credentials. Reduce number of passwords, so it’s possible to make them stronger, and possibly change them on a reasonable basis. In another direction, use certificates.
• On another diimension, use multi-factor authorization (acces granted only if from the right user, right location, right time, …); this reduces the potential exploitation of stolen credentials.
• On a similar direction, encrypt data at rest and in motion. That can block illegal accesses, even from DB administrators.

For SQL injection, things are a bit easier. Threat vectors are mostly input validation failure and inadequate access control. The first one is under the responsibility of the application, and the second one gets us back to the access control. One interesting idea is to use behavior profiling on applications, in order to create a white list of actions allowed for a given application.

Overall, a very interesting session. In the questions, a Gartner guy noted that there were only about 50 persons in the room, which shows that nobody cares about security. I replied to him that most security-related sessions in Oracle Develop and JavaOne were full, in particular if their description includes the word “threat”. This actually proves the usefulness of the session: technical people are aware, suits aren’t.