An Exploration of End-to-End Network Segmentation—Part I: Hyper-Segmentation

More than 90% of businesses say they have some sort of cybersecurity framework in place, but here’s the truth: a network security strategy will never be effective if a company’s underlying architecture isn’t what it needs to be. Traditional, hierarchical, client-server architecture is simply not built to support today’s next-generation network, or protect against the increased risk of exposure inherent in it (this is something I recently blogged about for the Huffington Post). This is like riding a horse and buggy down the freeway and expecting life-saving crash protection.

Cue the thousands of solution providers vying for market share, all selling the concept of failsafe network security. But let’s be honest: any provider that claims to offer foolproof security is only fooling you. Considering today’s rapid pace of innovation, we’ll hopefully see this day soon. Until then, not even the best provider can absolutely guarantee network security 24×7.

There are, however, a few ways to safeguard your organization with a (near) impenetrable network that significantly minimizes security risks and reduces exposure. It all comes down to the technology you use and from whom you get that technology. At Avaya, we believe companies need to take a foundational approach to network security by implementing an end-to-end segmentation solution that inherently protects from the inside out. This approach consists of three core capabilities:

  • Hyper-Segmentation:

    The ability to create stealth segments that span the entire network.

  • Native Stealth:

    The characteristic of a hyper-segment that’s invisible to hackers.

  • Automated Elasticity:

    Extending and retracting hyper-segments access automatically.

The way we see it, endorsed by many cyber security experts, end-to-end segmentation is the holy grail of network security today. This critical level of protection should be as simple as safety is for a driver getting behind the wheel. All companies need to do is buckle up and enjoy the ride.

At Avaya, our goal is always the same: equip business leaders with the necessary skills, knowledge and know-how to do what’s ultimately best for their organizations. For IT leaders contemplating a better way to protect their networks, I’ve put together a three-part series that pulls back the veil on our all-new end-to-end segmentation solution and its core capabilities of hyper-segmentation, stealth and elasticity.

Ready to join me? If so, let’s kick things off by exploring the incredible concept of hyper-segmentation.

Out with the Old

A classic segmentation method, in which virtual local area networks (VLANs) are created, is one that companies have been using for 20+ years. This method involves isolating segments in order to maximize quality of service, ensuring one type of traffic doesn’t impact the other. In this case, each segment carries different traffic types that require different characteristics to deliver the desired quality of experience.

For example, one segment may carry real-time voice traffic while another would carry best-effort data traffic such as web browsing. This approach sounds simple, but there’s one big problem: as organizations grow, so too must their segments. This creates high levels of complexity and increases risk of failure, as VLANs used are subject to loops created by human errors while having to learn about each node that physically joins the virtual network.

So, these segments must inevitably grow in order to meet evolving network and application needs. As they do, they become increasingly difficult to troubleshoot and manage, leading to greater network strain and performance issues. At this point, a company’s only resolution is to create more smaller segments, which simply introduces more complexity into their already intricate network environments.

All the while, these network segments aren’t truly isolated from one another; rather, they’re communicating extensively when IP services are enabled. These are known as Layer 2 virtualized networks. To make matters worse, Layer 3 virtualization is also typically required when IP services need to be isolated from one another. Think of two departments or two tenants wanting to share a common networking infrastructure. At that point, the concept of VRF (Virtual Route Forwarding) needs to be introduced. Once again, each node participating in this Layer 3 virtualized network must be configured.

Hence, end to end segmentation is achieved by performing complex nodal configuration. Not very scalable when you think about it, yet it does work! Add to this other services such as multicast and you now have a fragile house of cards to deal with, as all these layers have interdependency. Because of this interdependency, this stack can (and will) collapse if just one layer is affected (think of how easy it is to knock down a house of cards with just a flick of the finger). Each layer depends on one another in order to keep the stack running and secure. For businesses relying on legacy architecture, this setup of multiple interdependent protocol layers can lead to tragic outcomes if even just one segment is affected. This is exactly what happened with the infamous 2013 Target breach. An HVAC vendor, external to Target, had authorized access to service the HVAC system. As the network was statically configured using VLANs, hackers were able to get into that HVAC virtual segment. But rather than being contained there (we’ll get to that shortly), they broke out of the HVAC segment and into the segment that hosts credit card data. So you see, in this environment, the inherent lack of security at layer 2 (e.g., HVAC segment) negatively impacted other layers — including the mission-critical apps that resided in them. Safe to say this is not the business outcome you want.

The goal, then, is to greatly simplify the way segmentation can be achieved. I guess you could say, let’s manage less and, in doing so, better converge, sustain and control the network. Right? Well, sort of. This “less is more” approach can also lead to network complexities. Hear me out: fewer segments to manage means greater risk in terms of network performance and outages. Without a certain level of segment isolation, one misbehaving device, human error or system glitch can create instability to the entire network. In other words, you should be cautious about putting all of your eggs in one basket (one huge virtual segment).

Are there any other options? Well, MPLS has been designed to deliver what many considered “true” end-to-end virtualization. However, does it really deliver what companies need? It’s true that MPLS does offer end-to-end virtualization, but it’s still based on a restrictive nodal labeling methodology with even more layers of protocols. Obviously, end-users don’t notice this, as this complexity is expertly masked by providers or IT using highly sophisticated provisioning tools. These tools allow them to quickly deploy an end-to-end virtualized network while hiding all backend complexity. It’s a powerful and scalable solution, yet in the end built on a similar and unfortunately more complex foundation.

In with the New

Now I want to clarify that there’s nothing necessarily wrong with MPLS. Many large organizations still run on an MPLS model they deployed long ago. This is fine if you have the skill set and have made the investment in provisioning tools. What businesses are beginning to realize, however, is that they need to better support the dynamic changes happening not just within the data center, but where all data is consumed by mobile users and other devices. Nothing is static anymore. They must be able to add new services on the fly, make changes to existing services within minutes and build new network segments on demand across the entire enterprise. Remember, end users and IoT devices don’t sit in the data center!

You simply can’t deny that today’s business environment looks drastically different than it did 20+ years ago. So, why would we still rely on legacy segmentation methods from that period? The only way to flexibly and securely meet today’s network needs is to deploy a solution that eliminates nodal configuration and yet achieves true segmentation. Hyper-segmentation does just this by using the concept of end-to-end Virtual Services Networks (VSNs). This enables businesses to provision their networks only at specific points of service. In other words, where the service is offered and where the service is being consumed by end users or device(s). That’s it! The core becomes an automated and intelligent virtualized transport.

By eliminating nodal configuration, companies are able to drastically reduce complexity and create hundreds—even thousands—of agile and secure virtual segments that are completely isolated from one another (meaning no communication by default). This allows companies to decide if they want to establish communication between segments, verses having to prevent it. With hyper-segmentation, segments can be quickly created (and easily provisioned) without the need for time-consuming or error-prone network nodal configurations.

This result is achieved because of the technology’s ability to isolate segments by default on one secure, converged network. This transforms network protection by allowing security tools to focus on performing the specific functions they’re implemented for, verses having to serve as a barrier between segments to prevent chatter. In this way, hyper-segmentation allows companies to gain maximum transparency into how their networks are behaving in order to quickly prevent, identify and mitigate security incidents.

Remember Target? With hyper-segmentation, the hackers would have been contained to the HVAC segment (in other words, isolated there). All other segments would have been invisible (natively stealth) to them. It doesn’t matter how skilled of a hacker they are. You can’t hack what you can’t see.

In this new world, multilayer protocols exist only because we must maintain backwards inter-operability with the legacy model, but new virtualized services can be delivered with just one protocol. No more house of cards, unless you absolutely need it!

Now if your company depends on MPLS, you may be thinking, “Where does this leave me?” Here’s my advice: leave your MPLS network environment as static as possible so you can embrace the dynamic configuration of hyper-segmentation and leverage its strength of provisioning at the point-of-service only. In doing so, you’ll benefit from some of the next-generation segmentation technology without having to forklift your current investment as hyper-segments can now traverse any IP WAN solutions including IP MPLS or SD-WAN solutions from vendors such as FatPipe. In the end, it’s now up to you to decide how you want to implement end-to-end hyper-segmentation. No more dependency on the service provider’s to configure and extend a service (VLAN, VRF, DC inter-connect, etc.) across the WAN … you now control your own destiny!

Now on to the next question: what role does native stealth play in end-to-end segmentation? Learn more in Part II next week.

 

Related Articles:

Benefits of Deploying the Avaya Surge™ Solution for Any IP Network

The Avaya Surge™ Solution is designed to work in an SDN Fx fabric environment. But many companies don’t have the luxury of deploying a full Ethernet fabric before they deploy their IoT-based applications. Avaya Surge release 1.0.1 (November 2016) added support for non-fabric IP networks.

The Surge IoT Controller works essentially the same way as in the SDN Fx fabric deployment, except the Open vSwitch on the Open Networking Adapter can’t automate network provisioning. Therefore, the VLANs must be configured manually on the network. The solution still provides centralized inventory, white list profiles, flow filtering, and a single pane-of-glass status for all Open Networking Adapter-enabled IoT devices. Without the SDN Fx fabric infrastructure, segmentation is limited to VLANs that aren’t stealthy and mobility requires manual network service set-up and tear-down. For environments where devices are static, the IP-only version of Avaya Surge may suffice until a full fabric can be deployed.

The risk profile of IoT doesn’t lend itself to “good enough” solutions for long. When a company’s network and data are compromised, less than best practices will be criticized in the media, in the court room, and, as in the Yahoo case, impact executive pay. Avaya Surge Release 2.0, scheduled for the second quarter of 2017, adds IPSec encryption and tunneling to an IP-only deployment. (IPSec will be available for SDN Fx deployments as well.)

A HyperSec gateway is deployed to coordinate the IPSec functionality with the Open Networking Adapters. The HyperSec gateway terminates the IPSec connection from the Adapters and directs the data to the correct VLAN to reach the target application server. Return data is encrypted and sent to the appropriate Adapter, which terminates and forwards the data to the IoT device. The addition of the HyperSec gateway adds encryption to the data on the network, while adding mobility to the solution. The Adapter is able to dynamically create the IPSec tunnel to the HyperSec gateway, reducing manual network management.

The HyperSec gateway is deployed as an active/standby pair. Each Adapter will be set up with primary/secondary tunnels. If the primary is not available, the Adapter will communicate over the secondary tunnel to the HyperSec gateway. The HyperSec cluster is headless. Configuration information is maintained in the Surge IoT Controller. This greatly simplifies scale-out clustering of the HyperSec gateway.

I will blog more about the HyperSec solution closer to availability. Keep in mind that you can get started with Avaya Surge on an IP network today and add IPSec when it becomes available. Also, it is not an all-or-nothing solution. Critical IoT components and services go through the HyperSec gateway and less critical and stationary workloads are deployed with IP and VLANs. Furthermore, SDN Fx fabric can be incrementally added to portions of the IoT portfolio to gain the value of hyper-segmentation, native stealth, and automatic elasticity.

Look at all of this through a different lens. I was talking to a friend, an intellectual property rights attorney, about the exposure that companies face from data breaches. It was one of those conversations where he wanted to know more about the technology and I was curious about his perspective as someone who makes money from a company’s problems. He was especially interested because legal firms are getting $500K to $2.5M for a simple breach defense. When looking at these numbers, I think that even if a company isn’t found culpable in a data breach, they could spend a lot of money in defense. So, it’s probably best to invest in the infrastructure to deploy IoT projects in a safe and sane manner.

In my recent blogs about the IoT, I’ve looked at how the IoT enables Digital Transformation and examined a business-first approach to IoT technology adoption. Then I looked at how Avaya’s SDN FxTM provides a foundation for a safe and sane IoT deployment. Finally, I introduced the Avaya Surge™ Solution, which extends network fabric to IoT devices and provides centralized device management, protection, and flow filtering.

Avaya Surge™ Solution Makes Securing the IoT Easy for All Devices

Let’s explore how you can manage thousands of IoT devices while protecting your network and data from unnecessary risk. Often, we think newer devices will be more secure than older ones that were network-enabled before the current threat profile. However, Gartner predicts devices will remain unsecured for quite some time. The Avaya Surge™ Solution makes securing the IoT easy for all devices.

Avaya Surge, recently named a 2017 Gold Edison Award winner, consists of an IoT controller and an Open Networking Adapter, which is a proxy for IoT endpoints and provides the programmable security for insecure devices.

Key Attributes of Avaya Surge

  • Automated onboarding of IoT devices
  • Inventory reporting, including real-time status
  • MAC-based device security
  • Traffic flow filtering
  • Tight integration with Avaya SDN Fx (but works with any IP network)
  • IPSec encryption and tunneling in release 2.0 (coming in the second half of 2017)

How Avaya Surge Works

  1. An Open Networking Adapter is paired with an IoT device on the IoT controller by matching the serial number of Adapter (or QR code) to the MAC address of the IoT device. The IoT Controller sees the Adapter/IoT device as an inseparable pair and manages the IoT device through the Adapter.
  2. The IoT device is connected to the Adapter which is connected to the edge switch (plug RJ45 connectors together).
  3. The Adapter uses DHCP and DNS to locate the IoT Controller. The Adapter negotiates security keys with the IoT Controller and the onboarding process begins.
  4. The IoT Controller looks up the profile identified for the device type connected to the Adapter and down loads it to the Adapter. The profile contains network configuration, service requirements and allowable flows.
  5. The IoT device establishes connection to its application server and the Adapter begins monitoring network traffic.

Key Operational Benefits of Avaya Surge

  • The Adapter doesn’t retain profile information through a power cycle. If an Adapter is disconnected from the network or loses power, data in memory is lost. When power is returned, the Adapter must connect to the IoT controller to get its profile to function. Avaya Surge will indicate the Adapter/IoT device has lost network connectivity. Without a valid registration, the Adapter does nothing. Network or profile information can’t be learned from a stolen Adapter.
  • The Adapter is based on white list security. When the Adapter boots, it doesn’t allow traffic from the IoT device. The profile provides a white list of approved devices and flows. For instance, if the only IP addresses that an IoT device is supposed to contact are its application server and network services (DHCP, DNS, etc.), the Adapter will block all other traffic. This prevents a compromised device from infecting its peers.
  • The Adapter has a learning mode. A profile can be complex to create. Therefore, the Adapter can be set to accept all traffic and mirror it to the IoT controller. The IoT device operates normally with Avaya Surge cataloging the traffic. This allows the IoT device to operate normally under the supervision of IT staff. When adequate time has passed (dependent on device operation), the captured traffic is converted to a reusable profile that becomes the standard for all like devices. The Adapter is taken out of learning mode, updated with the new profile, and a new device has been added to the network—safely and sanely. Under normal circumstances, the IoT Controller receives reports only from the Adapter and isn’t in the data path.
  • The profile stops MAC spoofing. If all the Adapter did was lock down a MAC address, an antagonist could disconnect the IoT device and connect a computer with the same MAC address. Technically, the Adapter will allow this to happen. However, as soon at the antagonist tries to do something that the IoT device isn’t normally allowed to do, the Adapter will block the traffic and report an abnormal flow attempt to the IoT Controller. One of the issues with IoT is many devices can’t be physically secured and are susceptible to tampering. Avaya Surge addresses this challenge.
  • The inventory addresses all use cases. IoT devices will be deployed within an organization across many use cases and application stacks. For example, a facility may have point-of-sale terminals: CCTV cameras, HVAC sensors and controls, security key pads and door controllers, medical devices, robots, assembly stations, and more. Each of these is deployed with its own application servers with device status monitoring and inventory management. Avaya Surge provides network IT with a single pane status for all IoT devices that are secured with Adapters within the infrastructure.
  • Avaya Surge supports device mobility. Devices can be automatically moved from one network port to another. The Adapter contains OVS 2.4 code, including support for Auto-attach (IEEE 802.1Qcj). Auto-attach provides the ability for the Adapter to signal Avaya Fabric Attach to create the required services on the edge switch, such as VLAN and ISID mapping. If a device needs to be moved, a technician would simply unplug the Adapter from the switch, move the device and Adapter to the new location, and plug the Adapter into the new port. When the Adapter is unplugged, the Adapter loses its profile and the SDN Fx network disables the services to the old port. When the Adapter is reconnected, it contacts the IoT Controller to get its profile and the OVS requests the services be provisioned on the new port. Within a couple of minutes, the IoT device is functioning in its new location and the move has been done safely, sanely and without Networking IT involved. Note that networking IT would have been notified when the Adapter was disconnected and reconnected through the Avaya Surge dashboard.

In my recent blogs about the IoT, I’ve looked at how the IoT enables Digital Transformation and examined a business-first approach to IoT technology adoption. Then I looked at how Avaya’s SDN FxTM provides a foundation for a safe and sane IoT deployment. Next in this blog series, I’ll explore deploying Avaya Surge in a non-SDN Fx IP network.

Secure IoT Deployments with Avaya SDN Fx™ Architecture Solutions

Let’s look at how to deploy the IoT in a safe and sane manner—a top-of-mind business challenge. Before diving into the technology, let’s remember why secure IoT deployments are so important. The Yahoo breach is a lesson learned: Yahoo CEO Marissa Mayer lost $12M in bonuses over the Yahoo data breach and Yahoo paid $16M to investigate the breach and cover legal expenses as of March 2, 1017. It’s clear that the cost of not building a safe infrastructure is much more than the cost to build one.

Software Defined Networking (SDN) is sometimes over-hyped. At a base level, separating the control plane from the data plane makes sense (if one understands the definitions of a data plane and control plane). In a practical sense, it means the network infrastructure doesn’t need to be managed on a node-by-node basis (i.e., logging into network devices on each end of the cable to make complementary changes to configure a network link). This is where SDN can be over-hyped. The SDN solution automates the process of making the changes to each end of the cable, making the network easier to manage. But, it doesn’t reduce the complexity, increase the resiliency (other than reduce outages due to typing errors), or make it easier to troubleshoot or expand.

Avaya SDN FxTM Architecture is based on fabric, not network technology. The architecture was designed to be managed as an entity of subcomponents and not a bunch of nodes that are interconnected to create a larger entity. In other words, it’s like designing something to manage a forest, as opposed to managing the trees. Would you really want to manage a forest one tree at a time?

How SDN Fx Architecture Benefits the IoT

Although the SDN Fx network architecture wasn’t specifically designed for the IoT, it works well for providing a solid foundation to deploy IoT solutions. These are the key components of the SDN Fx Architecture that benefit the IoT:

Avaya Fabric Connect is Avaya’s implementation of Shortest Path Bridging (SPB/IEEE 802.1aq). SPB replaces the traditional network stack, greatly simplifying network configuration, management and security. Three key benefits of Fabric Connect apply directly to IoT deployment use case:

  • Hyper-Segmentation: SPB supports 16 million+ network segments. In theory, every IoT device on a network could have its own segment. More realistically, every device type can have its own segment. For instance, HVAC could be one network, security cameras could be on another, employees on a third, guests on a fourth, etc. It’s worth noting that the NSA sees segmenting IoT networks as a key to limiting exposure of IoT deployments. (In my next blog, I’ll examine how Avaya solutions provide security between devices on the same segment.)
  • Automatic Elasticity: Services in SPB are provisioned at the edge without touching the core of the network. This makes it very straightforward to provision network services for the hundreds or thousands of IoT devices that the business wants up and running yesterday. Plus, edge provisioning makes moving devices simple. When a device is disconnected from the network, the network service to that port is disabled and eliminates open holes in the network security. When the device is connected to the same or different port, the device is authenticated and services are automatically configured for the port.
  • Native Stealth: SPB operates at the Ethernet, not the IP layer. For example, if a would-be hacker gains access to one segment of a traditional network, they can go IP-snooping to discover the network architecture. A traditional network is only as secure as the least secure segment/component. With Fabric Connect, if a security loophole is overlooked in a less important network project, there isn’t a back door to access the rest of the network and the corporate data.

Avaya Fabric Extend provides the ability to extend an SPB fabric across a non-fabric network, such as IP core, between campuses over Multiprotocol Label Switching (MPLS), or out to the cloud over WAN. IoT deployments enable the phased adoption of SDN Fx so that IoT projects can gain the values above, without ripping and replacing significant network infrastructure or affecting non-IoT workloads.

Avaya Fabric Attach automates the elasticity of the SPB fabric for IoT devices and other devices supporting Automatic Attachment (IEEE 802.1Qcj). Fabric Attach allows the device to signal the network that it needs in order to connect to a service. If the device is authorized, the service is automatically provisioned. When the device is disconnected, the service is terminated. If the device is moved to a different network port, the service will be provisioned automatically to the new port. This makes deploying and moving Fabric Attach-enabled devices very simple. For a real-world example, see how Axis Communications is starting to deploy Fabric Attach in their IoT devices.

Avaya Open Networking Adapters—an Open Network Adapter is a small device that sits in-line with an IoT device to provide programmable security for IoT devices that lack adequate network security. One component of the solution is Fabric Attach, which provides automated service provisioning and mobility to devices that don’t have the auto-attach capability. (I’ll explore more about the power of Open Networking Adapters in an upcoming blog.)

The Avaya Identity Engines Portfolio provides powerful tools for managing user and device access to a network, commonly referred to as Authentication, Authorization, and Accounting. In the IoT use case, Identity Engines authenticate a device by MAC address or MAC address group and use predefined policies for the device type to dynamically configure services. For instance, a camera could be assigned to Video VLAN 30 and provisioned for multicast, while a phone would be authenticated, assigned to VLAN 20, and configured for SIP communications. This provides security for unauthorized devices joining the network and provides automatic segmentation based on device type and service requirements.

I’m not sure if there ever was a time when network design and implementation was static, but there was a time when the devices connected to the network could be predicted: servers, printers, storage, PCs, etc. With IoT, IT is being asked to design networks for devices that haven’t been thought of yet. The old network technologies were designed for mobility by work order, and IT was able to list the number of device types that wouldn’t work on the network. SDN Fx provides a true software-defined network and not software-defined automation on old network constructs. A fabric network has the intrinsic flexibility and security required for tomorrow’s IoT projects, today.

In my recent blogs about the IoT, I’ve looked at how the IoT enables Digital Transformation and examined a business-first approach to IoT technology adoption. Next in this blog series, I’ll explore the newest component of the SDN Fx solution for the IoT, the Avaya Surge™ Solution.