As we mentioned last post, after you figure out what risk means to your organization, and determine the best way to quantify and rank your vendors in terms that concept of risk, you’ll need to revisit your risk assessment; because security in general, and each vendor’s environment specifically, is dynamic and constantly changing. We also need to address how to deal with vendor issues (breaches and otherwise) – both within your organization, and potentially to customers as well.

Ongoing Monitoring

When keeping tabs on your vendors you need to decide how often to update your assessments of their security posture. In a perfect world you’d like a continuous view of each vendor’s environment, to help you understand your risk at all times. Of course continuous monitoring costs. So part of defining a V(IT)RM program is figuring out the frequency of assessment.

We believe vendors should not all be treated alike. The vendors in your critical risk tier (described in our last post) should be assessed as often as possible. Hopefully you’ll have a way (most likely through third-party services) of continually monitoring their Internet footprint, and alerting you when something changes adversely. We need to caveat that with a warning about real-time alerts. If you are not staffed to deal with real-time alerts, then getting them faster doesn’t help. In other words, if it takes you 3 days to work through your alert queue, getting an alert within an hour cannot reduce your risk much.

Vendors in less risky tiers can be assessed less frequently. An annual self-assessment and a quarterly scan might be enough for them. Again, this depends on your ability to deal with issues and verify answers. If you aren’t going to look at the results, forcing a vendor to update their self-assessment quarterly is just mean, so be honest with yourself when determining the frequency for assessments.

With assessment frequency determined by risk tier, what next? You’ll find adverse changes to the security posture of some vendors. The next step in the V(IT)RM program is to figure out how to deal with these issues.

Taking Action

You got an alert that there is an issue with a vendor, and you need to take action. But what actions can you take, considering the risk posed by the issue and the contractual agreement already in place? We cannot overstate the importance of defining acceptable actions contractually as part of your vendor onboarding process. A critical aspect of setting up and starting your program is ensuring your contracts with vendors support your desired actions when an issue arises.

So what can you do? This list is pretty consistent with most other security processes:

• Alert: At minimum you’ll want a line of communication open with the vendor to tell them you found an issue. This is no different than an escalation during an incident response. You’ll need to assemble the information you found, and package it up for the vendor to give them as much information as practical. But you need to balance how much time you’re willing to spend helping the vendor against everything else on your to do list.
• Quarantine: As an interim measure, until you can figure out what happened and your best course of action, you could quarantine the vendor. That could mean a lot of things. You might segment their traffic from the rest of your network. Or scrutinize each transaction coming from them. Or analyze all egress traffic to ensure no intellectual property is leaking. The point is that you’ll need time to figure out the best course of action, and putting the vendor in a proverbial penalty box can buy you that time. This is also contingent on being able to put a boundary around a specific vendor or service provider, which may not be possible, depending on what services they provide.
• Cut off: There is also the kill switch, which removes vendor access from your systems and likely ends the business relationship. This is a draconian action, but sometimes a vendor presents such risk, and/or doesn’t make the changes you require, so you may not have a choice. As mentioned above, you’ll need to make sure your contract supports this action. Unless you enjoy protracted litigation.

The latter two options impact the flow of business between your organization and the vendor, so you’ll need a process in place internally to determine if and when you quarantine and/or cut off a vendor. This escalation and action plan needs to be defined ahead of time. The rules of engagement, and the criteria to suspend or end a business relationship due to IT risk, need to be established ahead of time. Defined escalations ensure the internal stakeholders are in the loop as you consider flipping the kill switch.

A good rule of thumb is that you don’t want to surprise anyone when a vendor goes into quarantine or is cut off from your systems. If the business decision is made to keep the vendor active in your systems (a decision made well above your pay grade), at least you’ll have documentation that the risk was accepted by the business owner.

Communicating Issues

Once the action plan is defined, documented, and agreed upon, you’ll want to build a communication plan. That includes defining when you’ll notify the vendor and when you’ll communicate the issue internally. As part of the vendor onboarding process you need to define points of contact with the vendor. Do they have a security team you should interface with? Is it their business operations group? You need to know before you run into an issue.

You’ll also want to make sure to have an internal discussion about how much you will support the vendor as they work through any issues you find. If the vendor has an immature security team and/or program, you can easily end up doing a lot of work for them. And it’s not like you have a bunch of time to do someone else’s work, right?

Of course business owners may be unsympathetic to your plight when their key vendor is cut off. That’s why organizational buy-in for criteria for quarantining or cutting a vendor off is critical. The last thing you as a security professional want is to be in a firefight with a business leader over a key vendor. Establish your criteria, and manage to them. If you are overruled and the decision is to make an exception, you can’t do much about that. But at least you will be on record that the decision goes against the policies established within your vendor risk management program.

Breach Exposure

If you have enough vendors you will run into a situation where your vendor suffers a public breach. You will need to factor that specifically into your program, because you may have a responsibility to disclose the third-party breach to your customers as well. First things first: the vendor breach shouldn’t be a surprise to you. A vendor should proactively call their customers when they are breached and customers are at risk. But this is the real world, so we cannot afford to count on them acting correctly. What then?

This comes back to your organization’s Incident Response playbook. You have that documented, right? As described in our Incident Response Fundamentals research, you need to size up the issue, build a team, assess the damage, and then move to contain it. Of course this is a bit different for vendors, because there is a lot you don’t know about their systems. And depending on the vendor’s sophistication, they might not know either.

So (as always) internal communication and keeping senior management appraised of the situation are critical. You need to stay in close contact with the vendor, constantly assess your level of exposure, and decide if and when you need to disclose – to your board, audit committee, and possibly customers.

Also, as described in Our IR fundamentals research, make sure to work through a post-mortem with the vendor to make sure they learned from the experience. If you aren’t satisfied that it won’t happen again, perhaps you need to escalate to the business managers on your side, to reevaluate the relationship in light of the additional risk in doing business with them. Additionally, use this as an opportunity to refine your own process for next time a vendor gets popped.