There's nothing more frustrating than not having the right tool for an otherwise simple job. Anybody who's ever...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
tried loosening a screw with a knife, making hasty repairs with duct tape or picking their teeth with a business card knows what I'm talking about. It's said that "any job is easy with the right tool," and the converse is also true.
In the past, cloud technologies, while both powerful and versatile, have had challenges in certain applications. There are situations where -- contrary to what we might want from a technology or cost-control perspective -- using cloud is less than optimal.
One area where this has historically been the case is internal "air-gapped" networks. This means private, closed networks that, due to security, compliance or operational reasons, need to stay isolated from the outside world. Examples of this are legion, but might include healthcare clinical networks, industrial control networks, broadcast networks (for example, at a media company), retail payment networks, and numerous other industry- and business-specific situations.
In cases like these, keeping internal resources inaccessible from the Internet, general purpose employee networks or partner extranets is beneficial. In fact, to minimize the attack surface for those networks, even metadata -- for example, addresses of hosts, services running on those hosts or who uses them -- could be advantageous to keep concealed.
However, cloud -- even private cloud -- can make meeting these goals more challenging.
In a traditional network architecture, the situation is fairly straightforward: A static perimeter is employed to keep these resources insulated. But what about when the underlying network is outside an organization's scope of control? Or when the segmented zone needs to span both the enterprise environment and infrastructure hosted at an infrastructure as a service (IaaS) or platform as a service provider? Or when users outside that network (for example, those on a mobile device or using a remote desktop) need to gain access?
Yes, technologies exist to address these situations under a traditional perimeter model. But because it can become very complicated very quickly, maintaining those products can be effort-intensive, potentially costly and time-consuming.
The logical perimeter
This is the backdrop against which the software-defined perimeter (SDP) has come about.
SDP is a protocol published by the Cloud Security Alliance (CSA) that allows the creation of (from the 1.0 specification) "on-demand, dynamically provisioned, air-gapped networks." It's a relatively recent effort; the initiative itself was launched in December 2013, the 1.0 specification was released in April 2014, and the protocol was publically showcased during a "hackathon" during the CSA Congress in September 2014.
What is a "dynamically provisioned air gap"? It's a segmentation of network resources that mirrors in many respects a physically defined network perimeter, but operates in software rather than via an appliance. This allows the owner of a particular resource to create a logical boundary around those resources to enforce similar security properties as those found within a traditional physical network boundary.
Much like a traditional perimeter, access to and information about the network resources is provided only to those requesters that are trusted. However, unlike a traditional perimeter where the distinction of trusted or untrusted is made on the basis of location on the network, the distinction is instead enforced via the protocol itself. This in turn means that devices can be "inside" the perimeter from anywhere, including on a mobile phone over a cellular network, on an internal network, at an IaaS provider or at a business partner's facility.
The SDP boundary is enforced through several means, including:
- Mutual authentication of sessions (TLS or IKE with mutual auth)
- Transport-layer cryptographic protections (e.g., TLS)
- Device identification
- Single packet authorization (port knocking)
SDP controllers (the "server" side of the connection that clients connect to) can utilize one of a number of possible authentication and authorization mechanisms (e.g., SAML, LDAP, geolocation, etc.) to ensure that only authorized devices and users can gain access to the virtual perimeter. To the outside world (i.e., outside the logical perimeter), information about the network is likewise concealed.
Planning for SDP in the enterprise
If you're a security pro and the above sounds appealing to you, your next question is likely to be, "How do I use it in my environment?"
Though there are vendors offering SDP-based services and the CSA has announced that it intends to distribute an SDP implementation as open source, the relatively recent nature of the protocol means the number of deployments currently are few. As cloud service providers start to integrate the protocol into their software as a service and IaaS offerings -- and as network/host product vendors start to integrate the protocol into platforms they ship -- the use of SDP will likely increase.
In the meantime, though, if SDP functionality has appeal, there are some things organizations can do to prepare to make use of the protocol once it becomes more ubiquitous.
First and foremost, enterprises can explicitly discuss support of the functionality with their cloud services providers to understand if and when they intend to integrate support of the protocol into their service offerings. A direct inquiry of this type will allow security pros to keep an eye on their provider's timetable and help organizations align internal plans with the providers they use. For smaller providers (or larger ones that might be slower on the uptake in regard to security matters), asking the question can help get the wheels turning for integration into the product roadmap sooner than would otherwise be the case.
Thinking long-term, it's also helpful to start laying the architectural foundation for integration by making a list of existing "perimeters" (i.e., network zones) that are already in use -- in other words, inventory where SDP could be leveraged. For example, is there an air-gapped network internally already? Does it overlap or extend into the cloud (for example, to support bursting or a data center virtualization effort into an IaaS)? Does the organization have users that require access into those networks from mobile devices or devices that might otherwise be outside that perimeter? These are all important pieces of information that will inform an organization of potential SDP use.
Interest in the software-defined perimeter is likely to only increase in the future. If, like most, your organization doesn't have all this information at its fingertips currently, now is a good time to start collecting it.
About the author:
Ed Moyle is the director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at Computer Task Group. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.
Learn more about the CSA's software-defined perimeter
View a Q&A with CSA CEO Jim Reavis