Intro: Services
© 2025 Sonrai Security. All rights reserved.
Overview
Unused [enabled] Services - a useful attack vector for threat actors to leverage!
Maybe you forgot to turn off AWS S3 when you were done testing storage solutions, or perhaps one of your overprivileged developers took the initative to test that out for you (unintentionally bypassing your change management process...)
Sonrai's Cloud Permissions Firewall immediately notifies you whether you have any unused but enabled services and/or privileged permissions access to review.
Scope
Initially, you may be wondering "What am I looking at?..", but a better question is "What do I want to look at first?", which is answered by the top left-hand dropdown providing the scope of the Service-related data in view.
From here you can select a:
- cloud type to narrow down the table results
- logical grouping (the entire Organization, an Organizational Unit (OU), Accounts [nested under an OU])
| Cloud Type | Path |
|---|---|
| AWS | aws/<organization>/<organizational unit*>, aws/<organization>/<organizational unit*>/<account> |
| Azure | azure/<tenant>/<management-group*>/<subscription> |
| GCP | gcp/<gcp-organization>/<folder*>/<project> |
Your selected scope carries through to each action you take within the Services page (i.e. protections will only populate possibilities for the accounts/identities in the chosen scope)
Protecting Services at Scope
With the current architecture of the Cloud Permissions Firewall, when you select an OU from the dropdown menu and protect a service at that scope, it will apply protections to each individual AWS Account nested underneath the OU scope (rather than applying to the OU and inheriting).
Scoped Identity Exemptions
Scoped exemptions can be especially useful for situations where a break glass account or super admin is concerned.
Much like granular account-based identity exemptions for a specific service, these overarching scope-based identity exemptions allow you to manage privileged permissions access, but for a broader scope within your Organization. This method provides you the much more efficient way of exempting an identity for a wider set of privileged permissions across accounts.
The entries with lock icons are system required exemptions.
To maintain full Organizational access for root accounts, create a global exemption for *:root at the top of the Organization tree.
Hero Cards
Once your scope is adjusted, the hero cards (along with the services table) will adjust to reflect the drilldown number of:
- One Click Protection
- IAM users and roles with excessive privilege
- Zombies
- Unused services
The hero cards provide a preview of the identities/services/etc. involved in Sonrai's recommended changes for these categories and a convenient single-click to action!
IAM Users and Roles With Excessive Privilege
Unused privileged service access is a latent attack surface that enables attackers to gain footholds and move laterally within your organization.
Examples involving privileged service permissions:
- creating a new EC2 VPC
- updating the function code of a lambda
- executing an ECS command
Reference: See here for information on IAM users and roles with excessive privilege.
Zombies
A Zombie is considered to be any identity (user, role, etc.) that has been unused for at least 90 days.
Inactive but enabled Zombie identities provide the capability for threat actors to escalate privileges, move laterally, gain access to sensitive data, and more.
Rather than deleting Zombie identities entirely, we opt to help you quarantine them so they remain present within your cloud but can no longer be used. Sometimes Zombies reanimate after some time, but are subject to requesting privileged service access through Permissions on Demand (PoD).
Reference: See here for information on zombie identities.
Unused Services
Service blocks remove the ability for identities within your cloud to use any of the permissions associated with the service.
Disabling service(s) can be regarded as a quick and simple method of reducing attack surface to lower the overall level of service-related risk(s) for your cloud.
Reference: See here for information on unused services.
Regions
Unused but enabled regions provide attackers a vector for environmental movement and increase risk of compliance breach.
Regional blocks remove the ability for identities within your cloud to use any services within the disabled region(s).
Service Status
Key terms and concepts for each possible status you may encounter in the Services table:
All accounts [in scope] allow this service to be used without protection
(i.e. you have not implemented any blocks/protections through Sonrai's Cloud Permissions Firewall yet)
Some accounts [in scope] fully allow this service without protections
(*some accounts may be blocked from using the service and some may use the service with protections in place)
All accounts [in scope] are restricted with one or more cloud controls enabled
(*all accounts have at least one cloud control in place (i.e. some accounts may be blocked from using the service and some may use the service with protections in place))
This service is disabled in all accounts
(i.e the service cannot be used at all)
Any status with "(pending)" indicates there are entries within the Pending Changes page to review/action
Service Controls
Service Controls are one or more protections that can be applied to the cloud to restrict or prevent actions or activities through:
- cloud-native frameworks
- like Azure Policy or AWS Config
These active controls dictate what can and cannot be done to and by the service within your cloud estate, like:
- who and what can access the service specifically in a sensitive manner
Common Controls
The number of Service Controls that apply to any given service will vary based on the nature of the service, but the most common controls you'll see are:
The first step to achieving an effective Least Privilege footprint in a cloud estate; limiting all permission(s) related to that service from use by any identity
The second step in achieving effective Least Privilege; enabling only those identities that have a proven need for this level of privileged permissions access for the service
These types of blocks/protections do not remove previously created elements of your cloud, simply the ability for identities to make more.
For example, the privileged permissions involved with the EC2 service could be controlled and removed from most [or perhaps all] users in a particular part of your cloud hierarchy. Removing this permission from your identities, however, does not remove any existing internet gateways!
Service Actions
There are several options as per how you take action for each service, depending on your use case:
Disable the service entirely so that no accounts within your organization can use it (i.e. all permissions related to this service are blocked for all identities within the selected account(s) [in scope])
The service is being moved into a protected state. Users can elect which cloud controls are to be enabled for the service.
[*If no cloud controls are turned on, the service stays as "Unprotected" status]
The entire service will be unlocked for use by all identities that have grants to the service (zero cloud controls will be enabled in this state)
When we talk about a Service like AWS EC2, Azure Functions, etc. being "protected", we mean those that have one or more Service Control(s) applied. These would be services for which you clicked the "Disable"/"Protect" action at a given scope
Settings
These global settings apply to all of your cloud environments and deployments.
If you have multiple Organizations onboarded, these settings apply to all of them!
To view the settings, click on the cog icon in the top right-hand corner then click the settings menu option:
Baseline
- Zombie Duration (days) - When an identity has been unused for X days, the Cloud Permissions Firewall will tag it as a zombie, preventing it from using privileged service permissions (default: 90 days).
Permissions on Demand (PoD)
-
Request Denial Snooze Time (minutes) - The time to wait (i.e. the snooze duration) before generating an additional Permissions on Demand (PoD) Request after an Approver has denied the initial request (default: 15 minutes).
-
Escalation Window (hours) - The time to wait for an Approver's response to a Permissions on Demand (PoD) Request before escalating to the next list of Approvers in the hierarchical tree (default: 1 hour).
-
Time to Live - TTL (hours) - The number of hours before a Permissions on Demand (PoD) Request will expire (default: 24 hours).
-
Request User Justification - Whether to have your users provide a mandatory justification message with their Permissions on Demand (PoD) Request for privileged service permissions (default: checked).
-
Send Service Block Notification - Whether to notify a Requester through ChatOps that they are attempting to access a service which is blocked by the Cloud Permissions Firewall (default: enabled).
-
Service Block Notification Interval (hours) - The time period for suppressing repetitive notifications to a Requester through ChatOps for attempts to access the same service which is blocked by the Cloud Permissions Firewall (default: 24 hours).
Service FAQs
-
Services with a lock are considered integral to core to cloud provider functionality and cannot be disabled, only protected.
-
Services with account usage "Coming soon" values are those which we are currently unable to validate as legitimately "in use" because they have:
- no create/update/delete activity in audit logs
- no cost explorer usage
- When you completely disable the Access Analyzer service in AWS, expect to see this error when attempting to edit a bucket policy:
You need permissions
User:arn:aws:123456789123:assumed-role/AWSReservedSSO_AdministratorAccess_y7dsefy79ertyf7re7f8reggf7eir/myUser@example.com is not authorized to perform access-analyzer:ValidatePolicy on resource: arn:aws:access-analyzer:us-east-1:123456789123:* with an explicit deny
This is just a visual notification of an error, it does not affect your capability to edit the bucket policy.
Check out our series of how-to pages next!
- How-to: Exempt Identities
- How-to: Disable Services
- How-to: Protect Services