[SystemSafety] "Security Risk" and Probability

[Todd Carpenter]

Another is to provide resources, such as computing, memory, and
communications, to unauthorized users. For example, a medical device
vendor recently released a patch for a vulnerability in a 2010 product
that allows remote execution on its embedded radio. The vendor claims
that due to its partitioned design (a.k.a., the radio is on its own
chip) the *safety *of the medical device itself was not impacted. We'll
take that claim at face value, since it is possible to architect a
system that way. One might argue that letting someone else run arbitrary
code on your network facing component is insecure. The botnet people
certainly seem to like that sort of thing.

On 11/2/2017 2:11 PM, Driscoll, Kevin R wrote:
>> How can software be safe and not secure?
> One that leaks private information, which doesn't lead to a safety issue.
>
>> -----Original Message-----
>> From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-
>> bielefeld.de] On Behalf Of Martyn Thomas
>> Sent: Thursday, November 02, 2017 13:54
>> Cc: systemsafety at lists.techfak.uni-bielefeld.de
>> Subject: Re: [SystemSafety] "Security Risk" and Probability
>>
>> How can software be safe and not secure? Only by having no safety
>> function?
>>
>> Martyn
>>
>>> On 2 Nov 2017, at 18:30, Chris Hills <safetyyork at phaedsys.com> wrote:
>>>
>>> It is a question of levels.
>>>
>>> At the base level the quality of the SW is that it is robust and does exactly
>> what is intended no more and no less.
>>> This is why MISRA-C now applies to security as much as to safety.
>>>
>>> However, the functional aspects of the source code can be safe but not
>> secure, secure but not safe.
>>> In some cases (most I would venture) it is neither safe nor secure.
>>>
>>> Software that is both safe and secure I would suggest is very rare as the
>> requirements and design for a safe and secure system may be mutually
>> exclusive or chasing different goals such that compromised must be made.
>>> Back to the base level that once those compromises and design decisions
>> have been made then the software should fore fill  them precisely and
>> reliably under all conditions.
>>> Poor software can make a system insecure and unsafe.
>>> High quality software cannot on its own make a system either safe or
>> secure.
>>> -----Original Message-----
>>> From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-
>> bielefeld.de] On Behalf Of Peter Bernard Ladkin
>>> Sent: Thursday, October 26, 2017 8:15 AM
>>> To: systemsafety at lists.techfak.uni-bielefeld.de
>>> Subject: Re: [SystemSafety] "Security Risk" and Probability
>>>
>>> Following on from my blog post yesterday about people's attempts to
>> equate SILs, a safety requirement, with SLs, a security requirement, the
>> question remains why one might want to try to do so. An evident motivation
>> might be that both entail requirements on code quality. A higher SIL and a
>> higher SL both require higher-quality code.
>>> I give a simple example in
>>> https://abnormaldistribution.org/index.php/2017/10/26/code-quality-for-
>> safety-and-code-quality-for-security/
>>> of a design which has perfect code quality for safety properties and poor
>> code quality for security properties. Code quality cannot be measured on
>> one ordinal scale. It is multi-dimensional.
>>> That vitiates any argument through code quality for wanting to equate SILs
>> with SLs.
>>> That code quality is parametrised by properties is obvious when you think
>> about it. You write down the list of properties P you want the code to fulfil
>> and maybe it fulfils them. That doesn't necessarily say anything about
>> whether the code fulfils a completely different list of properties P'. But
>> people do seem to forget it frequently.
>>> 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
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20171102/df59f8af/attachment-0001.html>