[trustable-software] Safety, Security, and Portability

[Andrew Banks]

Hi Robert

 

An interesting read - thanks for sharing.

 

As you and I have discussed previously, the heart of the question is this:
is the whole C Language (as defined by ISO/IEC 9899:2011) fit for purpose
for safety- and security-critical software.

 

That ISO/IEC JTC1/SC22/WG14 (the owners of the C Language standard) have
commissioned a second edition of 17961 answers the question in the negative.
as does the existence of MISRA C and CERT-C.  This in turn has led to the
use of "safe" subsets of the C Language (as required by IEC 61508 and ISO
26262 etc).

 

A couple of other comments:

 

1)      I am intrigued by your view of security flaws:

 

To be considered a security flaw, a software bug must be triggerable by the
actions of a malicious user or attacker.

 

Does this mean that a software bug that can be accidentally triggered by a
non-malicious user is not a security vulnerability?  I would suggest it most
definitely is, especially if it results in the compromising of data!

 

 

2)      Your summary states:

 

An International Standard . needs to address the requirements for
safety-critical systems, security-critical systems and safety- and
security-critical systems.

 

I think we can mostly agree that this is the requirement.  Given that we
have failed miserably in persuading WG14 to address this in the C Standard,
a bolt-on addendum is the next best thing.

 

3)      You then state:

 

. rules for security-critical systems need to support the entire language.

 

I am not convinced by this generalisation!

 

 

My recommendation to the Study Group would be, rather than attempt to
generate Rules to detect potential defects, would be to define safe- and/or
secure-behaviours for the gaps in the Language. ie define the undefined, and
specify the unspecified. As this Addendum is (ahem) only (/ahem) intended
for the Safety- and Security-minded communities, those who (ahem) rely on
these undocumented behaviours (/ahem) can continue  to do so. Perhaps in the
longer term, this could then be incorporated into the Standard itself J  Or
maybe the tool-vendors will adopt as standard, as the base-standard ceases
to be the State of the Art?

 

 

But just to show I am not disagreeing with you out of sheer
bloody-mindedness:

 

Coding standards, no matter how good, are unable able to address logic flaws
comprehensively.

 

Absolutely agreed - which is why it is imperative that the whole
organisational Systems- and Software Development Process is properly defined
and documented - and followed.  For examples, see ISO/IEC 15288 and ISO/IEC
12207 (although others are available).  A coding standard on its own is
worthless.

 

 

Kind regards

Andrew

(writing in a personal capacity)

 

 

 

From: trustable-software
[mailto:trustable-software-bounces at lists.trustable.io] On Behalf Of Robert
Seacord
Sent: 12 September 2017 04:14
To: Trustable software engineering discussion
Subject: [trustable-software] Safety, Security, and Portability

 

I've written a short white paper on Safety, Security, and Portability to
support the work of the WG14 Safety and Security Rules Study Group that we
announced on this list some time ago.  

 

If anyone has any comments either respond to this list, email me privately,
or ideally markup the attached word document using track changes and return.

 

Thanks,

rCs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20170914/1d4f91e7/attachment.html>