Determine what VPCs are peered, which accounts are associated, and identify accounts that aren’t controlled by the enterprise.
VPC peering connects two virtual networks within AWS. These VPCs do not need to be in the same AWS account, and can even span AWS regions. It isn’t uncommon to find VPCs peered that shouldn’t be; often leftover from previous projects. This creates operational sprawl and potential security risks by expanding the potential blast radius. This op assesses peered VPCs and can be used to identify stale connections, connections from other AWS accounts, and new connections that may not have been expected. It can optionally isolate the connected VPC by implementing a network ACL, or even dissolve the connection.
Supported Issue Types:
- A peered VPC within the same account was found
- A peered VPC from another known/registered account was found
- A peered VPC from another account also owned by your organization was identified
- A peered VPC from an unknown, external account was found
- A peered VPC from the external account with the id was identified
- Quarantine the peered network with a new ACL
- Disconnect the peered VPC
In our last post, we walked through the console and highlighted making the most of the Security Hub console and some tips and tricks to make it more useful. Today I want to dive into one of the best parts of Security Hub — taking actions on events and findings.
Security Ops Waiting Game Remember in the olden days, when central IT ruled the land? If an application required fixes or new capabilities, the business put in a change order, and the IT folks