As discussed previously, some of the common challenges in SIEM platforms is the platform management, real-time communication, alert customization, etc. To address these challenges, Adrian provides solutions for SIEM platform management, real-time communication on alerts, alert customization, etc. Apart from resolving the challenges discussed, Adrian also has new features that introduces a paradigm shift in how security alerts are managed and responded to across platforms. This innovative approach adds more values to SIEM platforms and to the overall cybersecurity field.

The design of Adrian is based on the principles of reliability, customization, categorization, and bidirectional communication. Before delving into the design principles of Adrian, it is important to introduce the architecture of Adrian. The architecture of Adrian revolves around a seamless integration between existing SIEM platforms and wisely used collaboration tools. The integration is enabled through a middleware. The middleware layer ensures that the data transmission is reliable between the two platforms even during downtimes or high-traffic scenarios.

The middleware is a robust message broker that would handle the communication between the SIEM platform and the collaboration tool. Not only does this framework preserve the confidentiality and integrity of the message, but also ensure that the alerts are categorized and prioritized before being sent to the collaboration tool. These mechanisms assist in focusing on high-priority alerts, which require immediate attention.

Adrian’s innovative bidirectional communication design is one of its core features that sets it apart from traditional alert management systems. Apart from just alert distribution, Adrian integrates the platforms to enable SIEM management activities through the collaboration tool.

· Reliability—Adrian prevents data loss in scenarios where the collaboration platform is down. This reliability is possible because of the introduction of middleware queueing mechanism. If the collaboration platform is down, then Adrian’s queue would have all the alerts stored and then send it to the collaboration platform when it is functioning. This makes Adrian a reliable solution.

· Customization—Adrian’s solution resolves the issue of alert customization by including only the relevant fields and modifying it to a more readable format. The cleaned data is then sent to the collaboration platform. This alert customization mechanism would help the DevSecOps teams to interpret the alerts.

· Categorization—Apart from alert customization, Adrian has the capability for alert categorization also. Based on the severity level of the alert, it categorizes the alerts into 3 categories—low, medium, and high alerts. This would be helpful for organization as the DevSecOps team can primarily focus on the high priority alerts.

· Alert Statistics—Another advantage of Adrian is the generation and communication of the alert statistics. Adrian not only calculates the alert statistics, but also provides a visual representation of the generated statistics and sends to a separate channel in the organization’s collaboration platform. Adrian also ensures that this communication is performed in a separate channel so that the statistics is not confused with the alerts. These statistics enable security teams to identify trends, allocate resources efficiently and improve overall security posture.

· Bidirectional Communication—The most important feature of Adrian is its two-way communication channel. Adrian would not only provide communication from the SIEM platform to the collaboration platform, but also provide SIEM platform management activities through a channel in the collaboration platform. Adrian’s bidirectional channel allows a more dynamic interaction between the two platforms, thereby significantly shortening response times and enhancing operational agility.

The above advantages help in making Adrian a robust, reliable, and scalable solution. These design principles not only significantly reduce the response time to incidents, but also enables a more dynamic and interactive approach to security management. Adrian was primarily built to bridge the gaps and provide a more comprehensive solution.

The proposed solution, Adrian, is divided into two phases. The first phase involves alert distribution from the SIEM platform to the collaboration platform. The second phase involves response network from the collaboration platform to the SIEM platform.

Unlike the traditional approach of integrating two systems using APIs, Adrian uses a more reliable and scalable approach. It uses a middleware queueing mechanism that would not only connect SIEM platform with the collaboration platform but also regularize the traffic flow between the two platforms. Figure 2 provides a high-level architecture of Adrian through middleware where the message broker would be the queueing mechanism that would connect the SIEM platform to the collaboration platform.

The message broker such as RabbitMQ or ActiveMQ helps in the asynchronous communication between the two platforms. Without waiting for the acknowledgement from the collaboration platform, the message broker would send an acknowledgement to the SIEM platform so that the SIEM platform can continue with the other allocated tasks.

The message broker would also help in prioritizing the alerts through Adrian’s alert customization and alert categorization features. This queueing mechanism would ensure efficient processing and delivery to the appropriate channels in the collaboration platform, thereby making Adrian a more reliable and scalable solution.

For Phase 2 of Adrian i.e., the communication from the collaboration platform to the SIEM platform can be completed through a flexible, modular interface. This communication is novel and has not been developed previously. The developed application would be the interface that connects the collaboration platform to the organization’s SIEM platform. Figure 3 is the high-level architecture of the response network.

The modular interface, as described in Figure 3, could be an application that would adapt to different communication platforms and SIEM systems. The application could consist of webhooks, APIs or custom plugins based on the requirement of the organization.

The above technical architecture of Adrian shows that the solution is modular, scalable, and designed to meet the evolving needs of cybersecurity operations. The solution consists of relevant and useful features such as alert customization and alert categorization. It also consists of new features such as generating and visualizing alert statistics and enabling a bidirectional communication.

In Adrian’s design principles, we emphasized on reliability, efficiency, and

scalability, which persuaded our choices of communication models and the specific use of Rest APIs. We decided that our model should perform asynchronous communication which would be facilitated by RabbitMQ, a message broker that is used for a publish/subscribe scenario. Using this approach, the SIEM platform continue its alert processing and generation without waiting for acknowledgements from the collaboration platform. This non-blocking feature of asynchronous communication is vital during high alert volume periods. By incorporating this feature, the model ensures that alert management is not hindered by network latency or downtimes of the collaboration platform. Moreover, the producer-consumer (a.k.a. publisher-subscriber) mechanism implemented is effective in scenarios where alerts need to be distributed across various channels. This model also supports decoupling of alerts produced from consumers, thereby enhancing the system’s modularity and scalability.

For integrating the SIEM platform (Wazuh) with the collaboration platform (Slack), we chose Rest APIs due to their ubiquity and ease of use. The APIs eased a straightforward communication that can be easily managed and scaled. The stateless feature of Rest APIs supports scalable environments by simplifying server design and facilitating easier adjustments. The stateless feature is where each request contains all the necessary data to be understood independently.

These design choices were crucial for ensuring that Adrian remains robust and efficient. It should be capable of handling real-time data and adapt to the various organizational environments.

The primary objectives of this case study include the following:

· To demonstrate the capabilities of Adrian by implanting its core principles. The demonstration would include middleware usage for reliability, alert customization, alert categorization, and bidirectional communication for interactive alert management.

· To reiterate the practical benefits of integrating SIEM platforms with collaboration platforms for improved alert response times, enhanced team collaboration and increased operational efficiency.

· To showcase the adaptability of Adrian across various tools and platforms, thereby emphasizing its potential for broader application in the cybersecurity field.

Adrian was implemented in two phases. The first phase was a communication channel from Wazuh to Slack and the second phase was a communication channel from Slack to Wazuh.

For completing both the phases of Adrian, Python was the programming language we used. The reason for choosing Python was because of the several libraries that it consists of that helped in connecting various interfaces. The following are the libraries used:

· pika—used for connecting any interface with RabbitMQ.

· slacksdk—used for connecting any interface with Slack.

· matplotlib.pyplot—used for generating the alert statistics bar graph.

These libraries help in a seamless integration between Wazuh and Slack and also provide a bidirectional communication.

For connecting Wazuh to Slack to send the alerts and alert statistics, this case study of Adrian uses RabbitMQ as its message broker.

RabbitMQ is a proven reliable broker queue that is used by organizations such as Netflix and Salesforce. It decouples the processes (in this case, Slack and Wazuh), increases the reliability and scability of the solution [5] . RabbitMQ provides reliability by providing an asynchronous communication. In addition to its basic functionalities, it also has an acknowledgement feature where it would send an acknowledgement to the appropriate platform after a message has been put in its queue or when a message is being sent from its queue. It provides various routing mechanisms through its concept of Exchange. Adrian uses Direct Exchange which helps in separating alerts and alerts statistics.

For this project, we have chosen Wazuh and Slack. The reason for choosing Wazuh was because it is a popular open-source threat prevention, detection, and response platform [6] . It is primarily used for data collection, indexing, aggregation, and data analysis from various sources including intrusion detection, suspicious behaviors, and threat detection. Some of the core functionalities of Wazuh include log data analysis, intrusion detection, incident response, etc.

We used Slack because of the channel feature that is available in the platform. The Slack channels have been made public intentionally so that anyone, with the required permissions, can subscribe to the alert channels or the alert statistics channel to view the information. However, the solution can be expanded to include other platforms such as Teams or CatchUp.

For developing the Slack application that would connect to Wazuh through an interactive channel, we used Flask and ngrok [7] .

Flask is a microweb framework coded in Python that does not require any specific libraries or tools. It supports use cases for form validation, upload handling, and several common framework related tools. It is lightweight, modular, scalable, flexible making it an optimal solution for creating web applications and hosting web services.

Ngrok is a cross-platform application that creates a security tunnel for data from the internet to the local server on our local machines. It permits exposure of web server to the internet without much effort making it particularly useful for web development, allowing developers to share their local sites without the need to deploy those sites to a public server, testing applications, etc [7] .

Phase 1: Wazuh to Slack Communication

The queueing mechanism chosen for Adrian is RabbitMQ [5] . RabbitMQ is an open-source message broker that is proven to be useful in a producer-consumer scenario. Using the RabbitMQ solution and decoupling Wazuh and Slack, Adrian would provide an asynchronous communication. The detailed diagram of Phase 1 of Adrian is shown in Figure 4.

For categorization of the alerts based on its alerts level, Adrian categorizes the alerts based on its severity level and inserting them into low-alerts-queue, medium-alerts-queue, and high-alerts-queue respectively in RabbitMQ. Alerts with severity level < 5 are put into the low-alert-queue. Alerts with severity level ≥ 5 and level < 7 are put into the medium-alerts-queue. Alerts with severity level ≥ 7 are put into high-alerts-queue [8] .

The segregation is performed using Exchanges in RabbitMQ. Exchanges (aka Topics in other broker queues) assist in connecting the producer to different queues using a routing key [9] . Routing Key is specified by the producer while transmitting the message to RabbitMQ. There are different types of Exchanges; Adrian uses Direct Exchange [10] . After receiving the message and the routing key the direct exchange, based on the configured routing key, inserts the message in the appropriate queue [11] . The detailed diagram is depicted in Figure 5.

Alert categorization is performed on the consumer side as well. To avoid cluttering of a single Slack channel, Adrian segregates the messages into three different slack channels for the alerts [11] . The messages from the low-alerts-queue are published to the low-alerts-slack-channel. A similar concept is followed for the medium and high alerts. Apart from the three channels in Slack, Adrian uses a fourth channel to publish the alert statistics [12] [13] . This helps in separating

the technical specifics and the statistical information of the alerts [14] . The detailed diagram is depicted in Figure 6.

Figure 7 shows the queues that are configured in RabbitMQ. The queues are wazuh-alerts-high, wazuh-alerts-medium, and wazuh-alerts-low [15] .

Figure 8 shows the binding of the routing keys and the queues through exchange. Adrian uses Direct Exchange. The routing key for wazuh-alerts-high queue is wazuh-alerts-high. The routing key for wazuh-alerts-low queue is wazuh-alerts-low. The routing key for wazuh-alerts-medium queue is wazuh-alerts-medium.

Phase 2: Slack to Wazuh Communication

For phase 2 of Adrian i.e., connecting Slack with Wazuh. The Slack application provides an interactive Slack channel that would provide various management related activities to be performed on Wazuh. Each button corresponds to an activity that can be obtained from Wazuh [14] . Figure 9 is the block diagram provides a detailed visual representation of the response network architecture [16] .

An important aspect of Adrian’s innovative approach is its alignment with the FCAPS model [16] , a network management framework that was developed by International Organization for Standardization (ISO). By categorizing network management tasks into five domains, FCAPS provides a comprehensive blueprint for network operations. This model is adeptly used by Adrian to enhance SIEM functionality and team responsiveness. The full form and the details of the FCAPS model is:

· Fault Management—helps in identifying and correcting any malfunctions.

· Configuration Management—helps in monitoring the system configurations.

· Accounting Management—helps in managing the users, roles, etc.

· Performance Management—helps in monitoring system performance.

· Security Management—helps in protecting the system by checking the security rules.

For each of the components of the FCAPS model [16] , we have chosen two APIs. The APIs chosen are as follows. This is a comprehensive list and can be expanded to include more API functionalities for each category.

1) Fault Management

· Fault Status—returns the faults that the agent has been allocated. It includes the source, details, and status of the fault. It also provides the first detected timestamp and the last updated timestamp of the fault.

· Agent Upgrade Status—returns the status of an upgraded agent, if any. If any agent was upgraded, it provides the status of the upgrade and details on which component of the agent was upgraded.

2) Configuration Management

· List rules—returns the top 10 rules that Wazuh uses for identifying malicious activities. There are over 6500 rules that are configured. Hence, I chose the top 10. This number is configurable and can be modified based on the requirements.

· List decoders—returns the top 10 decoder rules and configurations that Wazuh uses for parsing and decoding the data that it receives from various sources. There are approximately 500 decoder rules, I have chosen the top 10. This field is configurable and can be modified based on the requirements.

3) Accounting Management

· List users—returns the users present in the system, along with their roles and username.

· List roles—returns the different roles configured in the system along with the name of the role and the policies that have been applied to it.

4) Performance Management

· SCA scan results—returns the SCA scan results of Wazuh. SCA stands for Security Configuration Assessment. It runs the scan for CIS benchmark for Ubuntu and provides the number of checks that passed, failed and were invalid. It also provides the start time and end time of the scan.

· Manager logs—returns the Wazuh manager logs that include a description, level, and timestamp of the logs.

5) Security Management

· Security policies—list the top 10 security policies of Wazuh. It lists the name and details of the policy, the resources, and users where the policy is implemented. There are over 5000 security policies. I have chosen the top 10 policies.

· MITRE References—lists the top 10 references that are used for identifying MITRE ATT&CK by Wazuh. The results include the MITRE ID, source, description, and the reference link for each attack pattern. There are approximately 650 references. I have chosen the top 10 policies. This field is configurable and can be modified based on the requirements.

The API and the formatting of the API responses is included in the Flask app. The Flask app creates an interactive Slack channel that initially gives the user five options to choose from [17] . The options include the high-level configurations of FCAPS. After the user selects one of the five options, the Flask app provides two more options in the submenu. The options in the submenu include the APIs that were previously mentioned. After obtaining a choice, the app connects to Wazuh and fetches its response [18] . The response is formatted to include only the relevant details and in a more organized format and then published to the Slack channel [19] . The Flask app flowchart is depicted in Figure 10. Figure 11 includes all the details of the APIs used in the FCAPS model of Adrian [20] .

Phase 1 of Adrian covered the communication from Wazuh to Slack. While Figure 12 is the screenshot of the original alert that was before Adrian cleaned up the alert, Figure 13 shows the alert that Adrian customized to only include the relevant fields and categorized it as a low alert based on the severity level.

Figure 14 and Figure 15 present examples of medium and high alert generated in Wazuh and sent through Adrian to the corresponding Slack channels. These screenshots illustrate Adrian’s capability for alert prioritization and categorization.

Figure 16 and Figure 17 is an illustration of Adrian sending the alert statistics

to the teams in a timespan of 24 hours. Figure 16 was sent on 3rd March and Figure 17 was sent on 4th March. The figures indicate that there was a dip in the number of low alerts from 50 to 30. There is a marginal dip in the medium alerts as well. However, the number of high alerts has increased which could be a cause of concern for the team. In such instances, the team would have to login to investigate the issue further.

Figure 18 shows the initial message of the Flask app in the slack channel. As per the FCAPS model, it displays the high-level menu for the user to select the option.

The submenu for each option is shown in Figure 19. The flowchart represents all the submenu options that the user can choose from based on the chosen model. The images in the flowchart represent the options displayed to the user from the submenu.

Figure 20 represents the Fault Status and Agent Upgrade Status. Figure 20 (top image) provides the details of the fault that the agent has been allocated. Figure 20 (bottom image) represents the agents that were upgraded. In cases where there is no agent to be upgraded, it displays the message depicted in the diagram.

Figure 21 represents the Rules and Decoders. The figure show only one rule and one decoder, but Wazuh consists of over 6500 rules and approximately 600 decoders. Figure 21 (top image) shows the required details on each rule including the name and directory of the rule. Figure 21 (bottom image) shows the details of the decoder including the name and the pattern that is used by Wazuh for parsing and decoding data.

Figure 22 represents the Users and Roles. Figure 22 (top image) provides all the users and the roles they are mapped to. Figure 22 (bottom image) provides all the roles and the policies that each role is mapped to. Together, users can map the users to their policies.

Figure 23 represents the SCA Scan Results and Manager Logs. Figure 23 (top image) provides the total number of checks that have passed, failed, and considered invalid. Since the host machine is an Ubuntu machine, SCA scan was performed for CIS Benchmarks for Ubuntu. Figure 23 (bottom image) provides the latest Wazuh manager logs.

Figure 24 represents the Security Policies and MITRE References. Figure 24 (top image) provides all the details on the security policies that are configured in Wazuh. Figure 24 (bottom image) represents one of the MITRE references that Wazuh uses for identifying MITRE ATT&CK in the host machine. The image represents a limited set of security policies and MITRE references, but there are 250+ security policies and 100+ MITRE references that are configured in Wazuh.

This case study of Adrian clearly demonstrates the system’s innovative approach to improving SIEM platforms’ alert management and response mechanisms. By streamlining the flow of information between Wazuh and Slack, Adrian not only enhances the real-time alert distribution but also introduces a higher level of alert customization, alert categorization, and operational responsiveness.