취약성 개선이란 무엇입니까?

취약성 복구는 사이버 보안 분야에서 운영상 가장 까다로운 분야 중 하나입니다. 그러나 프로그램이 어려움을 겪는 경우 취약성을 식별하는 것은 거의 없습니다. 많은 조직의 경우, 실제 문제는 복구를 일관되게 실행하고 촉박한 시간 내에 수정이 효과적인지 확인하는 데 있습니다.

이 문서에서는 실행 메커니즘에 초점을 맞춥니다. 우선순위 목록을 배포 계획으로 전환하고, 개선 대 완화 시기를 결정하고, 자동화를 안전하게 관리하고, 팀 간에 조정하고, 수정 사항이 노출을 종료했는지 확인합니다. 개별 단계뿐만 아니라 취약성 복구 프로세스를 엔드투엔드로 이해하는 것은 측정 가능한 결과 없이 활동을 생성하는 것과 위험을 일관되게 줄이는 프로그램을 구분하는 것입니다.

취약성 개선이 실제로 수반되는 것

소프트웨어 결함, 잘못된 구성 및 기타 보안 취약성을 포함하여 프로그램이 직면하는 취약성 유형은 각각 서로 다른 복구 접근 방식이 필요합니다. 취약성 복구는 식별 및 우선순위 지정 후 시스템, 애플리케이션 또는 구성에서 이러한 보안 취약점을 제거하는 프로세스입니다.

이는 취약성 관리 수명 주기의 실행 및 검증 단계를 나타내며, 우선순위가 지정된 결과는 시정 조치 및 검증된 결과로 변환됩니다. 광범위한 사이버 보안 환경에서 복구는 노출된 사항을 파악하고 위험을 줄이는 중요한 가교 역할을 합니다.

[자산 중요도 및 수평 이동 리스크가 CVSS 점수를 실제 비즈니스 노출을 반영하는 우선순위 결정으로 전환하는 방법을 알아보십시오]

이론적으로는 단순하지만, 대부분의 프로그램이 그라운드를 잃기 시작하는 곳입니다.

복구는 식별, 우선순위 지정 및 실행 워크플로가 통합되지 않을 때 종종 세분화됩니다. 스캐너가 중요한 CVE를 표시합니다. 이 결과는 보안 대시보드에 있는 반면 IT 운영은 두 시스템 간에 일관된 핸드오프 없이 별도의 티켓팅 시스템에서 작동합니다. 일 경과. 취약점은 열린 상태로 유지되며, 이러한 지연은 공격자가 악용해야 하는 창을 직접 확장합니다.

IT/SecOps 핸드오프는 또 다른 공통 장애 지점을 생성합니다. 보안 팀은 식별 및 우선 순위를 지정합니다. IT 운영 부서는 시스템을 소유하고 수정을 실행합니다. 배포 상태와 유효성 검사 결과에 대한 공유 가시성이 없으면 티켓은 양쪽에서 조기에 닫힙니다. 정렬이 없으면 우선순위가 높은 취약성도 노출된 상태로 유지될 수 있습니다.

[정말 지속적인 것으로 간주되려면 취약성 관리 프로그램이 충족해야 하는 다섯 가지 조건을 참조하십시오]

그런 다음 검증 격차가 있습니다. 패치가 배포됩니다. 티켓이 종료됩니다. 그러나 취약점이 실제로 엔드포인트에서 사라졌습니까, 아니면 여전히 다른 경로를 통해 도달 가능하거나 악용 가능합니까? 많은 프로그램은 수정이 의도한 결과를 달성했는지 확인한 후가 아니라 작업이 수행된 후 해결된 항목을 표시합니다.

취약성의 우선 순위가 지정되면 문제가 중요한 것을 결정하는 것에서 대규모로 안정적으로 수정을 실행하는 것으로 전환됩니다.

우선순위가 지정된 취약성 목록을 복구 계획으로 전환

취약성의 점수가 매겨진 목록이 있습니다. 다음 단계는 이 목록을 조정된 작업으로 전환하는 것입니다.

시퀀싱 결정

우선 순위 점수는 시퀀싱을 알려주지만, 이를 지시하지는 않습니다. 시퀀싱 전에 오탐을 필터링하는 것 또한 가치가 있습니다. 즉, 환경에서 실제 노출을 반영하지 않는 스캐너 결과는 대기열을 팽창시키고 복구 작업을 잘못 지시합니다. 격리된 테스트 서버의 CVSS 9,8 은 도메인 컨트롤러의 CVSS 7,5 보다 배포 대기열에서 순위가 낮습니다.

시퀀싱은 심각도와 자산 중요도, 노출(예: 인터넷 연결 대 내부), 활성 악용 신호, 유지 보수 기간 및 시스템 종속성과 같은 운영 제약을 결합합니다. 이는 기본적으로 취약성 수준에서 적용되는 위험 평가로, 성공적인 공격의 잠재적 비즈니스 영향에 대한 악용 가능성을 가중합니다.

CISA의 알려진 악용 취약점(KEV) 카탈로그 및 악용 예측 채점 시스템(EPSS) 점수와 같은 위협 인텔리전스 소스는 야생에서 활발하게 악용되고 있는 것을 식별하는 데 도움이 됩니다. 스캐너의 결과는 NVD(National Vulnerability Database)와 같은 취약성 데이터베이스로 다시 매핑되어 CVE 메타데이터, 심각도 점수 및 복구 지침이 최신 상태이고 컨텍스트에서 정확하게 해석되도록 해야 합니다. \"적극적으로 악용\" 및 \"중요 자산\"의 교차점에 있는 중요 취약성은 대기열 앞에 있습니다.

CISA의 KEV 카탈로그는 연방 기관의 복구 기한을 정하며, 악용 위험에 따라 정의된 기한 내에 복구가 필요한 많은 중요한 문제가 있습니다.

우선순위 설정만으로는 실행 효율성을 보장할 수 없습니다. 효과적인 복구 프로그램은 취약성 결과를 복구하는 데 필요한 특정 패치, 구성 변경 또는 업데이트와 연관시켜야 합니다. 이러한 연결이 없으면 팀은 종종 CVE를 실행 가능한 수정으로 변환하는 데 시간을 낭비합니다. 활성 취약성과 연결된 누락된 패치를 식별하는 등 취약성 데이터를 복구 작업에 직접 연결하는 플랫폼은 보안 팀과 IT 팀 간의 마찰을 줄이고 우선순위가 지정된 위험을 동일한 워크플로에서 실행 가능한 작업 항목으로 전환하여 해결 시간을 단축할 수 있습니다.

순서 결정이 설정되면 실행 계획은 소유권 및 리소스로 전환됩니다.

리소스 및 소유권 할당

첫 번째 패치를 배포하기 전에 각 우선순위 계층에 대한 실행을 소유한 사람을 명확히 합니다. 제로데이 취약성 은 우선순위가 가장 높은 계층을 나타내며 일반적으로 압축된 타임라인을 가진 가속화된 워크플로우를 요구합니다. 중요 계층 항목은 종종 신속한 변경 승인 및 전용 리소스가 필요합니다. 중간 계층 항목은 주간 유지 보수 기간에 배치될 수 있습니다.

[효과적인 위협 및 취약성 관리 전략이 조직의 노출을 줄이고, 위험을 우선시하며, 진화하는 위협에 더 빠르게 대응하는 데 어떻게 도움이 되는지 알아보십시오]

대기열의 각 항목은 일반적으로 범위, 영향을 받는 자산, 기한 및 승인 요구 사항이 채워진 ITSM 티켓을 생성하거나 매핑합니다. 이 티켓은 보안과 IT 운영 간의 주요 조정 지점이 됩니다. 심각도가 높은 항목의 경우, 개선 진행 상황 및 일정에 대한 가시성이 필요한 이해관계자를 위한 커뮤니케이션 기록 역할도 합니다.

워크플로 예: 오전 9시 우선순위 분류의 CISA KEV 목록에 CVSS 9,8 CVE가 나타나 중요 계층에 할당됩니다. ITSM 티켓은 영향을 받는 자산 목록과 함께 자동으로 생성됩니다. 링 1은 50 개의 파일럿 엔드포인트에 배포됩니다. 검증 재스캔은 정의된 주기로 실행되며, 툴링 및 스케일에 따라 종종 몇 시간에서 하루까지 실행됩니다. Ring 2 이 프로덕션에 배포됩니다. 종결하려면 수정을 확인하는 감사 증거가 필요합니다.

배포 계획을 수립한 상태에서 다음 결정은 각 취약성에 맞는 대응 유형입니다.

개선, 완화 또는 예외

모든 취약성이 동일한 응답을 얻는 것은 아닙니다. 결정은 수정 가용성, 운영 제약 및 위험 허용치에 따라 달라집니다.

올바른 응답 유형을 선택하는 것은 프로그램이 종종 미끄러지는 부분입니다. 운영상의 제약으로 인해 패치가 비현실적인 경우 패치로 기본 설정하지 않고 수정이 가능한 경우 예외로 기본 설정하지 않습니다.

복구 는 실행 가능한 경우 가장 완전한 해결이며, 취약점을 근원에서 제거합니다. 여기에는 패치 적용, 구성 강화 또는 지원되지 않는 소프트웨어 교체가 포함되지만 규모에 맞게 성공하려면 조정, 테스트 및 배포 규율이 필요합니다.

완화 는 시간을 확보합니다. 이는 근본적인 문제를 제거하지 않고 활용성을 감소시키며, 팀이 패치를 기다리거나 검증을 완료하는 동안 블래스트 반경을 제한합니다. 따라서 운영상 유용하지만 장기적인 솔루션으로 취급할 경우 위험합니다.

예외는 기술적 부채를 초래합니다. 취약성을 수용하면 정당한 사유 문서화, 보상 통제 유지 및 시간 경과에 따른 결정 재검토와 같은 거버넌스에 대한 부담이 변경됩니다. 이러한 규율이 없으면 수용된 위험이 눈에 띄지 않게 누적되는 경향이 있습니다.

대규모 복구 실행

중단 없이 수천 개의 엔드포인트에 수정 사항을 배포하려면 툴링뿐만 아니라 엄격한 접근 방식이 필요합니다.

벤더 패치 적용

패치 배포는 스테이징된 패턴을 따릅니다. 패치를 획득하고, 배포를 위해 준비하고, 광범위한 배포 전에 비생산 링에서 테스트합니다. 효과적인 패치 관리 는 개별 CVE가 표면화될 때 반응성뿐만 아니라 이 프로세스가 반복 가능하고 감사 가능하도록 보장합니다.

파일럿 그룹은 문제를 조기에 포착합니다. 패치가 애플리케이션 종속성을 깨뜨리거나, 기능을 중단하거나, 성능 저하를 일으키는 경우 5.000가 아닌 50 엔드포인트에 대해 알고 싶어합니다. 링 사이의 유지 기간을 통해 전진하기 전에 안정성 신호를 관찰할 수 있습니다.

연결이 끊어졌거나 오프라인인 엔드포인트 에는 특정 문제가 있습니다. 많은 플랫폼에서 팀이 복구 작업을 사전에 정의할 수 있지만 실행은 엔드포인트 재연결 및 해당 지침 수신에 따라 달라집니다. 재연결할 때까지 노출된 엔드포인트는 여전히 위험에 처해 있습니다.

잘못된 구성 강화

구성 수정은 설정을 변경하지 않습니다. 기준선에서 드리프트를 감지하고, 정책을 통해 수정을 스크립팅 또는 시행하고, 후속 정책 응용 프로그램 이후에 변경 사항이 지속되었는지 확인합니다.

일반적인 대상은 다음과 같습니다.

• 기본 자격 증명: 공격자가 먼저 시도하는 것으로 알고 있는 공장 설정 사용자 이름과 비밀번호
• 불필요한 오픈 포트: 공격 표면을 확장하는 네트워크 진입점
• 과도하게 허용되는 액세스 제어: 사용자가 요구하는 것보다 더 넓은 액세스 권한을 부여하는 설정

이들 각각은 공격자가 적극적으로 검색하고 활용하는 일반적인 취약성 패턴을 나타내며, 대부분의 팀이 사용할 수 있는 가장 높은 활용도의 복구 활동 중 하나를 구성 강화합니다. 구성 관리 툴링은 규모에 따라 변경 사항을 적용하지만, 검증을 통해 적용이 보류되었음을 확인합니다.

수명이 다한 소프트웨어 업그레이드 또는 교체

수명 종료(EOL) 소프트웨어는 더 이상 보안 패치를 수신하지 않습니다. 복구란 지원되는 버전으로 업그레이드하거나, 소프트웨어를 교체하거나, 완전히 해제하는 것을 의미합니다. 이는 상용 및 오픈 소스 구성 요소에 동일하게 적용됩니다. 많은 환경에서 표준 패치 주기 동안 간과하기 쉬운 애플리케이션에 내장된 EOL 오픈 소스 라이브러리를 가지고 있습니다.

EOL 복구는 운영상 복잡합니다. 종속성 매핑은 업그레이드 시 어떤 중단이 발생하는지 보여줍니다. 테스트를 통해 새 버전이 사용자 환경에서 작동하는지 확인합니다. 비즈니스 승인은 생산 변경 창을 확인합니다. 복잡성에도 불구하고 EOL 취약성은 지속적인 노출을 나타내기 때문에 높은 활용도의 복구 대상입니다.

보완 통제 구현

직접적인 복구를 즉시 실행할 수 없는 경우, 보상 통제는 중간에 위험을 줄입니다. 이는 민감한 데이터를 저장하거나 처리하는 시스템에서 특히 중요하며, 이러한 시스템에서는 완화되지 않은 노출이 기술적 위험을 넘어서는 규제 및 비즈니스 결과를 초래할 수 있습니다. 네트워크 세분화, 액세스 제한 및 향상된 모니터링과 같은 제어는 내부 이동을 제한하고 공격 표면을 줄이며 악용이 발생하는 경우 탐지를 개선하는 데 도움이 됩니다.

보상 통제는 종종 일시적이지만 경우에 따라 장기적으로 유지되고 환경이 변함에 따라 효과적인 상태를 유지하기 위해 지속적인 모니터링이 필요할 수 있습니다. 예외와 함께 이를 추적하고, 정기적으로 검토하고, 수정이 가능할 때 영구 복구로 교체하는 것이 중요합니다.

자동화된 복구 관리

자동화는 실행을 가속화합니다. 또한 수천 개의 엔드포인트에 잘못된 구성 또는 패치 실패를 몇 분 만에 전파할 수 있습니다. 정답은 자동화입니다. 제어된 자동화: 생산 규모에 도달하기 전에 문제를 포착하는 제어와 속도 균형이 맞춰집니다.

[복잡한 기업 환경에서 작업하기 위해 자동화된 패치 복구가 필요한 사항과 위험을 증가시키지 않고 롤아웃을 단계적으로 수행하는 방법 알아보기]

신뢰도 점수 및 배포 자격

신뢰도 스코어 링은 데이터 기반 컨텍스트를 제공하여 팀이 롤아웃 전에 패치 또는 구성 변경의 안전성을 평가하는 데 도움이 됩니다. 자동으로 결정을 내리는 대신 이전 배포 성공, 안정성 결과 및 성능 영향과 같은 신호를 표시하여 운영자에게 정보를 제공합니다.

신뢰도가 높은 변경은 광범위한 출시를 위한 더 나은 후보일 수 있지만 신뢰도가 낮은 변경은 일반적으로 조직 정책에 따라 추가 검증, 테스트 또는 명시적 승인이 필요합니다.

위험 관리로서의 링 기반 배포

링 배포 단계는 점진적으로 더 큰 엔드포인트 그룹에 걸쳐 롤아웃됩니다. 일반적인 패턴: 카나리아(5–10 개 엔드포인트), 파일럿(50–200개), 광범위(나머지).

벨소리 간의 보류 기간이 중요합니다. 패치 실패율, 애플리케이션 호환성 오류 및 엔드포인트 안정성 신호를 주시하고 있습니다. 링당 실패 임계값은 중지 또는 롤백 시기를 정의합니다. 명확한 에스컬레이션 기준은 배포를 진행 또는 중지할 권한이 있는 사람을 결정합니다.

링 배포는 엔터프라이즈 규모에서 자동화를 더 안전하게 만드는 데 도움이 되는 메커니즘입니다.

플레이북 기반 실행

플레이북은 적용할 수정 유형, 이를 대상으로 하는 범위 및 엔드포인트 그룹 전반에서 배포가 진행되는 방법을 포함하여 자동화된 복구 로직을 정의합니다.

실행에는 종종 승인 단계 및 단계적 출시가 포함되므로, 팀은 보다 광범위한 배포 전에 변경 사항을 검토하고 결과를 검증할 수 있습니다.

또한 Playbook 실행은 티켓팅 및 변경 관리 프로세스를 포함한 기존 워크플로와 통합하여 복구 작업 및 승인이 팀이 이미 운영 중인 방식과 일치하도록 할 수 있습니다.

IT/SecOps 조정 문제

무엇을 수정해야 하는지 알고 어떻게 수정해야 하는지 알고 있다고 해서 수정이 보장되지는 않습니다. 고장은 일반적으로 보안과 IT 운영 부서 간의 핸드오프에서 발생합니다.

핸드오프가 분해되는 위치

보안 팀은 취약성을 식별하고 우선순위를 지정합니다. IT 운영 팀은 시스템을 소유하고 수정을 실행합니다. 배포 진행 상황, 검증 결과 및 소유권 책임에 대한 공유 가시성이 없으면 수정이 실제로 확인되기 전에 복구 노력이 완료된 것으로 보일 수 있으므로 노출이 열려 있고 감사 증거가 불완전합니다.

특정 장애 지점은 다음과 같습니다.

• 보안 부서는 수정이 '권장'일 때 티켓을 닫습니다. IT 부서가 아직 배포하지 않았습니다.
• IT 부서는 패치가 \"배포\"될 때 티켓을 닫습니다. 보안 부서는 수정이 취약성을 닫았는지 확인하지 못했습니다.
• 공유 대기열 없음: 보안은 취약성 스캐너에서 작동합니다. IT는 ITSM(IT 서비스 관리) 티켓팅 시스템에서 작동합니다. 이들 간에 자동 번역이 존재하지 않습니다.
• SLA 불일치: 보안 부서는 48 시간 내에 중요한 CVE가 패치될 것으로 예상합니다. 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 플랫폼은 실시간 엔드포인트 가시성 및 제어를 통해 취약성 식별, 복구 작업 및 검증 워크플로를 연결하여 단편화된 도구에 대한 의존도를 줄입니다.

실제로 이는 다음과 같은 기능*을 통해 나타납니다.

• 실시간 엔드포인트 가시성과 온디맨드 취약성 및 구성 평가: 정기적으로 업데이트되는 콘텐츠 라이브러리가 지원하는 운영 체제, 애플리케이션 및 구성 포함
• 중대하고 새로운 취약성에 대한 실시간 경고: Tanium 콘솔 내의 취약성 비상 대응 팀(VERT) 조사의 지원을 받는 Tanium Guardian 을 통해 제공, 종종 권장 복구 작업 및 지침 포함
• 통합 복구 워크플로: 식별된 취약성에 대해 조치를 취하고 동일한 플랫폼 내에서 복구 워크플로를 시작하여 도구 간 전환 필요성을 줄입니다.
• 신뢰도 점수: 설치 성공률, 안정성 결과 및 성능 영향과 같은 신호를 사용하여 더 광범위한 배포 전에 패치 결정에 대한 정보를 제공합니다.
• 점진적 링 기반 배포: 소규모 엔드포인트 그룹으로 시작하여 결과를 검증하고 각 단계가 성공 기준을 충족함에 따라 롤아웃을 확장합니다.
• 저코드 및 무코드 자동화 플레이북: Tanium Automate를 사용하여 운영자의 감독 하에 엔드포인트 및 복구 워크플로를 오케스트레이션합니다.
• 배포 후 유효성 검사 기능: 패치 상태를 확인하고 복구 작업이 예상대로 적용되지 않은 시스템을 식별합니다.
• ServiceNow 및 기타 주요 워크플로와의 통합: IT 및 보안 팀에게 기존 프로세스 내에서 일관된 엔드포인트 데이터에 대한 액세스 제공
• 구성 평가 및 취약성 관리 사용 사례: PCI, HIPAA 및 SOX와 같은 일반적인 프레임워크와 일치
• 복구 가시성: 보안 및 운영 팀이 복구 진행 상황을 추적하고 실행을 조정하는 데 도움이 되는 패치 적용 가능한 취약성, 누락된 패치 및 배포 상태를 표시합니다.

*설명된 기능 및 결과는 Tanium 제품 설명서, 검증된 고객 사례 연구 및 실제 사용을 기반으로 합니다. 실제 결과는 배포 환경, 구성 및 조직 성숙도에 따라 다를 수 있습니다.

Tanium을 사용하면 복구 작업을 배포하는 데 사용되는 것과 동일한 워크플로에 검증을 통합할 수 있습니다. 팀은 패치 설치 상태 또는 구성 변경과 같은 엔드포인트 상태를 확인하고 노출을 재평가하여 복구 작업이 의도한 결과를 달성했는지 여부를 평가할 수 있습니다.

복구 활동 추적에서 위험 감소 확인에 이르기까지 이러한 변화는 대응적인 프로그램과 성숙한 프로그램을 구분합니다.

대부분의 규정 준수 도구는 무엇이 잘못된지 알려줍니다. 더 적은 수로 이에 대해 무엇을 해야 하는지 알 수 있으며, 거의 아무것도 동일한 화면에서 작업할 수 없습니다. Tanium Comply 의 개선 가시성은 이를 변경합니다. Tech Talks #121에서 Tanium Risk & Compliance 도메인 아키텍트 Margie Sills는 이 기능이 취약점을 실행 가능한 패치에 매핑하는 방법과 위험 감소 영향에 따라 순위를 매기는 방법, 그리고 도구를 전환하거나 핸드오프를 기다리지 않고 팀이 검색에서 수정으로 전환하는 방법을 세분화합니다.

취약성 개선 FAQ

개선 실행은 프로세스 문서에 깔끔하게 맞지 않는 실용적인 질문을 제기합니다. 다음은 스캔 결과를 실행으로 변환할 때 팀이 자주 묻는 일반적인 질문입니다.

취약성 스캐너가 수백 개의 CVE를 반환했습니다. 어디서부터 시작해야 합니까?

CVSS 점수만으로는 시퀀싱에 충분하지 않습니다. 도메인 컨트롤러의 CVSS 7,5 은 격리된 테스트 시스템의 CVSS 9,0 보다 우선 순위가 더 높은 실행 대상입니다.

활성 악용 상태(CISA KEV 및 EPSS 신호) 및 자산 중요도의 두 가지 렌즈를 통해 목록을 필터링합니다. 와일드에서 적극적으로 악용되고 중요한 자산에서 ‘적극적으로 악용되는’ 교차점의 항목은 첫 번째 실행 대기열을 형성합니다.

CVSS 점수가 먼저 해결해야 할 사항의 우선순위를 정하기에 충분하지 않은 이유는 무엇입니까?

CVSS는 정의된 조건에서 기본 및 환경 심각도를 측정하지만 적극적인 악용 또는 비즈니스 컨텍스트를 고려하지 않습니다. 취약점이 공개적으로 적극적으로 악용되고 있는지 또는 영향을 받는 시스템이 비즈니스에 중요한지 여부를 고려하지 않고 공격자에게 이상적인 조건에서 악용 가능성과 영향을 평가합니다.

환경에서 실행되지 않는 소프트웨어의 CVSS 9,8 은 적극적으로 악용되고 인터넷에 연결되는 시스템의 CVSS 6,5 보다 우선순위가 낮습니다. 효과적인 실행 순서는 CVSS와 EPSS(악용 가능성) 및 자산 중요도를 결합하며 심각도 점수만 결합하지 않습니다.

[취약성 평가의 작동 방식, 자산 검색 및 약점 우선순위 지정이 중요한 이유, 공격자가 먼저 격차를 발견하기 전에 노출을 줄이는 방법 알아보기]

개선이 완화와 어떻게 다릅니까?

복구는 패치 또는 구성 수정을 통해 소스에서 취약점을 해결하는 반면, 완화는 영구 수정이 가능할 때까지 네트워크 세분화 또는 액세스 제한과 같은 제어를 통해 일시적으로 악용 가능성을 줄입니다.

취약성 개선의 예는 무엇입니까?

알려진 CVE를 수정하기 위해 벤더가 발급한 패치를 적용하거나, 잘못 구성된 방화벽 규칙을 강화하거나, 수명 종료 소프트웨어를 지원되는 버전으로 업그레이드하는 것은 모두 노출을 줄이는 것이 아니라 소스에서 취약성을 해결하기 때문에 복구로 간주됩니다.

취약성 개선은 단지 취약성을 해결하는 것이 아니라 위험이 실제로 감소했는지 확인하는 것입니다. 우선순위 지정, 실행 및 검증을 연속 워크플로 에 연결하는 프로그램은 노출 기간을 줄이고 진화하는 사이버 위협에 보조를 맞출 수 있는 더 나은 위치에 있습니다.Tanium을 사용하여 환경 전반에서 취약성 복구를 간소화하고 검증하는 방법을 보려면 데모
일정을 잡으십시오.