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.

[Palo Alto Networks Blog]

National Cyber Security Awareness Month: There Is Something New To Talk About

Executive Summary

On the occasion of the 12th U.S. National Cyber Security Awareness Month, threat prevention comes to the forefront as something that the community has rediscovered as a security innovation. We used to do this as a matter of course, but sort of lost our way for a while. Today, smart network defenders have learned that threat prevention is inextricably linked to detection and mitigation. You should not have one without the other two.

Introduction

Twelve years ago, the Department of Homeland Security designated October as National Cyber Security Awareness Month for the United States. [1] When I noticed that this year’s installment was approaching, I began to wonder if there were any new developments in the cybersecurity community of which most people were not aware. Part of my job is to travel around the world talking to smart people about how they do security, and it has been an education these past two years. Every network defender whom I talk to does it differently, and they all have good reasons why they are different. But the one thing that is clear to me is that most do not realize that there is a quiet revolution going on right under their noses. The cybersecurity community is rediscovering the idea that threat prevention is an atomic piece of the overall defensive strategy for any organization.

A Little History

When I started in the industry some 25 years ago, all we had in our toolbox was threat prevention controls: stateful inspection firewalls, intrusion detection systems and antivirus engines to name a few. Sometime in the mid-2000s, innovative companies started selling some very good niche products that could detect adversaries once they had breached the typical threat prevention defenses that we all had deployed in our networks. Some of these new tools were very good and we started finding all kinds of bad guys in our systems.

In 2010, state-sponsored cyber espionage adversaries attacked Google, and for the first time in history, a commercial company went public with the information.  [2] Before the Google attacks, referred to as Operation Aurora in the press, no commercial company would dare go public with the fact that a cyber adversary had been successful in breaching their network. Common wisdom in the industry at the time was that such an admission would wreck the bottom line of the company by hurting the brand name. But with Google’s public admission and a plethora of state-passed, public breach notification laws on the books that came later [3], it seems that you can’t get through a week of cybersecurity news today without one or two companies announcing they have been breached.

Somewhere between the Google attacks and today, the security vendor community threw up their hands in dismay and declared that it was not possible to prevent bad guys from penetrating our networks.  Our only hope, they would say, was to quickly detect them, once they were successful, and eradicate them from the network as soon as possible. The security vendors seemed to declare that threat prevention was dead, and our only hope was detection and mitigation.

That is the dumbest notion I have ever heard.

Threat Prevention as a Rediscovered Innovation

We can absolutely stop most of the known badness that black hat adversaries throw at our networks. We can’t stop all of it, for sure, but we can stop most of it. As a network defender, why would you leave that option off the table to simply rely on a detection and mitigation strategy? That obvious question has started to pop up on the radar of many network defenders whom I have talked to this year.

My CTO, Nir Zuk, is fond of saying that, if you are okay with the idea that some adversary will steal your most precious secrets right out from under your very noses, and your risk mitigation plan involves noticing that they were there after they are gone,  then you should probably consider another line of work. [4] And he is absolutely right. When you say it out loud like that, you realize how crazy that sounds.

What I have noticed this past year is that the cybersecurity community has come back around to this notion that threat prevention is a key and fundamental element to any network defender’s plan. It has to work hand in hand with the other two requisite pieces: detection and mitigation, but it cannot be left out. All three are essential to the plan, but none are sufficient by themselves. Smart network defenders have never abandoned this idea. The rest of us are just now rediscovering it.

Conclusion

As I reflect on the state of cybersecurity during this 12th U.S. National Cyber Security Awareness Month, threat prevention comes to the forefront in my mind as something that has been old in the past but is new again today. As I travel around the world talking to smart people about security, this is what they are talking about: threat prevention is key and essential to any defensive program. It is as important as detection and mitigation but, more to the point, network defenders should not choose one over the other. They are inextricably linked together.

Sources

[1] National Cyber Security Alliance. 2015. “National Cyber Security Awareness Month,”StaySafeOnline.org. Last Visited 28 September 2015.
https://www.staysafeonline.org/ncsam/about

[2] Zetter, Kim. 2010. “GOOGLE HACK ATTACK WAS ULTRA SOPHISTICATED, NEW DETAILS SHOW.” Wired. Last Visited 28 September 2015.
http://www.wired.com/2010/01/operation-aurora/

[3] National Conference of State Legislatures. 2015. “SECURITY BREACH NOTIFICATION LAWS.” National Conference of State Legislatures. Last Visited 28 September 2015.
http://www.ncsl.org/research/telecommunications-and-information-technology/security-breach-notification-laws.aspx

[4] Zuk, Nir. 2015. “Only a Platform Can Prevent Attacks.” Ignite 2015, Palo Alto Networks. Last Visited 28 September 2015.
http://researchcenter.paloaltonetworks.com/2015/05/nir-zuk-at-ignite-2015-only-a-platform-can-prevent-attacks/

[Palo Alto Networks Blog]

English
Exit mobile version