[trustable-software] From security to safety, or the other way around?

Robert Seacord Robert.Seacord at nccgroup.trust
Tue Oct 25 16:54:08 UTC 2016


So there are a couple of days to address this problem.  The first is to negotiate a bit more with CMU and maybe asked them to drop or modify the requirement.

A second possibility is to start with the book version of the standard from Addison Wesley, which is slightly different but could serve equally well as a base document.

Thanks,
rCs

------ Original message------
From: Chris Polin
Date: Tue, Oct 25, 2016 9:33 AM
To: trustable-software at lists.veristac.io;Robert Seacord;
Cc:
Subject:Re: From security to safety, or the other way around?


Hi All (and Robert, specifically),

Following from my previous mail, I've been working towards integrating CERT-C into the OpenControl bank of standards, and have written a yaml file which references the controls contained therein. The issue I've encountered is that this yaml file is arguably a 'derivative work' and as such I followed the protocol to obtain permission from SEI before publishing it. They responded with a permission agreement which allows us to use the yaml, however only on the condition that we use the word 'Codethink' in the name of the new file.

This work is a community effort in the open, and is simply a yaml file with the names of the controls contained within CERT-C - it is not affiliated with Codethink. It is effectively the contents page of the CERT-C standard, arranged in a format that is compatible with OpenControl's software. In any case, as the yaml file is to be placed into an open-source Github repository, it could easily be forked and renamed by anyone who so chose to.

In case you are not aware, OpenControl<http://opencontrol.xyz/philosophy/> is an open-source project to automate the production of compliance documentation by referencing a project against a standard. The project has a yaml file associated with it, and OpenControl has a bank of standards (also in a compatible yaml format) with which it is compared. As aforementioned, the NIST-800-53 and PCI-DSS standards have been integrated into the project (NIST<https://github.com/opencontrol/NIST-800-53-Standards> and PCI<https://github.com/opencontrol/PCI-DSS-Certifications>), and we wish to integrate CERT-C in exactly the same fashion.

The addition of 'Codethink' into the title of either the yaml or the repository will immediately introduce ambiguity for the user, as it may imply that the standard that they are looking for is not CERT-C but a Codethink project. Furthermore, it is not in keeping with the other standards in the repo. Ideally it would be named 'CERT-C Coding Standard' so as to avoid this confusion, as the user will be writing code in compliance with the official SEI standard. However, SEI said they were not willing to remove the naming clause.

I don't wish to fall on the wrong side of copyright law or indeed SEI's good graces, and I believe that this is a mutually beneficial move as the end result is that it is easier and less labour-intensive for people to use the standard (and subsequently as the project moves forward, trace their code to each control in turn - Trustable!). But I don't feel that my intentions were understood entirely by the contracts department of SEI (as I got a bit of a 'computer-says-no' response), and as such I'm at an impasse.

Has anyone any experience with this sort of situation before? Any advice you could offer?

Best regards,

Chris Polin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.veristac.io/pipermail/trustable-software/attachments/20161025/22e1a268/attachment.html>


More information about the trustable-software mailing list