The Software-Defined Perimeter, Identity Management, and…Orcs?
Awareness and adoption of the Software-Defined Perimeter (SDP), a specification from the Cloud Security Alliance (CSA), is growing. It’s been referenced in recent articles and industry conferences, and is clearly an up-and-coming market segment.
We’re seeing (and helping to lead) a great deal of activity within the CSA. Not only is there work applying the SDP to Infrastructure-as-a-Service (IaaS) environments, the group has kicked off a project to create version two of the SDP specification.
If you’re new to the Software-Defined Perimeter and would like an overview, take a look at our recent blog posting on the topic.
Analysts have also been writing about the SDP — recently, ESG analyst John Olksik wrote about the Software-Defined Perimeter, explaining why it should be considered:
“…a combination of mobile device and cloud use renders existing network perimeters obsolete, so security policy enforcement decisions must be driven by identity attributes (i.e., user identity, role, device identity, location, etc.) rather than IP packet attributes. We see this transition coming to fruition with the concept of a software-defined perimeter (SDP) where smarter network access decisions can be made based on identity attributes.”
Essentially, SDP moves beyond traditional security solutions, which are struggling to keep up with today’s threats, to introduce an innovative way to ensure network security. However, as organizations look to embrace and deploy the SDP, there are a few challenges.
Mind the Gap
Specifically, there’s very often a gap, or at least a misalignment between Identity Management and Security. Olksik’s article talks about a misalignment between enterprises’ goals and investments, making a case for why increased investment in Identity and Access Management (IAM) is necessary, if the benefits of SDP are to be realized. We support the argument that IAM programs are often underappreciated and under-resourced!
But, we also firmly believe that incremental adoption is necessary for any technology to be commercially successful, and that SDP is no exception. In fact, because SDP is a network security technology, it’s doubly important that organizations be able to incrementally deploy this to a small set of users, systems, or services. Let’s explore how SDP can be incrementally deployed and connected to IAM systems.
SDP & IAM: a Complementary Relationship
Enterprise IAM programs put a lot of effort into creating and maintaining role-based access control (RBAC) and attribute-based access control (ABAC) for secure access. These programs are a lot of work for organizations. Unfortunately these programs typically rely solely on application authentication to control access, while network access is controlled by separate, disconnected systems. This represents a significant security risk, as many application or infrastructure vulnerabilities only require network access to exploit. For example, Onapsis recently published a report on a critical vulnerability in SAP HANA:
“a remote attacker can execute arbitrary operating systems commands with high-privileges and/or create SAP administration users, simply using a web browser and without the need to initially have a valid SAP user id and password in the target system.”
Given vulnerabilities such as this, preventing unauthorized users from accessing business-critical applications must be a security goal.
A Software-Defined Perimeter solution accomplishes this, embracing the need for user-centric security, and incorporating roles and attributes into access decisions – just like how well-run IAM systems do this. And SDP extends this to enforce this access control at the network level helping to eliminate the security risk of only relying on application authentication to control access.
Cryptzone’s Software-Defined Perimeter Solution
Our customers are using our SDP product, AppGate, to gain the benefits of network security that is aligned with their IAM solutions.
One interesting and relatively simple way to do this is to tie together an organization’s authentication system, using an industry standard mechanism such as Security Assertion Markup Language (SAML), with its SDP-based network access control. Specifically, the SDP system can consume SAML assertions as a trusted form of authentication for users, and grant corresponding network access. By doing so, security teams can begin to bridge the gap between identity and network security, while delivering a consistent and business user-friendly experience.
In another article in Network World, John Oltsik offers perhaps a cautionary endorsement of SDP:
I’m a big fan of SDP. It clearly represents the culmination of a number of IT initiatives and will likely anchor enterprise network connections in the years to come. Those organizations that move forward with SDP must do so with eyes wide open—it may involve an IT-based Lord of the Rings-like journey to get there.
John has deliberately taken a slightly broader view of SDP, encompassing more technologies and architectures than we have within the CSA Software-Defined Perimeter working group, which is presumably influencing his caution about an arduous journey.
From our perspective as a vendor, with an enterprise-ready product, we’re seeing customers able to deploy our commercial SDP offering quickly and incrementally, with many customers going into production in fewer than four weeks. And, to date, there have been no reports of Orcs!
Learn more about how a Software-Defined Perimeter can help you secure your network resources.