# A Methodological Approach to Securing Cyber-Physical Systems for Critical Infrastructures
## 3 Open (Sub-)Challenges
### Mitigation Challenges  
**Automatic Firewall Reconfiguration.** Firewall filtering operates by evaluating each incoming packet against a predefined set of rules. As a result, the packet is either permitted to pass through or blocked. The effectiveness of this filtering is significantly influenced by the average number of rules that each packet must navigate. When there is a significant surge of incoming traffic, such as during a denial of service (DoS) attack or a temporary spike in traffic, the packet processing delay may increase substantially. This situation can lead to packet loss as well.  
One potential remedy might involve redistributing rules across multiple cascaded firewalls, which could help maintain a high rate of packet processing, even when the firewall is under attack. A promising strategy for this has been detailed in reference [46]. However, it utilizes the same abstract model of stateless firewalls found in several foundational studies [47; 61], indicating that it cannot be directly applied as is; there remains a need to bridge the gap between the abstract, stateless models and actual stateful firewalls used in practice.  
In particular, IPTABLES [48], which is one of the most recognized and widely used firewall technologies, is also open source. This makes it a primary candidate to address the aforementioned gap.  
The key differences between the _abstract firewall model_ in references [46; 47; 61] and IPTABLES that we must carefully consider to achieve our objective are as follows:  
1. The abstract firewall model consists of a singular list of rules, which are sequentially examined against certain fields of the packet header until a match is found with a rule that specifies an action of _ACCEPT_ or _DROP_. In contrast, IPTABLES evaluates packets against a more complex framework of rule lists organized into _chains_ and _tables_[48], following a specific pathway deeply outlined in [62], where the _Packet Flow in Netfilter and Generale Networking_'s well-known diagram depicts all paths foreseen for a packet entering an IPTABLES firewall. In general, the chosen path depends on the source and destination IP addresses: whether the packet originates from outside or from the firewall itself, and whether the recipient is external or the firewall itself. On the other hand, the mitigation challenge proposed here shall only deal with packets originating from outside the firewall, and whose recipient is external. For this reason, Figure 2 only shows the packets' path of interest for us through the _packet processing diagram_ (PPD), a subset of that which is depicted in [62]. In particular, each element of the flow followed by a packet entering an IPTABLES firewall is a sequence of rules belonging to the _chain_ whose name is prefixed by _C:_ and contained in the table listed in the name that is prefixed by \(T\). The two elements outlined by the red line highlight the sequence of rules which will be addressed by the mitigation challenge proposed here.
2. The _abstract firewall model_ operates on the assumption that only the packet header fields are compared to each rule, meaning that it acts as a _stateless firewall_. On the other hand, IPTABLES supports more advanced checks, such as determining whether the packet is part of an established connection, and can enact actions that alter the _netfilter_ status that has already been assessed.  
The challenge lies in adapting the algorithm from reference [46] for IPTABLES while considering the unique characteristics and features outlined above.