Drift prevention / tamper protection

[tghosth]

14.1.5 Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.

Live version Point in time version

We currently have this mechanism as an L3 control.

Is this the same as drift prevention? Should we be clearer about this?

[jmanico]

Meh, this seems really esoteric, I'd like to drop 14.1.5

[tghosth]

So drift prevention is important for things like infrastructure as code where you are expecting the environment config to stay as what you originally created it as. My main question would be whether this is not really application code which is more of the focus of ASVS but more like some sort of grey area around application infrastructure...

[yosignals]

security configuration attestation is what we’re looking for here, ‘verify an administrator can verify’ forgive me ! Is a bit word soupy, - perhaps 4 (appropriate) eyes on changes + immutable change log is enough ? Pre-prod operations

[wet-certitude]

I don't really understand what this requirement requires in practice.

Has anybody seen a solution or product that would meet this requirement in a real system? Are we talking about something like AIDE or Tripwire?

What is the attack scenario we try to prevent? Tampering by an outside attacker who gained control over a system (rootkits would be a concern, we'd likely be talking about a way more advanced solution)? A rogue admin? Config modification that bypasses the change management process or IaC code reviews or PAM?

I'd suggest if no-one can describe what this requirement is supposed to require, we remove it (BTW, if it were up to me, I'd use this policy way more often in ASVS).

[tghosth]

I am inclined to agree to remove as I think that the ephemerality concept discussed in #1315 is more actionable. What do you think @wet-certitude?

[tghosth]

Any further comments @wet-certitude?

@set-reminder 2 weeks @tghosth decide what to do if no response

[octo-reminder[bot]]

⏰ Reminder Wednesday, December 21, 2022 12:00 AM (GMT+01:00)

@tghosth decide what to do if no response

[octo-reminder[bot]]

🔔 @tghosth

@tghosth decide what to do if no response

[tghosth]

So the ephemerality reference in #1315 is more about the build environment rather than the deployed environment itself.

I would therefore suggest the following more specific control:

14.1.5 Verify that deployed environments are short lived and frequently redeployed to a "known good" but updated state. Alternatively, long lived environments should use some form of "drift prevention" to ensure that deployed configurations are not changed to an insecure state.

I think this is easier to understand. Whilst it is difficult to enforce, it is L3 so that is kinda expected.

Thoughts?

@set-reminder 4 weeks @tghosth to decide what to do if no response

[octo-reminder[bot]]

⏰ Reminder Wednesday, January 18, 2023 12:00 AM (GMT+01:00)

@tghosth to decide what to do if no response

[octo-reminder[bot]]

🔔 @tghosth

@tghosth to decide what to do if no response