Managed Security

Safeguarding & Hardening

We close what testing found and keep it closed: configuration baselines, identity, secrets, backups and logging, done with your engineers and verified by the people who test.

Plenty of teams are tested every year and carry the same classes of finding from one report to the next: over-privileged roles, long-lived access keys, a new cluster on default settings, backups nobody has tried to restore. The report explains each issue. Closing it for good needs someone who knows how it is exploited and how your platform is run, and that combination is hard to hire.

We work in your environment alongside your engineers, through your change process. Each fix is made at the level that stops the class of issue, such as a policy, a baseline or a pipeline check, rather than on the single host in the report. Then we try the original attack again. The work ends at a verified state and a baseline your team can apply to the next system without us.

Usually, one of these is true

The same classes of finding appear in every penetration test report, and closing them one host at a time has not worked.
An engineer left and took the only working knowledge of how your cloud accounts, keys and admin access are set up.
A ransomware incident elsewhere in your sector made someone ask when a backup was last restored, and nobody knew.
A customer or an auditor asked for evidence of hardened configuration, and all you have is the provider's defaults.

What we harden

Work starts from your open findings and the benchmark that fits each platform. Every deviation from the benchmark is either fixed or written down with a reason and an owner.

Configuration baselines. Cloud accounts, Linux and Windows hosts, Kubernetes clusters and databases brought to the relevant CIS Benchmark, with the baseline kept as code so new systems start hardened.
Identity and access. SSO and MFA on every admin path, phishing-resistant factors for privileged users, unused roles removed, and standing admin rights replaced with time-bound, approved access where it matters.
Secrets and keys. Long-lived keys found and retired, secrets moved into a managed store, rotation that has actually been exercised, and a written procedure for the day one leaks.
Backup and recovery. Backups separated from the credentials that could delete them, made immutable where the platform supports it, and restores tested end to end against a ransomware scenario.
Logging and detection. Audit logging switched on where an intrusion would currently leave no trace, retained long enough to investigate, and first detections for the paths your last test used.
Pipeline guardrails. Checks in CI and infrastructure-as-code review that stop a fixed misconfiguration from being reintroduced by the next deploy.

How the work runs

It runs from the findings you already have to a baseline that stays in place, with each change agreed with your team and each fix tested again.

Findings intake. We gather open findings from our reports and anyone else's, group them by root cause, and agree with you which classes of issue to close first.
Baseline. We measure each in-scope platform against its benchmark and your own policies, and write down the gap, including anything you choose to accept.
Paired changes. Fixes go through your change process and your repositories, paired with your engineers, with a rollback written down for every change that could affect production.
Verify. We rerun the original attack or reproduction against each fix and recheck the baseline, so closed means the path is gone, not that a ticket moved.
Hold and review. CI guardrails and drift checks keep the baseline in place. At each agreed review we recheck it, look at what drifted and why, and update the documentation.

What you get

Hardening baseline. The configuration standard for each platform, kept as code where possible, for the engineers who build the next system.
Remediation record. Every finding closed, the change that closed it and the verification that proved it, for your security lead and your auditor.
Exceptions register. Each deviation you chose to accept, with the reason, the compensating control and an owner, so accepted risk is written down rather than forgotten.
Runbooks. Step-by-step procedures for key rotation, access reviews and restore tests, written for the team that maintains them after we leave.
Retest and attestation. A retest of the original findings once the work is done, and a letter of attestation for your customers and auditors.

What we need from you

The findings to close: recent penetration test reports, cloud security posture exports or audit observations.
Access through your normal change process: repository access, a role in each cloud account, and a named engineer on your side to pair with.
Your change windows and anything that must not break, such as a payments path or a nightly batch job, so each change is planned around it.
Existing policies, standards and exceptions, so the baseline builds on what you have rather than replacing it.
A non-production environment where risky changes can be tried first, or an agreed way to roll back production changes.

What we can show you

Fixed by the people who test. One team runs testing and hardening. The engineers closing your findings know which fix stops the attack and which only changes the scanner output.
Every fix is retested. Every fix is checked by rerunning the original reproduction. A ticket marked done is not the same as the path being gone.
Knowledge stays with you. Work goes through your repositories and your change process, with documentation and runbooks for the team that inherits it.
Least-privilege access. Our access is least-privilege and limited to the engineers on the engagement. Evidence is encrypted, covered by mutual NDA, and destroyed after the retest on request.

Standards we work to

Baselines are built from the public benchmarks auditors and cloud providers already reference, so every deviation can be explained against a named control.

CIS Benchmarks
CIS Controls v8.1
NIST SP 800-53 Rev. 5
NIST SP 800-63B
NIST CSF 2.0 (Protect)
DISA STIGs

Common questions

Do you make the changes, or tell us what to change?

Either, agreed in the scope. Pairing works best: we make changes alongside your engineers through your repositories and change process, so the knowledge stays on your team. If you would rather make every change yourselves, we write the change and verify it afterwards.

Will hardening break production?

It can if it is done carelessly. That is why every change is planned around your change windows, tried outside production where possible, and has a rollback written down before it is applied. Anything with a real chance of disruption is agreed with the system owner first.

Can you fix findings from another firm's report?

Yes. We start from the original evidence, confirm the issue still reproduces, fix the class of problem rather than the single instance, and verify by rerunning the reproduction. If a finding no longer reproduces, we record that instead of claiming a fix.

Which benchmark do you harden to?

Usually the CIS Benchmark for each platform, at the profile that fits how the system is used, adjusted for your own policies and any framework you report into. Where a recommendation would break something you rely on, the deviation goes into the exceptions register with a reason and a compensating control.

How do we stop the same findings coming back?

By fixing the source rather than the instance: a baseline applied as code, a policy set at the cloud organisation level, a CI check that fails the build. At each review we look at what drifted and why, and fix the process that let it drift.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.