공격자가 의료 기관보다 빠르게 움직이면 어떤 일이 발생할까?

보건 분야는 오래전부터 보안 문제를 패치하는 데 실질적인 장벽에 직면해 왔습니다: 병원의 보안 팀은 오후만에 임상 시스템의 취약점을 식별할 수 있을지라도, 안전하게 수정을 적용하는 것은 병원의 급박한 일상 업무 현실에 의해 보통 방해받습니다. 장치 제조업체는 업데이트를 검증해야 할 수도 있고, 병원은 이를 테스트하고 다운타임을 일정에 잡아야 하며, 일부 변경은 규제 검토까지 필요할 수 있습니다.

공격자는 이러한 제약에 전혀 구속받지 않습니다. AI 도구가 취약점 탐색·연구와 익스플로잇 개발을 가속화함에 따라, 이미 과부하 상태인 의료 분야의 복구 프로세스에 더욱 큰 압력이 가해지고 있습니다.

이 문제가 특히 고통스러운 이유는 패치 지연이 종종 공급업체 의존성에 의해 길어지기 때문입니다. 예를 들어 MRI 시스템의 수정이 공급업체의 검증을 필요로 할 수 있지만, 여전히 병원의 변경 관리 승인을 받아야 합니다. 그리고 이 모든 과정은 환자 치료를 방해하지 않아야 합니다.

Health-ISAC의 Frontier AI in the Health Sector 보고서는 지연된 패치를 해당 분야의 주요 노출 중 하나로 꼽고 있습니다. 따라서 병원은 한 가지 실현 가능한 방안을 가질 수 있습니다: 패치 일정의 모든 단계를 제어할 수는 없지만, 업데이트가 배포되는 동안 공격자가 할 수 있는 일을 제한할 수 있습니다.

패치 일정에 바닥이 존재하는 이유

Many of the steps in a hospital’s patching timeline may annoy information security professionals, but they exist to ensure patient safety. No untested update to a ventilator or an infusion pump that aims to close a cybersecurity risk is worth the cost of hindering patient care. The answer therefore, is to speed up the parts of the process that can be accelerated without weakening existing protocols.

감사인과 이사회는 종종 긴 복구 기간을 프로그램 성숙도나 예산 문제로 간주하는데, 때때로 이는 옳습니다. 일반적으로 긴 패치 일정은 실행력 부족, 자원 부족, 혹은 보안 팀이 통제할 수 없는 병목 현상의 증상입니다. 분석가를 늘리면 취약점 탐지·분류·우선순위 지정은 개선될 수 있지만, 제조업체의 일정이나 다운타임 창을 단축할 수는 없습니다.

취약점 악용이 공격자가 목표 네트워크에 접근하는 가장 일반적인 방법으로 떠오르면서, Verizon 2026 Data Breach Investigations Report (DBIR)는 조직이 패치를 배포할 여지가 얼마나 적은지를 보여줍니다. 알려진 악용 취약점을 완전히 복구하는 중앙값 시간이 2025년 32일에서 2026년 43일로 증가했으며, 완전히 해결된 취약점 비율은 38%에서 26%로 감소했습니다.

The fact that these figures are not specific to healthcare shows how difficult remediation already is, before accounting for the clinical and vendor constraints hospitals must also manage.

심각도 점수 너머를 바라볼 때가 왔다

While remediation windows have gotten longer, attackers have been getting faster. The DBIR found that vulnerability exploitation is now the leading way hackers get into systems, at 31% of breaches, passing stolen credentials for the first time in the 19 years the report has been published.

Verizon은 AI가 취약점 발견 및 악용을 가속화했으며, 이전에 몇 달이 걸리던 작업이 이제는 몇 시간 혹은 며칠 안에 이루어질 수 있다고 밝혔습니다. 그리고 이는 현재 세대의 최첨단 모델이 출시되기 전의 이야기이며, DBIR 데이터셋은 2025년 10월까지의 자료를 포함하고 있습니다.

하지만 요즘은 이런 속도가 당연시됩니다. Health-ISAC 보고서는 더 중대한 문제를 지적합니다: 최신 AI 모델은 낮은 심각도 발견을 연결해 중요한 공격 경로를 만들 수 있으며, 개별적으로는 중요해 보이지 않는 약점 조합을 식별합니다. 이는 심각도 점수에만 의존하는 복구 프로그램에 또 다른 문제를 야기합니다. 흔히 무시되거나 백로그에 밀려나는 낮은 심각도 취약점이 접근 권한이나 핵심 시스템에 영향을 미칠 경우, 그 중요성이 급격히 커질 수 있기 때문입니다.

증가하는 백로그는 상황을 더욱 악화시킵니다. Nature에 기고한 Max Planck Institute 소장 Thorsten Holz는 Mozilla가 최첨단 모델을 활용해 단일 Firefox 릴리스에서 271개의 취약점을 찾아 수정했으며, 이는 기존 도구와 리뷰어가 전년 대비 일반적인 한 달 동안 발견한 양을 훨씬 초과한다는 점을 설명했습니다.

이러한 분류 압박은 공급 측면에도 확대되고 있습니다. 리눅스 커널 유지관리자인 Linus Torvalds는 5월에 AI가 생성한 버그 보고서가 유지관리자를 과부하시키고 있다고 지적했습니다.

빠르게 수정할 수 없을 때는 접근 가능한 범위를 축소하라

다행히도, 제거할 수 없는 백로그도 관리할 수 있습니다. 패치를 기다려야 할 경우, 우선순위는 취약점이 악용될 가능성을 낮추는 것이어야 합니다. 이는 복구 속도에서 접근 가능성으로 작업 초점을 전환하는 것으로, 병원에서 제어 가능한 영역입니다.

세분화는 강력한 보완책이 될 수 있습니다. 광범위한 접근 권한을 가진 영상 장치는 도메인 컨트롤러, 파일 공유, 그리고 공개 인터넷에 도달할 수 있습니다. 그러나 해당 장치를 PACS 서버와 제조업체 업데이트 엔드포인트로의 트래픽만 허용하고, 기본적으로 나머지 접근을 차단하는 격리된 세그먼트에 제한한다면, 해당 장치에 영향을 미치는 취약점은 패치가 완료될 때까지 격리된 상태로 유지될 수 있습니다.

장치와 공급업체 요구사항이 허용하는 경우, 병원은 세분화, 외부 트래픽 제어 및 기본 차단 규칙을 활용해 패치가 진행 중일 때 접근 경로를 좁히거나 완전히 차단할 수 있습니다.

병원은 노출 표면을 축소하기 전에 전체 자산 목록을 완벽히 갖출 필요는 없습니다. 먼저 인터넷에 노출된 시스템을 파악하고, 전체 인벤토리가 확장되는 동안 그 수치를 최신 상태로 유지하며, 해당 시스템이 네트워크 내부에서 접근할 수 있는 범위를 제한하는 것을 우선순위에 두세요.

Health-ISAC 설문 조사 데이터는 업계가 이미 그 방향으로 움직이고 있음을 보여줍니다. 약 80%의 Health-ISAC 회원이 AI 기반 보안 도구 또는 취약점 평가를 위한 예산을 확대할 계획이라고 답했습니다. 유용할 수 있는 한 가지 방법은 자체 환경에서 어떤 공격 경로가 작동하는지 분석하는 것입니다: 우선순위 점수가 주목을 끌기 전에 주목할 만한 낮은 심각도 취약점 조합을 찾아보세요.

공급업체와의 대화에서도 서비스 수준 계약서의 문구를 넘어야 합니다. 계약서는 수년 전 양측이 약속한 내용을 담고 있지만, 위협 모델은 크게 변했습니다. 따라서 먼저 공개된 취약점에 대해 검증된 패치가 발행되는 데 걸리는 시간을 파악하고, 업데이트를 기다리는 동안 사용할 수 있는 완화 조치를 확인하세요. 또한 현재 AI 지원 공격 기법에 대해 제품을 테스트하는지 여부를 물어보는 것도 가치가 있습니다.

제거할 수 없는 노출을 관리하라

대부분의 조직은 익스플로잇이 공개된 후 검증된 수정이 실제 운영에 적용되기까지 걸리는 시간을 정확히 알지 못합니다. 그 기간을 파악하는 데 집중하면 패치 윈도우를 논쟁하는 대신 어떤 공급업체와 시스템이 가장 오래 노출되는지를 파악하는 데 초점을 맞출 수 있습니다. 이를 통해 복구 작업의 우선순위를 정할 수 있습니다.

정보 공유는 해당 의사결정 주기를 크게 단축시킬 수 있습니다. 제가 본 가장 빠른 복구 결정 중 일부는 병원이 동료로부터 취약점이 공개되기 전에 공급업체 플랫폼이 악용되고 있다는 소식을 들었을 때 이루어졌습니다.

검증 기간 자체가 확대되지는 않을 것입니다. 병원은 여전히 개방된 취약점을 가진 임상 시스템을 운영할 것이며, 이는 해당 시스템에 대한 세분화 전략이 패치 일정보다 더 중요하게 다루어져야 함을 의미합니다. 모든 병원은 각 핵심 플랫폼에 대해 내일 그 플랫폼이 침해될 경우 네트워크에서 어떤 일이 발생할지를 지정할 수 있어야 합니다.