SPIKE: Cortex XSIAM IAM integration review

[davidkelliott]

User Story

As a security engineer I want to view IAM data in Cortex XSIAM So that I have better quality user data and can alert on IAM issues

Value / Purpose

Improve data in cortex leading to better findings.

Useful Contacts

Ashwin John

Additional Information

No response

Definition of Done

• [ ] Review integration and see if it is appropriate
• [ ] Demo to team your finding and discuss with team to decide if we want to go ahead
• [ ] If we decide to go ahead create a new ticket with the steps required

[markgov]

@davidkelliott can we have some more information on this issue

[davidkelliott]

So the key things to consider when reviewing the integration would be:

1. What permissions does it need and are we happy with it having those permissions?
2. What data does it take, are we ok to share this data? Who will see this data? Is that ok?
3. How does it integrate? Are there any risks involved?
4. IAM users are in the modernisation-platform account, is that the only account it would be useful or are there other accounts.
5. When reviewed an presented to team, Ewa / Dave / Simon make a call on if we want to go ahead with this.

[dms1981]

Also, is this what we're looking to do? https://docs-cortex.paloaltonetworks.com/r/Cortex-XSIAM/Cortex-XSIAM-Administrator-Guide/Ingest-Cloud-Assets-from-AWS

There's no direct integration I could see that references pulling IAM data from AWS, but the closest I could see is the above link to retrieve an inventory of assets which ought to include IAM data.

[ashwinmoj]

For more information on the requirements for these integrations, please refer to the following links: • AWS IAM Integration • AWS Integrations Authentication

[ashwinmoj]

Hi, has there been any updates on reviewing this task?

[ashwinmoj]

To provide additional context for this request: the purpose of this integration is to enhance alerts from the AWS environment on the XSIAM platform. Specifically, we aim to use this integration for alert enrichment by querying information about Amazon resources, which will assist the SOC in investigating AWS-related alerts.

I've attached the list of commands available on XSIAM after the IAM integration is complete. We are specifically interested in the commands that query information, rather than making any changes to the platform. This includes commands starting with aws-iam-get and aws-iam-list. So when configuring the integration, we need to set up a role that allows these commands to be executed.

AWS IAM vs AWS Identity Center commands.xlsx

Mod Platform data is already being ingested on XSAIM via Amazon S3 and Cloudwatch. The SOC team will be the primary users of this data, investigating any alerts from the AWS environment and escalating any concerning incidents according to the agreed process.

[ashwinmoj]

For the integration we’ll need to use the Access Key and Secret Key authentication option.

As part of the configuration for the Access Key and Secret Key authentication you create a role and can specify granular IAM permissions. This looks to be the list of actions you can choose from: Actions - AWS Identity and Access Management . This will allow you to only give the account the privileges it needs for the particular commands you would like to use.

Full steps for setting up the account and integration for the Access Key and Secret Key authentication option are here: AWS Integrations - Authentication | Cortex XSOAR

[richgreen-moj]

So far I've just been reading up on all the information provided above. I'm meeting with Ashwin today so I can get an example of the kinds of alerts that are coming through so I can better understand the user need and whether the solution proposed is going to meet that.

[richgreen-moj]

I had a long chat with Ashwin who gave me a quick overview of the XSIAM tool and we looked at one example of the kinds of alerts that it raises for AWS...

• We discussed the information in this alert and whether or not that could be enriched by an integration into AWS IAM. In this case it had noticed that an ec2 instance in analytical-platform-compute was downloading more objects from an s3 bucket than had been noticed previously.

• The alert had provided the instance-id arn and some raw log details about the role that had been assumed etc. We spoke about how this could have been triggered by an individual with access to the instance or programatically as part of a application/script etc. but that identifying whether or not it was malicious activity would likely require further context from the application/infrastructure owners. After this kind of engagement this kind of alert could be suppressed or amended to fit individual use cases.

I also gave Ashwin an overview of the vast array of accounts we have on the platform (circa 216) and how access to these is managed centrally via AWS access identity center etc. We also discussed the diff between this and IAM on an individual account basis which is used much less frequently bar for some service user identities and a few exceptions like the root and MP account. I also explained that a potential integration into the organisations API for this account would provide dynamic way of referencing application names/contact emails from the account ids in alerts. I believe there is a static process for this currently which queries a list.

Next steps:

• Ashwin is reaching out to his SOC colleagues to get a few more examples of the kinds of alerts that require enrichment and will schedule a follow-up call. This way we can better see what kind of integration would help them.
• I will talk to @davidkelliott about the potential of testing an integration in a test environment so that the benefit of such integration can be explored

[richgreen-moj]

I had another meeting last Thursday (5th Sept) with Ashwin and a group of SOC engineers to go through some more example alerts. One was another ec2 instance uploading to s3 and I tried to explain that the public IP was that of a NAT GAteway endpojnt (i.e. not traceable to a real user) The majority of users are identifiable in the root account (AWS SSO) although that doesn't hold much info (i.e. no genuine contact details/info regarding users). Also we found that one alert was for Cloud Platform which wasn't hooked into the AWS SSO etc.

I offered the possibility of testing the IAM integration in the Modernisation Platform account where we have a limited set of collaborator users but I think Ashwin was going to hold another internal meeting to discuss what kind of integration would add the most benefit to the SOC as they are getting many alerts across multiple platforms.

[richgreen-moj]

Update from Ashwin: The SOC has confirmed that there's no need to proceed with the IAM or Identity Center integration for ModPlatform, as it doesn't provide the enrichment they're looking for. However, the AWS Organisation integration would be really useful. I suggest we close the current ticket and open a new one for AWS Organisation.

[ashwinmoj]

Before using AWS Organizations, you need to perform several configuration steps in your AWS environment. Prerequisites

• Attach an instance profile with the required permissions to the Cortex XSIAM server or engine that is running on your AWS environment.
• The instance profile requires the following minimum permission: sts:AssumeRole.
• The instance profile requires permission to assume the roles needed by the AWS integrations.

Configure AWS Settings

1. Create an IAM role for the instance profile.
2. Attach a role to the instance profile.
3. Configure the necessary IAM roles that the AWS integration can assume.

For detailed instructions, see AWS Integrations - Authentication.

For AWS Organizations quotas, guidelines and restrictions, see AWS Organizations Quotas.

https://xsoar.pan.dev/docs/reference/integrations/aws---organizations

[richgreen-moj]

https://github.com/ministryofjustice/modernisation-platform/issues/7897 << This is the new issue for enabling AWS Organisations integration