취약점 100개 중 실제로 뚫리는 것은 몇 개인가

[관점]

국내 취약점 진단은 발주처가 제공한 자산 목록에서 시작한다. 목록에 없는 자산이 구조적으로 보이지 않는 구조이며, 실제 침해는 그 목록 밖에서 시작되는 경우가 적지 않다.

「공격자 관점」이 태도가 아니라 데이터 소스의 문제라는 지적이 국내에서 특히 유효한 이유가 여기에 있다. 출발점을 자산 목록에서 도메인·인증서·IP 등록 정보 같은 외부 관측 데이터로 옮기면, 목록과 실제의 차이가 첫 산출물로 나온다. 그 차이가 대개 가장 위험하다.

목록 길이와 실효성의 반비례

취약점 진단 보고서를 받아 본 사람이면 안다. 수천 건이 산출된다. High 만 추려도 수백 건이다. 그리고 그 수백 건을 다 조치할 인력은 어느 조직에도 없다.

그래서 다들 같은 걸 한다. CVSS 점수로 줄을 세운다. 9.8 부터 위에서 아래로 내려가면서 처리한다. 합리적으로 보이고, 감사 대응에도 설명이 되고, 무엇보다 기준이 명확하다.

문제는 CVSS 가 「이 취약점이 이론적으로 얼마나 나쁜가」를 재는 척도지, 「우리 환경에서 실제로 뚫리는가」를 재는 척도가 아니라는 점이다. 인터넷에서 도달할 수 없는 내부망 서버의 CVSS 9.8 과, 외부에 노출된 채 기본 자격증명이 살아 있는 CVSS 6.5 중 어느 쪽이 먼저 털릴지는 점수가 알려주지 않는다.

Pentera 의 Yuval Lazar 가 쓴 글이 정확히 이 지점을 짚는다. 조치 대상을 개수가 아니라 실제 익스플로잇 가능한 소수로 좁히라는 것이다.

원문의 4단계

원문이 제시하는 순서는 이렇다.

Take the Adversarial Perspective — 공격자 관점을 취한다
Expand Coverage of Your Exploitable Attack Surface — 익스플로잇 가능한 공격 표면으로 커버리지를 넓힌다
Automate Security Validation for Continuous Testing — 검증을 자동화해 상시화한다
Align to MITRE ATT&CK and OWASP Top Ten — 결과를 MITRE ATT&CK 과 OWASP Top Ten 에 매핑한다

골자는 이렇다. 방어자의 자산 목록에서 출발하지 말고 공격자가 밖에서 보는 노출면에서 출발할 것, 이미 아는 자산 너머까지 범위를 넓힐 것, 한 번 보는 게 아니라 계속 볼 것, 그리고 결과를 공통 프레임워크에 붙여 우선순위와 커뮤니케이션의 언어를 통일할 것.

전문은 원문에서 읽으시기 바란다 — 아래 「원문 출처」에 두 링크를 모두 걸어 두었다.

국내 적용 관점

1. 「공격자 관점」은 태도가 아니라 데이터 소스의 문제다.

국내 취약점 진단은 대부분 자산 목록을 받아서 시작한다. 발주처가 IP 대역과 서버 목록을 주고, 수행사가 그 목록을 훑는다. 이 구조에서는 목록에 없는 자산이 구조적으로 안 보인다. 그런데 실제 침해 사고의 상당수는 그 목록에 없던 것에서 시작한다 — 퇴사자가 띄워 놓고 간 테스트 서버, 인수한 계열사가 들고 온 미등록 대역, 마케팅팀이 외주로 만든 캠페인 페이지.

자산 목록 기반과 외부 관측 기반의 시야 차이 Deloitte One Cyber & Resilience

공격자 관점을 취한다는 건 마음가짐을 바꾸는 게 아니라 출발점을 자산 목록에서 도메인·인증서·IP 등록 정보 같은 외부 관측 데이터로 바꾸는 것이다. 그러면 목록과 실제의 차이가 첫 산출물로 도출된다. 그 차이가 대개 가장 위험하다.

2. CVSS 를 버리라는 말이 아니다 — 두 번째 필터를 두라는 말이다.

국내에서 CVSS 기반 우선순위는 이미 ISMS-P 증적, 내부 감사, 협력사 SLA 에 깊이 박혀 있다. 이걸 걷어내자는 제안은 현실적이지 않고, 원문도 그렇게 말하지 않는다.

실무적으로 가능한 건 순서를 하나 추가하는 것이다. CVSS 로 1차 정렬한 뒤, 그 상위 목록에 대해 「이게 우리 환경에서 실제로 체인이 이어지는가」를 검증하는 단계를 추가한다. 실제로 이어지는 것이 위로 올라온다. 감사 증적은 CVSS 정렬로 그대로 유지되고, 조치 순서만 검증 결과를 반영한다. 기존 체계를 갈아엎지 않고 얹을 수 있다는 점이 도입 승인에서 결정적이다.

3. 「상시화」는 도구가 아니라 조치 SLA 가 정한다.

검증 주기를 연 1회에서 월 1회로 바꾸면 발견 건수도 12배가 된다. 조치 조직과 SLA 가 그대로면, 늘어난 건 발견 건수가 아니라 미조치 잔량이다. 그리고 미조치 잔량은 다음 감사에서 그 자체로 지적 사항이 된다.

주기를 당기기 전에 조치 소유자와 기한을 먼저 정하십시오. 순서를 바꾸면 도구 도입이 감사 리스크를 만드는 역설이 발생한다.

4. MITRE ATT&CK 매핑은 기술 문서가 아니라 보고 문서를 위한 것이다.

원문의 4단계가 ATT&CK·OWASP 매핑으로 끝나는 이유는 기술적 정확도 때문이 아니다. 경영진과 이사회에 설명할 공통 언어가 필요하기 때문이다. 「CVE-2024-xxxxx 3건 미조치」는 임원 회의에서 아무 판단도 이끌어내지 못하지만, 「초기 침투부터 자격증명 탈취까지 경로가 검증됐고 그중 2단계가 열려 있다」는 예산 결정을 이끌어낸다.

국내에서 ATT&CK 매핑을 기술팀 내부 문서로만 쓰는 경우가 많은데, 원래 자리는 보고 라인이다.

출처 · Pentera, 4 Steps to Identifying Your Exploitable Attack Surface (2024-01-17, Yuval Lazar (Technical Product Manager & Senior Security Researcher, Pentera))