- 클라우드와 코드 전반에 수천 개의 발견 사항
- 실제 위험을 반영하지 않는 심각한 심각도 점수
- 끝없는 스프레드시트, 회의, 수동 분류
- 제품 개선 대신 낮은 영향의 문제를 패치하는 데 소비되는 엔지니어링 시간
- 진정으로 익스플로잇 가능한 하나의 문제가 묻혀 있다는 지속적인 걱정
질문: 여기서 익스플로잇 가능한가요?
CVE는 어디서나 자동으로 익스플로잇 가능한 것이 아닙니다. 종이에 작성되어 책상 위에 있는 취약한 코드는 공격자가 컴퓨터에 접근하기 위해 실행할 수 없습니다. 시스템에 있어야 하고, 실행 중인 서비스의 일부여야 하며, 네트워크에 노출되어 있어야 하고, 인터넷으로 가는 경로가 있어야 합니다. 모든 취약점에는 이러한 요구사항이 있습니다. 공격자가 성공하기 위해 충족해야 하는 전제 조건의 체크리스트라고 생각하시면 됩니다. 익스플로잇 요구사항의 예시:- 운영 체제가 특정 유형이어야 함 (Windows vs Linux)
- 시스템 아키텍처가 특정 유형이어야 함 (x86_64 vs ARM/Graviton)
- 특정 기능이 켜져 있어야 함
- 서비스가 실행 중이고 네트워크를 통해 도달 가능해야 함
- 특정 버전의 소프트웨어 라이브러리가 있고 사용되어야 함
- 특정 하드웨어가 연결되어 있어야 함
예시: 서류상으로는 심각, 실제로는 익스플로잇 불가능
다음은 노이즈를 만들고 알림 피로를 유발하는 일반적인 경우들입니다. CVE는 일반 데이터베이스에서 심각으로 평가될 수 있지만, 익스플로잇 요구사항이 워크로드를 실제로 실행하는 방식과 맞지 않습니다.예시 1: Linux 워크로드의 Windows 전용 취약점 (CVE-2024-49138)
- 우리가 보는 것: CVE-2024-49138, 이 서버에 표시된 심각한 Windows 권한 상승 취약점.
- 익스플로잇 요구사항: 대상이 Windows를 실행 중이어야 함.
- 우리의 현실: 자산이 Linux를 실행 중.
- 결과: 이 자산에서 익스플로잇 불가능. 주의와 엔지니어링 시간을 경쟁할 필요가 없습니다.
예시 2: RDMA 요구사항 (CVE-2023-25775)
- 우리가 보는 것: CVE-2023-25775, Intel 이더넷 컨트롤러 RDMA 드라이버의 높은 심각도 취약점.
- 익스플로잇 요구사항: Intel RDMA 드라이버가 설치된 RDMA 가능 하드웨어.
- 우리의 현실: 표준 NIC, RDMA 없음.
- 결과: 이 자산에서 익스플로잇 불가능.
예시 3: 네트워크 도달 가능성 (CVE-2024-6387)
- 우리가 보는 것: CVE-2024-6387 (regreSSHion), OpenSSH의 심각한 원격 코드 실행 취약점.
- 익스플로잇 요구사항: OpenSSH 서버 (sshd)가 실행 중이고 공격자가 도달 가능해야 함.
- 우리의 현실: 이 자산에서 sshd가 실행되지 않음.
- 결과: 이 자산에서 익스플로잇 불가능.
운영 심각도: 우리에게 긴급한 것은?
취약점이 익스플로잇 가능하다는 것을 알게 되면, 다음 질문은 우선순위입니다: 우리 환경에서 얼마나 긴급하게 조치해야 하는가? 다음 사이에는 차이가 있습니다:- 기본 심각도: 추상적인 최악의 영향을 설명하려는 일반적인 점수 (CVSS 같은).
- 운영 심각도: 익스플로잇 가능성과 맥락을 기반으로 우리 자산과 환경에 대한 점수.
- 익스플로잇 불가능: 자신 있게 우선순위 낮추기.
- 익스플로잇 가능성 낮음: 우선순위 낮추되, 완전히는 아님 — 증거가 100% 확실하지 않음.
- 익스플로잇 가능성 높음: 먼저 수정하고, 종료까지 추적하며, SLA에 맞추기.
- 불분명/증거 누락: 수동으로 조사한 다음 결정.
설명 가능한 결정
저는 단순히 심각도 점수를 주고 보내드리지 않습니다. 신뢰할 수 있는 추론을 드립니다. 각 자산의 각 취약점에 대해, 저는 요구사항, 각 요구사항이 충족되는지 여부, 그리고 이를 뒷받침하는 증거와 추론을 보여드립니다. 즉, 항상 제기되는 질문에 답할 수 있습니다:- 왜 이것을 우선순위 낮췄나요?
- 무엇이 이것을 익스플로잇 가능하게 만들까요?
- 노출을 줄이기 위해 무엇을 바꿔야 하나요?
수정: 다음에 해야 할 것
취약점이 우리 환경에서 익스플로잇 가능하지 않을 때, 자신 있게 우선순위를 낮출 수 있습니다. 하지만 익스플로잇 가능할 때, 다음 질문은: 실제로 어떻게 처리할까요? 모든 익스플로잇 가능한 취약점에 대해, 저는 ROI로 순위가 매겨진 구체적인 조치의 우선순위 목록을 작성합니다. 각 조치는 수정해야 하는 것뿐만 아니라 얼마나 가치 있는지를 팀이 볼 수 있도록:| 우선순위 | 조치 | 하는 일 |
|---|---|---|
| 1 | 이미지 수정 | 이 CVE를 해결하고 단일 조치로 전체 플릿 전반에서 잠재적으로 수백 개를 해결 |
| 2 | 패키지 패치 | 이 자산의 영향받은 패키지에 대한 직접 수정 |
| 3 | 완화 | 벤더 패치를 기다리는 동안 노출을 줄이기 위한 보완 컨트롤 |
| 4 | 위험 수용 | 현재 수정이 가능하지 않을 때 위험이 이해되고 수용된다는 공식 인정 |
조율: 수정을 완료까지 추진
무엇이 중요한지 알면, 저는 일반적인 조율 비용 없이 팀이 수정할 수 있도록 도와드립니다:- SLA에 맞게 Jira 이슈 생성 또는 풀 리퀘스트 올리기
- 엔지니어가 조치할 수 있는 명확한 수정 지침 제공
- 영향 표시 (예: 이것을 수정하면 12개의 VM에서 158개의 취약점이 해결됨)
- 수정 사항 검증 및 루프 종료
- Slack, Microsoft Teams, 또는 이메일로 업데이트 유지
저의 혜택
노이즈 ~90% 감소
자산에서 실제로 익스플로잇 가능하지 않은 취약점을 필터링하여 알림 피로를 줄입니다. 백로그가 중요한 것으로만 줄어듭니다.
조사 시간 절약, 실제 위험 더 빠르게 수정
익스플로잇 가능한 것과 그 이유를 설명하고 (엔지니어와 감사인을 위한 감사 추적과 함께), 진정으로 수정이 필요한 취약점에 대한 수정을 완료까지 추진합니다.
ROI 우선 취약점 수정
모든 익스플로잇 가능한 취약점에 대해 ROI로 수정 조치의 우선순위를 지정합니다.
수정을 완료까지 추진
무엇을 수정할지 알면, Jira 이슈를 생성하거나 풀 리퀘스트를 올리고, 수정 사항을 검증하며, 루프를 종료합니다. 취약점이 단순히 파악되는 것이 아니라 해결됩니다.