
You all heard about one of the most serious vulnerabilities hitting the Internet in the last few years: I of course speak of Heartbleed [1], a bug in the open-source library OpenSSL. But instead of talking about technical details of the vulnerability, I’d like to discuss the way how the information spread and finally arrived at the actual users.
Officially, the information was published by the OpenSSL Software Foundation on their Website on the 7th of April 2014, at 17:30 UTC [2]. According to some sources [3], the foundation informed some of their (Premium?) customers before the public announcement. But then, how were the “ordinary” users of the library informed? Simply by reading the news! Meaning that the reaction delay can vary between few hours to 4 or 5 days . The same for the patching information.
Let’s talk about the way how, in general, such kind of information is communicated to the users and the customers. We distinguish 3 different channels:
Apart from those content-related dimensions, the consumption of the above channels incurs certain costs at end-user side. Those stem from license or subscriptions fees (in case of commercial offerings), or from the manual processing required to understand the relevance of given information (with regard to the software components and versions in use at end-user side).
Let’s have a closer look at the informal channel, especially at Social Networks, where official and non-official information providers publish the latest news about recent vulnerabilities, patches or exploits related to software applications and libraries. Together with my colleagues gilles.montagnon emathias and henrik.plate we started investigating some recent vulnerabilities. Starting from official information we retro-searched in Twitter for related tweets. After a long and time consuming manual search, we ended up with an interesting observation: All the vulnerabilities that we targeted in the search were reported on Twitter, sometimes at more or less the same time as through the other channels, but sometimes before – in some cases up to several months - before any information was provided through any of the other channels. Besides information about the mere presence of a vulnerability, we were also able to find exploit or patch details.
Now what if we automate this search, or even better, what if we monitor *live* all the information related to our software in order to be alerted very early about vulnerabilities and related patches? And do we have an efficient infrastructure for storing analyzing and processing a huge amount of data? Are we the first to have the idea to monitor software vulnerabilities through social networks?
The answers are:
If an administrator was following the all the security events related to OpenSSL he would have been notified about the vulnerability on April 7th at 9 PM without any premium subscription. He would be informed about the fix (upgrade the library version) on April 7th at 11 PM.
SMASH is the first prototype concretizing the concepts that I depicted before. SMASH stands for Social Media Analysis for Security on HANA and was developed in TGIF mode with my colleagues.
The concept is simple: we scan a system (for example a virtual machine) in order to get all its software components. Once we have this list, we create a Twitter filter for each software component in order to monitor all the related security messages. We store all the messages on HANA then we perform an analysis in order to detect new information related to vulnerability disclosure, exploit code or fix/patch release. We used SAP Fiori as UI interface connected to HANA to provide an easy to use dashboard to monitor alerts, warning and statistics.Here is a video to the Demo:
For this idea, a patent and a prototype are not sufficient, for this reason we decided to submit a Demo in the D-Code Demo Jam in Walldorf. The demo was accepted and we finished on the top three finalist. Click on the photo to access to the recording:
A standard running system is usually composed of hundreds of software elements. Imagine for each of them, we listen, collect and analyze the information. Within the collected information there is a lot of false positive or unrelated content. Beside the alerting functionality, SMASH offers the possibility to make security statistics on the software components that require complex querying and processing. Do you know a better database and platform able to perform a high speed access and analysis? SAP HANA is the perfect solution for that !!!!!!
If you are interested to push for the productization of SMASH at SAP you can help us !
If you are a SAP Customer and you think that you need SMASH please let us know !
[1] Heartbleed Bug
[2] https://www.openssl.org/news/secadv_20140407.txt
[3] The Heartbleed vulnerability: how does it apply to you? - TechRepublic
Important: Please note that the following work stems from research activities and has prototypical character. It does not correspond to functionality offered by official SAP products
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
14 | |
11 | |
7 | |
7 | |
7 | |
6 | |
5 | |
5 | |
5 | |
5 |