[cabf_netsec] SC20 and Adversarial Interpretation

[Neil Dunbar]

Ryan has added some comments to 
https://github.com/neildunbar/documents/pull/1

If folks would be good enough to take a look, perhaps we can tighten up 
the language. My initial feelings are that retitling "configuration 
change" to "modification" might just be a distinction without a 
difference. In other words, I'm not sure this particularly protects 
against the perverse interpretation; just because something is called a 
"change management process" doesn't automatically create a special 
meaning of the word "change", but prevent a special meaning of 
"modification".

Regarding the capitalisation of Change Management Process - I wonder if 
defining it is just creating a rod for our own backs? I think it would 
be easier to simply lowercase the term, and let the CAs define their 
processes to their auditors.

But that's just my initial feeling - I might well shift as I think on it 
some more.

Cheers,

Neil

On 03/02/2020 18:04, Tobias S. Josefowitz wrote:
> Hi Neil,
>
> On Mon, 3 Feb 2020, Neil Dunbar via Netsec wrote:
>
>> 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
>
> We worked on this a bit in the Pain-Points subgroup today and did not 
> quite find a way to express it so that it is not open to a perverse 
> interpretation. We considered the quite possibly best cause of action 
> might be to take Ryan up on his offer, create an SC20 pull request and 
> see what he comes up with.
>
>> 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!
>
> We came up with:
>
> Change Management Process: 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 authorized.
>
> Anyway, should we create the pull request? I volunteer(ed) to take 
> care of it, and I stand by it, but given you are the proposer and 
> already have the commit and all and just need to click a button, maybe 
> you prefer to do it?
>
> Tobi