Proactive Cloud IAM Security: 5 Critical Access Challenges

Challenge 1: External vendors and external trust. 

1. External vendors. Executives came back from a conference and informed the CloudOps team that the organization is going to have a new tool that solves important business problems. The contract between the company and the vendor was already signed, the wire was already sent and the product has to be deployed as soon as possible.  The vendor asks for admin permissions in cloud to provision their tool. If the permissions are not given to the vendor, then the vendor will report to the organization’s leadership that they are blocked by the CloudOps team. So the vendor is given the permissions. I think you’ve seen this a lot… That’s how we get stories like this in the news: “AT&T confirmed that call and text message records for nearly 110 million wireless customers were illegally downloaded from its workspace on the Snowflake cloud platform”. Then AT&T agreed to a $177 million class-action lawsuit settlement to compensate affected consumers and paid a separate $13 million FCC fine for a related cloud security failure. 
2. External trust is one of my favorite technical topics in protecting cloud IAM. The problem is that it is really easy to hide, but it is really difficult to find the external trust configuration in a massive cloud environment. It is not too hard to find and block an IAM service account key, but it is much harder to find the unauthorized external trust coded somewhere deep in an AWS role trust relationships policy or GCP service account impersonation. Not too many CNAP/CSPM tools will alert or report about newly created or existing external trust configurations. This trust can stay hidden in the environment for years until it is exploited by a former employee or hackers. I have interviewed many CloudOps, DevOps, SRE and other cloud engineers and when I ask them what is an external trust in cloud IAM and how it is organized in different cloud providers, fewer than 10% can accurately answer this question. Having a complete external trust inventory is a crucial thing for protecting cloud IAM from any external threat actors.

Challenge 2: Inventory management.

The other challenge in managing and protecting cloud IAM is the inventory management: how many identities does the organization have, how many of them are actively used and how many are not, how many service account keys exist, how many external trust configurations does the organization have, which external trust configuration is legit… These are just a few of the questions around cloud IAM security that have to be answered on a daily basis. Google cloud, for example, allows creating up to 10 keys for one service account. I saw in my practice that the developers were allowed to create the keys. What usually happened was: they created a key, lost it, then created a new one, then lost the new one, and on and on… The organization ended up having more than 1300 cloud service account keys. When we were cleaning up that organization’s IAM, we removed 700 keys without any damage to the infrastructure. Nowadays, to have up to date cloud IAM inventory the Cloud Operations engineers should not waste time reinventing the wheel by writing automated scripts that will collect the data from the cloud and put it into excel spreadsheets. From the other side, the cloud IAM inventory should not be collected only once a year during an audit. Existing tools allow collecting this data in almost realtime. Teriam, for example, shows the whole up to date cloud IAM inventory on one page in the Governance report.

Challenge 3: Audits.

Audits are stressful to CISOs and GRC from their side, but are seen as beneficial for the business side. An organization has to prepare for the audit: implementing tasks from backlog, making cleanups and remediations the team did not have time to make before, finding risky misconfigurations and vulnerabilities – all of these increase the level of security in the cloud infrastructure. If the cyber security team works on remediation constantly during the year, they can show the auditors progress – for this they need to compare what security posture the infrastructure had one year ago and what it has now. Teriam keeps all IAM resources risk scores and tracks remediation progress. It automatically tracks Identity Security Posture Management metrics that allows auditors to see the progress before and during the audit. Auditors also ask the questions about the Inventory. The team should be able to reply and show at the audit that the cloud IAM risk is low or is being reduced to an acceptable threshold.

Challenge 4: Incidents and incident response.

Cloud IAM is one of the most critical parts of infrastructure in the cloud. Common vulnerabilities include, but are not limited to: 

• Stolen IAM keys
• Forgotten external trust
• A compromised overprivileged identity
• A compromised vendor that has admin access to your cloud infrastructure
• A compromised compute resource that has federated admin access to the cloud
• A backdoor left by a former employee

We are not talking about the legal part of the question, just the technical. To implement reactive protection for breaches and security incidents, an organization has to have a SOC team onsite or buy a Managed Detection and Response (MDR) service. Some situations require both. The team should know the most common and sophisticated IAM attack paths and how to react to them. These are just a few examples:

• Compromised cloud compute instance
  • The attack: a compromised computer instance returns active cloud API access keys taken from the instance metadata to the attacker.
  • The detection: CNAP or NextGen SIEM alerts
  • Remediation: lock the compromised compute system, deactivate all past Cloud IAM access for the compromised identity, while keeping the identity active so the production system that is using it does not collapse.
• Unauthorized external trust
  • The attack: a cloud identity with high privileges has an unknown identity in its trust relationships policy
  • The detection: monitoring of all identities in the cloud and alerting if some new external trust appears 
  • Remediation: remove the trust from the identity. Find in the audit logs whose system added the trust and identify the root cause of the vulnerability
  • Comments: the external identity trust might be authorized, so it should be added to exceptions to avoid alert flooding.
• Escalation privileges
  • The attack: an identity that does not have admin access, but has permissions to grant admin access. The identity grants admin access to itself or another identity
  • The detection: CNAP and SIEM alerts
  • The remediation: reduce permissions for the identity. Investigate what was the root cause of the privileges escalation 

These are the two biggest challenges in the incident response process:

1. There are many systems, platforms, tools, and services that need to be monitored by the SOC team – cloud IAM detection and response can be overlooked if it is not prioritized correctly.
2. Understanding and defining enough possible attack paths to maintain adequate security and setting up priorities to address them. 

Incident response is a reactive measure. It is as important as the proactive measures – configuring Cloud IAM in a secure way from top to bottom, from the Organization level to the resource policies of each resource. There are thousands or tens of thousands of resources in a cloud environment. Without proper tools it is really hard for a human to see all of them: identities, permissions, privileges, misconfigurations, etc. Teriam evaluates the entire access path not only by one piece of infrastructure, but by combining access configuration at all levels. Only the combination of the right tooling, senior skillset, regular Cloud IAM tuning, access review cycles, and a well defined incident response program will provide sufficient level of Cloud Infrastructure protection in today’s AI realities.

Challenge 5: Insurance

Cybersecurity insurance is not a silver bullet that will cover any and all damages if an organization was hacked. The insurance provider will make it very difficult to be eligible for payment. They will: 

• require regular audit reports to show that the infrastructure is secured
• set high premiums or initiate policy cancellations when the customer does not satisfy requirements
• require detailed investigation after a breach 
• make the investigation as protracted and exhaustive as possible
• lower or deny payments if the infrastructure was not adequately protected before the incident
• find something else buried in your contract that the they will tell you about on the day you need their help

We can understand insurance providers’ positions too. If an organization does not invest enough funds and resources to protect its infrastructure thinking that any time they are hacked their losses would be covered, the insurance provider would be out of business. Insurance is the reactive thing, the last resort that works when well-implemented proactive infrastructure protection measures weren’t sufficient to avoid an incident. 

There is a balance between dollars spent on infrastructure protection and dollars spent on insurance. Today’s SOC2 audits do not always show the real picture and do not audit cloud IAM setups deeply enough. Relying just on the SOC2 audit results might not be sufficient to sleep well at night in industries where compromised infrastructure can cause billions of dollars in liability. Insurance companies understand this and highly scrutinize an organization’s security posture before making a decision whether to sell your organization a policy or not. Having detailed evidence about your cloud IAM risk score and posture puts you in a much better position to negotiate cyber insurance premiums. Teriam delivers these details about your cloud IAM setup, shows the remediation progress, and provides the precise cloud access risk report that cyber security insurance underwriters need to see.