Proactive detection of security incidents II - Honeypots

From Botnets.fr
Revision as of 12:00, 22 November 2012 by Eric.freyssinet (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

(Publication) Google search: [1]

Proactive detection of security incidents II - Honeypots
Enisa-honeypots.png
Botnet
Malware
Botnet/malware group
Exploit kits
Services
Feature
Distribution vector
Target
Origin
Campaign
Operation/Working group
Vulnerability
CCProtocol
Date 2012 / 2012-11-22
Editor/Conference Enisa
Link http://www.enisa.europa.eu/activities/cert/support/proactive-detection-of-security-incidents-II-honeypots www.enisa.europa.eu (www.enisa.europa.eu Archive copy)
Author CERT Polska
Type

Abstract

An increasing number of complex attacks demand improved early warning detection capabilities for CERTs. By having threat intelligence collected without any impact on production infrastructure, CERTs can better defend their constituencies assets. Honeypots are powerful tools that can be used to achieve this goal. This document is the final report of the ‘Proactive Detection of Security Incidents: Honeypots’ study. The study was initiated to investigate more in-depth honeypot technologies that can be used by CERTs in general and national/governmental (n/g) CERTs in particular to proactively detect and capture network attacks directed at their constituencies. The study is a follow-up to a previous more generic study on ‘Proactive Detection of Network Security Incidents’,1 also conducted by ENISA. Among the findings of that study was the fact that while honeypots are recognised by CERTs as useful tools that can be utilised to detect and study attacks, their usage in the CERT community was not as wide as could be expected, which implies that barriers exist to their deployment.

The core of the document is an investigation of existing honeypot and related technologies, with a focus on open-source solutions, also because not many commercial solutions are available and testing would involves extra costs. Basic honeypot concepts and deployment strategies are covered, to help CERTs gain a better understanding of the critical issues related to deployment. The intention of the study is to focus on the practicality of a solution, not necessarily its research or academic value. Hence, to help CERTs, as part of the study we have introduced criteria that had mostly not been used before for evaluation of honeypots. The goal: to offer insight into which solutions are best from the point of view of deployment and usage by a security team – particularly a CERT team, making it easier for a new team to select which honeypot technology to deploy. The evaluation includes results of actual testing of solutions, rather than just desktop research. Overall, a total of 30 different standalone honeypots were tested and evaluated, including: low-interaction server honeypots (general purpose, web, SSH, SCADA, VoIP, USB, sinkholes), high-interaction server honeypots, and low and high-interaction client-side honeypots. Additionally, various hybrid solutions, Early Warning Systems based on honeypots, online honeypots and sandboxes and their possible usage by CERTs are also introduced. The study also explores the future of honeypots.

The study found a number of possible barriers for deployment (see Chapter 10). These include: difficulty with usage, poor documentation, lack of software stability, lack of developer support, little standardisation and in general a requirement for highly skilled people to handle and maintain honeypots, as well as problems in the CERT community in understanding basic honeypot concepts. Nevertheless, if deployed correctly, honeypot benefits for CERTs are found to be considerable.

The study recommended three groups of solutions to consider for possible deployment. The most important are a group of the most mature and ready to use honeypots: dionaea (see section 5.2.2.1.2), Glastopf (see section 5.2.2.2.3), kippo (see section 5.2.2.3.1) and Honeyd (see section 5.2.2.1.4). SURFcert IDS (see section 5.4.3) is a good solution for deploying a network of server-side honeypot sensors.

For those CERTs that can devote more resources to maintaining their honeypot deployments, but in exchange gain the capability to detect malicious websites, client honeypots such as Thug (see section 5.3.1.4) and Capture-HPC NG (see section 5.3.2.1) are found to be worth considering. Finally, for those able to devote resources to research and further development, Argos (see section 5.2.1.1) and the development of client honeypots based on the Cuckoo sandbox (see section 7.1.1) are possible selections.

Honeypots offer great insight into malicious activity in a CERT’s constituency, providing early warning of malware infections, new exploits, vulnerabilities and malware behaviour as well as an excellent opportunity to learn about changes in attacker tactics. The study therefore recommends that CERTs explore the possibility of deploying honeypots across their constituency (a set of general recommendations can be found in section 10.2). Using honeypots as sensors can be easier than other technologies, as they normally do not monitor production level traffic, making privacy issues a lesser concern. To combat the increasing cyber threat, CERTs need to cooperate and develop large-scale interconnected sensor networks in order to collect threat intelligence from multiple distributed geographic areas. Again, honeypots are ideal for this purpose. Honeypots can also be used to combat the insider threat. Nevertheless, they often still require some work to meet the needs of CERTs. In order for honeypot technologies to meet these expectations, CERTs and honeypot researchers are encouraged to work together. CERTs should reach out and take part in the honeypot communities identified in this study, giving feedback, researching new ideas and aiding in development. The end goal: powerful and reliable tools that help CERTs and others make the Internet a safer place.

Bibtex

 @misc{Lua error: Cannot create process: proc_open(/dev/null): failed to open stream: Operation not permitted2012BFR1212,
   editor = {Enisa},
   author = {CERT Polska},
   title = {Proactive detection of security incidents II - Honeypots},
   date = {22},
   month = Nov,
   year = {2012},
   howpublished = {\url{http://www.enisa.europa.eu/activities/cert/support/proactive-detection-of-security-incidents-II-honeypots www.enisa.europa.eu}},
 }