Security Labelling

On the second day of AppSec Washington DC 2010, I had a particularly difficult choice to make concerning which session to attend after the first break.

In the end, I went to Dan Cornell's talk about Application Portfolio Risk Ranking (slides) as I thought it was most relevant to my "day job". It was a great presentation and it's worth asking Dan for a copy of his spreadsheet if you are interested, but it meant I missed Jeff Williams' talk about Website Security Facts Labelling (slides).

I mentioned initiatives in this area from 2002 onwards in my previous blog post about Software Assurance Labelling. Having now read the presentation slides and related discussion on OWASP mailing lists, I can see Jeff Williams' ideas have moved forward significantly. He has even produced a Security Facts Tool to help build demonstration security facts labels, for example:

Well, that's a long label. The concept is based on his earlier work, and research on related consumer labelling examples from other industries (see presentation slides). The label includes information about what major modules and code libraries are used, the platform components, interfaces and connections, what types of sensitive data are collected, processed, stored & transmitted. But it also suggested that it should include some concept of how security risks have been reduced—in this case, whether the risks in the OWASP Top Ten 2010 have been addressed, and what common security practices are in place in the development lifecycle using those defined in the OWASP Software Assurance Maturity Model. The label might benefit from having the target site/application name recorded.

But the key finding from his research was the precise content of the label does not really matter that much. In his words:

Whatever you think about the appropriateness of the items included, one area where I think this labelling could be used immediately is in procurement. Organisations will often ask potential bidders for examples of previous work. The design agencies/software houses could be asked to complete the security facts label for whichever web products they choose to showcase—they should have this information available, they can use the tool quickly to produce a label and it's not going to become released to the public domain. The acquisition team will then have greater knowledge of the technologies and processes used, to help make more informed decisions about software choice instead of "does it look nice". The actual specification and contract will need to be more explicit about security, but for examples of previous projects, this would work very well.

So the concept is to make security concrete and visible—see the final "Security in Sunshine" slide at the end of the presentation slides. And, contribute your ideas and feedback.