본문 바로가기

인사이트

[규제 Insight] IEC 81001-5-1과 FDA Cybersecurity Guidance 분석

안녕하세요, 의료기기 규제 업무를 담당하고 있는 RA manager 이상준(Joseph)입니다.☺️

 

최근 의료기기 사이버 보안의 중요성이 강조되면서 규제가 강화되고 있는데요, 본 포스팅에서는 의료기기 사이버 보안의 핵심 규격이 되는 IEC 81001-5-1 Health software and health IT systems safety, effectiveness and security (Part 5-1)를 리뷰하도록 하겠습니다.🖊️

IEC 81001-5-1은 안전성, 효과성, 보안성 3가지를 모두 고려하는 지속적인 소프트웨어의 개선 방법을 제공하는 규격입니다. 소프트웨어의 개발부터 유지보수까지 전체 생명주기에 걸친 보안 요구사항을 정의하고 있어서 안전한 의료기기를 개발하는 데 큰 도움을 제공합니다.🔒 국내는 물론 FDA(미국 식품의약국), CE(유럽 적합성) 인증을 진행하기 위해서 꼭 알아야 할 규격이라고 할 수 있겠습니다.

 

 

FDA는 2022년 12월에 IEC 81001-5-1를 합의 표준에 등록했고, 2023년 9월에 Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions 가이던스 문서를 발행했습니다. 해당 가이던스에는 여러 중요한 개념이 존재하지만 대표적으로는 'SPDF(Secure Product Development Framework)'라는 안전한 제품을 개발하는 방법을 자세하게 다루고 있습니다.

 

💡SPDF란?
    - SPDF, 안전한 제품을 개발하는 프레임워크
    - JSP 나 IEC 81001-5-1 으로 적용할 수 있다고 FDA 가이던스에서 언급

"FDA recommends that manufacturers use device design processes such as those described in the QS regulation to support secure product development and maintenance. To preserve flexibility for manufacturers, manufacturers may use other existing frameworks that satisfy the QS regulation and align with FDA’s recommendations for using an SPDF. Possible frameworks to consider include, but are not limited to the medical device-specific framework that can be found in the Medical Device and Health IT Joint Security Plan (JSP) and IEC 81001-5-1.

Frameworks from other sectors may also comply with the QS regulations, like the framework provided in ANSI/ISA 62443-4-1 Security for industrial automation and control systems Part 4-1: Product security development life-cycle requirements."

출처:  Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submission, p.10

 

시간이 지날수록 사이버보안 위협은 새로 나타납니다. FDA는 제조사가 제품의 잠재적인 취약점들을 발견하고, 위험한 부분들을 계속 해결하는 프로세스를 보유하길 권고하고 있습니다. 이 프로세스는 IEC 81001-5-1과 밀접한 관련이 있기 때문에, 본 글에서는 해당 IEC 81001-5-1 규격을 소개드리도록 하겠습니다.

 

 


 

IEC 81001-5-1 은 크게 다음과 같은 목차를 갖고 있습니다. 

 

  • [4장] 일반요구사항
        - 제품 보안 관련 품질관리
        - 보안에 대한 위험관리 시스템 적용
  • [5장] 소프트웨어 개발 프로세스
        - 소프트웨어 보안 위험 요구사항 분석
        - 위협 완화 테스트 (Threat mitigation testing) ⭐
        - 취약 테스트 (Vulnerability testing) ⭐
        - 침투 테스트 (Penetration testing) ⭐
  • [6장] 소프트웨어 유지보수 프로세스
        - 소프트웨어 유지보수 계획 수립
        - 보안 위협을 방지하는 소프트웨어 업데이트 방식
  • [7장] 보안 위험관리 프로세스
        - 잠재적인 취약점, 위협 식별
        - 위험 측정&평가 > 위험 통제 > 통제에 대한 모니터링
  • [8장] 소프트웨어 형상 관리 프로세스
        - 제품 개발, 유지 관리, 형상 관리 프로세스 수립
  • [9장] 소프트웨어 문제 해결 프로세스
        - 잠재적인 보안 취약점 수집, 분석, 해결 프로세스 수립

 

또한 IEC 81001-5-1은 IEC 62443-4-1, IEC 62304와 밀접한 연관성을 갖고 있다고 합니다. 본 규격을 따르면 제조업체는 기존 소프트웨어 개발 프로세스에 보안적으로 안전한 소프트웨어 수명 주기를 구현할 수 있습니다!😎

 

💡IEC 62443-4-1: 산업제어시스템 보안 — 제4-1부: 안전한 제품 개발 생명주기 요구사항
💡IEC 62304: 의료기기 소프트웨어 ─ 소프트웨어 수명주기 프로세스

 

이제 본 규격의 항목을 간략하게 살펴보겠습니다.

 


 

🔖 [4장] 일반 요구사항 (품질관리 포함)

 

4장은 본 규격에서 품질관리와 관련된 내용을 다루고 있습니다. 기본적으로 품질 관리 시스템은 ISO 13485 또는 기타 동등한 품질 관리 시스템 표준에 따라 구현되어야 하며, 제조업체는 보안 관련 이슈를 공개하고, 정기적으로 보안 결함 관리를 검토해야 함을 언급하고 있습니다.

 

 

 

4장에서 주목해서 볼 만한 건 4.1.4 security expertise, 4.1.7 disclosing security-related issues 등이 있습니다. 4.1.4 에서는 ISO 13485 6.2 Human Resources 에서 다루는 것처럼, 보안 전문가의 직무에 직원 배정이 필요하며, 이에 대한 기록 자료가 필요함을 언급하고 있으며, 4.1.7 에서는 보안 관련 이슈를 규제 기관과 제품 사용자에게 신속하게 안내해야 하는 활동이 필요함을 안내하고 있습니다. 이때 4.1.7에는 Vulnerability(취약점) 과 CVSS(Common Vulnerability Scoring System)에 대한 내용을 포함하고 있는데, 해당 부분은 7장 보안 위험관리 프로세스에서 더욱 자세하게 다루고 있습니다.

 

 

🔖 [5장] 소프트웨어 개발 프로세스

 

5장에서는 수명주기 프로세스를 설정하고, 개발 환경의 보안을 유지하며, 안전한 코딩 표준(Secure coding)을 준수해야 함을 언급하고 있습니다. 또한 IEC 62304 에서도 언급되는 Software design(소프트웨어 설계), Software unit verification(유닛 검증), Software integration testing(통합 테스트), Software system testing(시스템 테스트) 등을 언급하고 있습니다.

 

5장에서 주의깊게 볼 수 있는 내용은 5.7.1 Security requirements testing, 5.7.2 Threat mitigation testing, 5.7.3 Vulnerability testing, 5.7.4 Penetration testing입니다. 이는 FDA 의 가이던스의 C. Cybersecurity Testing 와도 밀접하게 관련된 내용입니다.

 

Security requirements;

  • Manufacturers should provide evidence that each design input requirement was implemented successfully.
  • Manufacturers should provide evidence of their boundary analysis and rationale for their boundary assumptions.

Threat mitigation;

  • Manufacturers should provide details and evidence of testing that demonstrates effective risk control measures according to the threat models provided in the global system, multi-patient harm, updatability and patchability, and security use case views.
  • Manufacturers should ensure the adequacy of each cybersecurity risk control (e.g., security effectiveness in enforcing the specified security policy, performance for maximum traffic conditions, stability, and reliability, as appropriate).

✅ Vulnerability Testing (such as section 9.4 of ANSI/ISA 62443-4-1); and

  • Manufacturers should provide details and evidence61 of the following testing and analyses:
    • Abuse or misuse cases, malformed and unexpected inputs;
      • Robustness.
      • Fuzz testing.
      • Attack surface analysis;
      • Vulnerability chaining;
      • Closed box testing of known vulnerability scanning;
      • Software composition analysis of binary executable files; and
      • Static and dynamic code analysis, including testing for credentials that are "hardcoded," default, easily guessed, and easily compromised.*

Penetration testing;

  • The testing should identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product. Penetration test reports should be provided and include the following elements:
    • Independence and technical expertise of testers;
    • Scope of testing;
    • Duration of testing;
    • Testing methods employed; and
    • Test results, findings, and observations.

 

 

🔖 [6장] 소프트웨어 유지보수 프로세스

 

6장에서는 소프트웨어 유지보수 계획을 수립, 문제 모니터링, 보안 업데이트의 무결성 검증을 포함한 업데이트 유지관리를 다루고 있습니다.🔧 보안 문제가 발견될 경우 보안 취약점 해결을 위해서는 보안 업데이트가 필요하며, 이 과정에서 업데이트에 대한 무결성을 보장해야 되는 내용을 담고 있습니다.

 

 

 

본 6장에서는 제품 업데이트에 대한 무결성만을 언급하고 있지만, 무결성(Integrity)은 제품 보안 기능에서도 자주 언급되는 주요 목표입니다. Information Security Attributes 에서는 Confidentiality(기밀성), Integrity(무결성), Availabity(가용성)를 정보보안의 기본 3원칙으로 다룹니다. (*CIA Triad 라고도 합니다)

 

 

🔖 [7장] 보안 위험관리 프로세스

7장에서는 보안 위험 관리 프로세스를 설정하고, 취약점을 식별하며, 관련된 위협을 평가하고 통제해야 함을 언급합니다. 7.2 항에서는 취약점, 위협, 부정적인 영향을 식별에 대하여, 7.3 과 7.4 에서는 보안위험을 측정, 평가, 통제하는 활동이 설명됩니다. 특히 보안 위험은 CVSS 혹은 MITRE scoring 통해 취약점 측정이 가능합니다.

 

 

FDA Guidance에서는 Threat Modeling으로 보안 위험을 측정할 수 있음을 설명하고 있으며, 이 과정에서 MITRE의 Threat Modeling Playbook이 언급됩니다. 이와 관련하여, 보안 위험을 측정하고 평가하는데 있어서 CVSS 와 MITRE 에서 제공하는 scoring 툴을 활용할 수 있습니다.

 

 

 

추가적으로 취약점을 추적하는데 있어서는 CVE와 CWE를 사용할 수 있습니다. 공개된 취약점 모두 MITRE에서 제공하는 웹사이트에서 확인할 수 있습니다. 이 취약점에 대한 구체적인 내용은 9장에서 다룹니다.

 

 

🔖 [8장, 9장] 소프트웨어 형상 관리 프로세스 & 문제 해결 프로세스

 

8장에서는 소프트웨어의 형상관리 과정에서 소프트웨어의 구성 요소를 재현할 수 있는 기능을 제공해야 함을, 9장에서는 소프트웨어의 취약점 리뷰 및 분석을 통해 보안 문제를 처리해야 함을 언급합니다.🗣️

 

취약점을 분석하는 방법은 크게 취약점에 대한 영향 평가 → 해당 문제를 포함하는 제품 식별 → 문제의 원인 식별 → 제품에 미치는 영향 평가로 이루어집니다. 물론 이후 해당 보안 이슈를 해결하기 위해 활동을 수립해야 하며,  이 과정에는 periodc review(정기적 검토)가 필요합니다.

 

 

이 전체 프로세스는 FDA Cybersecurity Guidance 에서 언급하는 JSP(Joint Security Plan)에서도 확인할 수 있습니다. JSP 에서 다루는 제품 전 수명주기 보완 활동에는 Vulnerability Management 와 Patch/Software Update 이 포함되어 있으며, 이 전 과정이 주기적으로 반복되어야 함을 다루고 있습니다.

이렇게 본 규격인 IEC 81001-5-1은 소프트웨어 의료기기에 대한 안전성과 보안성을 확보하는데 필요한 전반적인 내용을 다루고 있습니다. IEC 81001-5-1 은 ISO 웹사이트에서 구매하실 수 있으니 참고 바랍니다.

(참고) IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security Part 5-1: Security — Activities in the product life cycle

 

 




의료기기의 사이버 보안은 점점 강화되고 있으며, 새로운 가이던스가 지속적으로 나오고 있습니다. 유럽 MDR 에서는 MDCG 2019-16 - Guidance on Cybersecurity for medical devices에서도 다루고 있으며, 새로 중요시되는 SBOM에 대한 가이던스도 중요해지고 있습니다.

앞으로도 꾸준히 에이아이트릭스 RA/QA 팀에서 소프트웨어 의료기기 관련한 규제를 소개 드리도록 하겠습니다. 감사합니다!🤓

 

 

에이아이트릭스 채용 바로가기> https://www.aitrics.com/career