Last week I had the opportunity to attend and speak at the International Common Criteria Conference (ICCC) in Doha, Qatar. This was a first in a number of areas: first time keynoting for longer than five minutes, first time attending a compliance-focused conference, first time speaking on compliance as a topic, and my first time in Qatar (or any Persian Gulf country for that matter).
My keynote was about vulnerability management in the compliance space, particularly the notion that we can ever have “zero known vulnerabilities” in software, which is something that Common Criteria strives for when performing certification (and the next day be darned, we only care about zero known vulnerabilities on the day we give you a certificate!). That’s just not possible when last year there were close to 30,000 CVEs and this year promises to be much higher.
It also focused on compliance reciprocity — the means by which I can be accepted where one compliance framework is demanded and another similar one is achieved. For example, if certificates A and B have reciprocity, and I already have certificate B, when I want to enter a market that requires certificate A I don’t have to pursue it because of mutual recognition. This means that I, as a vendor, can save time, effort, and money not chasing a certifcation that is functionally equivalent to one I already hold. This also means that those in the market where certificate A is required can avail themselves of my software and services faster since certification and testing takes time, or at all, because I don’t have to invest in the certification to obtain it to enter into that market to begin with. I also don’t have to make that difficult decision on whether the market is large enough to warrant my investment.
The message was well received and I hold out hope that a common sense view of working towards both of these efforts will start to happen. My goal was to point out facts — including the similar talking point of prior talks about who these vulnerabilities are “known” to (in other words, the proprietary vs open debate, backed up with data).
A few folks even mentioned that I “said the quiet part out loud” which makes me believe that this is known by more than are willing to admit it, but perhaps they just don’t know what to do about it. That makes sense, as this is a difficult problem to solve. How do you accept that there are issues that may be security-relevant, and you just accept that they are there without remediation?
Well, in my view, by accepting the fact that all use of software carries risk and the return on investment for chasing zero known vulnerabilities is tantamount to burning cash with nearly zero true risk avoidance. It isn’t any clearer than that. It fractionally reduces risk and ignores the places where real risk lies: the people and processes that make these breaches continue to happen.
Also appreciated being able to spend a few days with other Red Hatters who were at the conference as well demoing the sec-certs open source compliance tool that got a lot of interest as well.