## 4 Proposed Framework  
The proposed framework comprises a set of tools and processes integrated into a reference architecture for implementing an Intrusion Detection System based on Host in a cluster of container orchestration. To implement the framework, the GNS3 network emulator software was used in version 2.2.29. A topology of a corporate network environment \begin{table}
\begin{tabular}{c c c} \hline \hline
**Related Work** & **Key Contributions** & **Limitations** \\ \hline \multirow{7}{*}{This paper} & In comparison to existing works in the area, & \\  & the proposed framework enhances the IDS & \\  & implementation in container platforms with & \\  & regards to a distributed and scalable & \\  & architecture built using open-source tools. & \\  & The layered architecture is feasible to changes & \\  & and integration with other security systems. & \\  & Additionally, detailed information on how the & \\  & implementation can be done in conjunction & \\  & with the related configuration and codes are & \\  & made available through a public repository & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: _Cont._was then built containing a Kubernetes container orchestration cluster at version 1.18, vlans, a firewall, routers and switches, according to the Figure 1.  
A possible intrusion or attack on a containerized system can be identified by detecting anomalies in the system calls invoked by the containers to the kernel of the Operating System of the host of the container platform. Thus, the framework aims to improve Intrusion Detection Systems on container platforms and was designed with the aim of contributing to the resolution of problems exposed by related works such as: the computational overhead caused in container platforms across HIDS, the absence of current datasets, and the need for improvements in anomaly detection in system calls. Figures 2-4 show respectively the flowcharts that describe the operation of framework in three stages of operation: training (Figure 2), testing (Figure 3), and production (Figure 4), in five processing layers: layer 1 (data capture), layer 2 (feature engineering), tier 3 (indexing and searching), tier 4 (anomaly detection), and tier 5 (alert generation and data analysis). Thus, the operation of the IDS begins in the training phase, followed by the test phase and, finally, the production phase. Eventually, the IDS operation cycle may be reset in view of the need to train the model with new data or parameter adjustments. Figure 1: Network topology implemented in the GNS3 software. Figure 3: Flowchart describing how the framework works during the testing phase. Figure 2: Flowchart describing how the framework works during the training phase. Due to the fact that the machine learning model used performs batch learning, its learning is carried out offline [35]. That is, the model trained and in use in the production phase is used only for detection and does not learn simultaneously with the data being analyzed. Although training a new model has to be done offline, this requirement does not prevent the IDS from working while new models are being trained or tested. That way, after training and testing a model with new parameters or datasets, it can be deployed for production operation to replace another model in use. In the framework training phase (Figure 2), the main objective is to train a machine learning model through benign behaviors of a containerized application. The model trained with normal behaviors will be able to identify anomalies through the discrepancy between the system calls invoked in normal use and malicious use of the system. To do so, it is necessary to ensure that no attack or malicious activity occurs while capturing the system calls that make up the dataset with benign behavior. Data processing in this phase starts at layer 1 of the framework and proceeds through the intermediate layers to layer 4, where the model is trained and terminated when the model reaches satisfactory levels of detection using the data of training.