01 / 03
Existing infrastructure hardening
Most of the infrastructure we are asked to harden already exists: an inherited Active Directory forest, pipelines shipping to production, a cluster set up to run workloads. It carries history and has teams who depend on how it works today. So we do not hand you a reference architecture and leave: we inventory what is actually privileged, what ships and what runs, we design the hardening around your real administration paths, and we implement it incrementally, with the rollback and the migration of existing accounts written down first. One framework, three domains: your applications, your pipelines, your clusters.
When this engagement applies
This is for you if
- Your forest has grown over the years and nobody can say with certainty which admin accounts are actually used
- Your pipelines build and deploy without any security step, or scanners run but nobody acts on the results
- You run Kubernetes in production without a documented security baseline
- Day-to-day administrators currently hold far more privilege than their job requires
- An audit or a compliance requirement demands documented privileged access and secure delivery controls
- You need to pass a cloud security review or an audit and prove what is actually in place
What is out of scope
- Migration to a different identity provider or a rewrite of your CI platform, which are separate architecture projects
- Managed monitoring and detection once the handover is done, as well as the day-to-day operation of your clusters
- Application-level authorisation and penetration testing of your applications, which belong to a separate service
- Building custom scanners, as well as platform engineering, cost optimisation and developer experience work
- Social engineering, which belongs to the red team service
Active Directory
Hardening an existing directory
Most directories we are asked to secure already exist, already carry history, and already have administrators who depend on how they work today. So we do not hand you a reference architecture and leave: we inventory what is actually privileged today, we design a tier model around your real administration paths, and we implement it incrementally, with the rollback and the migration of existing accounts written down first.
What is in scope
- Assessment of the existing forest: privileged groups, delegation, service and task accounts, legacy protocols still enabled
- Tier model design and documentation, adapted to your real administrative workflows
- Implementation of the tiers: group restructuring, delegation rules, admin workstations where relevant, break-glass path definition
- Configuration hardening: SMB and LDAP signing, channel binding, disabling unused protocols, credential protection on privileged accounts
- Migration plan and execution for existing admin accounts and service identities, group by group
Deliverables
- An assessment of privileged access as it exists today
- A tier model document and diagram, with the reasoning behind each boundary
- An implementation plan with rollback steps for each migration wave
- The hardened configuration baseline, with the GPO or equivalent artefacts exported
- A migration plan for legacy admin accounts and service identities
- A handover session with your team and a verification pass afterwards
How we run it
- 01
Assess the existing forest
We inventory privileged accounts and groups, delegation, exposed protocols and the actual dependency map, so the model is built on reality rather than on a template.
- 02
Design the target model
Tiers, administrative workstations, delegation and the break-glass path are written down and validated with the teams who will live with them before anything changes.
- 03
Implement with your teams
No big-bang cutover. Migration happens per group and per forest, with a tested rollback at every step.
- 04
Hand over and verify
Documentation, monitoring hooks and a spot-check against the model, so the configuration you end up with is the configuration we designed.
Standards and references
- Active Directory Tier Model
- Microsoft Security Baselines for Windows Server
- CIS Microsoft Windows Benchmarks
- NIST SP 800-53
- MITRE ATT&CK
CI/CD
Securing your delivery pipelines
Security scanning in a pipeline is easy to buy and easy to run badly. The tools fire, the results pile up, and after a few weeks nobody reads them. We design the scanning process with your teams, integrate it into the pipelines you already maintain, baseline the existing results before gating anything, and centralise what comes out so remediation is tracked per team rather than lost in a dashboard nobody opens.
What is in scope
- Pipeline review: runners, secret handling, build isolation, artefact provenance, who can publish
- Integration of SAST, software composition analysis, secret scanning and infrastructure-as-code scanning into your existing CI
- DAST against deployed environments, staged and tuned so it stays fast and non-intrusive
- Baseline and tuning to remove false positives before any gate is enabled
- Gating policy: severity thresholds, exceptions with an expiry date, tracking of every bypass
- Centralisation of the results in AppGuard, with remediation tracked per team and per repository
Deliverables
- A pipeline review with concrete findings on secrets, runners and build isolation
- Integrated pipeline configuration for your CI platform, committed to your repositories
- SAST, SCA, IaC and DAST configuration with a tuning baseline for your codebase
- A written gating policy: thresholds, exception process, and who approves a bypass
- An AppGuard workspace receiving the results, with the remediation workflow configured
- A handover session with the developers who will own it
How we run it
- 01
Review the pipeline
We look at runners, secrets, build isolation, permissions and artefact handling before deciding where any check belongs.
- 02
Select and integrate
We choose tools that fit your stack and languages, and add them where they give useful signal early enough to be cheap to fix.
- 03
Baseline, then gate
Existing findings are triaged and baselined first, so a gate is introduced on top of a clean signal rather than on top of noise.
- 04
Measure and iterate
Remediation rate, exception ageing and bypass counts are reviewed, and the thresholds move as the pipeline gets cleaner.
Standards and references
- OWASP Software Component Verification Standard
- OWASP SAMM
- NIST Secure Software Development Framework
- SLSA
- OWASP Top 10 and OWASP API Security Top 10
Kubernetes
Hardening clusters
A cluster that was set up to run workloads tends to accumulate default settings, broad RBAC bindings and cluster-admin rights handed out for convenience. We assess the cluster and its workloads against published hardening guidance, implement the controls that matter, and convert the rest into policy so the configuration cannot silently drift back. On the supply chain side, we wire image and IaC scanning into the pipeline that builds them.
What is in scope
- Control plane and node hardening: API server, etcd encryption, kubelet, admission and Pod Security Standards
- Workload security: image provenance and signing, runtime restrictions, network policies, resource and security context defaults
- Supply chain: registry hygiene, admission control, and image plus IaC scanning integrated into your build pipeline
- RBAC review and a concrete role set, including the removal of standing cluster-admin bindings
- Policy as code and admission control, so the baseline is enforced rather than documented
- Secret handling in the cluster: encryption at rest, external secret managers, and access control on secrets themselves
Deliverables
- A cluster and workload assessment with findings rated by exposure
- A hardening baseline document with the reasoning for each control
- RBAC review and a ready-to-apply role set, replacing standing cluster-admin bindings
- Policy-as-code and admission configuration for the cluster
- Supply chain integration in your CI for image and IaC scanning
- Continuous scanning and detection wired to your existing alerting
How we run it
- 01
Assess cluster and workloads
We review the control plane configuration, RBAC, running workloads, image sources and existing exposure, using the same scanners we would recommend you run continuously.
- 02
Define the baseline
We pick a hardening baseline appropriate to your cluster type and risk, and separate what is enforced by policy from what is documented for your teams.
- 03
Implement the controls
RBAC, admission control, secret management and network policies are applied per environment, starting with non-production, each change with a rollback.
- 04
Automate the detection
The same checks run continuously so drift is caught, and results land in AppGuard with the rest of your security tooling.
Standards and references
- CIS Kubernetes Benchmark
- Kubernetes Pod Security Standards
- NIST SP 800-190
- MITRE ATT&CK for Containers
- SLSA