[cabf_netsec] SC20 and Adversarial Interpretation

[Tim Hollebeek]

My personal opinion is that there is nothing that can be done in standards to
prevent perverse interpretations, and that attempting to do so introduces far
more problems than it solves.  The best solution to the problem is to make
the standards language clear, unambiguous, and auditable, and then let
relying parties hold those accountable who try to disguise non-compliance as
compliance.

-Tim

> -----Original Message-----
> From: Netsec <netsec-bounces at cabforum.org> On Behalf Of Neil Dunbar
> via Netsec
> Sent: Monday, February 3, 2020 12:40 PM
> To: CABF Network Security List <netsec at cabforum.org>
> Subject: [cabf_netsec] SC20 and Adversarial Interpretation
> 
> 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
> 
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/netsec/attachments/20200204/3d83183d/attachment.p7s>