Vendors, Cybersecurity Risk: Ugh

Good news if your organization experienced a cybersecurity breach recently thanks to some vendor floating around in your extended enterprise: you have plenty of company.

So says the latest report from the Ponemon Institute, which surveyed more than 625 executives about data risks posed by their vendors or other third parties. Fifty-six percent said their organizations had suffered a breach thanks to one of their vendors, up from 49 percent last year. At the same time, less than half say that managing vendor risk is a priority for their organization. Only 17 percent rate their ability to manage third-party risk as “highly effective.”

The Ponemon report is a splendid bit of timing, because I had been tinkering with some thoughts about the Equifax breach disclosed on Sept. 6. Yes, the breach is a disaster for Equifax, and an object lesson in how not to handle affairs after a breach— but then again, so what? We’ve had plenty of those cases before, from Target (2013) to Yahoo (2016) to even the SEC’s own breach, announced just last week.

Compliance officers have immensely important roles to play after a breach. That’s been covered. I’m more interested in how you can participate in managing cybersecurity risk before a breach.

The Ponemon report frames the problem nicely: as an issue of third-party risk. Look at it that way, and we can divide the compliance officer’s challenge into two parts.

First and most obvious, compliance officers can expand your pre-existing third-party risk programs— for anti-bribery, related party transactions, conflicts of interest— to encompass  cybersecurity concerns as well. After all, you are the ones with expertise in policy development and management, in due diligence and vetting. The risk here is different than, say, FCPA or collusion; but the organizational mechanics of addressing that problem at scale is quite similar.

Second, compliance officers can work with CISOs or IT security officers to assess and manage risks within the IT department itself— and that’s where I suspect many CCOs play a less active role than they could, or should.

Equifax Example of Cybersecurity

The broad contours of where Equifax went wrong are already known. The company used Apache Struts, a piece of open-source software to build “web applications”—programs  that sit on your company website and interact with the outside world. Six months ago, the cybersecurity community found a bug in Apache Struts that would let intruders take over your web applications. Equifax didn’t patch that vulnerability.

What happened at Equifax, and what has happened with the cybersecurity risk profile at all manner of organizations, is an excellent example of my second point above. Corporate IT systems are defined as a series of layers. You have the physical layer of hardware in the office. You have the network layer of connectivity to the outside world. Each of those layers do have specific risks: some knucklehead sticks an infected thumb drive into a desktop PC; your intrusion detection software is out of date and isn’t policing intruders on the network adequately.

We also have the application layer: all those applications we are adding to the corporate IT network. Sometimes you build them yourself using Apache Struts. Sometimes employees download them from the Web. Sometimes people sign up for cloud services and use those nifty apps remotely.

What’s happened is that cybersecurity risk has migrated from the physical and network layers to the application layer— but nobody is governing the risk implications of that change. At least, not anywhere near to the degree that those implications should be addressed.

This is where the CCO can sit down for a long conversation with the CISO— and probably the CFO and the board, too. This change in risk profile isn’t news to the CISO and his or her minions; they’ll all say one proper response is to hire more staff with expertise in cybersecurity for web applications, and those people don’t come cheap. The CCO can provide invaluable help articulating the consequential risks (reputation harm, breach disclosure, regulatory probes, civil litigation) and translating them back into remedial measures like staffing improvements.

Think about it: the migration of cybersecurity risk into the application layer is analogous to the migration of FCPA risk from in-house sales people to agents and intermediaries. A structural shift in how the (IT/sales) function does its job leads to an increase in (cybersecurity/FCPA) risk. That sentence holds no matter which function holds no matter which function we’re talking about.

Back to Vendor Risks

This dynamic about application risk also holds no matter where the applications come from: developed in-house, or downloaded from the Interwebs somewhere. Hence we still have that first point I raised, about due diligence and oversight. Which brings us back to the Ponemon Institute report.

Click to see report.

The news is not good. The rise of vendors in your corporate IT environment is soaring. The rise of vendor risk management efforts is increasing too, but nowhere near the same pace. According to the Ponemon report, the average number of third parties with access to your company’s sensitive information rose 25 percent last year, from 378 to 471 third parties. Meanwhile, 57 percent of survey respondents said they can’t determine whether a vendor’s safeguards and security policies will actually prevent a breach as promised. (Shameless plug here for another post I wrote about how to scope a SOC 2 audit for cybersecurity.)

We have a disconnect between developing wise vendor risk policies— which, really, aren’t that hard to sketch out at a theoretical level— and actual confirmation that vendors’ own policies, procedures, and controls live up to the risk management goals you want. Less than half of respondents in the Ponemon report said they evaluate security practices of vendors before starting a business relations where confidential information is exchange. When they do evaluate, mostly it’s to get a signature on a certification form somewhere that, yes, the vendor will adhere to security policies.

Try holding up those certifications when the bullets of public opinion start firing at your company after a breach, and see how well they deflect. The solution here needs to be about auditing, testing, documenting— and, yes, spending more money on experienced personnel to get security right the first time.

That’s a point Equifax’s new CEO may want to contemplate, because his company’s one strike has already come and gone.

Leave a Comment

You must be logged in to post a comment.