close
close
Your Network of Tomorrow
Your Network of Tomorrow
Plan your path toward a faster, more secure, and more resilient network designed for the applications and users that you support.
          Experience Netskope
          Get Hands-on With the Netskope Platform
          Here's your chance to experience the Netskope One single-cloud platform first-hand. Sign up for self-paced, hands-on labs, join us for monthly live product demos, take a free test drive of Netskope Private Access, or join us for a live, instructor-led workshops.
            A Leader in SSE. Now a Leader in Single-Vendor SASE.
            A Leader in SSE. Now a Leader in Single-Vendor SASE.
            Netskope debuts as a Leader in the Gartner® Magic Quadrant™ for Single-Vendor SASE
              Securing Generative AI for Dummies
              Securing Generative AI for Dummies
              Learn how your organization can balance the innovative potential of generative AI with robust data security practices.
                Modern data loss prevention (DLP) for Dummies eBook
                Modern Data Loss Prevention (DLP) for Dummies
                Get tips and tricks for transitioning to a cloud-delivered DLP.
                  Modern SD-WAN for SASE Dummies Book
                  Modern SD-WAN for SASE Dummies
                  Stop playing catch up with your networking architecture
                    Understanding where the risk lies
                    Advanced Analytics transforms the way security operations teams apply data-driven insights to implement better policies. With Advanced Analytics, you can identify trends, zero in on areas of concern and use the data to take action.
                        The 6 Most Compelling Use Cases for Complete Legacy VPN Replacement
                        The 6 Most Compelling Use Cases for Complete Legacy VPN Replacement
                        Netskope One Private Access is the only solution that allows you to retire your VPN for good.
                          Colgate-Palmolive Safeguards its "Intellectual Property” with Smart and Adaptable Data Protection
                          Colgate-Palmolive Safeguards its "Intellectual Property” with Smart and Adaptable Data Protection
                            Netskope GovCloud
                            Netskope achieves FedRAMP High Authorization
                            Choose Netskope GovCloud to accelerate your agency’s transformation.
                              Let's Do Great Things Together
                              Netskope’s partner-centric go-to-market strategy enables our partners to maximize their growth and profitability while transforming enterprise security.
                                Netskope solutions
                                Netskope Cloud Exchange
                                Netskope Cloud Exchange (CE) provides customers with powerful integration tools to leverage investments across their security posture.
                                  Netskope Technical Support
                                  Netskope Technical Support
                                  Our qualified support engineers are located worldwide and have diverse backgrounds in cloud security, networking, virtualization, content delivery, and software development, ensuring timely and quality technical assistance
                                    Netskope video
                                    Netskope Training
                                    Netskope training will help you become a cloud security expert. We are here to help you secure your digital transformation journey and make the most of your cloud, web, and private applications.

                                      AWS: Improve CloudTrail Logging for Assumed Role

                                      May 06 2020

                                      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
                                      Jenko Hwong
                                      Jenko has 15+ years of experience in research, product mgmt., and engineering in cloud security, routers/appliances, threat intel, vulnerability scanning and compliance.
                                      Jenko has 15+ years of experience in research, product mgmt., and engineering in cloud security, routers/appliances, threat intel, vulnerability scanning and compliance.

                                      Stay informed!

                                      Subscribe for the latest from the Netskope Blog