ACTIVITIES

A.  Estimate overall infrastructure risk profile

Interview business owners, platform operators and stakeholders and create a list of worst-case scenarios across the organization's estate. Based on the way in which your organization builds and runs systems, the list can vary widely, but common issues include ransomware reaching production storage, compromise of a cloud control plane granting authority over every environment at once, loss of a facility, exposure of a database to the public internet, and an outage that outlasts the business's tolerance.

After broadly capturing worst-case scenario ideas, collate and select the most important based on collected information and knowledge about the core business. Any number can be selected, but aim for at least 3 and no more than 7 to make efficient use of time and keep the exercise focused.

Elaborate a description of each of the selected items and document details of contributing worst-case scenarios, potential contributing factors, and potential mitigating factors for the organization.

The final infrastructure risk profile should be reviewed with business owners and other stakeholders for understanding.

B.  Build and maintain assurance program roadmap

Understanding the main business risks to the organization, evaluate the current performance of the organization against each of the twelve Practices. Assign a score for each Practice from 1, 2, or 3 based on the corresponding Objective if the organization passes all the cumulative success metrics. If no success metrics are being met, assign a score of 0 to the Practice.

Once a good understanding of current status is obtained, the next goal is to identify the Practices that will be improved in the next iteration. Select them based on the infrastructure risk profile, other business drivers, compliance requirements, budget tolerance, etc. Once Practices are selected, the goals of the iteration are to achieve the next Objective under each.

Iterations of improvement should be approximately 3-6 months, but a strategy session should take place at least every 3 months to review progress on activities, performance against success metrics and other business drivers that may require program changes.

ACTIVITIES

A.  Conduct periodic industry-wide cost comparisons

Research and gather information about infrastructure security costs from intra-industry communication forums, business analyst and consulting firms, or other external sources.

First, use collected information to identify the average security effort being applied by similar types of organizations in your industry. This can be done top-down from estimates of total percentage of infrastructure budget, or bottom-up by identifying the controls and operational activities considered normal for your type of estate.

The next goal is to determine whether there are savings available on the tooling your organization currently licenses. Consolidation is often possible where capabilities have been bought piecemeal, but account for hidden costs such as re-instrumenting environments or running two agents in parallel during migration.

These exercises should be conducted at least annually prior to the subsequent strategy session, and comparison information presented to stakeholders in order to better align the program with the business.

B.  Collect metrics for historic infrastructure spend

Collect information on the cost of past infrastructure incidents. Time and money spent rebuilding compromised systems, revenue lost during outages, regulatory fines, emergency tooling purchases, and the cost of engineering effort diverted to response are the usual components.

Using the environment risk categories and the respective roadmaps for each, a baseline security cost per environment can be initially estimated from the costs associated with the corresponding category.

Combine the per-environment cost information with the general cost model, then evaluate for outliers, i.e. sums disproportionate to the risk rating. These indicate either an error in classification or the necessity to tune the program to address root causes more effectively.

Tracking should be done quarterly at the strategy session, and the information reviewed by stakeholders at least annually.

ACTIVITIES

A.  Identify and monitor external compliance drivers

Gather the regulations, contractual obligations and industry standards that place requirements on the systems your organization operates. Payment, health care and public-sector standards are the usual sources, along with customer contracts that specify control requirements, data residency and audit rights.

For each driver, extract the obligations that land on infrastructure rather than on the wider organization — encryption at rest and in transit, access control and separation of duties, log retention, network isolation, vulnerability remediation windows, and recovery objectives are the usual set.

Assign an owner for each driver and establish a lightweight review to catch changes, since standards and their interpretations shift over time.

B.  Establish the shared responsibility boundary

For every platform and provider the organization uses, document which controls are the provider's responsibility and which are yours. The division differs by service model, and it differs again between services from the same provider.

The failure mode this prevents is assuming a control is inherited when it is not. A provider securing its facilities and hypervisors says nothing about the configuration of the network, the identity policy, or the encryption settings your teams chose, all of which remain yours.

Record the boundary alongside the compliance obligations so that an auditor's question can be answered with evidence rather than an assumption, and review it when a new service is adopted.

ACTIVITIES

A.  Conduct periodic compliance audits of the estate

Move from confirming compliance at deployment to confirming it continuously. Infrastructure drifts through emergency changes, manual intervention during incidents, and resources created outside the standard process.

Audit against the internal standards rather than the tooling's own defaults, and include the resources nobody claims. Orphaned systems — created for a project that ended, or inherited through acquisition — are consistently over-represented in incidents because no team considers them theirs.

Each environment should undergo audit at least biannually, with the highest risk tiers audited more often.

B.  Collect and control compliance evidence

Establish a repository of evidence sufficient to satisfy an external auditor without a scramble: configuration state over time, access reviews, change records, vulnerability remediation timelines, backup and restore test results, and exception records.

Automate collection from the platforms themselves wherever possible. Evidence assembled by hand at audit time is expensive, tends not to survive scrutiny, and diverts the people who would otherwise be fixing the findings.

Report adherence to stakeholders at least quarterly, trending over time rather than presenting a single snapshot.

ACTIVITIES

A.  Conduct technical infrastructure security awareness training

Offer the staff who build and run systems access to training covering the fundamentals of infrastructure security, reflecting the platforms your organization actually operates rather than a generic curriculum.

Cover the mechanisms that matter: the identity and authorization model of each platform, how network isolation is achieved and commonly defeated, where secrets are supposed to live, how credentials are escalated and rotated, and the common paths by which an estate is compromised — which are usually credential theft followed by lateral movement rather than a novel exploit.

Aim to reach the whole engineering and operations population within a year, and refresh at least every two years as platforms change.

B.  Build and maintain technical guidelines

Assemble reference guidelines for the teams who work on infrastructure, covering the specific decisions and settings your organization expects rather than restating general advice available elsewhere.

Practical topics include how to request and use privileged access, which baseline applies to which environment tier, how to expose a service safely, where to store and retrieve secrets, and how to hand a system over to another team.

Keep the guidelines lightweight and current. A short document that is accurate beats a comprehensive one that describes a platform you migrated off last year.

ACTIVITIES

A.  Establish role-based examination and certification

Introduce assessment so that competency is demonstrated rather than assumed, particularly for the roles that hold broad authority over the estate.

Tie certification to access. An engineer with administrative rights over the cloud control plane holds more effective authority than almost anyone else in the organization, and it is reasonable to require demonstrated competency before granting it and to review that competency periodically.

Practical examination against your own platforms and baselines is more informative than a vendor certificate, though the two can complement each other.

B.  Establish centralized guidance control

Bring guidance and runbooks under central control with clear ownership, review cycles and version history, so the organization can state with confidence what its current expectations are.

Distribute from a single authoritative source and retire superseded material actively. Stale runbooks are worse than absent ones, because they are followed during incidents when nobody has time to verify them.

Measure whether guidance is reaching people and being used, and feed that back into the roadmap.

ACTIVITIES

A.  Build and maintain environment-specific threat models

For each environment the organization runs, build a lightweight model of how it could be attacked. A workshop and a page of notes per environment is enough to start.

Work through the ways an estate is exposed. Services are published to untrusted networks. Systems trust one another, often more than intended. Administrators hold credentials that work everywhere. Management planes and automation pipelines can deploy anywhere. Backups are reachable from the systems they protect. Vendors have remote access.

Record for each threat what currently stands in the way. Organizations frequently discover at this point that a control they assumed was universal covers only production, or only one cloud account.

Review the models with the teams who operate each environment and refresh at least annually.

B.  Develop attacker profile from estate exposure

Characterize who would attack your infrastructure and what they would want. The commodity ransomware operator scanning for an exposed service, the group specifically targeting your sector, and the insider with legitimate credentials call for very different defenses.

Ground the profile in how the estate is actually exposed and operated. An organization running systems on-premises with a small operations team carries different risk from one where dozens of application teams provision cloud resources directly, even where the workloads are identical.

Document the profiles alongside the threat models so the two are read together.

ACTIVITIES

A.  Explicitly evaluate risk from providers and third parties

Extend threat assessment to the infrastructure your organization depends upon but does not operate: cloud providers, hosting and colocation partners, managed service providers with administrative access, and the software supply chain feeding your images and automation.

For each, establish what is actually known and what is merely assumed. Where assurance cannot be obtained directly, decide whether to reduce what the party can reach, require an intermediating control, or accept the residual risk explicitly and record who accepted it.

Give particular weight to parties holding standing administrative access, since their compromise is indistinguishable from your own until it is investigated.

B.  Elaborate threat models with compensating controls

Complete the mapping from each identified threat to the specific controls that mitigate it, and record the residual risk remaining after those controls apply.

This mapping is what lets an organization answer the question executives and auditors actually ask — not 'what controls do you have' but 'what happens if this occurs'. It also exposes controls mitigating nothing in the current threat model, which are candidates for retirement.

Maintain the mapping as the estate changes, and review residual risk with business owners at least annually so acceptance is renewed deliberately rather than inherited silently.

ACTIVITIES

A.  Derive security requirements from workload purpose

For each class of workload, work from what it does and what it handles to the security properties its infrastructure must provide. Start from the data and the availability expectation rather than a generic checklist.

A short set per class is enough at this level. Typical entries include encryption at rest and in transit with control over keys, isolation from other tenants and environments, authentication that integrates with the organization's identity provider, audit logging exportable to your own retention, and recovery objectives the platform can actually meet.

Have the requirements reviewed by the teams who will run the workload. A requirement nobody can operate is not yet a requirement.

B.  Evaluate security and compliance guidance for requirements

Draw on the compliance obligations, the responsibility boundary and the threat models already produced to catch requirements that purpose alone would not surface.

Compliance drivers frequently mandate specific properties — data residency, key custody, separation of duties — and the threat models will suggest others, particularly around administrative access and logging.

Consolidate into a single requirement set per workload class so that selection conversations have one document to work from.

ACTIVITIES

A.  Build security requirements into supplier agreements

Carry the organization's requirements into contracts with cloud providers, hosting partners, hardware vendors and managed service providers.

The commitments worth securing in writing are those impossible to retrofit: breach notification obligations and timescales, audit and evidence rights, data residency and deletion guarantees, defined firmware and platform support periods, and constraints on the provider's own administrative access to your environments.

For managed service providers, specify the standard required of the systems they administer and the evidence they must produce, since their access makes their posture effectively part of yours.

B.  Expand audit program for infrastructure requirements

Extend routine audit to cover whether systems in service actually meet the requirements specified for their class, closing the loop between what was specified and what was built.

Audit the supplier commitments too. A stated support period is only useful if someone notices when it lapses, and appliances or platform versions approaching end of support need to enter the replacement cycle before they stop receiving fixes.

Report findings into the strategy session so requirement failures inform the roadmap rather than being handled solely as individual exceptions.

ACTIVITIES

A.  Maintain a list of recommended platforms and services

Publish the platforms, services and regions the organization supports, and keep it short. Every additional platform multiplies the baselines to write, the tooling to integrate and the expertise the operations team must hold.

Base inclusion on the security requirements already specified — isolation model, identity integration, exportable audit logging, encryption with controllable keys, and a support commitment outlasting the intended service life.

Record what is not supported as clearly as what is, and give the list an owner and review cadence so it tracks vendor and provider lifecycle announcements.

B.  Identify and promote secure design principles

Establish the handful of principles every design should honor, and make them explicit so design decisions can be checked against something.

The durable ones are: grant least privilege and prefer short-lived credentials; separate environments so that compromise of one does not imply compromise of another; deny network traffic by default and permit deliberately; keep secrets out of images, code and configuration; make systems reproducible rather than hand-tuned; and ensure that anything protecting the estate cannot itself be reached from the systems it protects.

Circulate the principles to design teams and use them as review criteria.

ACTIVITIES

A.  Build reference architectures and automation modules

Produce complete reference architectures for the patterns the organization deploys — not documents describing an architecture, but working automation modules that yield a compliant environment without manual steps.

Reproducibility is the goal: an environment created from the module is identical to every other, and a change is made by altering the module and redeploying rather than by adjusting the running system. This removes the largest single source of drift, which is manual intervention.

Maintain the modules under change control with review, versioning and their own test suite, and make them genuinely easier to use than building by hand. Adoption follows convenience far more reliably than it follows policy.

B.  Validate usage of reference architectures

Verify that systems in service were in fact built from the reference modules and continue to match them, rather than assuming that publishing a module ensures its use.

Resources created outside the standard process — during an incident, by a team in a hurry, or inherited through acquisition — are the ones that will not match, and they are disproportionately represented in findings.

Report the proportion of the estate built from reference modules as a programme metric, and route exceptions through the documented process rather than letting them accumulate silently.

ACTIVITIES

A.  Identify the attack surface of a design

For each proposed environment, document what it exposes and where its boundaries lie. This need not be elaborate; a diagram and a page of notes is enough to start.

Record what is reachable from the internet, what is reachable from other environments, which identities can administer it, what credentials and secrets it holds, where its data is stored and encrypted, and what it can reach outbound. Egress is routinely omitted and is how most compromises communicate.

The exercise is most valuable where a design diverges from the standard pattern, since that is exactly where an exception gets made quietly.

B.  Check the design against known security risks

Review each proposed design against the organization's threat models and design principles, working through the identified threats and asking what in this design addresses each one.

Concentrate on properties that are hard to change later: how environments are separated, how administrative access is obtained, where secrets originate, whether logging leaves the environment it describes, and whether backups can be reached and destroyed from the systems they protect.

Record the review outcome with the design. Even an informal note stating who reviewed it and what was raised gives the next reviewer a starting point.

ACTIVITIES

A.  Develop data-level review of infrastructure designs

Deepen review to cover the data an environment will hold and what happens to it under adverse conditions.

Trace specific data classes through the design. Where does regulated data come to rest, and in which jurisdiction? Who holds the keys, and can the provider read it? What is replicated, and where to? What does a backup contain, how long is it kept, and who can delete it? What remains after a system is decommissioned?

These questions are answerable at design time and expensive to answer after a regulator or an incident asks them.

B.  Require reviews and audit design compliance

Make review mandatory for designs destined for the higher environment tiers, and verify through routine audit that the requirement is met rather than assuming it.

Audit both that reviews happened and that their conditions were implemented. A review concluding 'approved provided the management network is not routable from the workload subnet' is worth nothing if nobody checked.

Feed audit findings into the strategy session so systematic review failures are addressed as programme problems rather than individually.

ACTIVITIES

A.  Create review checklists from known requirements

Build a checklist per platform from the security requirements and baselines already defined, expressed as things that can actually be observed on a running system.

Keep it to the settings carrying real weight rather than every line of a benchmark. Public exposure of services and storage, administrative access paths and their authentication, encryption at rest and in transit, logging enabled and leaving the environment, patch currency, and default or shared credentials will identify most of what needs attention.

Have the checklist reviewed by the teams who operate each platform, since they know which settings are commonly relaxed and why.

B.  Perform point review of high-risk environments

Sample systems from the higher risk tiers and check them directly against the checklist, rather than relying solely on a console's own compliance view.

Direct inspection matters because tooling reports what agents and APIs tell it, and the systems of most concern are often those outside the tooling's scope entirely — the appliance nobody can install an agent on, the account created outside the standard process, the environment inherited from an acquisition.

Start with internet-facing systems, anything holding regulated data, and the management plane itself. Record findings and route them for remediation with an owner and a date rather than filing them as a report.

ACTIVITIES

A.  Customize assessment for organization-specific concerns

Extend automated assessment beyond benchmark settings to the configurations that matter specifically to your organization and would not appear in any published standard.

These are usually the interesting ones: the network path a previous incident showed to be dangerous, the legacy protocol that must not be re-enabled, the specific role assignment that would let a build pipeline reach production, or the provider service the organization has decided not to use.

Maintain these custom checks with the same discipline as the baselines, since a check written after an incident years ago may now be enforcing something obsolete.

B.  Gate infrastructure change with policy as code

Move enforcement earlier by expressing the standards as machine-checkable policy evaluated before a change is applied, so that non-compliant infrastructure is prevented rather than detected.

Evaluating proposed changes in the pipeline turns a finding that would have taken weeks to remediate into a failed check the author fixes immediately, and it produces an auditable record of what was permitted and why.

Introduce the gate in warning mode first to discover what would have been blocked, and enforce once the noise is understood. Provide an exception route with a named approver, since a gate with no legitimate way past it will be circumvented rather than respected.

ACTIVITIES

A.  Derive test cases from known requirements

Turn the security requirements for each environment class into tests that can actually be run, so a requirement can be shown to hold rather than asserted.

Start with the controls the organization is most relying upon. If the design rests on network separation, the test is to attempt to reach a production service from the environment that should not be able to. If it rests on encryption, the test is to read the data directly from storage.

Document the expected result alongside each test so that a change in behavior after a platform update or a configuration change is noticed.

B.  Conduct penetration testing on infrastructure

Have a representative environment tested by someone attempting to defeat its controls, working from a realistic starting position rather than with administrative access.

Useful scenarios at this level include an attacker reaching the environment from the internet, an attacker with a foothold on one host inside it, and an attacker holding a low-privilege credential. The question in each case is what they reach and how far they travel.

Test an environment built by the standard process rather than one prepared for the test, and record findings against the reference architecture so remediation lands in the pattern rather than on a single system.

ACTIVITIES

A.  Employ organization-specific test cases

Generate test cases from your own threat models and attack paths rather than a generic catalogue, so testing addresses the paths that matter for your estate.

Where an attack path describes a chain from foothold to production, build a test that attempts the chain and establishes where it breaks. This produces findings expressed in business terms, which is what makes them actionable outside the security team.

Include the response process in scope. Testing whether a compromised system is detected, contained and recovered within the target time measures the whole system rather than any single product.

B.  Establish a production release standard

Define the security testing that must pass before an environment or significant change reaches production, and hold the line on it.

Require the standard to be met by the automation rather than by the instance, so that passing is inherited by everything built from the same pattern. This is the difference between testing that scales and testing that becomes a bottleneck.

Require audit evidence that the standard was met, and route exceptions through the documented process with a named approver.

ACTIVITIES

A.  Identify point of contact for infrastructure issues

Establish and publish a single obvious route for reporting a suspected infrastructure problem, and make sure it works from outside the affected environment.

Cover the paths reports actually arrive by: an internal engineer noticing something odd, an automated alert, a customer report, a provider notification, and an external researcher who has found an exposed service. The last of these needs a published address that does not require an account to use.

Publish the route where people will find it under pressure, and make sure it reaches a human out of hours.

B.  Create informal infrastructure response capability

Assemble a group who can act when an issue is reported, with the access needed to do something about it.

The capabilities that matter most are the ability to isolate a system from the network, revoke credentials and sessions, and reach the provider or vendor. Many organizations discover during their first real incident that the person taking the report holds none of these and must find someone who does.

Write down who holds these permissions and how they are reached outside working hours, and confirm that the mechanism works when the environment it depends on is the one that is broken.

ACTIVITIES

A.  Conduct root-cause analysis of infrastructure incidents

Investigate what allowed each significant incident to occur and what allowed it to spread, rather than closing on the immediate remediation.

The causes worth finding are structural: the system was unpatched because it was outside the automation, the credential worked everywhere because roles were never separated, the intrusion went unnoticed because that log source stopped shipping months ago, or the environment was reachable because a rule opened during a previous incident was never closed. Each is a programme finding rather than an incident finding.

Route causes to the Practice that owns them and track them to closure. An analysis programme producing recommendations nobody implements erodes willingness to participate.

B.  Collect and report infrastructure incident metrics

Instrument the process so its performance can be measured and trended, and report results into the strategy session.

The measurements that drive behavior are time from compromise to detection, detection to containment, the proportion of incidents involving systems outside the standard automation, and the proportion involving conditions that were already known and unremediated. The last is usually the most uncomfortable and the most useful.

Trend over time rather than reporting snapshots, and use the data to argue for the roadmap rather than to allocate blame.

ACTIVITIES

A.  Maintain an inventory of systems and their software

Establish and maintain an accurate inventory of the systems the organization runs, along with their operating system versions, installed software and owners.

Inventory is foundational because every other control is scoped by it. An organization cannot patch, assess or decommission what it does not know exists, and the systems missing from inventory are disproportionately those created outside the standard process.

Reconcile sources rather than trusting one. The configuration management database, the cloud provider's resource list, the network's own view and the billing record will each know about systems the others do not, and the differences are the finding. Billing is often the most complete source, since resources that cost money are hard to hide.

Record an owner for every system. Ownerless systems do not get patched, and they are the ones nobody dares turn off.

B.  Apply security updates to systems and their software

Establish a consistent process for delivering operating system, firmware and software updates across the estate, with a defined window by environment risk tier.

Set the window from the risk tier rather than uniformly, and measure against it. Latency is the meaningful number: how long, in practice, between a fix becoming available and the estate having it. Most organizations find their real latency is considerably longer than their policy states.

Handle the long tail deliberately. Systems that cannot be restarted, appliances with vendor-controlled update cycles, and anything supporting a business process nobody will schedule downtime for will account for most of the residual risk, and each needs an owner and a compensating control rather than a recurring reminder.

ACTIVITIES

A.  Establish resilient backup and recovery

Ensure the organization can recover even when an attacker has had administrative access, which is the scenario ordinary backup arrangements are not designed for.

The properties that matter are isolation and immutability: recovery points that cannot be altered or deleted within their retention window, held outside the identity and network domain of the systems they protect, so that compromise of the estate does not imply compromise of its backups. Attackers target backup infrastructure first precisely because this is so often untrue.

Set recovery objectives per workload from business need, and verify them by measurement rather than assertion. Include the ability to rebuild the foundation itself — identity, networking, the automation — since restoring workloads into an environment that no longer exists is not recovery.

B.  Expand audit program for infrastructure hardening

Bring the hardening controls under routine audit so their continued operation is verified rather than assumed.

Audit should confirm both that controls are present and that they are effective. A segmentation rule permitting any-to-any is present but protecting nothing, and a privileged access broker that most engineers bypass is worse than none because it creates false confidence.

Review privileged accounts and automation identities on a defined cycle, removing what is unused. Access accumulates silently, and the accounts of people who changed role years ago are a recurring finding.

Report into the strategy session so systematic weaknesses drive the roadmap.

ACTIVITIES

A.  Capture critical infrastructure telemetry

Identify the information required to establish what is happening in the estate and ensure it is collected and retained centrally.

The core set is well established: authentication and authorization events, administrative and configuration changes, control plane and API activity, network flow records, and the systems' own security logs. Control plane activity deserves emphasis in cloud environments, since that is where the most consequential actions occur and where they are least visible from inside a host.

Collect to a destination outside the environment being observed, so that an attacker who compromises a system cannot erase the record of how they got there.

Review the collected set with the people who respond to incidents, since they will know which source they most often wish they had.

B.  Document procedures for typical infrastructure alerts

For the alerts the estate routinely produces, document what they mean and what the recipient should do.

Cover the common ones: administrative access outside expected hours, a change made outside the automation, a new principal granted broad privilege, unusual egress, a log source falling silent, and backup failure. For each, record the likely benign explanation as well as the malicious one, since most alerts have both.

Keep the procedures where responders work, and review them when alert volumes change materially — a rule producing hundreds of alerts a day is training people to ignore it.

ACTIVITIES

A.  Expand audit program for operational information

Bring the monitoring itself under audit, verifying that the telemetry the organization believes it has is actually arriving and is actually being watched.

Audit for gaps rather than volume. The questions that matter are which systems are not reporting, which sources have fallen silent, which detections have never fired in a period when they plausibly should have, and which alerts were raised and never actioned. A collector that stopped receiving produces no alerts, which is easily mistaken for an absence of problems.

Verify retention meets both compliance obligations and realistic investigation needs. Intrusions are frequently discovered months after they begin, and retention shorter than that period converts an investigation into speculation.

B.  Validate decommissioning and data destruction

Establish and verify the end-of-life process, so that systems leave the estate without leaving anything behind.

The sequence needs to be explicit and confirmed: revoke the system's credentials and certificates, remove its access and trust relationships, confirm data destruction to the standard the data class requires, release addresses and DNS entries, remove it from inventory and monitoring with a recorded disposition, and retain evidence of disposal for owned hardware.

Audit the outcome rather than the intent. Reconciling systems marked decommissioned against those still holding credentials, still resolving in DNS, or still incurring cost reliably finds systems retired in name only. Dangling DNS entries pointing at released addresses deserve particular attention, since they are trivially reclaimed by someone else.