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

  • Security Service Edge Products

    Protect against advanced and cloud-enabled threats and safeguard data across all vectors.

  • Borderless SD-WAN

    Confidently provide secure, high-performance access to every remote user, device, site, and cloud.

  • Platform

    Unrivaled visibility and real-time data and threat protection on the world's largest security private cloud.

Netskope Named a Leader in the 2022 Gartner Magic Quadrant™ for SSE Report

Get the report Go to Products Overview
Netskope gartner mq 2022 sse leader

Gartner® Quick Answer: How Does Netskope’s Acquisition of Infiot Impact SD-WAN, SASE, and SSE Projects?

Get the report
Quick Answer: How Does Netskope’s Acquisition of Infiot Impact SD-WAN, SASE and SSE Projects?

Netskope delivers a modern cloud security stack, with unified capabilities for data and threat protection, plus secure private access.

Explore our platform
Birds eye view metropolitan city

Make the move to market-leading cloud security services with minimal latency and high reliability.

Learn more
Lighted highway through mountainside switchbacks

Prevent threats that often evade other security solutions using a single-pass SSE framework.

Learn more
Lighting storm over metropolitan area

Zero trust solutions for SSE and SASE deployments

Learn more
Boat driving through open sea

Netskope enables a safe, cloud-smart, and fast journey to adopt cloud services, apps, and public cloud infrastructure.

Learn more
Wind turbines along cliffside
  • Our Customers

    Netskope serves more than 2,000 customers worldwide including more than 25 of the Fortune 100

  • Customer Solutions

    We are here for you and with you every step of the way, ensuring your success with Netskope.

  • Training and Certification

    Netskope training will help you become a cloud security expert.

We help our customers to be Ready for Anything

See our Customers
Woman smiling with glasses looking out window

Netskope’s talented and experienced Professional Services team provides a prescriptive approach to your successful implementation.

Learn more
Netskope Professional Services

Secure your digital transformation journey and make the most of your cloud, web, and private applications with Netskope training.

Learn more
Group of young professionals working
  • Resources

    Learn more about how Netskope can help you secure your journey to the cloud.

  • Blog

    Learn how Netskope enables security and networking transformation through security service edge (SSE).

  • Events & Workshops

    Stay ahead of the latest security trends and connect with your peers.

  • Security Defined

    Everything you need to know in our cybersecurity encyclopedia.

Security Visionaries Podcast

Episode 15: Building Permanent Security Awareness

Play the podcast
Black man sitting in conference meeting

Read the latest on how Netskope can enable the Zero Trust and SASE journey through security service edge (SSE) capabilities.

Read the blog
Sunrise and cloudy sky


Netskope is positioned to help you begin your journey and discover where Security, Networking, and Zero Trust fit in the SASE world.

Learn more

What is Security Service Edge?

Explore the security side of SASE, the future of network and protection in the cloud.

Learn more
Four-way roundabout
  • Company

    We help you stay ahead of cloud, data, and network security challenges.

  • Why Netskope

    Cloud transformation and work from anywhere have changed how security needs to work.

  • Leadership

    Our leadership team is fiercely committed to doing everything it takes to make our customers successful.

  • Partners

    We partner with security leaders to help you secure your journey to the cloud.

Netskope enables the future of work.

Find out more
Curvy road through wooded area

Netskope is redefining cloud, data, and network security to help organizations apply Zero Trust principles to protect data.

Learn more
Switchback road atop a cliffside

Thinkers, builders, dreamers, innovators. Together, we deliver cutting-edge cloud security solutions to help our customers protect their data and people.

Meet our team
Group of hikers scaling a snowy mountain

Netskope’s partner-centric go-to-market strategy enables our partners to maximize their growth and profitability while transforming enterprise security.

Learn more
Group of diverse young professionals smiling

AWS: Improve CloudTrail Logging for Assumed Role

May 06 2020


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. 


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


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
Jenko Hwong
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.