Adapt to the Cloud Operating Model Part 3: Taking the DevSecOps Journey

This is the third and final blog post in our Adapt to the Cloud Operating Model series. 

With any organisational change that impacts people, process, and technology, it’s best to take it in stride. When talking with customers about their Zero Trust security initiatives, an analogy I often use is: “if Google’s BeyondCorp is the peak of Mt. Everest, let’s get you to Base Camp first.” The reasoning being, if you don’t set the right foundation and get the basic security posture elements lined up first, you won’t make it to the top. 

The same analogy applies to adopting cloud infrastructure. Whether you’re migrating existing workloads to the cloud, or deploying net new workloads, if not tackled early on, the challenges around speed, scale, and complexity will invariably rear their ugly head. We concluded our previous post on this topic with an adaptation of the DevSecOps mantra, Shift Identity Left making identity and access part of your automation—not an afterthought. Read on as I show how to put that into practice via an achievable sequence of actions.

What needs to change

The running theme of this blog series is this: traditional methods of security and operations do not translate to the cloud because of the dynamic nature of the environments. This is especially true where elastic resources are constantly spinning up and down. To meet the demands of speed, everything must be automated. To secure automation, controls must be placed early and often. 

That sounds feasible on the surface; however, in order to effectively adhere to the principles of least privilege, there are properties of traditional operational methods that need to be addressed. With regards to identity and access management, the following are anti-patterns to the Cloud Operating Model:

• Static credentials: As resources spin up and down, and as users join, move, and leave, static credentials pose a significant risk of sprawl. They’re not well attributed to users and, in themselves, carry too many inherent privileges. 
• Shared accounts: Accounts that are not directly attributed to a user are difficult to control and audit, leaving additional steps to assume the account. This practice adds more complexity to your security policies, and makes it harder to ensure adherence. 
• Unlinked local accounts: Systems that have local accounts with no ties back to the system of record are near impossible to control, and do not scale. The risk of these types of accounts laying around is significant, and also the fastest way to fail an audit.
• Intermediary directory services: The common practice of placing a directory service like LDAP in front of your systems to broker identities breaks down with elastic scale resources. These services quickly become performance bottlenecks. Intermediary directory services are distributed systems in themselves, requiring a lot of operational overhead to maintain, often leading to synchronisation issues.

In order to avoid the pitfalls of legacy operations that lead to issues of drift and sprawl, a strong identity foundation leads the way to enabling secure velocity, at scale. A modern approach to identity and access management is as follows:

• Just-in-time credentials: dynamic systems need dynamic credentials to match. A more effective mechanism to ensure least privilege access is to only mint short-lived, tightly scoped credentials, on-demand wherever possible. Not all systems support this mechanism, however, so the alternative is to secure secrets in a vaulting service that handles rotation and checkout in a just-in-time manner.
• User accounts: people are dynamic too; they come and go and their jobs can change. The only way to keep up with all joiner, mover, and leaver scenarios is to make all of your security policies identity-centric, with permissions tightly tied to roles and attributes. Your policies will be easier to manage with greater assurances towards adherence.
• Automated lifecycle management: the only way to keep up with automated systems is to automate identity. With a strong directory service as the foundation, user accounts and policies automatically propagate across all downstream resources, with any changes to user status or group membership being reflected almost instantly. 

A DevSecOps Identity Maturity Curve

With an understanding of what needs to change, let’s look at that stride through the lens of a maturity curve, with Okta as the unified Identity foundation, serving the journey from end-to-end. And, while the following is meant as a guide to adapting to a Cloud Operating Model, it need not be a prescriptive step-by-step process. I like to use this visualisation to illustrate areas of change and coverage.

• Phase 1: Sprawl Control – In order to control sprawl, you must first know where everything is. A great starting exercise is to take inventory of all the accounts and credentials being used to access sensitive resources. Any use of static credentials should be replaced with just-in-time credentials or secured in a vault at a minimum. When credential sprawl is under control, baseline access controls can be effectively placed between users and resources.
• Phase 2: Injected Identity – With a baseline in place, start building out your identity automation. This means injecting account provisioning into your Infrastructure as Code automation. And because these are highly privileged activities, it’s best to add additional controls to access in the form of multi-factor authentication and authorisation steps.
• Phase 3: Lifecycle Automation – A natural byproduct of injected identity is the ability to automate the end-to-end lifecycle of administrative accounts and policies. In practice, this means being able to adapt to any joiner, mover, or leaver scenario in near real-time, and getting more fine-grained with your authorisation controls. Another element to consider here, as an extension of removing static credentials, is to incorporate the minting of just-in-time credentials, wherever possible. And it’s worth calling out that dynamic PKI services are not trivial to build by any means.. Thankfully, this is something that Okta can fully abstract with Advanced Server Access. For a deep dive into our backing PKI architecture, read this blog post, SSH is Dead. Long Live SSH: One Million SSH Logins with Okta. Zero SSH Keys.
• Phase 4: Adaptive Infrastructure – It’s perfectly reasonable to stop at Phase 3. Your auditors will be more than pleased, and your team will never be happier. But to really get to the peak of Mt. Everest, you can do a few more things to further control least privilege access and manage sessions. Additionally, across CI/CD pipelines, there will be service accounts performing privileged tasks. Here you can take the properties of the prior steps for human users and apply them to service users. The key difference is that service users authenticate differently than humans, which requires a different interaction point. These are the advanced use cases Okta can help you achieve to plant your flag at the peak of Mt. Everest!

Okta as Your DevSecOps Identity Partner

As the leader in identity for the cloud, Okta provides the right foundation to adapt to the Cloud Operating Model. Universal Directory is the source of truth for users, their attributes, and their roles so you can effectively manage security policies. And with Lifecycle Management, you can automate provisioning and deprovisioning workflows to handle all joiner, mover, leaver scenarios. 

Okta also provides “last mile” capabilities across key areas of cloud infrastructure. Advanced Server Access is purpose-built to further automate the lifecycle of local Linux and Windows accounts and policies, also extending seamless Single Sign-On and Multi-factor Authentication to SSH & RDP workflows.

Interested in learning how Okta can help accelerate your journey to the Cloud Operating Model? Request a demo here, and we’ll bring in one of our cloud specialists to review your environments and deliver personalized recommendations.