 |
The previous segment of this blog described some of the reasons for transforming from a perimeter driven model that uses VPNs/Firewalls to a device-centric, reverse-proxy based approach. As mentioned, the proposed new model is not yet an entirely paved road, and there are challenges. Here are some of them: Inventory data quality; Device identity: To get there, IT needs to build a clean meta-inventory of all devices. Included in this directory: Unique identification/state information for every managed device. This takes time; requires gradual device migration from the current design to the new one. Each of the device becomes managed, with unique identification (often finally, a signed certificate). Infrastructure needs to be implemented to ‘tag’ each managed device with a signed certificate and ensure the integrity of the issued certs. In other words, can you spell PKI? In addition, IAM solutions need to include support for device identities, not just user identities. Such solutions need to support reverse proxies to enable device identification and access control; A change that becomes even more important with IoT uptake: Managing the identity of “things” rather than users. Growing Reverse proxy management complexity: While reverse proxies are easier to manage than VPNs in small/medium networks, applying reverse proxies to very large environments and complex networks could end up with more or less the same complexities as VPN. And how about Virtual Networking? They allow creating virtual network segments, isolated from any other virtual network and physical network infrastructure; eliminating the need for defining a big chunk of rules & access conditions. Segments can span on-premise and cloud-hosted resources. Overall, it could be much simpler to manage than reverse proxies. Device data protection challenges: Key information stored on these trusted devices, especially those used for data encryption and device identification needs to be well protected. Devices that are not equipped with hardware root of trust are not as trust-worthy as those that include such capabilities. This results in (at least) 2 buckets of haves/have not’s, therefore 2 levels of trust, even for managed devices. Are all our communication devices trust-worthy? I recently wrote about this topic and concluded that while we’re not there yet, but we’re moving in that direction. User authentication, user credentials: A key requirement of the new model is user authentication. Devices are unlocked and apps communicate with services only after users authenticate themselves. Its critical for the user authentication to be strong (multi-factor) and for the credentials used during the authentication to be well protected. Ideally, as many companies have advocated, such as FIDO Alliance, user credentials should not be transmitted over the wire. Not all devices are ready for this model. Therefore, multi-factor authentication policies should go hand-in-hand with varying device capabilities, to establish dynamic authentication policies that depend on user roles, apps and devices. Applications are not all ready: Today’s reverse proxies are web traffic (http) focused. Thick clients applications that don’t use http for communication can’t take advantage of the new model. Good news: A majority of mobile apps use web-based RESTFul communication, but, as acknowledged by Google, this is not ubiquitous yet. Barring these challenges, the advantages of a device-centric approach are clear, and the transformation makes sense: We’re heading towards a firewall & VPN free world. I’d like to thank my colleagues Riaz Zolfonoon and Chris McLaren for their contribution to this blog series. The post Imagine no VPN, it isn’t hard if you try! (Part 2) appeared first on Speaking of Security - The RSA Blog and Podcast. |
