# NCS. Project: Security Operational Center. Report.

[TOC]

## Team
B18-SB-01
* Daniil Manakovskiy
* Sergey Makarov
* Vlad Kalmykov
* Anton Brisilin

## Abstract
In the document we discuss the possibility of deploying a Security Opertaional Center using the open-source security solutions. We present a short review of the componets of a typical SOC, describe the architecture of our system. We describe SOC's role and the actions taken by the security team in case of detecting attacks. We also provide the OVAs of all the virual machines used.

## Introduction

Before start deploying, let us define some requirements to the system:
* Before the incident even happened, system should provide some passive protection, such as firewall.
* It should also do some scheduled security audits to make security team's life easier.
* In case an attack happened, it is very important to automatically detect security incidents and alert the security team, so that defensive measures can be taken immediately. This detection system can take some automated measures, for instance dropping suspicious connections.
* For each case of intrusion, all artifacts should be gathered in a convenient way, so that security analyst can identify causes of attacks and develop mitigation mechanisms.
* The system should contain utilities for investigation and reporting, so that security team can work in the most effective way.

Usually a SOC consists of 5 major components:
* Firewalls - a static intrusion prevention system, firewall is a network mechnism that prevents some network packets from being forwarded based on the contents of the TCP/IP headers
* IPS/IDS - Intrusion Prevention and Detection System - these systems can analyse network traffic at a deeper level than firewalls. They can make decisions based on the contents of the network packets and analyze patterns in the trafic. The main differense between an IPS and IDS is that the first one can take some measures in order to **prevent** a possible intrusion, whereas the latter only **detects** it.
* Security monitoring agent - detect suspicious behaviour through logs, running processes and user actions on each host.
* SIEM - security information and event management system
* Incident response platform - each case should be analyzed, and mitigation mechanisms developed. This platform helps to syncronizing work of multiple security analysts, and in the end of investigation collects overall results from each team member in a single report.

## Description of work done

### Architecture

As for monitoring agents, we decided to use Wazuh and Suricata. Suricata is used to monitor packets in the organisational network and detect suspicious traffic. Wazuh agent is installed to every host that needs to be monitored. It should detect any malware-connected activity within clients' systems.
Wazuh manager is used to gather monitoring data from agents on client machines and Suricata. It performs analysis of data, and saves it to the Elasticsearch via FileBeat.
Kibana is configured to fetch data from Elasticsearch and visualize it.
Additionaly, we have TheHive connected to the Wazuh manager in order to automatically gather all alerted logs in a single case and manage the investigation process.
Cortex simplifies investigation within TheHive through smart automated analysis of observabilities.

### How to deploy
The project is deployed in 3 VM machines: Win7 client, Mikrotik RouterOS, Parrot-Home IDS.

#### OVA
Mikrotik router: https://disk.yandex.ru/d/X822B8oUcJC0UA
IDS (Parrot OS): https://disk.yandex.ru/d/1Yi14K4q-9EgbQ
Win7 client: https://disk.yandex.ru/d/06Ec_uBcxL_BIQ

#### Machine IPs
ParrotHome: `192.168.0.252`
IEWin7: `192.168.0.251`
MikrotikRouter:
* internal network: `192.168.0.1`
* bridged

#### Interfaces on IDS
1. TheHive: http://localhost:9000
1. Cortex: http://localhost:9001
1. Kibana with Wazuh dashboards: https://localhost
1. Wazuh manager, agent connection: `TCP/UDP:1514`
1. Wazuh manager API: `TCP:55000`
1. Elasticsearch: `TCP:9200`
1. Kibana: `TCP:5601`

### PoC: attack cases

As a Proof of Concept we decided to do several "attacks" and simulate work of a security team, that tries to investigate what caused attacks and respond to these cases.

#### Case 1. Malicious website
At the middle of working night (US time) Security Team receives alerts in Slack chat:

Members open TheHive dashboards, and see weird alerts:

It creates TheHive case, includes these alerts and run Cortex analyzers for malicious IPs.

Security team tries to investigate, what was attacked:

It is visible, that IDS detected something what is supposed to be network trojan. Source IP is `104.21.22.216`, which is someone's public IP, and dest IP is `192.168.0.251`, which is client's host in our monitored network.

To investigate what is this malicious IP (`104.21.22.216`), team runs analyzers:

VirusTotal detected several URLs related to this IP. Team looks for all the URLs, and finds the reason:


Testmyids.ca is a "malicious" site. Now team creates a task for network operational team to block this website on the router firewall.

Now system administrator sees the task and adds new firewall rule.


#### 2. Malware
Slack has given new alerts. Now they look really scary:

At the TheHive dashboard it is visible, that our poor client with IP 192.168.0.251 seems to be attacked again. Suricata detected suspicious DNS lookup of Tor address, and then machine connects to it.


Suricata have guessed that this is a famous Cerber malware.
Machine's desktop can confirm this.


### PoC: Wazuh audit
Wazuh is capable of monitoring its agents and generating several types of reports:

#### Integrity monitoring

#### Vulnerability report

#### MITRE ATT&CK

Events summary:

#### Security configuration assessment

#### NIST 800-53 compliance

## What we learned
1. Never do random clicks.
Our machine was available for us only via TeamViewer ( required the internet connection). Once Daniil turned his laptop after the hybernation he got cursor bug either in TeamViewer or in VBox. His cursor was not in a proper position. He did couple random clicks thinking that the TV just temporarily lagged, but actually he managed to disconnect the VM from the internet with 5 random clicks. We lost it for almost an hour.

2. Monitor your hardware.
Well, we just accidentaly run too many VMs. Thus our machine got killed by OOM killer and didn't restart

3. Delete everything with patience and do backups.
Our teammate wanted to delete data inside a directory using
`sudo rm -rf ./*`
But got a typo and wrote
`sudo rm -rf /*`
So we got the machine almost dead since crucial files were deleted within couple of seconds. Thankfully we had some backups

## Conclusions
Deploying SOC is not an easy task. The hardest part is to integrate all services together.
However efforts worth it. As it is shown by PoC part of this report, SOC helps monitoring security state of the network and clients.
If there were more than one client in the network, it would be hard to manually notice that something happens.

## Future works
Currently all network trafic is streamed to the IDS machine to be analyzed by Suricata. In production-scale systems such behavior will cause DoS of our network. The solution is to deploy Suricata to every client, connect it to local wazuh-agent and filter out unneded alerts.

For the sake of project we deployed the whole IDS inside one powerful machine. Clearly it is a single point of failure. It would be better to have a distributted setup.