[cabf_netsec] SC20 and Adversarial Interpretation

[Neil Dunbar]

All,

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!

Thoughts welcome,

Neil