Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: Trust But Verify
Quick Take
On this week’s episode, the Compliance Unfiltered, the guys dig in to those three little words in the world of compliance, “Trust But Verify.” But honestly, what the heck is the topic even about?
- What does trust but verify mean in practical application?
- What should you do to best leverage the notion of trust but verify?
- What are the best practices to follow?
The CU guys will tackle all these topics and more, on this week’s episode of Compliance Unfiltered!
Remember to follow Compliance Unfiltered on Twitter and Instagram at @compliancesucks
Read The Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s so hard to keep organized, and it requires a ton of expertise in order to survive the entire process. Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less.
Now, here’s your host, Todd Coshow, with Adam Goslin.
Well, welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow, alongside a man who is in a celebrating mood today, Mr. Adam Goslin. Adam, how the heck are you? Oh, morning, I’m doing good. Just living the dream today. It’s hard to argue, hard to argue with living the dream, sir. Today, we’re talking about something that’s near and dear to everybody’s heart in the compliance space, but should probably get a little bit more run in mainstream compliance than it usually does, and that is trust but verify.
So Adam, what’s the topic today really about? Well, I started thinking about this particular topic because I had a client that was trusting in the security of one of their vendors. And what I mean by that is this particular vendor, they’ve been around for a long time. The client was going under the guiding assumption that this particular vendor knew what they were doing in the security and compliance space. But my client ended up getting burned. The vendor really didn’t have their act together from a security perspective. They whitewashed their approach to things that the client hadn’t done all the stuff they were supposed to do. They weren’t as it turns out going through a third-party audit assessment against any particular standard. The company hadn’t done their due diligence with this particular vendor. And the problem was, the vendor ended up exposing the data, but the client ultimately is the one that ended up paying the price. I mean, sure you can go back to fill in the blank vendor and hold them accountable. You can tell everybody under the sun that it really wasn’t me, it was somebody else.
I mean, if you think about it, I love talking about this one, but like the Target breach. Everybody under the sun refers to it as the Target breach. Now reality was, their HVAC vendor was at the core of how they ended up getting their butts handed to them. But is everybody going, Oh, it’s the HVAC vendor that screwed Target? No, nobody says that. They just call it the Target breach, Right? And so yeah, the end client ended up getting caught up in the mix, getting their name in lights and all this fun stuff, and really paid the price. It wasn’t their direct responsibility to be personally accountable for the vendor security. And they didn’t use trust, but verify when they should have, that’s really at the root of it.
And I was doing a little bit of digging into, where the hell did trust, but verify come from? And I don’t know if you knew this, but it was Reagan that pop popularized the Russian proverb, after he signed the INF treaty with Mikhail Gorbachev. And since that time, people have been using it all over the place, through personal relationships and taxes. So, unfortunately too often it’s not used in the security and compliance space. And as a result, businesses that really are trying to do the right thing, they end up getting burned.
So what does trust, but verify mean in reality? Like I get it, I know the term, I remember hearing Reagan say it, but I’m curious, what does that mean in practical application? Well, if you think about it, it’s built on a premise that mistakes happen. It’s okay to believe people that are saying that they’ve done what they should have done, or they’ve done what you think they’ve done. And then, it’s another thing to actually know it, because you’ve done the due diligence, you’ve gathered the evidence, you’ve discussed things with them, and you’ve done all of your appropriate validation. There’s a gigantic difference between those two. And part of the problem in the security arena is, that in the grand scheme of things, you know, think about it, right? I mean, you know, how long have people really been taking this stuff seriously? And even if we were to go back to, when did people really start taking this stuff sort of seriously at all? I don’t know, maybe you’re going back two decades, maybe two and a half, something along those lines. But really over the last, I don’t know, I want to say maybe six years or so, I’ve been seeing a constant march toward organizations starting to take things more and more seriously.
Part of the reason for that is, that literally companies have just been getting their butts handed to them left, right and sideways for not doing so. So, you hear the lip service, right? We have antivirus or, we’ve got a firewall. You’ve got antivirus, but is it working the way it’s supposed to be working? And we’ve got a firewall, is it even configured correctly and up to date, and patched? So the organization in many cases, they go and they write blank checks, even to their internal personnel without going and looking at requirement level details. So the trust, but verify, I mean, it applies across the board. And the one thing that I’ve found the most interesting, as I’m going through engagements, and being exposed to different things in the space, is especially with large organizations, companies will say, oh, well, it’s so-and-so, so, and they’re huge, and they’ve been around for a while, so they must have their act together. And there’s a certain amount of comfort that they get in dealing with the big company. And the funniest part about it is, I’ve seen some freakin huge companies that just do not have their act together when it comes to their security and compliance. So, what does this all mean? The bottom line, is the difference between knowing, verses assuming. And you know what happens when you assume. Besides the assume point, you made a really good point about the cybersecurity vertical as an entity, is very much in its infancy. So focus on the foundational pieces earlier, it’s extremely important for any organization.
Now my question to you is, what does one need to leverage for the notion of trust, but verify? How do you do it? Well, at its root, it’s all about getting evidence. And I used the phrase before doing your due diligence. It’s less about whether or not you trust people, and it’s really about doing that due diligence. The security of your organization is important. It’s not a game. It’s not a gamble. It’s nothing you want to roll the dice on. You need to take it seriously. And so your compliance activities, that’s what’s actively protecting the organization from folks, that would actively try to gain access to information, data, and intellectual property that you’re attempting to protect. So you don’t want to be cutting corners on it. You want to make sure that you’re taking that responsibility seriously as you go through. So when you’re going through a compliance engagement, and this is more on the internal side of the fence, it’s really important that you’re actually collecting evidence for every line item requirement.
We talked about this on one of our prior podcasts, and I used this example a fair amount. The example is, when somebody is going through their compliance thing, they go to the IT crew and they’re like, so do we have antivirus? And they’re like, check, we have antivirus. And everybody goes, whew, okay, great. Now let’s go to bed. We’re going to just blanket check off everything in the AV arena and keep the party moving. Meanwhile, you start getting into the antivirus arena. And it’s not just do I have antivirus? there’s all sorts of different things that we need to go in and validate, right? So like, how many machines are supposed to have antivirus? Well, there’s 587 machines that need antivirus. Okay, well, do we have 587 machines showing they have antivirus? It’s stuff like that. It’s are the updates that are supposed to be getting spread through the organization being acquired in a timely fashion? In terms of both the engine updates for your AV solution, and any signature files or heuristics that may come into play, are those parameters getting both pulled in from source, and then spread through the organization appropriately? And really when you look at that, you look at the core elements, right? Does it look like it’s set up properly to do this? Okay, that’s cool, check. Don’t stop there, go off and actually sample, whatever, 5% or 10% of your instances, and or preferably pull a report that shows, yep, everything in the environment, all 537 machines are supposed to have their antivirus, and have it up to date. Make sure that those things are actually flowing through your logs from your antivirus, endpoints, and master console. Are those going back into your logging solution? Do we have 90 days of that immediately accessible? A year’s worth of logs ultimately accessible? There’s a lot of things, but I can’t even begin to tell you, especially with the AV example, because it’s the most popular one I like, because the most popular one I run into is everybody going, yeah, yeah, we got AV.
So the bottom line is, is that you need to collect up that evidence line by line against each individual requirement, making sure, yep, we have that. Yes, we have that. Don’t make the freaking assumptions. The stuff you’re gathering up, maybe it’s a policy document that’s supposed to contain coverage for a particular requirement statement for whatever certification you’re going up against. A lot of organizations will have a, I don’t know, a pray and spray approach with their policies, where they’ve got a policy for every single little freaking thing that they do. In another case, there’d be the organization that uses the, I don’t know, I use the the Lord of the Rings reference to the policy documentation, where it’s like one policy to rule them all type of thing, right? And especially, it’s a lot more difficult to do when you’ve got the pray and spray with the policy stuff because then, I literally have a policy for every single little fricking thing that I need. But when you’re using the one policy to rule them all, it’s easy to go, oh, well, we only have one policy, I’m just gonna go ahead and attach it and keep it moving. But does that policy actually contain the requirement, and the language to support fill in the blank requirement statement?
Especially when I go through, you know, with new organizations, and I’m bringing them through it for the first time. In many cases, they’ll feel like, oh my gosh, you’re really bringing this to the Nth degree. Well, I mean, part of my job is to make sure that you’re doing this right. And just because nobody else decided to ask the question, doesn’t mean that was an appropriate approach. If you’re going to do it right, then you’ve got to bring it down to that level. So whether it’s policies, procedures, or you’re grabbing a screenshot, a report, a config file, some type of a written explanation that goes along with your evidence. Whatever you are supposed to have line by line, bring it down to that level. And that way, you can really be assured of a couple of different things. Number one, you’re assured that yes, we actually have this in play. This is the I’m able to sleep at night notion, if you will. The other thing that you gain through that process is in some cases, the organization will have a security and compliance consultant that’s their external, yet internal resource as a sounding board or QA for their organization. Well now as you’re going in, making sure you’ve gathered up this evidence properly, you’re moving it over to your security compliance consultant, now you have a better notion that you’re actually going to have a high success rate, a higher success rate with the submissions to them,and less rejections. But more importantly, as the evidence flows through and over to the assessor, now you’re going to end up, number one, raising a lot fewer red flags with the assessor. They’re not going to have to come back asking as many questions, things are actually going to be buttoned up, but you’re going to clear more items through.
It’s that same premise in the development arena, where you’re developing a new tool or a new product. Effective to, you know, catch things you otherwise would miss through the dev process. Is it easier to catch those as you’re literally writing the upfront requirements for what it is we need to go do? Or is it better to catch it after it’s been defined? You know, been spec’d out, gone through development, unit testing, integration testing, change control up to two or three environments. Only to have somebody in the business side turn around and go, well, that’s not what I wanted. It just makes sense. So getting all of that stuff in line, that makes it a lot easier for the relationship with the assessor. And finally, the last real benefit, which is what a lot of organizations don’t focus on enough is, now that we’ve done this properly, now that it’s gotten through the battle testing of your security or compliance consultant’s hands, it’s gotten through your assessor’s hands, we’ve thrown the compliance party. Well now when I get, whatever, let’s say it’s 10 months later, and we’re going to be starting up our compliance engine again, to go back through next year’s whatever. Now those people a year from now on your next year’s track, they have a rock solid repository of, who did what? What evidence worked? What did the assessor accept? What were the types of pitfalls they ran into with gathering this? You’ve got a top to bottom, just like Bible, if you will, for what we need to go do this time. Unless you’re switching from whatever, PCI 3.2.1 to version 4.0, not that that’s gonna happen anytime soon.
But the reality is, unless you’re folding in a completely new standard, or your standard switched from version to version, which doesn’t happen like every year. Now you’ve got consistency year over year. Doing that validation is just absolutely huge. And finally the last piece of this is, in the unlikely event that something in your security or compliance realm goes sideways, right? You happen to get nailed by some zero day, let’s say, and data gets exposed, or some type of a data breach occurs. Hey, you want to know what? As part of that discussion, dialogue, forensic investigation. Now you’ve got things in hand where you can show, I was being diligent. I was attempting to do everything under the sun. We did stuff when we were supposed to. You’ve got all of this just sitting right there at your fingertips, and now I can go ahead and leverage that information to be able to support, and better yet, proactively protect the organization you’re trying to protect in the first place.
No, it’s a great shot. No, I expect this notion extends beyond the organization’s four walls, yes? Oh yeah, and if you think about it, what we’ve been talking about so far, it’s just the internal validation and trust, but verify process that you need to go through. But it’s not just your internal mechanisms, you need to extend that out to your third-party vendors and partners as well. We were talking earlier about the lack of due diligence and validation that was performed by that client I was generically referring to earlier. So the reality is, you don’t want to just go check out the company’s website, see that they have a badge for fill-in-the-blank compliance sitting on their marketing page, and then go, oh, okay, well, we’re good. Instead, go through one of the premises for many of the compliance standards that are out there that are more prescriptive, and quite frankly, should be done period. Even if your not, you need to be gathering up your list of vendors annually, going through that list of vendors, collecting up updated information from them about their security and compliance.
So go compile your list.
Usually what I’ll do is, I’ll have the organization go through and identify where the starting point for the gathering of that list is. I’ll literally have them go to their accounting crew, and what I’ll tell them to do is, I say, I want you to tell your accounting crew to go pull a list of anybody, for any reason, that they’ve paid in the last year period. What organizations or people does that list include? That way I get a full list. We’re not missing stuff as we go through that process. Now, is everybody on that list going to be somebody that I need to go and put the screws to for security and compliance? No, I don’t know, maybe one of your vendors is office supplies, right? I don’t necessarily need to have my pen and pencil vendor going through the full scale battalion of security compliance. But if it’s your outsourced development team, or it’s the organization you’re using to print your monthly statements to your clients, that has all sorts of information about the client services they’re leveraging, things along those lines. Maybe your business is printing a whole bunch of stuff on behalf of your clients. So you want to go down the list of the vendors. And usually what I’ll do is, I’ll add some columns. Does this vendor get exposed to any of our or our customers PII information? Or any credit card or healthcare related information? So I’ll usually put PII, PCI and PHI in columns, and we’ll just put X’s down there, and we’ll go through and review them all. If I have vendors that are on that list, like the pen and pencil vendor, I’ll go ahead and knock them off the list. But then, you can go down and have vetting procedures for those that are being exposed to PII, PCI, or PHI data. Once you’ve got those identified, then go to the vendors and request their security and compliance reports.
Here’s the important part about this. Because I’ve seen this done, I can’t even tell you how many times. Oh yeah, no, we totally went out, we asked all of our vendors for their updated security and compliance stuff. We’ve got them, and yeah everything’s good. And meanwhile somebody else comes in, goes in and looks at the information that was delivered, and there’s a bunch of problems with it. I’ve seen engagements where the organization received a PDF from the vendor that had what looked like a correct name for what would have otherwise been a security and compliance document. However, the content of it doesn’t have anything to do with it. I’ve seen clients that will gather their reports, they’ll claim that they’ve reviewed them and blah. Meanwhile what happened in reality is, someone internally basically just took them out of the repository or receipt process, and stuck them on the shelf, they didn’t even look at them. So one of the things that I had also seen, was the vendor coughs up their documentation, and the client was using, let’s say, just call it Facility A, right? And the compliance documentation they received was for Facility B. Well, that’s cool and everything, but that doesn’t have anything to do with any pertinence to what we’re doing here. In another case, I had a client that went out, they requested their vendor security documentation, and the vendor themselves had a suite of services that they offered. Let’s say for the sake of this discussion, there were 10 different services that were on offer, and the client was using three of those services. Well, when you go in and you start actually reading what the organization had provided for security compliance documentation, I’ll be damned if any of the three services that they had on there were even on the list. And it turned out that the coverage of what the vendor had provided documentation for, had nothing to do with the services the client was actually consuming. So meanwhile, they’re sitting there with compliance documentation for services they aren’t consuming, and haven’t done their job. So a lot of people will look at it like, hey, it’s not my problem, this is the vendor’s issue or whatever. But the reality is, is that it’s on you to make sure that these vendors are doing what they’re supposed to do. That they’re providing the right information, and you’ve actually gone through and reviewed it. You take into account your scope of consumption, making sure that you’ve got eyes dotted T’s crossed and everything’s good. Trust, but verify.
Now, I gotta ask at this stage, any parting thoughts and shots for the folks. The reality is that a lot of people, if they made it to this point, they were probably walking in with a trust, but verify, it just makes common business sense, and it’s true. But sometimes when you take a minute, pause and kind of think it through. Especially after hearing examples of all the things that I’ve seen and run into. It’s good to be able to get those insights, get those inputs, put it into your context.
Too many people will make those assumptions as they go through this process. It’s important that you go through and do your cross checks, and double checks. You know, your CFO asks you for an expense report, they’re usually validated to make sure that all the numbers add up. When hiring on a new employee, you go through and get background checks and references before you extend job offers. The trust, but verify principle really should be a given for anywhere where you need to mitigate risk within the organization. And one would think that security should be at the top of that list.
So a lot of the organizations, especially when I would start working with them, they would have the sense that they were in a good place, from a security compliance perspective. It’s actually really interesting, the organizations that truly believed that, hey, we’re good, we’ve been doing our thing for, blah, blah, blah, for this period of time. And it’s entertaining when I take those organizations from that statement, to then pulling them through an appropriate process and all that fun stuff.
At the back end of it, many, many of them will say, whoo, I thought we were good before, but now I know that we’re good. It’s a great sense of security for the organization to be able to know that they have it together. Trust, but verify.
Man, that’s the good stuff right there. I’ll tell you what, Compliance Unfiltered listeners, next week in observance for the July holiday, we’re going to take a vacation. We hope that you have a happy, safe and healthy holiday, and we’ll see you in a couple of weeks. Well, that’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow. And I’m Adam Goslin. Hope we help to get you fired up to make your compliance suck less.
