Security Infrastructure: What to Think About When You’re Thinking About Scale

We see a lot of RFPs as enterprises and service providers go through the process of modernizing their security infrastructures. The requirements typically include these specifications relating to scale:

• Device throughput and latency
• Number of sessions
• Sessions per second
• Number and speed of network interfaces
• VLAN capacity
• Central management capabilities
• Rule base size
• Logging capacity

Our products have no problem meeting those requirements, but as we respond to these RFPs, it seems that the true objective of security at scale is not well-served by the questions. Security at scale is not simply a matter of speeds and feeds. The goal is to achieve effective, operationalized security at ever-growing scale and in highly dynamic environments. The success factors are in these areas:

• Expanded definition of throughput
• Security policy
• Automation
• Orchestration

Let’s take a closer look at each of these areas:

Throughput

The relevant metric for scaling with respect to throughput is in terms of application visibility, application control and threat prevention. Ports and protocols have become irrelevant in terms of their ability to control what users actually do on a network. Therefore it only makes sense that throughput requirements are defined in terms of the security objectives: controlling who can do what, where and when on the network.

Security Policy

The relevant metric here is not how many rules can be configured. Security policy in traditional port-based firewalls involves translating the requirements of an application or service into port, protocol and IP address rule definitions. As an example, enabling Sharepoint requires opening TCP ports 80, 443, 16500–16519, 22233–22236, 808, 32843, 32844, 32845, 5725, UDP 389, 53, 464, 49152-65535, 2015–5000, with the correct source and destination IPs associated with each rule definition. Because large-scale networks are dynamic, it is common practice to use “any” in place of explicit addresses. As more services are enabled and more ports are opened up, the network is exposed to those ports being exploited for malicious purposes. Compounding the problem, rules often stay in place after they are no longer needed. In short, more rules don’t make for more security – quite the opposite.

Our approach to security policy that scales starts with policy definitions that are directly based on applications and business processes. Take the example of SharePoint. Rules are based on business requirements – who needs access, to what specific subfunctions (e.g., admin, docs, calendar), and what content (file types) should be allowed in the context of user identity and subfunction. This approach to application enablement is easier to configure and test, and it maps directly to policy objectives. Policy maintenance is also scalable. Using Dynamic Address Groups, our platform learns when application services are no longer needed (such as when servers are decommissioned or moved) and the rules adjust accordingly. Policy stays in sync with the network and the business.

Automation

When you are thinking about scale, automation should be top of mind. There are a couple of dimensions to automation. First, there is automation in terms of response to threats. The threat world has become fully automated. Attackers have managed to automate malware creation, dissemination and use – as evidenced by our threat intelligence cloud, which finds thousands of new malware variants every day. In order to be effective, a security platform must scale in terms of automated detection and response to these threats.

Automation is also a requirement for effective incident response – the means provided for correlating events, prioritizing response and recovery. What we see in many products are disparate sets of uncorrelated logs, which make it time-consuming and difficult to determine which events require investigation, and a lack of support for conducting investigations.

Some of the ways our platform delivers security at scale through automation include:

1. WildFire threat intelligence cloud: the largest, most automated APT defense system in the world.
2. Integrated logs: no need cross check events in multiple logs.
3. AutoFocus: actionable threat intelligence.
4. Automated correlation engine: connects isolated network events to reveal attacks and compromised hosts.

Orchestration

As service providers and enterprises move to software-defined networking (SDN) and network function virtualization (NFV), the need to embed and orchestrate security is apparent. We have seen that in traditional, physical networks the challenge of achieving security at scale is untenable using traditional port-, protocol- and IP address-based approaches. In a dynamic, virtualized world, the limitations of traditional approaches are even more pronounced.

An application-oriented approach to security policy provides a foundation for software-defined, orchestrated security. We have leveraged several fundamental advantages of our platform architecture to enable security orchestration in a software-defined world:

• Security policy is abstracted away from elements tied to the physical world of networking (ports, protocols, etc.).
• A full set of APIs enabling programmatic control of policy and configuration.
• Dynamic Address Groups enabling our security platform to automatically instantiate policy where and when it is needed.
• In-depth integration with leading orchestration platforms: VMware NSX, OpenStack, and Cisco ACI, as well as public cloud (Amazon AWS).

Final Thoughts

When the time comes to modernize your security infrastructure and perhaps issue an RFP to your short list of suppliers, you really should “think outside the box” when it comes to security at scale. Think about how the solution will enable you to scale policy, business process enablement, threat response and security orchestration.