Software-defined perimeter security for cloud-based infrastructures

A hackathon is a generic industry term used to describe online or in-person events where people work collaboratively on software development. They don’t always yield perfect solutions, but they often result in major advances on tough problems.

They’re also proving vital to development of security products. The Cloud Security Alliance (CSA) has used them for several years to prove the reliability of various proposals for software-defined perimeter security for cloud-based infrastructures. So far, that SDP security has been impregnable.

Earlier this year, in the fourth hackathon of the series, the CSA together with Verizon and security solutions company Vidder, tested the viability of cloud-based high availability infrastructure using an SDP front end to provide the access between various compute resources located across multiple public clouds.

First off, the event proved a cloud-based, high-availability infrastructure can be produced much quicker and for considerably less money than the equivalent hardware-based version. It also proved SDP is a solid security solution. Offering a $10,000 reward, CSA and its partners invited hackers around the world to try and break the SDP security. Despite some “highly sophisticated” attempts from the 191 identified participants who generated millions of attacks, it stood firm.

An additional demo was also included to showcase SDP’s capabilities for the U.S. government sector, where security requirements are more stringent than those for more general users of the infrastructure. A cloud-based flight management system for unmanned aerial vehicles was placed on the same network as CSA’s hackathon. Although the network was under constant attack, the UAV application was not disrupted.

SDP is an attractive solution for cloud security because it doesn’t require much new investment. It basically combines the existing device authentication, identity-based access and dynamically provisioned connectivity that most organizations should have in place under a software overlay. The CSA said the SDP model has been shown to stop all forms of network attacks, including distributed denial of service (DDoS), man-in-the-middle, SQL injection and advanced persistent threat.

Given the cost and resource constraints government is under, agencies see potential in SDP and have already launched various initiatives involving SDP security. Late last year, for example, the Department of Homeland Security selected Waverley Labs to develop the first open source SDP to defend against large and sophisticated DDoS attacks.

The CSA, together with Waverley Labs, has been working for a year on developing open source code for SDP, with the intent of getting information security and network providers to deploy SDP widely for cloud solutions. The goal is to take the inherently open approach of the internet — a liability for security in the age of an Internet of Things — and essentially make parts of it dark. In these appropriately named “Dark Clouds,” only those connections that can be definitely authenticated will be allowed.

None of the technologies used for SDP are new, and all of the concepts — such as as geolocation and federation used for connectivity — are well understood. However, most of the SDP implementations up to now have been highly customized and proprietary and designed for an organization’s specific needs. The push behind the CSA program is to develop a more general approach to SDP that can be readily applied across all organizations.

The CSA’s SDP Working Group has launched several use case initiatives, including the open-source DDoS effort and, more directly aimed at government, one that will use SDP to enable virtualized security for cloud infrastructures that complies with the “moderate” level described in the Federal Information Security Management Act. The latest initiative targets SDP that can be deployed for infrastructure as a service.

For anyone looking for examples of what it takes to erect an enterprise SDP infrastructure, Google has detailed the approach it used for its BeyondCorp initiative, which defines how employees and devices across Google access internal applications and data. With SDP, the company said, BeyondCorp essentially sees both internal and external networks as untrusted and allows access by dynamically asserting and enforcing various tiers of access.

As for CSA, the SDP Working Group hopes to get its analysis of what’s required for SDP security for those use cases, along with architectural and deployment guidelines, published in the next year or two.