Netskope named a Leader in the 2022 Gartner® Magic Quadrant™ for Security Service Edge. Get the Report.

  • Plateforme

    Une visibilité inégalée et une protection des données et des menaces en temps réel sur le plus grand cloud privé de sécurité au monde.

  • Produits

    Les produits Netskope sont conçus sur Netskope Security Cloud.

Netskope offre une solution moderne de sécurité du cloud, dotée de fonctions unifiées en matière de protection des données et de détection des menaces, et d'un accès privé sécurisé.

Découvrir notre plateforme

Netskope reconnu comme un des leaders dans le rapport du Magic Quadrant™ 2022 du Gartner dédié au SSE

Recevoir le rapport

Optez pour les meilleurs services de sécurité cloud du marché, avec un temps de latence minimum et une fiabilité élevée.

Plus d'informations

Neutralisez les menaces qui échappent souvent à d'autres solutions de sécurité à l'aide d'un framework SSE unifié.

Plus d'informations

Solutions Zero Trust pour les déploiements du SSE et du SASE

Plus d'informations

Netskope permet à toutes les entreprises d'adopter des services et des applications cloud ainsi que des infrastructures cloud publiques rapidement et en toute sécurité.

Plus d'informations
  • Suivi de nos clients

    Sécurisez votre transformation digitale et profitez pleinement de vos applications privées, cloud et Web.

  • Support client

    Un accompagnement proactif et la volonté d'optimiser votre environnement Netskope et de booster votre réussite.

Choisissez Netskope pour vous aider à faire face aux menaces toujours grandissantes, mais aussi aux risques émergents, aux évolutions technologiques, aux changements organisationnels et réseau, ainsi qu'aux nouvelles exigences réglementaires.

Plus d'informations

Notre équipe mondiale d'ingénieurs qualifiés met à profit son expérience plurielle dans les domaines de la sécurité du cloud, la mise en réseau, la virtualisation, la diffusion de contenu et le développement logiciel pour fournir une réponse rapide et efficace à vos questions techniques.

Plus d'informations
  • Ressources

    Découvrez comment Netskope peut vous aider à sécuriser votre migration vers le Cloud.

  • Blog

    Découvrez comment Netskope permet de transformer la sécurité et les réseaux à l'aide du Security Service Edge (SSE).

  • Événements et ateliers

    Restez à l'affût des dernières tendances en matière de sécurité et créez des liens avec vos pairs.

  • Security Defined

    Tout ce que vous devez savoir dans notre encyclopédie de la cybersécurité.

Podcast Security Visionaries

Épisode bonus : L'importance du Security Service Edge (SSE) – en anglais

Écouter le podcast

Découvrez comment Netskope permet de passer au Zero Trust et au modèle SASE grâce aux fonctions du Security Service Edge (SSE).

Lire le blog

Rejoignez-nous pour participer gratuitement à un atelier pratique lors duquel vous apprendrez à mettre en place des services cloud en toute sécurité au sein de votre entreprise.

Trouver un atelier

Qu'est-ce que le Security Service Edge ?

Découvrez le côté sécurité de SASE, l'avenir du réseau et de la protection dans le cloud.

Plus d'informations
  • Entreprise

    Nous vous aidons à conserver une longueur d'avance sur les défis posés par le cloud, les données et les réseaux en matière de sécurité.

  • Pourquoi Netskope

    La transformation du cloud et le travail à distance ont révolutionné le fonctionnement de la sécurité.

  • Équipe de direction

    Nos dirigeants sont déterminés à faciliter la réussite de nos clients.

  • Partenaires

    Nous collaborons avec des leaders de la sécurité pour vous aider à sécuriser votre transition vers le cloud.

Netskope permet l'avenir du travail.

En savoir plus

Netskope redéfinit la sécurité du cloud, des données et des réseaux afin d'aider les entreprises à appliquer les principes Zero Trust pour protéger leurs données.

Plus d'informations

Penseurs, concepteurs, rêveurs, innovateurs. Ensemble, nous fournissons le nec plus ultra des solutions de sécurité cloud afin d'aider nos clients à protéger leurs données et leurs collaborateurs.

Meet our team

La stratégie de commercialisation de Netskope privilégie ses partenaires, ce qui leur permet de maximiser leur croissance et leur rentabilité, tout en transformant la sécurité des entreprises.

Plus d'informations
Blog Threat Labs AWS: Improve CloudTrail Logging for Assumed Role
May 06 2020

AWS: Improve CloudTrail Logging for Assumed Role

Introduction

Imagine an AWS user in your environment escalates privileges by assuming a role (calling sts:AssumeRole) and performs a malicious action. How will you know in the first place and how will you find the offending user in order to remediate the situation? 

CloudTrail of course. But you find that the event logged for the malicious action tells you the role and not necessarily the original user. To find that user, you need to go back to CloudTrail and find a different, earlier event logged for the AssumeRole call. Finding and correlating two events in CloudTrail or your SIEM is not necessarily difficult, as long as you have CloudTrail configured properly, secured it, have its events in an optimized and indexed data store with enough retention, and know what to look for.

Well, AWS has made all of our lives a little easier. On April 21, 2020, AWS released a new IAM policy condition that, when configured properly, will force the user assuming the role to include their username, which will then be logged in the event every time the user performs an action with that role. Now, only one event needs to be looked at and the user is clearly logged in one of the CloudTrail event fields.

This blog post clarifies how to make use of this new feature to improve clarity of CloudTrail logging for the purposes of incident response and investigations. This will also make it easier to do any analysis on CloudTrail events since identifying the username/owner of a role-based action no longer requires correlation with another event.

The Old Way

CloudTrail Action Event 

Here’s a CloudTrail event for a user that has escalated privileges with sts:AssumeRole and is listing objects in an S3 bucket:

Codeblock showing a CloudTrail event for a user that has escalated privileges with sts:AssumeRole, listing objects in an S3 bucket

We know the action taken is ListObjects on the bucket, MySensitiveBucket, but we don’t know who exactly is taking this action. We know they are using a role, MyBucketRole, but that’s about it.

CloudTrail AssumeRole Event 

To figure out “who” or which IAM user is behind this, we need to go back to CloudTrail and find the earlier event logged when the user actually called sts:AssumeRole. This could be up to 36 hours before the original action event. Assuming we have CloudTrail properly configured and all events stored in an indexed/optimized datastore, perhaps a SIEM, we can query on the same accessKeyId and eventName = “AssumeRole” to find an event like this:

Code block showing query of accessKeyId and eventName = "AssumeRole" in CloudTrail event to uncover userIdentity

Ahhh, there we are. The userIdentity.userName is “support_user”, that’s who is behind all the terabytes of data leaving our S3 bucket.

The New Way

Condition sts:RoleSessionNameWith the latest IAM changes, we now have a new condition, sts:RoleSessionName which we can use to force a calling user to identify their username when they call sts:AssumeRole. Otherwise, their AssumeRole call will be denied. You use this condition in the role’s Trust Policy. Here’s a slightly-modified example from IAM and AWS STS Condition Context Keys in the IAM documentation:

Slightly-modified example from IAM and AWS STS Condition Context Keys in IAM documentation

This policy now forces anyone calling sts:AssumeRole on this role to also supply their username as the role session name when calling the API. This field primarily had been for the calling user’s use, and this condition allows us to enforce self-identification for any callers.

CloudTrail Action Event

The role session name will now be the user’s name and will be logged in the userIdentity.arn field in the CloudTrail event:

Role session name being used as the user’s name and logged in the userIdentity.arn field in the CloudTrail event

Now, one event says it all: userIdentity.arn is the role arn, which includes the role session name, which was forced to be the user’s name: support_user by our policy condition. It’s now clear which user is accessing MySensitiveBucket using MyBucketRole. 

Enforcement

In order to enforce this policy, you can audit your AWS environment using the API/CLI and check all roles that are allowed to be assumed for a trust policy that includes the sts:RoleSessionName condition. Some CLI scripts (e.g. aws iam get-role) running as a job that checks the fields in  Role.AssumdedRolePolicyDocument in the returned policy json could be a simple and effective audit check:

Example of CLI scripts running as a job that checks the fields in Role.AssumdedRolePolicyDocument in the returned policy json

Netskope customers can easily create a custom rule to check and enforce this condition and alert if if any applicable roles are not configured properly:

Example of custom rule Netskope customers can easily create to check and enforce this condition

Conclusion

The policy condition, sts:RoleSessionName, is a small but beneficial new feature that will help you quickly understand the identity of users taking actions as seen in your CloudTrail logs.

At Netskope, we’ve previously blogged about Securing AWS Temporary Tokens, which describes some of the challenges in reducing risk around temporary tokens, including the same challenge in understanding attacker actions from logs.

Using an sts:RoleSessionName condition in all assumed roles should be a mandatory practice as it improves the clarity and simplicity of logged CloudTrail events for actions taken after assuming a role. Given that AssumeRole typically involves the escalation of privileges, it’s even more crucial to have clear and informative logging in place. 

Security operations are much simpler dealing with one event with all information vs. dealing with two events correlated over time. Even the best of logging products or systems can lose events, and the best of people can forget the secret decoder rings needed to understand logged events. 

We also recommend ensuring that sts:RoleSessionName is incorporated in your role provisioning and IAM change management procedures and that it’s enforced by regular configuration checks.

Finally, it’s a good idea to regularly check the IAM Documentation History to stay on top of the latest changes in IAM which can have a wide-ranging impact on your AWS environment.

author image
About the author
Jenko has 15+ years of experience in research, product management, and engineering in cloud security, AV/AS, routers/appliances, threat intel, Windows security, vulnerability scanning and compliance. At Netskope, he researches new cloud attacks.
Jenko has 15+ years of experience in research, product management, and engineering in cloud security, AV/AS, routers/appliances, threat intel, Windows security, vulnerability scanning and compliance. At Netskope, he researches new cloud attacks.