Netskope wurde im Gartner Magic Quadrant für Security Service Edge 2022 als führendes Unternehmen ausgezeichnet. Report abrufen.

  • Produkte

    Netskope-Produkte basieren auf der Netskope Security Cloud.

  • Plattform

    Unübertroffene Transparenz und Daten- und Bedrohungsschutz in Echtzeit in der weltweit größten privaten Sicherheits-Cloud.

Netskope wurde 2022 zum Marktführer im Gartner Magic Quadrant™ for SSE Report ernannt

Report abrufen Netskope Produktübersicht
Netskope führend bei SSE in Gartner MQ 2022

Netskope bietet einen modernen Cloud-Security-Stack mit vereinheitlichten Funktionen für Daten- und Bedrohungsschutz sowie sicherem privaten Zugriff.

Erkunden Sie unsere Plattform
Städtische Metropole aus der Vogelperspektive

Steigen Sie auf marktführende Cloud-Security Service mit minimaler Latenz und hoher Zuverlässigkeit um.

Mehr Informationen
Beleuchtete Schnellstraße mit Serpentinen durch die Berge

Verhindern Sie Bedrohungen, die häufig anderen Sicherheitslösungen entgehen, mithilfe eines SSE-Frameworks mit single-pass Architektur

Mehr Informationen
Gewitter über einem Großstadtgebiet

Zero-Trust-Lösungen für SSE- und SASE-Deployments

Mehr Informationen
Bootsfahrt auf dem offenen Meer

Netskope ermöglicht einen sicheren, cloudintelligenten und schnellen Weg zur Einführung von Cloud-Diensten, Apps und Public-Cloud-Infrastrukturen.

Mehr Informationen
Windkraftanlagen entlang einer Klippe
  • Customer Success

    Sichern Sie Ihren Weg zur digitalen Transformation und holen Sie das Beste aus Ihren Cloud-, Web- und privaten Anwendungen heraus.

  • Kunden-Support

    Proaktiver Support und Engagement zur Optimierung Ihrer Netskope-Umgebung und zur Beschleunigung Ihres Erfolgs.

  • Schulung und Zertifizierung

    Netskope-Schulungen helfen Ihnen ein Experte für Cloud-Sicherheit zu werden.

Vertrauen Sie darauf, dass Netskope Sie bei dem Schutz vor neuen Bedrohungen, neuer Risiken und technologischer Veränderungen unterstützt. Ebenso bei organisatorischen sowie Compliance Anforderungen.

Mehr Informationen
Lächelnde Frau mit Brille schaut aus dem Fenster

Wir verfügen weltweit über qualifizierte Ingenieure mit unterschiedlichem Hintergrund in den Bereichen Cloud-Sicherheit, Netzwerke, Virtualisierung, Inhaltsbereitstellung und Softwareentwicklung, die bereit sind, Ihnen zeitnahe und qualitativ hochwertige technische Unterstützung zu bieten.

Mehr Informationen Support Portal
Bärtiger Mann mit Headset arbeitet am Computer

Mit Netskope-Schulungen können Sie Ihre digitale Transformation absichern und das Beste aus Ihrer Cloud, dem Web und Ihren privaten Anwendungen machen.

Mehr Informationen
Gruppe junger Berufstätiger bei der Arbeit
  • Ressourcen

    Erfahren Sie mehr darüber, wie Netskope Ihnen helfen kann, Ihre Reise in die Cloud zu sichern.

  • Blog

    Erfahren Sie, wie Netskope die Sicherheits- und Netzwerktransformation durch Security Service Edge (SSE) ermöglicht.

  • Veranstaltungen& Workshops

    Bleiben Sie den neuesten Sicherheitstrends immer einen Schritt voraus und tauschen Sie sich mit Gleichgesinnten aus

  • Security Defined

    Finden Sie alles was Sie wissen müssen in unserer Cybersicherheits-Enzyklopädie.

Security Visionaries Podcast

Episode 11: Empowering People for a Secure Future

Podcast abspielen
Dunkelhäutiger Mann in einer Webkonferenz

Lesen Sie die neuesten Informationen darüber, wie Netskope die Zero Trust- und SASE-Reise durch Security Service Edge (SSE) -Funktionen ermöglichen kann.

Den Blog lesen
Sonnenaufgang und bewölkter Himmel

SASE-Week

Netskope hilft Ihnen dabei, Ihre Reise zu beginnen und herauszufinden, wo Sicherheit, Netzwerk und Zero Trust in die SASE-Welt passen.

Mehr Informationen
SASE-Week

Was ist Security Service Edge?

Entdecken Sie die Sicherheitselemente von SASE, die Zukunft des Netzwerks und der Security in der Cloud.

Mehr Informationen
Kreisverkehr mit vier Straßen
  • Unternehmen

    Wir helfen Ihnen, den Herausforderungen der Cloud-, Daten- und Netzwerksicherheit einen Schritt voraus zu sein.

  • Warum Netskope?

    Cloud-Transformation und hybrides Arbeiten haben die Art und Weise verändert, wie Sicherheit umgesetzt werden muss.

  • Unternehmensführung

    Unser Führungsteam ist fest entschlossen, alles zu tun, was nötig ist, damit unsere Kunden erfolgreich sind.

  • Partner

    Unsere Partnerschaften helfen Ihnen, Ihren Weg in die Cloud zu sichern.

Netskope ermöglicht das "neue" Arbeiten

Finde mehr heraus
Kurvige Straße durch ein Waldgebiet

Netskope definiert Cloud-, Daten- und Netzwerksicherheit neu, um Unternehmen dabei zu unterstützen, Zero-Trust-Prinzipien zum Schutz von Daten anzuwenden.

Mehr Informationen
Serpentinenstraße auf einer Klippe

Denker, Architekten, Träumer, Innovatoren. Gemeinsam liefern wir hochmoderne Cloud-Sicherheitslösungen, die unseren Kunden helfen, ihre Daten und Mitarbeiter zu schützen.

Lernen Sie unser Team kennen
Gruppe von Wanderern erklimmt einen verschneiten Berg

Die partnerorientierte Markteinführungsstrategie von Netskope ermöglicht es unseren Partnern, ihr Wachstum und ihre Rentabilität zu maximieren und gleichzeitig die Unternehmenssicherheit an neue Anforderungen anzupassen.

Mehr Informationen
Gruppe junger, lächelnder Berufstätiger mit unterschiedlicher Herkunft
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.