## 4 Policy/Intent-Based Security in SDN and NFV Networks  
### Policy-Based Networking Development  
Previously, when enhancing the security of networks using policies, all methods required manual configurations, and even though high-level policy languages have been around for quite some time, as in the case of _Ponder_, which was defined in 2001, implementations that used them were scarce and very limited, since most of the process could not be automated. The development of policy-based networking (PBN) has evolved to uphold network security and efficient resource management, as discussed in the work of [100], which focuses on designing energy-efficient networks with minimal environmental impact. This is possible due to the research conducted into refining policies using algorithms that adapt them based on predefined criteria such as energy efficiency. Still, in the context of the development of this tool since its inception, [101] explains how the development of technologies such as SDN further increased the integration of policies into the definition of how networks are structured and deployed. In this work, OpenFlow was used in the automation of policy enforcement across network devices, and these policies were translated from human-readable security policies into actionable network configurations through the OpenSec framework explicitly developed for this work and with the intent of making it possible to enforce these abstract security policies dynamically within SDN. For future reference, since even though there are some discrepancies in how the policies are applied, translated, or enforced, the process itself is usually very similar; the following are the procedures in OpenSec for a successful security policy enforcement in networks that are instantiated through SDN and utilise Network Function Virtualization (NFV), and the further-discussed implementations will have many similarities:  
* **Policy Definition:** Network administrators define security policies using the OpenSec language (a high-level policy language). * **Policy Translation:** The SDN controller translates these high-level policies into low-level flow rules that can be implemented in the network hardware. This translation is critical to enabling dynamic, automated security management. * **Flow Processing:** Based on the translated rules, network flows are directed to appropriate security services. For instance, if a flow is identified as needing deep packet inspection (DPI), others need to be passed through an IDS. * **Security Event Handling:** When a security service detects a threat (such as malicious traffic identified by an Intrusion Detection System (IDS)), it alerts the SDN controller. The controller then takes predefined actions, including blocking the traffic, rerouting it, or simply logging the event. * **Policy Enforcement:** The SDN controller continuously monitors compliance with security policies and can adjust flow rules dynamically in response to network conditions or security incidents. This continuous monitoring is what security policy enforcement is mostly about and why the development of SDN has been so advantageous for its implementation. Furthermore, the process can also be found in the older literature articles that preceded the implementations that will be discussed further in this section and have defined architectures of policy-based management for what used to be described as programmable networks, now referred to as SDNs. One of these examples of architecture on which most current implementations are based is present in the work of [102]. In their proposed architecture, it is possible to find a hierarchical structure organised into two tiers consisting of the Network Management System (NMS) and the Element Management System (EMS); both are still present to a point in current SDN architectures in terms of functionality, albeit with different terminology. The policies are defined at the NMS level and translated as well as enforced down to the EMS and network elements.