Learning about SDP via Google BeyondCorp

I’ve been following Google’s BeyondCorp project for a while. In fact, I was recently quoted in a Wall Street Journal blog on this topic. 

If you are not familiar with BeyondCorp, it is Google’s spin on what’s become known as a software-defined perimeter (SDP). SDP, also called a “black cloud,” originated at the Defense Information Systems Agency (DISA) and is now being driven by the Cloud Security Alliance (CSA).  

Basically, SDP is a security architecture where all network connections are authenticated (using MFA and/or PKI) to establish a trust relationship between source and destination. As part of this process, the health of each endpoint is inspected to determine if it represents a risk due to some real-time condition (i.e. the endpoint hasn’t been patched, it contains a suspicious file, etc.). SDP also considers other factors as part of the authentication process—the type of endpoint device, the endpoint’s location, the time of day, etc.

Aside from authentication, SDP can also include access controls for authorization. In other words, who gets access to which assets. In this way, SDP can enforce the principle of least privilege, which can be used to limit access to sensitive applications and data.

Finally, SDP is based upon continuous monitoring of what’s on the network and what each device is doing on the network. It also correlates this connection data with new information about threats and vulnerabilities so it can make network access decisions based on changing risks. 

Google has certainly thrown some of its best and brightest at BeyondCorp, but this is not an exclusive esoteric project that is applicable only to the Googles of the world. In fact, enterprise organizations are quite interested in doing a similar type of SDP deployment. According to ESG research (note: I am an ESG employee):

• 49% of enterprise organizations want to require user and device authentication for network access controls.
• 43% of enterprise organizations want to maintain continuous monitoring of all devices connected to the network in order to detect or block suspicious behavior.
• 43% of enterprise organizations want to deny access to any endpoint device that is suspected to contain malware and/or does not conform to a configuration requirement.
• 40% of enterprise organizations want to use VLANs and other forms of network segmentation technologies to limit endpoint access and decrease the network attack surface.

Since large organizations are quite interested in the SDP model, it is worthwhile to read the Google BeyondCorp paper, as it describes several of Google’s challenges and lessons learned. Google readily admits that SDP depends on real-time and continuous data collection/analysis, so sparse data, out-of-date data or issues associated with data integrity can impact overall SDP effectiveness. Furthermore, any changes with network security must be communicated and accommodated in the SDP architecture.  Finally, SDP must be included into a disaster recovery planning.

Large organizations should keep an eye on Google’s BeyondCorp project so they can learn from this pioneering effort. Aside from Google, ESG has some additional SDP recommendations that may help:

1. Follow the SDP work out of CSA. 
2. SDP is closely aligned with previous work done with network access control (NAC). Vendors such as Aruba (HP), Bradford Networks, ForeScout and Pulse Secure play here.
3. Cisco offers a number of technologies, such as AMP, AnyConnect, pxGrid and TrustSec, that can be used as the foundation of an SDP architecture.
4. Endpoint profiling technologies from vendors such as Great Bay Software, Promisec and Tanium can help assess the health of endpoints before gaining network access.
5. Standards from the Trusted Computing Group (TCG) and FIDO Alliance can be used for endpoint authentication.
6. A start-up named Vidder offers a commercially available SDP architecture on its own.