[trustable-software] Integrating software security in the Trustable framework

[Paul Albertella]

Hi,

On 24/05/2019 09:59, Charles-H. Schulz wrote:
> This could be somewhat tricky considering that security requirements are 
> usually applied as a group of criteria marking a specific level of 
> security. Taken individually, each requirement may not mean much, 
> because it has to be considered in connection with other demands.
> But let's see, it could be possible to select some higher level security 
> criteria that could be included in the Trustable framework.

Apologies for the confusion - that's not what I meant to suggest.

I understand that you would want to consider a full set of security 
requirements when considering whether a piece of software meets a 
specified level of security. What I am interested to understand is 
whether it is possible to describe such a set of requirements using our 
model, which may mean focussing on some specific types of criteria 
initially, in order to identify where this may be difficult.

However, I appreciate that working with an unproven and incomplete 
abstract model (see next comment) has its own challenges, so it may be 
better to focus on identifying these types of criteria for security and 
describing how existing standards and certification programmes expect 
software creators to demonstrate that they've been met.

> Thank you. I actually have a question on the HAP model: do you happen to 
> have a page or some sort of resources explaining clearly how it works?

The HAP model is what we refer to as 'the ontology' in the current 
versions of the documents. It is still a work in progress, so there is 
no user-friendly explanation or illustration of how it works yet, but 
the following document describes the basic model:

  https://gitlab.com/trustable/documents/blob/master/ontology/elements.md

and this document describes the higher-level concepts:

  https://gitlab.com/trustable/documents/blob/master/ontology/concepts.md

As you'll see, the focus is on modelling the process of proposing, 
reviewing and incorporating changes to artifacts into a history, which 
we believe must underpin any formalised software engineering process. 
The higher-level concepts frame the desired characteristics and 
constraints for the software and the system that it will realise, and 
the process of creating and refining it.

Note that 'artifacts' in this context means everything associated with 
the creation of software, including source code, tests, binary 
dependencies and intermediate outputs, requirements, build scripts, 
design docs and anything else that might be used in the process.

It's also important to stress that, while 'history' in this context 
might mean a single git repository (or some other VCS) and could equally 
be something less sophisticated (e.g. a mailing list or a shared file 
system), in practice, it is likely to be something a *lot* more complex 
e.g. a coordinated set of dev and test repositories, requirements 
database(s) and/or issue management system(s).

Regards,

Paul