취약점 대응은 사이버 보안 분야에서 운영 측면에서 가장 많은 노력을 요하는 분야 중 하나입니다. 하지만 프로그램이 어려움을 겪는 부분은 취약점을 파악하는 데 있는 경우가 거의 없다. 많은 조직의 경우, 진정한 과제는 촉박한 시간 제약 속에서 수정 조치를 일관되게 실행하고 그 효과가 있는지 확인하는 데 있습니다.
이 글에서는 실행 메커니즘에 중점을 둡니다. 즉, 우선순위가 지정된 목록을 배포 계획으로 전환하고, 문제 해결과 완화 조치 중 어떤 조치를 취할지 결정하며, 자동화를 안전하게 관리하고, 팀 간 협업을 조정하며, 수정 조치를 통해 취약점이 해결되었는지 확인하는 과정을 다룹니다. 개별 단계뿐만 아니라 취약점 수정 프로세스 전반을 이해하는 것이야말로, 위험을 지속적으로 줄이는 프로그램과 측정 가능한 결과 없이 단지 활동만 양산하는 프로그램을 구분 짓는 핵심 요소입니다.
취약점 대응이 실제로 무엇을 포함하는지
프로그램에서 발생하는 취약점의 유형, 즉 소프트웨어 결함, 잘못된 구성 및 기타 보안 취약점 등은 각각 서로 다른 해결 방안이 필요합니다. 취약점 수정이란 시스템, 애플리케이션 또는 구성에서 보안 취약점을 식별하고 우선순위를 정한 후 이를 제거하는 과정을 말합니다.
이는 ‘ ’ 취약점 관리 라이프사이클의 실행 및 검증 단계를 나타내며, 이 단계에서는 우선순위가 지정된 분석 결과를 시정 조치로 전환하고 그 결과를 검증합니다. 광범위한 사이버 보안 환경에서, 문제 해결은 어떤 부분이 노출되었는지 파악하는 것과 위험을 줄이는 것 사이의 중요한 가교 역할을 합니다.
[자산의 중요도와 측면 이동 위험이 어떻게 CVSS 점수를 실제 비즈니스 위험 노출을 반영하는 우선순위 결정으로 전환하는지 알아보세요]
이론적으로는 간단해 보이지만, 바로 이 부분에서 대부분의 프로그램이 어려움을 겪기 시작합니다.
문제 파악, 우선순위 설정 및 실행 워크플로가 통합되지 않으면 문제 해결이 종종 차질을 빚게 됩니다. 사용 중인 스캐너에서 심각한 CVE가 발견되었습니다. 이 발견 사항은 보안 대시보드에 표시되어 있는 반면, IT 운영팀은 별도의 티켓 관리 시스템을 통해 업무를 수행하고 있으며, 두 시스템 간에 일관된 업무 인계 절차가 마련되어 있지 않습니다. 날들이 지나간다. 이 취약점은 여전히 노출된 상태이며, 이러한 지연으로 인해 공격자가 이를 악용할 수 있는 시간이 직접적으로 늘어납니다.
IT와 SecOps 간의 업무 인계 과정은 또 다른 흔한 문제 지점을 야기합니다. 보안 팀은 위협을 파악하고 우선순위를 정합니다. IT 운영 부서는 시스템을 관리하며 문제 해결을 수행합니다. 배포 상태와 검증 결과에 대한 공동 가시성이 확보되지 않으면, 양측 모두에서 티켓이 조기에 종결됩니다. 대응 조치가 이루어지지 않으면, 우선순위가 적절히 설정된 취약점조차도 계속해서 노출된 상태로 남아 있을 수 있습니다.
[취약점 관리 프로그램이 진정한 의미에서 ‘지속적’으로 인정받기 위해 충족해야 할 다섯 가지 조건을 확인해 보세요]
그리고 검증 격차도 있습니다. 패치가 배포됩니다. 티켓 판매가 마감됩니다. 하지만 그 취약점이 엔드포인트에서 실제로 사라진 것일까, 아니면 여전히 다른 경로를 통해 접근하거나 악용할 수 있는 상태일까? 많은 프로그램에서는 문제가 해결된 것으로 표시할 때, 실제로 수정 조치가 의도한 결과를 달성했는지 확인한 후가 아니라, 단순히 조치가 취해진 시점을 기준으로 삼습니다.
취약점에 대한 우선순위가 정해지면, 문제는 ‘무엇이 중요한지’ 결정하는 것에서 ‘대규모로 안정적으로 수정 조치를 실행하는 것’으로 옮겨갑니다.
우선순위가 지정된 취약점 목록을 수정 계획으로 전환하기
취약점에 대한 점수가 매겨진 목록이 있습니다. 다음 단계는 그 목록을 체계적인 행동으로 전환하는 것입니다.
순서 결정
우선순위 점수는 순서 결정에 참고가 되지만, 이를 강제하는 것은 아닙니다. 시퀀싱을 진행하기 전에 오탐을 걸러내는 것도 중요합니다. 실제 환경에서의 노출 상황을 반영하지 않는 스캐너 검사 결과는 대기열을 불필요하게 늘리고, 문제 해결 노력을 잘못된 방향으로 이끌 수 있기 때문입니다. 격리된 테스트 서버에서 CVSS 9,8 등급의 취약점은 도메인 컨트롤러에서 CVSS 7,5 등급의 취약점보다 배포 대기열에서 우선순위가 낮습니다.
우선순위 결정은 심각도와 자산의 중요도, 노출 정도(예: 인터넷에 노출된 자산 대 내부 자산), 활발한 악용 신호, 그리고 유지보수 시간대 및 시스템 종속성과 같은 운영상의 제약 조건을 종합적으로 고려하여 이루어집니다. 이는 본질적으로 취약점 수준에서 수행되는 위험 평가로, 악용 가능성을 성공적인 공격이 초래할 수 있는 잠재적 비즈니스 영향과 비교하여 평가하는 것입니다.
CISA의 ‘알려진 악용 취약점(KEV)’ 카탈로그 및 ‘악용 예측 점수 시스템(EPSS)’ 점수와 같은 위협 인텔리전스 정보원은 실제 환경에서 어떤 취약점이 활발히 악용되고 있는지 파악하는 데 도움이 됩니다. 스캐너의 검사 결과는 National Vulnerability Database(NVD)와 같은 취약점 데이터베이스와 연동되어야 하며, 이를 통해 CVE 메타데이터, 심각도 점수 및 수정 지침이 최신 상태인지 확인하고 상황에 맞게 정확하게 해석될 수 있도록 해야 합니다. “적극적으로 악용되고 있는” 상태와 “중요 자산에 영향을 미치는” 상태가 겹치는 치명적인 취약점은 처리 우선순위 목록의 최상위에 두어야 합니다.
CISA의 KEV 카탈로그는 연방 기관에 대한 시정 조치 기한을 규정하고 있으며, 많은 중대한 문제들은 악용 위험도에 따라 정해진 기한 내에 시정 조치가 이루어져야 합니다.
우선순위 지정만으로는 실행 효율성이 보장되지 않습니다. 효과적인 수정 프로그램에서는 취약점 분석 결과를 이를 해결하기 위해 필요한 구체적인 패치, 구성 변경 또는 업데이트와 연계해야 합니다. 이러한 연계가 없다면, 팀들은 CVE를 실제 적용 가능한 수정 사항으로 전환하는 데 종종 시간을 낭비하게 됩니다. 가 활성 취약점과 관련된 누락된 패치를 식별하는 와 같이, 취약점 데이터를 해결 조치와 직접 연결하는 플랫폼은 동일한 워크플로우 내에서 우선순위가 지정된 위험을 실행 가능한 작업 항목으로 전환함으로써 보안 팀과 IT 팀 간의 마찰을 줄이고 문제 해결 시간을 단축할 수 있습니다.
순서 결정이 확정되면, 실행 계획 수립은 책임 소재와 자원 확보 단계로 넘어갑니다.
자원 및 소유권 배분
첫 번째 패치가 배포되기 전에, 각 우선순위 단계별로 누가 실행을 담당하는지 명확히 해야 합니다. 제로데이 취약점 은 최우선 순위 단계에 해당하며, 일반적으로 일정을 단축한 신속한 대응 절차가 요구됩니다. 중요 등급의 항목은 대개 의 신속한 변경 승인( )과 전담 인력이 필요합니다. 중급 아이템은 주간 점검 기간에 일괄 처리될 수 있습니다.
[효과적인 위협 및 취약점 관리 전략이 조직이 위험 노출을 줄이고, 위험의 우선순위를 정하며, 끊임없이 변화하는 위협에 더 신속하게 대응하는 데 어떻게 도움이 되는지 알아보세요]
대기열에 있는 각 항목은 일반적으로 범위, 영향을 받는 자산, 마감일 및 승인 요건이 미리 입력된 ITSM 티켓을 생성하거나 해당 티켓에 매핑됩니다. 해당 티켓은 보안 팀과 IT 운영 팀 간의 주요 조정 창구 역할을 합니다. 중요도가 높은 항목의 경우, 이는 시정 조치 진행 상황과 일정을 파악해야 하는 이해관계자들을 위한 소통 기록의 역할도 합니다.
워크플로우 예시: CVSS 9,8 CVE가 오전 9시 의 CISA KEV 목록에 등재됩니다. 우선순위 분류 결과, 이 CVE는 ‘심각(Critical)’ 등급으로 지정됩니다. 영향을 받은 자산 목록이 포함된 ITSM 티켓이 자동으로 생성됩니다. 링 1이 50 개의 파일럿 엔드포인트에 배포됩니다. 검증 재스캔은 정의된 주기에 따라 실행되며, 툴링 및 규모에 따라 대개 몇 시간에서 하루 정도 소요됩니다. Ring 2 이 운영 환경에 배포됩니다. 종결을 위해서는 수정 사항이 확인된 감사 증거가 필요합니다.
배포 계획이 수립된 상태에서, 다음으로 결정해야 할 사항은 각 취약점에 어떤 대응 유형을 적용할지입니다.
시정, 완화 또는 예외
모든 취약점에 대해 똑같은 대응이 이루어지는 것은 아닙니다. 이 결정은 수정 사항의 가용성, 운영상의 제약 조건 및 위험 수용 수준에 따라 달라집니다.
| 응답 유형 | What it does | 사용 시기 |
|---|---|---|
| 정화 | 취약점을 근원적으로 제거합니다 | 공급업체 패치가 제공되며, 귀사의 SLA 범위 내에서 배포할 수 있습니다. |
| 완화 | 근본 원인을 제거하지 않으면서도 악용 가능성을 줄입니다 | 아직 패치가 없거나, 배포를 위해서는 추가적인 테스트가 필요합니다. |
| 예외 | 위험을 해결하거나 완화하지 않은 채 공식적으로 수용한다 | 해당 시스템은 가동 중단될 예정이거나, 보상 제어 기능을 통해 위험이 허용 가능한 수준으로 낮아집니다. |
적절한 대응 방식을 선택하는 단계에서 프로그램들이 종종 실수를 저지르곤 합니다. 운영상의 제약으로 인해 패치 적용이 현실적으로 불가능한 경우에는 무조건 패치를 적용하는 것을 피하고, 해결책이 있는 경우에는 무조건 예외를 적용하는 것을 피해야 한다.
정화 조치 는 실행 가능한 경우 가장 완벽한 해결책으로, 취약점을 근원적으로 제거합니다. 여기에는 패치 적용, 보안 강화 설정, 지원이 중단된 소프트웨어 교체 등이 포함되지만, 대규모로 성공적으로 수행하기 위해서는 협업과 테스트, 그리고 체계적인 배포 절차가 필요합니다.
완화 조치 는 시간을 벌어줍니다. 이는 근본적인 문제를 해결하지는 않으면서도 악용 가능성을 줄여주며, 팀이 패치를 기다리거나 검증을 완료하는 동안 피해 범위를 제한합니다. 이로 인해 운영상 유용하지만, 장기적인 해결책으로 간주할 경우 위험할 수 있습니다.
의 예외는 기술적 부채를 초래합니다. 취약점을 수용하면 그 부담이 거버넌스로 옮겨가게 됩니다. 즉, 근거를 문서화하고, 보완 통제를 유지하며, 시간이 지남에 따라 해당 결정을 재검토해야 합니다. 그런 절제가 없다면, 감수하기로 한 위험이 눈치채지 못한 채 쌓이게 마련이다.
대규모로 시정 조치 실행
중단 없이 수천 개의 엔드포인트에 수정 사항을 배포하려면 단순한 도구만으로는 부족하며, 체계적인 접근 방식이 필요합니다.
공급업체 패치 적용
패치 배포는 단계별 방식을 따릅니다. 패치를 확보하고, 배포를 위해 준비한 후, 본격적인 배포에 앞서 비생산 환경에서 테스트하십시오. 의 효과적인 패치 관리( )는 이 프로세스가 개별 CVE가 발생할 때마다 단순히 대응하는 데 그치지 않고, 반복 가능하고 감사 가능한 방식으로 이루어지도록 보장합니다.
시범 그룹은 문제를 조기에 파악합니다. 패치로 인해 애플리케이션 종속성이 깨지거나, 기능이 중단되거나, 성능 저하가 발생한다면, 5.000개 엔드포인트가 아니라 50 개 엔드포인트에서 해당 문제를 파악하고 싶을 것입니다. 벨이 울리는 사이의 대기 시간을 두면 다음 단계로 넘어가기 전에 안정성 신호를 확인할 수 있습니다.
연결이 끊기거나 오프라인 상태인 엔드포인트 는 특별한 문제를 야기합니다. 많은 플랫폼에서 팀이 사전에 수정 조치를 정의할 수 있도록 지원하지만, 실제 실행 여부는 엔드포인트가 다시 연결되어 해당 지침을 수신하는지에 달려 있습니다. 재연결이 이루어질 때까지 노출된 엔드포인트는 위험에 노출된 상태로 남아 있습니다.
설정 오류에 대한 보안 강화
구성 수정 작업은 단순히 “설정을 변경하는 것”을 넘어섭니다. 기준선에서 벗어난 편차를 감지하고, 스크립트를 작성하거나 정책을 통해 수정 사항을 적용한 뒤, 이후 정책 적용 후에도 변경 사항이 유지되는지 확인하고 있습니다.
일반적인 대상에는 다음이 포함됩니다:
- 기본 인증 정보: 공격자들이 가장 먼저 시도하는 것으로 알려진 공장 출하 시 설정된 사용자 이름과 비밀번호
- 불필요한 개방 포트: 공격 표면을 확대하는 네트워크 진입점
- 지나치게 관대한 접근 제어: 사용자에게 필요한 것보다 더 광범위한 접근 권한을 부여하는 설정
이들 각각은 공격자들이 적극적으로 탐지하고 악용하는 일반적인 취약점 패턴을 나타내며, 이로 인해 구성 강화는 대부분의 팀이 활용할 수 있는 가장 효과적인 문제 해결 조치 중 하나가 됩니다. 구성 관리 도구는 대규모로 변경 사항을 적용하지만, 검증 과정을 통해 해당 변경 사항이 제대로 적용되었는지 확인합니다.
수명 주기가 끝난 소프트웨어의 업그레이드 또는 교체
지원 종료(EOL) 소프트웨어는 더 이상 보안 패치를 제공받지 않습니다.. ‘정정 조치’란 지원되는 버전으로 업그레이드하거나, 소프트웨어를 교체하거나, 또는 소프트웨어를 완전히 폐기하는 것을 의미합니다. 이는 상용 구성 요소와 오픈소스 구성 요소 모두에 동일하게 적용됩니다. 많은 환경에서 애플리케이션에 내장된 EOL(지원 종료) 오픈소스 라이브러리가 존재하지만, 일반적인 패치 주기 중에는 이를 간과하기 쉽습니다.
EOL 문제 해결은 운영상 복잡합니다. 의존성 매핑은 업그레이드 시 어떤 문제가 발생하는지 보여줍니다. 테스트를 통해 새 버전이 사용자의 환경에서 정상적으로 작동하는지 확인합니다. 사업 승인 절차를 통해 생산 변경 기간이 확정됩니다. 복잡함에도 불구하고, EOL 취약점은 지속적인 보안 위협 요인으로 작용하기 때문에 해결 시 큰 효과를 기대할 수 있는 대상입니다.
보완 통제 조치 시행
직접적인 시정 조치가 즉시 실행될 수 없는 경우, 보완 통제 조치를 통해 그 동안 위험을 줄일 수 있습니다. 이는 민감한 데이터를 저장하거나 처리하는 시스템의 경우 특히 중요한데, 이러한 시스템에서 노출을 제대로 방지하지 못할 경우 기술적 위험을 넘어 규제 및 비즈니스상의 결과를 초래할 수 있기 때문입니다. 네트워크 분할, 접근 제한, 강화된 모니터링과 같은 통제 수단은 횡방향 이동을 제한하고, 공격 표면을 축소하며, 침해가 발생할 경우 탐지 능력을 향상시키는 데 도움이 됩니다.
보상 조치는 대개 일시적인 것이지만, 경우에 따라 장기적으로 유지될 수도 있으며, 환경 변화에 따라 그 효과를 유지하기 위해서는 지속적인 모니터링이 필요합니다. 이들을 예외 사항과 함께 추적하고, 정기적으로 검토하며, 수정 방법이 마련되면 이를 영구적인 해결책으로 대체하는 것이 중요합니다.
자동화된 문제 해결 관리
자동화는 업무 수행 속도를 높여줍니다. 또한 잘못된 구성이나 패치 실패를 수천 개의 엔드포인트 전체로 단 몇 분 만에 확산시킬 수도 있습니다. 해답은 자동화를 줄이는 것이 아닙니다. 가 주도하는 자동화: 문제가 생산 규모에 이르기 전에 이를 포착하는 제어 기능을 통해 속도와 균형을 맞춥니다.
[복잡한 기업 환경에서 자동화된 패치 수정 기능이 제대로 작동하기 위해 필요한 요건과, 위험을 증가시키지 않으면서 단계적으로 도입하는 방법을 알아보세요]
신뢰도 점수 산정 및 배포 적격성
신뢰도 점수 산정 은 데이터 기반의 맥락 정보를 제공하여, 팀이 패치나 구성 변경 사항을 적용하기 전에 그 안전성을 평가할 수 있도록 지원합니다. 이 시스템은 자동으로 결정을 내리기보다는, 과거 배포 성공 사례, 안정성 결과, 성능에 미치는 영향 등의 신호를 제시함으로써 운영자의 판단에 참고 자료를 제공합니다.
신뢰도가 높은 변경 사항은 더 광범위한 적용에 더 적합한 후보가 될 수 있는 반면, 신뢰도가 낮은 변경 사항은 일반적으로 추가적인 검증, 테스트 또는 조직 정책에 따른 명시적인 승인이 필요합니다.
위험 관리를 위한 링 기반 배포
의 링 배포는 점차 더 큰 규모의 엔드포인트 그룹을 대상으로 단계적으로 진행됩니다. 전형적인 패턴: 카나리아(5–10 개 엔드포인트), 파일럿(50–200개), 광범위(나머지).
벨이 울린 후의 대기 시간이 중요합니다. 패치 실패율, 애플리케이션 호환성 오류, 엔드포인트 안정성 신호를 주시하고 계십니다. 링별 오류 임계값은 중지하거나 롤백해야 할 시점을 정의합니다. 명확한 에스컬레이션 기준에 따라 배포를 진행하거나 중단할 권한이 있는 사람이 결정됩니다.
링 배포는 기업 규모에서 자동화의 안전성을 높이는 데 기여하는 메커니즘입니다.
플레이북 기반 실행
플레이북은 자동화된 수정 로직을 정의하며, 여기에는 적용할 수정 유형, 적용 범위, 그리고 엔드포인트 그룹 전반에 걸친 배포 진행 방식 등이 포함됩니다.
실행 과정에는 대개 승인 단계와 단계별 배포가 포함되며, 이를 통해 팀은 변경 사항을 검토하고 결과를 검증한 후 더 광범위한 배포를 진행할 수 있습니다.
플레이북 실행은 티켓팅 및 변경 관리 프로세스를 비롯한 기존 워크플로우와도 통합될 수 있으므로, 문제 해결 조치와 승인 절차가 팀의 기존 운영 방식에 맞춰 진행될 수 있습니다.
IT/SecOps 간 협력 문제
무엇을 고쳐야 하는지, 어떻게 고쳐야 하는지를 안다고 해서 반드시 고쳐진다는 보장은 없습니다. 이러한 문제는 대개 보안 부서와 IT 운영 부서 간의 업무 인계 과정에서 발생합니다.
인계가 제대로 이루어지지 않는 경우
보안 팀은 취약점을 파악하고 우선순위를 정합니다. IT 운영 팀은 시스템을 관리하며 문제 해결을 수행합니다. 배포 진행 상황, 검증 결과 및 책임 소재에 대한 공동 가시성이 확보되지 않으면, 수정 사항이 실제로 확인되기도 전에 문제 해결 작업이 완료된 것처럼 보일 수 있으며, 이로 인해 보안 취약점이 그대로 노출되고 감사 증거가 불완전해질 수 있습니다.
구체적인 문제점은 다음과 같습니다:
- 보안 팀은 수정 사항이 “권장”될 때 티켓을 종결합니다: IT 팀은 아직 이를 적용하지 않았습니다.
- IT 부서는 패치가 “적용”되면 티켓을 종결합니다: 보안 팀은 해당 수정 사항이 취약점을 해결했는지 아직 확인하지 않았습니다.
- 공유 큐 없음: Security는 취약점 스캐너를 기반으로 작동합니다. IT 부서는 IT 서비스 관리(ITSM) 티켓팅 시스템을 통해 업무를 수행합니다. 이 두 언어 간에는 자동 번역 기능이 제공되지 않습니다.
- SLA 불일치: 보안팀은 중대한 CVE에 대한 패치가 48 시간 이내에 적용되기를 기대하고 있습니다. IT 부서에는 매주 진행되는 변경 관리 기간이 있습니다.
[AI를 활용한 위협이 왜 노출 관리를 ‘위험 식별’에서 ‘공격자가 행동에 나서기 전에 적극적으로 대응’하는 방향으로 전환시키고 있는지 알아보세요]
많은 문제 해결 프로그램이 IT와 SecOps 간의 업무 인계 단계에서 난항을 겪는데, 이는 팀들이 올바른 의도를 가지고 있지 않아서가 아니라 워크플로가 유기적으로 연결되지 않기 때문이다.
조정 계층으로서의 ITSM 통합
ITSM 워크플로우 통합은 업무 인계 과정의 단절을 해소하는 데 핵심적인 역할을 합니다. 취약점 분석 결과를 바탕으로, 범위, 우선순위 및 마감일이 자동으로 입력된 ITSM 티켓을 생성하거나 해당 티켓에 매핑하도록 구성할 수 있습니다. 배포 상태 정보가 IT 부서에서 보안 팀의 화면으로 다시 전달됩니다.
성숙한 프로그램의 경우, 정보 공유는 선택 사항이 아닙니다. 양 팀 모두 취약점 수정 현황을 실시간으로 동일하게 확인할 수 있습니다. 승인 워크플로는 두 팀 모두에 걸쳐 진행됩니다. 배포 전에 누가 승인하고, 배포 후에 누가 확인하는지입니다.
공동 소유 모델
성과가 뛰어난 프로그램은 책임 소재를 명확하게 규정하고 있다. SecOps와 IT 책임자 간에 합의된 공동 대응 SLA는 기대 사항을 명확히 규정합니다. 에스컬레이션 절차는 기한 미준수 문제를 해결하기 위한 것입니다. 단일 정보 소스를 통해 시정 조치를 추적합니다.
지표는 병목 현상이 발생하는 지점을 보여줍니다. 단계별(발견부터 티켓 생성까지, 티켓 생성부터 배포까지, 배포부터 검증까지)로 추적한 평균 문제 해결 시간(MTTR)을 통해 지연의 원인이 문제 파악 단계에 있는지, 아니면 실행 단계에 있는지를 정확히 파악할 수 있습니다.
정화 조치가 효과가 있었는지 확인하기
패치가 적용되었다고 해서 반드시 해당 취약점이 해결된 것은 아닙니다. 검증은 노출이 단순히 공정 단계에서 처리된 것뿐만 아니라, 실제로 감소되었거나 제거되었는지 확인하는 데 도움이 됩니다.
많은 프로그램은 수정 조치가 적용된 후에 취약점을 해결하지만, 수정 사항이 제대로 작동하는지 확인한 후에 해결하는 것은 아닙니다. 이러한 구분은 보안 상태에 대한 잘못된 확신을 불러일으키고 감사 증거에 허점을 남기게 됩니다.
검증 과정에서는 일반적으로 영향을 받는 엔드포인트에 대해 취약점 스캔 을 수행하거나, 수정 사항이 적용된 후 엔드포인트 상태를 확인해야 합니다. 패치를 적용한 후에는 스캔 결과에서 해당 CVE가 더 이상 나타나지 않는지, 그리고 취약한 상태가 더 이상 존재하지 않거나 접근할 수 없는지 확인하십시오. 구성을 변경한 경우, 해당 설정이 유지되었는지, 그리고 이후 정책 적용으로 인해 덮어쓰이지 않았는지 확인하십시오.
분산 환경에서는 수정 조치의 적용 범위가 완전한지 확인하기 위해, 표본 집합뿐만 아니라 영향을 받는 모든 자산에 걸쳐 검증을 수행해야 합니다. 다른 환경에서는 검증 과정에서 단순히 변경이 이루어졌는지 여부를 확인하는 것뿐만 아니라, 수정 조치가 원래의 취약점 상태를 직접적으로 해결했는지 여부도 확인해야 합니다.
이 구별은 중요합니다: “조치가 취해졌다”는 것은 프로세스가 완료되었음을 의미합니다. “위험이 실제로 감소했다”는 점이 규정 준수, 감사 증거, 그리고 전반적인 보안 태세 측면에서 중요한 결과입니다.
[리스크 관리가 무엇인지, 조직에 왜 중요한지, 그리고 위협을 파악하고 대응하기 위한 효과적인 전략을 어떻게 수립할 수 있는지 이해하기]
검증 절차가 마련된 이상, 마지막으로 남은 질문은 프로그램이 제대로 작동하고 있는지 어떻게 측정할 것인가 하는 점입니다.
정화 프로그램의 건전성 평가
지표는 문제 해결 조치가 효과를 거두고 있는지, 그리고 효과가 없을 때 어디에 개입해야 하는지를 알려줍니다.
문제 해결까지 걸리는 평균 시간
MTTR은 취약점 탐지 또는 티켓 생성(프로그램 정의에 따라 다름) 시점부터 검증된 수정 조치가 완료될 때까지의 소요 시간 을 심각도 등급별로 추적하여 측정합니다.
중요 등급 항목의 MTTR이 증가하는 것은 워크플로우의 어느 부분에서 문제가 발생했음을 나타냅니다. 문제 발견부터 티켓 생성까지의 시간, 티켓 생성부터 배포까지의 시간, 배포부터 검증까지의 시간을 비교해 보면, 지연의 원인이 우선순위 결정, 실행, 아니면 검증 중 어디에 있는지 파악할 수 있습니다. 프로그램 수준에서 추적된 MTTR은 지연이 발생하는 지점을 파악하기 어렵게 만듭니다. 단계별로 분류하세요.
정화 대상 비율
적용률은 정의된 기간 내에 발견된 취약점 중 해결된 비율을 나타냅니다.
높은 MTTR과 높은 처리율이 동시에 나타나는 것은 체계적인 처리 지연이 있음을 시사하지만, 우선순위 분류에 문제가 있는 것은 아닙니다. 커버리지율이 낮다는 것은 우선순위 설정에 문제가 있거나 자원 용량에 제약이 있음을 나타냅니다. 자산 등급별 적용률을 추적합니다. 표준 엔드포인트보다 보호 범위가 좁은 중요 자산은 우선순위 설정에 문제가 있음을 시사합니다.
SLA 준수율
SLA 준수 여부는 심각도 등급별로 정해진 시정 조치 기한을 얼마나 잘 준수했는지를 기준으로 측정합니다. 일반적인 서비스 수준 목표(SLO)는 다음과 같습니다. ‘중요’ 등급은 24–48 시간 이내, ‘높음’ 등급은 7–14 일 이내, ‘보통’ 등급은 30 일 이내입니다.
중요도 등급별 SLA 위반 패턴을 분석하면, 실행 워크플로우의 어느 단계에서 리소스가 부족하거나 관리가 미흡한지 정확히 파악할 수 있습니다. SLA 준수 여부는 규정 준수 감사의 주요 평가 지표입니다. 규제 체계와 내부 보안 지침 은 대개 심각도 등급에 따라 구체적인 시정 조치 기한을 규정하고 있습니다. 단순히 티켓이 종결된 것뿐만 아니라, 배포와 검증에 대한 문서화된 증거가 있어야만 해당 요건을 충족할 수 있습니다.
MTTR은 여러분의 속도가 얼마나 느린지를 알려줍니다. 보장률은 보장 범위가 얼마나 완벽한지를 나타냅니다. SLA 준수 현황을 통해 어떤 부분에서 약속을 지키지 못하고 있는지 파악할 수 있습니다. 이 세 가지 요소가 모두 갖춰지지 않은 상태에서 운영되는 어떤 개선 프로그램이든, 실행 상태의 건전성이 아닌 결과물만을 측정하고 있는 것입니다. 새로운 취약점이 지속적으로 발견됨에 따라, 이러한 격차는 시간이 지남에 따라 더욱 심화됩니다.
Tanium이 취약점 대응을 가속화하는 방법
이 기사에서 설명한 실행상의 문제점들, 즉 도구 사용의 단편화, 업무 인계 지연, 제한적인 검증 등은 대개 서로 연결되지 않은 워크플로우와 엔드포인트 전반에 걸친 불완전한 가시성에서 기인합니다.
의 Tanium Autonomous IT Platform( )은 의 실시간 엔드포인트 가시성( ) 및 제어 기능을 통해 취약점 식별, 수정 조치, 검증 워크플로를 연계함으로써, 분산된 도구에 대한 의존도를 줄여줍니다.
실제로 이는 다음과 같은 기능*을 통해 드러납니다:
- 실시간 엔드포인트 가시성과 주문형 취약점 및 구성 평가의 결합: 운영 체제, 애플리케이션 및 구성을 포괄하며, 정기적으로 업데이트되는 콘텐츠 라이브러리를 통해 지원됩니다.
- 중요 및 새롭게 발견된 취약점에 대한 실시간 알림: 를 통해 제공되며, Tanium 콘솔 내에서 Tanium Guardian 이 취약점 긴급 대응 팀(VERT)의 연구 결과를 바탕으로 지원하며, 대개 권장되는 수정 조치 및 지침이 포함됩니다.
- 통합된 수정 워크플로: 동일한 플랫폼 내에서 식별된 취약점에 대응하고 수정 워크플로를 시작하여 도구 간 전환의 필요성을 줄일 수 있습니다.
- 신뢰도 점수: 설치 성공률, 안정성 결과, 성능 영향 등의 지표를 활용하여 대규모 배포에 앞서 패치 적용 여부를 결정하는 데 참고하십시오.
- 단계적, 링 기반 배포: 소규모 엔드포인트 그룹으로 시작하여 결과를 검증하고, 각 단계가 성공 기준을 충족할 때마다 배포 범위를 확대합니다.
- 로우코드 및 노코드 자동화 플레이북: 는 Tanium Automate 를 활용하여 운영자의 감독 하에 엔드포인트 및 문제 해결 워크플로를 조정합니다.
- 배포 후 검증 기능: 패치 상태를 확인하고, 수정 조치가 예상대로 적용되지 않은 시스템을 파악하는 데 도움이 됩니다.
- , ServiceNow 및 기타 주요 워크플로우와의 통합: 이를 통해 IT 및 보안 팀은 기존 프로세스 내에서 일관된 엔드포인트 데이터에 접근할 수 있습니다.
- 구성 평가 및 취약점 관리 사용 사례: PCI, HIPAA, SOX와 같은 일반적인 프레임워크에 부합합니다.
- 의 취약점 수정 현황: 보안 및 운영 팀이 수정 진행 상황을 추적하고 실행을 조율할 수 있도록, 패치 가능한 취약점, 누락된 패치 및 배포 상태를 표시합니다.
*여기에 설명된 기능 및 결과는 Tanium 제품 설명서, 검증된 고객 사례 연구 및 실제 사용 사례를 바탕으로 합니다. 실제 결과는 배포 환경, 구성 및 조직의 성숙도에 따라 달라질 수 있습니다.
Tanium을 사용하면, 검증 과정을 수정 조치를 배포하는 데 사용되는 동일한 워크플로에 통합할 수 있습니다. 팀은 패치 설치 상태나 구성 변경 사항 등 엔드포인트 상태를 확인하고, 노출 위험을 재평가하여 수정 조치가 의도한 결과를 달성했는지 판단할 수 있습니다.
시정 조치 현황을 추적하는 것에서 위험 감소 여부를 확인하는 것으로의 이러한 전환이, 성숙한 프로그램과 사후 대응형 프로그램을 구분 짓는 요소입니다.
대부분의 규정 준수 도구는 무엇이 문제인지 알려줍니다. 어떻게 대처해야 할지 알려주는 곳은 드물고, 같은 화면에서 바로 조치를 취할 수 있게 해주는 곳은 거의 없습니다. Tanium Comply의 ‘Remediation Visibility’ 가 이러한 상황을 바꿔 놓습니다. Tech Talks #121 ‘’에서 Tanium의 리스크 및 규정 준수 도메인 아키텍트인 Margie Sills는 이 기능이 취약점을 실행 가능한 패치와 어떻게 매핑하는지, 위험 감소 효과에 따라 순위를 매기는 방식, 그리고 팀이 도구를 바꾸거나 업무 인계를 기다릴 필요 없이 취약점 탐지에서 해결 단계로 어떻게 전환할 수 있는지를 상세히 설명합니다.
취약점 수정 관련 자주 묻는 질문
정화 작업의 실행 과정에서는 프로세스 문서에 명확히 규정되어 있지 않은 실무적인 문제들이 제기됩니다. 다음은 스캔 결과를 구체적인 조치로 전환할 때 팀들이 자주 묻는 일반적인 질문들입니다.
제 취약점 스캐너에서 수백 건의 CVE가 탐지되었습니다. 어디서부터 시작해야 할까요?
CVSS 점수만으로는 순위를 매기기에 충분하지 않습니다. 도메인 컨트롤러에 존재하는 CVSS 7,5 은 격리된 테스트 시스템에 존재하는 CVSS 9,0 보다 우선순위가 높은 실행 대상입니다.
두 가지 기준, 즉 현재 악용 여부(CISA KEV 및 EPSS 신호)와 자산의 중요도를 바탕으로 목록을 필터링하십시오. “실제 환경에서 적극적으로 악용되고 있는” 항목과 “중요 자산에 존재하는” 항목이 교차하는 부분이 첫 번째 실행 대기열을 구성합니다.
왜 CVSS 점수만으로는 어떤 문제를 먼저 수정할지 우선순위를 정하기에 충분하지 않은가요?
CVSS는 정의된 조건 하에서 기본 심각도와 환경적 심각도를 측정하지만, 실제 악용 상황이나 비즈니스 맥락은 고려하지 않습니다. 이 평가는 공격자에게 유리한 이상적인 조건 하에서 악용 가능성과 영향도를 평가하며, 해당 취약점이 실제로 야생에서 활발히 악용되고 있는지, 또는 영향을 받는 시스템이 귀사의 비즈니스에 중요한지 여부는 고려하지 않습니다.
사용자의 환경에서 실행되고 있지 않은 소프트웨어에 대한 CVSS 9,8 은, 현재 악용되고 있으며 인터넷에 노출된 시스템에 대한 CVSS 6,5 보다 우선순위가 낮습니다. 효과적인 실행 순서 결정은 단순히 심각도 점수만 고려하는 것이 아니라, CVSS와 EPSS(악용 가능성) 및 자산의 중요도를 종합적으로 고려합니다.
[취약점 평가가 어떻게 진행되는지, 자산 탐지 및 취약점 우선순위 지정이 왜 중요한지, 그리고 공격자가 먼저 취약점을 발견하기 전에 노출 위험을 줄이는 방법을 알아보세요]
정화 조치는 완화 조치와 어떻게 다른가요?
정화 조치는 패치나 구성 수정을 통해 취약점의 근본 원인을 해결하는 반면, 완화 조치는 영구적인 해결책이 마련될 때까지 네트워크 분할이나 접근 제한과 같은 통제 수단을 통해 일시적으로 악용 가능성을 줄이는 것입니다.
취약점 수정 조치의 예로는 무엇이 있나요?
알려진 CVE를 해결하기 위해 공급업체에서 배포한 패치를 적용하거나, 잘못 구성된 방화벽 규칙을 강화하거나, 지원 종료된 소프트웨어를 지원되는 버전으로 업그레이드하는 것은 모두 단순히 노출 위험을 줄이는 데 그치지 않고 취약점의 근본 원인을 해결하므로 ‘시정 조치’에 해당합니다.
취약점 대응은 단순히 취약점을 수정하는 데 그치는 것이 아니라, 위험이 실제로 감소했는지 확인하는 과정입니다. 우선순위 지정, 실행, 검증을 ‘ ’의 연속적인 워크플로로 통합하는 프로그램 은 노출 기간을 단축하고 끊임없이 진화하는 사이버 위협에 대응하는 데 더 유리합니다.
데모를 예약하세요 . Tanium을 통해 전체 환경에서 취약점 수정 작업을 어떻게 간소화하고 검증할 수 있는지 확인해 보세요.
