I once had a client that had trusted in the security of one of their vendors. The vendor had been around for a long time, so it was assumed they knew what they were doing. Yet, my client got burned because the vendor didn’t have their act together from a security perspective. The company had never performed appropriate security validation of the vendor, the vendor ended up exposing data, and the client paid the price.
The company wasn’t directly responsible for the breach, but they were the ones left with a black eye. That’s why I continually prescribe a simple principle in security and compliance: trust, but verify.
President Reagan popularized the Russian proverb “trust, but verify” after signing the INF Treaty with Mikhail Gorbachev. Since then, the saying has been used everywhere, from personal relationships to taxes. But all too often, it isn’t used in security and compliance.
And as a result, well-meaning businesses get burned.
What Does “Trust but Verify” Mean?
Trust, but verify is built on the premise that mistakes happen. It’s fine to believe people who say they’ve done what they’re responsible for. But it’s another thing to know it, because you have the evidence and you’ve validated it.
Too often in the security arena, organizations take people’s word for it that requirements have been fulfilled. “We have antivirus.” “Our firewall is set up.” The organization writes a blank check to their personnel, without actually looking at the requirements in detail to be sure that everything is fulfilled according to the pertinent security standard’s specifications.
Organizations assume that because a vendor is a big company, they must have their security act together, and they must have their compliance paperwork.
It’s the difference between knowing and assuming. And you know what happens when you assume.
Get the Evidence
This principle is less about whether you trust your people and more about doing your due diligence. Your security is important, it’s not a game. Your compliance activities are protecting your organization from people who are actively trying to break into your data. That’s not something to cut corners on. Don’t take that responsibility lightly.
When you go through a compliance engagement, it’s critical to collect evidence for every line item requirement, to verify that you have your ducks in a row. It can be in the form of a policy statement, a procedure document, a screenshot, a report from a system.
Having that evidence in hand is your validation that you do in fact have this or that thing in place. So that in the (hopefully) unlikely event that something goes sideways, you have a repository that you can go back to and prove that you did your due diligence on this or that particular item. You had the right things in place, because the evidence proves it.
Verify Your Vendors
Trust, but verify applies not just to your internal compliance team, but also to your third-party partners and vendors as well. That means you don’t merely check their website to see if they’re compliant and take their word for it. Instead, request and receive the report. And don’t just get the report from your vendor, but actually read it.
I’ve been on engagements where our client had requested a report from the vendor, and they basically saw that they had a PDF with the right name and called it done. The client set the vendor’s report aside and moved on. Sure enough, as we were doing validation, we opened the PDF and quickly realized that the vendor’s security validation was for a completely different facility than the one our client was using.
In another case, one of our clients had brought on a vendor with a list of responsibilities to provide, yet the security documentation didn’t detail any of the coverage for the security services that the client was supposed to be receiving. That’s not to say that the vendor wasn’t providing those services, but we had no compliance documentation that spelled out exactly what that vendor was covering.
It’s your responsibility — not your vendor’s — to go through and make sure that the documentation your vendor provides has the right information. Never take a vendor’s word for it that the report covers what it’s supposed to cover.
It’s not that your vendors aren’t trustworthy, but that they’re human. Humans make mistakes, and honest mistakes happen all the time.
Trust but Verify Is Common Business Sense
Trust, but verify is a given in other areas of your business, and it should be a given in security as well. When your CFO asks for expense reports, those reports are validated to ensure that the numbers add up. When hiring a new employee, you get third party validation through background checks and references before extending a job offer.
The trust, but verify principle should be a given in any area of your business where you need to mitigate risk, and security is at the top of that list.
Don’t Assume, Know
I can’t tell you how many companies I’ve worked with that had a sense they were in good shape, from a security and compliance standpoint. But when we started digging in, they discovered a lot of holes in their security landscape.
It’s one thing to feel a sense of security. It’s another thing altogether to actually know that you’re secure. Trust, but verify.