The TCP/IP based rewall is a notorious non-evolvable system. Changes to the rewall often result in unforeseen side e ects, resulting in the unavailability of network resources. The root cause of these issues lies in the order sensitivity of the rule base. It is not only essential to de ne the correct rule. The rule must be placed at the right location in the rule base. As the rule base becomes more extensive, the problem increases. According to Normalized Systems, this is a Combinatorial E ect. This paper studies the ontology of a rule base and its implementation in an actual rewall. Based on this study, we explain why existing rewalls do not prevent evolvability issues. A new ontological model and implementation are proposed, using Normalized Systems, which drastically increases the rewall rule base's evolvability.
Evolvability Normalized Systems Firewall
The TCP/IP based rewall has been and will continue to be an essential network
security component in protecting network-connected resources from unwanted
tra c. The increasing size of corporate networks and the need for connectivity
have resulted in rewall rule bases increasing considerably. Large rule bases
have a nasty side e ect. It becomes increasingly di cult to add the right rule at
the correct location in the rewall. Anomalies start appearing in the rule base,
resulting in the erosion of the rewall's security policy or incorrect functioning.
Making changes to the rewall rule base becomes more complex as the size of the
system grows. An observation shared by Forrester [
Normalized Systems theory (NS) [
The order sensitivity plays a vital role in the evolvability issues of the rule base. The necessary condition to remove the order sensitivity is known, being non-overlapping or disjoint rules. However, rewall rule bases don't enforce that condition, leaving the door open for miscon guration.
Issues with evolvability of the rewall rule base induce business risks. The rst is the risk of technical communication paths not being available to execute business activities properly. The second is that aws in the rule base may result in security risks, making the business vulnerable for malicious hacks resulting in business activities' impediment.
The topic presented in this paper is technical. Using domain-speci c
knowledge and instruments of Enterprise Engineering, such as DEMO [
Design Science [
This section starts by explaining the basic concepts of the rewall and continues with the introduction of NS. 2.1
Firewall basics: An IP4 TCP/IP based rewall, located in the network path
between resources, can lter tra c between the resources, based on the Layer
3 (IP address) and Layer 4 (TCP/UDP ports) properties of those resources
[
A rewall rule base is a collection of order-sensitive rules. The rewall starts at the top of the rule base until it encounters the rst rule that matches the tra c. In a rewall rule, <Source IP>, <Destination IP>, <Destination Port> and <Protocol> can be one value or a range of values. In the remainder of this paper, protocol and port are grouped together in service (for example, TCP port 58 or UDP port 58 are 2 di erent services).
Firewall group objects: Rules containing IP addresses for source/destination and port numbers, are di cult to interpret by humans. Modern rewalls allow the usage of rewall objects, called groups, to give a logical name to a source, a destination, or a port, which is more human-friendly. Groups are populated with IP addresses or ports and can be nested. The groups are used in the de nition of the rules. Using groups should improve the manageability of the rewall. 2.2
Normalized Systems [
The Normalized Systems Theory takes the concept of system theoretic stability from the domain of classic engineering to determine the necessary conditions a modular structure of a system must adhere to in order for the system to exhibit stability under change. Stability is de ned as Bounded Input equals Bounded Output (BIBO). Transferring this concept to software design, one can consider bounded input as a certain amount of functional changes to the software and the bounded output as the number of e ective software changes. If the amount of e ective software changes is not only proportional to the amount of functional changes but also the size of the existing software system, then NS states that the system exhibits a CE and is considered unstable under change.
Normalized Systems Theory proves that, in order to eliminate CE, the software system must have a certain modular structure, were each module respects four design rules. Those rules are: { Separation of Concern (SoC): a module should only address one concern or change driver. { Separation of State (SoS): a state should separate the use of a module by another module during its operation. { Action Version Transparency (AVT): a module, performing an action should be changeable without impacting modules calling this action. { Data Version Transparency (DVT): a module performing a certain action on a data structure, should be able to continue doing this action, even is the data structures has undergone change (add/remove attributes).
NS can be used to study evolvability in any system, which can be seen as a
modular system and derive design criteria for the evolvability of such a system
[
This section investigates the root cause of evolvability issues in rewall rule bases, being relationships between rules. We will create an ontological model of a rewall rule base by analyzing the DEMO FACT model that is associated with the \create rewall rule" transaction. We continue by reverse-engineering the relational model used in a rewall rule base, based on a rule base's export. We conclude this section by investigating the rule relationships, rewall ontology model, and rewall implementation model with the NS principles. 3.1
In [
A fully consistent rule base should only contain disjoint rules. In that case, the
order of the rules in the rule base is of no importance, and the anomalies
described above will not occur [
The analysis of a rewall rule base's ontology will be done with a DEMO FACT
model [
In the scope of a security department that manages the rewalls, the \create rewall rule" transaction is considered an ontological transaction. During the request phase, information must be provided to the executor, corresponding with the ltering objective: source, destination, service, and action. The ontology of a rule base can be expressed in a DEMO FACT model, as shown in Figure 3. For simplicity reasons, details about value types and the transactions related to the coming about the facts and products are omitted. Note that a host has the dual notion of a source and destination. There are multiple ways to identify a source or a destination, depending on whether the network resource(s) are identi ed by their IP address(es) (IPRESOURCE, IPRESOURCEGROUP) or by their logical name(s) (HOST, HOSTGROUP). SOURCE and DESTINATION are a generalization of those di erent resource identi cations. A similar reasoning holds for SERVICERESOURCE and SERVICERESOURCEGROUP. A SERVICERESOURCE is the aggregation/cartesian product of PROTOCOL and PORTRANGE. A RULE is the aggregation/cartesian product of the di erent entity types making up a rule. 3.3
Firewall vendors do not share or publish the rewall's internal data model explicitly. We will reverse-engineer the implemented data model based on a rewall con guration export.
Firewall export Two exports were made from rewalls inside the Engie network. One rewall is used to protect data center resources in Belgium, the other rewall is used to interconnect an Azian branch of the Tractebel Engie business entity to the Tractebel network. Both rewalls are from PaloAlto. The rewall con guration contains the following information: the Service objects, ServiceGroup objects, Address objects, AddressGroup objects, and Rule objects. Service objects The Services objects export contains a data de nition header. The relevant elds of this header are: Name (reference name), Protocol (TCP or UDP), and Destination Port (one or more ports or port ranges). Analysing the di erent objects, the following observations are made: { The naming of the Services: No formal naming convention. The name explains the usage and meaning of the service or repeats the service content. ServiceGroup objects The ServicesGroup objects export contains a data definition header. The relevant elds of this header are: Name (reference name) and Services (one or more Service objects) Analysing the di erent objects, the following observations are made: { The naming of the ServiceGroups: No formal naming convention. The name includes the usage of a grouping of Service objects. { Uniqueness/overlap: The ServiceGroups overlap { As ServiceGroups are an aggregation of services, ServiceGroup and Service objects are by design overlapping.
Address objects The Address objects export contains a data de nition header. The relevant elds of this header are: Name (reference name), Type (a Fully Quali ed Domain Name (= DNS resolvable name) or IP Netmask (/32 for a single IP or a /x for a range of IP addresses) or an IP range (from a.b.c.d to a.b.c.f)) and Address (the address according to one of the three type). Analysing the di erent objects, the following observations are made: { Naming: No formal naming convention. The name includes the IP Mask, the FQDN, the hostname (di erent from FQDN), or a logical name for an IP range. { Uniqueness/overlap: Multiple Address objects were found containing the same information of existing Address objects. The Address objects are not unique.
AddressGroup objects The AddressGroup objects export contains a data de nition header. The relevant elds of this header are: Name (reference name), Address (an Address Object). Analysing the di erent objects, the following observations are made: { Naming: No formal naming convention. The name includes the function of the AdressGroup. { Uniqueness/overlap: AddressGroups overlap. { As AddressGroups are an aggregation of addresses, AddressGroup and Address objects are by design overlapping.
Rule objects The Rule objects export contains a data de nition header. The relevant elds of this header are: Nr (location in the rule base (1 = top)), Name (reference name), SourceAddress (an Address object and/or a AddressGroup object referenced via its Name), DestinationAddress (An Address object and/or a AddressGroup object referenced via its Name), Services (a Services object and/or ServiceGroup object referenced via its Name), Action (Allow or Deny). Analysing the di erent objects, the following observations are made: { Source- and DestinationAddress: Source- and Destination Address contains
AddressGroup objects and/or Address objects. { Source- and DestinationAddress: AddressGroup objects or Address objects can be used for both SourceAddress and DestinationAddress. { The rule base contains both allow and deny rules, mixing a whitelist (rule base only contains "allow" rules and a default "deny" rule at the end) and blacklist (rule base only contains "deny" rules and a default allow rule at the end) approach. 3.4
An ontology is an implementation independent model and needs to be translated
towards a technology implementable solution. Certain design decisions need to
be made during this conversion. The FACT model shown in Figure 3 contains
generalization relations or (inverse) inheritance relations. The way inheritance
relations are translated towards an implementation can profoundly impact the
evolvability of the implementation model [
Based on the rewall export, we can reverse-engineer the implementation model. We can see that Source, SourceGroup, Destination, and DestinationGroup are not present in the implementation model. Only the notion of Address and AddressGroup exists. The Address object represents both a Host, IPResource, and IPResourceGroup (in the form of an IP Mask or an IP Range). The AddressGroup object represents a HosGroup. IPResources/IPResourceGroups cannot be added directly to the Rule SourceAddress or Rule DestinationAddress. Only an Address or an AddressGroup can be added. IPResources/IPResourceGroups cannot be added directly to a rule. Similar principles hold for the services. Rule Services can only be populated by either Service objects or ServiceGroup object, not by ServcieResource/ServiceResourceGroups directly. Figure 4 shows the derived implementation model as a set of tables and relationships between the tables. The di erent objects found in the rewall export map to rows in these tables.
According to NS, a modular structure will be free of CE regarding a set of anticipated changes if each module respects the 4 NS theorems { SoC, SoS, AvT, and DvT.
From Section 3.2 we can deduce that a source, a destination, and a service can be speci ed in multiple ways as they are a generalization of other types. At instantiation time, the same logical concept of a network resource can be represented by di erent objects, thus resulting in overlap. These overlaps could lead to non-disjoint rules. The ontology does not contain restrictions that would favor the creation of non-disjoint rules. If the implementation follows this ontology, it is expected that no restrictions will be present to avoid the creation of non-disjoint rules.
From Section 3.3 we can deduce that SoC between the di erent rule base objects is not respected. Service and ServiceGroup objects manage the same concern, being a protocol/port(s) pair combination. The same reasoning hold for Address and AddressGroup. The same network resource can be represented in three ways: IP Mask, IP Range, or FQDN. The three representations are generalized in the Address and AddressGroup objects.
From the observation made in Section 3.3 we conclude that SoC is violated for Address and AddressGroup. The same concern, being either a source or a destination, are combined into Address and AddressGroup. A considerable amount of changes would need to be made to the rule base's design if a source would require new attributes and actions compared to a destination. An example could be integrating identity-based ltering (the user using the source) into the ltering actions. It would require a redesign of the rule base model, e ectively representing a CE. The fact that identity-based ltering is not a simple "add-on" to an existing IP-based ltering rewall demonstrates the point.
We are more concerned about di erent relations that can exist between rewall rules. Those relations represent a form of coupling inside the rule base that only becomes visible when the design model is being instantiated. These couplings result in evolvability issues at runtime.
The namings of the Service, ServiceGroup, Address, AddressGroup objects are independent of the objects' content. They are considered as two concerns that can evolve independently from each other. Like the naming of variables in programming should be anthropomorphic with respect to what they represent, so should the naming of the rule-based objects be anthropomorphic to their content. If name and content deviate from each other, incorrect objects can be chosen to make rules, thus creating incorrect rules. The separation of naming and content result in objects with di erent names, representing the same thing. Changes to the resource, like a new IP, need to be propagated to all objects representing that resource. As you cannot deduce this from the design of the objects, it means that at runtime, you will need to search through the rule base objects to determine the impact. The change will ripple through the system and is a function of the size of the system; thus, it is a CE.
The implemented rule base's design violates SoC in 2 ways - combine di erent concerns - introducing additional coupling - and decompose concerns - violating cohesion. As changes to names, IP Masks, IP ranges, ports, protocols will happen over time, violation of SoC will lead to ripple e ects in the con guration of the rewall rule base. They can result in non-disjoint rules and become CE with respect to the addition and deletion of rules in the rule base.
Given the above, we can conclude at this point that neither the ontological model nor the implementation model facilitates the creation of disjoint rules. 4 4.1
An evolvable rule base should only contain disjoint rules. From the previous section, we know that the current ontological and implementation model of a rule base contains insu cient inherent restrictions to create disjoint rule components and thus disjoint rules. We require a systematic approach that tells us how to create the rule components and how to combine them into rules. Applying such an approach would mean introducing a more restrictive ontology for a rule base, one that supports disjoint rules. In the next subsection we present an artifact, a method, to create an evolvable rule base by applying a strict design for rule components and rules. 4.2
In previous work [
Hj X a=1
Cj ! a
Hj : X a=1
Hj ! a k=1 217 k 1 A where Cj and Hj are function of N: Cj = fc(N) and Hj = fh(N)
A subset of those rules will respresent the intended security policy and only a subset of that subset will be the set of rules that are disjoint. The maximum size of the disjoint set of \allow" rules (aka a while list) is:
fdisjoint = Hj:217 with Hj is the number of hosts connected to the network. Hj = fh(N) and 217 the max amount of services available on a host. (1) (2)
The probability that a rewall administrator will always pick rules from the disjoint set is low if there is no conscious design behind the selection of rules.
In previous work [
The section shows that applying such an artifact is enforcing a new ontology for the rewall rule base. Applying a more restrictive ontology will also mean that the implementation model will be more restrictive. 5.1
A DEMO FACT model taking those restrictions into account can be found in Figure 5. As the model is the basis for the implementation mode, the restrictions will be present there as well and will favor the usage of disjoint components and rules. The artifact enforces an implementation model that is shown in Figure 6. The necessary restriction to ensure disjoint rules are put in place. If a rewall were to use this implementation mode, it would favor the usage of disjoint rules and be evolvable under change. 6
This paper re nes previous work [
The result of applying the artifact is a ne-grained rule base. For each
host/service pair, there is a rule. As those pairs are disjoint, the rule base is
evolvable. A ne-grain rule base results in a large rule base. This could result in
a performance issue as a rewall is sized for a certain max number of rules. If
a disjoint rule base is used, horizontal scaling of the rule base becomes possible
and even dynamic adjustments of the rule base, putting more frequently used
rules at the top. Formal proof and information on the mechanism to apply for
horizontal scaling, can be found in previous work [
Making the rules manually is not a good idea. Errors or the urge to aggregate could result in loss of evolvability. For this reason, the rule base should be managed and expanded in a tool sitting next to the rewall. The tools should expand the rules according to the artifact and push them to the rewall. Adding, removing, changing rules may no longer happen directly on the rewall, as the internal data model opens the door for non-evolvable design. Creating a tool enforcing the artifact on the rewall con guration is the subject of further research and work. Introducing such a tool in an enterprise would require changes in the current operational procedures. The rewall would no longer be managed directly, but indirectly.
The initial ontological model and implementation model are reverse-engineered. The model mimics the behavior of rewalls. This study was performed with data coming from a PaloAlto rewall. Additional veri cation should happen with other rewalls such as CheckPoint, Fortinet, and Cisco. Firewall administrators who helped with this study expect similar implementation for rewalls of other rewall vendors. Explicit validation is required.
The artifact assumes that we start from an empty rule base. A method must be put in place to convert an existing rule base into a rule base that only contains disjoint rules. At that point, the rewall can be managed according to the artifact. Tooling for this transformation is the subject of future research and work. A prototype based on an iterated local search heuristic algorithm is being built and provides promising results. Being able to \normalize" an existing rule base will also bring more clarity on the size of an evolvalbe rule base. It is expected that the size will increase but unknown how much.
This paper does not include an explicit literature study as this has been done
extensively in previous work [
We started by identifying the evolvability issues of the rewall rule base. We looked at the problem from the point of view of relationships between rules, from the point of view of an ontological DEMO FACT model and a reverse-engineered rewall rule-based implementation model. We learned that the current ontology and implementation of a rewall rule base have insu cient restrictions and guarantees that only disjoint rules will be created. NS has been used to create an artifact that has been discussed in previous research. The artifact will enforce a set of restrictions on how to create rules. It e ectively implements a more restrictive ontology of the rewall rule base.
The author would like to thank Philippe Hendrickx and Jean-Francois Brison of Engie for providing the rewall export.