We touched on the Risks of the Extended Enterprise and the specifics of Assessing Partner Risk, so now let’s apply these concepts to a few use cases to help make the concepts a little more tangible. We will follow a similar format for each use case, talking about the business needs for access, then the threat presented by that access, and finally how Ecosystem Threat Intelligence (EcoTI) helps you make better decisions about specific partners.

Without further ado, let’s jump in.

Simple Business Process Outsourcing Use Case

Let’s start simply. As with many businesses, sometimes it is cheaper and better to have external parties fulfill non-strategic functions. We could be talking about anything, from legacy application maintenance to human resources form processing. But almost all outsourcing arrangements require you to provide outsiders with access to your systems so they can use some of your critical data.

For any kind of software development an external party needs access to your source code. And unless you have a very advanced and segmented development network, developers have access to much more than just the (legacy) applications they are working on. So if any of their devices are compromised, attackers can gain access to your developer’s devices and build systems, and a variety of other things that would probably be bad.

If we are talking about human resources outsourcing, those folks have access to personnel records, which may include sensitive information including salaries, employment agreements, health issues, and other stuff you probably don’t want published on Glassdoor. Even better, organizations increasingly use SaaS providers for HR functions, which moves that data outside your data center and removes even more of your waning control.

The commonality between these two outsourcing situations is that access is restricted to just one trading partner. Of course you might use multiple development shops, but for simplicity’s sake we will just talk about one. In this case your due diligence occurs while selecting the provider and negotiating the contract. That may entail demanding background checks on external staffers and a site visit to substantiate sufficient security controls.

At that point you should feel pretty good about the security of your trading partner. But what happens after that? Do you assess these folks on an ongoing basis? What happens if they hire a bad apple? Or if they are attacked and compromised due to some other issue that has nothing to do with you? Thus, the importance of an ongoing assessment capability. If you are a major client of your outsourcer you might have a big enough stick to get them to share their network topology. So at least you won’t have to build that yourself.

In this scenario, you are predominately concerned with bot activity (described as Sickness from Within in our previuos Risk Assessment post) because that’s the smoking gun for compromised devices with access. Compromised Internet-facing devices can also cause issues so you need to consider them too. But as you can see, in this use case it makes sense to prioritize internal issues over the public-facing vulnerabilities when you calculate a relative risk score.

In this limited scenario it is not really a relative risk score, because you aren’t really comparing the provider to anyone else, because only one external party has access any particular dataset. So if your Ecosystem Threat Intelligence alerts you to an issue with this partner you will need to act quickly. Their access could cause you real problems.

Many Partners Use Case

To complicate things a bit let’s consider that you may need to provide access to many trading partners. Perhaps external sales reps have access to your customer database and other proprietary information about your products and services. Or perhaps your chain of hospitals provides access to medical systems to hundreds of doctors with privileges to practice at your facilities. Or it could even be upstream suppliers who make and assemble parts for your heavy machinery products. These folks have your designs and sales forecasts, because they need to deliver inventory just in time for you to get the product out the door (and hit your quarterly numbers).

Regardless of the situation, you have to support dozens of trading partners or more, offering them access to some of your most critical enterprise data. Sometimes it’s easier for targeted attackers to go after your trading partners, than to target you directly. We have seen this in the real world, with subassembly manufacturers of defense contractors hacked for access to military schematics and other critical information on a particular weapons program.

In this situation, as in the use case above, the security team typically cannot refuse to connect with the partner. Sales executives frown on the security team shutting down a huge sales channel. Similarly like the security team cannot tell the final assembly folks they can’t get their seats because the seat manufacturer got breached. Although you can’t stop the business, you can certainly warn the senior team about the risks of connecting with that specific trading partner. But to substantiate those concerns, you need data to back up your claim.

This is where calculating relative risk scores for multiple trading partners can really help make your case. It’s probably not a bad assumption that all trading partners are compromised in some fashion. But which ones are total fiascos? Which partners cannot even block a SQLi attack on an ecommerce site? Which has dozens of bots flooding the Internet with denial of service attacks? Specifics from your Ecosystem Threat Intel efforts enable you to make a fact-based case to senior executives that connecting to a partner is not worth the risk. Again, you can’t make the business decision for that executive, but you can arm them with enough information for them to make a rational decision.

Or you could suggest an alternative set of security controls for those specific partners. You might force them to connect into your systems through a VDI (virtual desktop) service on your premises (so your data never leaves your network) and monitor everything they do in your systems. There are a number of ways to deal with vulnerable trading partners, but you need to start with the knowledge that they are vulnerable.

Buy Versus Build

As we alluded earlier in this series, gathering and analyzing this data is non-trivial. Especially if you are dealing with hundreds or thousands of partners. Just building the maps to understand your partner attack surface is resource-intensive. Then assessing networks, penetrating botnets, setting up honeypots, and the like, is a series of major endeavors. And given your list of things to do every day building an EcoTI capability might not happen – even though it should.

The good news is that emerging threat intelligence providers are focusing on this third-party assessment use case. They are gathering the data to assess trading partners and providing a quantified means to quantitatively compare trading partner security postures. There aren’t yet many providers but we expect to see growth in this capability over the next 2-3 years.

That said, you need some way to evaluate these services for applicability in your environment, so here are a few things to focus on in any discussion with an EcoTI provider.

1. Data sources: The first thing to understand is where the provider gets their data. Is it internal research? Do they buy external threat feeds? What kind of information can they detect? Don’t be surprised if the provider requires you to sign a non-disclosure agreement for access to this information, because quality and breadth of data sources can be clear competitive advantages.
2. Network topology mapping: How does the provider figure out which devices and networks are controlled by your trading partner? How long does it take them to get coverage for your list of partners? How do they keep their lists current?
3. Risk scoring: If the provider makes a judgement about the security posture of a partner, how is that score derived? What is their quantification based on? Can you tune it for your specific situation and risk tolerances?
4. Integration with enterprise systems: Is there a clean way to get alerts or other data into your enterprise systems? It would be great if, when the EcoTI service finds a serious problem with a trading partner, they can feed that directly into your SIEM or GRC platform to streamline your response.
5. Viability: In any emerging market you want to deal with an organization that will be there tomorrow (and hopefully the next day). So it is not out of bounds to get a feel for funding, senior team experience, level of resources, etc.

Also look for shorter deals at this time in the market. We expect a lot of innovation and new players in the market to emerge, so it makes the most sense to maintain your flexibility in EcoTI providers as the market matures – other services may soon better meet your needs.

With that we wrap up the EcoTI series. We will assemble it into a paper over the next week or so, so if you have any comments please let us know.