[SystemSafety] IEC TR 63069

[Peter Bernard Ladkin]

On 2019-01-10 06:58 , Matthew Squair wrote:
> For example if you have a white-list security function wouldn’t it need to have  the same functional assurance level as that of the safety function that it it is providing a whitelist for?

Sure. Another can of worms.

There are things called SILs. For random failures, there are quantitative reliability criteria. For
so-called systematic failures (failures due to something in the design that can be replicated), one
is "only" required to assure a specific "systematic capability" (SC). The software associated with a
safety function with a safety requirement of SIL x will have a requirement for SC x. There are
sheaves of tables listing methods which can be used in software development at various stages, on
the rows, and the columns are labelled with SIL 1 to SIL 4. Entries are "Not Recommended",
"Recommended" or "Highly Recommended". For example, the table for "software architecture design"
lists 28 techniques or measures, and issues an NR, R or HR for each SIL, for each measure. Some of
these tables are normative (that is, you have to follow them) and some are informative. Exactly what
it means to "have to follow" a recommendation is an interesting question, because a recommendation
is not a requirement. You can conform with a recommendation to use M without actually using M: "we
considered it but rejected it for the following reason....."

Does this all work?

I would say that having to pay attention to all this detail at least means that SW developers have
to understand that detail. They at least have to know what Fault Detection, Error-Correcting Codes,
Failure Assertion Programming, Diverse Monitor Techniques, Diverse Redundancy, Functionally Diverse
Redundancy, Backward Recovery, Stateless SW Design, etc all are. And most of the people coming out
of universities with computer science degrees and getting programming jobs don't (of course, it does
depend on the university). So they do have to educate themselves further, if they are going to be
producing IEC 61508-conformant SW. Knowing about these techniques and having to explain to an
assessor why you did or didn't use each of them is a form of inspection that we might expect
intuitively would lead to higher-quality SW.

But I suspect the quality here is largely being driven by social processes which cannot be
standardised. Companies producing kit for specific industries ultimately need to - and do - sell
their kit on dependability qualities they are seen to have achieved. The techniques and measures
listed in the IEC 61508 tables are really just an account of such companies saying "we do this stuff
and it works for us", enhanced by researchers and other hangers-on saying "it might be a good idea
to do this as well". The expectation is that if some other company does it similarly then they may
hope to get similar quality results (whatever those results may be).

We have recently discussed here the weaknesses in such thinking, but it is sort-of right, to a
point. Mimicking somebody who is producing stuff similar to you and whose quality you want to
emulate does seem like an obvious thing to try. For example, say a company produces a series of
industrial Ethernet switches. You can imagine their customers want them to be pretty resilient, to
be able to service safety functions with a pretty high SIL, also taking into account cybersecurity
properties. Which means they have to be developed, and the development documented, according to the
requirements I have indicated above.

So far so good. It must then be a little disconcerting to have someone discover your kit can be
bricked by certain input values https://ics-cert.us-cert.gov/advisories/ICSA-18-254-05 . After all,
this is a phenomenon which computer scientists thought they knew how - and did know how - to control
in the 1960's. Which resurfaced in spades in the mid 1990's when the Internet took off and computers
began to be generally internetworked. And is still with us nowadays, even though there are multiple
products on the market which can assure your SW is not subject to it, if you care to use them.

So the correlation between IEC 61508 tables and achieved SC of software is only sort-of. Even after
twenty-plus years of experience with the standard. And why people such as Martyn and myself suggest
that mature formal methods should be used in development in such a way that run-time anomalies such
as the above can be guaranteed to be avoided.

So a "functional assurance level" is a very definite thing: SC1 to SC4, and its allocation is very
definite. But its realisation in SW is obscure. It is not at all clear what objective properties you
can attribute to software with SC3.

So say you have this white-list security function and the associated safety function is SIL 3. Then
the security function has to be SC3. But what does that mean exactly? Literally, only that you can
persuade an assessor you have followed the tables during development, and you can present the
nearly-60 pieces of documentation that IEC 61508-3 requires.

But people who develop security SW don't necessarily do that (better said, most don't). They have
Security Levels (SL), which in general specify certain resilience to attacks and attackers with
increasing capabilities and resources.

What is an SL? Good question. IEC 62443-1-1 makes a useful distinction between the SL required
(SL(capability)) and the SL actually achieved by the implementation (SL(achieved)). And it says
there are three of them ("Low", "Medium", "High"), and that it is a scale, but it doesn't specify
how they are assigned. It says "SL(capability) is defined for countermeasures and inherent security
properties of devices and systems within a zone or conduit that contribute to the security of a zone
or conduit. It is a measure of the effectiveness of the countermeasure, device, or system for the
security property that they address."

So say there is a white-list-function SW with SL3, and you want to use it in your SIL3 safety
function. And the developer of the white-list-function doesn't have the required IEC 61508
documentation because heshe is developing security software, not safety SW. What do you do?

Answer: you say SL3 corresponds to SIL3. And if you are really slick, you try to write that in a
standard.

Don't laugh. This comes up again and again. I have had to deal with it at least four times in the
last few years.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190110/dc9767de/attachment-0001.sig>