A Scalable, Honeypot-Driven Threatmap

It becomes evident that the arising cyber threats must be countered. For this purpose, among other techniques, so called honeypot systems are being used. A honeypot is a specifically designed entity, e.g. a server or computer within a network, whose primary task lies in acting as a decoy for network intruders (cf. Spitzner 2003). The goal is to gather information about a malicious intruder to understand attack-vectors and to improve the defense of productive systems. This makes a honeypot an important system, and next to Intrusion Detection Systems (IDSs) and Intrusion Prevention Systems (IPSs), essential in determining the presence of security threats. Honeypots provide a convincing method of detecting the presence of an intruder and serving as prey for malicious actions. However, having only a single sensor available results in limited possibilities of defending a network. In order to detect attacks directed towards a network, multiple instances can be deployed to form a honeynet (cf. Spitzner 2000) and, in conjunction with proper IDSs, detect correlated attacks, as shown by Vasilomanolakis et al. (2015). With an increasing number of sophisticated attacks in the past years (cf. Vasilomanolakis et al. 2015) the administration of networks requires additional support systems that automatically summarize and visualize the latest data from network security systems like IDSs, IPSs and
honeypots in order to cope with the increased number of security threats and detecting correlated
attacks.
 
While there exist a number of projects that provide the base for a network security setup like dionaea 1 , Glastopf 2 or honeytrap 3 , these tools’ strengths rather lie in gathering than processing security data. However, being able to receive and handle various streams of honeypot-input data is mandatory in order to discover complex threat scenarios like correlated attacks (as examined by Katti et al.) or the epidemic behaviour of spreading malware and requires the presence of a threatmap that provides the possibility to visualize and aggregate incoming data from honeypots at a central service (cf. Vasilomanolakis et al. 2015).
 
However, there are multiple problems with current available implementations of such a threatmap, which are so severe that current implementations can not be used for a customizable solution. Some of these are: Already available threat monitors are not open source, their source code is not editable, which hinders the custom modification of the software. Hence, custom data sources can not be fed into these maps. Further, existing solutions don’t aggregate data of multiple honeypot feeds, but show gathered data individually at the place of collection - their possible application is therefor limited.