Strongedge.io

Traditional policy enforcement will be insufficient for the future of clouds and things. We will need identity and attribute based macro segmentation to reduce the attack surface.

Key constructs of the next generation infrastructures will be to:

Define in Policy

Enforce in Infrastructure

Automate implementation and audit

 

Segmentation is the construct of taking portions of our IT infrastructure and creating levels of isolation so that we can insert policy enforcement points, protect and constrain failure domains, and provide regulatory compliance. This helps constrain the attack surface by an order of magnitude by reducing the Any:Any mesh of IP reachability in our security policy.

Traditionally we have done these over well segmented IP address pools, enforcing layer 2 and 3 isolation and multi tenancy. A traditional segmentation approach (along IP Subnet lines), is below. However, with the raft of new technologies and requirements, from mobility to cloud to IOT, the traditional methods of IP subnet based virtualization will unfortunately, not scale. Fortunately, new technologies have come to market which make for attribute (OS, APP) level segmentation, something that before was very HARD to do with ACL’s, and makes them attainable.

Traditional Segmentation

What do I mean by OS and attribute based segmentation? Specifically, over 99% of customers I have had the opportunity to work with run over 99% of their workloads on two operating systems, Linux and Windows. MOST customers do not create infrastructure ACL’s to apply best practice system hardening in the infrastructure. And that is a shame, because the infrastructure is sitting there with stranded resources. It has the capabilities, you have paid for the TCAM space, but it lays fallow because the reality is implementing this with the legacy constructs of IP based identification and location, make it unmanageable.

However, with advances in technology, the ability to perform what has traditionally been done in “market segmentation”, grouping applications and systems by their “characteristics”, is now within reach. This allows for us to provide proper services, hardening, and quality of service, to specific applications and groupings of systems based on business requirement. This level of abstraction also allows us to apply best practice system level hardening much easier than we could in the past.

 

Some feedback is that customers don’t fully understand their applications and applying application policy is hard. Luckily, we’ve been down this road before.

Because we HAVE been down this road before… the road of classifying applications and treating them based on their attributes. We did this when we enabled Quality of Service. In the past 15 years of deploying Quality of Service, there were some key learnings which came out of that development, namely :

1. Not everything, is worth managing discretely.
2. Start with everything in a common pool, and pull out items that require a differentiated service.
3. Over engineering can lead to exponential complexity (especially when using IP based semantics)
4. Focus on what matters most, and group (macro segment) the rest based on requirements.

This leads well into group based policy, where instead of just managing each application, we can group applications along characteristic boundaries, be it web, SQL and application layers.

Macro Segmentation can enable real time value of group based policy in an existing environment, through applying OS based best practice system level hardening.

And for a traditional environment which is already deployed, there is significant value in that you can migrate to newer technology today, and almost immediately get benefit of group based segmentation Without understanding all of your applications. The reason is, at day zero, you can begin applying policy on the Operating systems, which we understand well, and there exists best practices on hardening.

Some specific advances in technology which enable this are :

1. Separation of location from identity.
   1. This is important, because traditionally these were conflated in an IP design. This is like calling me William from Phoenix, it’s a great name, and I can keep it wherever I go, so long as its within Phoenix. And I derive my security based on the security of the township for which I am named. By separating location from identity, I am instead known as William, and appropriate security is based on the characteristics of the demographics, for which you decide as a network architect. (this enables you to group all William’s in the world and ensure that whenever someone speaks with us, they use the “Sir” prefix).
2. Data center and campus fabrics
   1. Decoupling location from identity is only viable if you maintain the key goal of IP, reachability. Through development of data center and campus fabrics which can allow for connectivity of IP addresses, which are no longer associated with a place, you have allowed for reachability.
3. An Open group based policy
   1. Once we have decoupled location from identity, and provided reachability… now we have the ability to redo policies for quality of service and security, in our liking. This means the following are within reach,
      1. Classifying and applying security and best practice hardening, on the operating system
      2. Classifying and applying security for applications
      3. White list policies specific to application and OS requirements
      4. service chaining based on the above characteristics.

 

This leads to being able to apply best practice system level hardening, and segmentation based on device or app “type”, which can enable NIST, FIPS, HIPPA, and PCI compliance.

NIST Guidelines

PCI Requirements

 

An example of options available to macro segment based on OS characteristics, We use the term “EPG” as it pertains to “Endpoint Group”, which is a logical grouping of endpoints.

 

And the type of Best Practice OS Level hardening policies we can apply….

Which leads to an ability to create compensating controls,

 

 

And most importantly, by segmenting based on Characteristics… of either an App or an OS, it becomes reasonable to automate the Audit of these applications and operating systems, as they share attributes…

An example of how an automated Audit capability could be used to interrogate the “AS IS” from the “Intent”. In fact, specific “red herrings” could be implemented in group based policy which creates a behavior shaping constraint to ensure proper end point classification. Namely, you could block RDP from the Linux groups, and SSH from the windows groups. That is because typically you don’t RDP to linux servers, or SSH to windows servers… and by blocking those ports in the end point groups, if an administrator accidentally applies the wrong system level policy (puts a windows server in the linux group), it would be apparent in short order that a mistake had been made (when they can no longer remotely administer the system), leading to them to investigate and correct the change.

 

 

In summary, the advances in technology now put system level best practice hardening capabilities in reach for network administrators. This creates a defense in depth capability, which can be audited.