1) 자산·안전기능·데이터흐름을 ‘안전 관점’으로 재정의
사이버보안 위협모델을 위해 시나리오로 연결할 때 가장 먼저 해야 할 일은, 보안 문서에서 말하는 “자산(Asset)”을 RMF가 이해하는 “안전 영향의 대상”으로 다시 정의하는 것입니다. 보안팀 관점의 자산은 계정, 키, 서버, 네트워크, 데이터베이스처럼 기술 요소로 정리되기 쉽지만, 위험관리 관점에서는 그 자산이 침해될 때 어떤 안전 기능이 흔들리고 어떤 위해상황이 열리는지가 핵심입니다. 따라서 변환의 출발점은 자산 목록을 나열하는 것이 아니라, 제품의 안전 관련 기능(Safety-related function) 과 안전 관련 데이터(Safety-related data) 를 분리해 식별하는 것입니다. 예를 들어 경보 임계값, 치료 파라미터, 환자 식별정보, 측정 원시데이터, 알고리즘 모델 파라미터, 로그/감사기록, 업데이트 패키지 검증 키는 모두 보안 침해가 곧 안전 위해로 연결될 가능성이 높은 항목입니다. 반대로 단순 UI 테마 설정이나 비안전 기능의 텔레메트리 값은 보안상 중요할 수 있어도 안전 위해 연결 강도는 낮을 수 있으므로 우선순위를 다르게 둘 수 있습니다.
다음 단계는 데이터 흐름(DFD)을 “통신 다이어그램”이 아니라 “안전 경로”로 보는 것입니다. 즉 어떤 데이터가 어디에서 생성되고(센서/사용자 입력/외부 시스템), 어디에서 처리되며(알고리즘/규칙 엔진), 어디에 저장되고(로컬/클라우드), 어떻게 표시·전달되는지(화면/알람/리포트) 중에서 안전 판단에 영향을 주는 경로를 표시해야 합니다. 여기서 실무적으로 중요한 포인트는 경계(Boundary) 정의입니다. 병원망, 클라우드, 모바일 앱, 유지보수 포트, 원격 업데이트 서버처럼 신뢰 경계가 바뀌는 지점은 위협이 ‘현실화’되는 지점이므로, 위해 시나리오의 촉진 조건으로 곧바로 연결됩니다. 특히 SaMD/연결형 의료기기는 “서버는 제품이 아니다”라는 예외를 두는 순간 안전 통제가 공중분해되기 쉬우므로, 서버 설정 변경과 배포 파이프라인을 안전 경로의 일부로 포함시키는 편이 정합성이 높습니다.
이렇게 안전 관련 자산과 경로가 정리되면, 보안 이벤트를 위해 시나리오로 번역할 때 ‘무엇이 중요한가’가 명확해집니다. 예컨대 위협모델에서 “권한 상승”은 보안 용어지만, 위해 시나리오에서는 “비인가자가 안전 관련 설정(임계값/알람)을 변경할 수 있는 상태”로 재서술됩니다. “데이터 변조”는 “측정값 또는 결과값이 변경되어 사용자가 잘못된 임상 판단을 하게 되는 상태”로, “서비스 거부(DoS)”는 “필수 경보/표시가 지연되거나 누락되어 이상 상태를 인지하지 못하는 상태”로 연결됩니다. 1단계의 목표는 보안 위협을 곧바로 위해로 점프시키지 않고, 안전 기능과 데이터에 대한 침해로 재정의해 연결 고리를 만드는 것입니다.
2) STRIDE/ATT&CK를 ‘안전 사건 흐름’으로 번역하는 6단계
보안 위협을 위해 시나리오로 정합화하려면, 위협 분류(STRIDE, ATT&CK 등)를 그대로 붙여넣는 대신 “사건 흐름” 문법으로 다시 써야 합니다. 실무에서 가장 안정적으로 작동하는 프레임은 다음 6단계입니다. (1) 공격자 전제(역량/접근 경로), (2) 공격 표면(진입점), (3) 악용 이벤트(취약점/오류), (4) 시스템 상태 변화(안전 기능·데이터 관점), (5) 탐지/전달 실패(또는 실패 가능성), (6) 위해상황→위해입니다. 이 6단계를 유지하면, 보안 문서의 기술 용어가 RMF의 위해 논리로 자연스럽게 변환되고, 통제와 검증 설계도 동시에 가능해집니다.
예를 들어 “Spoofing(가짜 신원)” 위협을 연결해 보겠습니다.
- 공격자 전제: 내부망 접근 또는 계정 탈취 가능
- 공격 표면: 원격 관리 콘솔, 유지보수 계정, API 토큰
- 악용 이벤트: 약한 인증/세션 관리로 비인가 로그인 성공
- 시스템 상태 변화: 안전 관련 설정 변경 권한 획득(임계값/알람/치료 파라미터)
- 탐지/전달 실패: 변경 로그는 남지만 현장에 실시간 알림이 없거나, 감사로그가 쉽게 검토되지 않음
- 위해상황→위해: 잘못된 설정으로 경보 미발생 또는 과다발생 → 이상 상태 인지 실패 또는 알람 피로 → 대응 지연/부적절한 처치
“Tampering(변조)”는 데이터 경로를 기준으로 쓰면 더 명확해집니다.
- 공격자 전제: 중간자(MITM) 가능 또는 저장소 접근 가능
- 공격 표면: 네트워크 전송 구간, 로컬 DB, 리포트 생성 모듈
- 악용 이벤트: 암호화/무결성 검증 미흡으로 데이터 수정
- 시스템 상태 변화: 측정값/결과값 무결성 붕괴(안전 판단 입력이 오염됨)
- 탐지/전달 실패: 이상치 감지 로직 부재 또는 사용자가 값의 비정상성을 알아채기 어려움
- 위해상황→위해: 잘못된 표시/리포트에 기반한 임상 판단 오류 → 불필요한 처치 또는 치료 지연
“DoS”는 단순 가용성 이슈로 끝내지 말고 안전 기능의 시간 제약과 연결해야 합니다.
- 공격자 전제: 트래픽 유발 또는 리소스 고갈 가능
- 공격 표면: 클라우드 API, 통신 게이트웨이, 이벤트 큐
- 악용 이벤트: 요청 폭주로 큐 드랍/타임아웃
- 시스템 상태 변화: 경보/표시 지연, 이벤트 누락, 데이터 갱신 정지
- 탐지/전달 실패: 시스템은 장애를 인지하나 사용자에게 “안전한 실패(safe state)”로 안내되지 않음
- 위해상황→위해: 이상 상태를 제때 인지하지 못하고 사용 지속 → 대응 지연 → 위해 발생
이 프레임에서 특히 중요한 포인트는 5단계(탐지/전달/해석)입니다. 보안 이벤트가 안전 위해로 확대되는 경로는 대개 “무엇이 잘못되었는지”를 현장이 알아채지 못하는 순간 열립니다. 그래서 위해 시나리오에서는 탐지와 사용자 커뮤니케이션을 독립 사건으로 다루는 것이 품질을 높입니다. 2단계의 결론은 STRIDE/ATT&CK가 제공하는 ‘분류’는 참고로 두고, RMF가 요구하는 안전 사건 흐름 6단계 문법으로 재작성하는 것입니다.
3) 통제 체계·검증·PMS까지 ‘보안-안전’ 한 줄 추적성으로 완성
보안 위협을 위해 시나리오로 연결하는 작업은 여기서 끝나지 않습니다. 실제 품질은 통제 선택과 검증이 위해 경로를 끊는 방식으로 설계될 때 완성됩니다. 따라서 각 시나리오에 대해 “어느 고리를 끊는가”를 기준으로 통제를 배치하고, 통제의 증거를 검증으로 남겨야 합니다. 실무적으로는 통제를 4개 층으로 정리하면 관리가 쉽습니다. (1) 예방(예: 강한 인증, 최소권한, 서명 검증), (2) 탐지(예: 무결성 체크, 침입 탐지, 이상 행위 탐지), (3) 대응/복구(예: 롤백, 안전 상태 전이, 키 폐기/회전), (4) 커뮤니케이션(예: 현장 알림, IFU 지침, 운영 절차). 이 4층을 위해 시나리오의 사건 흐름 위에 매핑하면, “암호화 했다” 같은 단편 통제가 아니라, 안전 위해를 줄이는 체계로 통제가 설명됩니다.
검증 설계는 ‘보안 시험을 했다’라는 선언이 아니라, 통제가 끊어야 할 사건 고리를 재현하는 방식으로 작성해야 합니다. 예를 들어 업데이트 패키지 변조 시나리오라면, 서명 검증이 실패하면 설치가 차단되는지(예방), 실패 이벤트가 감사로그에 남고 운영자에게 알림이 가는지(탐지/커뮤니케이션), 차단 후 시스템이 이전 안전 버전으로 유지되는지(복구), 현장에서 사용자가 어떤 행동을 해야 하는지 안내가 존재하는지(IFU)까지 확인해야 합니다. 계정 탈취 시나리오라면 MFA, 세션 타임아웃, 비정상 위치 로그인 차단 같은 예방 통제뿐 아니라, 설정 변경 시 이중 승인, 변경 즉시 알림, 변경 이력의 비가역성(로그 무결성)처럼 안전 기능 보호에 직접적인 통제를 시험해야 합니다. DoS라면 부하 조건에서 경보 기능이 어떻게 degrade되는지, 안전 상태 전이가 정의되어 있는지, “데이터가 갱신되지 않는다”는 사실이 사용자에게 명확히 전달되는지가 검증 포인트입니다.
마지막으로 PMS와 변경관리 연결이 없으면 정합성은 유지되기 어렵습니다. 취약점 정보(CVE), 침해 시도 로그, 보안 패치 적용, 제3자 라이브러리 업데이트는 RMF의 확률 가정과 통제 효과를 흔듭니다. 따라서 (1) 어떤 취약점 등급/영향 범위에서 RMF 재평가를 트리거할지, (2) 패치가 안전 기능에 미치는 영향을 어떻게 영향평가할지, (3) 보안 사고/근접사고가 발생했을 때 어떤 위해 시나리오를 우선 재검토할지 운영 규칙을 명시해야 합니다. 또한 보안 통제의 일부가 운영 절차(키 관리, 계정 발급, 접근권한 리뷰)에 의존한다면, 그 절차의 이행 증거가 품질시스템(QMS) 안에서 관리되어야 합니다. 그렇지 않으면 문서상 통제는 존재하지만 현장에서 작동하지 않는 ‘종이 통제’가 됩니다.
정리하면, 보안 이벤트를 안전 위해로 정합화하는 프레임의 핵심은 (1) 안전 관련 자산/기능/데이터 경로를 먼저 고정하고, (2) 공격 분류를 사건 흐름 6단계로 번역하며, (3) 예방-탐지-복구-커뮤니케이션 통제를 검증과 PMS/변경관리까지 한 줄로 연결하는 것입니다. 이 한 줄 추적성이 확보되면, 보안과 안전은 분리된 문서가 아니라 동일한 위험관리 체계 안에서 설명 가능한 근거로 통합됩니다.