Technical Report By CyberFortress

Name Surname
Med Arbi Bacha
Yasmine Ben Youssef
Walid Jaouani
Mehdi Azzaz
Ghaith Mechergui
Omar Ouenich
Achref Hamdi

Tutors : Salma Alkhayat, Sarra Berrahal, Fatma Louati, Hend Ben Moussa

2022-2023
Technical Report 0

Contents

List of Figures 3

List of Tables 4

1 Project Description 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Technical Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Project Solution 1
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Study Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2.1 Traditional SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2.2 Next-Generation SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2.3 Comparison Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.3 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.4 Physical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.5 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6 Defense-in-depth strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.7 Compliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.7.1 HIPPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.7.2 ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.8 Technologies used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.8.1 DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.8.2 HoneyPot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.8.3 SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.8.4 SOAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9 Machines and IP list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Deployment 1
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.2 SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.2.1 SIEM (ELK Stack) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.2.2 EDR (Wazuh) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2.3 NDR (SELKS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.4 XDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 SOAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1 SAO (Shuffle) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.2 TIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.3 SIRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.4 Cuckoo sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Implementation 1
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.2 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.2.2 Attack description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.3 Real-Time Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.3.1 Malware Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.3.2 Malware Detection by Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.3.3 Alert Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.3.4 Shuffle workflow execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Page 1
 4.3.5 Alerting The Incident Response Platform . . . . . . . . . . . . . . . . . . . . . . . 4
4.3.6 Alert Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3.7 Case Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4 Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 General Conclusion 1
List of Figures
2.1 The Physical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 The Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Layer defense diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Hippa Dashboard Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 NIST Dashbaord wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Wazuh Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 SELKS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.8 SOAR Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Integrations ELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.2 Integrations ELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.3 Wazuh Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.4 Wazuh Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.5 SELKS Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.6 XDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.7 Shuffle Home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.8 Shuffle Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.9 MISP Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.10 TheHive Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.11 The Hive Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.12 Cuckoo Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Payload Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.2 Wazuh Alerted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.3 Wazuh Detect alerts from the victim machine . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.4 Workflow for Alert creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.5 Workflow for case creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.6 TheHive Live Alerts Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.7 TheHive detailed Alert list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.8 alert feeds from Wazuh to be treated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.9 Shuffle creation of the case flowing a specific workflow . . . . . . . . . . . . . . . . . . . . 6
4.10 The first case created from Wazuh Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.11 Second case created from Wazuh Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.12 Analyzing Malicious a file with Cuckoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.13 Result of the Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
List of Tables
1.1 Requirements vs Technical Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Table Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Machines and their respective IP and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 List Malware types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Technical Report 1

1 | Project Description
1.1 | Introduction
This chapter will describe the project overview, the objectives, and the technical requirement that needs
to be met.

1.2 | Project Overview

The main purpose of this project is to implement a Proof of Concept (PoC) of a next-generation SOC
solution provided by ITC Consulting while considering the requirements expressed in the current project
specification sheet. In particular, this project aims to design a functional and technical architecture,
benchmark open-source solutions, and install and test the solutions chosen to integrate them in the same
environment.
The following features have to be considered in the deployed SOC:

■ Vulnerability Management: Correlating log data with threat intelligence to understand what exploits
attackers are using, and identify vulnerable elements within an infrastructure before they can be
compromised.
■ Automated Incident Response: Taking action automatically when a particular kind of incident
occurs via rules called playbooks. It is possible to set up automated responses for the most common
incident types via this functionality.

■ Investigations Coordination: Organizing security data easily and retrieving relevant third-party
threat intelligence when needed. Instant access to external data sources helps analysts make the
right decision in every investigation.
■ Automate compliance reporting: The provided solution should achieve compliance with applicable
industry regulations such as ISO2700x, GDPR, HIPAA, SWIFT, SOX, and PCI DSS.

■ Comprehensive Integration: Getting different IT security solutions to work together because SOCs
often use a range of security tools from various vendors, and even though they are practical on their
own, these tools lack interoperability.
■ Security analytics integration: To properly ingest and analyze data, machine learning, and deep
learning technologies have to be considered. The deployed ML/DL-based security solutions should
detect abnormal and risky behavior on the corporate network (e.g., prevent the misuse of privileged
account access, ensure the appropriate use of access rights, verify file integrity, and prevent data loss
and data leakage).
■ Automate Asset Security Testing: Offensive security should also be supported through the automation
of the monitoring and analysis of threats and misconfiguration of assets, providing real-time scanning,
and providing summarized and detailed PDF reports.-

1.3 | Project Objectives

■ Provide a comprehensive overview that evaluates the business influence of vital assets, the potential
odds of an attack, and the effects of vulnerabilities and security threats.
■ Design the security architecture.
■ Provide a layered architecture that modularizes the SOC components into different layers based on
three key functionalities – integration, automation, and orchestration.

■ Deploy, configure, and integrate appropriate security solutions for both physical and virtual infras-
tructures.
■ Test the effectiveness and efficiency of the deployed SOC solution against internal and external
attacks.
■ Provide a comprehensive review of the organization’s adherence to regulatory health compliance.

Page 1
Technical Report 1

1.4 | Technical Requirements

Table 1.1: Requirements vs Technical Constraints

1.5 | Conclusion
In conclusion, implementing a physical architecture for a hospital that complies with HIPAA and ISO
27001 requirements is critical to ensuring the security and confidentiality of patient data. This requires
careful planning and execution to meet all technical requirements.
Key technical requirements for the physical architecture of a hospital include secure access controls, data
encryption, backup and disaster recovery systems, and network security. alarm systems are also crucial to
protecting sensitive data and assets.
In addition to meeting technical requirements, it is important to maintain ongoing compliance with HIPAA
and ISO 27001 standards through regular security audits and assessments. This helps identify and address
any vulnerabilities or weaknesses in the physical architecture and ensures that the hospital is continuously
improving its security measures.
By prioritizing the technical requirements for physical architecture following HIPAA and ISO 27001,
hospitals can provide their patients with a safe and secure environment for receiving care while maintaining
compliance with regulatory standards.

Page 2
Technical Report 2

2 | Project Solution
2.1 | Introduction
This chapter will describe the solution for our project and we will see the physical architecture and the
different zones and technologies.

2.2 | Study Case

A Security Operations Center (SOC) is an essential part of an organization’s cybersecurity strategy.
It’s a centralized team responsible for monitoring, detecting, and responding to security incidents in an
organization’s IT environment.

2.2.1 | Traditional SOC

Traditionally, SOCs used manual processes and security monitoring to detect and respond to threats. They
relied on technologies such as SIEM (Security Information and Event Management), threat intelligence
feeds, and incident response processes. However, as the threat landscape has become more complex,
traditional SOCs have struggled to keep up with the speed and sophistication of cyber attacks.

2.2.2 | Next-Generation SOC

A next-generation SOC uses more advanced technologies and processes to improve threat detection and
response. These SOCs leverage automation and orchestration to speed up the identification and response
to threats. They use machine learning, artificial intelligence (AI), and robotic process automation (RPA)
to identify patterns and anomalies in security data and automate incident response workflows to quickly
contain and remediate security incidents.

2.2.3 | Comparison Study

Table 2.1: Table Comparison

This table summarizes the difference between a traditional SOC and Next Generation SOC:

■ Approach : A traditional SOC waits for incidents to occur before responding. A next-generation
SOC takes a more proactive approach by using threat intelligence, predictive analytics, and other
advanced technologies to identify and prevent threats before they occur.

Page 1
Technical Report 2

■ Monitoring : T. SOCs typically rely on the manual monitoring of security events, which can be
time-consuming and prone to errors. A next-gen SOC uses automated monitoring tools that can
quickly analyze vast amounts of security data to identify potential threats.

■ Threat Detection: [Link] often use signature-based detection methods to identify known
threats. Next-gen SOCs use behavior-based detection techniques that can identify anomalies in user
and system behavior that may indicate a previously unknown threat.
■ Analytics : [Link] typically use simple rule-based analytics to identify security incidents.
Next-gen SOCs use advanced analytics, including machine learning, to detect and respond to threats
in real time.
■ Scalability : The traditional one may have a limited capacity to handle the increasing volume
and complexity of security incidents but the next-gen SOCs are designed to be more scalable, with
elastic computing resources that can handle large-scale security events.
■ Integration : [Link] may not be well integrated with other security tools and technologies such
as endpoint detection and response (EDR), network traffic analysis, or vulnerability management
tools. Next-generation SOCs are designed to be more integrated with other security tools, allowing
for a more comprehensive view of the security landscape.
■ Incident Response : Traditional SOCs may not have access to the latest threat intelligence data,
which can limit their ability to detect and respond to new threats. Next-generation SOCs use a wide
range of threat intelligence sources to provide a more comprehensive view of the threat landscape.
■ Threat Intelligence : Traditional SOCs lack access to the latest threat intelligence data, limiting
their ability to detect and respond to new threats. Next-generation SOCs use diverse threat
intelligence sources for a comprehensive view of the threat landscape, allowing them to better detect
and respond to emerging threats.

■ Threat Intelligence : Traditional SOCs lack access to the latest threat intelligence data, limiting
their ability to detect and respond to new threats. Next-generation SOCs use diverse threat
intelligence sources for a comprehensive view of the threat landscape, allowing them to better detect
and respond to emerging threats.
■ User and Entity Behavior Analytics: Traditional SOCs don t have access to advanced user
and entity behavior analytics tools, which can limit their ability to detect insider threats and other
advanced attacks. Next-generation SOCs often include those tools as a built-in feature.

2.3 | Proposed Solution

The solution that we propose is a next-generation SOC architecture that combines threat detection
features with incident response features in an automated environment to help reduce the workload of the
soc team, reduce time, and prioritize serious threats

Page 2
Technical Report 2

2.4 | Physical Architecture

Figure 2.1: The Physical Architecture

The figure describes the physical architecture of the implemented infrastructure using the Defense in
Depth strategy to create a more secure environment where layers of security controls are used to protect
organization assets.
The combination of Wazuh, Modoboa, AD Server, Nagios, NGINX, ELK, DNS, SELKS, Shuffle, Cortex,
MISP, The Hive, and Cuckoo Sandbox form a powerful suite of cybersecurity tools and services that can
be used to detect and respond to cyber threats.
Wazuh, with its OSEC agent variant called WAZUH agent, uses rules imported from SOC Fortress and is
integrated with NDR to create an XDR. Modoboa provides an SMTP/IMAP server with a user interface
and a MongoDB database.
AD Server is a Windows server used for Active Directory.
Nagios is a monitoring system that allows administrators to quickly detect and respond to issues.
NGINX is a powerful web server and reverse proxy that is known for its high performance, scalability,
and security features.
ELK is particularly useful for detecting and responding to security incidents, while DNS plays an important
role in protecting against various types of attacks.
SELKS is a network security distribution that provides a comprehensive suite of network security tools
and services for detecting and responding to cyber threats.
Shuffle is an open-source security platform designed to help users streamline their security operations.
Cortex is an AI-powered social media marketing platform that can improve ROI and engagement processes.
MISP is a software solution that allows users to collect, store, distribute, and share cybersecurity indicators
and threats about cyber incidents and malware analysis.
The Hive is a scalable Security Incident Response Platform, tightly integrated with MISP, designed to
make life easier for SOCs.
Finally, Cuckoo Sandbox provides an automated and customizable platform for analyzing malware samples.
Together, these tools and services can provide a comprehensive solution for protecting against cyber
threats and ensuring the security of digital assets.

Page 3
Technical Report 2

2.5 | Logical Architecture

Figure 2.2: The Logical Architecture

The figure refers to the conceptual architecture and the different blocks where information’s collected
from multiple sources like network traffic, security events collectors.

2.6 | Defense-in-depth strategy

Figure 2.3: Layer defense diagramme

■ Defense in depth is a cybersecurity strategy that involves the implementation of multiple layers
of security controls throughout an IT infrastructure. The goal is to provide overlapping layers of
protection to reduce the likelihood and impact of a successful cyber attack.

Page 4
Technical Report 2

■ The strategy involves implementing a range of security controls, including firewalls, intrusion
detection and prevention systems, antivirus software, access controls, encryption, and employee
training. Each layer of security provides a barrier against cyber threats, and if one layer is breached,
the remaining layers provide additional protection.

2.7 | Compliances
In our Project, we decided to use two compliances HIPPA and ISO 27001.

2.7.1 | HIPPA
■ HIPAA stands for the Health Insurance Portability and Accountability Act. It is a federal law passed
by the United States Congress in 1996 to protect the privacy and security of health information.
■ Privacy Rule: This rule establishes national standards for the protection of personal health informa-
tion. It sets limits on the use and disclosure of PHI and gives patients certain rights with respect to
their health information.

■ Security Rule: Requires healthcare organizations to implement safeguards for electronic health
information. Breach Notification Rule: Requires notification in case of a breach involving unsecured
electronic protected health information (ePHI).

Figure 2.4: Hippa Dashboard Wazuh

2.7.2 | ISO 27001

■ ISO 27001 is a global standard for information security management systems (ISMS).
■ Provides a systematic approach to managing sensitive information using a risk management approach.
■ Involves a set of requirements and best practices for implementing an effective ISMS, including
policies, procedures, and controls to manage information security risks. Not specific to healthcare
but can the approach can be used to enhance cybersecurity practices.

The National Institute of Standards and Technology (NIST) is the equivalent standard-setting body for
cybersecurity and information management in the United States, just as ISO/IEC 27001 serves as the
international standard for information security management systems (ISMS).

Page 5
Technical Report 2

Figure 2.5: NIST Dashbaord wazuh

2.8 | Technologies used

2.8.1 | DMZ
■ Web server(NGINX) : is a powerful web server and reverse proxy that is widely used for its high
performance, scalability, and security features.
■ Nagios : is a monitoring system that enables organizations to identify and resolve IT infrastructure
problems before they affect critical business processes. Nagios monitors hosts, services, and network
devices, and alerts system administrators when something goes wrong. It provides a centralized
view of the entire IT infrastructure, enabling administrators to quickly detect and respond to issues.
■ DNS (Domain Name System) : is a critical service used for translating human-readable domain
names into IP addresses that can be understood by computers. In the context of cybersecurity, DNS
plays an important role in protecting against various types of attacks.
■ SMTP (Modoboa): a free and open-source mail hosting and management platform that allows
users to manage their email accounts and domains in a web-based interface. It provides a user-friendly
interface for managing domains, mailboxes, aliases, and other email-related tasks. Modoboa also
supports multiple languages, spam filtering, and integration with external services such as LDAP,
IMAP, and SMTP.
■ Active Directory : is a Microsoft-developed directory service that manages user accounts, comput-
ers, and other network resources in a hierarchical structure. It provides centralized authentication,
authorization, and management for Windows-based networks.

2.8.2 | HoneyPot
■ HoneyNet : is a security mechanism designed to detect and analyze the behavior of malicious
actors on a network by deploying a network of decoy systems and services that appear to be real
but are designed to lure attackers. The honeynet consists of various components, including virtual
or physical machines, network devices, and other assets that are configured to appear as legitimate
targets for attackers. The goal of a honeynet is to monitor the attacker’s actions and techniques, gain
insight into their motives and methods, and improve the security of the real network by identifying
vulnerabilities and attack vectors. Honeynets are often used by security researchers and organizations
as a proactive measure to prevent and mitigate cyber-attacks.

2.8.3 | SOC
■ SIEM (ELK) : In the context of cybersecurity, ELK is particularly useful for detecting and
responding to security incidents. It enables security teams to collect and analyze log data from a
wide range of sources, including network devices, servers, and applications. This log data can then
be used to identify potential security threats, such as unauthorized access attempts or suspicious
network activity.

Page 6
Technical Report 2

■ EDR (Wazuh) : Is a free and open-source security platform that provides threat detection,
visibility, and compliance management, and also provides centralized management for security
policies, compliance reporting, and incident response. our version has custom rules added to it for
security and is used as an EDR by installing the Wazuh agent on machines and on Suricata to
provide the capability of XDR.

Figure 2.6: Wazuh Architecture

■ NDR (SELKS) : Is a network security distribution based on the Debian GNU/Linux operating
system. It is designed to provide a comprehensive suite of network security tools and services for
detecting and responding to cyber threats.

Figure 2.7: SELKS Architecture

NDR is next generation network detection response platform that replaces network intrusion detection
solutions, it offers advanced features that makes the incident response process more efficient and more
reliable than older solutions.

Page 7
Technical Report 2

2.8.4 | SOAR

Figure 2.8: SOAR Architecture

The figure illustrates the role of each element as well as the functionalities it offers and how communication
is established between them.
■ SOA Shuffle : is an open-source tool used to automate routine tasks and orchestrate multiple
automated tasks to achieve a desired outcome such as intelligence gathering, incident investigation,
incident investigation, and response coordination.
■ Cortex : is a powerful orchestration platform that is used for case management, and threat
intelligence and integrates a wide range of security technologies using a pre-built library of playbooks.
■ TIP MISP : is an open-source software solution for collecting, storing, distributing, and sharing
cybersecurity indicators and threats about cybersecurity incidents analysis and malware analysis.
■ SIRP The Hive : is a scalable Security Incident Response Platform, tightly integrated with
MISP (Malware Information Sharing Platform), designed to make life easier for SOCs, cybersecurity
incidents analysis, and malware analysis.
■ Cuckoo : is an open-source dynamic malware analysis system that provides an automated and
customizable platform for analyzing malware samples and suspicious files images, it has an isolated
environment that allows the visualize the behavior of malware.

Page 8
Technical Report 2

2.9 | Machines and IP list

Table 2.2: Machines and their respective IP and Ports

The table represents the elements of the architecture as well as the network configuration and the ports
used by each service.

2.10 | Conclusion
In this chapter, we presented the proposed solution to implement as well as the physical and logical
architecture, with a detailed description of each element of the next-generation Security operation center.
In the next chapter, we will talk about the system requirements as well as how we deployed those solutions
in the architecture.

Page 9
Technical Report 3

3 | Deployment
3.1 | Introduction
In this chapter we will talk about how each service was deployed in our solutions, we will also dive deep
into the configuration of each service as well as the rules that were used in it.

3.2 | SOC
3.2.1 | SIEM (ELK Stack)
■ System Requirements: The ELK solution was run on a VM with these specifications:

- Processor: 2 Core Processor

- RAM: 8 GB

- Operating System: Ubuntu 22.04

- Storage: 80 GB
■ Installation and Configuration :
- Phase 1: Configure the network interface to a static IP in our case we chose the address
[Link] .
- Phase 2: Download and install Elasticsearch from the apt repository and then edit Elasticsearch’s
main configuration file, [Link] to the address of the interface.
- Phase 3: Enable the elastic server.
- Phase 4: Install Kibana and configure it to the elastic server installed.
- Phase 5: Enable the Kibana server and generate elastic passwords and tokens.

■ Installing the Fleet Server : Install the fleet server from the integrations tab, add user policies,
and add agents to each user policy.
■ Integrations : These are the components we chose to integrate with our user policies:

Figure 3.1: Integrations ELK

■ Importing Custom Rules : For the ELK solution to detect custom events and to generate alerts
for events that would not be detected otherwise, import custom rules for new attacks and intrusions.

Page 1
Technical Report 3

Figure 3.2: Integrations ELK

3.2.2 | EDR (Wazuh)

■ System Requirements : The Wazuh solution was run on a VM with these specifications:

- Processor: 2 Core Processor

- RAM: 12 GB

- Operating System: Ubuntu 20.04

- Storage: 120 GB
■ Installation and Configuration : The installation process went in 5 Phases :
-Phase 1: Configure the network interface to a static address which is in our situation [Link].
-Phase 2: Install a Wazuh indexer node on the virtual machine.
-Phase 3: Install the Wazuh server and tie it to the Wazuh indexer node that was created in the
second phase.
-Phase 4: Install the Wazuh dashboard and tie it to our Wazuh server.
-Phase 5: Configure Wazuh custom rules.

■ Adding Agents : We added agents of the Windows machines and services on the network as well
as the Linux machines and services.

Page 2
Technical Report 3

Figure 3.3: Wazuh Agents

■ Importing Custom Rules : For the Wazuh solution to detect custom events and to generate
alerts for events that would not be detected otherwise, we create custom rules for new attacks and
intrusions.

Figure 3.4: Wazuh Rules

3.2.3 | NDR (SELKS)

■ System Requirements : The SELKS solution was run on a Docker cluster with these specifications:

- Processor: 2 Core Processor

Page 3
Technical Report 3

- RAM: 10 GB

- Operating System: Ubuntu 20.04 Docker-Based

- Storage: 100 GB extended depending on storage requirements

■ Installation and Configuration : The installation process went in 5 Phases :
-Phase 1: Install and configure a virtual machine to use the next ip address [Link].
-Phase 2: Install Docker and docker-compose to manage docker cluster
-Phase 3: Pulling the docker images for each service and running it
-Phase 4: Configure Suricata rules and update rulesets
-Phase 5: Deploy the cluster with the final configuration.

Figure 3.5: SELKS Dashboard

3.2.4 | XDR
To implement an extended detection response solution it is possible to integrate an EDR and [Link]
solution offers better visibility over the infrastructure to detect intrusion in the early stage of the attack
with better information about the targeted victim.

Figure 3.6: XDR

The required configuration for this implementation is to configure Wazuh Agent on the Suricata endpoint
to collect network alerts following the next steps:

Page 4
Technical Report 3

-Phase 1: Install Wazuh agent on SELKS machine and configure the IP address for Wazuh manager
[Link].
-Phase 2: Locate the path for the file that contains the generated alerts and add it to the agent configuration
file
-Phase 3: Start the agent
-Phase 4: Add the SELKS alerts parser to Wazuh-manager
-Phase 5: Add the Decoder for SELKS rules and start collecting alerts

3.3 | SOAR
■ System Requirements : The SOAR solution was run on a Docker Cluster with these specifications:

- Processor: 4 Core Processor

- RAM: 16 GB

- Deployment method: Debian 9 Docker-based

- Storage: 240 GB

■ Installation and Configuration : The installation process went in 4 Phases :

-Phase 1: Configure the network interface to a static address which is in our situation [Link].
-Phase 2: Install Docker engine and Docker compose.
-Phase 3: Pull repository and pull images
-Phase 4: Run containers .

3.3.1 | SAO (Shuffle)

■ Configuration : To allow Shuffle Automation to communicate with other services we need to
follow the next configuration:
-Phase 1: Import Rest API of the service.
-Phase 2: generate an API key
-Phase 3: Configure the authentication of the REST API by adding the API key URI and the
organization(optional)
-Phase 4: use API authentication to communicate THE REST API with the service .

Page 5
Technical Report 3

Figure 3.7: Shuffle Home page

This figure represents the home page of Shuffle where you can create new workflows and manage existing
ones.

Figure 3.8: Shuffle Workflows

This figure describes an example of shuffle workflow. this workflow handles the creation of new alerts
after receiving an event of security services like the EDR after the successful creation of the alert Shuffle
will extract the IOCs (indices of compromise) and create the respective case for the alert

3.3.2 | TIP
■ Configuration : To allow other applications to communicate with MISP the following configuration
must be followed:
-Phase 1: create a new user account
-Phase 2: generate the API key of this account
-Phase 3: add the API key to each service that requires an authentication method with MISP

Page 6
Technical Report 3

Figure 3.9: MISP Homepage

3.3.3 | SIRP

Figure 3.10: TheHive Dashboard

This figure illustrates the main dashboard of the hive which shows the alerts, open cases, and treated
■ Configuration : To communicate TheHive with MISP and Cortex the following configuration
must be implemented:
-Phase 1: Generate API Keys of MISP and Cortex
-Phase 2: Add the API keys to The Hive configuration file
-Phase 3: Restart the Hive and check if Cortex and MISP are connected

Page 7
Technical Report 3

Figure 3.11: The Hive Dashboard

This Figure illustrates the dashboard of Cortex where analyzers are shown, It allows us to check the status
of each running job and the output.

3.3.4 | Cuckoo sandbox

Figure 3.12: Cuckoo Dashboard

Cuckoo Sandbox is a powerful Dynamic malware analysis tool used for observing and analyzing malware
behavior in a virtual and isolated environment, It can help the Soc team to analyze phishing e-mails,
jointed files, and more.

Page 8
Technical Report 3

3.4 | Conclusion
In this Chapter, we presented the implementation of different services as well as the requirement,
configuration, and results. In the next chapter, we will talk about how we implemented those features
and how they were tested in a scenario.

Page 9
Technical Report 4

4 | Implementation
4.1 | Introduction
This Chapter will demonstrate a use case scenario and how each element of the solution will react to this
incident
.

4.2 | Scenario
4.2.1 | Description
An Employee of the company found a flash drive in front of the building of the company, after picking
it up, He found a label writing on it important, so wanting to help find the owner of the flash drive he
decided to plug the flash drive into his work computer and see the content, he ran a malicious malware
in his computer. This is a hypothetical example of course, with this scenario we will see how our SOC
architecture will respond to such an attack.

4.2.2 | Attack description

■ Malware Attack: Malware attack is an execution of a malicious program on the victim’s machine
that gives an attacker access to the victim’s machine to recover sensitive data and manipulate the
machine in a malicious way, generally a malware attack follows the next steps:
-Phase 1: The victim starts by receiving a malicious file generally in an e-mail or document.
-Phase 2: The victim accesses this file and executes it if the antivirus does not detect the malware
the attack will be successful.
-Phase 3: If the attack is successful the malware will start a communication with the hacker’s
computer to let him know that the attack is successful and give him access to the victim’s machine.
-Phase 4: The attacker will start his attack and the victim’s machine is now compromised.

■ Table Malware types :

Table 4.1: List Malware types

4.3 | Real-Time Scenario

Right after running the malware, the Wazuh agent will report the alert to Wazuh where it will be classified
in the dashboard as a high-level alert.

Page 1
Technical Report 4

4.3.1 | Malware Execution

Figure 4.1: Payload Execution

This figure shows the executed malware on the victim machine it is used in an isolated environment the
malware will service under the name [Link] which is a well-known service in Windows that allows to
share resources across multiple services it can record user actions like keyboard inputs and other actions

4.3.2 | Malware Detection by Wazuh

Figure 4.2: Wazuh Alerted

This figure elaborates on the events detected by sysmon and Wazuh-agent that are sent to The Wazuh-
Manager with a high severity level that will be later alerted.

Page 2
Technical Report 4

4.3.3 | Alert Creation

Figure 4.3: Wazuh Detect alerts from the victim machine

After the events are detected this figure demonstrates the creation of the Alerts that will be later sent
to Shuffle Automation by a specific Web hook which is used to send information in JSON format to be
analyzed by the workflow

4.3.4 | Shuffle workflow execution

Figure 4.4: Workflow for Alert creation

The Figure describes the Workflow used to create alerts where information coming from the web-hook is
analyzed and required fields are used to enrich the info about the alert.

Page 3
Technical Report 4

Figure 4.5: Workflow for case creation

The figure describes the workflow used to create a case where general information is used to enrich the case
and observables are extracted from the fields ( IP addresses, executed command, running files, privilege
escalation, file creation, and file Hash ) which are IOC’s that will be later used to decide if the alert is a
true positive or negative and if there is an impact to the system

4.3.5 | Alerting The Incident Response Platform

Figure 4.6: TheHive Live Alerts Dashboard

This figure shows a live feed for newly created alerts in the hive platform that helps the SOC team monitor
alerts and optimize incident response time

Page 4
Technical Report 4

4.3.6 | Alert Generation

Figure 4.7: TheHive detailed Alert list

We can observe with more detail each alert generated by Shuffle, where we can see the time and date of
the creation of the alert the status, and the timer for the duration the alert is not treated yet.

4.3.7 | Case Creation

Figure 4.8: alert feeds from Wazuh to be treated

In this figure we list the execution status of each alert generated for security service that was forwarded
to Shuffle automation to see the status of the progress and if any execution has failed to investigate it
later and resolve the problem.

Page 5
Technical Report 4

Figure 4.9: Shuffle creation of the case flowing a specific workflow

This figure describes the steps of the execution where we can see the orchestration of each tool and the
status of each level of the workflows until the success of the final step.

Figure 4.10: The first case created from Wazuh Alerts

In this figure, we illustrate an example of the automatically generated case where shuffle uses the analyst
account to generate the case, The title of the case is extracted from the alert generated by Wazuh-Manager.
The incident is related to non-interactive PowerShell execution mostly related to the execution of a
malicious command to execute a program in the background without the user’s knowledge.

Page 6
Technical Report 4

Figure 4.11: Second case created from Wazuh Alerts

In this figure, we illustrate another example of the automatically generated case where shuffle uses the
analyst account to generate the case, The title of the case is extracted from the alert generated by
Wazuh-Manager. The incident is related to a file being dropped in a folder which is a technique used by
malware to hide in a way that is under a legitimate service name so the user does not see that something
fishy is happening and antivirus can not detect usually, this is a common method used by hackers to hide
malware and executable to keep access to the victim machine.

Figure 4.12: Analyzing Malicious a file with Cuckoo

To better understand the behavior of the malware the analyst was able to identify the malicious file and
run it in the Cuckoo Sandbox, this figure demonstrates the start of the analysis of the [Link] file.

Page 7
Technical Report 4

Figure 4.13: Result of the Analysis

After analyzing the malicious file the following results were shown, The figure illustrates the analysis
result of the malware analysis, the malware was trying to reach the attacker’s machine to let him know
that the execution was successful.
Luckily the Response team was able to stop the attack before the attacker was able to connect to the
victim’s machine and isolated it.

4.4 | Remediation
■ Remediation: To respond to these types of attacks the Incident response team must flow these
steps:
-Step 1: Isolate the victim machine to stop the attack from spreading in the network
-Step 2: Detect the source of the attack and block it
-Step 3: Quarantine the machine and eliminate the malware
-Step 4: Analyze the network to see if there are any other contaminated machines and reduce the
attack surface.
-Step 5: Recover any leaked data, resume normal work, and learn how the attack happened.
-Step 6: Train employees to learn how to act in such scenarios to avoid the attack happening again.

4.5 | Conclusion
In this Chapter, we described a case study where an attack is being executed how the next-gen SOC
functioned, and how to respond to such attacks

Page 8
Technical Report 5

5 | General Conclusion
During this Project, we were able to propose and deploy a next-generation-SOC for the healthcare industry.
In the first Chapter, we presented the overview of the project as well as the project requirements.

In the second Chapter, we detailed the difference between a traditional SOC and next-gen SOC, and
finally, we presented the proposed solution architecture, tools used, and the followed regulation.

In the third Chapter, we dived into the deployment of each tool used in the creation of a next-generation
soc where we detailed the hardware requirement of each tool and the deployment method as well as a
descriptive guide on how to deploy each tool.

Finally, In the last Chapter, we studied a real-time scenario where a malicious file has been executed and
how the solution detected this attack and alerted the SOC team and how to handle the incident.

Page 1