[cabf_netsec] SC20 and Adversarial Interpretation
benwilsonusa at gmail.com
Mon Feb 3 11:05:24 MST 2020
I think we can do some things (add language) to address Ryan's concern
about a CA weaseling around with the definition of change - as you
suggest. We discussed that in the pain points subgroup this morning.
I think we should capitalize Change Management Process and define it. We
made some steps in that direction too.
We could combine approaches to the wording of the definition until we're
happy with it. Right now, it is proposed to say, " An established set of
steps followed to ensure that the intended system configuration and changes
to it have received appropriate levels of review and have been duly
We could have it say alternatively,
“The process by which changes to an installation are implemented in a
systematic manner following a well-defined set of procedures.”
“A sequence of activities that are followed by a change management team to
use change management on a project to ensure that it meets the intended
“A control process designed to ensure that changes proposed are reviewed,
authorized, tested, implemented, and released in a controlled manner; and
that the status of each proposed change is monitored.”
“The objective of change controls is to ensure that all changes to
software applications, database systems, and associated infrastructure
assets are properly authorized, documented, tested, approved, and
implemented into the production environment.”
“The purpose of change management is to ensure that the system components
used to deliver services are identified, recorded, and monitored so that
only authorized changes are applied.”
What do we say already about configuration management in the NCSSRs? - See
On Mon, Feb 3, 2020 at 10:40 AM Neil Dunbar via Netsec <netsec at cabforum.org>
> 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,
> Netsec mailing list
> Netsec at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Netsec