[trustable-software] Security certifications and agreements

Charles-H. Schulz chs at adocentyn.io
Fri Apr 12 17:19:39 BST 2019


Hello Paul,

Please see my comments inline.

Paul Sherwood @ 2019-04-12 11:17 CEST:

> Hi Charles,
>
> welcome aboard! Please see my comments inline...
>
> On 2019-04-11 15:08, Charles-H. Schulz wrote:
>> This the first time I'm posting here. I've done some cursory research
>> on the Trustable Gitlab as well as on this mailing list, but I do not
>> see software security (as in, "cybersecurity") being considered or
>> investigated by this project. I'd be happy to help in that regard.
>
> You're right that we've not so far begun any material work targeting
> security specifically, mainly I think due to lack of bandwidth, not
> lack of interest. There are quite a few cybersecurity folks on the
> list already, who I think would be pleased to collaborate.

Excellent, I'm happy to help and I'll be examining the wiki and the rest of
Gitlab to see where I could add content. 
>
> We have been considering security as part of our overall thinking and
> approach, however, and I personally see overlap between security and
> safety concerns in many cases. I fear these are not being adequately
> addressed in general. Some of the systems engineering thinking from
> STAMP + STPA may usefully address the overlap so that's the approach
> I'm most actively exploring.

Indeed, I see how these two can mostly address safety - security is somewhat
different. While I do see that there my be overlap between the two notions,
my experience is that they tend to conflict as well; but when they don't, it
is often thanks to developers relying on proper safety OR security
methodologies AND languages deemed secure, such as OCAML or Rust. 
>
>> More specifically, there are a set of international standards as well
>> as government delivered security certifications that help clearly
>> label or verify the solidity of any given software. I'm particularly
>> thinking about the Common Criteria (http://www.commoncriteria.org) but
>> there are other sets of requirements, sometimes based on these.
>
> This is interesting, for sure.
>
> I do note in passing that the site supports http: but not https:,
> which these days triggers security alerts in many browsers (!)
>
I'm not surprised. You know what they say about shoemakers :-)

>> In some other instances, there are even specific audits that combine
>> security certifications and sofware assurance schemes involving the
>> tracking/mapping of components origins, authors, etc.
>>
>> I do realize that security is but one element of what is very much a
>> continuum when it comes to the trustability of software. In my opinion
>> however, it is far from being a trivial or unimportant one.
>
> Totally agree.

And to add to it: audits tend to verify the state of a system or a software
in what is necessarily a n-1 state, but of course they don't verify the
present state nor do they verify anything in a continuous or real time
fashion. Which is a big drawback when you think about it. 

>
>> My question at this point is whether we should add to the wiki or the
>> existing documents - after discussion here.
>
> Absolutely.  In the interim I've submitted a merge request to add the
> CC and SOGIS projects to the website [1]

Nice!

Thank you,

Charles.



More information about the trustable-software mailing list