- NFV-based security involves software-based security infrastructure, micro security services, and high-capacity clusters.
- In SDN networks, security devices must support open northbound interfaces.
Key takeaways:
This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy
The cloud creates a whole new network environment. But, it needs to be protected. Here's how to do it.
Key takeaways:
Transforming network security is intrinsic to network transformation. NFV and SDN are the tools for ensuring that operators can meet business requirements with a security system that adapts to the new environment network-wide.
Service-driven, cloud-based network transformation brings a slew of financial and performance benefits to operators, including greater service agility, faster service provisioning and TTM, lower OPEX, automation, the Pay-as-you-Grow model, and VAS.
But, traditional security mechanisms are no longer up to the task of protecting cloud environments for a number of reasons:
Ineffective static security software and hardware: The traditional static security components and software deployed on the network borders and servers cannot sense east-to-west traffic between virtual machines (VM) or ensure security in cloud scenarios.
Complex security management: Large cloud data centers (DC) have numerous cloud security policies, placing high demands on personnel to manually handle application, review, and configuration tasks such as policy updates, approvals, and around-the-clock maintenance.
Access and backbone transmission networks are still largely based on traditional architecture. As a result, NFV and SDN security features are applied mainly in the core network and cloud DC applications.
New network architecture creates different security requirements in different locations, as demonstrated in the following four scenarios.
One: vEPC requires signal security, so the security infrastructure must provide functions such as 3GPP IPSec encryption.
Two: The security requirements of vMSE include high-performance NAT and URL filtering, as well as Anti-DDoS.
Three: Security requirements for vCPE include border protection for enterprises with end-to-end VPN encryption, E2E QoS, IPS, and anti-virus.
Four: The IT Cloud provides telecom VAS like video for operators, which needs tenant-grade perimeter security.
The virtualized and cloudified infrastructure in each of these scenarios requires NFV-based security services. Scenarios three (vCPE) and four (IT Cloud) involve enterprise border protection and tenant protection, respectively. So, they require network equipment scheduling, including hardware boxes and vSwitch virtualized components, meaning that security must be integrated into the SDN network and adapted to the entire network architecture.
NFV-based security involves processes for achieving the following three goals: software-based security infrastructure, micro security services, and high-capacity clusters with elastic scalability in cloud architecture.
Software-based security infrastructure applies to different sizes of software and hardware security components. Next-Generation Firewall (NGFW) hardware is deployed at every perimeter on the cloud DC network in the traditional manner, while the software version of NGFW is deployed on every VM. When VMs are launched, the software firewall or security service agent must also be launched.
Hardware and software NGFW must support 1:N and N:1 virtualization. 1:N virtualizes a single NGFW software or hardware device into many virtual devices that can be invoked by different servers or services based on NFV service requirements. N:1 pools multiple NGFW software and hardware components, so security resources can be flexibly invoked based on service needs. In both scenarios, the flexibility and ease of use of the software and hardware NGFW makes managing 1:N and N:1 virtualization easier.
Micro security services applies scheduling on individual and combined services. Virtual NGFW (vNGFW) includes more than ten types of security services, including application identification, NAT, VPN, IPS, and URL filtering. For easy deployment, these services can be batch deployed on a single vNGFW. For greater flexibility, distributed deployment can run each virtual security NE (or VM) as a virtual network function, with the Service Chain invoking the corresponding security service when they’re used.
High-capacity clusters and elastic scalability implements high-capacity clusters to better support high-volume operator pipe services, with two possible implementation methods. The first is distributed architecture, where different modules of a vNGFW, such as URL filtering, VPN, and IPS, are deployed on different VMs. The multiple VMs are arranged on a single vNGFW to form a high-capacity cluster. The second method deploys each vNGFW on a single VM, and a cluster is formed by bundling multiple VMs. Once the vNGFW has formed a high-capacity cluster, security gateways of various sizes can be formed according to service requirements. This ensures the security of different traffic volumes and services within the cloud DC.
In SDN networks, security devices must support an open northbound interface. The SDN controller can then carry out scheduling, micro-segmentation and, preferably, different controller ecosystems so they’re effective in multi-vendor hybrid networks.
Integrating security into an SDN network depends on security NEs that can be automatically deployed by the controller platform, so that services can be provisioned based on the Service Chain. Scheduling threat protection on-demand can provide minute-level service provisioning through Plug & Play; customized services such as automatic provisioning, expansion, and recovery; and the flexible directing of traffic flow.
The service process of the security NE is as follows: The external user or VM sends a first packet stream. After the stream passes the vSwitch, the vPath carries out policy-based packet analysis. After the vSwitch identifies a new stream, the designated virtual FW (vFW) inspects the stream, which is then sent to the corresponding vFW. The vFW implements the ACL policy and caches the ACL policy to the vSwitch. If the policy allows, the packet is sent to the target VM. Otherwise, it’s discarded.
When the security NE is scheduled by the controller, it needs to collaborate closely with the vSwitch and other cloud network components. Thus, it assumes true responsibility for security in the virtualized network.
Traditional DCs use perimeter security technology, including NGFW and IPS components. They carry out immersive analysis on inflowing traffic to confirm threats, and apply security policies like blocking and passing to allow authorized users or service flows to access DC resources. Typically, these security devices can only analyze north-to-south traffic, that is, traffic that enters and exits the DC.
However, east-to-west traffic now comprises the dominant volume of traffic in a cloud DC. The traditional method of defining security zones based on IP no longer meets the security requirements of cloud DCs for two reasons: one, cloud DC NEs have evolved from traditional single component hardware to VMs; and, two, users accessing the cloud DC have evolved from traditional fixed network users into dynamic tenants and mobile and IoT users.
Micro-segmentation tech has changed the traditional method of defining security zones by IP. Security groups can now be defined on more parameters, for example, OS, device name, security tag, VLAN and MAC address. This particularly suits the dynamic security groups of cloud DCs such as dynamic virtual NEs, dynamic tenants, and dynamic remote access users.
Security NEs in cloud DCs must be able to support micro-segmentation, identify the security group of any traffic based on parameter and label, report to the controller, and accept and execute the security policy issued by the controller.
When building cloud DCs, different operators use different controllers and network equipment from multiple vendors depending on specific requirements and existing infrastructure. Having this choice is an important way operators can reduce CAPEX and OPEX. As a result, it has become essential for security devices – as components of the SDN network in the cloud DC – to support management and orchestration via multiple types of cloud platforms and controllers, as well as multiple hypervisors. This capability determines whether security components can be widely adopted in cloud DC networks.
In a cloud DC, three methods of security management exist: the cloud platform (including third-party cloud platforms), the controller, and the traditional network management system. Security NEs support management by the cloud platform.
For open-source cloud platforms, security NE management plug-ins must be released to the open-source community for certification. For third-party cloud platforms, security NEs must be adapted to the third-party vendor. For the security NE to support SDN controller management, the northbound interface – normally RESTful – needs to be open and able to interoperate with the corresponding vendor's controller. The northbound SNMP and CLI interfaces of the security NE must remain open, as there will still be a need for independent network management systems for a long time to come.
In cloud DCs, the hypervisor and vSwitch direct and schedule virtualized traffic, as east-to-west traffic between VMs does not pass any physical firewalls. As a result, security vendors' virtual firewalls are often unable to function independently. Security NEs must therefore adapt to the main hypervisor and vSwitch. If they don't, security management and control won’t be effective.
Operators are future-proofing their networks through cloudification, and adapting security to this new cloud architecture is an essential part of the process. Huawei’s NFV-based security infrastructure fully supports SDN networks, enabling operators to simplify O&M, reduce TTM, enable flexible scheduling, and utilize resources efficiently to achieve business success as well as robust network security.