A little bit over five months ago, AlienVault released the first public version of its Open Threat eXchange, OTX. We’ve just created an info graphic – titled “The 2nd United Nations: The World Comes Together to Open-Source Cyber Security ” – in order to share some interesting findings from the first five months of use.
The goal of OTX is to have a collaborative shared-intelligence platform taking input from OSSIM and its connected devices, both free open source and commercial, and providing the output free of charge in different formats for reuse. The ‘power of all’ to collect and share threat data.
In its current form, with the IP reputation database at its core, OTX can be compared to the IAFIS fingerprint database. A certain IP address would have its own “rap sheet” inside the OTX database with the “crimes” committed by that IP associated to it. In no way is a relationship between the crimes and the crime reporter saved, so think of it as giving anonymous tips when you share data with OTX.
To further illustrate this, please have a look at our “Most Wanted IPs” here: http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputation-portal/
At the time of this writing, the most wanted IP is 18.104.22.168, with 9865 detected “crimes” (as defined above: sharing malware, attacking one of the OSSIM installations, attacking our honeypots, etc.).
If you go to this IP’s page (or any other in the “most wanted” if that one’s clean), you will see a full list of this IP’s crimes, what we call “Malicious Activity”, such as having a malware domain pointed at it, being a known malware IP, being an IP included by other sources as part of a known network of malicious IP addresses, spamming, etc.
This database of malicious activity can serve many purposes:
- Validate access to systems through correlation
- Raise awareness of lower priority events with this IP in them either as source or destination
- Visually notifying the user through the interface of this IP being “malicious” throughout the interface
- Using the database’s contents to write firewall or correlation rules
As you can see, applications can be many, and these are just the tip of the iceberg.
We have mentioned this before but we’ll say it again: the more people whose systems contribute data to OTX, the more information will be gathered and shared among OTX members.
And as with police/government databases, we don’t have to stop at IP addresses and attacks. Information such as traffic trends, statistics on type of target and on amount of traffic can all lead to enhanced detection capabilities.
There’s a big difference between the police/government databases and OTX though: you, the user, chose what to share and how, and when you want to get full insight into the results of this “collection”.
On the info graphic mentioned above we show a series of statistical results and curious data trends found in OTX during its first five months. It makes no sense repeating them in this text, but we’d like to highlight some points.
The obvious one would be to apply a golden rule that firewall admins around the world have used for decades: default deny.
If you look at the top malicious networks it would make sense for most organizations and end users (or even full ISPs) to completely drop inbound traffic from and outbound traffic to the entire IP address space of China. Of course, this is not practical and actually a somewhat dangerous precedent, since it could lead to other types of IP censorship under the excuse of “mistakes”.
What would be interesting is a statement from the Chinese government as to why their firewalls so successfully filter inbound content to their citizens, but are so bad at filtering outbound malicious activity. (Maybe free-speech-over-malware should become a common practice in some countries where free speech is harder to get in a different way…)
If we have a look at the top activities, we could quickly derive a pie chart like this one:
More than ½ of the top 4 activities are scanning: either port scanning, scanning for live hosts, scanning for vulnerable services, i.e. recognition. There is almost no legitimate reason for a host to be doing any of these on an external IP. It would be similar in a real life scenario to someone walking down a street at night and checking car doors or house entrances to see if they’re open.
This is pretty rudimentary stuff, but still comprises the vast majority of attacks seen out there. The more sophisticated “scanners” wouldn’t be caught by default detection configurations anyway. (Imagine a group that wants to gain entry into a building, and every week a different person walks in front of it through a crowded street taking a 3 second sneak peak at it… hard to mark as suspicious.)
The others malicious activities are even more obvious. An IP hosting malware is either:
a) Consciously distributing it
b) Has been intruded and is being used as a zombie server
c) Hosts it for research purposes, in which case it should prevent it from being immediately accessible to any automated host
A real life simile to a) and b) would be meth dealing. Whether you deal directly out of your home or you’re renting your home to a meth dealer, in both cases the home should be raided and everything confiscated, destroyed, and all participants put in jail. Legislation lagging 30 years behind reality, international boundaries and similar impediments make its virtual enforcement more difficult than it sounds.
Finally, spamming should be a capital crime anyway.
On the malicious content by type, we see some more interesting trends. Even with all the hosted content (no, I won’t say the C**** word), web front-ends, mobile media and so on, executable files are still number one in malicious content. This is probably due to wide-open holes in known operating systems and software still being discovered on a continuous basis.
Securing HTML shouldn’t be so difficult if you ask me, but I guess there’s more behind developing a safe/secure HTML rendering engine than is apparent.
I won’t talk about compressed files since it is my belief that any problems related to compressed and .exe files can be blamed entirely on antivirus software alone.
Finally, if Adobe would drop flash in favor of HTML5 and we used a simpler .xml (or similar language) based self-contained document format, we’d have fewer headaches.
So much for talk about the malicious content, the rest of the data is more or less self-explanatory.
All of us at AlienVault — and me personally as information security enthusiast — would like to thank each and every one of you who contribute to the OTX effort.
You can follow any responses to this entry through the RSS 2.0 Both comments and pings are currently closed.