% Policy analisy, conflicts and trasformation

\subsubsection{Models of Rule Relations}

A Network Security Policy is a set of rules with a specific order and in most of the cases the number of rules are huge. Therefore it becomes hard to understand if the rules have dependencies and how they are related.
The relations between filtering rules are due to misconfiguration or maybe the security admin is aware of them. They could be summed up as follow~\cite{firewall-01}:
\begin{itemize}
	\item 
	exactly matching, if one rule R\textsubscript{1} for each field has an equal correspondence to another rule R\textsubscript{2}, they are exactly matching (R\textsubscript{1} = R\textsubscript{2});
	\item
	inclusively matching, if in rule R\textsubscript{1}, called \textit{subset match}, every fields are a subset of a second \textit{superset match} rule R\textsubscript{2} ($R\textsubscript{1} \subset R\textsubscript{2}$);
	\item
	correlated rules, neither of the two rules is a subset or superset of the other one, but their fields space is partially overlapped and the rest of the fields are equal. ($R\textsubscript{1} \bowtie R\textsubscript{2}$);
	\item
	disjoint rules, two rules (R\textsubscript{1} and R\textsubscript{2}) are \textit{completely disjoint} if every fields in the first rule is not equal, not a subset or superset to the corresponding field in the second rule ($R\textsubscript{1} \cap R\textsubscript{2}$ = $\oslash$). Eventually there is also the term \textit{partially disjoint} that identify the condition when the R\textsubscript{1} has at least, one field that is equal, subset or superset to the corresponding field of the R\textsubscript{2}, but at the same time the first rule has at least one field that is not equal, subset or superset of the same field in the second rule. 
\end{itemize} 

\subsubsection{Policy Analysis}

Policy Analysis performs an inspection of the rules in a policy, or more than one, in order to detect anomalies, which can be threads that are evidence of a misconfiguration of the system and thus leads to security problems.\cite{D4.3}
These conflicts may exist between just a policy, or between different policies and security devices, so they lead to the following classification:
\begin{itemize}
	\item
	intra-policy anomalies, this class represent all the conflicts that arise between rules of the same policy;
	\item
	inter-policy anomalies, which are the anomalies that come out between different policies, but with the same capability;
	\item
	inter-function anomalies, it is the class that represent the anomalies between two function owned by different policies having different capabilities;
	\item
	inter-actor anomalies, which are the anomalies between two rules of different policies, but defined by different actors.
\end{itemize}

\subsubsection{Policy Conflicts}

Moreover, each anomaly class can have different rules conflicts, the first one looks into the\break Intra-Policy Anomalies:
\begin{itemize}
	\item 
	Shadowing anomaly (Figure \ref{fig:rule_anomalies}(a)): a rule is called shadowed if every packet that could be matched by this rule, it is matched by another rules that is preceding or it has higher priority then the first rule.
	In others words two rules, R\textsubscript{1} and R\textsubscript{2}, which performs different action, make a shadowing anomaly when R\textsubscript{1} matches, at least, the same packets of R\textsubscript{2} (the condition clause of R\textsubscript{1} includes all the condition clause of R\textsubscript{2}) and R\textsubscript{1} has a greater priority then R\textsubscript{2} or it is preceding the second rule.
	\item
	Correlation anomaly (Figure \ref{fig:rule_anomalies}(b)): it occurs when there is some traffic that matches both R\textsubscript{1} and R\textsubscript{2} rules, which means the two rules are partially, and not completely, overlapped for some fields' values. 
	They preform different filtering action on the matching condition, so the result action applied on the traffic depends on the ordering of the rules. This dependency leads to ambiguity in the definition of the security policy.
	\item
	Exception anomaly (Figure \ref{fig:rule_anomalies}(c)): it is also called Generalization anomaly and it expresses the situation in which, R\textsubscript{1} and R\textsubscript{2} perform different actions, the first rule, with the higher priority, match all the packets of the second one that has lower priority, so this last one is a superset of the matching condition of R\textsubscript{1}.
	This is not an error, but it is used to allow or to exclude a particular pattern traffic, while the general one performs the opposite action. 
	\item
	Redundancy anomaly (Figure \ref{fig:rule_anomalies}(d)): it occurs when R\textsubscript{1} matches all the traffic that could be matched by R\textsubscript{2} and R\textsubscript{1} has a better priority then R\textsubscript{2}, but they perform the same action.
	This means that if R\textsubscript{2} is removed the behaviour of the security policy is unchanged.
	\item
	Irrelevance anomaly: it refers to a rule that cannot match any packets flows on the devices where it is enforced.
\end{itemize}

\begin{figure}[ht]
	\centering{\includegraphics[width=0.9\textwidth]
		{policy-01.png}}
	\caption{Geometrical representation of rules anomalies.
		\label{fig:rule_anomalies}}
\end{figure}

Inter-Policy Anomalies class has some of the previous conflicts as \textit{Shadowing anomaly},\break \textit{Redundancy anomaly} and \textit{Correlation anomaly}, which are similar in the definition and in the behaviour.
There is another anomaly called \textit{Spuriousness anomaly} that has seriously impact on the network security, because the traffic is not properly handled and it flows in the network.
This occurs when the upstream security device, having a define set of filtering capability, allows some packets to be forwarded, but the downstream filtering device that has the same capabilities of the first one, blocks this traffic.
Obviously the traffic will not reach the destination, but it could be dropped before in the upstream firewall, avoiding the unnecessary flows through the network.

Moreover, the \textit{Policy Analysis} does not takes into account two particular cases. The first one is what is the behaviour of the system when no rules are matched, and the second case is what the system will do if conflicts rules match the same traffic~\cite{ACPAandT}.

It is necessary defines and chooses a policy action that is applied to all the packets when the traffic do not match any rules, this is called \textit{default action} $\mathit{d} \in \mathcal{A}$.
The security system, on the contrary, when more than one rule is matched, takes the decision according to the \textit{Resolution Strategy} function that decides which action must be performed.
At first instance all the matching rules are picked out and then the resolution strategy chooses the action that will be performed between the matching ones, so it could be represented in a formal way as: $\Re$ : 2\textsuperscript{R} $\to \mathcal{A}$ in which the resolution strategy function maps all the possible groups of rules into an action $\mathit{a} \in \mathcal{A}$.

Each Security Policy could define its own custom resolution strategy, it depends on the contexts of the policy deployment, commons functions are the following:
\begin{itemize}
	\item  
	First Matching Rule (FMR): the policy performs the first rule between the set of the\break matching ones;
	\item
	Allow  Takes  Precedence  (ATP): if two matching rules have different actions, the one that allows the forwarding of the traffic is chosen;
	\item
	Deny  Takes  Precedence  (DTP): that means, if two matching rules have different actions, the one that drops the packet is chosen;
	\item
	Most Specific Takes Precedence (MSTP): the resolution policy chooses the rule which has more matching fields;
	\item
	Least Specific Takes Precedence (LSTP): the resolution policy chooses the rule which has less matching fields, so it is more generic.
\end{itemize}

\subsubsection{Policy Transformation}

Usually Security Administrators specify policy at high level, maybe in a human readable syntax for debugging and they make the security policy more readable to be understandable.
This set of rules needs to be translated into a format that real devices can read, accept and enforce. \newline
This policy manipulation task needs the concept of \textit{Semantics-Preserving Policy Morphism} that is a transformation of the policy representation, but it guarantees that it keeps the policy\break unchanged~\cite{ACPAandT}.
 
This translation of policy representation allows analyzing anomalies independently from the resolution chosen by the administrator, but leaving its semantics unchanged.
\clearpage

This is done following two steps: 
\begin{itemize}
	\item
	first, it is a process to translate the policy in a generic intermediate representation called \textit{Canonical Form};
	\item
	second, it is a process that takes advantage of the first step to translate the canonical form into any target resolution strategy.
\end{itemize}

The \textit{Canonical Form} is a policy representation, useful for policy manipulation and based on the operation set to solve conflicts. 
It is formally equivalent to the original one, but it has more rules, this permits an easier processing, because all the possible combination of conflict cases are precomputed with the resolution strategy $\Re$.
Now all the algorithms that work on the Canonical Form of a policy do not have to consider the original $\Re$, because all the differences between the resolution strategies are removed.

\begin{figure}[H]
	\centering{\includegraphics[width=0.9\textwidth]
		{policy-02.png}}
	\caption{Graphical geometrical representation of the match function (a), the cover graph (b) and, finally, the exported rules (c).
		\label{fig:FMR}}
\end{figure}
