Description:
This check verifies that all Security Groups actively associated with Utho Cloud resources have at least one inbound (ingress) filtering rule configured. A Security Group without ingress filtering may inadvertently permit unrestricted access depending on its configuration or fail to enforce the organization's intended network security policy. Every Security Group in use should explicitly define the inbound traffic that is allowed.
Rationale:
Security Groups are the primary mechanism for controlling inbound network access to cloud resources. Using a Security Group without properly configured ingress rules can result in unintended exposure of services or inconsistent network security controls.
This check helps:
Ensure all attached Security Groups enforce inbound access restrictions.
Prevent accidental exposure of cloud resources.
Maintain a least-privilege network security model.
Improve compliance with industry security best practices.
Impact:
Ensures every Security Group attached to a resource has explicit inbound filtering.
Reduces the risk of unintended network exposure.
Improves consistency of firewall configurations across cloud resources.
Applications requiring inbound connectivity may become inaccessible if appropriate ingress rules are not configured after remediation.
Default Value:
Utho Cloud does not automatically ensure that Security Groups attached to resources contain ingress filtering rules. A Security Group without inbound rules that is attached to a resource should be reviewed to ensure it aligns with the organization's security requirements.
Pre-requisites:
Utho Cloud account.
Permissions to view and manage Security Groups.
Access to the Utho Cloud Console or Utho API.
Compute instances or other supported resources protected by Security Groups.
Remediation Steps:
Test Plan:
Using the Utho Cloud Console
Sign in to the Utho Cloud Console.
Navigate to Networking → Security Groups.
Review each Security Group that is attached to a resource.
Examine the Inbound (Ingress) rules.
Verify that the Security Group contains one or more inbound filtering rules permitting only the required traffic.
.
Using the Utho API
List all Security Groups (Firewalls).
curl -s -H "Authorization: Bearer $UTHO_API_TOKEN" \
https://api.utho.com/v2/firewall
Retrieve the details for each Security Group.
curl -s -H "Authorization: Bearer $UTHO_API_TOKEN" \
https://api.utho.com/v2/firewall/<FIREWALL_ID>
Implementation Plan:
Using the Utho Cloud Console
Log in to the Utho Cloud Console.
Navigate to Networking → Security Groups.
Select the Security Group that is attached to a resource but contains no ingress rules and click Manage.
Add inbound rules required by the workload, specifying:
Protocol
Port or port range
Trusted source IP address or CIDR range
Save the Security Group.
Verify that only the intended inbound traffic is allowed.
Using the Utho API
Retrieve the Security Group details to confirm that no inbound rules exist.
curl -s -H "Authorization: Bearer $UTHO_API_TOKEN" \
https://api.utho.com/v2/firewall/<FIREWALL_ID>
Add the required ingress rule.
curl -s -X POST \
-H "Authorization: Bearer $UTHO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type":"incoming",
"service":"SSH",
"protocol":"TCP",
"port":"22",
"addresses":"203.0.113.10/32"
}' \
https://api.utho.com/v2/firewall/<FIREWALL_ID>/rule/add
Replace the protocol, port, and trusted CIDR with values appropriate for the workload.
Backout Plan:
Log in to the Utho Cloud Console.
Navigate to Networking → Security Groups.
Select the modified Security Group.
Remove the newly added ingress rule if it causes unexpected application behavior.
Restore the previous Security Group configuration if documented.
Verify application connectivity and network access after the rollback.
References: