In the past several weeks, we have seen the effects of ignoring the risks of our third-party vendors. They can quickly put your enterprise in peril, as this story about a third-party provider to the airline industry.  In this case, a back-end database supplier grounded scheduled flights because of a computer outage. And then there is this story about how two third-party providers from Facebook exposed more than 500M records with unsecured online databases. These are just the more notable ones. Hackers are getting more clever about how and when they attack us, and often our third-party apps and vendors are the soft underbelly of our cyber security. Witness the various attacks on point-of-sale vendors, or back-end database vendors, payment providers or ecommerce plug-ins, etc. And then there are system failures, such as what happened to the airline databases.

This isn’t a new problem, to be sure, but we have to ssume these attacks and system failures are going to happen more frequently, and expose more data. A study of 40 incident responders found that half of them have seen attacks that are targeting their entire supply chain, and more attackers are trying to move across an enterprise network laterally to find better opportunities to ply their trade.

We mention the issue with third-party risk management in this post for the RSAC blog. I want to follow up where this post leaves off and talk about more specific and actionable suggestions to protect your third-party flank. The problem is that we are too trusting when it comes to these third-party apps. We have developed complex infrastructures that combine the best of the online and on-premises worlds, with a nice sprinkling of browser-based interfaces riding over all of this. That is great for building some powerful apps, but not as great when it comes to making sure that all of this gear is properly protected.

Here are a few practical things to check as your formulate your own strategies for mitigating these third-party risks:

– Vet your providers as if their were your own employees. As this post describes in more detail, you should do due diligence on any prospective vendor, partner or third-party supplier. This is helpful not just for cyber security, but also for compliance reasons too. For example, when did your prospective supplier perform its last pen test or business continuity exercise? Speaking of which, does your breach response plan take into account the posture of all of your key suppliers?

– With any of your security tools, don’t just set and forget but regularly examine your third-party apps to see if any of them have had recent exploits or if they are behind on a software version. NotPetya depended on this lazy upgrade experience. Their authors sent out their malware by taking advantage of a bug that was only patched by Microsoft a few weeks before it was exploited. There are numerous other examples. Hackers are paying attention to the timing of these bugs and zero-days, and that means you have to be ever-vigilant with your upgrades. That means your network is only as good as everyone’s equipment, whether you own it, connect to its servers or just share data with it. When you purchase a new third-party app, make sure you understand your supplier’s update policies and audit this  equipment regularly.

– Speaking of audits, you should regularly perform data inventories too. By this I mean what data sets your third-parties have access to or store on their own computing infrastructures. Part of this assessment is understanding what data from your third-party provider is available online and how it is protected at rest and in motion. This will come in handy if any of your third-party providers is hit with a breach, and can minimize the blowback to your own computing environment.

– Segment your network and put each vendor’s servers behind its own firewall. vLANs are not anything new, but they are the first line of defense when trying to stop a hacker from being able to roam around your network at will. A number of third-party attacks happened because the attackers were able to move about an internal flat network from their point of entry, until they found a victim’s PC that they could leverage for a breach.

–  Review your user access policies and know who has administrative and other more privileged rights. This becomes more of an issue when you have numerous third-parties attached to your network, and you may not know if a trusted employee of theirs has been terminated – but his account still has those higher-level access rights. Indeed, as I was writing this post, I got an email from one of my co-workers who told me that I had admin rights to our CMS. I can’t remember why I had these rights, but glad that someone was checking.

–  Have good management techniques on third-party devices and treat them as if they were your own. This is especially important for internet-connected devices.  As our networks become more complex, it becomes harder to lock every endpoint down. This means a network-connected printer at one of your suppliers could become infected and used to move onto your own network.

–  Recognize that these attacks could be a symptom of bigger problem with your security and structure your protection accordingly. Have you lagged behind keeping up with your network documentation? Do you vet all your suppliers consistently? Do you have representatives from your suppliers working on premises – and know what physical access restrictions they have?

– Finally, who stores your secrets (keys, certs) and where do they put and protect them? Just because a third-party uses encryption doesn’t mean they are using it effectively, or universally. The recent Facebook breaches with plaintext passwords discovered unprotected is a good case in point.

As you can see, managing third-party risks isn’t anything fancy, but just the basic block-and-tackling of issues that we have known about for decades. If you follow these best practices, you will go a long way towards protecting your business.