Cloud scans
Cyberwatch provides a dedicated assistant that simplifies the setup of scans on cloud infrastructures such as Amazon Web Services, Google Cloud Platform, Microsoft 365, Microsoft Azure, and Active Directory. In particular, CIS benchmarks for these platforms are partially supported for compliance checks.
The goal of these scans is to ensure that the configuration follows some best practices, for example by ensuring that sensitive resources are not publicly accessible.
Prerequisites
AWS compliance
Configure AWS access via CloudFormation (recommended)
The recommended way to create AWS credentials is to use Cyberwatch’s cloud assistant and to choose a deployment using CloudFormation. Using CloudFormation for your deployment brings several perks :
- The deployment is faster and more automated
- Using only one set of credentials in Cyberwatch, you can access all or part of the AWS accounts in your organization.
- Newly created AWS accounts are handled dynamically and automatically.
Deploying accesses via CloudFormation is done by executing the following steps :
- Choose a deployment type: AWS account or AWS organization.
- If AWS organization is selected, choose on which part of the organization the accesses will be deployed. Giving the root ID to deploy accesses on the whole organization is recommended.
- Deploying several accesses en the same AWS accounts is enabled by specifying a suffix, failing to provide one will result in the CloudFormation stack failing.
- Click the Launch CloudFormation button, which will redirect to the AWS console. Connecting on the management account or on a delegated admin account to deploy the CloudFormation is required for organization deployments. For account deployments, connect on the account on which the CloudFormation will be deployed.
- On AWS, check that the information in the form is correct, tick the checkbox I acknowledge that AWS CloudFormation might create IAM resources with custom names, and create the CloudFormation stack.
- Once the stack execution is complete on AWS, go into the results of the stack, and copy the output into Cyberwatch.
- Finally, finish to fill the form in Cyberwatch and save.
Note
The access key in the CloudFormation output is temporary and will be overridden once the credentials are saved in Cyberwatch.
Manual AWS access configuration
To browse your AWS infrastructure, Cyberwatch needs an access key. You may create them from the AWS console by clicking your user name at the top right corner, then select “My security credentials”. See also AWS’ detailed documentation: https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys.
It is recommended that you create a dedicated AWS user for Cyberwatch with the following roles:
- SecurityAudit
- ViewOnlyAccess
Once your access key has been created, you need to add it to Cyberwatch from “Stored credentials” in the lateral bar, then clicking Add. In the credentials adding form, select type Amazon Web Services and input your generated access key ID and its secret access key.
EKS compliance
| Attribute | Permission |
|---|---|
| AWS user with the policy | eks:ListClusters |
| AWS user with the policy | eks:DescribeCluster |
For each EKS cluster, an IAM access entry must be defined for the user, with the access policy AmazonEKSAdminViewPolicy.
The CIS compliance rules in section 3.2 require the creation of a Kubernetes RBAC ClusterRole that allows read (get) access to the API route api/v1/nodes/{node}/proxy/configz. A ClusterRoleBinding must also be created to associate this ClusterRole with the user used by Cyberwatch. This configuration must be applied to each EKS cluster.
Google Cloud Platform compliance
| Attribute | Permission |
|---|---|
| Role | Security Reviewer |
| Role | Viewer |
| Cloud Resource Manager API | Enabled on each project |
Azure compliance
Configure an Entra application with a PowerShell script (recommended)
To create remote access to Azure, it is recommended to use the cloud creation assistant and choose the deployment via the PowerShell script. This method allows you to:
- Deploy accesses faster and in an automated way.
- Access all or part of the tenant’s subscriptions with a single set of credentials.
- Dynamically manage the addition of new subscriptions.
To run the script, you must have one of the following roles:
- on the chosen scope in Azure: Owner or User Access Administrator
- on Microsoft 365: Global Administrator, Privileged Role Administrator, Application Administrator, or Cloud Application Administrator
To deploy via the PowerShell script:
- Choose the scope of the Entra application: Tenant root management group (recommended), Management group, or Subscription.
- Enter the ID of the chosen scope.
- Optional - Choose the name of the Entra application — the default name is Cyberwatch.
- Click the Get command line button.
From the Azure portal, log in to the tenant, then:
- Run the obtained command line in Cloud Shell in PowerShell mode.
- Once the script execution is complete, copy the returned JSON into Cyberwatch.
- Finish filling out the form and save.
Manual Entra application configuration
To configure accesses manually, create an Entra application and assign it the following permissions:
| Attribute | Permission |
|---|---|
| Role | Virtual Machine Contributor |
| Role | Managed Application Contributor |
| Role | Reader |
| Role | Key Vault Reader |
| Role | Storage Account Contributor |
| Role | Web Plan Contributor |
| Application permission on Microsoft Graph | Policy.Read.All |
AKS compliance
The Entra application created in the Azure compliance section already has the necessary permissions. For manual configuration, the Entra application must also have the following permissions:
| Attribute | Permission |
|---|---|
| Role | Azure Kubernetes Service RBAC Reader |
The CIS compliance rules in section 3.2 require the creation of a Kubernetes RBAC ClusterRole that allows read (get) access to the API route api/v1/nodes/{node}/proxy/configz. A ClusterRoleBinding must also be created to associate this ClusterRole with the user used by Cyberwatch. This configuration must be applied to each AKS cluster.
The CIS compliance rules in section 4.1 require creating a custom role containing the following dataAction type permissions:
- Microsoft.ContainerService/managedClusters/rbac.authorization.k8s.io/clusterroles/read
- Microsoft.ContainerService/managedClusters/rbac.authorization.k8s.io/clusterrolebindings/read
- Microsoft.ContainerService/managedClusters/rbac.authorization.k8s.io/roles/read
- Microsoft.ContainerService/managedClusters/rbac.authorization.k8s.io/rolebindings/read
Microsoft 365 compliance
The Entra application created in the Azure compliance section already has the necessary permissions. It is also possible to run the PowerShell script deployment from the Microsoft 365 cloud creation assistant by following the same procedure as described in the Configure an Entra application with a PowerShell script section. For manual configuration, the Entra application must also have the following permissions:
| Attribute | Permission |
|---|---|
| Microsoft Graph application permission | AccessReview.Read.All |
| Microsoft Graph application permission | AuditLog.Read.All |
| Microsoft Graph application permission | DeviceManagementConfiguration.Read.All |
| Microsoft Graph application permission | DeviceManagementManagedDevices.Read.All |
| Microsoft Graph application permission | DeviceManagementServiceConfig.Read.All |
| Microsoft Graph application permission | Domain.Read.All |
| Microsoft Graph application permission | OnPremDirectorySynchronization.Read.All |
| Microsoft Graph application permission | OrgSettings-AppsAndServices.Read.All |
| Microsoft Graph application permission | OrgSettings-Forms.Read.All |
| Microsoft Graph application permission | Policy.Read.All |
| Microsoft Graph application permission | RoleManagement.Read.All |
| Microsoft Graph application permission | SharePointTenantSettings.Read.All |
| Microsoft Graph application permission | User.ReadBasic.All |
| Office 365 Exchange Online application permission | Exchange.ManageAsApp |
| SharePoint application permission | Sites.FullControl.All |
| Microsoft Entra role | Global Reader |
Some Microsoft 365 rules in the SharePoint category require certificate-based credentials.
Active Directory compliance
| Attribute | Permission |
|---|---|
| Permission | Read-only |
Add a project
- Go to the menu Assets management > Cloud
- Click on Add
- Choose a platform: AWS, GCP, Azure, Microsoft 365, or Active Directory
- Enter an access key or API identifier directly into the form, or select an already stored credential, then click Browse
- Define the name and choose one or both of the following options based on your needs:
- Save discovery:
A discovery will be created using the defined name, listing all discovered machines. This discovery will be available from the Discoveries page.
- Check project compliance:
This option will create a cloud asset using the defined name and return the result of the compliance scan.
- Click Save to launch the automatic setup of the selected elements.
You will then be able to view the compliance scan results in the Compliance inventory, or by clicking the asset’s name from the Assets management > Cloud menu, as well as the discovery results on the Discoveries page.