Why Companies Should Have ‘Zero Trust’ in Their IT Suppliers

Edited excerpts follow:

THE WALL STREET JOURNAL: Jerry, earlier you said, “You can never give absolute trust to a vendor.” Why not?

MR. PERULLO: I like to say “zero trust” is kind of what we’ve been saying for 30 years, but this time we really mean it: The whole idea that systems, people, any entity was meant to have just enough permissions to accomplish what they needed to by design, and not anything more.

Now we’re really seeing that when we see supply-chain threats. With the amount of efforts that vendors are going through to make sure they are delivering secure products, that’s wonderful. But as a user of those products, you should never trust anything. That’s what “zero trust” means. So when you bring in a product, whether it’s something third-party or even anything internal, it should be designed and deployed in a way that even if it were completely malicious, it has limited ability to affect anything.

WSJ: Michael, what kind of response should a CISO expect from the tech company that has been hacked?

MR. OVERLY: There used to be a balance that you could strike, maybe not absolutely equitable, but a balance in technology contracting with suppliers. And what we’re seeing today is a lack of that balance. When you talk about, “What can we expect from a business partner in the event of a hack?” The answer is, in many instances, “Little or no help.”

That you’ll get late notice, potentially, of a hack; that in fact the vendor may have been aware of the hack for weeks, months before revealing it to you, in some cases, years. And then if you do find that they are responsible for a hack, you have the problem of the contract limiting the vendor’s responsibility to potentially a trivial amount of money.

WSJ: Jerry, have you seen that happen? How have you handled it?

MR. PERULLO: I’ve actually had exposure to that on both ends. On the back end, where there’s an incident, and what are you going to do; and on the front end, where procurement teams try to pre-empt limitations on liability and say, “Well, if there’s an issue we want you to cover it.”

There is this real asymmetry between the value of the contract, when it comes to cybersecurity, and the value at risk. And that has not been common in operational risk before. Generally, when you look at a lot of contracts historically, there was, “If things go really, really bad, we’re going to unwind the whole deal and get our money back.” Or there may have been business loss as a result of that contract going south. But now you can have an existential threat from a very low-value contract, and especially with small vendors.

I have not seen a lot of efficacy in efforts to stop unlimited limitations on liability because, for one, if you have a critical infrastructure provider take a hit as a result of a small vendor, and you try to go after what that would cost the critical infrastructure entity, it could be in the billions of dollars. And you’re not going to recover that [from the small vendor] no matter what the contract says. They’re just going to disappear before you can do that.

And with the larger vendors, that’s where they are going to have the most leverage and the most legal power, so you’re not going to get that anyway. You really have to just insulate how much impact you can feel if things go terribly wrong with any given vendor or product.

WSJ: It’s a really good point, that a small tech provider can be the source of a giant problem if they are hacked. Michael, when you’re negotiating with vendors, how can you negotiate better provisions into the contract?

MR. OVERLY: This is a very good point that Jerry made about smaller vendors. And this is sort of Job One before you sign the contract: diligence of the vendor, looking at what they do with regard to information security, but also financial wherewithal.

Regulators in financial services have given direction on this. Which is that you really need to look at this from a risk perspective overall: “What kind of data are we putting in play?” “What’s the financial stability of this particular vendor?” “What would happen if we do have a compromise?”

The point is to have a sufficient level of liability that the vendor or business partner actually has an interest in performing the agreement. A lot of times notice provisions in a contract would say, if there’s a breach, the vendor was required to give the customer notice within a certain amount of time, generally 48 hours, maybe 72 hours, depending on jurisdictions.

The problem is that those provisions are frequently worded in terms of: “The vendor will give notice once it confirms the incident.” And the problem with that is confirmation can be very flexible. Is that today? Is that a year from now?

WSJ: The aftermath really depends also on the kind of unwritten relationship you have with the tech company, right?

MR. PERULLO: Yes, that’s true. But what’s interesting is that you could really see two halves to the negotiations: pre-emptive and reactive. We talked a lot about the reactive: “Well what if something goes wrong? What, contractually, can we have?”

On the other hand there’s the proactive things that you can do in the contract provisions. Instead of just focusing on the “What if?” and the notification requirements, and the liability, we also focused on very specific controls that we wanted to see that vendor have.

We called it “eating our own dog food.” We said, “What do we think would be reasonable to be asked of us? And not only what we do, but what we do well?” We were very specific about, “What does the vendor do for us?” “What could happen that would be bad?” “Let’s model that out. If they hold our own data then obviously if they lose our data that would be bad.” “Well, what protects against that?” Things like data leakage control, or the ability to extricate data, very specific technical measures.

So right in the contract language we would say that they are to implement protection against the egress of data, very specific things like that. People were much quicker to agree to actually implementing controls, spending a buck, and getting the program up to snuff.

MR. OVERLY: There are three parts to addressing information security and vendor and business-partner relationships. We’ve touched on two of them but No. 3, which is the one a lot of people fall down on, is post-contract policing. You have a contract that says you need to have egress and ingress cameras so that you can monitor who’s going in and out of a secure building. Excellent. We did a deal like that in India, where we went out and looked at it. And, sure enough, the vendor had cameras at every single point. The problem was those cameras weren’t being monitored by anyone, they weren’t connected to anything.

So going out and following up is very important, walking around, looking at what the vendor is actually doing. If those things were employed, a lot of times that can really mitigate the risk that’s presented by the types of cases and incidents that you just described.