## 4 Proposed Framework
### Layer 5--Data Generation and Analysis  
In the fifth and final layer of the proposed architecture, data analysis and alert activities are concentrated, including performance evaluation of detections made by the machine learning module, adjustment of detection thresholds (acceptable error threshold), and SOC action in case of alerts. For the performance of these activities, the dataframes generated in the previous layer and Kibana are important tools to aid the SOC team. According to the flowcharts shown in Figures 2-4, the actions performed in layer 5 are executed during the testing and production phases of the framework. During the test phase, the SOC team does not act in the event of alerts and any anomalies detected. Thus, the main objective of framework operation in this phase is to evaluate the performance of the IDS before its entry into production. After indexing the datasets and detection results in Elasticsearch done in layer 3, you can analyze and inspect this data through Kibana. Kibana has native integration with Elasticsearch and provides a graphical interface for analyzing both datasets and anomaly indices generated by the IDS [33]. Still in the test phase, the performance of the IDS can be evaluated according to the analysis of the alerts generated by the machine learning module, in addition to the detection metrics calculated through the Equations (2)-(7). Depending on the performance of the machine learning module, it is possible to adjust the acceptable error threshold for other confidence intervals in order to improve performance in detecting anomalies. As the distribution of prediction errors resembles a normal distribution, most of the samples are concentrated in the center of the curve. In this way, the acceptable error threshold obtained is reduced as the confidence interval used is reduced, and the lower the acceptable error threshold, the more sensitive the model becomes to detect anomalies. Given the above, the detection sensitivity of the IDS can be adjusted by varying the confidence interval and the corresponding error threshold. Even so, if the performance of the IDS is still unsatisfactory after adjusting the acceptable error threshold, the test phase can be closed and the framework operation goes back to the training phase to improve the machine learning module. In the operation of the framework in the production phase, the activity of the SOC team is inserted in layer 5 of the flowchart described in Figure 4. Therefore, the detection of anomalies and alerts produced by the IDS causes the SOC team to act to analyze the event. The preliminary analysis of alerts and anomalies detected by the IDS is performed through the Kibana interface, which allows system calls windows with an anomalous score to be identified. The anomaly detected at a given time must also be investigated using other security and environment monitoring tools, with a view to correlating the alert with other security events. As a HIDS usually cannot provide complete protection to systems, in today's industry, a HIDS is usually integrated with other security mechanisms such as vulnerability analysis and management and incident response [13]. If the IDS performance is unsatisfactory, it is possible that the acceptable error threshold is adjusted to other confidence intervals, changing the IDS detection sensitivity. However, if the performance of the IDS is not adequate, the framework can go back to operating in the training phase to improve the machine learning model. After analyzing and investigating an anomaly, the SOC team will be able to act with measures to contain the propagation of a possible attack through actions such as: restricting application communication to limited contexts (sandboxing), verifying changes in the configuration of the running application (e.g., recent deploy of a new version), contacting the team responsible for developing the application, or even interrupting the execution of the application container that generated the alert.