Service Provider Security Architecture – Part 2
In my earlier blog post, I described the need for pervasive security and architectural approaches to enable secure, agile services against increasingly sophisticated attackers. Pervasive security is critical to the Open Network Architecture (ONA).
But what does pervasive security actually mean? Since a picture is worth a thousand words, let’s represent this graphically.
As stated earlier, the focus for traditional Service Provider security models has been on enforcement methods across the layers, and these remain a critical foundation to the successful security architecture. The other key component of the pervasive security model in the Open Network Architecture is Visibility. The key lesson we outlined earlier is that a successful security strategy requires the ability to understand what is happening inside our networks, both at the perimeter and within. After all, you can’t protect what you can’t see! Since each layer on the ONA performs a different task, it is critical for visibility to include each layer in order to gather as much data about what is actually happening on the network as possible.
Now, all that data isn’t useful without context or meaning. The Policy and Segmentation layer of the security architecture refers to the understanding and rules regarding the way services work and such matters as who is allowed to talk to whom? What are they allowed to talk about? How are they allowed to talk? And when are they allowed to talk? This can be for anything from endpoint communication, through network hosts, servers or even the cloud, across defined segments or within them. This then allows us to understand what should be happening on the network.
The Service Provider is now in the situation of knowing what is happening as well as what should be happening on their network. It is logical to compare these two things to provide context and understanding to the data collected, and to provide monitoring of policy violations. This analysis can then be enriched through threat intelligence feeds, which provide information about known threats and events seen by other Service Providers, as well as techniques like behavioral analysis, which define the baseline behavior and identify deviations from this typical behavior.
Once anomalies or threats are identified by analytics, the Service Provider can then make changes at the enforcement layer to mitigate the threat. This might be anything from selecting a more secure service from the catalog, to spinning up a new security Virtual Network Function (VNF), to changing a firewall ruleset, Domain Name System (DNS) or File Policy. It can even be something as simple as shutting a port.
Working together, these layers provide a pervasive and holistic security architecture that scales to the demands and challenges of the next generation of Service Provider networks. By adopting such an architecture and selecting products and technology for implementation at each layer, Service Providers should be ideally placed to provide secure and agile services, and to face the challenges of the future.