SEC 1. How do you establish a security baseline and detect drift from it?
Last updated on
A penetration test is a sample. It tells you about one environment on one day, and the environment changes the following week: someone opens a port for debugging, a bucket is made public for a migration, a permission is granted for an incident and never removed.
None of that involves anyone doing anything wrong. It is the normal entropy of a system under development, and the only defence is a stated baseline that something measures continuously.
Best practices
Section titled “Best practices”SEC 1.1Derive the baseline from the frameworks you are actually assessed againstSEC 1.2Measure continuously and automatically rather than by periodic auditSEC 1.3Treat a regression as an incident rather than a backlog itemSEC 1.4Cover the whole estate, including the parts nobody claims
SEC 1.1 Derive the baseline from the frameworks you are actually assessed against
Section titled “SEC 1.1 Derive the baseline from the frameworks you are actually assessed against”Risk if not established: Medium
A baseline assembled from general good practice produces a long list where everything is equally important, which means nothing is. A baseline derived from the obligations you actually carry has a defensible order.
Start from the frameworks that apply to you, which SOV 8 establishes: GDPR, BSI C5, ISO 27001,
sector regulation, and any customer contract that imposes controls. Those give you the mandatory
part. Add what your own threat model requires beyond them, since compliance frameworks are a floor
rather than a ceiling.
Write the baseline as checkable configuration statements rather than as principles. “Object storage buckets are not publicly readable” can be measured. “Data is appropriately protected” cannot, and a baseline made of the second kind produces audits rather than automation.
Distinguish what blocks from what is reported. A control that prevents a deployment needs to be worth blocking for, and a long list of blocking controls of mixed importance trains people to look for exceptions to all of them.
On STACKIT. CSPM checks your environment against selectable benchmarks, and the two named in the documentation are useful starting points: BSI C5 Basic and an internal STACKIT Standard. Starting from a published benchmark rather than a blank list saves the part of this work that is easiest to get wrong.
- Project-Level Security Dashboard: The service currently provides a single, unified view of security risks and compliance status at the project level via the STACKIT Portal UI. Future iterations will expand this to include hierarchical views at the folder and organization levels.
- Compliance Assessment: Continuous compliance assessment against both public industry standards (like BSI C5 and ISO 27000) and the internal STACKIT Standard.
- Automated Detection & Mitigation: Automated detection of misconfigurations and vulnerabilities, complete with guided mitigation recommendations directly in the interface.
- Compliance Report Export: Generate and export point-in-time compliance snapshots directly from the UI. This allows you to generate tamper-evident compliance state logs to easily share your security posture and audit readiness with stakeholders.
Active monitoring or alerting functionalities based on policy violations are not currently available.
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
That maps directly onto SOV 8: if BSI C5 is one of the frameworks you are assessed against, the
same benchmark serves your security baseline and your compliance evidence.
The benchmark is a starting point rather than the whole baseline. Controls specific to your workload, your data classification and your contractual obligations sit on top of it and are yours to define.
Tradeoffs. None between pillars. The cost is time to agree, mostly with people outside engineering. A baseline nobody has agreed is a document rather than a standard.
Verify. Where is your security baseline written, which frameworks was it derived from, and how many of its statements are checkable by a machine?
SEC 1.2 Measure continuously and automatically rather than by periodic audit
Section titled “SEC 1.2 Measure continuously and automatically rather than by periodic audit”Risk if not established: High
An annual audit tells you about one day and leaves the other 364 unexamined. Configuration drifts continuously, so the measurement has to be continuous too.
Two measurement points, and both are needed. Before deployment, in the pipeline, where a
non-compliant change can be stopped before it exists. That is OPS 2.2 applied to security
controls. After deployment, against the running environment, which catches everything that did
not arrive through the pipeline: console changes, drift, and resources created by automation
nobody reviewed.
The second is the one teams skip, and it is the one that finds the interesting problems. A pipeline check only sees what the pipeline deploys.
Make the result visible as a trend rather than as a snapshot. A count of violations that is falling tells you the practice works; a count that is stable at a low number and occasionally spikes tells you something different. Both are more useful than a pass or fail.
On STACKIT. CSPM provides the post-deployment half: a compliance dashboard with overall health and trend data, a list of the most frequently violated policies with occurrence counts, and per-policy detail showing affected assets, severity and violation timestamps. Findings can be exported as CSV, which is what makes them usable in a report or a ticket queue.
Each violation comes with a mitigation guide describing how to fix the resource. CSPM provides guidance rather than automated remediation, so the fix is a human or a pipeline action. That is the usual division for posture management tools, and it means the remediation path is something you build once rather than something that arrives configured.
The pre-deployment half is yours: policy checks in STACKIT
Pipelines
against the infrastructure definitions from OPS 3.
Tradeoffs. Operational Excellence. Continuous measurement produces findings continuously,
and a stream nobody triages is worse than a periodic report somebody reads. SEC 1.3 is what
makes the stream actionable.
Verify. How would you know if a storage bucket became publicly readable this afternoon? How long would it take, and who would see it?
SEC 1.3 Treat a regression as an incident rather than a backlog item
Section titled “SEC 1.3 Treat a regression as an incident rather than a backlog item”Risk if not established: Medium
A finding that goes into a backlog joins a queue ordered by something other than exposure. The value of continuous measurement is the speed of the response, and a fast detector feeding a slow process delivers the slow process.
Route findings by severity rather than uniformly. A publicly exposed data store with sensitive
contents is an incident and should reach someone now, using the process from OPS 9.1. A missing
tag is a backlog item. Most tools produce both and give them the same shape, so the routing is
yours to define.
Set a maximum exposure window per severity, in the same way SEC 8.2 does for patching, and treat
exceeding it as a failure of the process rather than of the individual finding.
Track the exceptions. Some findings are false positives and some are accepted risks, and both need
recording with a reason and an owner under REL 3.4. What must not happen is a finding that is
neither fixed nor accepted, which is the state most estates settle into.
On STACKIT. CSPM assigns severity to findings, which is the input to the routing. Connecting that to an alert or a ticket is yours to build, since CSPM presents findings rather than dispatching them.
The audit log is what tells you how a violation appeared: recorded by default for users, service accounts and the platform, at organization, folder and project scope. That answers whether a public bucket was a mistake, a deliberate change, or something that arrived through automation.
Tradeoffs. Operational Excellence. Treating security findings as incidents consumes on-call capacity, and a threshold set too low produces fatigue rather than speed.
Verify. For the last high-severity finding in your environment, how long between detection and resolution? What was the target, and where is it written?
SEC 1.4 Cover the whole estate, including the parts nobody claims
Section titled “SEC 1.4 Cover the whole estate, including the parts nobody claims”Risk if not established: High
Baselines get applied to the environments people think about. The exposure is usually in the ones they do not: an old project from a proof of concept, a test environment that outlived its project, resources created by someone who has since left.
These are attractive to an attacker precisely because they are unattended. They are rarely patched, rarely monitored, and frequently hold a copy of production data from whenever they were created.
The fix is inventory before assessment. Enumerate what exists rather than assessing what you remember, which means the measurement runs across the whole organization rather than per project by request.
Unowned resources found this way are the same list OPS 1.3 and SUS 6 produce. Assigning an
owner or deleting them serves security, cost and sustainability at once, which is unusual enough
to be worth doing on that basis alone.
On STACKIT. The Resource Manager
hierarchy is the
enumeration: organization, folders and projects give you the full set rather than the set someone
remembered to list. That is another reason the hierarchy is worth defining deliberately, per
SEC 2.2.
CSPM assesses what exists in the scope it covers, so the scope is the thing to check rather than assume. A project outside it is a project nobody is measuring.
On STACKIT it is enabled per project. There is no organization-wide switch that takes in every project at once, which means a project nobody claimed is a project nobody is assessing, and adding a project to the estate is an explicit step rather than an automatic one. Within an enabled project the assessment covers the platform’s services and runs against three policy frameworks; the policies themselves are readable through the API, which is what lets you check a finding against its rule rather than take the score on trust.
The practical consequence for SEC 1.3 is that enabling CSPM belongs in whatever creates a
project. A measurement that has to be remembered is one that will be missed on exactly the project
that needed it.
Tradeoffs. Cost Optimization. Assessing everything costs more than assessing what matters, and the resources nobody claims are exactly the ones nobody will fund the assessment of.
Verify. How many projects exist in your organization, and how many are covered by your baseline measurement? What is in the difference?
Related
Section titled “Related”SEC 2Segmentation, which the estate structure supportsSEC 8Hardening and patching, a large part of what a baseline statesSOV 8Compliance mapping, which supplies the frameworks the baseline derives fromOPS 3.3Drift detection, the same discipline applied to infrastructure definitionsOPS 9Incident management, which high-severity findings route into