What this service covers
We test the infrastructure your applications and staff depend on: cloud accounts, identity and access, networks, container platforms, and wireless and connected devices on site. Testing combines configuration review with hands-on testing from the positions agreed with you, such as the internet, a workstation on your network, or a compromised cloud identity.
This service is for platform, infrastructure, and security teams that run cloud environments or corporate networks and need an independent view of exposure, access paths, and segmentation. It is also used as evidence for audits and customer security reviews.
What is in scope
We agree the exact targets with you during scoping. An engagement can include any of the following.
Cloud accounts
AWS accounts, Azure subscriptions, and GCP projects. Storage exposure, public endpoints, logging, encryption settings, and service configuration.
Identity and IAM
Users, roles, policies, service accounts, and federation. We look for excessive permissions and paths that let one identity gain the access of another.
Network and segmentation
External and internal network testing, firewall and security group rules, and whether separation between environments and network zones holds.
Kubernetes and containers
Cluster configuration, RBAC, workload isolation, secrets handling, admission controls, and container image settings.
Wireless and connected infrastructure
Corporate and guest wireless networks, network devices, and connected equipment on site, where agreed.
Hosts and services
Servers and exposed services, patch levels, and hardening compared with CIS Benchmarks.
How an engagement runs
We agree the accounts, subscriptions, projects, clusters, IP ranges, and sites in scope, the testing positions, test windows, excluded actions, and contacts. These are recorded in the rules of engagement. We check the cloud provider's testing policy for the services involved. An NDA is signed before you share details.
We review configuration with read-only access and test from the agreed positions. Where we find a path from one identity, network, or workload to another, we confirm it within the limits set in the rules of engagement.
You receive an executive report and a technical report. Each finding has a severity rating, the affected resource, reproduction steps, and remediation guidance. Where several findings combine into an access path, the report shows each step.
After your team fixes the findings, we retest them and confirm which issues are resolved and which remain open.
What you receive
Each engagement produces the same set of deliverables, sized to the scope you agree with us.
Agreed scope
- Written scope covering targets, environments, and accounts
- Rules of engagement with test windows, excluded actions, and contacts
- NDA signed before you share details
Findings
- Each finding rated by severity
- Affected account, resource, or host for each finding
Reports
- Executive report for leadership and stakeholders
- Technical report with reproduction steps for each finding
- Remediation guidance your engineers can act on
Retest
- Retest of findings after your team applies fixes
- Updated status for each retested finding
Assessment types
Assessments can be combined in one engagement. Duration depends on scope.
| Assessment | What it involves | When it fits |
|---|---|---|
| Cloud configuration review | Read-only review of accounts, IAM, and service settings | You want a broad view of misconfiguration and excess permissions across accounts. |
| External network test | Testing internet-facing hosts and services from outside | You want to know what is exposed to the internet and whether it can be used to gain access. |
| Internal network test | Testing from a position inside your network, such as a workstation or VPN connection | You want to know how far access from inside reaches and whether segmentation holds. |
| Kubernetes assessment | Cluster configuration review and testing from a workload or user position | You run production workloads on Kubernetes or a managed container platform. |
| Wireless assessment | On-site testing of wireless networks and guest isolation | You have offices or sites with corporate and guest wireless networks. |
Standards and methods
The testing process follows NIST SP 800-115. Configuration review references the CIS Benchmarks for the relevant cloud providers, Kubernetes, and operating systems.
Access paths and techniques are mapped to MITRE ATT&CK, including its cloud and container matrices, so your detection team can compare findings with their coverage. Where useful, findings can also be mapped to the Cloud Security Alliance Cloud Controls Matrix.
Common questions
Will testing affect production?
Testing is planned to avoid disruption. The rules of engagement set test windows, list excluded actions such as denial-of-service or load testing, and name who to contact if something looks wrong. Configuration review uses read-only access and does not change your environment.
Do we need permission from our cloud provider?
AWS, Azure, and GCP each publish rules for security testing on their platforms. Common testing of your own resources does not need prior approval, but some activities are restricted. We check the relevant policy during scoping.
What access do you need?
For cloud review, a read-only role in each account, subscription, or project in scope. For internal testing, a network connection or VPN access. For Kubernetes, cluster credentials at the level agreed for the test.
Do you test staging or production?
Either, and often both. Cloud configuration review is usually run against production accounts with read-only access. Active testing is agreed per environment during scoping.
How are findings shared securely?
We sign an NDA before you share details of your environment. How reports and other sensitive material are exchanged is agreed with your team during scoping.
Can you provide a letter for our customers?
We can discuss it during scoping.
How to prepare
List the cloud accounts, subscriptions, and projects in scope, the IP ranges and domains for external testing, and the sites for any wireless work. Create read-only access for configuration review.
Share network diagrams, an overview of how environments are separated, and previous test reports. Name contacts for your cloud, network, and security operations teams, and decide whether your monitoring team or managed service provider should know when testing runs.
What stays out of scope
Testing covers what your team configures and controls in each cloud platform. The provider's own underlying infrastructure is outside scope, and the provider's testing policy sets limits on some activities. Systems run by third parties, such as managed service providers, are tested only with their written agreement.
