Software implantierbarer Geräte

Sicherheit lässt sich programmieren

7. Oktober 2019, 10:15 Uhr | Daniel Kästner (Absint)

Fachbeitrag | Eine Fehlfunktion implantierter Medizingeräte kann schwerwiegende Auswirkungen haben. Die Sicherheit dieser Geräte muss daher gewährleistet sein, das gilt sowohl für die Hardware als auch die Steuerungssoftware. ...

Eine Fehlfunktion implantierter Medizingeräte kann schwerwiegende Auswirkungen haben. Die Sicherheit dieser Geräte muss daher gewährleistet sein, das gilt sowohl für die Hardware als auch die Steuerungssoftware. Durch statische Codeanalyse lassen sich zahlreiche kritische Programmfehler und -verwundbarkeiten ausschließen.

Literaturverzeichnis

1.    IEC/DIS 62304 – Draft International Standard, “Health software – Software life cycle processes,” 2018.

2.    U.S. Food and Drug Administration, Center for Devices and Radiological Health, “White Paper: Infusion Pump Improvement Initiative,” 2010.

3.    J. G. Ronquillo and D. M. Zuckerman, “Software-Related Recalls of Health Information Technology and Ohter Medical Devices: Implications for FDA Regulation of Digital Health,” in The Milbank Quaterly, vol. 95, pp. 535–553, Wiley Periodicals Inc., 2017.

4.    U.S. Food and Drug Administration, “FDA News Release. FDA warns patients and health care providers about potential cybersecurity concerns with certain Medtronic insulin pumps.” https://¬www.fda.gov/¬news-events/¬press-announcements/¬fda-warns-patients-and-health-care-providers-about-potential-cybersecurity-concerns-certain, 2019.

5.    U.S. Department Of Health and Human Services, Food and Drug Administration, Center for Devices and Radiological Health, Center for Biologics Evaluation and Research, “General Principles of Software Validation; Final Guidance for Industry and FDA staff,” 2002.

6.    “Medizinproduktegesetz in der Fassung der Bekanntmachung vom 7. August 2002 (BGBl. I S. 3146); zuletzt geändert durch Artikel 12 des Gesetzes vom 24. Juli 2010 (BGBl. I S. 983).”

7.    IEC 61508, “Functional safety of electrical/electronic/programmable electronic safety-related systems,” 2010.

8.    ISO/FDIS 26262, “Road vehicles – Functional safety,” 2018.

9.    CENELEC EN 50128, “Railway applications – Communication, signalling and processing systems – Software for railway control and protection systems,” 2011.

10.    Radio Technical Commission for Aeronautics, “RTCA DO-178C. Software Considerations in Airborne Systems and Equipment Certification,” 2011.

11.    IEC 60601-1:2005/AMD1:2012, “Medical electrical equipment – Part 1: General requirements for basic safety and essential performance,” 2012.

12.    IEC 61010-1:2010, “Safety requirements for electrical equipment for measurement, control, and laboratory use – Part 1: General requirements,” 2010.

13.    DIN EN 62304; VDE 0750-101:2016-10, “Medical device software – Software life cycle processes,” 2016.

14.    EN 45502-1:2015, “Implants for surgery. Active implantable medical devices. General requirements for safety, marketing and for information to be provided by the manufacturer,” 2015.

15.    ISO 14708-1:2014, “Implants for surgery – Active implantable medical devices. Part 1: General requirements for safety, marketing and for information to be provided by the manufacturer,” 2014.

16.    ISO 14971:2007-03, “Medical devices - Application of risk management to medical devices,” 2007.

17.    ISO 13485:2016, “Medical devices – Quality management systems – Requirements for regulatory purposes,” 2016.

18.    FDA. US Food and Drug Administration, “CFR – Code of Federal Regulations Title 21. Part 820. Quality System Regulation.” \http://¬www.accessdata.fda.gov/¬scripts/¬cdrh/¬cfdocs/¬cfCFR/¬CFRSearch.cfm, 2010.

19.    ISO/IEC 15408, “Informationstechnik – IT-Sicherheitsverfahren – Evaluationskriterien für IT-Sicherheit,” 2008/2009.

20.    ISO/IEC 27001, “Informationstechnik – IT-Sicherheitsverfahren – Informationssicherheits-Managementsysteme – Anforderungen,” 2013.

21.    DIN EN IEC 62443, “Normenreihe Industrielle Kommunikationsnetze - IT-Sicherheit für Netze und Systeme,” 2009-2018.

22.    SAE International, “SAE J3061. Cybersecurity Guidebook for Cyber-Physical Vehicle Systems,” 2016.

23.    IEC TR 63069, “Industrial-process measurement, control and automation – Framework for functional safety and security,” 2019.

24.    R. Bloomfield and R. Stroud, “Security-Informed Safety ”If it’s not secure, it’s not safe”,” in Safecomp 2013 FastAbstract (M.-O. Killijian, ed.), (Toulouse, France), p. NC, Sept. 2013.

25.    “MISRA-C:2012 Guidelines for the use of the C language in critical systems,” Mar. 2013.

26.    Software Engineering Institute SEI – CERT Division, SEI CERT C Coding Standard – Rules for Developing Safe, Reliable, and Secure Systems. Carnegie Mellon University, 2016.

27.    ISO/IEC, “Information Technology – Programming Languages, Their Environments and System Software Interfaces – Secure Coding Rules (ISO/IEC TS 17961),” Nov 2013.

28.    The MITRE Corporation, “CWE – Common Weakness Enumeration.”

29.    AbsInt GmbH, “RuleChecker Website.” http://¬www.AbsInt.com/¬rulechecker.

30.    J. Lions et al., “ARIANE 5, Flight 501 Failure,” Report by the Inquiry Board, 1996.

31.    M. Barr, “Bookout v. Toyota, 2005 Camry software Analysis by Michael Barr.” http://¬www.safetyresearch.net/¬Library/-BarrSlides_FINAL_SCRUBBED.pdf, 2013.

32.    N. G. Leveson and C. S. Turner, “An investigation of the therac-25 accidents,” Computer, vol. 26, pp. 18–41, July 1993.

33.    P. Cousot and R. Cousot, “Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints,” in POPL ’77: Proceedings of the 4th ACM SIGACT-SIGPLAN symposium on Principles of programming languages, (New York, NY, USA), pp. 238–252, ACM Press, 1977.

34.    D. Kästner, A. Miné, L. Mauborgne, X. Rival, J. Feret, P. Cousot, A. Schmidt, H. Hille, S. Wilhelm, and C. Ferdinand, “Finding All Potential Runtime Errors and Data Races in Automotive Software,” in SAE World Congress 2017, SAE International, 2017.

35.    AbsInt GmbH, “aiT WCET Analyzer Website.” http://¬www.AbsInt.com/¬ait.

36.    AbsInt GmbH, “StackAnalyzer Website.” http://¬www.AbsInt.com/¬stackanalyzer.

37.    D. Kästner, “Applying Abstract Interpretation to Demonstrate Functional Safety,” in Formal Methods Applied to Industrial Complex Systems (J.-L. Boulanger, ed.), London, UK: ISTE/Wiley, 2014.

38.    D. Kästner, L. Mauborgne, and C. Ferdinand, “Detecting Safety- and Security-Relevant Programming Defects by Sound Static Analysis,” in The Second International Conference on Cyber-Technologies and Cyber-Systems (CYBER 2017) (J.-C. B. Rainer Falk, Steve Chan, ed.), vol. 2 of IARIA Conferences, pp. 26–31, IARIA XPS Press, 2017.

39.    AbsInt GmbH, “Astrée Website.” http://¬www.AbsInt.com/¬astree.

40.    A. Miné, L. Mauborgne, X. Rival, J. Feret, P. Cousot, D. Kästner, S. Wilhelm, and C. Ferdinand, “Taking Static Analysis to the Next Level: Proving the Absence of Run-Time Errors and Data Races with Astrée,” Embedded Real Time Software and Systems Congress ERTS 2, 2016.

41.    D. Kästner, M. Mauborgne, S. Wilhelm, B. Schmidt, M. Schlund, and C. Ferdinand, “Analyze This! Sound Static Analysis for Integration Verification of Large-Scale Automotive Software,” in SAE World Congress 2019, Submitted for Publication, SAE International, 2019.

42.    P. Kocher, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom, “Spectre attacks: Exploiting speculative execution,” ArXiv e-prints, Jan. 2018.

43.    X. Leroy, S. Blazy, D. Kästner, B. Schommer, M. Pister, and C. Ferdinand, “CompCert - A Formally Verified Optimizing Compiler,” in ERTS 2016: Embedded Real Time Software and Systems, 8th European Congress, (Toulouse, France), SEE, Jan. 2016.

44.    D. Kästner, L. Mauborgne, and C. Ferdinand, “Practical Experience on Qualifying a Formally Verified Compiler: Reducing V&V Effort with CompCert,” Forum Safety and Security, 2018.

 

 


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu AbsInt Angewandte Informatik GmbH