## 6 Method for Reducing the False Alarm Rate  
Given the results from our experiments, it seems that manual adjustment of the ruleset is inevitable if one wants to fine-tune the optimal point of operation in the operational environment. However, this can be a costly and time-consuming process that relies on experts and for which there is scarce guidance. In this section, we provide a method implemented with InspectorLog and Snort's rules to determine which signatures to deactivate from a baseline ruleset to minimize _FP_ until a target precision is achieved for a given operational \begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline  & \multicolumn{3}{c}{**Union**} & \multicolumn{3}{c}{**Voting Majority**} & \multicolumn{3}{c}{**Intersection**} \\ \cline{2-9}  & **low** & **med.** & **max.** & **low** & **med.** & **max.** & **low** & **med.** & **max.** \\ \hline \#Alerts & 3952 & 96,927 & 102,941 & 1625 & 14,317 & 14,452 & 52 & 1308 & 1312 \\ \hline \#FP & 1721 & 94,661 & 100,675 & 234 & 12,693 & 12,828 & 0 & 0 & 0 \\ \hline \#TP & 2231 & 2266 & 2266 & 1391 & 1624 & 1624 & 52 & 1308 & 1312 \\ \hline Precision & 0.565 & 0.023 & 0.022 & 0.856 & 0.113 & 0.112 & 1.000 & 1.000 & 1.000 \\ \hline \#alerts/day & 131.7 & 3230.9 & 3431.4 & 54.2 & 477.2 & 481.7 & 1.7 & 43.6 & 43.7 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Precision and alarm generation rate with a cooperative decision. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline  & & **\# Alerts** & **\#TP** & **\#FP** & **Precision** & **\#Alerts/Day** \\ \hline \multirow{3}{*}{Inspectorlog} & low & 57 & 57 & 0 & 1.000 & 1.9 \\ \cline{2-6}  & med. & 85,641 & 1356 & 84,285 & 0.016 & 2854.7 \\ \cline{2-6}  & max. & 91,791 & 1356 & 90,435 & 0.015 & 3059.7 \\ \hline \multirow{3}{*}{ModSecurity} & low & 2299 & 868 & 1431 & 0.378 & 76.6 \\ \cline{2-6}  & med. & 23,820 & 1714 & 22,106 & 0.072 & 794.0 \\ \hline Nemesida & Default & 2551 & 2127 & 424 & 0.834 & 85.0 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Alerts generated, FP, TP and precision with _Inv_es trace. context. We believe that our tuning process can serve as guidance to operators in the context of web attacks. A prerequisite is to collect enough volume of events from the operational environment [37]. The size of the collected dataset will have implications in the time spent in the tuning process since we will need to manually review some of the alerts generated. In our case, we used the _Inve_s trace. We assume that attacks are scarce in real-life traffic such as this trace (e.g., \(<\)0.1%). We start our procedure by deciding the baseline or initial ruleset that represents the upper bound of the detection rate that we are willing to accept. In our case, and given the previous results, we chose the medium sensitivity configuration med. (i.e., all rules but those marked as DELETED) since it provided a nearly maximum detection capability and generated slightly less FP than max. This configuration includes 3198 detection rules. The first step in our procedure is to run InspectoLog with this initial ruleset, keeping track of the Signature ID (SID) and URI in each alarm. This lets us build a histogram of rules (SID) sorted from larger to smaller by the frequency of the alarms generated such as the one shown in Figure 4. In our case, only 35 out of 3198 rules produced alarms, the top 10 are listed in Table 7. Observe that the top 5 rules generated more than 500 alarms each, or that the top 14 rules generated at least 50 alarms each (see thresholds in Figure 4). Then, we follow the steps in Algorithm 1 whose input is the previous histogram, the log of alarms generated, and the target precision we want to achieve \(\Phi\). The later will be used to narrow down the number of rules handled by the algorithm. The choice of \(\Phi\) is up to the expert and will determine the manual workload of the process. High values of \(\Phi\) (close to 1) will lead to a review of almost all the rules that trigger alarms in order to avoid any FP.