[ABVM②] 취약점 악용 가능성 기반 대응 전략

기업 현재 환경서 취약점 악용 가능성·비즈니스 영향도 따른 대응 필요 패치 후 검증·예외처리 지속적 모니터링 필수

매일 수십 개의 새로운 공통 취약점 및 노출(CVE) 정보가 쏟아지고, 수천 개의 시스템에서 수만 개의 취약점이 발견되는 현실에서 모든 경고에 동일한 비중으로 대응하는 것은 불가능하다. 이는 제한된 보안 자원을 분산시켜 정작 중요한 위협을 놓치게 만드는 결과를 초래할 수 있다. 따라서 성공적인 취약점 관리의 핵심은 ‘선택과 집중’ 이다. 즉, 수많은 취약점 데이터와 조직의 내부 자산 정보를 지능적으로 결합해, 우리 조직에 실질적인 비즈니스 위험을 초래할 수 있는 ‘진짜 위협’을 식별하고, 명확한 근거에 기반해 처리 우선순위를 결정하는 체계적인 분석 및 평가 방법론이 필요하다.

이번 기고에서는 자산 인벤토리를 기반으로, 외부의 취약점 및 위협 인텔리전스 데이터를 결합해 실행 가능한 통찰(Actionable Insight)을 도출하는 기술적 방법론을 설명한다. 또한, 이론적인 평가를 넘어 실제 운영 환경에서 취약점을 효과적으로 조치하고, 불가피한 리스크를 체계적으로 관리하기 위한 현실적인 프레임워크를 제시하고자 한다.

취약점 분석과 위험 평가의 체계화

취약점 스캐너를 실행하고 결과 보고서를 나열하는 것은 진정한 의미의 취약점 관리가 아니다. 이는 단순한 데이터의 나열일 뿐, 의사결정을 위한 정보가 되지 못한다. 진정한 가치는 분절된 데이터들을 연결하고, 조직의 고유한 환경이라는 컨텍스트를 부여해 위험을 정량적으로 평가하는 과정에서 창출된다. 구체적인 방법은 다음과 같다.

✅ 자산 인벤토리와 CVE 정보의 지능적 매핑

사이버 보안 세계의 공통 언어인 CVE는 효과적인 취약점 관리의 기초가 된다. 하지만 매일 쏟아지는 CVE 정보의 홍수 속에서 우리 조직에 실제로 영향을 미치는 정보를 선별하는 것이 첫 번째 관문이다. 이를 위해서는 1부에서 구축한 동적인 자산 인벤토리와 실시간으로 유입되는 CVE 정보를 지능적으로 매핑하는 메커니즘이 필수다.

예를 들어, 아파치 스트러츠(Apache Struts)에서 원격 코드 실행이 가능한 치명적인 취약점(CVE-2017-5638)이 발표되었다면, 보안팀은 ‘아파치 스트러츠를 사용하는 서버가 있는지’ 확인하는 것을 넘어 ‘어떤 사업부가 운영하는 어떤 서비스의 어떤 서버에서, 해당 취약점의 영향을 받는 버전의 아파치 스트러츠를 사용하고 있으며, 그 서버가 인터넷에 직접 노출되어 있는가? 또한 그 서버가 처리하는 데이터는 무엇이며, 장애 발생 시 비즈니스에 미치는 영향은 어느 정도인가’와 같은 다차원적인 질문에 즉각적으로 답할 수 있어야 한다.

정교하게 구축된 자산 데이터베이스와 취약점 정보가 API를 통해 실시간으로 연동되어 있다면, 이러한 질문에 대한 답을 수 분 내에 얻을 수 있다. 이 시스템은 새로운 CVE가 발표되는 즉시, 자산 인벤토리에서 해당 소프트웨어(CPE)를 사용하는 자산을 자동으로 식별하고, 해당 자산의 비즈니스 중요도, 네트워크 위치 등의 컨텍스트 정보를 결합해 초기 위험 등급을 자동으로 부여하게 된다. 이는 수동으로 모든 서버를 점검하던 과거와는 비교할 수 없는 속도와 정확성을 제공한다.

✅ CVSS 점수의 맹점과 컨텍스트 기반 재해석

공통 취약점 평가 시스템(CVSS)은 취약점의 심각도를 0부터 10까지의 점수로 표현해 객관적인 기준을 제공하는 유용한 도구이다. 하지만 많은 조직이 이 CVSS 점수를 절대적인 기준으로 맹신하는 오류를 범한다. 우리가 흔히 접하는 CVSS 기본 점수(Base Score)는 취약점 자체의 기술적 특성, 즉 공격 복잡성, 필요한 권한, 사용자 상호작용 여부 등을 기준으로 산출된 이론적인 값일 뿐, 특정 조직에서의 실제 위험도를 그대로 반영하지는 않는다.

CVSS 기본 점수가 9.8점으로 평가된 매우 심각한 취약점이 발견되었다고 가정해 보자. 만약 이 취약점이 존재하는 시스템이 외부 네트워크와 완전히 분리된 폐쇄망의 연구 개발용 서버이고, 해당 서버에는 어떠한 중요 데이터도 저장되어 있지 않다면 실제 비즈니스 위험은 매우 낮을 수 있다. 반대로, CVSS 점수는 7.5점으로 상대적으로 낮지만, 해당 취약점이 인터넷에 직접 노출된 고객 결제 시스템에 존재한다면 이는 조직의 생존을 위협하는 치명적인 위험이 된다.

따라서 CVSS 점수를 올바르게 활용하기 위해서는 반드시 조직의 환경을 반영하는 환경 점수(Environmental Score)를 함께 고려해야 한다. 환경 점수는 자산의 중요도, 데이터의 민감도, 네트워크 위치와 같은 내부 컨텍스트를 반영해 기본 점수를 보정하는 역할을 한다.

한 제조업체에서 CVSS 9.0의 취약점(테스트 서버)과 7.5의 취약점(생산 라인 제어 시스템)을 동시에 발견했을 때, 비즈니스 영향도를 고려해 7.5 취약점을 우선 처리한 사례는 컨텍스트 기반의 위험 평가가 왜 중요한지를 명확히 보여준다.

✅ TI 연동, ‘이론적 위험’에서 ‘실제 위협’으로

자산 컨텍스트와 CVSS 환경 점수를 통해 취약점의 내부적인 위험도를 평가했다면, 다음 단계는 이 취약점이 외부에서 얼마나 활발하게 악용되고 있는지를 파악하는 것이다. 이 역할을 하는 것이 바로 위협 인텔리전스(TI)이다. 단순히 취약점이 존재한다는 사실을 아는 것과, 그 취약점을 악용하는 공격 코드가 이미 공개되었고 특정 공격 그룹이 이를 적극적으로 활용하고 있다는 사실을 아는 것은 위험의 시급성 측면에서 완전히 다른 차원의 문제이다.

TI는 현재 활동 중인 공격 그룹의 TTPs(전술, 기술, 절차), 그들이 주로 표적으로 삼는 산업군, 최근 유행하는 악성코드 등에 대한 정보를 제공한다. 예를 들어, 금융 기관을 주로 공격하는 특정 APT 그룹이 최근 A사의 VPN 장비 취약점을 집중적으로 악용하고 있다는 인텔리전스가 있다면, 금융 기관은 해당 VPN 장비의 패치를 다른 어떤 취약점보다도 최우선으로 적용해야 한다. 비록 해당 취약점의 CVSS 점수가 상대적으로 낮더라도, ‘실제 공격에 사용되고 있다’는 사실이 훨씬 더 중요한 판단 기준이 되기 때문이다.

이러한 실제 위협 정보를 보다 체계적으로 위험 평가에 통합하기 위해 최근에는 다음과 같은 지표들이 핵심적으로 활용된다.

EPSS(Exploit Prediction Scoring System): 특정 취약점이 향후 30일 내에 실제 공격에 악용될 가능성을 0%부터 100%까지의 확률 점수로 제공하는 예측 시스템이다. CVSS가 취약점의 심각도를 나타낸다면, EPSS는 악용 가능성, 즉 시급성을 알려주는 지표이다.

CISA KEV(Known Exploited Vulnerabilities) 카탈로그: 미국 사이버보안 및 인프라 보안국(CISA)에서 관리하는 목록으로, 이미 실제 공격에서 악용된 사례가 확인된 취약점들의 리스트이다. KEV에 등재된 취약점은 더 이상 이론적인 위험이 아닌, ‘검증된 실제 위협’으로 간주해야 한다.

가장 정교한 위험 평가는 CVSS(심각도) + 자산 중요도(비즈니스 영향) + EPSS(악용 가능성) + CISA KEV(실제 위협 여부)를 종합적으로 고려하는 다차원적인 모델을 통해 이뤄져야 한다. CVSS 점수가 다소 낮더라도 EPSS 점수가 높거나 CISA KEV 목록에 포함된 취약점은 즉각적인 조치가 필요한 최우선 대상으로 분류해야 한다.

withVTM 3.0 취약점 표준 평가 및 관리 체계

효과적인 취약점 조치와 리스크 관리

정교한 분석을 통해 처리해야 할 취약점의 우선순위를 결정했다면, 이제 이를 실제로 해결하는 ‘조치’ 단계로 넘어가야 한다. 그러나 이 단계 역시 기술적, 조직적 제약으로 인해 이상적으로만 진행되지는 않는다. 현실적인 접근과 체계적인 프로세스가 뒷받침되지 않으면, 잘 수립된 계획도 실행 단계에서 좌초될 수 있다.

✅ 패치 관리의 현실적인 접근법

발견된 모든 취약점을 즉시 패치하는 것이 가장 이상적인 시나리오지만, 현실에서는 불가능에 가깝다. 24시간 무중단 운영이 필수적인 핵심 서비스의 다운타임 문제, 패치 적용 후 발생할 수 있는 애플리케이션 호환성 이슈, 제한된 보안 인력 등 다양한 제약 사항이 존재하기 때문이다. 따라서 현실적이고 체계적인 패치 관리 전략이 필요하다.

• 우선순위 기반 패치 적용: 앞서 수립한 위험 평가 결과에 따라 패치의 우선순위를 명확히 결정한다. CISA KEV에 등재되었거나, 인터넷에 노출된 핵심 자산에 존재하는 치명적인 취약점은 ‘긴급 패치’로 분류해 24~48시간 내에 적용하고, 그 외의 취약점은 ‘정기 패치(월별 또는 분기별)프로세스에 따라 진행하는 등 명확한 SLA(Service Level Agreement)를 수립해야 한다.

• 사전 테스트 및 검증: 보안 패치가 오히려 시스템 장애의 원인이 되는 경우는 드물지 않다. 따라서 운영 환경에 패치를 적용하기 전, 반드시 개발 또는 스테이징 환경에서 충분한 사전 테스트를 거쳐야 한다. 이를 통해 패치로 인한 서비스의 성능 저하나 기능 오류가 없는지 검증하고, 안정성이 확보되었을 때 운영 환경으로 이관해야 한다.

• 보완 통제(Compensating Controls)의 활용: 패치를 즉시 적용하기 어려운 상황이라면, 위험을 방치하는 대신 보완 통제를 적용해 공격 표면을 줄여야 한다. 예를 들어, 웹 서버의 취약점을 당장 패치할 수 없다면, 웹 애플리케이션 방화벽(WAF)에서 해당 취약점을 악용하는 공격 패턴을 차단하는 가상 패치(Virtual Patching) 규칙을 적용할 수 있다. 또한, 해당 시스템에 대한 네트워크 접근 제어(ACL)를 강화하거나, 침입 방지 시스템(IPS)의 감시 수준을 높이는 등의 임시 조치를 통해 위험을 완화할 수 있다.

✅ 조치의 검증과 추적: ‘완료’의 진정한 의미

패치 적용이 ‘취약점 해결’을 의미하지는 않는다. 많은 조직이 패치 적용 후 검증 단계를 소홀히 해, ‘패치했다고 생각했던’ 시스템에서 보안 사고를 겪는다. 성공적인 조치 활동은 반드시 체계적인 검증과 추적 과정으로 마무리되어야 한다.

검증은 최소 3단계로 이뤄져야 한다. 첫째, 패치가 기술적으로 올바르게 설치되었는지 시스템 레벨에서 확인한다. 둘째, 취약점 스캐너를 다시 실행해 해당 취약점이 더 이상 탐지되지 않음을 객관적인 데이터로 확인한다. 셋째, 시스템과 서비스가 정상적으로 동작하는지 기능 및 성능 테스트를 수행한다.

모든 조치 활동의 이력(누가, 언제, 어떤 취약점에 대해, 어떤 조치를 수행했고, 그 검증 결과는 어떠했는지)은 상세하게 기록되고 중앙에서 관리되어야 한다. 이러한 기록은 향후 감사 대응, 사고 발생 시 원인 분석, 그리고 전체 취약점 관리 프로세스를 개선하는 데 매우 중요한 데이터 자산이 된다.

✅ 예외 처리와 위험 수용

모든 취약점을 100% 제거하는 것은 불가능하다는 현실을 인정하는 것에서 성숙한 리스크 관리가 시작된다. 벤더의 지원이 종료된 레거시 시스템, 패치 시 막대한 비즈니스 중단이 예상되는 특수 시스템 등은 취약점이 발견되더라도 즉시 조치하기 어려울 수 있다.

이러한 경우, 문제를 외면하는 것이 아니라 공식적인 위험 수용(Risk Acceptance) 프로세스를 따라야 한다.

• 위험 식별 및 문서화: 해당 취약점의 기술적 내용과 방치했을 경우 발생할 수 있는 비즈니스 영향을 명확하게 문서화한다.

• 보완 통제 구현: 가능한 모든 보완 통제를 적용해 잔여 위험(Residual Risk)을 최소화한다.

• 경영진 승인: 식별된 위험과 그 영향, 그리고 적용된 보완 통제에 대한 내용을 관련 비즈니스 책임자와 경영진에게 보고하고, 위험을 수용할 것인지에 대한 공식적인 승인을 득한다.

• 주기적인 재검토: 위험 수용은 영구적인 결정이 아니다. 해당 시스템을 대체할 새로운 기술이 등장했거나, 새로운 보완 통제 방법이 개발되는 등 상황이 변할 수 있으므로, 분기별 또는 반기별로 위험 수용 결정을 재검토하는 절차를 수립해야 한다.

이처럼 자산 컨텍스트에 기반한 정교한 위험 평가와 현실적인 조치 및 리스크 관리 프레임워크가 결합될 때, 비로소 조직은 정보의 홍수 속에서 방향을 잃지 않고, 제한된 자원으로 최대의 보안 효과를 달성할 수 있다.

---

원문 보기

데이터넷