Project factsheet information
Project Title | Honeynet Threat Sharing Platform |
Full name and acronym | SWISS GERMAN UNIVERSITY (SGU) |
Address | The Prominence Tower
Jalan Jalur Sutera Barat Kav 15, Alam Sutera, Kota Tangerang, Banten 15143 Indonesia |
Phone | +622129779596 |
Fax | 6221 2977 9598 |
Website | www.sgu.ac.id |
Dates covered by this report: | 15-01-2020 – 15-08-2020 – |
Report submission date | 15-08-2020 |
Country where project was implemented | Indonesia |
Project leader name | Charles Lim |
Project Team | Kalpin Erlangga Silaen [email protected] Andi Yusuf, M.T. [email protected] |
Partner organization | Indonesia Honeynet Project, Badan Siber dan Sandi Negara |
Total budget approved | US$20,000 |
Project summary | With the continuous rise of cyber security threats, monitoring security potential threats and attacks become essential to plan for cyber defense. Honeypot, a decoy system designed to lure attackers, has been used to track and learn attacker’s behavior. Collecting attacker’s interactions with honeypot at different locations inside different organization’s premises provide useful and more complete picture of the landscape of current cyber security threats. The log of the attacks to the honeypots become an essential cyber security threat information that could be shared to many of the security incident analysts at different organizations to provide relevant and contextual threat intelligence. The goal of this project is to develop and implement a honeynet threat sharing platform that could collect, store, add contextual information pertaining to the threat and share these threat information to the relevant organization. The result of the project will be first implemented in Indonesia then ASEAN and Asia Pacific countries, providing organizations security threat information on a collaborative effort among participating organizations. |
Table of Contents
Background and Justification:[Back to table of contents]
With the continuous rise of cyber security threats, monitoring potential security threats and attacks become essential to plan for cyber defense. Honeypot, a decoy system designed to lure attackers, has been used to track and learn attacker’s behavior [1]. Collecting attacker’s interactions with honeypot at different locations inside different organization’s premises provides a useful and more complete picture of the landscape of current cyber security threats. The log of the attacks to the honeypots become an essential cyber security threat information that could be shared to many of the security incident analysts at different organizations to provide relevant and contextual threat intelligence.
The Ministry of Communication and Informatics (KOMINFO) started to implement the first honeypot back in 2012 and it is part of collaboration between Indonesia Honeynet Project (IHP) and KOMINFO to raise cyber security awareness in the higher-level education, local government and corporation. KOMINFO and IHP conducted yearly seminars and workshop honeynet at different provinces, to encourage research collaboration between local universities and government to explore various security threats starting with honeypot data captured at various locations around the country. By the end of 2017, KOMINFO has successfully implemented 20 honeypots across 6 provinces in Indonesia.
In 2018, Badan Siber & Sandi Negara (BSSN) took on the responsibility of KOMINFO on leading the Cyber Security effort in Indonesia. In the same way, BSSN dan IHP conducted 2 seminar dan workshop: the first one at Universitas Syah Kuala (http://honeynet.unsyiah.ac.id/) in October 2018 and the second one at Swiss German University (SGU – http://honeynet.sgu.ac.id/). During the event at SGU, BSSN dan SGU signed a Memorandum of Understanding (MOU) to establish the research collaboration in the area of Malware and Threat Intelligence [2]. Toward the end of 2018, both IHP and BSSN published an annual 2018 report [3] reporting the activity we did during the year 2018. BSSN and IHP have updated the 2019 annual report of collaboration and they can be found in [4].
As BSSN, with the support of IHP, installed more honeypots at different provinces around the country, the collected attack information from these honeypots is is then visualized using a threat map portal (https://honeynet.bssn.go.id), as shown in Figure 1, to help raising the cyber security awareness for general public.
Fig. 1 The Honeynet-based Threat Map Portal
To leverage the usefulness and effectiveness, this threat information ought to be shared to the relevant parties, i.e. various industry sectors, universities and local government, to be utilized in the process of security incident response of relevant organizations located at different provinces in Indonesia. Hence, a reliable and robust threat sharing platform is required to support this effort.
The main objective of this research is to design and implement Honeynet Threat Sharing Platform that will enable organizations to share and exchange the threat information to other organizations with a consistent format and at ease. The platform will allow security analyst to add and complement existing security threat information with the results of the analysis of the security events or objects related to the events. Since growing cyber security community whose mission is to promote, collaborate, share and exchange security threat information using our platform will be a dedicated effort, SGU, IHP dan BSSN decided to establish a non-profit community-based organization to continue this mission. To provide a wider collaboration for all cyber security community, we agreed to name this organization as Cyber Security Community – Information Sharing Analysis Center (CSC-ISAC).
Jasper [5] described threat intelligence as formed from a collection of a variety of information sources, including human intelligence (HUMINT), signal intelligence (SIGINT), open source intelligence (OSINT), imagery intelligence (IMINT), etc. Cyber Threat Intelligence (CTI), on the other hand, consists of information from different sources, context-aware analysis, intelligence productions and delivery to consumers. The goal of having cyber threat intelligence is to provide the ability to recognize and act upon relevant threats in a timely manner. CTI is usually formed and delivered in the context of cyber threat information or indicators. Threat indicators can be in the form of indicators of compromise (IOC) or indicators of attack. Indicators of compromise might include malware hash information, signatures, exploits, vulnerabilities, and Internet Protocols (IP) addresses, while indicators of attack include the presence of code execution, persistence, stealth, command and control, and lateral movement in the network.
Honeynet, a collection of honeypots, is considered one of the most effective research tools to collect cyber security threat or attack information [1]. It is a decoy system, designed to trap attackers with emulated internet services, such as http, ssh, etc., and to track attacker’s interaction with the system. While Intrusion Detection System (IDS) provides a way to detect the cyber security attacks into the network using rules and signatures based on the indicator of compromise or attack, honeypot only records all the attacks directed toward the IP address in which the honeypot was associated with. Depending on the type of honeypot being used, the common threat information provided include: IP addresses (source and destination), ports (source and destination), timestamp, attack strings sent, malicious payload (hash value), etc. Collected honeypot threat information (attacks, behaviors, patterns) is useful information to help cyber security threat analyst additional information to handle security incidents in his/her organization [6].
Serrano et al [7] elaborated the information process framework, in which the events, i.e. in the form of logs, are first categorized to form patterns and these patterns are further analyzed to provide knowledge. The collection and correlated knowledge could then be used for decision making, especially for cyber defenders in relevant organizations, handling security incidents. Magee et al [8] described the transformation process involved, which include parsing and extracting the relevant threat data, categorizing the threats and finally scoring the threats. The threat categorization may involve human analysis or may be automatically performed by machine learning algorithms. Then, the threat information could be stored in a standard structure such as Structured Threat Information Expression (STIX) format [9], in which could be further shared to other interested parties using Trusted Automated eXchange of Indicator Information (TAXII). Another alternative of community threat sharing platform is using Malware Information Sharing Platform (MISP) [10], an open source threat intelligence platform.
Though there are many type of honeypots that could be implemented [11], we have chosen 2 most popular honeypots as they represent most common services available in the Internet, i.e. Cowrie and Dionaea. Cowrie is a medium interaction honeypot, emulating a secure shell (SSH), running on top of a fake file system based on Debian 5.0. On the other hand, Dionaea, is a low-interaction honeypot written in C and Python, emulating CPU instructions and making use of libemu library for shellcode detection. While low interaction honeypot has the advantage of just capturing all the interaction of the attacker with the honeypot without the risk of being compromised, medium honeypot allows more interaction through command shell emulation, i.e. all scripts or exploits are not executed in the system. Dionaea supports multi-protocol such as FTP, HTTP, Memcache, MSSQL, MySQL, SMB, TFTP, etc. The interaction logs could be stored locally or sent through a central repository using hpfeeds [12] and data normalization using mnemosyn [13] to support various honeypot data.
Figure 2 shows the system overview of honeynet-based threat sharing platforms. Organizations who are interested in deploying honeypots simply dedicate at least one IP public address and a virtual machine to host the honeypot, which is associated with the allocated IP public address. All honeypots were implemented in docker configuration, providing more robust and ease of maintenance. Honeypot data from all honeypot sensors deployed will be pushed using hpfeeds and stored in the central repository database before being parsed by Honeynet Parser Engine (HPE). If honeypot data contains binary payload, the extracted binary payload may then be sent to a malware sandbox for further analysis. Due to the time constraints, a malware sandbox analysis subsystem is not yet implemented for this project. The engine will parse and categorize the known threats and store them in the Data Lake, ready to be consumed by ELK, an open source search and analytics platform. In this implementation, we still relied on security analysts to categorize unknown threats that are separated from known threats during the processing by the HPE. As a start, the security analyst is a volunteer role from the project group but participating organizations may contribute to the community by allowing their security analyst to perform the threat analysis. Once the unknown threats have been categorized, it can be used for future incoming honeypot-based threat information processed by HPE. On the final stage, the enriched and validated threat information could be shared through MISP platform.
Fig. 2 The Honeynet-based Threat Sharing System Overview
With limited resources on our server for this research, containerized applications in a docker become essential in implementing many components of our system. Figure 3 shows the system design architecture, with hypervisor as the foundation layer enabling overall virtualization. Each of the honeypot is a docker in its own on top of the virtual machine and Linux operating system, i.e. Ubuntu 18.04. In the same way, components of HPE, i.e. hpfeeds, mnemoysyn, mongoDB and NodeRed, with one docker for the first 3 preceding subsystems and second docker for the last succeeding subsystem. NodeRed is an open source flow-based programming tool used to parse the incoming honeypot data. Threat categorization is also performed using NodeRed and the results are stored both in mongoDB and ArangoDB. While data in mongoDB will be archived and purged periodically providing backup for honeypot data, data in ArangoDB will be used as a Data Lake platform, for correlation and analysis purposes. Finally, ELK elastic subsystem pulled data stored in ArangoDB and displayed the graphical results in the dashboard through Kibana subsystem running on top of Elasticsearch.
Fig. 3 System Architecture
Our project achieved the following objectives:
- Develop a repository platform for storing honeynet-based threat information. The project allows anyone or organization to participate in a community-based threat information sharing based on the honeynet system. The repository platform includes the following:* CSC-ISAC Honeypot docker container [14].
* CSC-ISAC Honeypot Deployment documentation [15]. - Develop a repository and visualization platform that allows security analyst to add and complement existing security threat information with the results of the analysis of the security events or objects related to the events. This platform will be utilizing for the following: * Correlation analysis to help analysts to find relationships among security threat information and with other sources when they become available, in such that attack patterns can be mapped out and hopefully reveal the attack campaign.
* A platform to allow future analytics capability including artificial intelligence-based analysis allowing more accurate and faster detection of security threats.
- A platform that allows organizations to share and exchange security threat information with other organizations. The platform provides the following:
- Allow publish and subscribe mode via MISP for sharing analyzed threat information
- Allow correlation with other threat sources pulling from open source intelligence shared through MISP
- Extension to share and exchange through TAXII with other ISAC in other countries and regions around the world.
Project Implementation:[Back to table of contents]
Since SSH relies on the user id and password for authentication, login credentials become the first interaction between attacker and honeypot. We used the default allowed login credential, i.e. successful login, as “root” for user id. Other attempts to login to SSH using login user id other than “root” will fail and be recorded as unsuccessful login in our database. The other modification to the default configuration is host port is set to 2222 and incoming attack to port 22 is rerouted to port 2222.
To record a more detailed interaction between attacker and honeypot, the author of cowrie honeypot created so called “channels” to record various categories of interactions. Table 1 shows all the cowrie channels and their descriptions.
Table 1 Summary of Cowrie Channels
Following are the example for the raw data from cowrie honeypot:
- Figure 4: cowrie session with unsuccessful login
The credentials used are user id = “userftp” and password = “qwerty123” - Figure 5: cowrie session with successful login
The credentials used are user id = “root” and password = “1234” - Figure 6: cowrie session with successful login with command
The credentials used are user id = “root” and password = “abc123d4.”
It also has a series of commands being sent to the honeypot system, then ttylog is a recording session of the command execution on the shell that can be replayed using playlog utility command in linux. Finally, there was also an unknown command that was not recognized by the system.
Figure 4 – Example of cowrie unsuccessful login session (JSON format)
Figure 5 – Example of cowrie successful login with no command session (JSON format)
Figure 6 – Example of cowrie successful login with command session (JSON format)
While cowrie provides simple ssh service, Dionaea honeypot opens various ports including ftpd, httpd, smb, mssqld, mysqld, mongod, and others, for attackers to interact with the system. Due to space constraints, only common services were selected and listed here for the discussion. In general, an attacker will interact with the Dionaea honeypot with some kind of port scanning to find out the open ports or services. The attacker may decide to send some payload to exploit the open port or simply stop after scanning the port.
Table 2 shows all Dionaea channels and their descriptions. When attacker interact with the Dionaea, honeypot use “dionaea.connections” to record the first interaction and use “dionaea.capture” to store the hash value of binary when payload is involved and use channel “mwbinary.dionaea.sensorunique” to store the hexadecimal value of the binary involved, as shown in example of payload channel in Figure 14. Note that long binary hexadecimal values of the payload in Figure 14 were clipped.
Table 2 Summary of Dionaea Channels
Following are some of the examples for the raw data from Dionaea honeypot:
- Figure 7: Dionaea session SMB without payload
- Figure 8: Dionaea session SMB with payload
- Figure 9: Dionaea session mssqld (1433)
- Figure 10: Dionaea session mysqld (3306) without payload
- Figure 11: Dionaea session mysqld (3306) with payload
- Figure 12: Dionaea session httpd (80) without payload
- Figure 13: Dionaea session httpd (3306) with payload
- Figure 14: Dionaea payload
Figure 7 – Example of Dionaea session SMB without payload (JSON format)
Figure 8 – Example of Dionaea session SMB with payload (JSON format)
Figure 9 – Example of Dionaea session mssqld (JSON format)
Figure 10 – Example of Dionaea session mysqld without payload (JSON format)
Figure 11 – Example of Dionaea session mysqld with payload (JSON format)
Figure 12 – Example of Dionaea session http without payload (JSON format)
Figure 13 – Example of Dionaea session httpd with payload (JSON format)
Figure 14 – Example of Dionaea session binary payload (JSON format)
Threat Activities & Threat Categories
Our first few honeypots went live back in May and data collection has started since then. In general, we have collected a list of threat activities both from cowrie and dionaea honeypots. Threat Activity is used to define the activities that the attacker performs during the interaction with honeypot. In one activity, the attacker may choose to perform more detail acts, hereinafter referred to as threat category.
Based on 3-month data collection, there were several threat activities have been analyzed and Table 3 enumerates the threat activities both for cowrie and dionaea honeypots. Table 4 lists all possible threat categories both for cowrie and dionaea honeypot.
Table 3 – Threat activities for Cowrie and Dionaeae
SCS = Shell Command Set; DAS = Dionaea Activity Set
Table 4 – Threat Category & Mitre att&ck mapping
For example one example of threat activity with its relevant threat categories is shown in Table 5.
Table 5 – Example of Threat Activity SCS005 & Threat Categories
SSH Honeypot (COWRIE) Case
Figure 15 and 16 show a case of SSH honeypot data threat activity and analysis respectively. In this case, the attacker successfully used the credentials for ssh authentication then sent some commands to the target as listed below. The threat activity for this particular event has been analyzed, Shell Command Set (SCS007) was used to identify this particular incident. We chose to use 2 AV vendors for validation reason, i.e. Ahnlab and Microsoft, it was interesting to note that MIcrosoft misclassified the payload as the Windows payload. Thus, choosing at least 2 AV vendors helped validate our findings. Table 6 lists the threat category for the respective threat activity mapped to relevant mitre att&ck techniques.
Figure 15 Cowrie Case – Threat Activity
Figure 16 Cowrie Case – Threat Activity Analysis
Table 6 Cowrie Case – Threat Categories SCS007
Dionaea Honeypot Case
Figure 17 and 18 shows a case of a dionaea honeypot threat activity and payload analysis respectively. It is interesting to note that the attacker using a moving source IP address to attack the target and the IP address in the URL sent to the target is also listed active since July. We added some analysis using a Virustotal graph shown in Figure 18 to provide more information regarding the relationship between the IP addresses and their relevant binaries.
Figure 17 Dionaea Case – Threat Activity
Figure 18 Dionaea Case – Payload Analysis
Dashboard
To provide a platform for public and internal use to better utilize the honeynet threat sharing system, a web-based dashboard has been developed. In general, there are two types of dashboard, public dashboard and internal dashboard. Figure 19 and 20 show the public dashboard and detail statistics to display current attack statistics and threat activities and threat categories, while internal dashboard, as shown in Figure 21, 22 and 23, provide more detail regarding threat activity and threat category, including URL address, payload hashes, etc.
Figure 19 Public Dashboard
Figure 20 Threat Category Statistics
Figure 21 Top 20 URL addresses
Figure 22 Top 20 hashes
Figure 23 Top 20 IP addresses
Project Evaluation:[Back to table of contents]
This research is the one of the first projects initiated by Swiss German University to facilitate a research collaboration both for men and women from 3 institutions: SGU, BSSN and IHP. The project began with a simple desire to explore ways to best share and possibly exchange the collected honeypot data with the community starting within the country and to other regional countries at the ends. The project successfully defined a collection of threat activities for each of the honeypots and threat categories for the relevant threat activity, performed by the attacker during the interaction with the honeypot. Once analyzed and categorized, this threat information becomes known threats and incoming security threats will be matched based on the patterns, it will be stored as an unknown threat when it is not matched. The unknown threat is then analyzed manually to possibly define a new threat activity and/or with their relevant threat categories.
Public dashboards as well as internal dashboards have been developed to allow both public and analysts to view the threat activities and threat categories over time. An internal dashboard security analyst could use the search capability to discover any possible hidden attacker behavior, such as attack campaigns. For the time being, only static analysis is being recorded in the threat information, with dynamic analysis for the binary to our honeypot will be planned for the next project.
Moreover, the project contributed a research paper entitled “XT-Pot: eXposing Threat Category of Honeypot-based attacks,” to be published in ICONETSI 2020, an International Conference on Engineering and Information Technology for Sustainable Industry. This research work was the first step toward creating a comprehensive Honeynet-based threat information, starting with the two most popular honeypot, i.e. Cowrie and Dionaea. As more honeypots are used and more threat activities and categories were discovered, a complete taxonomy for honeynet-based threat information could be developed. This obviously will enrich the threat intelligence to be shared to the public through the open source threat sharing platform.
The project also has contributed the all docker image in github used in this project for public use as well as project implementation documentation [15]. This allows more participants both men and women from the community, i.e. academician, private, and government, to be involved in sharing security threats from their respective institutions. In addition, this project has also initiated a new Cyber Security Community for sharing cyber security threat information, CSC-ISAC, starting with existing honeypot data. The dashboard portal for public use was also hosted in CSC-ISAC domain, i.e. https://dashboard.cscisac.org, and ready to be used for public view.
Indicators | Baseline | Project activities related to indicator | Outputs and outcomes | Status |
---|---|---|---|---|
How do you measure project progress, linked to the your objectives and the information reported on the Implementation and Dissemination sections of this report. | Refers to the initial situation when the projects haven’t started yet, and the results and effects are not visible over the beneficiary population. | Refer to how the project has been advancing in achieving the indicator at the moment the report is presented. Please include dates. | We understand change is part of implementing a project. It is very important to document the decision making process behind changes that affect project implementation in relation with the proposal that was originally approved. | Indicate the dates when the activity was started. Is the activity ongoing or has been completed? If it has been completed add the completion dates. |
Docker Container & Project Documentation published in github
|
Public can pull docker image and install in their premise
|
Docker installation, Implementation and Testing
|
8 docker images installed sending honeypot data continuously to our repository database
|
15 January 2020 – 15 May 2020 |
Threat Sharing Dashboard developed
|
Public can view ongoing threats live
|
Dashboard development and testing
|
Public Dashboard can be used to view and search past security threats
|
1 April 2020 – 25 May 2020 |
Threat Sharing Platform
|
Threat Sharing Platform Data Lake Ready
|
Dashboard can pull and display results using the database
|
Query can be performed directly on the Data Lake
|
15 March 2020 – 25 May 2020 |
Gender Equality and Inclusion:[Back to table of contents]
This research collaboration between university, government and cyber security community was unique and had drawn some attentions in our campus, including the participation of two women in our team:
- Claudia Dwi Amanda, a cyber security analyst of BSSN, providing analysis on security threats on honeypot data with her team.
- Patricia Hamdoyo, a fourth semester IT student, who contributed her technical writing and documentation for the project
We are so proud of their contributions in this project.
Project Communication Strategy:[Back to table of contents]
To provide the broadest reach to greater community, SGU has initiated the following 2 events:
- Cyber Security Events on Threat Intelligence on 18 Jan 2020, announcing the research grant of ISIF Asia and hosting around 180 participants from commercial companies from various sectors, government, academics. Social media such as Linkedin, Facebook, Instagram, twitter and other web-based blogs or portals are part of the media channel used to distribute this information
- Cyber Security Events on Exposing Honeynet Threat Sharing Platform on 22 July 2020, hosted more then 250 participants from government, commercial companies and academicians. The event also provides a good opportunity to announce the establishment of CSC-ISAC.
Recommendations and Use of Findings:[Back to table of contents]
Following are the recommendation for various parties that might be involved in similar works or might benefit from this research:
- Internet Service Provider (ISP)
Since the project provides a list of IP addresses detected by the honeypots deployed by various communities, ISP might use the related for further investigation for possible abuse. ISP could also be the extended partner to encourage ISP’s customers to deploy honeypots to provide greater coverage of possible security threats. With wider deployment of honeypots, there will be more possible security threats detected, analyzed and categorized, providing a greater accuracy of threat intelligence share to the public. - Researchers
As the malicious techniques used by attackers continue to evolve, there are always many research approaches and perspectives that researchers can explore. The research in the early threat detection area is always interesting and allowing more motivation for researchers to move forward. Collaboration models between cyber security communities are critical and necessary to build trust between academicians, government and private institutions so that sharing security threats becomes a natural extension.
We recommend private organizations from various sectors to actively collaborate in community context with academics and government to build trust by sharing and exchanging security threats, either using our community platform or other platforms.
Swiss German University (SGU) was established in 2000 as a joint effort between Germany, Austria, Switzerland and Indonesia. SGU is recognized as a university under Indonesian law, with its license issued by the National Ministry of Education. SGU is dedicated to delivering quality education in line with international standards, and aims to develop skilled professionals. SGU Bachelor’s Degree program offers courses which combine both theoretical and practical training (internship), fully supported by lecturers with qualifications from Indonesia and abroad. In addition, the Master’s Program is uniquely placed to produce business leaders that are fit to compete globally. SGU also provides intensive courses for programs of further education and their certification.
Badan Siber and Sandi Negara (BSSN), a government institution of the Republic of Indonesia, was established in 2017 based on Presidential Regulation Number 53 of 2017 signed on May 19, 2017 which was enhanced by Presidential Regulation Number 133 of 2017 concerning BSSN. This institution is tasked with implementing cyber security effectively and efficiently by utilizing, developing, and consolidating all elements related to cyber security.
Indonesia Honeynet Project (IHP), is a cyber security community that was established in 2011 during a joint seminar and workshop event with JPCERT in 2011. Indonesia Honeynet Project (http://honeynet.or.id) is also formally recognized as a chapter of Honeynet Project (https://www.honeynet.org/chapters/Indonesia) since January 2012. Currently, there are more than 450 IHP members and the amount is increasing continually. IHP has a vision to become a non-profit organization which provides real contribution to the cyber security community by providing products and services to the community and to the country of Indonesia. IHP will share its research results in the form of publications and share its knowledge to the members and public in the form of seminars, workshops and conferences.
Cyber Security Community Information Sharing Analysis Center (CSC-ISAC) is a Cyber Security Community that was established in 2020 out of this project. The mission of this community is to provide a platform for the cyber security community, i.e. academician, private, public, and government, to share and exchange security threat information starting with honeynet-based threat information and later with other threat sources.
Bibliography:[Back to table of contents]
[1] L. Spitzner, “The honeynet project: Trapping the hackers,” IEEE Secur. Priv., vol. 1, no. 2, pp. 15–23, 2003.
[2] S. G. University, “SGU and Badan Siber dan Sandi Negara (BSSN) Supports Indonesia Government in Cyber Security,” Tangerang, Nov. 25, 2018.
[3] I. Honeynet Project, Laporan Tahunan Honeynet Project BSSN IHP, 2018th ed., vol. 1. 2018.
[4] B. IHP, “Laporan Tahunan 2019 Honeynet Project BSSN-IHP,” Feb. 28, 2020.
[5] S. E. Jasper, “US cyber threat intelligence sharing frameworks,” Int. J. Intell. CounterIntelligence, vol. 30, no. 1, pp. 53–65, 2017.
[6] H. Almohannadi, I. Awan, J. A. Hamar, A. Cullen, J. P. Disso, and L. Armitage, “Cyber Threat Intelligence from Honeypot Data Using Elasticsearch,” in 2018 IEEE 32nd International Conference on Advanced Information Networking and Applications (AINA), May 2018, pp. 900–906, doi: 10.1109/AINA.2018.00132.
[7] O. Serrano, L. Dandurand, and S. Brown, “On the design of a cyber security data sharing system,” in Proceedings of the 2014 ACM Workshop on Information Sharing & Collaborative Security, 2014, pp. 61–69.
[8] J. C. Magee et al., Collective threat intelligence gathering system. Google Patents, 2014.
[9] O. C. T. Intelligence, T. Committee, and others, Structured Threat Information eXpression (STIX). 2017.
[10] C. Wagner, A. Dulaunoy, G. Wagener, and A. Iklody, “Misp: The design and implementation of a collaborative threat intelligence sharing platform,” in Proceedings of the 2016 ACM on Workshop on Information Sharing and Collaborative Security, 2016, pp. 49–56.
[11] E. Borges, “Best Honeypots for Detecting Network Threats,” Best Honeypots for Detecting Network Threats, Oct. 2019. https://securitytrails.com/blog/top-20-honeypots (accessed Jul. 10, 2020).
[12] Hpf. Team, “hpfeeds,” hpfeeds, May 2013. https://github.com/hpfeeds/hpfeeds (accessed Jul. 10, 2020).
[13] J. Vestergaard, “Mnemoysn,” Mnemosyn, May 2014. https://github.com/johnnykv/mnemosyne (accessed Jul. 10, 2020).
[14] CSC-ISAC, “CSC-ISAC Honeypot Docker,” CSC-ISAC Docker Github, May 2020. https://github.com/csc-isac (accessed Jul. 10, 2020).
[15] CSC-ISAC, “CSC-ISAC Honeypot Deployment,” CSC-ISAC Project Documentation, May 2020. https://csc-isac.readthedocs.io/en/latest/ (accessed Jul. 10, 2020)