Allow for multi-account push into AWS

[SteveMcGrath]

Findings appeared in AWS, but the script pushed all findings related to different AWS accounts to the Security Hub of the specified AWS account in the config file.

Originally posted by @tracker5676 in #43

This will likely require a configuration flag to support this in a backwards compatible way.

[SteveMcGrath]

A new optional parameter has been added to the config file called map_to_asset_account is now available that will attempt to fetch the aws account id from the TVM-stored asset and use that instead. It will still fall back to using the configured account if it cannot be found, or if the config setting is set to false.

To enable, simply set this flag to true

[tracker5676]

Hi @SteveMcGrath ,

Please let me know how to use this field in the config file? Just put - map_to_asset_account = "ACCOUNT ID FOR WHICH I WANT TO EXPORT THE RESULTS".

If yes, how can we put 2-3-4 account id?

Example, I have 10 aws accounts but I want to export findings for 3-4-5 of them

[SteveMcGrath]

Just flag it as true like so:

map_to_asset_account = true

It will pull all assets that TVM is aware of into Security Hub. I didn't wrap something to be more granular than that.

[tracker5676]

once map_to_asset_account = true attribute added I get an error:

[tracker5676]

Hi @SteveMcGrath,

Could you please comment on this?

[SteveMcGrath]

Apologies, i thought i had responded to this one. Looking into it, do you have Security Hub enable on all of your accounts? Does this user have access to post to all of these accounts?

AWS apparently restricts findings to only be associated to the account that is feeding the findings (see here). For a multi-account setup, we may need to restrict the integration to only feed data to/from the same account in that case.

[tracker5676]

Hi @SteveMcGrath,

Sure, SecurityHub is enabled on all accounts. So, as of now I scan two AWS accounts with TVM. AWS User has access only to the specific (one) AWS account.

Please clarify available options on how can we pull/push findings belonging to 2 AWS accounts from TVM to SecurityHub?

Thanks

[SteveMcGrath]

Right, but we can only flow data for a matching account into that account's SecurityHub by the look of it. Do you have Security Hub enabled on each account you're sending the data to? is the AWS role you're using to feed the data into support multi-account delegation?

Just my assumption, but the integration today was originally written to feed data into a single SecurityHub instance, however it sounds like you'd need to setup a securityhub instance for each account and ensure that the integration as permissions to write to all of these accounts. Alternatively, the inetegration could be amended to restrict the asset metadata (and therefore the vuln data) to a single account or list of supported accounts. This might take a minor bit of effort to support however.

[tracker5676]

• Security Hub is enabled for all AWS accounts;
• I use an AWS user (not role) to communicate with AWS Security Hub and this user has only access to the specific (one) account;

Based on your words will It be correct to say:

1. As of now binary does not support multi-account integration (if we have tvm findings associated with assets belong to different AWS accounts and we want to export them to the appropriate AWS account)?
2. If we have two AWS accounts and we want to export associated findings to AWS Security Hub we might have two instances to launch the binary (one for AWS Account A and one for AWS Account B).
3. I expected that the binary would get/filter only the findings belonging to the AWS account provided in the config file as of now and would push these findings to the Security Hub of the provided AWS account but instead, It looks like the binary gets all findings and tries to push them to one AWS Account. Can we fix it?

[SteveMcGrath]

1. correct. The logic on the current integration is to feed the data into a single AWS account.
2. If the AWS user account being used to connect to AWS doesn't support multi-account, then yes
3. Yes, this shouldn't be hard to do

[tracker5676]

It looks like the answer to point 1 denies the possibility of using point 2 even if there is a role that has the ability to communicate with many aws accounts. So, we can assume that under any circumstances, multi-accounts is not currently possible?

[SteveMcGrath]

Alrighty, so 2.1.0 released. What it should do is a couple of things:

1. if map_to_asset_account is set to true (and nothing else) is done, it will only publish assets and findings that match the aws_account_id in the config file.
2. If allowed_accounts is set within the config file, then it will read that list of account ids (string values) and allow any accounts that are within that list to be published.
3. If map_to_asset_accounts isnt set or is set to false, the original behavior is maintained.

[tracker5676]

Hi @SteveMcGrath,

I added parameters to the config file: map_to_asset_account = true allowed_accounts = "XXXXXXXXXXX, YYYYYYYYYYY"

Additionally, I created a role for cross-account access but within the binary execution, I got an error (Something seems to be wrong with ARN)

.

I'm using an AWS IAM user with aws cli created in account A + I created a role in account B that allows the user from account A to assume it.

In AWS CLI If you want to run commands with role assuming from another Account you have to add --profile assumed-role-profile but we can't use this option with binary execution.

So, how can we troubleshoot or fix the problem?

[tracker5676]

I tested 2nd account separately with a role - all findings have been exported successfully.

Thoughts: When you work with aws cli you are working based on aws profiles that are based on IAM User key or IAM user + assumed role.

For example, you have AWS Account A and Account B. You created IAM User - "Test" in Account A and access key for this user. You added Test user to aws cli as a default profile. So it means all the commands will be executed within the account this user belongs to.

If you want to execute commands in account B you must create a role, allow assume this role by the user from account A. And you have to add parameter --profile assumed-role-profile within the execution of any aws cli commands.

As of now binary know nothing about the aws profile and assumed role. This is the problem.

[SteveMcGrath]

as the integration is relying on AWS's Boto3 client to handle things like the profile, Boto3 natively understands this using either the AWS config file OR via an environment variable. If you set the envvar below with the name of the profile to use, you should be good-to-go.

https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-environment-variables

AWS_PROFILE=""

Also for the config file as the allowed_accounts is a list:

map_to_asset_account = true
allowed_accounts = ["XXXXXXXXXXX", "YYYYYYYYYYY"]

To tie all this up:

AWS_PROFILE="" tvm2aws --configfile config.toml

[tracker5676]

I tried using this variable, but it does not play a role in my case since I use the profile - default with aws cli. I have created 3 identical roles in 3 AWS accounts and one user in a separate (fourth) AWS account.

1. All roles I described as a separate profile in .aws/config file with a source_profile = default.
2. All accounts have activated SecutityHub + activated Tenable integrations.
3. Cloud Connector in Tenable activated for all accounts.
4. Region is the same

So, tvm2aws works fine with 2 of 4 accounts.

binary execution for the other 2 accounts failed with an error:

What could be wrong, any ideas? 😊

[tracker5676]

When I left only one account in tvm2aws config and specify AWS_PROFILE="PROFILE_WITH_ASSUMED_ROLE" - It worked fine. If I change AWS_PROFILE="default" the script can't assume this role.

[SteveMcGrath]

This is more of a Boto3/AWS permissions issue at this point. I know I have seen similar issues with the Boto3 client and have always run with a non-default role that support assumed role.

I'm not an AWS IAM expert by any means, so I don't know why AWS does this. We rely on AWS's authentication code for all this as many auth mechanisms can be quite complex.

[tracker5676]

@SteveMcGrath ,

Is there a chance that we can describe in the config file all the profiles we want to use for the accounts mentioned in allowed_accounts? Like: allowed_accounts = ["XXXXXXXXXXXX", "YYYYYYYYYYYY"] profiles = ["profile XXXX", "profile YYYY"]

[tracker5676]

Hi @SteveMcGrath,

What do you think?)

[SteveMcGrath]

I looked into it, and there is an option to instantiate a singular Boto3 client with a single profile. I don't think a single run could support multiple profiles as you'd likely want to restrict the profile to a series of accounts.

Adding a singular profile attribute into the integration is definitely possible however.

[tracker5676]

I have no idea why we got an error when assuming the other AWS account roles. Individually, all the roles work fine, manual assuming works fine.

.aws/config file includes 4 profiles: [profile sechub] region = eu-central-1

[profile assumed-role-111] role_arn = arn:aws:iam::XXXXXXXXXXXX:role/Tenable-Sec-Hub-integration source_profile = sechub region = eu-central-1

[profile assumed-role-222] role_arn = arn:aws:iam::YYYYYYYYYYYY:role/Tenable-Sec-Hub-integration source_profile = sechub region = eu-central-1

[profile assumed-role-333] role_arn = arn:aws:iam::ZZZZZZZZZZZZ:role/Tenable-Sec-Hub-integration source_profile = sechub region = eu-central-1

I can specify only one profile with AWS_PROFILE key. If I specify AWS_PROFILE="sechub" It does not assume all associated roles because of something, If I add AWS_PROFILE="assumed-role-333" the binary will be able to perform batch import operation in ZZZZZZZZZZZZ account only.

Thought. When the binary runs the commands It can run with the appropriate profile. To import vulns:

• to the account AAAAAAAAAAAA use command - "aws securityhub batch-import-findings .... --profile sechub --region eu-central-1"
• to the account XXXXXXXXXXXX use command - "aws securityhub batch-import-findings .... --profile assumed-role-111 --region eu-central-1"
• to the account YYYYYYYYYYYY use command - "aws securityhub batch-import-findings .... --profile assumed-role-222 --region eu-central-1"

Profiles could be used as variable described in the tvm2aws config file.

[SteveMcGrath]

Alrighty, finally had the time to start looking at this. I may be able to support what your looking for here, but it'll require a different way to track the role -> account relationships...

Instead of the current flat layout, we would instead build a mapping like so:

[[aws_profile]]
name = "assumed-role-1"
accounts = ["1234567890", "2345678901"]

[[aws_profile]]
name = "assumed-role-2"
accounts = ["3456789012", "4567890123"]

etc...

Then what we would do internally is have independent caches for each profile and a lookup between the accounts and the profiles. Should allow a single run to do everything.

[tracker5676]

@SteveMcGrath,

`[[aws_profile]] name = "assumed-role-1" accounts = ["1234567890", "2345678901"]

[[aws_profile]] name = "assumed-role-2" accounts = ["3456789012", "4567890123"]

etc...`

Will it be a part of the config file?

Thoughts: As an option, we can use naming for AWS CLI profiles - "assumed-role-accountID", where accountID is a variable. This means that the user must create a profile in ~/.aws/config for each AWS account where findings are to be imported.

~/.aws/config looks like: [profile sechub] region = eu-central-1

[profile assumed-role-XXXXXXXXXXXX] role_arn = arn:aws:iam::XXXXXXXXXXXX:role/Tenable-Sec-Hub-integration source_profile = sechub region = eu-central-1

[profile assumed-role-YYYYYYYYYYYY] role_arn = arn:aws:iam::YYYYYYYYYYYY:role/Tenable-Sec-Hub-integration source_profile = sechub region = eu-central-1

If binary trying to export findings belong to account XXXXXXXXXXXX it will use profile assumed-role-XXXXXXXXXXXX.

[SteveMcGrath]

Yes, for example, I have the following coded up for testing. As for naming the roles to the account id, I think that may end up overly implementation specific. Further depending on how the profiles are generated, you may not have a choice in the naming (i can tell you I don't when using our credential management tooling).

access_key = "XXXXX"
secret_key = "XXXXX"

[[aws_profile]]
name = "XXXX"
accounts= [1234]
region = "us-east-1"

I'm also working on fixing the earlier string vs integer problem for accounts. the updated code should recast whatever is stored in accounts as a string, so it wont matter what type is in there.

[tracker5676]

Let's try what you recommend.

[tracker5676]

Hi @SteveMcGrath,

Just wondering — is there any timeline or estimate for when the new version could be released?

[SteveMcGrath]

the code is mostly complete at this point, I just don't have a multi-account setup to test with, so I have been waiting for something setup internally to finalize testing.

[tracker5676]

Good news! Thanks, Steve

[SteveMcGrath]

Just note that may take a bit of time, especially with RSA being next week.