LZ account - Cloudwatch destination log groups for LZ

[stmag]

Within a child account (secops 906266124095) i was able to modify the LZ CW destination log group that sends its logs to the Seclog account.

This means that someone with malicious intent could turn off all centralised logging to the Seclog account, and thus the project owner and security S2 would be blind to any activiity occuring inside that account. This requires a policy in place to prevent these actions from occurring with a similiar management IAM admin role incase this is needed for support reasons.

[silavjy]

Another approach is to publish an account management policy document explaining how customers should manage their accounts/roles.

Full admin access to the account should only be used for break-glass situations(?) all other users should have a default role with least privilege access required to perform their tasks.

[stmag]

that could be an option, but i was thinking more restrictive measures to prevent the deletion and/or modification of any CW log destination from the source AWS account to the project seclog account, and conversely changing any CW destination groups from SecLog account to splunk. If any of these are changed we run the risk of missing vital security logs

[neisije]

Current SCP must be reviewed to be compliant with non default cloudwatch log group names (....##ENV##production##...)

[stmag]

@neisije - my initial thinking was just the log sources that SOC depend on downstream (CT, GD, SH, Config etc) - there maybe more that comes tbh but at least the core security services deployed as part of LZ at a minimum

[neisije]

@stemcg1 : yes this is what I want to implement as well in the SCP.

But the current SCP is based on the default namings of the cloudwatch log groups, this doesn't work for DIGIT D1 for which we configured the loggroups of the LZ based on the following naming convention:

DG##DIGIT##Project##FPFIS##ENV##production##Service##cloudtrail##Source##cloudtrail## DG##DIGIT##Project##FPFIS##ENV##production##Service##cloudtrail##Source##insight## DG##DIGIT##Project##FPFIS##ENV##production##Service##events##Source##config## DG##DIGIT##Project##FPFIS##ENV##production##Service##events##Source##guardduty## DG##DIGIT##Project##FPFIS##ENV##production##Service##events##Source##securityhub##

=> The SCP must be updated to protect cloudwatch these loggroups

I was thinking on a tag based policy like any AWS resources tagged with "Project: secLZ" cannot be updated or deleted

To be discussed as currently none of the loggroups created by the LZ are not tagged despite the fact we pass the tags via the cloudformation...This was not expected...Support ticket to be created I guess