Use Case: Cloud
Risky security group changes
A developer added 0.0.0.0/0 inbound on port 5432 to a security group attached to the production PostgreSQL cluster. The intention: temporary access for a vendor demo. The exposure: the entire internet.
The temporary fix that becomes a permanent exposure
Security group misconfiguration is the most common cloud infrastructure vulnerability. The pattern: a developer needs temporary access to a database for debugging, adds a broad inbound rule to save time, intends to remove it after the session, and forgets. Shodan and Censys index newly-exposed services within hours. Attackers using these scanners can identify and attempt to exploit open database ports within the same day the rule was added.
ManySignal evaluates every security group change against a risk model that considers: the destination port's sensitivity, the CIDR breadth of the rule, the tier of resources protected by the security group, and whether the change was made via IaC or manually via the console.
rule: risky_security_group_change
type: cloud_posture_event + risk_model
sources:
- aws_cloudtrail (AuthorizeSecurityGroupIngress)
- azure_monitor (Microsoft.Network/networkSecurityGroups)
- gcp_admin_activity (compute.firewalls.patch)
trigger:
- condition: |
rule.cidr IN ["0.0.0.0/0", "::/0"]
OR rule.cidr.prefix_length < 16 # broader than /16
AND rule.port IN sensitive_ports [22, 3389, 3306, 5432, 27017, 6379]
enrichments:
- resource_tier: attached_resources, data_classification
- iac_attribution: terraform, cloudformation, deployment_manager
- shodan_exposure: public_service_scan_results
- itsm_correlation: approved_change_window
mitre: T1562.007 (Disable or Modify Cloud Firewall)MITRE ATT&CK mapping
Security group change FAQ
What security group changes trigger immediate alerts vs. low-priority findings?
Immediate P1 alerts: any inbound rule allowing 0.0.0.0/0 or ::/0 (all traffic) to port 22 (SSH), 3389 (RDP), 5432 (PostgreSQL), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis), or 9200 (Elasticsearch). Medium priority: broad CIDR ranges to admin ports, any change to a security group attached to a database tier. Low priority: changes to non-sensitive ports or known-safe IP ranges.
Does this cover Azure NSG rules and GCP firewall rules in addition to AWS?
Yes. Azure Network Security Group rule changes are monitored via Azure Monitor, and GCP VPC firewall rule changes via GCP Admin Activity logs. All three platforms are normalized into the same risky security group change model.
Can ManySignal automatically revert dangerous security group changes?
For changes that match high-severity patterns (0.0.0.0/0 to database ports), ManySignal can revert the change autonomously by calling the cloud provider API to remove the offending rule. This autonomous action is configurable and requires explicit enablement — it's disabled by default to prevent operational disruption.
How does this detection handle legitimate temporary access requirements?
Temporary access grants are accommodated via the change management correlation: if a ticket in ServiceNow or Jira documents a time-limited access requirement, the security group change is not flagged during the approved window. The ticket must include the specific IP CIDR, port, and expiration time. ManySignal monitors for the expiration and alerts if the rule isn't removed on schedule.
Alert on dangerous firewall changes before Shodan indexes your database
Real-time cloud firewall monitoring with risk scoring and optional auto-remediation.