It’s a well-known fact that vendors can be a weak point within your organization’s security posture. The Internet is littered with stories of vendors falling victim to a security oversight, the latest malware, or someone with too much time on their hands. Our most recent Incident Response Insights Report found threat actors frequently targeting supply chains.
While I’m out and about visiting clients, and occasionally performing tabletops, we often speak about the roles that vendors fulfill for the organization. For a typical financial institution such as a bank or credit union, an average array of vendors may host a website, print and mail account statements, help with marketing campaigns, provide cloud storage solutions, and assist with backups. And more often than not, that’s just scratching the surface.
Proactively Working with Vendors
Far too often, organizations are assessing their risk posture by looking inwards and forgetting the larger risk landscape, including data and systems outside of their purview. When dealing with vendors, security begins not at the point of implementation, but far sooner.
During tabletop exercises, I ask clients what measures are undertaken to ensure their data won’t become entangled with the next vendor-related compromise. The question almost always elicits a mild groan as the client understands all too well that their organization can do everything right, and still end up in the papers due to a vendor. The responses I receive are fairly sensical, and range from service level agreements (SLAs) to performing a vendor risk assessments. For more mature organizations, the preparation begins from the moment a vendor’s inclusion is considered.
Vendor Support During an Incident
One of my favorite questions to ask a client is whether the vendor – an organization that may hold significant amounts of the client’s sensitive data – has been tested to see if they can assist during a cybersecurity incident? Almost universally, the response is “no.”
As an incident responder, I have seen firsthand the trials of requesting support from a vendor during an incident. During one such engagement, a client’s vendor was suspected to have lost critical data sets and I was asked to assist with the investigation. The client’s vendor was asked for network and operating system logs and, eventually, forensic images. Unfortunately, these requests took well over two weeks to fulfill, which is nothing short of an eternity during an emergency situation.
Test Your Vendor
So where do we go from here? The old security adage “trust but verify” comes into play. You must test your vendor.
A common tabletop exercise that often bears fruit is to identify a non-critical system hosted or operated by a vendor, and ask the vendor to supply network or operating system artifacts (e.g., firewall logs, Windows event logs, etc.) due to ‘observed suspicious activity.’ Then you wait to see what happens.
When performing these exercises on behalf of clients, it is surprisingly rare to have a vendor be able to provide adequate support. The results from these phone calls to vendors include:
- Vendors that are unable to provide logs because they are co-mingled with other client data.
- Vendors that lack timely support – a request may take a week or more to get routed to the right internal contact.
- Vendors that require a ‘premium support contract’ to fulfil a request.
- Clients that discover their vendor isn’t logging what they had specified (or thought they had specified) within their contracts.
These exercises are very simple to perform, don’t require ample resources, and allow you to understand if a vendor will be able to provide support during a cybersecurity incident.
Coffee
The next time you’re reading about the latest vendor compromise and waiting for your coffee to kick in, consider reaching out to your key vendor to involve them in an exercise. You may be pleasantly surprised or, at the very least, get to know your vendor a bit better.
