취약점 관리
더 많은 작업
- Vulnerability Management; 취약점 관리, 취약점 관리 프로세스
- 조직의 자산에 있는 취약점을 지속적으로 식별하고, 위험에 따라 우선순위를 정해 조치하며, 조치 결과를 검증하고 보고하는 순환 프로세스
취약점 평가가 한 번의 점검이라면 취약점 관리는 그 점검을 끝없이 돌리는 운영 체계이다. 새로운 취약점은 매일 공개되고, 자산은 계속 추가·변경되며, 공격자는 공개된 취약점을 빠르게 무기화한다. 그래서 취약점 관리는 "스캔을 몇 번 했는가"가 아니라 "위험한 취약점이 얼마나 빨리, 얼마나 확실하게 사라지는가"로 평가한다.
CISSP에서 이 주제는 두 곳에 걸쳐 있다. 6.4(테스트 결과 분석과 보고)는 테스트 결과를 조치(remediation)와 예외 처리(exception handling)로 연결하는 방법을, 7.8(패치와 취약점 관리)은 이를 보안 운영의 상시 절차로 구현하고 지원하는 방법을 다룬다. 국내 ISMS-P 인증기준 2.11.2(취약점 점검 및 조치)도 정기적인 취약점 점검과 신속한 조치, 최신 취약점 발생 여부의 지속적 파악과 영향 분석을 요구한다.
| 단계 | 주요 활동 | 산출물 |
|---|---|---|
| 0. 준비(자산 파악) | 자산 목록과 소유자, 중요도, 인터넷 노출 여부를 정리한다. 목록에 없는 자산은 관리되지 않는다 | 자산 목록, 스캔 범위 |
| 1. 식별 | 인증 스캔, 에이전트, 구성 점검, 소프트웨어 구성 목록(SBOM), 제조사 권고문, 위협 정보로 취약점을 찾는다 | 탐지 목록 |
| 2. 평가 | 오탐 제거, 실제 영향 확인, 보완 통제 존재 여부 확인 | 검증된 취약점 목록 |
| 3. 우선순위 | 심각도·악용 가능성·자산 중요도·노출도로 위험을 매기고 조치 기한을 정한다 | 위험 등급, 기한 |
| 4. 조치 | 패치, 구성 변경, 보완 통제, 위험 수용 중 하나를 선택해 실행한다 | 변경 요청, 조치 기록 |
| 5. 검증 | 재스캔이나 수동 확인으로 실제 해소를 확인한다 | 검증 결과 |
| 6. 보고 | 지표와 미조치 현황을 자산 소유자와 경영진에 보고하고 다음 주기에 반영한다 | 대시보드, 보고서 |
| 요소 | 근거 | 의미 |
|---|---|---|
| 심각도 | CVSS(FIRST) | 취약점 자체의 기술적 심각도 |
| 악용 가능성 | EPSS(FIRST) | 앞으로 30일 안에 실제 악용될 확률 추정치(0~1) |
| 실제 악용 여부 | CISA KEV(Known Exploited Vulnerabilities) 목록 | 실제 공격에 쓰이고 있음이 확인된 취약점 |
| 자산 중요도 | 자산의 중요도 평가기준, 업무 영향 분석 | 침해 시 업무·법적 영향 |
| 노출도 | 네트워크 위치, 인증 필요 여부 | 인터넷에 노출된 자산인가, 내부망 깊숙이 있는가 |
| 보완 통제 | 기존 통제 | 웹 방화벽 규칙, 분리, 비활성화된 기능 등으로 이미 위험이 줄었는가 |
미국 CISA는 BOD 22-01로 연방 기관이 KEV 목록의 취약점을 정해진 기한 안에 조치하도록 했다. 기본 기한은 2021년 이전에 CVE가 부여된 취약점은 6개월, 그 밖의 취약점은 2주이며, 위험이 심각하면 기한을 조정할 수 있다. CISA는 CVSS 점수도 계속 활용해야 하지만 실제 악용 여부를 우선순위에 반영해야 한다고 설명한다. 민간 조직도 이 방식을 참고해 "KEV 등재 + 인터넷 노출 + 중요 자산"을 최우선 등급으로 두는 경우가 많다.
| 조치 유형 | 내용 | 언제 쓰는가 |
|---|---|---|
| 패치·업그레이드 | 제조사 수정본을 적용한다 | 가장 기본이며 근본적인 해결. 상세 절차는 패치 관리 |
| 구성 변경 | 취약한 기능·프로토콜 비활성화, 설정 강화, 기본 계정 제거 | 패치가 없거나 설정 문제인 경우 |
| 보완 통제(compensating control) | 가상 패치(웹 방화벽·IPS 규칙), 네트워크 분리·접근 제한, 탐지 규칙 강화 | 패치를 당장 적용할 수 없을 때 위험을 낮추는 임시 또는 대체 수단 |
| 제거·교체 | 쓰지 않는 서비스나 지원이 끝난 제품을 없애거나 바꾼다 | 제품 지원 종료 자산 |
| 위험 수용 | 조치하지 않고 위험을 그대로 받아들인다 | 위험이 낮거나 조치 비용이 더 클 때. 반드시 아래 예외 처리 절차를 거친다 |
조치는 운영 시스템을 바꾸는 일이므로 변경 관리 절차를 따른다. 긴급한 경우에도 긴급 변경 절차로 기록을 남긴다. 조치 후에는 재스캔으로 검증해야 "조치 완료"가 된다. 담당자의 완료 보고만으로 닫지 않는다.
정해진 기한 안에 조치할 수 없는 취약점은 예외(exception)로 공식 처리한다. 예외는 "안 고친다"가 아니라 "위험을 알고, 책임자가 승인하고, 기한을 정해 관리한다"는 뜻이다.
| 요소 | 내용 |
|---|---|
| 사유 | 업무 영향(서비스 중단 불가), 제조사 패치 부재, 호환성 문제, 지원 종료 제품 등 구체적 근거 |
| 위험 평가 | 남는 위험(잔여 위험)의 크기와 영향 범위 |
| 보완 통제 | 예외 기간 동안 위험을 낮출 대체 통제(분리, 접근 제한, 가상 패치, 모니터링 강화) |
| 승인자 | 위험의 주인인 자산 소유자·경영진. 보안 담당자나 시스템 관리자가 혼자 승인하지 않는다. 위험 수용 참고 |
| 기한 | 만료일을 정하고 만료 시 재평가한다. 무기한 예외는 두지 않는다 |
| 기록·추적 | 예외 대장에 등록하고 정기적으로 경영진에 보고한다. 감사 시 증거가 된다 |
- 위험 등급별 평균 조치 기간(발견부터 검증 완료까지)
- 기한 내 조치율과 기한 초과 건수
- KEV 등재 취약점 미조치 건수
- 스캔 범위 대비 자산 목록 적용률(자산 커버리지)
- 유효한 예외 건수와 만료된 예외 건수
- 재발 취약점 비율
자세한 지표 설계는 보안 지표 문서를 본다.
| CISSP 항목 | 관점 | 이 문서와의 관계 |
|---|---|---|
| 6.2 보안 통제 테스트 | 찾기 | 취약점 평가, 모의 침투 테스트, 침해 공격 시뮬레이션이 취약점을 찾는다 |
| 6.4 결과 분석과 보고 | 판단하기 | 결과를 분석해 조치와 예외로 나누고, 외부 제품 취약점이면 취약점 공개 절차로 보낸다 |
| 7.8 패치와 취약점 관리 | 운영하기 | 위 주기를 상시 운영하고 패치 관리로 조치를 실행한다 |
| 7.9 변경 관리 | 통제하며 바꾸기 | 조치는 변경 관리 절차를 따른다 |
- 취약점 관리는 일회성 스캔이 아니라 식별 → 평가 → 우선순위 → 조치 → 검증 → 보고의 순환이다. 자산 목록이 출발점이다.
- 우선순위는 CVSS 점수만이 아니라 실제 악용 여부(KEV), 악용 가능성(EPSS), 자산 중요도, 노출도를 함께 본다.
- 패치를 바로 적용할 수 없으면 보완 통제를 적용하고 예외를 공식 승인받는다. 아무것도 하지 않는 것은 오답이다.
- 위험 수용(예외)은 자산 소유자·경영진이 승인하며 기한이 있어야 한다. 보안팀이 혼자 결정하는 선지는 오답이다.
- 조치 후 재스캔·검증까지 해야 종결이다.