Cloud accounts and identity
Identity and access settings, logging, storage exposure and key management. For AWS, Azure and Google Cloud in depth, including benchmark versions and what provider dashboards leave out, see our cloud security review.
Security posture assessment and infrastructure hardening
Find the risky settings across your systems — and harden them in order.
We read how your cloud accounts, servers, network devices, staff laptops and desktops (endpoints) and workplace apps such as Microsoft 365 and Google Workspace are actually set up. We compare each setting with a named benchmark and turn the gaps into a hardening plan, in priority order.
- Read-only access wherever possible
- No change without your approval
- Same settings re-read after hardening
- CIS Benchmarks
- Vendor security baselines
In brief
- What it is
- A review of how your systems are configured, setting by setting. We compare each setting with a named benchmark and record the gap.
- Why it matters
- A vulnerability scan checks software versions and exposed services. It often can't see the settings themselves, such as identity, logging, encryption and access rules, so a clean scan can still leave risky settings in place.
- What you get
- Findings by setting, a hardening plan in priority order, a short summary for leadership, and a re-check once the changes are made.
What a security posture assessment examines
We usually check five areas, each against a named benchmark.
Your security posture is the sum of the settings across everything you run. We read them where they live.
Servers and endpoints
Running services, local accounts and administrator rights, patch levels, disk encryption, host firewalls and logging. Each system is read against the benchmark for its exact operating system version.
Network devices
Firewalls, routers and switches: rule sets, management interfaces, remote access, firmware levels and logging. The network review is described further down this page.
Microsoft 365 and Google Workspace
Your company's own setup in these software-as-a-service (SaaS) products, known as a tenant: external sharing, admin roles, multi-factor sign-in enforcement, legacy sign-in methods, mail authentication and audit logging.
CI/CD and source control
The pipelines that build and release your software (continuous integration and delivery, or CI/CD) and the code repositories behind them: who can approve and merge changes (branch protection), how the passwords and keys the build uses (secrets) are stored and injected, and what the build tools (pipeline tokens and build runners) are allowed to do.
Security configuration review
Every finding is measured against a named benchmark.
Without a fixed reference, a finding is only somebody's opinion.
A configuration review reads the settings themselves, not only software versions. It records how each setting is configured today and how that differs from a written reference.
Three rules that keep findings fair
- Name the benchmark, version and profile. We compare each setting with the benchmark your scope names, such as a Center for Internet Security (CIS) Benchmark or the vendor's own security baseline, including its version and profile level.
- Record accepted exceptions. We collect the exceptions you have already accepted first, with who approved them and why. A setting that departs from the benchmark for an approved reason is reported as an exception, not a finding, so decisions already made aren't reopened.
- Date the review. The report carries the date we read the configuration. If a setting changes after that date, that isn't an error in the review: the report shows what was true on the day.
What CIS Benchmark hardening means in practice
CIS publishes separate benchmarks per product and version, and its Level 1 and Level 2 profiles ask for different things. So a claim of CIS hardening says little until the benchmark, its version and the profile level are written down.
That is what CIS Benchmark hardening means in practice: a written reference for every setting, not a general sense of good practice. The same applies when your scope names a vendor security baseline instead.
Hardening
Infrastructure hardening, in priority order.
Gaps differ in two ways: how risky they are to leave, and how risky they are to change. The hardening plan groups them by both.
Low-risk changes first
Settings that can change with little operational risk are grouped as quick wins: enforcing multi-factor sign-in for administrators, turning on audit logging, removing unused accounts. Your team can make them together.
Changes that need a maintenance window
Changes that could interrupt service, such as disabling an old protocol or tightening a firewall rule that live traffic depends on. Each one is scheduled with an owner, a window and a rollback step.
Changes that need a design decision
Some gaps can't be closed with a setting, such as a flat network, where any device can reach any other, or an administrator account shared by several teams. These go to your architects with the options written down, and our security architecture consulting can help you work through them.
Network
Network security assessment without attack traffic.
Much of a network's exposure can be found by reading how it is configured, without sending hostile traffic at it.
- Firewall and security group rules. We read your firewall rules and cloud security groups (the cloud's own firewall rules) for entries that are unused, too broad or undocumented. Each finding names the rule and the change we recommend.
- Segmentation against your documented design. We compare your configuration with your documented design and data flows: which network zones can reach which, and through which rules. Where the documents and the configuration disagree, the report shows both, and your team decides which one is right.
- Remote access and management interfaces. Remote access paths, such as virtual private network (VPN) gateways and remote desktop services, and device management interfaces are checked for internet exposure, strong authentication, current firmware and logging.
What the network review reads and looks for
Typical rule findings: any-to-any rules (traffic allowed from anywhere to anywhere), management ports open to the internet, rules with no owner, and rules that no longer match a running service.
What the review reads:
- Firewall and router configuration exports
- Cloud security group and network access control list (ACL) definitions
- Network diagrams and data-flow documents
- VPN and remote access settings
- Device firmware versions and logging targets
How we work
Four steps, and nothing changes in your systems until you approve it.
Scope from your inventory
We draw the scope from your asset inventory and agree it in writing: which accounts, servers, devices and tenants are in, and which benchmark each one is measured against.
Read-only access
Access is read-only wherever the platform allows it, and nothing is switched on in your systems without your approval. Any need for higher privileges is agreed in scoping and recorded.
Collect configuration evidence
We export or capture the configuration, so each finding can be checked by someone who wasn't there, such as your auditor or the engineer who makes the fix.
Harden and re-verify
Approved changes go through your own change process, made by your team or with our help. We then read the same settings again, and the report records the result.
What you receive
Three documents, each for the people who act on it.
Findings by setting
Each finding names the setting, the benchmark reference, the current value and the recommended value, with the evidence it was read from.
Hardening plan
Changes in priority order, grouped as quick wins, scheduled changes and design decisions, each with an owner, a window and rollback notes.
Posture summary for leadership
A short summary that leadership and auditors can read without the technical annex: where you stand against the benchmark, what is being fixed and what has been accepted. To keep that evidence current between reviews, see Compliance as a Service.
What this work does not include. We read configuration and send no attack traffic. A posture assessment is not an audit and does not produce a certificate. Audits and certificates come from an accredited or empanelled body, which we are not.
After the assessment
Keep your security posture from drifting.
Settings drift as people make changes. Three things keep your hardened systems close to the agreed settings, known as the baseline.
Baselines as code
Hardened settings can be captured as policy or configuration code in your pipelines, so a change that breaks the baseline is caught before it ships. DevSecOps consulting covers how to build those checks.
Ongoing vulnerability management
Vulnerability management keeps patch levels current between posture reviews, with findings ranked by risk and fixes re-checked on a cycle you choose.
Detection for what can't be hardened yet
Some changes wait for a window or a design decision. Threat detection support helps your team set up the logging and alert rules that would show misuse in the meantime, and Blue Team exercises rehearse whether those alerts reach someone who acts on them.
This assessment is one part of our defensive cybersecurity services.
FAQ
Questions about security posture assessment.
Benchmarks, access and the risk of change. For anything else, ask us directly.
An examination of how your systems are configured, setting by setting, against a named benchmark, followed by a prioritized hardening plan and a re-check once changes are made.
A scan looks for known vulnerabilities in software versions and exposed services. A configuration review reads the settings themselves, such as identity, logging, encryption and access rules, which a scan often cannot see.
The ones your scope names, typically CIS Benchmarks or the vendor's own security baseline for the platform, with the version and profile level written down so the findings have a fixed reference.
Every change is proposed with an owner, a maintenance window where needed and a rollback step, and nothing is applied without your approval through your own change process.
Read-only access sufficient to read configuration wherever the platform allows it. Where a setting can only be read with higher privileges, that is agreed in scoping and recorded.
Let's talk
Tell us which systems, and what they should be measured against.
List the systems in scope and, if you know it, the benchmark or baseline they should meet. We'll come back with a scope and the access it needs. We reply within one working day.