[SystemSafety] IEC TR 63069

[paul cleary]

Hi,
Could somebody please advise on the IEC 62508 MT Working Group, it’s mandate to reissue 61508 standards?

Thankyou
Paul Cleary 
Rail Assured Consulting

Sent from my iPad

> On 10 Jan 2019, at 14:41, Peter Bernard Ladkin <ladkin at causalis.com> wrote:
> 
> 
> 
>> 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
> 
> 
> 
> 
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety