The problem of security information sharing

In a previous post Sharing security information I suggested that fragmentation of knowledge is a root cause of security breaches.

I was thinking about the problem of sharing data loss information this past week and I realized that we are saturated with solutions, technologies, policies, security frameworks and security standards – COBIT, ISO27001 etc..

The German physicist Helmholtz identified three stages of creativity: saturation, incubation and illumination.   We appear to be in the saturation stage right now.

Henri Poincaré identified a fourth step that follows the other three. Verification is putting a solution into concrete form and checking it for errors or usefulness.

In the early 1960s, the American psychologist Jacob Getzels proposed that a preliminary stage of creativity involves formulating a problem.So let’s start with formulating the problem of security information sharing.

People and their employers are unwilling to discuss the details of security events that happened, their security vulnerabilities,  the damage in dollars was actually caused, how the events were discovered, how the threats that exploited the vulnerabilities were mitigated and most importantly – how well their current security products perform.

In our threat analysis work, we run into these problems daily.  We offer an excellent free threat modeling tool from our colleagues at PTA Technologies called PTA – Practical Threat Analysis. I think we have over 15,000 downloads. Users sometimes have questions that require taking a closer look at their threat model but it almost never happens because of the fear of disclosure. On one occasion – a user shared his threat model after obfuscating the data (you can download the software here – free risk assessment software.)

Here is a possible solution to the  problem we just formulated:

• Define a language for describing a security event -  having a canonical language to describe things is a basic requirement for sharing information between people.
• Build models of attackers, vulnerabilities, assets under attack and security countermeasures in order to describe loss events using the common language.
• Enable people to build, maintain and share models anonymously. What is important is not the identity of the company who had the loss event, but the details of the model.
• Use the models to measure the loss impact and the effectiveness of their security countermeasures in dollars. This provides a security metric that will enable people to look at models and compare ‘apples’ to ‘apples’ without involving marketing factors such as product features and distribution channels.