As we discussed in the introduction post of our Ecosystem Threat Intelligence series, today’s business environment features increasing use of an extended enterprise. Integrating systems and processes with trading partners can benefit the business, but dramatically expands the attack surface. A compromised trading partner, with trusted access to your network and systems, gives their attackers that same trusted access to you. To net out the situation, you need to assess the security of your partner ecosystem; and be in a position to make risk-based decisions about whether the connection (collaboration) with trading partners makes sense, and what types of controls are necessary for protection given the potential exposure. To quote our first post:

You need to do your due diligence to understand how each organization accessing your network increases your attack surface. You need a clear understanding of how much risk each of your trading partners presents. So you need to assess each partner and receive a notification of any issues which appear to put your networks at risk.

This post will discuss how to assess your ecosystem risks, and then how to quantify the risks of partners for better (more accurate) decisions about the levels of access and protection appropriate for them.

When assessing risks to your ecosystem, penetration tests or even vulnerability scans across all your partners are rarely practical. You certainly can try (and for some very high-profile partners with extensive access to your stuff you probably should), but you need a lower-touch way to perform ongoing assessments of the vast majority of your trading partners. As with many other aspects of security, a leveraged means of collecting and analyzing threat intelligence on partners can identify areas of concern and help you determine whether and when to go deeper and to perform active testing with specific partners.

Breach History

Investors say past performance isn’t a good indicator of future results. Au contraire – in the security business, if an organization has been compromised a number of times, they are considerably more likely to be compromised in the future. Some organizations use publicly disclosed data loss as a catalyst to dramatically improve their security posture… but most don’t. There are various sources for breach information, and consulting a few to confirm the accuracy of a breach report is a good idea. Besides the breach disclosure databases, depending on your industry you might have an ISAC (Information Sharing and Analysis Center) with information about breaches as well.

Although there are some limitations in this approach. First of all, many of the public breach reporting databases are volunteer-driven and can be a bit delayed in listing the latest breaches, mostly because the volume of publicly disclosed breaches continues to skyrocket. Some organizations (think military and other governmental organizations) don’t disclose their breaches, so there won’t be public information about those organizations. And others play disclosure games about what is material and what isn’t. Thus checking out public disclosures is not going to be comprehensive, but it’s certainly a place to start.

Mapping Your Ecosystem

The next step is to figure out whether the partner has current active security issues, which may or may not lead to data loss. The first step will be to associate devices and IP addresses with specific trading partners, because to understand a partner’s security posture you need an idea of their attack surface. If you have the proverbial “big bat” with a partners – meaning you do a lot of business with them and they have significant incentive to keep you happy – you can ask them for this information. They may share it, or perhaps they won’t – not necessarily because they don’t want to. It is very hard to keep this information accurate and current – they may not have an up-to-date topology.

If you can’t get it from your partner you will need to build it yourself. That involves mining DNS and whois among other network mapping tactics, and is resource intensive. Again, this isn’t brain surgery, but if you have dozens (or more) trading partners it can be a substantial investment. Alternatively you might look to a threat intelligence service specializing in third party assessment, which has developed such a map as a core part of their offering. We will talk more about this option under Quick Wins in our next post.

Another question on network mapping: how deep and comprehensive does the map need to be. Do you need to know every single network in use within a Global 2000 enterprise? Because that would be a large number of networks to track. To really understand a partner’s security posture you should develop as comprehensive a viewpoint as you can, within realistic constraints on time and investment. Start with specific locations that have access to your networks, and be sure to understand the difference between owning a network and actually using it. Many organizations have large numbers of networks, but use very few of them.

Public Malaise

Now that you have a map associating networks with trading partners, you can start analyzing security issues on networks you know belong to trading partners. Start with Internet-accessible networks and devices – mostly because you can get there. You don’t need permission to check out a partner’s Internet-facing devices. In-depth scanning and recon on those devices is bad form, but hopefully attackers aren’t doing that every day, right?

If you find an issue that is a good indication of a lack of security discipline. Especially if the vulnerability is simple. If your partner can’t protect stuff that is obviously be under attack (Internet-facing devices), they probably don’t do a good job with other security. Yes, that is a coarse generalization, but issues on public devices fail the sniff test for an organization with good security practices.

So where can you get this information? Several data sources are available:

1. Public website malware checking: There are services that check for malware on websites – mostly by rendering pages automatically on vulnerable devices and seeing whether bad stuff happens. Often a trading partner will buy these services themselves to assess their security posture, but nothing says you can’t do a quick assessment of partners as well. Especially higher-profile trading partner.
2. Phishing hosts: If a site on a trading partner’s network is a known phishing host, the partner compromised Internet-facing server being repurposed by a phisher.
3. C&C nodes: Like a phishing host, if your trading partner is unwittingly hosting a C&C node a least one of their devices has been compromised, and they probably don’t know it.
4. DNS issues: If there are rogue DNS resolvers within your partner network or some other means of tampering with DNS results, that increases the likelihood of other security issues.

A lot of this analysis falls under more comprehensive IP reputation analysis offered by many security vendors use as part of security and malware protection. So getting access to the IP reputation databases of your strategic security providers can streamline the process. But remember that IP reputation should not be the definitive arbiter of security posture. Look a bit deeper into your trading partners’ networks.

Sickness from Within

The other major category of threat intelligence helpful for assessing business partners is internal compromise. If you can get a feel for the number of compromised devices or bots participating in command and control networks, you can get a pretty good feel for the effectiveness of an organization’s security program. Another reason to include internal compromise in your ecosystem risk assessment is that outward-facing devices are sitting ducks. So many organizations prioritize protecting them over internal devices. Not that that’s a bad prioritization, but good externals security doesn’t guarantee that internal devices don’t provide a foothold for advanced attackers to complete their missions.

There are a few sources for this kind of data:

1. IP reputation: As discussed above, IP reputation factors in a lot of information that provides perspective on the intent of traffic originating from an IP address. With advanced NAT isolating the true IP address can be challenging, but you probably don’t need the ultimate source IP to glean useful threat intelligence. If you have significant bot traffic coming from an IP address within a partner network, whether it’s 2 or 20 bots is interesting but ultimately a detail.
2. Botnet intelligence services: A new type of threat intelligence is emerging which provides visibility into specific devices on botnets in one of two ways. One approach involves penetrating botnets and monitoring their command and control sources and destinations. The other tactic is to monitor partner networks and DNS for indicators of botnet traffic.
3. Honeypots: You might set up honeypot networks to detect attacks from partner networks.
4. Black/grey market accounts: Finally, you can mine black and grey market sites peddling stolen email addresses and authentication credentials. If you see a bunch of your trading partner’s accounts for sale, that’s a good indication of a bad security problem.

You probably won’t invest in all these different information sources, aggregate all this data, analyze it all yourself, and draw conclusions about the health of each trading partner. But we work through this detail so you can become an educated buyer of threat intelligence. So you can ask the right questions about how any intel provider gets their data, and make sure it’s relevant.

Time to Remediate

Another way to leverage botnet intelligence is to track when specific devices are remediated. If you are mining a C&C network and see the same IP address for weeks or months at a time, that indicates that specific organization either doesn’t know the device is pwned or is inept at remediating the issue – or perhaps you’re lucky and it’s their honeypot, but don’t hold your breath. The point isn’t to harshly penalize every trading partner for every bot that shows up on a specific network. Bots happen (we should sell a t-shirt). But bots that stay operational over long periods of time indicate underperformance by security. Similarly, Internet-facing devices that show extended indications of compromise fall in the same category of security fail.

Quantifying Partner ‘Risk’

Once you have data on the devices and networks that show signs of being compromised via the intelligence gathering process described above, you can get a feel for the number of security issues your trading partners have. Cross-reference your list of compromised devices against your map of trading partner networks, developed at the beginning of this process. This gives you data to draw a somewhat objective conclusion about how secure each partner is, and track each partner’s security score over time.

When we talk about quantifying we are referring to some kind of objective, consistent, and repeatable means of generating a security posture metric. We could go into detail about what a good metric is (and what it isn’t), but we covered that ground in Security Benchmarking, so check that out for a deep discussion of metrics.

For the purposes of Ecosystem Threat Intelligence, we aren’t overly concerned with the specifics on how the metric is generated, so long as the approach is logical and defensible. We know the risk quantification crowd is likely to violently disagree with that position, but we focus on how to make better security decisions – not on defending your metrics for a dissertation. As long as the metrics are derived in a fair, objective, and consistent method – and you buy into the scoring algorithm and specific components of deriving the metrics – we believe this relative approach to quantification offers value for decision support. Keep your eye on the prize, which is understanding the relative risk of each trading partner connecting to your network.

We will wrap up this series next post, with a scenario showing how you can quickly leverage Ecosystem Threat Intelligence to improve your security posture.