Our introductory blog on PaaS adoption in financial services outlined six core challenges facing institutions. This follow-up by Citihub Consulting’s CTO Brett Aukburg examines one of those challenges in more detail – identity management.
The adoption of PaaS services increases the need for organizations to update their security from classic, location-based boundary models to modern, identity-based segmentation models. We will describe these two security models in this blog and some of the current tooling which can assist with the implementation of an identity-based model.
Over the past two decades, the networks of large organizations have grown to include managed and unmanaged mobile devices, connections from semi-trusted and untrusted networks, contingent labour on and off premise, and more recently, public cloud PaaS services with limited network controls.
As my colleague, Jim Oulton, mentioned in an earlier part of this series, maintaining a secure network boundary when adopting PaaS services presents a number of challenges. To many, the traditional concept of a network boundary with a very clear “outside” and “inside” is an anachronism. It has been replaced by highly segmented networks in which each segment has a distinct security classification and associated methods of access.
As organizations shift from having a relatively finite boundary to something that is more like an onion or perhaps a bushel of onions, the complexity of securing the network mesh increases exponentially relative to the volume of segmentation. The ongoing challenge faced by organizations is how to distinguish between access which should be granted and access that should not be allowed. Core to solving this challenge is identity.
Identity is deceptive in its complexity. Per Merriam-Webster, it is “the condition of being the same as something described or asserted.” When we talk about electronic communications, how is identity asserted, attested, verified, and maintained? How is delegation enabled and controlled? How is forgery and impersonation detected and prevented?
Security Model – Castle to Hotel
“The perimeter security model is often compared to a medieval castle: a fortress with thick walls, surrounded by a moat, with a heavily guarded single point of entry and exit. Anything located outside the wall is considered dangerous, while anything located inside the wall is trusted. Anyone who makes it past the drawbridge has ready access to the resources of the castle.” As Google’s BeyondCorp articles explain, the modern mobile workforce reduces the viability of the castle model. For such a simple model, a similarly simple identity model can be employed. If you are known and trusted, you may enter the castle. If you are unknown or known and untrusted, you are forbidden from entry.
A more current security model might be compared with a hotel. The perimeter security for a hotel is required to be porous. A subset of services such as restaurants, bars, or even a casino are meant to service both hotel guests and the public. Prior to being identified, even unregistered guests are allowed free entry into the lobby for comfort and convenience. However, once inside, we discover a highly compartmentalized security architecture in which identity is the key. As part of the check-in process, guests will be authenticated by presenting identity tokens (e.g. passport, driver’s licence, credit card) previously issued by external agencies. The process of local authentication by verification of standardized identity tokens issued by a central authority is analogous to OpenID Connect (OIDC). Once authenticated, the guest’s reservation is used to provide a temporary key (i.e. hotel key card) which will authorize them to access specific rooms and services within the hotel. The hotel key card is analogous to OAuth. Following a similar process, service personnel within the hotel are issued keys with broader access rights. Regardless, every key is restricted to accessing the appropriate portions of the hotel and every key use is captured and logged. Inappropriate or questionable use of a key can result in its immediate expiration and require the holder to revisit the issuer to be reauthorized.
The hotel model is an analogy for a “zero trust network.” This model does not assume that users or applications should be trusted simply because they originate within a security perimeter. Rather than location being a primary consideration for trust, it becomes one of many components considered during authentication to determine how much authorization to provide.
Authentication – Not all are equal
The greater complexity of a zero-trust network demands similar changes to authentication and authorization processes. As the first step in the authentication process, attestation and its associated level of trust, are perhaps the most important to get right.
In the castle model, attestation was frequently kept simple. Users, systems, and applications provided a name and a password. Users’ passwords had complexity and management requirements while system passwords often remained stagnant. A successful attestation from within the security boundary resulted in a full trust authentication. The user or application was subsequently authorized to communicate broadly across the internal network and to access any resources associated with that identity.
The hotel model is, in part, an acknowledgement that the attack surface following authentication was simply too great. A modern enterprise evaluates more factors. Whether a person or application, the multifactor authentication requires some combination of “something you know,” “something you have,” and “something you are” for attestation. A successful, multifactor attestation is combined with additional factors such as originating device and network to determine the level of authorization. Only with a successful attestation and all additional factors being positive is full authorization provided. Even then, full authorization limits an identity to traversing the segments of the network necessary to access the allowed resources. Per the hotel analogy, one is only allowed to take the elevator to the floors on which one’s authorized rooms are located.
Application attestation works similarly to that for people but autonomic applications (i.e. processes) can be a greater threat. Once again leveraging the hotel analogy, think of cleaning services as such a process. Members of this service will require access to almost every room in the hotel. To protect against potential exploitation, process attestation must be held to an extremely high bar. For each process, “something to have” will generally be a certificate or pre-shared key that is rotated with some frequency. “Something to know” might be embedded in compiled code and take the form of hashes embedded in all inter-process calls. In a highly virtualized and containerized world, “something to be” will be fulfilled by a combination of attributes like process name, instantiation time, and assorted checksums. This combination serves as a sort of “birth certificate” issued by a central manager and stored in some secure repository. Limiting access and requiring frequent re-attestation further secures this scenario like granting maid service a key that only works for five or ten rooms and requiring them to return to the front desk between each set. The major cloud service providers (CSPs) each have a mechanism by which a VM or a managed container can attest its own identity by retrieving its “birth certificate” from the CSP.
Stay current on your favourite topics
The Secure Production Identity Framework For Everyone or SPIFFE is an open source standard for securely identifying software. It is becoming the de facto standard for software identity management and has been adopted by the Cloud Native Computing Foundation (CNCF). SPIRE, the SPIFFE Runtime Environment, is another open source implementation which simplifies adopting the SPIFFE standard. Istio, a popular open source solution, also follows the SPIFFE standard and includes micro-segmentation capabilities.
Implementations like SPIRE and Istio are excellent solutions regardless if public cloud is part of an organization’s environment. They also work well used in conjunction with the native models from each CSP. The CSP identity models are evolving quickly but their current solutions tend to focus on the identity of the cloud resource (e.g. vm or container), rather than the actual process running on that resource, which is the level at which SPIFFE operates. And, while the CSPs all provide excellent security tools for securing resources, the security achieved depends on the quality of a customer’s use of the CSP’s tools. A flawed implementation can lead to a hijacked resource and a single hijacked resource that is overly trusted can lead to catastrophe. By enforcing identity at the process level, an organization can dramatically limit the damage that a hijacked resource can cause. SPIFFE compliant solutions can verify the resource, by leveraging a CSP’s resource identification, and the process running on that resource using customer defined attributes.
As organizations adopt a heterogenous set of public cloud services from multiple cloud providers managing security via network boundary controls becomes exponentially more challenging. As a result, organizations are realizing that finer-grained access policies combined with robust authentication and authorization is a stronger security model than one which relies primarily on network boundaries.
Managing identity and access control is complex. However, with a robust multi-factor attestation process, organizations can have a high degree of confidence that authenticated identities for both humans and systems are genuine. Different levels of trust in the identity can be established through point-in-time attributes – such as source network or geolocation. This trust level can be used to authorize the resources the requestor is allowed access to, limiting the damage of successful resource or identity hijack.
Layering process-level authorization on top of the resource-level authorization provided by Cloud Service Providers provides further protection from exploits in the Provider’s platform.