## 3 Materials and Methods
### Low-Level XAI Pipeline Components  
We will now detail the fundamental components of our XAI pipeline, as illustrated in Figure 1 and in the Algorithm 1. **Loading Intrusion Database:** The first step in our pipeline is to import data from the database. We employ three extensively used network intrusion detection datasets: RoEduNet-SIMARGL2021 [35], CICIDS-2017 [33], and NSL-KDD [34]. These datasets are critical for our analyses and the training of our models. **Choosing Feature Columns:** The second component in our framework is the selection of important features from the database. Such feature extraction is essential for building AI models for intrusion detection tasks. The feature extraction process usually impacts AI models. We followed prior works [33; 35] for extracting the basic set of features for each network intrusion dataset using information gain [36] and K-best [35] methods. As an important note, for RoEduNet-SIMARGL2021 and CICIDS-2017, the experiments for choosing a basic set of features using K-best and information gain were already performed in their respective works. We also performed K-best and information gain for the NSL-KDD dataset. Furthermore, in this work, we perform feature extraction using XAI methods (particularly SHAP) for all three datasets considered in our work (as explained later in this section). In particular, from the basic set of features (explained above), we extract the top intrusion features for different AI models and intrusion types. Based on this feature selection, we also select the best features among all AI models (as will be shown in our evaluation). We also emphasize that we take advantage of our XAI-based feature selection to generate a new set of features (which we use to compare our approach against baselines, as will be shown in Section 4.4), thus creating a feedback loop in the framework to update the basic features after the whole process can be exploited in our framework when applied to real-world IDSs. **Feature Normalization:** To prevent variations in scales among different traffic features, we apply a standard feature normalization step (min-max feature scaling) to all columns in our datasets (where we apply feature scaling for each column, one column at a time, to address inconsistencies across different features' scales). This process ensures that all features are brought to a consistent numerical scale, thereby avoiding any discrepancies in magnitude across the dataset. Such a process has been applied in several related prior works [10; 53; 54; 55]. In terms of the nature of the datasets, all of them use tabular data. The CICIDS-2017 dataset only has features with numerical values for continuous, discrete, and categorical data. Therefore, we applied normalization to all features used. The RoEduNet-SIMARGL2021 dataset has features with numerical values for discrete and categorical data and three categorical features (i.e., PROTOCOL_MAP, IPV4_DST_ADDR,and IPV4_SRC_ADDR). However, the feature extractor module for a basic set of features (explained earlier) did not generate two of these three features, and thus, we did not use the IP addresses for any of the experiments. On the other hand, PROTOCOL_MAP has an identical counterpart feature column called PROTOCOL but with the correspondent numeric values that represent each protocol (i.e., TCP is 6, ICMP is 1, gre is 47, ipv6-ICMP is 58, skip is 57, and UDP is 17). For the NSL-KDD dataset, we work with 41 features, of which 4 are categorical. The protocol_type feature has 3 categories (i.e., Protocol_type_tcp, Protocol_type_icmp, and Protocol_type_udp). The service feature is quite diverse, with 70 categories, including service_IRC and service_aol. Flag comes with 11 categories, with examples being flag_S0 and flag_SH. Lastly, the label categorizes network behavior into 23 types, which are further classified into 5 broader categories, which are Normal, DoS, Probe, R2L, and U2R. We discuss feature normalization's effect in Section 4.