The Non-Human Entities that Plague the Cloud
Entities that make cloud services work together also pose a security risk. Here are four worth considering
At the average-sized company today, employees use hundreds of different cloud services. All of these apps integrate with each other using APIs, roles and privilege delegation to make workflows in the cloud as intuitive and efficient as possible. In the process, sharing and exposing data becomes simple. That is why SecOps usually focuses on human users who expose data either accidentally or intentionally, and can have their identities stolen as a result.
But there are many “non-human” entities such as roles that act in the background to make these integrations possible and usually go unnoticed. Here are four of the top roles that should always be monitored closely in your cloud environments.
SaaS Roles
One of the best features of the cloud is how simple it is to integrate between different services. This allows for the creation of an ideal environment for efficient workflows in every department of any company with minimal to no effort from IT. Generally, apps integrate with each other using service accounts, which differ from human user accounts in the way they interact with the cloud service. Service accounts use APIs rather than web interfaces and access information based on the context of another user, assuming its role. They authenticate as a byproduct of user login or even bypass authentication completely using a token. These are the most common non-human entities in cloud networks. Small popular apps are one of the top targets for attacks and should be closely monitored.
A hacker can try to compromise one cloud application to steal passwords that may have been reused in other services or to hop to a different application by using existing integrations. In 2018, for example, Evernote, a note collaboration platform, was hacked and sent phishing emails requesting passwords from users, and in 2015, LastPass, a company that stores passwords, was hacked, exposing users’ passwords.
Security Automation Roles
A few notable types of SaaS roles do security automation including IDaaS, CASB and SIEM.
Think of IDaaS as your cloud’s border control. It may have only a small amount of permissions in each of your cloud apps, but if you want to manage groups and roles in your IDaaS, you must provide it with permissions to create users and assign policies to them. When hacked, the IDaaS can create privileged entities that can act as a backdoor to your cloud infrastructure. This became a notable concern when OneLogin was hacked in 2017 and potentially jeopardized thousands of companies’ security.
CASB functions as your cloud’s security line. It inspects every packet and API call before it reaches your cloud, protecting it against strange API calls. CASB also provides rollback support in the event of an attack. Being a proxy, the CASB has its own token allowing it to perform many administrative API calls on your cloud services.
Both IDaaS and CASB are strong non-human entities in your network. They mask the initial actor that performed API calls in your logs but make fewer mistakes than a human user. But if they go rogue, it will be very difficult to track down how an attack happened.
Another virtually invisible non-human entity with access to administrative data is a SIEM, which reads and stores logs from your cloud. SIEM performs the same functions around metadata about all the activity in your network and should be well guarded at all times.
PaaS Roles
PaaS roles make all of your cloud API calls possible. They function like gears that keep your infrastructure going, carrying event-driven tasks without requiring you to build the whole platform behind them on a machine or cluster, introducing the concept of “serverless applications.” They are assigned a user or role in your cloud and typically perform in some mutual context with a virtual machine or human. These entities are monitored less frequently than humans or machines, which can be a costly mistake because they perform sensitive tasks such as deleting data, providing permissions, sending emails and accessing secrets. In 2017, for example, a security bounty hunter gained access to 14% of NPM packages that were protected by weak passwords. It would be very easy to push a line of code into a package that is used by an AWS Lambda function to send the Lambda role’s temporary AWS credentials to a remote server, which could try to use them to list buckets and download all their contents. You can see how easily data is exposed by compromising an AWS Lambda role yourself in the flaws2 challenge provided by Scott Piper.
IaaS Roles
Everything in the cloud, including your machines, is an entity, but machines, unlike humans, are always logged in. When machines need to access data from the cloud, whether it is on an external database service, a source code versioning software, or a storage platform, they are assigned an entity that they can use to access cloud APIs using API keys or magic IP addresses. It will usually be difficult to understand why a machine performed some activity at a given time, but since all activities will be from the same source, it will be easy to identify a remote compromise of its entity. Even though machines are sometimes accessible directly from the internet, making them a popular target for cloud attacks, they still receive much less attention than human users.
Conclusion
Your security & IT team should be aware of all the entities in your cloud network (human and non-human), what permissions they have and use and the threats they pose, as well as how to identify them. We strongly recommend more emphasis from both the IT community and cloud service providers on this topic in the future.
