[cabf_netsec] SC20 and Adversarial Interpretation
ndunbar at trustcorsystems.com
Mon Feb 3 10:39:57 MST 2020
Reading through Ryan's comments on the main list, a couple of things are
springing to mind.
1) Is there anything that can be done to shut out a perverse
interpretation that a "change" to a system can be defined as "anything
which goes through our change management process"? Most reasonable
readers would think of a "change" as "something which alters the state
of our systems"; but Ryan's adversarial (and hypothetical) CA example is
looking for a way to reinterpret "change" such that they don't actually
need to scan for alterations in state; merely those alterations
predicated by their inclusion in a change management system.
Perhaps something like:
"Ensure that the CA’s security policies encompass a Change Management
Process, following the principles of documentation, approval and
testing. CAs SHALL NOT make any alterations to the configuration state
of Certificate Systems, Issuing Systems, Certificate Management Systems,
Security Support Systems, and Front-End / Internal-Support Systems
unless those are reflected by defined and properly approved issues
maintained under the Change Management Process;"
2) Should we decapitalise Change Management Process in 1(h), unless we
truly wish it to be a defined term? Given that there are plethorae of
systems capable of tracking changes, it might be problematic to come up
with an all-encompassing definition. In 1(h) we are stating the
characteristics which a change management system needs to demonstrate,
rather than specifically nail down what one is; therefore might it be
better to not make it appear as a defined term?
Alternatively, we could simply define one:
"Change Management Process: A protocol which catalogues proposed changes
to systems within its scope, allowing such changes to be approved,
rejected and reviewed"
My problem with the above is that I'm sure it just creates a dozen more
holes for bad actors to escape from!
More information about the Netsec