automated-security-response-on-aws

automated-security-response-on-aws copied to clipboard

Describe the bug

List of unused security groups does not take into account groups which are referenced as source or destination in other groups. It appears that currently a group is considered as "unused" if it's not attached to a resource (ec2 instance, lambda, etc)

To Reproduce

• create few security groups
• reference one of them in another one
• attach second security group of a resource
• wait for Security Hub to discover the first group as not being used

Expected behavior

• even if group is referenced in another security group, it will be listed as "unused" and using SHARR to auto remediate will attempt to delete it, potentially breaking another security group where it's referenced

Please complete the following information about the solution:

• [ ] Version: [e.g. v1.0.0]

• 1.42

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0111) AWS Security Hub Automated Response & Remediation Administrator Stack, v1.4.0". You can also find the version from releases

• [ ] Region: [e.g. us-east-1]
• [ ] Was the solution modified from the version published on this repository? REPOSITORY
• [ ] If the answer to the previous question was yes, are the changes available on GitHub?
• [ ] Have you checked your service quotas for the sevices this solution uses?
• [ ] Were there any errors in the CloudWatch Logs? Troubleshooting

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context Add any other context about the problem here.

This solution does not yet have a control/remediation runbook for AFSBP EC2.22 (Unused EC2 security groups should be removed). I'm guessing you're seeing this behavior from clicking on the remediate action in AWS Config? In that case, the remediation you're referring to is the AWS-owned document AWSConfigRemediation-DeleteUnusedSecurityGroup.

I would argue that there's nothing wrong with the remediation itself, but that the Config rule that implements this check for Security Hub is incorrect. Please let me know if I'm misunderstanding anything here.

Good morning,

The bug report I submitted revolves around the fact that Security Hub does not take into the account that the groups are being referred to in other security groups (as opposed to groups being associated with provisioned resources directly). In other words, though SGs are not used directly, they are still being used by association. Removal of those SGs would alter access restrictions of other SGs.

Please let me know if more detailed explanation is required.

Thank you ,

Eugene Shifer (pronouns: he/him) 718.619.5431 | @.*** Security Engineer | Controlled Work Environment

From: hearde @.> Sent: Tuesday, October 11, 2022 12:37 PM To: aws-solutions/aws-security-hub-automated-response-and-remediation @.> Cc: Shifer, Eugene @.>; Author @.> Subject: Re: [aws-solutions/aws-security-hub-automated-response-and-remediation] Deletion of unused Security Groups does not work properly (Issue #57)

This solution does not yet have a control/remediation runbook for AFSBP EC2.22 (Unused EC2 security groups should be removed). I'm guessing you're seeing this behavior from clicking on the remediate action in AWS Config? In that case, the remediation you're referring to is the AWS-owned document AWSConfigRemediation-DeleteUnusedSecurityGroup.

I would argue that there's nothing wrong with the remediation itself, but that the Config rule that implements this check for Security Hub is incorrect. Please let me know if I'm misunderstanding anything here.

— Reply to this email directly, view it on GitHubhttps://github.com/aws-solutions/aws-security-hub-automated-response-and-remediation/issues/57#issuecomment-1275182038, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZJPOOOC4SE3VRBN6B237JTWCW6WLANCNFSM5WWLN4RA. You are receiving this because you authored the thread.Message ID: @.***>

I should have explained myself better. I'm trying to determine where the problem you are describing is happening. The flow for a finding looks something like this:

1. The control is defined in a standard - in this case, I believe you are referring to the control EC2.22 in the standard AWS FSBP. If that's not correct, please let me know which control you are referring to.
2. Security Hub implements that control with an AWS Config rule. In this case, it's ec2-security-group-attached-to-eni-periodic.
3. Resources that fail the config rule trigger findings to appear in security hub
4. The Security Hub custom action for this solution is clicked or the eventbridge rule for this control is enabled, sending the finding to the solution Orchestrator step function
5. The remediation is invoked in the target account and region
6. The remediation resolves the finding - in this case, I'd expect it to delete the security group

I'm trying to make two points related to this bug:

1. It sounds like the bug is in the evaluation of the security group as unused (step 2) rather than in the remediation (step 6). You could argue that the remediation should also check, but the bug in the config rule remains.
2. We don't implement a remediation for this control yet. You can see in the source that there is no mapping for EC2.22, so it's not our remediation that is running. It's possible that you're looking at the AWS-owned SSM document named AWSConfigRemediation-DeleteUnusedSecurityGroup, which is not deployed by this solution. It looks like this document only checks that it's not trying to delete the default security group. You could argue that it should do more checks the ensure the input security group is actually unused, but the bug remains in the Config rule and the finding will still show up in Security Hub.

If I am misunderstanding anything here, please correct me and point out what you think is going wrong in the solution. But if I'm understanding correctly, I would say that the Security Hub Config rule ec2-security-group-attached-to-eni-periodic is what has the bug.

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

It's been awhile since my last comment. I believe that determination on whether security group is used requires additional verification. The fact that group is not used directly, does not necessarily mean that it's not used indirectly (as source or destination) in another security group. If there is a way to add this additional verification, deletion of the truly unused groups would not cause any adverse effects

This has been added to our backlog to be reviewed for a future release

Closing since Security Hub has deprecated this control.