반응형
취약점 관리는 도구만 도입하면 해결될 것 같지만, 운영을 해보면 가장 어려운 건 “무엇부터 고칠지”를 결정하는 일이다.
현업은 늘 바쁘고, 패치는 서비스 중단 위험도 있다. 그래서 취약점은 쌓이고, 어느 순간부터는 목록만 늘어난다.
결국 취약점 관리는 스캐너보다 우선순위 체계가 핵심이라고 느낀다.
CVSS 점수만으로 우선순위를 정하면 어긋나는 경우가 많다
CVSS는 중요한 지표지만, 실제 영향도는 환경에 따라 달라진다.
- 외부 노출 시스템인지(인터넷 공개 여부)
- 공격 난이도(인증 필요 여부, 익스플로잇 존재 여부)
- 자산 중요도(개인정보/결제/인증 여부)
- 보완 통제 존재 여부(WAF 룰, 네트워크 차단, 권한 분리)
그래서 점수만 보고 “높다/낮다”로 처리하면, 실제 위험한 것부터 놓칠 수 있다.
실무에서 쓰기 좋은 우선순위 기준
내가 선호하는 방식은 단순하다.
- 외부 노출 + 원격 공격 가능 + 익스플로잇 존재: 최우선
- 인증/권한이 필요하지만 핵심 자산(개인정보/인증)과 연결: 상위
- 내부망이지만 횡이동 가능성이 큰 구간(AD, 관리서버): 상위
- 영향은 크지 않지만 반복적으로 누적되는 것: 계획 수립 후 처리
이렇게 “공격 가능성”과 “자산 중요도”를 함께 보고 순서를 잡으면, 설명 가능성이 좋아진다.
패치가 어려운 시스템은 ‘완화조치’도 운영으로 인정해야 한다
현장에서는 패치가 바로 안 되는 케이스가 많다.
- 레거시 시스템
- 벤더 지원 종료
- 운영 중단 비용이 큰 구간
이때 중요한 건 “그럼 방치한다”가 아니라, 완화조치를 명확히 남기는 것이다.
- 외부 노출 차단(ACL, 방화벽 정책)
- 취약 경로 차단(WAF 룰, 기능 비활성화)
- 권한 최소화(관리 포트 제한, 점프서버 강제)
- 모니터링 강화(탐지 룰, 이상 징후 알림)
완화조치도 문서화하고, 리스크를 감수하는 의사결정으로 남겨야 나중에 흔들리지 않는다.
마무리
취약점 관리는 “완벽하게 다 고친다”가 아니라, “위험한 것부터 줄여간다”에 가깝다고 느낀다.
우선순위를 정하고, 그 근거를 설명할 수 있으면 보안 담당자의 신뢰가 올라간다.
반응형