Non-Human Identity Explosion in the Public Cloud

Although many organizations have shifted to working from home during the current pandemic, many businesses still don’t realize that this transition requires a “retooling of their security strategy from the ground up. In particular, the explosion in the number of non-human identities in the public cloud is a risk that businesses simply can’t ignore.” Many companies, in fact, do not even have a concise plan in place to combat non-human identities.

Reacting appropriately to these non-human identities is exactly where many organizations can get into serious trouble. That being said, there are still many effective methods to safeguard their cloud environments against these kinds of attacks.

So what exactly are non-human identities? These are defined as those kinds of identities “that act on behalf of a person. They can be pieces of code, such as AWS Lambda functions, or pieces of computing, such as Azure VMs or other public cloud services. Regardless of how you define them, they are extremely useful and often represent the vast majority of identities found in cloud deployments.”

What many people don’t realize is that ensuring the safety of each and every identity--both human and non-human--is of the utmost importance. In the current cloud environment, the security perimeter consists of both human and non-human identities and as this is the case, requires an optimal degree of management and safety.

If we examine the particular challenges of this issue, the first obstacle at hand pertains to the aspect of complexity. Even for professionals well-versed in technology, it can be difficult to make concrete sense of the level of complexity and confusion surrounding these specific identities. This, in turn, often leads to “cloud misconfigurations, some of which can be absolutely critical.” It is not uncommon for typical cloud deployment to be comprised of hundreds or sometimes even thousands of the aforementioned non-human identities. The issue therein lies that from the perspective of management or a higher authority figure, this can incite an extremely difficult problem, which if not solved correctly, can arise in additional challenges such as “failure to comply with least privilege and/or separation of duties requirements as well as attesting to what, where and how they can manipulate an entire cloud environment.”

Furthermore, another critical obstacle, this time from a security perspective, is that the use of human and non-human identities--by nature--makes it very difficult to accurately confirm a chronological chain of events for “who exactly did what” and so forth. Taking this into account, for a “malicious actor, this is a great way to mask their identity and blend in with the cloud environment. Because of this, any way you look at them, non-human identities can take many forms which can be both extremely powerful and pose significant risks in the public cloud.”

There’s no question that breaches in data can be absolutely detrimental to the stability and overall success of a business and its consumers. However, many data breaches can at times be easily prevented with the proper implementation of effective security measures. If we analyze some of the biggest data breaches in recent years, along with assisting various consumers with their operations in the cloud environment, we can discover several consistent and unnecessary errors in judgment when it comes to non-human identities.

The primary mistake at hand pertains to “allowing overly permissive identities, where the instance, function, etc. have far too many permissions on its own as well as inheriting even more permissions as it is used within and/or across clouds. What started as a function that can do very little in its own account, it now has full admin privileges across the cloud. How does that happen? For reasons explained above, these identities and their usage can get quite complex, quite quickly and as a result, misconfigurations can commonly occur.”

A secondary reason is that time and time again, these identities seem to be almost intentionally over-privileged. What this means in the scope of this specific cybersecurity obstacle is that far too many times, DevOps teams are simply demanded to work a particular task immediately or to “go back and fix it later.” The underlying concern here is that this approach leads employees to “do what is asked of them and give the identity the wide-open privilege...the crisis is managed, the business is happy, life goes back to normal and the DevOps team goes onto the next task; never to return to fix it later.” This then leads to the common error of “lost identities”, a term referring to those identities that have been “either been created or modified and then forgotten. They just sit there in the cloud environment, still very much alive but with nothing to do. That is until someone finds it and decides to use it, which leads to the next mistake.”

The third mistake that is all too familiar is the use of these identities for unintended or intentional purposes. Simply put, the naive assumption of “it made that thing work, so I’ll use it for this thing as well.” Although this may be partially true, this approach also sets a dangerous precedent that can be costly in the future. Perhaps this leads to the unintentional disclosure of data, granting access to data, or otherwise revealing sensitive or private information. Taking these common errors into consideration, it is pivotal to learn from these major data breaches, learn from these mistakes, and do everything possible to make sure o that your organization’s non-human identities are safely protected and managed accordingly.