Chapter 4. Suricata analysis 31
Chapter 4. Suricata analysis 32
Chapter 5 Solution proposal The project’s requirements were following: • Suggest and implement a way for SecMon to normalize Suricata logs. • Suggest and implement correlation rules tackling a specific type of attack • Improve frontend part of the source code to change how filter functions As this project’s aim is to improve SecMon’s intrusion detection and based on the analysis of the SecMon system I proposed to implement new normalization and correlation rules that connect SecMon with IDS Suricata to help it monitor network more efficiently. Suricata is a widely used software and its ET Open ruleset covers large amount of threats. Normalization aims to gather and validate data that a system receives from the network. As such, the normalization rule should be general enough to be capable of capturing every type of log Suricata produces. Suricata supports numerous rulesets and custom rules as well, many users create their own rules or borrow open source rules created by others online. Because of the massive amount of 33
Chapter 5. Solution proposal variable logs, the rule must be capable of normalizing every type of log to be useful for the SecMon. The main objective of correlation is to find matching patterns and find similarities and establish relationships between logs produced by normalization event operations. My proposal for this part of the project is to create rules that are capable of capturing and identifying multifaceted attacks from a specific host IP. Such attacks rely on attacking the system with various exploits and identifying it in real-time is crucial. The proposed solution will be capable of correlating such events to alert user of such potential threats. The final objective of this work is to improve the frontend experience. The filter page of SecMon is not fully efficient, especially when compared to other parts of the system that work with more modern approaches to UX. The proposed solution is to rewrite pats of the source code and improve the frontend by changing how the filter logic works and making it easier to use and work with. 34
Chapter 5. Solution proposal 35
Chapter 5. Solution proposal 36
Chapter 6 Description of implementation The goal of this project is to implement new rules in the SecMon system. More specifically, rules related to Suricata. In this section I will go over the specifics of Suricata and how it could be implemented in the SecMon system. Additionally, secondary goal of this thesis was to improve SecMon’s front end capabilities by updating a specific filter function on its filter page. 6.1 Implementation enviroment SecMon was installed on a virtual machine provided by Oracle VirtualBox Version 7.0.4 [27] using Ubuntu 22.04.2 [28] operating system. Virtual Machine was configured using port forwarding to allow guest machine connection to the localhost hosting SecMon. Reason why this project used VirtualBox is because it’s free and is very easy to configure for everything I need for the project. Ubuntu was selected as its a very modern, constantly updated operating system. While SecMon was developed on CentOS, I found working with Ubuntu much more comfortable. Lastly, I have installed the Suricata IDS/IPS inside the virtual enviroment. 37
Chapter 6. Description of implementation 6.2 Suricata configuration Firstly I configured Suricata’s HOME_NET and EXTERNAL_NET variables. For the HOME_NET variable I used the IP of the client machine while for the EXTERNAL_NET I wanted it to monitor all outside networks. Thus $HOME_NET was used. This tells Suricata to also monitor everything but our client network. Figure 6.1: Suricata network configuration The next step was to secure the style of logging. Suricata supports many ways to handle its logs, one of which is using rsyslog. [29]. SecMon uses rsyslog for its logging as well and comes with its own premade templates to handle this so configuring Suricata to send its logs to SecMon was a straightforward process once I got familiar with rsyslog and how it functions. Firstly I set up syslog logging on Suricata simply by enabling the option in the suricata.yaml file. In this file I enabled the syslog alerts and left everything else by default as that is how SecMon accepts these logs. That is, I left facility as local5 and also left level 38
Chapter 6. Description of implementation Figure 6.2: Enabling syslog alerting compability on Suricata commented. By default Suricata will consider this as "level:Info". With this done I had to configure one last thing and that was to set up rsyslog redirecting to go to my client machine with SecMon on it. This is done in the /etc/rsyslog.conf file at the very bottom. According to the official SecMon github[23], all that is required is to set the *.*[SecMon machine IP]:514 at the very end of this file. In my case the line would read as shown in the figure below. The port 514 is the commonly used port for syslog protocols [30], so it will remain unchanged. Figure 6.3: Syslog file redirection The last part of the configuration is actually already solved on SecMon’s side. SecMon comes with its own rsyslog templates, so I could simply use those. The templates can be accessed in the /etc/rsyslog.d/secmon.conf file. As such simply sending the syslog files to SecMon is enough. 39
Chapter 6. Description of implementation Figure 6.4: SecMon rsyslog templates With the configuration finished I could test if the log forwarding worked by looking at the Security Events tab in SecMon. 6.3 Suricata normalization rules The normalization rule aims to normalize all incoming logs from Suricata. It does not target concrete logs, it instead is written to be as universal as possible. This rule is saved in /home/user/Python-3.6.15/secmon/rules/active/normalization folder and is named suricata.rule. The rule is included in the technical documentation in Appendix B.1.1 Before proceeding with any subsequent analysis, it is crucial to initiate the process of log parsing as the initial step. The log must be parsed in accordance with SecMon’s log formatting and CEF date formatting. The resulting parsed log is comprised of the following components: • CEF event class ID serves as a unique identifier for the events. It can represent either the event’s own ID or an external ID. In this case, it corresponds to the Suricata rule’s ID. The identifier can be found in the following section of the log: [1:202049:3] • CEF name refers to the automatically assigned name by Suricata, which is 40
Chapter 6. Description of implementation Figure 6.5: SecMon displaying normalized logs sent by Suricata based on the corresponding Suricata rule used. In the provided log example, the rule assigns it the name ET MALWARE SuperFish Possible SSL Cert Signed By Compromised Root CA. • CEF severity indicates the priority automatically assigned by Suricata based on the Suricata log forwarding configuration. In this project, the severity setting was maintained in its default state (Info). The severity is located in the following field: [Priority: 1] • Protocol denotes the protocol used in the event. It is the second-to-last field in the log: {TCP} • IP addresses and ports are listed at the very end of the log, with the for41
Chapter 6. Description of implementation mat of source_IP:destination_protocol -> destination_IP:source_protocol. An example from the log is as follows: 155.233.238.159:57679 -> 10.0.2.15:80 6.4 Correlation rules Correlator in SecMon is built to read normalized events that, after normalization, were expanded with additional information about the type of event transpired. These logs are transmitted to the SEC input using a data pipe located at /var/www/html/secmon/__secOutput. Once the logs are passed into this pipe, the SEC tool conducts event correlation based on the rules found in the /var/www/html/secmon/rules/active/correlation directory. It is important to note that there are two rule directories: "active" and "available," but SEC only considers the rules in the "active" directory. When a properly written rule is present in the /active/correlation directory, the SEC tool will transmit the event to the output data pipe stored at /var/www/html/secmon/__secInput. To access these pipes and directories, the custom Docker image can be utilized by executing the command docker exec -it <container_name> bash. As a troubleshooting method, one can verify if an event is being appropriately correlated by directly accessing the data pipe directories and using the cat __secInput/Output command. If logs are displayed in these pipes, it indicates that the rule successfully parses the logs. However, it is important to note that using the cat command during such troubleshooting removes the log entry from SecMon, preventing it from being displayed in the graphical user interface (GUI). With this in mind, I wrote two rules that aim to monitor the network for this attack. One rule focuses on capturing logs from one concrete attacker directed at the whole network while the second rule focuses on capturing logs from one concrete attacker directed at a concrete victim IP address. 42
Chapter 6. Description of implementation 6.4.1 Multifaceted attack from the same IP directed at various hosts The first rule is capable of correlating events when an attacker is attacking various hosts. The full rule can be seen in the technical documentation. SEC uses different rule types to handle different kind of events. In my case, I used EventGroup rule. This rule is fit for scenarios where we have to consider multiple events of different types in one event correlation scenario. In my case, I need to observe the network for attacks from multiple attackers but also attacks from the same attacker. Because of this, I will also need to make use of SEC contexts to remember each instance that triggered this rule. This rule’s regular expression matches suricata logs and then sets variables as appropriate. Variable $2 is set as date and timestamp as it is required for the CEF format for SecMon. Variable $3 is set as username for the same reason. Variables $6 and $11 are set as attacker IP and suricata rule ID respectively. Variable $20 is set as suricata rule name which is then used to identify what type of attack occurred. Afterwards, the context !HOST_IP_$6_SURICATA_ID_$11 looks at the variables and determines true if context with a given attacker IP and suricata rule ID already exists. For example, if a rule matches attacker IP as 65.9.95.10 and rule ID as 2018959, the context created would look like this: HOST_IP_65.9.65.10_SURICATA_ID_2018959. If a context like this does not exist, it will start an event correlation operation. Once the operation starts, it will create an alias ATTACKER_69.9.95.10 for 120 seconds. This alias will ensure the rule does not match and create context for the exact same combination of attacker IP and suricata rule ID. Once the time runs 43
Chapter 6. Description of implementation out, the alias will be deleted and operation will stop. If the rule matches a new type of attack from the same IP, it will increment its event counter. Once the counter reaches 5 within given threshold, the rule will then write a warning into the SecMon __SecInput pipe as a correlated event. 6.4.2 Multifaceted attack from the same IP directed at a specific host The second correlated rule focuses on multifaceted attacks on the same IP address. In case our IDS monitors a larger network, the attacker may attempt to attack multiple IP addresses on the network. However, there is a case where the attacker would attempt to inflict damage on a single IP address with more specific kinds of attacks. The following rule is capable of capturing such attempts. The full rule can be seen in the technical documentation in Appendix in B.1.2 This rule functions similarly to the first rule. It uses contexts to track various types of attacks from the same IP address aimed at the same victim IP. It creates !ATTACKER_IP_$6_VICTIM_IP_$8_SURICATA_ID_$11 context, where $6 variable is IP of the attacker and $8 is IP of the victim on our network. If the regular expression matches a suricata log and attributes values to the given variables, it will check if given context already exists. For example, if context ATTACKER_IP_65.9.95.6_VICTIM_IP_10.0.5.15_SURICATA_ID_2018959 does not exist, it will create a new event correlation operation with the specified attacker and victim IP adresses. Once the operation begins, it creates an alias ATTACKER_65.9.95.6_ VICTIM_10.0.5.15. If the rules matches an instance where the attacker and victim IP are the same but a new type of attack is detected, the event counter will 44
Chapter 6. Description of implementation increase by 1. Once the counter reaches 5, the rule will write a warning into the SecMon __SecInput pipe as a correlated event. 6.4.3 CEF format Both rules follow the same CEF format in order to appropriately write the event into the SecMon pipe. The correlation format is as follows: action=write [directory_path] <date+timestamp> <host_name> <CEF_format> The CEF format follows this structure: CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name| Severity|Extension [31] These fields closely resemble the formatting used by the normalizer, but there are a few key differences: • Date: The date must be represented as a single variable that includes both the date and time. • Name: The name must follow the date in the specified order. • Severity: The severity is manually inputted when creating correlator rules. SecMon handles severity levels on a scale of 0-10, where 0-3 represents low severity, 4-6 indicates medium severity, 7-8 denotes high severity, and 9-10 signifies the highest level of severity. It is crucial to ensure that the assigned severity falls within this range; otherwise, the rule may not function correctly or potentially corrupt SecMon’s database. 45
Chapter 6. Description of implementation 6.5 Filter The goal of this section was to improve the search functionality of the filter on the Filter page. Currently, the filter does not utilize a search bar function to make browsing through the available items easier and faster. Instead, the user has to scroll through a long list of options and find their desired item. This improvement aims to fix that by introducing a scroll-search function to the filter. I decided to use a jquery plugin called jQuery-editable-select [32]. This plugin allows me to insert a search bar into the existing code, thus improving its functionality like I described above. The code needed to be rewritten to accommodate this new functionality. Firstly by inserting the relevant plugin into the script and then introducing a new method called .editableSelect() that implements the script’s functionality. Figure 6.6: jQuery script Next I needed to make adjustments to the existing code. The part that I mainly rewrote was the view part of an MVC model. • [\$index]column: An array that accepts and stores user input • [options: Options that set the HTML attributes for the field wrapper. It first sets the class to input-field-col-m3 which decides the size of the input text field and then it sets the class to selectColumnDropdown1 which implements the jQuery plugin script method. 46
Chapter 6. Description of implementation Figure 6.7: Part of the code that handles display of the filter • data: The data section generates a dropdown list input field. The first variable $colsDown provides a list of options the user can select while the second variable $colsDownOptions stores additional configurations for the dropdown list hidden in the background, such as storing whether the selected option is "compare" type or "regex" type. The difference between old filter and new filter can be seen in the following images: 47
Chapter 6. Description of implementation Figure 6.8: Old filter Figure 6.9: New filter 48
Chapter 6. Description of implementation 49
Chapter 6. Description of implementation 50
Chapter 7 Testing 7.1 Testing enviroment For the testing purposes I set up a new virtual machine with Ubuntu 22.04.2 installed. After configuring my custom virtual network, I could begin the testing. Figure 7.1: Testing environment 51
Chapter 7. Testing 7.2 Normalization Rule Testing To test the rule, I used a tool called testmynids.org [33]. This tool, as its name implies, is used to test network intrusion detection systems and their ability to detection of suspicious events. After properly configuring Suricata and how it observes the network, the program was then used to simulate sending various packets to the network to test my rule’s ability to detect it. Figure 7.2: Normalized logs Furthermore, it is possible to examine the event in greater detail to observe how the CEF parsing was executed. An example log that this rule aims to normalize looks like this: 171 Apr 15 16:42:09 kubko123 suricata[890]: [1:2020493:3] ET MALWARE SuperFish Possible SSL Cert Signed By Compromised Root CA [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 104.154.89.105:443 -> 10.0.2.15:49002 7.3 Correlation rule testing Testing the correlation rules was performed using several tools. nmap, metasploit and tcpreplay were the tools I used the most. 52
Chapter 7. Testing Figure 7.3: Event information details The testing was conducted under the assumption of the following conditions: • Suricata has been appropriately configured to monitor the network. • Syslog forwarding has been configured on Suricata. • No additional Suricata rules were utilized that could potentially disrupt the testing. • No other intrusion detection or prevention systems (IDS/IPS) were configured on the network apart from Suricata. • There were no other correlation rules in place that handle similar events. • Suricata was predominantly configured to retain its default settings. Using nmap, I have scanned all possible invulnerabilities on the SecMon system and using metasploit I have attempted to perform several attacks on SecMon. 53
Chapter 7. Testing Example of a correlated event: Figure 7.4: Example of a correlated events Figure 7.5: Example of a correlated log in the SecMon interface Example of a log before being correlated: 7:Apr 22 17:28:14 kubko123 CEF:0|OISF|Suricata|0|2020493|ET ET MALWARE SuperFish Possible SSL Cert Signed By Compromised Root CA|171| src=104.154.89.105 dpt=443 dst=10.0.2.15 spt=54674 proto=TCP externalId=2020493 rawEvent=171 Apr 22 17:28:14 kubko123 suricata[822]: [1:2020493:3] ET MALWARE SuperFish Possible SSL Cert Signed By Compromised Root CA [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 104.154.89.105:443 -> 10.0.2.15:58434 54
Chapter 7. Testing Example of a log after correlation: Apr 22 17:28:27 kubko123 CEF:0|OISF|Suricata|2020493|ET MALWARE SuperFish Possible SSL Cert Signed By Compromised Root CA| Multifaceted attack at various hosts|6| att=multifaceted_attack src=104.154.89.105 rawEvent=47:Apr 22 17:28:27 kubko123 CEF:0|OISF|Suricata|0|2020493|ET MALWARE SuperFish Possible SSL Cert Signed By Compromised Root CA|171| src=104.154.89.105 dpt=443 dst=10.0.2.15 spt=54674 proto=TCP externalId=2020493 rawEvent=171 Apr 22 17:28:27 kubko123 suricata[822]: [1:2020493:3] ET MALWARE SuperFish Possible SSL Cert Signed By Compromised Root CA [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 104.154.89.105:443 -> 10.0.2.15:54674 55
Chapter 7. Testing 56
Chapter 8 Conclusion 8.1 Summary In this study, various aspects of cybersecurity in relation to SecMon have been analyzed. One significant aspect examined is Defense in Depth (DiD), its advantages, and its prevalence in modern security systems. Additionally, a thorough exploration of SIEM systems has been conducted, covering their composition and operational mechanisms. Notably, the focus has been placed on the development of normalization and correlation rules, aligning with the initial objectives established at the beginning of the summer semester. Upon determining the project’s goal in consultation with my advisor, the implementation phase commenced. Key considerations included the proper configuration of Suricata, the chosen IDS/IPS for this work, as well as the setup of syslog forwarding and the selection of an appropriate operating system. While CentOS 8 was the recommended choice for SecMon, I opted for the familiarity and compatibility of Ubuntu, which proved equally effective. 57
Chapter 8. Conclusion The implementation process involved the creation of new normalization and correlation rules that operate with logs created by Suricata. Normalization rules were created to handle all kinds of logs, including those that were created as a result of custom rules. Correlation rules were focused on detecting multifaceted attacks and were written using EventGroup type of SEC rule. This rule utilizes SEC contexts and aliases that track different host IPs after matching a log. When the rule matches different attacks from the same host IP, it will trigger an action that sends message to the input SEC pipe. The result of this work are functional rules within the Suricata monitoring tool. I demonstrated functionality of both rules in this work and I believe when properly used, they will serve as a solid tool for future updates of SecMon. 8.2 Deficiencies and observations Although these rules have demonstrated functionality, they are heavily dependent on the current structure of SecMon. The monitoring system has a highly rigid framework, requiring the rules to be custom-tailored to its specific requirements. Even a minor change in a future update could potentially render the rules ineffective. Furthermore, the rules were designed with a specific Suricata configuration in mind. While I discovered during testing that, while the normalization rule can accommodate slightly different Suricata configuration settings, there is no guarantee that it will be compatible with all possible Suricata configurations, including those introduced in future updates. Therefore, it is crucial to consistently update the rules to ensure their continued functionality. Given the fragility of certain aspects of SecMon’s structure, regular 58
Chapter 8. Conclusion updates are essential to mitigate the risk of system failures. 8.3 Future Work In the future, if circumstances allow, I intend to revisit the rules within SecMon and undertake the task of cleaning up older rules while creating new ones for the Suricata system. Throughout this project, I developed a genuine interest in Suricata and the broader subject of monitoring systems, and I am eager to further explore and engage with it in the future. This includes refining existing rules that no longer function within the system and creating new rules to address other security challenges that Suricata allows to monitor. 59
Chapter 8. Conclusion 60
Resumé Úvod Práca sa zamerala na výskum, analýzu a zhrnutie rôznych bezpečnostných systémov. Jednou z častí tejto práce bola analýza Obrany do hĺbky (ďalej ako DiD z anglického Defense in Depth). DiD je veľmi rozšírený koncept v kyberochrane a využíva sa takmer všade. Obrovské množstvo informácií je spracované cez sieťové komunikácie, a preto je veľmi dôležité dosiahnuť vysoký level ochrany. V DiD sa využívajú viaceré vrstvy ochrany a každá vrstva je zodpovedná za inú časť celého systému. Keď jedna časť zlyhá, tak druhá časť by mala systém chrániť bez veľkých problémov naďalej. Princípy DiD sú postavené na báze bariér, ktoré obklopujú časti systému, ktoré chceme ochrániť. Tieto bariéry musia mať nasledujúce časti: • Odstrašenie • Detekcia • Oneskorenie • Odozva Tieto bariéry sa sústreďujú na získanie informácií o útočníkovi, odstrašenie potencionálneho útoku a okamžité varovanie v prípade útoku. Tieto bariéry nadväzujú 61
Chapter 8. Conclusion na hlavnú časť tejto práce, a to je detekcia. Analýza SIEM Na detekciu útokov existujú viaceré prostriedky. V tejto práci som opisoval SIEM systémy ako jeden z týchto prostriedkov. SIEM systémy sú vytvorené na analýzu a kolekciu správ z rôznych potencionálnych útokov. Tieto správy sa zbierajú najmä zo siete, ale aj zo zariadení používateľov pripojených na danú sieť. Jeden z veľkých benefitov SIEM systémov je to, že dokážu monitorovať a chrániť v pozadí bez narušenia hlavnej premávky siete. Jednou z najhlavnejších častí SIEM systémov sú ich pravidlá. Konkrétne, normalizačné a korelačné pravidlá. Normalizačné pravidlá sa sústreďujú na zbieranie správ ohľadom rôznych udalostí v sieti. Napríklad keď používateľ použije príkaz sudo v systéme, tak normalizačné pravidlo dokáže zobrať správu, ktorú systém vytvoril v momente kedy ten príkaz bol využití. Následne túto správu spracuje, zanalyzuje a vytiahne z nej všetko potrebné (napr. kedy bol príkaz využití, meno užívateľa, načo bol príkaz použití). Takýmto spôsobom je možné zozbierať obrovské množstvo správ a využiť ich na analýzu diania v sieti. Korelačné pravidlá sa dokážu pozrieť na správy generované normalizačnými pravidlami a ďalej ich zanalyzovať. Po analýze korelačné pravidlá dokážu usúdiť, či ide o nekalú udalosť v systéme alebo v sieti. Napríklad keď používateľ zadá zle svoje heslo viackrát za sebou, tak korelačné pravidlo zobrazí varovanie o potencionálnom brute-force útoku. 62
Chapter 8. Conclusion Implementácia nových korelačných a normalizačných pravidiel V tejto práci som sa zameral na rozšírenie SecMon systému cez nové normalizačné a korelačné pravidlá. Cieľom projektu a implementácie bolo použitie monitorovacieho nástroja Suricata na zozbieranie a preposielanie správ o bezpečnostných udalostí nástroju SecMon a využitie používateľského rozhrania nástroja SecMon na zobrazenie a testovanie správnosti nových pravidiel. Prvým krokom bolo zabezpečenie prepojenia Suricaty a SecMon-u. Bolo nutné, aby Suricata dokázala zbierať správy v syslog formáte a tieto správy následne poslať ďalej SecMon-u. Suricata je nástroj, ktorý dokáže preposlať takéto správy iným SIEM systémov, takže nadviazať takúto spoluprácu nebolo zložité. Akonáhle bolo toto prepojenie zabezpečené tak som mohol začať z implementáciou. Bolo treba si naštudovať, ako fungujú normalizačné aj korelačné pravidlá a ako funguje nástroj SEC na tvorbu a testovanie takýchto pravidiel. Zameral som sa na detekciu podozrivých činností na sieti pomocou nástroja Suricata. Mojím prvím cieľom bolo spísanie normalizačného pravidla, ktoré dokáže spracovať akékoľvek logy zo Suricaty. Logy zo Suricaty môžu mať rôznu formu. Môžu využívať existujúce pravidlá alebo pravidlá ktoré si používateľ navrhol sám na akékoľvek účely. Bolo treba zabezpečiť, aby moje pravidlo spracovalo všetky druhy logov, ktoré Suricata dokáže vygenerovať. Toto bolo otestované viacerými nástrojmi ako sú hping3, nmap, metasploit a boli využité už existujúce aj vlastne vytvorené pravidlá. Normalizačné pravidlo dokázalo zachitiť všetky druhy logov. Druhým cieľom bolo vytvorenie korelačných pravidiel. V prácy som sa zameral na vytvorenie korelačných pravidiel na zachytenie útoku "Multifaceted attack", Ktorý prihádza z jednej konkrétnej IP adresy. V práci som vytvoril dva druhy 63
Chapter 8. Conclusion pravidiel na zachytenie tohto útoku. Prvé pravidlo dokáže zachytiť útoky z jednej IP adreasy na viaceré adresy v jednej sieti. Druhé pravidlo sa je napísané tak, aby zachytilo útoky z jednej, konkrétnej adresy na inú, konkrétnu adresu. V korelačných pravidlách sa uplatňuje druh pravidla EventType, ktoré je určené na spracovávania viacerých udalostí naraz. Obe pravidlá zároveň využívajú SEC kontexty, pomocou ktorých vytvoria viacero operácií, aby správne spracovali všetky možné udalosti. Napr. v prípade prvého pravidla, pokiaľ máme IP adresu útočníka 69.9.16.75 a útok, ktorý Suricata klasifikuje cez ID 2018959 tak pravidlo vie, že má sledovať IP adresu 69.6.16.75 do vtedy, dokiaľ nezaeviduje ďalšie útoky z tejto IP adresy alebo dovtedy, dokiaľ čas na detekovanie útokov neskončí. Pre testovanie som použil simulované staging prostredie na kontrolu normalizačného pravidla. Normalizačné pravidlo dokázalo odchytiť viacero podozrivých aktivít, ktoré Suricata zachytila a preposlala SecMon-u. Filter Ďalším vylepšením SecMon-u bolo prepísanie kódu filtra na zlepšenie UX. Starý filter obsahoval veľké množstvo možností a nemal žiadny spôsob, ako nimi prejsť čo najrýchlejšie. Obsahom práce je aj zároveň prepísanie kódu frontendu. V kóde bol použití jqery skript na implementovanie funkcionality vyhľadávania. Záver V práci som analyzoval viaceré aspekty kyberochrany. Vysvetlil som a porovnal som existujúce SIEM systémy zo SecMon-om a následne som navrhl a vytvoril vylepšienia. Na záver by som chcel poukázať na viaceré nedostatky nástroja SecMon, ktoré by sa dali v budúcnosti upraviť. Jednou z týchto chýb bol zle ošetrený 64
Chapter 8. Conclusion kód. V prípade zlých hodnôt pri tvorbe pravidiel by databáza dokázala akceptovať hodnoty z ktorými kód nedokázal pracovať. Verím ale že v budúcnosti by bolo možné takéto problémy opraviť. 65
Chapter 8. Conclusion 66
Literature [1] Some principles of secure design. Designing Secure Systems module Autumn 2015. url: https://docplayer.net/17241198- Some- principles- ofsecure-design-designing-secure-systems-module-autumn-2015.html (visited on 01/03/2024). [2] C.L. Smith. “Understanding concepts in the defence in depth strategy”. In: IEEE 37th Annual 2003 International Carnahan Conference onSecurity Technology, 2003. Proceedings. 2003, pp. 8–16. doi: 10.1109/CCST.2003. 1297528. [3] C.L. Smith and M. Robinson. “The understanding of security technology and its applications”. In: Proceedings IEEE 33rd Annual 1999 International Carnahan Conference on Security Technology (Cat. No.99CH36303). 1999, pp. 26–37. doi: 10.1109/CCST.1999.797888. [4] Shengjian Liu, Ping Zhang, and Huyuan Sun. “Research on Defense In-depth Model of Information Network Confrontation”. In: 2012 Fourth International Conference on Computational and Information Sciences. 2012, pp. 267–270. doi: 10.1109/ICCIS.2012.239. [5] Fault Tolerant Computing in Industrial Automation Hubert Kirrmann. url: https : / / docplayer . net / 19203213 - Fault - tolerant - computing - in - 67
Literature industrial-automation-hubert-kirrmann-abb-research-center-ch5405-baden-switzerland.html (visited on 01/03/2024). [6] What is SIEM? A Beginner’s Guide. url: https: // www. varonis . com / blog/what-is-siem (visited on 01/03/2024). [7] Gustavo González-Granadillo, Susana González-Zarzosa, and Rodrigo Diaz. “Security Information and Event Management (SIEM): Analysis, Trends, and Usage in Critical Infrastructures”. In: Sensors 21.14 (2021). issn: 1424- 8220. doi: 10 . 3390 / s21144759. url: https : / / www . mdpi . com / 1424 - 8220/21/14/4759. [8] SIEM Rules or Models for Threat Detection? url: https://www.exabeam. com / siem / siem - threat - detection - rules - or - models/ (visited on 01/03/2024). [9] Igor Kotenko and Andrey Chechulin. “Attack modeling and security evaluation in SIEM systems”. In: International Transactions on Systems Science and Applications 8 (2012), pp. 129–147. [10] Tim Laue et al. “A SIEM Architecture for Multidimensional Anomaly Detection”. In: 2021 11th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications (IDAACS). Vol. 1. 2021, pp. 136–142. doi: 10.1109/IDAACS53288.2021. 9660903. [11] Igor Kotenko et al. “Design and Implementation of a Hybrid OntologicalRelational Data Repository for SIEM Systems”. In: Future Internet 5.3 (2013), pp. 355–375. issn: 1999-5903. doi: 10.3390/fi5030355. url: https://www. mdpi.com/1999-5903/5/3/355. 68
Literature [12] A guide to SIEM platforms, benefits and features. url: https : / / www . techtarget.com/searchsecurity/feature/Comparing-the-best-SIEMsystems-on-the-market (visited on 01/03/2024). [13] SIEM Correlation is Overrated. url: https : / / blogs . gartner . com / augusto- barros/2017/03/31/siem- correlation- is- overrated/ (visited on 01/03/2024). [14] FortiSIEM Solutions. url: https://www.fortinet.com/products/siem/ fortisiem (visited on 01/03/2024). [15] FORTINET. FortiSIEM data sheet. 2024. [16] Micro Focus recognized as Visionary in 2022 Gartner Magic Quadrant for SIEM, with ArcSight evaluated. url: https : / / community . microfocus . com/cyberres/b/sws-22/posts/micro-focus-recognized-as-visionaryin- 2022- gartner- magic- quadrant- for- siem- with- arcsight (visited on 01/03/2024). [17] Bc. Matej Puk Bc. Matúš Jurika Bc. Roland Lang Bc. Štefan Kadlic Bc. Norbert Danišik Bc. Matej Guráň. Pôvodná dokumentácia SecMon. 2024. [18] SEC - simple event correlator. 2024. url: https : / / simple - evcorr . github.io/. [19] Simple Event Correlator Tutorial. 2024. url: https : / / simple - evcorr . github.io/SEC-tutorial.pdf. [20] Event Processing - Normalization. 2024. url: https://raffy.ch/blog/ 2007/08/25/event-processing-normalization/. [21] ArcSight CEF format. 2024. url: https://docs.centrify.com/Content/ IntegrationContent/SIEM/arcsight-cef/arcsight-cef-format.htm. [22] SecMon GitHub page. 2024. url: https://github.com/jlasti/secmon. 69
Literature [23] What is Event Correlation? Examples, Benefits, and More. 2017. url: https: / / digitalguardian . com / blog / what - event - correlation - examples - benefits-and-more. [24] Suricata User Manual. url: https : / / suricata . readthedocs . io / en / latest/user-guide/ (visited on 03/25/2024). [25] intrusion detection system (IDS). url: https : / / www . techtarget . com / searchsecurity/definition/intrusion- detection- system (visited on 03/25/2024). [26] What is an Intrusion Prevention System? url: https://www.digitalguardian. com/dskb/intrusion-prevention-system (visited on 03/25/2024). [27] VirtualBox. url: https://www.virtualbox.org/ (visited on 03/25/2024). [28] Ubuntu. url: https://releases.ubuntu.com/ (visited on 03/25/2024). [29] 15.3 Syslog alerting compability. url: https://suricata.readthedocs.io/ en/latest/output/syslog-alerting-comp.html (visited on 04/15/2024). [30] The BSD syslog Protocol. url: https : / / datatracker . ietf . org / doc / html/rfc3164#section-2 (visited on 04/15/2024). [31] Common Event Format: Event Interoperability Standard. url: https : / / raffy . ch / blog / wp - content / uploads / 2007 / 06 / CEF . pdf (visited on 05/20/2024). [32] jquery editable select github page. 2024. url: https://github.com/indrimuska/ jquery-editable-select. [33] testmynids.org github page. 2024. url: https://github.com/3CORESec/ testmynids.org. 70
Literature 71
Literature 72