Experimental Physics and Industrial Control System
|
Just to tack on if I missed it, the workshop also brought up the NIST recommendations 800-82 ( https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf). We can talk all we want about "security" and "safety", but until we define what that really means in each context, the discussion is another problem altogether. Especially with the phrase "safety-critical" -- formally verified code does not mean the communication network between meets the same level of safety. I really should read those ICALEPS reports though.
EPICS not being a source of malware is one thing, but what could happen to an epics system if malware is on the network is another. Just saying one has a "trusted developer" is already pushing the risk off on whoever validated that developer in the first place. "Where the trust falls" if you will. That's one reason inCommon is so interesting to me -- it is a pay-to-verify identify system at the organizational level.
Buying a commercial solution outright (EPICS or otherwise) shifts the risk and responsibility of what happens when there is a failure to the commercial partner. Like the DO-254 certification process -- as long as you know the requirements, it can be certified....until something happens that wasn't in the requirements.
Hi Shen,
Oh, yes. We’ll do all those things too as appropriate for each system if that time comes. As I mentioned to Jonathan, my aim in this post was only to share what the NASA GRC-ATF rationale is for getting EPICS on the agency’s “Assessed and
Cleared” list. This has nothing to do with how well suited it is for any specific use but rather is focused on it explaining why we have confidence that it won’t be a source of malware from a development point-of-view (hence the whole Trusted Developer/Trusted
Repository model).
In other words, we have to show that it is safe for the Agency to install at all before we can even begin to discuss if it is capable of being used to mitigate/control a given hazard inherent in the system that needs to be controlled. That
said, I’m encouraged by your response here.. It sounds like if/when we get to that point there is indeed a path for using it in situations that require safety critical controls.
Thank you!
/Rich
Rich,
To be compliant with the cybersecurity requirement, you might also consider to design the system as a whole together with your IT infrastructure.
For example, deploying a firewall dedicated to your instrument control to isolate your whole system from the public network, from your campus network, and from your office network in case you have dedicated firewall for that; or further
adopt other method (e.g., MFA) to restrict access to your facility instrument control network which could reduce the risk.
Together with the other technical solutions mentioned, you might be able to satisfy the needs.
Thanks,
Guobao
Thank you so much for your response. I must confess that my intent in this post was originally only to talk about software safety in the (NIST) context of safe from “vulnerabilities” due to “malicious code” from “bad actors” and such as
Open Source Software, but your work on showing how EPICS can also be used in safety critical applications to mitigate what we would call “hazardous” operations is equally important topic to us as well.
Is it your position that any software that has been demonstrated to be “safe” for use in mitigating risks to personnel health and safety is also safe from external vulnerabilities due to the development process? That seems logical to me.
However the verification process you are referring to seems like it is highly dependent on the specific application and specific integration of otherwise established code. My goal today is only to get feedback on the (NIST) trustworthiness of the developer
(ANL) and repository as (NIST) safe for use at NASA in non-safety critical applications.
That said, thanks again.. I’m saving your reply for after we’ve solved the supply chain reliability question and are working on using EPICS in safety critical applications to mitigate hazardous operations.
I’m eager to establish a process for using EPICS in
CAUTION:
This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC.
|
> "Given that EPICS is open source and used around the world, How do you know that EPICS is safe?"
> Question 2 - Has this question been addressed by anyone previously? .. and are there any charts or papers that I can cite and/or reference when I talk with the NASA CIO folks about EPICS and SSCRM.
Several years ago, staff at the University of Washington Medical Cyclotron Facility, and faculty and staff at the University of Washington Department of Computer Science and Engineering, did a multi-year project to apply modern formal verification
methods and technology both to the EPICS core and an EPICS application program (an EPICS database on an IOC).
The project and its results were reported at the 2017 ICALEPS meeting. The slides give a quick overview of the project:
- Replies:
- Re: [EXTERNAL] Re: EPICS Software Supply Chain Risk Management (SSCRM) Gedare Bloom via Tech-talk
- References:
- Re: EPICS Software Supply Chain Risk Management (SSCRM) Jonathan Jacky via Tech-talk
- Re: [EXTERNAL] Re: EPICS Software Supply Chain Risk Management (SSCRM) Evans, Richard K. (GRC-H000) via Tech-talk
- Re: [EXTERNAL] Re: EPICS Software Supply Chain Risk Management (SSCRM) Shen, Guobao via Tech-talk
- RE: [EXTERNAL] Re: EPICS Software Supply Chain Risk Management (SSCRM) Evans, Richard K. (GRC-H000) via Tech-talk
- Navigate by Date:
- Prev:
RE: A question on modbus Mark Rivers via Tech-talk
- Next:
Re: [EXTERNAL] Re: EPICS Software Supply Chain Risk Management (SSCRM) Gedare Bloom via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
<2023>
2024
- Navigate by Thread:
- Prev:
RE: [EXTERNAL] Re: EPICS Software Supply Chain Risk Management (SSCRM) Evans, Richard K. (GRC-H000) via Tech-talk
- Next:
Re: [EXTERNAL] Re: EPICS Software Supply Chain Risk Management (SSCRM) Gedare Bloom via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
<2023>
2024
|
ANJ, 12 Jul 2023 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|