Here we go again.
You know the expression, “No good deed goes unpunished”? Well that idea has surfaced with regard to our OTX, or Open Threat Exchange. Let me explain what I mean.
First, some background. We launched OTX back in February with a passionate belief in the power of transparency and open source models. But we’re also as realistic as the next guy, which means we knew that it might open a crack in the door for those with malicious intent.
So when we’re asked whether the benefit of sharing threat intelligence is worth the perceived risk, we’ve got an answer. It’s not a flippant answer or a dismissive one. We thought through the implications of openness, and baked that into the design of Open Threat Exchange. And it is a continuous factor in our ongoing product decisions.
To fully respond to the question about creating risk, we need to look at potential attack vectors, within OTX. And then consider the consequences if an attacker is able to exploit one of them.
- An attacker is able to introduce data into Open Threat Exchange
- An attacker is able to access the information that OTX distributes
- An attacker is able to access the information that a particular contributor shares with OTX
- An attacker is able to impersonate OTX and feed a particular contributor bad data
Four possibilities, each one of them carefully considered. I hope I won’t bore you with the detail below, but it’s all important.
Attack Vector #1: An attacker is able to introduce data into Open Threat Exchange
Open Threat Exchange allows users to share reputation information for IP addresses, collaboratively creating a list of addresses known to manifest malicious behavior. The IP may not be completely malicious, but its previous actions should be considered when evaluating any future suspicious behavior that might originate from it.
IP addresses that are not on the list are not considered to be good, they just simply are not known to be bad. That is a “blacklist” philosophy, and it’s the most prudent approach in this case. Think about it. Malicious introduction of benign IP addresses could cause OSSIM / AlienVault to inappropriately classify them as suspicious but there is no way to ‘whitelist’ IP addresses (classify them as benign).
Since OTX is open to anyone, mitigating controls have been put in place. Submissions by any source are validated by the content of other contributors, by information collected by systems run by AlienVault, AND by contributors that are known as trustworthy. We also collect other information related to the IP address to substantiate the observed malicious behavior. For example, indicators like a recently registered domain name, or an IP with dynamic DNS are carefully examined. We expect our validation to largely address the potential issues coming from this attack vector.
However, even in the worst-case, if benign addresses slip through these validation mechanisms, the impact is minimal as the consequence means that false alerts would be generated by the AlienVault/OSSIM installation.
Attack Vector #2: OTX IS TOO Open, and an attacker is able to access the information we distribute
Assume that this is happening. However, its implications are not too concerning; the attacker already knows that an IP address they control is performing malicious activity so the only information that they are gaining is potentially that one of their IP addresses is now known to be malicious. If anything, that should render them more cautious about that address.
One variation of this risk is that an attacker might probe an environment for the use of AlienVault/OSSIM. It is true that if an attacker were to target a single victim from a unique IP and that IP then appears in Open Threat Exchange, the attacker could confirm that the target participates in Open Threat Exchange through this penetrative validation.
However, confirming participation in the Open Threat Exchange does not actually reveal anything substantial about the defensive capabilities that are in place. The attacker gains no information related to how the AlienVault / OSSIM installation is configured, how broadly it is deployed, what correlation rules are being used, nor do they gain any information about the other security controls that are deployed. Indeed, it sends a message that a potential target is paying smart attention to security; it might send the attacker elsewhere.
Attack Vector #3: An attacker is able to access the information that a particular contributor shares with Open Threat Exchange
Yes, to be candid, being able to isolate a particular contributor is a little more worrisome than the other attack vectors. But even so, the information that is shared would not likely lead to a compromise. If a contributor is sharing the list of external IP addresses that have triggered alerts, then that’s the only information that they are revealing.
If an attacker was able to access this information, they could confirm that their particular attack was detected and move on to a different strategy. So yes, here we see the potential for an attacker to improve their efficiency since we are effectively providing them a signal from which they can determine their attack is failing.
However—and this is a huge however—we are not introducing a new vulnerability or providing breadcrumbs to further their attack. Open Threat Exchange does not store or distribute any identifying information about who contributes the information in OTX. This means that the only potential way for this to be exploited is through the transport of the information. But by using the industry standard SSL protocols and valid certificates, our transport channel is no more vulnerable than any other SSL encrypted-channel. Not perfect but pretty darn good.
Attack Vector #4: An attacker impersonates the Open Threat Exchange and spoofs a contributor with bad data
The issues are similar to the first attack vector. But instead of controlling just a few of the IP addresses on the blacklist, here the attacker is controlling all of them, potentially resulting in a large number of false alerts. This could possibly diminish the utility of the SIEM. But simply disabling the reputation-based correlation rules would quickly address a DOS attack on the SIEM.
What’s more, actually exploiting this attack vector would require a successful man-in-the-middle attack on the SSL connection between the OSSIM / AlienVault installation and AlienVault. A possibility, but if someone were to pay the price of doing this to you, there are more interesting encrypted connections coming from your network I am sure J.
To summarize, we’ve kept an open mind as we developed our Open Threat Exchange. We are not oblivious to the risks.
These attack vectors have all been assessed in the context of the information we are sharing today: IP Reputation.
We also recognize that OTX isn’t static. It shouldn’t be. So as the platform expands and new information is shared we will consider these vectors and introduce new mitigating controls if necessary.
Good things and the right behaviors have risks associated with them. That includes sharing threat intelligence; but even if the system were to be completely compromised, the advantage an attacker might gain is minimal. We’re proud that the dangerous status quo of self-imposed isolation is broken. We look forward to your contributions to both OTXs – the Open Threat Exchange, and the Open Thread exchange, below.
Read more about Open Threat Exchange here, and check out the infographic featuring threat data from the first five months of the Open Threat Exchange.
