## 4 Proposed Framework
In addition to the trained machine learning model that can be used in the test and production phases of the framework, another by-product of the training phase is the datasets stored in Elasticsearch in layer 3, after treatment and filtering performed in layer 2. After training the machine learning model, in the testing phase of the framework (Figure 3), different datasets from the one used in the training phase are used to evaluate the performance of the trained model in anomaly detection. These datasets should contain benign or malicious behaviors of the same containerized application. Its construction should ensure the systematic capture of system calls in behaviors identified as normal and/or anomalous in the usage of the application. In this operational phase, the processing of the data begins at layer 1 and extends to the last layer of the framework. Differently from the training phase, in layer 4, the trained machine learning model is used solely to detect anomalies in the test datasets. In layer 4, performance metrics of the model can be  
Figure 4: Flowchart describing how the framework works during the production phase. visualized, as detailed in Section 5 of this work. The detection results of the model are also stored in Elasticsearch and can be queried and analyzed later on. In layer 5, it is possible to analyze the detection results of the model and the alerts generated in case of detected anomalies through a web interface of Kibana. If necessary, depending on the performance of the model, the choice of a new value of threshold for anomaly detection by the model can be adjusted. If the performance of the model in anomaly detection is unsatisfactory, the operation of the framework can return to the training phase for the construction of a new model of machine learning. It is worth noting that in both the training and testing phases of the framework, once the training and testing datasets are already indexed in Elasticsearch, the processing of layers 1 and 2 does not need to be repeated for each training or testing of a new model with indexed datasets. In this scenario, the execution of the processing flow can start at layer 3. During the production phase of the framework (Figure 4) the main objective is to detect anomalies in the behavior of the target application using the machine learning model trained and tested in the phases of previous operations. The capture of system calls occurs in layer 1 at application runtime and data processing follows the processing and indexing flow through layers 2 and 3, respectively. The indexing of system calls in Elasticsearch is done on indexes that are created in a fixed and adjustable time interval. At each defined time interval, a new index is created with a set of system calls executed in that period. Thus, the time window represented by an index introduces a delay between the occurrence of the system call and the analysis of anomalies by the model, being an important factor to be observed in the configuration of the framework. The frequency of creation of new indexes in Elasticsearch can be every day, hour or even smaller fractions of time, according to the detection time tolerance accepted by the IDS. After creating an index, it will be used as input for anomaly analysis by the machine learning model in layer 4. The indexes are read individually and sequentially, according to the creation time of each index. At layer 5, the SOC team will be able to track detection results by the IDS in a dashboard created in Kibana. In the event of an eventual anomaly, the SOC will be able to carry out a more in-depth analysis of the event, correlating it with other sources of information such as a SIEM, for example. In addition, the detection threshold can be adjusted to allow greater or lesser sensitivity in the detection of anomalies by the IDS. Even so, if the performance of the IDS is unsatisfactory, the framework operation may return to the previous phases to improve the machine learning model or make adjustments to other components.