Books and Their Covers

We're all familiar with the saying, "Never judge a book by its cover," and this holds up in information security as well as anyplace. Oddly enough, in information security, so does the inverse concept that we should never judge a cover by the book.

What this means is tied to both audits and incidents.

Just as a literary classic may have a damaged cover, an exceptional company you want to do business with may have suffered an incident. This single occurrence shouldn't remove them from consideration. One incident is, after all, a moment in time. Everyone experiences failures. What we should be concerned with is their handling of the incident and if it indicates a larger trend.

To evaluate a vendor in this situation, we're going to need to take a deeper look, which means going well beyond any SOC3 or STAR attestation. If the risk is significant and the deal justifies the effort, we want to sign some non-disclosures and dig into the controls and practices as well as their security efforts over time. We want to see that they are adequately mature, doing what we need them to do, and not a pretty cover masking a bad process.

And for the inverse, just because someone has a clean statement or attestation of compliance, does not mean the business is in good hands. While maturity assessments and audits over a time period are better, they do not indicate that the business is immune to security failures. There are no truly secure organizations, and all controls, no matter how perfectly designed, can be subverted. Our concern needs go beyond claims about security controls to examine how they deal with unexpected developments and failures of those controls.

How do we dig into this? By asking how they deal with failures in controls. Be specific. If the claim is regarding API security, discuss API failures and the aspects of incident identification and handling. Ask about testing and involve people that understand what is being discussed. Involving someone with audit experience is a good idea if the risk justifies the effort.

So if our third-party vendor risk management program involves checklists and doesn't look deeper than a security attestation, we may want to refine that process and drive evaluation to a deeper level based on business risk.

Add steps to look for incidents. Add questions about security practices over time. Invest the time and effort risk management demands, and don't use a one size fits all approach to third-party risk. Checklists can mask risk.

Every book is different, and a thin book with a bad cover might be a brilliant work of fiction, while a massive volume with institutional endorsements could be a waste of paper. Look past momentary criticisms and polished images because your business depends on selecting the right partner to enhance your competitive position.