It's easy to make mistakes and misconfigure settings in the cloud —  just ask Mark Ryland, director of the Office of the CISO at AWS.

When AWS customers create a principle for an application or workload that needs to call APIs, whether it’s an EC2 role or an IAM user, they need to limit the level of access and permissions allocated to that principle, Ryland said in an interview at Black Hat USA 2023.

All too often organizations are “not doing least-privilege work with their identities and their principles in the identity system,” he said. “That is to me the No. 1 thing I still see.”

This is especially common with software integrations. “The software only has a set of operations that it does, and it doesn’t need permissions for all the operations that it’s not doing,” Ryland said.

AWS dominates the public cloud infrastructure market, accounting for one-third of total spending during the three-month period ending June 30, according to Synergy Research Group.

Misconfigurations play a central and persistent role in cyber intrusions. Poor identity and access management is directly linked to more than 3 in 5 compromises in the cloud, according to Google Cloud research released earlier this month.

The openings these misconfigurations create for cyberattacks are avoidable.

There might be 25 operations that a piece of software executes as it runs. Software running on EC2 might need to download some configurations from S3 or trigger a backup from the relational database services.

“What you ought to do is limit the privileges of that software, the principle that software runs as, to those 25 operations and nothing else,” Ryland said.

This limits exposure and risk from the outset.

“That way, if the credentials leak somehow or you get hacked somehow and someone steals the credentials, then they can do those 25 things,” Ryland said.

“But they can’t change your IAM principles, they can’t add new principles, they can’t change the permissions on anything,” Ryland said. “All the kinds of more powerful operations, they have absolutely no power to do that with that stolen credential.”

Yet, some AWS customers, in a bid to save time and avoid broken integrations, will give full permissions to a piece of software from the start.

These unnecessarily expansive permissions present themselves as weak spots to attackers.

“The software gets hacked and now the bad guys have a very powerful credential,” Ryland said.

Cloud customers can determine where to limit access by looking back at the APIs a piece of software has called in the last 30 days. AWS can also generate an automatic policy that only permits necessary permissions, but that might not include a legitimate API call that occurred 31 days prior.

AWS might eventually build a feature to automatically lock down privileges based on past usage, but organizations would have to accept the risk of something breaking in the process, according to Ryland.

“We haven’t done that yet, but that’s an example where you have to kind of like move people along and think about what else can we do to make things easier for people,” Ryland said. “We’ve got to keep working on this.”

Disclosure: Black Hat and Cybersecurity Dive are both owned by Informa. Black Hat has no influence over Cybersecurity Dive’s coverage.