<의료기기 사이버보안 개요>
- 질병을 진단, 치료, 경감, 처치, 예방할 목적으로 사용되는 제품
- 상해 또는 장애를 진단, 치료, 경감, 보정할 목작으로 사용되는 제품
- 구조 또는 기능을 검사, 대체, 변형할 목적으로 사용되는 제품
- 임신을 조절할 목적으로 사용되는 제품
-> 제품= 기구, 장치, 기계, 재료, 소프트웨어
-> 안전성, 유효성 등을 인정받아야 하기 때문에 업허가와 기기허가를 받아야한다
2) 의료기기 산업환경
- 규제기관 (식약처, FDA, IMDRF)
- 국제표준, 국내표준화 기구 (ISO, IEC, IEEE, KS, TTA)
- 시험, 평가, 인증기관 (KTC, KTL, KTR, TTA)
- 건강보험심사평가원, 한국보건의료원
3) 의료기기 소프트웨어
-> 하드웨어 의존 여부로 구분
- SaMD: 하드웨어 의료기기의 일부가 아닌 하나 이상의 의료 목적으로 사용하기 위한 소프트웨어
ex) 혈당 수준에 따라 적절한 인슐린 용량 계산하는 앱
기기의 마이크를 사용해 수면 중 호흡 중단을 감지하는 소프트웨어- SiMD: 하드웨어에 탑재되어 단독으로 의료목적을 수행할 수 없는 소프트웨어
ex) 전자건강기록시스템
맥박조정기를 작동시키는 소프트웨어
4) 혁신의료기기
- 의료기기중 기술집약도가 높고 혁신 속도가 빠른 분야의 첨단기술 적용이나 사용방법 개선 등을 통해 기존의 의료기기나 치료법에 비하여 안전성, 유효성을 현저히 개선하였거나 개선할 것으로 예상되는 의료기기
5) 디지털치료기기 (DTx)
= digital therapeutics
- 약이나 실제 수술을 통하지 않고 소프트웨어를 통해 치료목적을 달성할 수 있는 의료기기 (하드웨어 여부 상관X)
ex) 디지털 치료 앱
+)
- SOUP: 기성 소프트웨어, 의료용으로 개발되지 않은 소프트웨어 (출처를 알 수 없는 소프트웨어)
- Legacy device: 현재의 사이버보안 위협으로부터 적절하게 보호될 수 없는 의료기기 (EoL: 더이상 생산되지 않아 단종된 제품/ EoS: 더이상 업데이트를 지원하지 않는 제품)
6) 의료기기 관련 법
- 의료기기법, 체외진단의료기기법, 의료기기산업육성 및 혁신의료기기 지원법, 디지털의료제품법
7) 의료기기의 등급
- 의료기기가 인체에 미치는 잠재적 위험성
- 한국 4단계, 미국 3단계, 유럽 4단계로 나뉨
- 첨단 ICT기술을 활용한 SaMD 급성장
- 의료기기 사이버보안 규제 강화
- 의료기기 사이버보안 공격표면 증가
2) 의료기기 사이버보안 사고 사례
- 심장이식 관련 의료기기 해킹-> 데이터 수정, 제어 가능
- IoT 의료기기 네트워크 취약점 발견-> 네트워크 정보 복사
- 암 스캔 이미지를 컴퓨터 바이러스가 바꾸는 사례
3) 의료기기 사이버보안 위험
- 의료기기의 안전 (safety ISO, IEC guide 51)
허용할 수 없는 위험으로부터의 자유 (freedom from risk which is not tolerable)
(1) 위험: 피해발생의확률과 피해의 심각도의 조합
(2) 위험원: 피해의 잠재적 요인, 위해/ 사고의 원인
(3) 위해: 신체에 대한 물리적 부상 또는 환경/ 자산에 대한 물리적 피해
(4) 위험한 상황: 시림, 자산, 환경이 하나 또는 그 이상의 위험원에 노출된 상황
- 정보보안 (safety ISO, IEC guide 27000)
: 정보의 기밀성, 무결성, 가용성 유지
- 기밀성: 인가된 사용자만 정보 자산에 접근 가능 (방화벽, 비밀번호 등)
기밀성 공격: 스누핑 (데이터에 대한 비인가 접근 또는 탈취, 인터넷 전송 파일 가로채기/ 훔쳐보기), 트래픽 분석 (데이터를 이해할 수 없게 암호화해도 트래픽을 분석하여 다른 형태의 정보를 얻을 수 있음)- 무결성: 적절한 권한을 가진 사용자가 인가한 방법으로만 정보를 변경할 수 있도록 하는 것
무결성 점검: 해쉬함수 이용 (암호학적 해쉬함수 사용하여 변경여부 확인)
무결성 공격: 변경 (메시지 수정), 가장 (개체의 신분위장), 재연 (재전송을 통해 인가되지 않은 사항에 접근), 부인 (자신의 송/수신 사실 부인)- 가용성: 필요한 시점에 정보자산에 대한 접근이 가능하도록 하는 것)
가용성 공격: DoS공격, DDoS공격, 좀비PC -> 필요한 시점에 정보자산에 대한 접근이 불가해짐
+) 위험: 목적에 대한 불확실성의 영향 (기대했던것과 가른 영향, 위협이 정보자산의 취약점을 이용해 기관에 위해를 일으킬 수 있는 잠재성과 관련)
데이터, 정보 (보호하고자 하는 것들)- 기밀성, 무결성, 가용성
4) 의료기기의 사이버보안 대응
- 대표유형: 인증, 암호, 데이터보호, 플랫폼보호, 물리적보호
- 정보보안 위험 처리: 회피 (기능 삭제), 전가 (보험), 완화, 수용
- 의료기기 특성상 security의 영역보다 safety의 영역이 더 중요
- 의료기기 규정에는 일반 안전, 성능, 요구사항 외에도 사이버보안 요구사항이 포함됨
- ISO/IEC 27001
- ISO/IEC 27002
-> 모든 보안의 기본이며, 비교적 폐쇄적- NIST Cybersecurity Framework
- NIST SP 800-53
-> information sharing
+) ISO/IEC 81001, 81001-5-1, 60601-4-5 ...
- 범위: 기기소프트웨어 기능을 포함하는 기기, 소프트웨어/ 펌웨어를 포함하는 기기, 프로그래밍 가능한 로직을 포함하는 기기 +a => SiMD, SaMD, PLC등 포함
2) 기기 안전성 및 품질 시스템 규제의 일부인 사이버보안
- 의료기기 제조업체는 자사 제품이 해당 요구사항과 사양을 일관되게 충족하는지 확인하는데 도움이 되는 품질시스템을 수립, 준수해야 함
(21 CFR Part 820= Quality System Regulation)- SPDF (Secure 제품 개발 프레임워크): 의료기기 설계/ 제조 등 사용, 제품의 취약점 수와 취약점의 심각도를 식별하고 감소시키는데 도움이 되는 일련의 프로세스로 설계/개발~폐기를 포함한 제품 수명주기의 모든 측면을 포함
사용시 QS규정을 준수한다는 것을 보장할 수 있음
3) 보안설계
- FDA는 기판 전 제출물 검토시 기기 아키텍처 전반에 걸쳐 보안목표 (무결성 포함 진본성/ 권한부여/ 가용성/ 기밀성/ 안전하고 시의적절한 업데이트 및 패치 가능성)를 제공 및 구현할 수 있는 기기의 성능 +a를 기반으로 기기 사이버보안을 평가하고자 함.
시판 전 제출물은 위의 보안목표가 기기설계에서 어떻게 다루어지고 통합되었는지 기술하는 정보가 포함되어야 함.
4) 투명성
- 기기 사용자는 기기의 사이버보안 통제에 관한 정보, 의료기기 시스템에 대한 잠재적 위험 등에 접근할 수 있어야 함, 따라서 사이버보안 정보가 기기 라벨표시에 포함되어야 한다고 판단함.
-> Transparency: 사이버침해 시 기기의 안전성/ 효과성을 감소시키는 사이버보안 취약점/ 위험 공개, 안전한 기기 설정 및 업데이트 방법 수록, 개발시 포함된 모든 통신 인터페이스 /타사 소프트웨어 목록 공개- 필요한 사이버보안 관련 정보 부재로 인한 안전 및 유효성 문제 발생 가능
=> 투명성이 명확하지 않으면 기기안전, 유효성, 기기 관리 및 보호 능력이 떨어질 수 있음
5) SPDF (Secure Product Development Framework)_ 보안위험관리
- 기기가 작동하는 대형 시스템의 맥락에서 기기의 안전과 보안 위험을 평가해야함
- 보안 위험 관리는 Total Product Lifecycle (TPLC)동안 다루어져야함
- TPLC: 설계, 개발, 제조, 시판 후 모니터링, 기기 소프트웨어/ 펌웨어 업데이트 제공, 서비스
- 보안 위험 관리는 ISO 14971에사 기술하는 안전 위험 관리와 다름
=> 보안의 맥락과 안전의 맥락이 같지 않음. 피해의 범위, 평가 요인이 달라질 수 있음
- 보안 위험 관리: 직간접적 환자 피해를 초래할 수 있는 위험이 포함될 수도 있지만, 사업이나 평판 위험에 관한 FDA의 안전성/ 유효성 평가 범위를 벗어나는 위험도 존재 가능
안전 위험 관리: 신체 상해, 재산/ 환경 피해, 기기/ 시스템 불가용성으로 인한 치료지연/ 거부- 품질 시스템 프로세스: 기기에 대한 잠재적 위험 관리, 기기 출시 후 안전성/ 유효성 유지 보장에 필요한 기술/ 인사/ 관리 관행 (보안 포함)
- 보안 위험 관리의 목표: 안전하고 효과성 있는 의료기기 제조 및 유지 관리의 지원을 위해 QS규정에 기술된 것과 같은 기기 설계 프로세스 사용 권고
- Security Risk Management, Security Achitecture, Cybersecurity Testing
- SBOM: SW에 어떤 부품이 포함됐는지 알려주는 것이다. 개발사-공급사-운영사 간 정보 비대칭성을 해결해주는 게 핵심이다. SW부품 간 포함 관계를 확인할 수 있어 취약점 등 문제 발생 시 빠르게 대응할 수 있다.
- 의료기기 시스템에 대한 보안 위험 관리 문서화: 제조업체는 보안 위험 관리 계획 및 보고서 생성 권고: 시스템 위협 모델링, 사이버보안 위험 평가, 소프트웨어 구성요소 목록, 컴포넌트 지원 정보 +a
- 위협 모델링: 의료기기 시스템에 적합한 보안 위험 및 통제 수단을 식별하기 위한 위험 분석 활용의 일환
시판 전 문서에 포함: 의료기기 시스템 전반의 보안목표, 위험, 취약점 식별
TPLC동안의 위협의 영향을 예방, 완화, 모니터링, 대응하기 위한 대책 정의
위협 모델링 방법론 선택 근거 제공 필요- 위협모델
의료기기 시스템 위험 및 완화 식별, 사이버 보안 위험 평가 일환으로서의 완화 이전 및 이후 위험 공지
의료기기 시스템 또는 사용 환경에 대한 가정 명시 (ex) 병원 네트워크는 본질적으로 적대적이기 때문에 공격자가 패킷을 변경, 삭제, 재생할 수 있는 능력을 가지고 네트워크를 제어한다고 가정))
공급망, 제조, 배포, 다른 기기와의 상호운용성, 유지보수, 업데이트활동, 폐기 활동으로 유입될 수 있는 사이버보안 위험 파악
- 사이버보안 위험 평가 (1)
사이버보안 위험 평가의 일부로 잔여 위험에 대해 보안 위험 및 통제를 평가해야 함
사이버보안 관련 오류는 의도의 여부와 무관하게 발생할 수 있기 때문에 예측하기 어려움...- 보안 위험 평가 프로세스는 악용가능성 (취약점 악용 능력)에 중점을 둠
- 사이버보안 위험의 악용 가능성에 대한 시판 전 평가는 시판 후 발견된 취약성의 악용가능성 평과와 다를 수 있음
- 사이버보안 위험 평가 (2)
사이버보안 위험에 대한 허용 기준은 의료기기 시스템의 TPLC를 신중하게 고려해야 함 (기기가 출시 되면 사이버보안 문제를 완화하는 것이 더 어려울 수 있음)- 알려진 취약점은 합리적으로 예측 가능한 위험으로 평가되어야 함
- 사이버보안 시험 중에 식별된 취약성에 대한 사이버보안 위험 평가에서는 취약성의 악용가능성이 기기 수명주기에 걸쳐 증가할 가능성이 높음 -> TPLC 고려 필요
- CISA (CyberSecurity and Infrastructure Security Agency)의 KVEC (이미 알려진 악용 취약성 카탈로그)에서 식별된 취약성은 이미 악용되고있고 의료기기 시스템과 사용자를 위험에 노출시키고 있으므로 기기에서 제거하여 설계해야 함
- 상호운용성 고려사항
사이버보안 통제는 안전하고 효과적인 정보 교환 및 사용을 허용하기 위한 수단으로 사용해야하며, 사용자가 본인의 기기 데이터에 접근하는 것을 금지해서는 안됨- 상호운용성 기능과 관련된 적절한 사이버보안 위험 및 통제수단을 검토하고 본 지침 전반에 걸쳐 권고하는 대로 이같은 고려사항을 문서로 기록
- 상호운용성을 가능하게 하는 공통 기술 및 통신 프로토콜 (bluetooth, bluetooth low energy, network 등)을 사용하는 경우 안전 및 유효성 보장을 위해 이와 같은 통신을 위한 추가적 보안 통제가 필요한지 평가해야 함
- 제3자 소프트웨어 컴포넌트
의료기기에 기성품 (OTS) 컴포넌트가 통합될 경우 소프트웨어 컴포넌트의 보안 위험은 전체 의료기기 시스템 위험 관리 과정 및 문서화의 대상- 21 CFR 820.30(g)에 따라 설계 통제 수단을 준수했음을 입증하고 공급망 위험 관리 과정을 지원하기 위해 제조업체는 모든 소프트웨어를 대상으로 기기의 소프트웨어 컴포넌트를 모두 기록하고, 관련한 사이버보안 위험을 평가하고, 해당 위험을 해결하거나 완화해야 함
- 제3자 소프트웨어 컴포넌트_ SBOM
SBOM은 원활한 위험 관리 과정에 도움을 줌- 대상 소프트웨어: 제조업체 자체 개발 컴포넌트/ 제3자 컴포넌트 (독점, 구매/ 라이선스, 오픈소스 등)
- Upstream SW의존도 표시: 독점, 구매/ 라이선스, 오픈소스 등
- SBOM 관리: 기기 설정 관리의 일부로 유지, 시판 기기의 소프트웨어 변경 사항을 반영해 정기적으로 업데이트 지원, 문서화 지원 (21 CFR 820.30(j), 820.181)
- 미해결 이상에 대한 보안평가
Content of Premarket Submission for Device Software Functions은 기기 제조업체가 제출 당시 제품에 존재하는 소프트웨어 이상 목록을 제공하도록 권고 => 제조업체는 각 이상에 대해 기기의 안전성/ 유효성에 미치는 이상의 영향 평가를 수행. 해당 지침을 참조해 해당 기기의 시판 전 제출물에 포함하도록 권장되는 관련문서를 평가하도록 권고- 개발이나 테스트 과정에서 발견되는 일부 이상은 보안 영향을 미칠 수 있으며 취약점으로 간주될 수도 있음
- 안전성 및 유효성에 대한 영향 평가에는 이상의 잠재적 보안 영향에 대한 평가가 포함될 수 있음
- 현행 CWE (Common Weakness Enumeration)범주의 검토 역시 평가에 포함될 수 있음
- 보안 영향으로 발생하는 이상을 해결하기 위한 기준과 논거는 시판 전 제풀물에 포함되는 문서의 일부로 제공해야 함
- TPLC보안 위험 관리
보안위험 관리 문서 업데이트
FDA는 기기의 사용수명동안 위험 관리 문서가 현장 기기 (시판기기/ 단종된 사용기기)에 대한 위험관리의 차이점을 설명하도록 권고- 유효성 입증을 위해 제조업체는 시판 전 제출물과 해당 PMA연례 보고서 (21 CFR 814.84)에 조치 밒 측정 기준을 추적, 기록하여 제공하도록 권고
- 취약점이 식별 및 해결될 경우 조치들에 대한 평균을 제공해야 함
6) SPDF (Secure Product Development Framework)_ 보안위험관리
- 보안통제 구현
제조업체는 보안 통제를 통해 보안 목표 달성 가능, 통제= SPDF 필수요건- FDA가 권고한 보안통제세트의 범주: 인증, 권한부여, 암호, 코드/ 데이터/ 실행무결성, 기밀성, 이벤트 탐지/ 로깅, 복원력/ 복구, 업데이트/ 패치
- 정보인증/ 개체인증, 펌위어 업데이트/ 소프트웨어 업데이트
- MDCG 2019- 16
- IEC 62443-4-1: 산업자동화 제어시스템 보안에 대한 표준, 사업자동화 제어시스템의 현재와 미래의 보안 취약점을 다루고 완화할 수 있는 유연한 프레임워크 제공
- IEC/ ISO 81001-5-1
- IEC/ ISO 81001-2-2
- AAMI TIR 57