벤더가 패치를 공개하면, 공격자들은 해당 패치가 해결하는 취약점에 대한 단서를 얻을 수 있습니다. 패치 배포 시점과 엔드포인트 전반에 걸친 설치 확인 시점 사이의 그 간극이 바로 위험이 누적되는 지점입니다.
이 가이드에서는 패치의 기술적 작동 원리, 실제로 접하게 될 다양한 유형의 패치, 그리고 배포만큼이나 검증도 중요한 이유에 대해 다룹니다.
소프트웨어 패치가 실제로 하는 역할
소프트웨어 패치란 기존 프로그램이나 운영 체제를 수정하는 작은 코드 조각을 말합니다. 패치는 버그를 수정하고, 보안 취약점을 해결하며, 성능을 향상시킵니다. 전체 소프트웨어 업데이트나 새 버전 출시와 달리, 패치는 애플리케이션 전체를 교체하지 않고 특정 문제만 해결합니다.
공급업체가 결함을 발견하면, 그것이 시스템 충돌을 일으키는 코딩 오류이든 공격자가 악용할 수 있는 수많은 알려진 취약점 중 하나이든 상관없이, 이를 수정하기 위한 패치를 개발합니다. 이 패치는 대상 시스템의 특정 파일, 레지스트리 항목 또는 구성 설정을 덮어쓰거나 수정합니다. 마치 기계의 엔진 전체를 교체하는 대신, 고장 난 부품 하나만 교체하는 것과 같다고 생각하면 됩니다.
패치는 공급업체 웹사이트, Windows Update와 같은 자동 업데이트, 앱 스토어 또는 기업용 패치 관리 도구를 통해 배포됩니다. 패치가 설치되면, 문제를 일으켰던 기본 코드를 수정하여 소프트웨어의 동작 방식을 변경합니다.
패치가 다른 업데이트 유형과 구별되는 점은 다음과 같습니다:
- 적용 범위: 패치는 기능에 광범위한 변경을 가하기보다는 구체적이고 국한된 문제를 해결합니다.
- 크기: 일반적으로 크기가 작으며, 대개 몇 메가바이트에 불과합니다.
- 긴급성: 특히 보안 패치는 공격자가 이미 파악하고 있을 수도 있는 취약점을 차단하기 때문에 시의적절하게 적용해야 합니다.
공급업체가 패치를 공개하면, 아직 해당 패치를 적용하지 않은 조직에 대해서는 취약점이 노출되는 기간이 시작됩니다. 해커와 조직화된 사이버 범죄자를 비롯한 기타 공격자들은 취약점이 어디에 존재하는지에 대한 중요한 단서를 얻을 수 있기 때문에, 패치 출시 상황을 자주 주시합니다. 그렇기 때문에 패치가 공개된 시점과 설치가 확인된 시점 사이의 시간이 그토록 중요한 것입니다.
[분기별 스캔과 수동 패치 주기로 운영 중이신가요? [실제 현장에서 지속적 노출 관리가 어떻게 이루어지는지 살펴보겠습니다]
기본적인 내용을 살펴봤으니, 다음 질문은 다음과 같습니다. 어떤 종류의 패치가 있으며, 그것들은 어떻게 다른가요?
소프트웨어 패치 유형에 대한 정밀한 분류 체계
모든 소프트웨어 패치가 동일한 긴급성이나 위험도를 지닌 것은 아닙니다. 이러한 차이점을 파악하면 배포 순서를 도착 순서가 아닌 실제 영향도에 따라 정할 수 있습니다.
| 패치 유형 | 목적 | 전형적인 긴급성 | 롤백의 복잡도 |
|---|---|---|---|
| 보안 패치 | 특정 취약점을 해결합니다 | 높음 ~ 매우 높음 | 보통은 간단합니다 |
| 핫픽스 | 정기 릴리스 주기 외의 긴급한 버그를 해결합니다. | 높음 | 범위에 따라 다릅니다 |
| 버그 수정 | 성능에 영향을 미치는 기능적 오류를 수정합니다. | 중간 | 보통은 간단합니다 |
| 누적 업데이트 | 여러 패치를 하나의 패키지로 묶습니다. | 중간 | 더 복잡하다 |
| 서비스 팩 | 패치, 버그 수정 및 기능 개선 사항을 통합합니다 | 아래로 | 복합체 |
| 기능 업데이트 | 새로운 기능과 새로운 성능을 추가합니다 | 아래로 | 다르다 |
보안 패치는 때때로 보안 업데이트라고도 불리며, 무단 접근, 데이터 도난 또는 시스템 침해로 이어질 수 있는 취약점을 해결합니다. 공통 취약점 평가 시스템(CVSS)은 심각도를 0 에서 10까지의 척도로 평가합니다. CVSS 점수가 9,0 이상인 경우, 일반적으로 즉시 우선순위를 두고 대응해야 할 심각한 취약점을 의미합니다.
핫픽스는 정기 업데이트 일정 외에 배포되는 신속 대응 패치입니다. 다음 예정된 릴리스를 기다리는 동안 시스템이 현재 진행 중인 위협이나 중대한 버그에 노출될 우려가 있는 경우, 공급업체는 핫픽스를 배포합니다.
의 누적 업데이트는 여러 패치를 하나의 패키지로 묶어 제공합니다. 마이크로소프트의 월간 ‘패치 화요일’ 업데이트는 대개 이러한 형태를 띱니다. 누적 업데이트는 편리하기는 하지만, 여러 변경 사항이 한데 묶여 있기 때문에 롤백하기가 더 어려울 수 있습니다.
실질적인 시사점: 보안 패치 및 핫픽스 는 현재 존재 중인 취약점을 차단하므로 가장 신속한 대응이 필요합니다. 누적 업데이트 와, 서비스 팩 에는 여러 가지 수정 사항과 개선 사항이 한데 묶여 있어, 이를 깨끗하게 롤백하기가 더 어렵습니다. 대규모 배포에 앞서 대표적인 애플리케이션 환경에서 테스트해 보십시오.
의 새로운 기능을 도입하는 기능 업데이트는 긴급도가 가장 낮지만, 호환성 문제가 가장 예측하기 어렵습니다.
패치 유형에 대해 명확히 알아보았으니, 이제 패치가 공급업체의 출시 단계부터 엔드포인트 설치 단계까지 거치는 과정을 살펴보겠습니다.
공급업체의 릴리스부터 엔드포인트 설치에 이르는 소프트웨어 패치의 수명 주기
공급업체가 소프트웨어 패치를 배포하는 시점부터 사용자의 엔드포인트에서 해당 패치가 검증되는 시점까지, 여러 가지 문제가 발생할 수 있습니다. 라이프사이클의 각 단계는 잠재적인 지연 요인이 되며, 모든 지연은 공격자가 활동할 수 있는 시간을 늘려줍니다.
1. 발견: 공급업체는 내부 테스트, 보안 연구원 또는 고객 제보를 통해 보안 결함을 파악합니다. 보안 문제의 경우, 대개 공개 전에 CISA나 미국 국립표준기술원( , NIST) 과 같은 기관과 협의를 거치게 됩니다.
2. 개발: 엔지니어들은 수정 사항을 작성하고, 다양한 구성 환경에서 테스트한 후 배포를 위해 패키징합니다. 이 단계는 작업의 복잡성에 따라 며칠에서 몇 주까지 걸릴 수 있습니다.
3. 배포: 해당 벤더는 공식 채널을 통해 패치를 배포합니다. 널리 사용되는 소프트웨어의 경우, 이번 공지가 공격자들에게 해당 취약점의 존재를 알릴 수 있습니다.
4. 탐지: 귀사의 조직은 자사 소프트웨어와 타사 애플리케이션 모두에 대한 새로운 패치가 존재한다는 사실을 알게 됩니다. 이는 공급업체 공지, 패치 관리 플랫폼의 자동 알림, CISA의 ‘알려진 악용 취약점(KEV)’ 카탈로그, 국가 취약점 데이터베이스(NVD) 또는 자동 스캔 도구를 통해 이루어집니다.
5. 우선순위 지정: 의 취약점 심각도, 자산의 중요도 및 비즈니스 상황을 바탕으로, 어떤 엔드포인트가 영향을 받는지와 패치 배포의 시급성을 평가합니다.
6. 테스트: 대규모 배포에 앞서, 호환성 문제나 예상치 못한 동작을 파악하기 위해 대표적인 엔드포인트 샘플을 대상으로 패치를 테스트합니다.
7. 배포: 이 패치는 사용자의 배포 인프라를 통해 대상 엔드포인트에 배포됩니다. 이는 단계적으로 진행될 수 있으며, 우선 중요도가 낮은 시스템부터 시작하여 이후 운영 환경으로 넘어갈 수 있습니다.
8. 검증: 배포 명령이 실행되었는지 여부뿐만 아니라, 취약점이 있는 애플리케이션 코드나 라이브러리가 실제로 교체되었는지 확인하여, 대상 엔드포인트에 소프트웨어 패치가 성공적으로 설치되었음을 확인합니다.
[패치 관리 모범 사례는 그 어느 때보다 중요해졌습니다. 선제적인 위험 관리와 사후 대응을 구분하는 방법은 다음과 같습니다.]
3 단계(출시)와 8 단계(검증) 사이의 간극이 바로 위험이 누적되는 지점입니다. 에 대한 패치가 적용되지 않은 엔드포인트 가 있는 상태로 하루하루가 지날수록 공격자들에게 유리한 상황이 지속될 수 있습니다.
팁: 현재 패치 적용 프로세스 워크플로우 를 이러한 단계에 맞춰 정리해 보세요. 지연은 주로 어디에서 발생하나요? 바로 그곳이 개선 노력을 집중해야 할 부분입니다.
노출 기간과 그에 수반되는 위험
노출 기간이란 공급업체가 패치를 출시한 시점부터 해당 패치가 영향을 받는 모든 엔드포인트에 설치되었음을 확인하기까지의 기간을 말합니다. 이건 추상적인 개념이 아닙니다. 이는 측정 가능한 위험입니다.
공격자들은 기다리지 않습니다. 패치가 출시되면, 해당 패치가 어떤 취약점을 해결하는지에 대한 세부 정보가 포함되는 경우가 많습니다. 보안 연구원들과 위협 행위자 모두 패치를 리버스 엔지니어링하여, 패치가 적용되지 않은 시스템을 정확히 어떻게 악용할 수 있는지 파악할 수 있습니다. 대부분의 경우, 이들은 그 정보를 재빨리 악용하여, 조직이 대응할 틈도 없이 새로 드러난 취약점을 노리는 악성코드를 유포합니다.
그 취약점 노출 기간 동안의 매일매일은, 공격자들이 해당 공급업체가 패치를 공개할 때 제공한 정보를 바탕으로 공격을 감행할 수 있는 날입니다. 일반적인 노출 기간 동안 어떤 일이 일어나는지 생각해 봅시다:
- 0일 차: 공급업체, 패치 및 권고 사항 발표
- 1–3일 차: 공격자들이 패치 내용을 바탕으로 익스플로잇 개발을 시작하다
- 7일 차: ‘ ’ 익스플로잇 코드가 암시장 포럼에서 유포되고 있을 수 있음
- 14일 차: 이 익스플로잇을 활용한 자동화된 공격 도구가 등장했다
- 30일 차 이상: 귀사의 조직이 드디어 배포를 완료했습니다
해당 기간 동안, 패치가 적용되지 않은 엔드포인트 는 여전히 취약한 상태로 남아 있을 수 있습니다. 창이 열려 있는 시간이 길어질수록 보안 침해 가능성이 높아집니다. 패치가 적용되지 않은 애플리케이션의 취약점은 공격자들에게 점점 더 주요 침투 경로로 활용되고 있으며, 이로 인해 규제, 재정적, 평판상의 결과를 초래할 수 있는 데이터 유출 위험이 높아지고 있습니다.
하지만 노출 범위는 단순히 속도만의 문제가 아닙니다. 또한 완전성에 관한 문제이기도 합니다. 영향을 받는 엔드포인트의 95 %에 대해서는 신속하게 패치를 적용하더라도 5 %를 놓친다면, 간과된 시스템들은 무기한으로 취약한 상태에 놓이게 됩니다.
대기업에서는 5 %가 수천 개의 취약한 엔드포인트를 의미할 수도 있습니다.
노출 기간을 단축하려면 두 가지가 필요합니다. 바로 소프트웨어 패치를 신속하게 배포하고, 해당 패치가 영향을 받는 모든 엔드포인트에 실제로 설치되었는지 확인하는 것입니다. 대부분의 조직은 첫 번째 부분에서는 꽤 잘 해내고 있습니다. 두 번째는 프로그램이 눈에 띄지 않게 오작동하는 경우입니다.
대규모 환경에서 소프트웨어 패치 배포가 종종 실패하는 이유
수천 개의 엔드포인트에 소프트웨어 패치를 배포하는 일은 기계적인 작업처럼 들린다. 실제로 이곳은 보안 사각지대가 은연중에 형성되고, 보안 침해 사고가 발생하며, 패치가 적용되지 않은 애플리케이션 취약점이 가장 오랫동안 남아 있는 곳입니다.
엔드포인트에 항상 접속할 수 있는 것은 아닙니다. 노트북은 이동이 잦다. 재택근무자들의 연결 상태가 간헐적으로 끊기곤 합니다. 격리된 네트워크 세그먼트에 있는 서버는 배포 명령을 수신하지 못할 수 있습니다. 패치가 배포될 때 엔드포인트가 온라인 상태가 아니거나 연결되어 있지 않으면, 해당 엔드포인트에는 패치가 적용되지 않습니다.
[가동 시간, 종속성 및 감사 대비 상태를 보호하면서 악용될 수 있는 위험을 줄이기 위한 서버 패치 관리 전략을 살펴보세요]
의존성은 충돌을 일으킵니다. 한 애플리케이션에 대한 소프트웨어 패치가 특정 버전이나 공유 라이브러리에 의존하는 다른 애플리케이션을 오작동하게 만들 수 있습니다. 어떤 애플리케이션이 설치되어 있고, 애플리케이션들이 서로 어떻게 상호작용하는지 파악하지 못하면, 무언가가 작동을 멈출 때까지는 문제가 있다는 사실조차 알 수 없습니다.
이질적인 환경은 복잡성을 가중시킵니다. 기업들은 여러 버전의 애플리케이션, 종속성 스택 및 OS 구성을 동시에 운영합니다. 특정 애플리케이션 버전에 대해 검증된 소프트웨어 패치가 다른 버전에서는 다르게 작동할 수 있습니다. 실제로 무엇이 설치되어 있는지 파악하지 못하면, 무작정 배포하는 셈입니다.
자기 보고는 신뢰할 수 없다. 많은 패치 도구들은 패치가 실제로 올바르게 설치되었는지 여부가 아니라, 배포 명령이 실행되었는지에 따라 성공 여부를 보고합니다. 기본적인 취약점이 여전히 남아 있음에도 불구하고, 엔드포인트에서는 “패치됨”으로 보고될 수 있습니다.
[매일 130 건 이상의 새로운 취약점이 공개되는 상황에서, 현대적인 취약점 관리가 한 발 앞서 나가는 것과 뒤쫓아가는 것의 차이를 만드는 이유는 다음과 같습니다]
유지보수 가능 기간은 제한되어 있습니다. 가동 중단 가능성이 있어 업무 시간 중에 재시작할 수 없는 애플리케이션은 패치 적용 가능 시간을 매우 제한적으로 만듭니다. 배포가 완료되기 전에 해당 창이 닫히면, 소프트웨어 패치는 적용되지 않고 대기열에 쌓이게 됩니다. 미해결 과제는 시간이 지남에 따라 누적되어, 적용되지 못한 각 패치의 취약성 노출 기간을 늘리고, IT 지원 팀이 선제적인 배포보다는 사후 대응적인 문제 해결에 매달리게 만듭니다.
패치가 실제로 적용되었는지 확인하기
배치는 결승선이 아닙니다. 검증이란.
설치 여부가 확인되지 않은 채 배포된 소프트웨어 패치는 해결된 취약점이 아니라 아직 해결되지 않은 문제입니다. “적용했다”와 “확인했다” 사이의 차이가 바로 조직들이 실제 패치 적용 범위를 지속적으로 과대평가하는 지점입니다.
검증은 다음 세 가지 질문에 답합니다:
- 패치가 엔드포인트에 적용되었나요? 네트워크 문제, 오프라인 상태인 기기 또는 배포 오류로 인해 전송이 이루어지지 않을 수 있습니다.
- 엔드포인트에 패치가 성공적으로 설치되었나요? 디스크 공간이 부족하거나, 권한 오류가 발생하거나, 충돌이 발생하면 패치가 전달되었더라도 설치가 실패할 수 있습니다.
- 해당 취약점은 실제로 해결되었나요? 경우에 따라 패치가 설치되더라도 구성 요구 사항이나 재부팅이 필요한 상태인 탓에 문제가 완전히 해결되지 않을 수 있습니다.
많은 조직이 패치 관리 도구의 성공 보고서에 의존하고 있습니다. 하지만 이러한 보고서는 대개 배치 시도만을 반영할 뿐, 검증된 결과는 아닙니다. 도구에서 패치를 적용했다고 표시됩니다. 이는 해당 엔드포인트가 패치를 실제로 올바르게 수신하고 설치했는지, 또는 근본적인 취약점이 해결되었는지를 확인해 주지는 않습니다.
효과적인 검증을 위해서는 엔드포인트에 직접 쿼리를 보내 현재 상태를 확인해야 합니다. 어떤 버전의 애플리케이션이 설치되어 있나요? 취약점이 있는 라이브러리나 파일이 여전히 존재하나요? 패치된 코드를 적용하기 위해 애플리케이션을 다시 시작했습니까?
바로 이 지점에서 의 실시간 엔드포인트 가시성 이 매우 중요해집니다. 특정 시점 스캔은 스캔 중에 오프라인 상태였던 엔드포인트를 놓치게 됩니다.
또한 스캔이 완료된 후 발생한 변경 사항도 놓치게 됩니다. 지속적인 가시성을 통해 전체 환경에 걸친 패치 상태에 대한 최신의 정확한 현황을 파악할 수 있습니다.
팁: 중요한 패치를 적용한 후에는 영향을 받은 엔드포인트를 직접 조회하여 취약한 구성 요소가 더 이상 존재하지 않는지 확인하십시오. 배포 로그에만 전적으로 의존하지 마십시오.
검증은 개별 소프트웨어 패치의 전체 과정을 마무리합니다. 하지만 어떤 패치도 단독으로 배포되는 것은 아니며, 공급업체의 릴리스 단계에서 검증된 엔드포인트 상태로 패치를 이동시키는 역할을 담당하는 프로그램이야말로 대규모 환경에서 패치 적용 범위가 유지되는지를 결정하는 핵심 요소입니다.
패치 관리에서 소프트웨어 패치의 위치
소프트웨어 패치가 무엇이며 어떻게 작동하는지 이해하는 것은 기본입니다. 하지만 기업 환경에서는 개별 패치가 저절로 배포되지는 않습니다. 이 과정은 ‘탐지, 우선순위 지정, 테스트, 배포, 검증’이라는 순서로 진행됩니다.
이 프로그램이 바로 패치 관리이며, 이 프로그램이 얼마나 원활하게 작동하느냐에 따라 소프트웨어 패치가 출시된 후 조직이 취약점 노출 기간을 얼마나 빨리 해소할 수 있는지가 결정됩니다. 패치 관리 프로그램의 구성 및 평가 방식에 대해 더 자세히 알아보려면, ‘ ’의 패치 관리 가이드()를 참조하십시오.
소프트웨어 패치가 바로 그 산물입니다. 패치 관리는 공급업체의 릴리스 버전에서 시작하여 잠재적으로 수십만 개에 달하는 엔드포인트 전반에 걸쳐 검증된 설치 단계까지 해당 아티팩트를 배포하는 시스템입니다.
이러한 구분이 중요한 이유는, 패치 실패의 상당수가 패치 자체의 문제가 아니기 때문입니다. 이 내용은 프로그램에 관한 것입니다:
- 탐지 사각지대: 패치가 존재하는지, 어떤 엔드포인트에 해당 패치가 필요한지 알 수 없음
- 우선순위 지정 실패: 중요한 패치들이 정기 업데이트 뒤에 대기열에 밀려 있다
- 테스트 병목 현상: 팀들이 호환성을 수동으로 검증하는 동안 배포가 지연되고 있습니다.
- 배포 제한 사항: 패치가 영향을 받는 모든 엔드포인트에 적용되지 않을 수 있습니다.
- 검증 누락: 패치가 실제로 설치되었는지 확실하지 않은 경우
이것들은 모두 패치 차원의 문제가 아니라 프로그램 차원의 과제입니다.
적절한 패치 관리 소프트웨어를 선택하는 것은 이러한 취약점을 체계적으로 해결하기 위한 첫 번째 단계인 경우가 많으며, 이를 통해 팀은 대규모 운영을 수행하는 데 필요한 가시성, 자동화 및 보고 기능을 확보할 수 있습니다.
대규모의 분산된 엔드포인트 환경을 관리하는 조직의 경우, 프로그램 차원의 과제가 개별 패치의 기술적 복잡성을 훨씬 능가하는 경우가 많습니다.
실시간 가시성, 검증된 배포, 명확한 패치 정책 및 자동화된 패치 관리 워크플로는, 특히 수천 개의 엔드포인트 전반에 걸쳐 패치 상태를 수동으로 추적해야 하는 상황을 고려할 때, 단순히 ‘있으면 좋은’ 기능이 아니라 운영상의 필수 요소가 됩니다.
Tanium이 기업의 소프트웨어 패치 관리를 어떻게 지원하는가
위에서 설명한 문제들, 즉 오래된 가시성, 배포 실패, 검증되지 않은 수정 조치 등은 개별 패치로는 해결할 수 없는 프로그램 차원의 문제들입니다.
타늄(Tanium)의 자율 IT 플랫폼 ‘ ’은 이러한 문제를 근본적으로 해결합니다. 즉, 엔드포인트에 직접 쿼리를 보내 실시간 패치 상태를 확인하고, 타늄 보안 신뢰도 점수(Confidence Scores) 및 취약점 데이터를 바탕으로 실제 위험도에 따라 배포 순서를 결정하며, 단순히 배포 로그에만 의존하지 않고 설치 성공 여부를 직접 확인합니다.
대규모의 분산된 엔드포인트 환경을 관리하는 조직의 경우, 이러한 조합은 별도의 인프라를 구축할 필요 없이, 스캔 기반 접근 방식이 일반적으로 허용하는 것보다 더 신속하게 패치 출시와 검증된 수정 조치 간의 격차를 해소할 수 있도록 설계되었습니다.
실시간 가시성을 기반으로
패치 프로그램이 대규모로 실패하는 가장 흔한 이유는 노력 부족 때문이 아닙니다. 정확하고 최신 데이터가 부족하기 때문입니다. Tanium의 자율 IT 플랫폼은 Windows , Linux 및 macOS 기기에 걸쳐 엔드포인트의 패치 상태를 실시간으로 파악할 수 있도록 지원함으로써 이 문제를 직접 해결합니다.
[리눅스 환경이 점점 더 복잡해짐에 따라, 정기적인 패치 적용과 지속적인 취약점 관리 간의 격차가 그 어느 때보다 큰 비용을 초래하는 이유는 다음과 같습니다]
몇 시간 또는 며칠 전의 스캔 데이터에 의존하는 대신, Tanium을 사용하는 조직은 엔드포인트에 직접 쿼리를 실행하여 현재 상태를 파악할 수 있습니다. 중요한 패치가 출시되면, IT 팀은 예정된 스캔 주기가 완료될 때까지 기다릴 필요 없이, 어떤 엔드포인트가 영향을 받을 가능성이 높은지, 어떤 엔드포인트는 이미 패치가 적용된 것으로 보이는지, 그리고 어떤 엔드포인트는 패치 적용을 연기해야 할지 신속하게 파악할 수 있습니다.
Tanium의 자율 IT 플랫폼은 지사, 원격 위치 및 지리적으로 분산된 사이트의 엔드포인트를 포함한 분산 환경 전반에 걸쳐 가시성을 유지하도록 설계되었으며, 단일 Tanium 인스턴스에서 모든 기능을 처리함으로써 보조 중계 서버, 데이터베이스 또는 배포 서버에 대한 의존도를 줄이도록 구성되었습니다.
이 플랫폼의 아키텍처는 수십만 개의 엔드포인트가 포함된 배포 환경을 비롯한 대규모 환경을 지원하도록 설계되었습니다. 이 척도가 중요한 이유는 패치 적용에 공백이 생기는 부분이 거의 균일하지 않기 때문입니다. 접근하기 가장 어려운 끝부분일수록 패치가 적용되지 않은 채로 남을 가능성이 가장 높습니다.
배포 전 위험 기반 우선순위 지정
모든 소프트웨어 패치가 똑같이 시급한 것은 아닙니다. 우선순위를 정하지 않고 배포를 진행하면, 팀은 활성 취약점 창을 해결하는 것만큼이나 위험도가 낮은 애플리케이션 업데이트를 처리하느라 분주해질 가능성이 높습니다.
Tanium의 자율 IT 플랫폼을 통해 조직은 취약점 데이터를 엔드포인트 중요도 및 신뢰도 점수와 결합하여 패치 적용 순위를 정하고, 고위험 취약점을 우선적으로 해결할 수 있습니다.
신뢰도 점수는 설치 성공률, 충돌 발생 빈도, 성능에 미치는 영향 등 다양한 추세를 실시간으로 클라우드 인텔리전스를 통해 분석하여 산출되며, 이를 통해 팀은 패치를 광범위하게 배포하기 전에 순차적 적용 결정을 내리는 데 활용할 수 있는 실질적인 데이터를 확보할 수 있습니다.
또한 이 플랫폼을 통해 팀은 위험 신호와 비즈니스 상황을 바탕으로, 노출 위험을 가장 크게 줄여주는 패치를 우선적으로 적용할 수 있습니다. 이 접근 방식은 패치 관리를 독립적인 IT 운영 업무로 취급하기보다는, 보다 광범위한 ‘ ’ 노출 관리 워크플로우와 직접 연계합니다.
팀은 패치 가능한 취약점과 가장 시급한 비정기 패치를 파악할 수 있으며, 이를 통해 보안 팀과 운영 팀 간의 의사소통을 원활하게 하고, 패치의 우선순위를 적절히 정하여 효과적으로 적용할 수 있습니다.
링 기반 단계적 배포를 통한 통제된 배포
Tanium의 자율 IT 플랫폼에서 운영 측면에서 특히 중요한 기능 중 하나는 점진적이고 한 링 기반 배포를 지원한다는 점입니다. 조직은 모든 엔드포인트에 패치를 동시에 배포하는 대신, 소수의 엔드포인트 그룹부터 시작하여 결과를 검증하고, Tanium 고객 커뮤니티에서 얻은 통찰력을 활용하여 각 단계가 성공 기준을 충족할 때마다 자신 있게 배포 범위를 확대해 나갈 수 있습니다.
이러한 접근 방식은 특히 제로데이 취약점의 경우, 속도가 매우 중요하지만 문제가 있는 패치로 인해 광범위한 혼란이 발생할 위험도 높은 상황에서 특히 적합합니다.
패치 배포는 승인 워크플로를 거쳐 처리되고 유지보수 시간대에 배정되어 비즈니스에 미치는 영향을 최소화할 수 있습니다. 팀은 조직의 기존 운영 방식에 맞춰 패치 일정 및 워크플로를 구성할 수 있으며, 이를 통해 어떤 엔드포인트가 어떤 순서로 패치를 받을지, 그리고 어떤 조건에서 배포가 다음 단계로 진행될지를 관리할 수 있습니다.
Tanium Automate를 기반으로 구축된 자동화 플레이북 은 대규모 엔드포인트 환경 전반에 걸쳐 소프트웨어 패치 워크플로를 실시간으로 관리할 수 있으며, 도구 간에 수동으로 작업을 넘겨받는 일련의 과정이 아닌, 단일한 반복 가능한 프로세스로 탐지, 배포 순서 지정 및 검증 단계를 처리합니다.
검증 및 폐쇄형 개선 조치
배포는 문제 해결과 같은 것이 아닙니다. Tanium의 자율 IT 플랫폼은 패치 적용 성공 여부, 예외 사항 및 성능 지표를 실시간으로 추적하며, 대상 선정, 시기 선정 및 순서 결정에 대한 향후 프로세스 개선을 지원하기 위한 상세한 보고서를 제공합니다.
배포가 완료된 후, 조직은 패치 적용 상태를 확인하고 업데이트에 실패한 시스템을 파악할 수 있으며, 이때 패치가 전달되었으나 설치되지 않은 엔드포인트와 배포 기간 동안 단순히 접속이 불가능했던 엔드포인트를 구분할 수 있습니다.
Tanium Comply 는 단순히 패치 배포가 완료되었는지 여부를 확인하는 데 그치지 않고, 패치 적용 후 소프트웨어 취약점이 실제로 해결되었는지까지 평가함으로써 이 기능을 한 단계 더 발전시켰습니다. 팀은 도구를 전환하거나 별도의 시스템에서 데이터를 통합할 필요 없이, 동일한 플랫폼 내에서 패치되지 않은 소프트웨어 취약점을 식별한 후 바로 수정 조치를 시작하고 진행 상황을 추적할 수 있습니다.
이러한 ‘식별-조치-검증’의 순환 과정은 패치 관리가 배포 단계에서 끝나는 것이 아니라, 취약점이 해결된 것으로 검증되었을 때 비로소 완료된다는 것을 의미합니다.
규정 준수 보고 및 감사 대비
소프트웨어 패치가 적용되었으며, 올바르게 적용되었음을 입증하는 것은 의 규제 감사 프로그램, 특히 HIPAA 및 PCI와 같은 프레임워크와 연계된 프로그램에서 점점 더 중요해지고 있습니다. Tanium은 이러한 문서화 요구 사항을 지원하도록 설계되었습니다.
Tanium Patch 는 모든 소프트웨어 패치의 배포 현황을 요약하여, 성공 여부와 조치가 필요한 실패 사례에 대한 즉각적인 피드백을 제공합니다. 감사관이 어떤 소프트웨어 패치가 언제 적용되었는지 물어볼 때, Tanium은 팀이 추측이 아닌 실제 데이터를 바탕으로 그 질문에 답변할 수 있도록 배포 내역, 재부팅 상태 및 수정 조치 확인 정보를 제공합니다.
규정 준수 격차에서 90% 패치 적용률 달성까지: 허니웰
허니웰(Honeywell)의 샌디에이고 지역 의료 센터( )는 패치 적용률이 낮아 랜섬웨어 및 기타 사이버 공격에 노출될 위험에 처해 있었습니다. Tanium을 도입한 후, 허니웰은 3개월 연속으로 패치 준수율 90 %를 달성했는데, 이는 이전에는 달성하지 못했던 수준이었다.
또한 Tanium을 통해 허니웰은 다른 패치 관리 도구를 통합하고, 경우에 따라서는 이를 완전히 제거할 수 있었으며, 경영진 및 운영 부문의 규정 준수 보고를 위한 통합 보고 플랫폼을 확보할 수 있었습니다.
”Tanium을 사용하기 전에는 패치 준수율이 낮았습니다. 이제 Tanium을 도입한 덕분에, 3개월 연속으로 패치 준수율이 90%를 넘어섰습니다. 그건 중요한 점입니다.”허니웰 IT 이사 마니쉬 초프라
소프트웨어 패치의 작동 원리는 간단합니다. 수천 개의 엔드포인트에 이를 하나씩 배포하는 운영상의 현실은 그렇지 않습니다. 다음은 가장 자주 제기되는 질문에 대한 답변입니다.
소프트웨어 패치 자주 묻는 질문
소프트웨어 패치와 업데이트의 차이점은 무엇인가요?
패치는 특정 문제, 주로 소프트웨어의 버그나 보안 취약점을 해결하기 위해 제공되는 맞춤형 수정 사항입니다. 업데이트는 패치, 기능 추가, 성능 개선 및 기타 변경 사항을 포괄할 수 있는 더 광범위한 용어입니다. 모든 패치는 업데이트이지만, 모든 업데이트가 패치인 것은 아닙니다.
소프트웨어 패치가 출시된 후 공격자들은 얼마나 빨리 행동에 나서는가?
대부분의 조직이 도입할 수 있는 속도보다 빠릅니다. 공급업체가 소프트웨어 패치를 출시할 때, 패치 자체를 통해 근본적인 결함에 대한 세부 정보가 드러날 수 있으며, 이로 인해 공격자들은 패치가 적용되지 않은 시스템을 악용할 수 있는 방법을 파악하게 됩니다. 주목받는 소프트웨어 취약점의 경우, 패치가 공개된 지 몇 시간 만에 악용 코드가 등장할 수 있습니다.
Check Point Research( )에 따르면, 널리 사용되는 자바 로깅 라이브러리의 결함인 ‘ 2021 Log4j ’ 취약점은 공개된 지 24 시간 만에 200.000 건 이상의 공격 시도가 발생했다고 밝혔다. 그렇기 때문에 소프트웨어 패치 출시와 검증된 설치 사이의 시간 차이는 단순한 운영상의 불편함이 아니라, 측정 가능한 위험 요소입니다.
문제가 발생하면 소프트웨어 패치를 되돌릴 수 있나요?
이는 패치가 어떻게 패키징되었는지에 따라 다릅니다. 대부분의 독립형 소프트웨어 패치는 해당 애플리케이션이나 패치 관리 도구를 통해 제거할 수 있으며, 이 경우 이전 버전으로 복원됩니다. 누적 업데이트는 한 가지 변경 사항을 되돌리려면 여러 가지를 되돌려야 하기 때문에 깔끔하게 원상복구하기가 더 어렵습니다.
소프트웨어 패치를 광범위하게 배포하기 전에, 대표적인 엔드포인트 샘플을 대상으로 테스트를 수행하고, 패치로 인해 호환성 문제나 예상치 못한 애플리케이션 동작이 발생할 경우를 대비해 롤백 절차를 마련해 두어야 합니다.
왜 일부 소프트웨어 패치는 재부팅이 필요한가요?
현재 사용 중인 응용 프로그램 파일이나 공유 라이브러리를 수정하는 소프트웨어 패치는 해당 파일이 활성화된 상태에서는 설치를 완료할 수 없습니다. 시스템을 재부팅하거나, 경우에 따라 애플리케이션을 다시 시작하면 해당 잠금이 해제되어 패치된 파일이 적용됩니다. 재부팅이 필요한지는 소프트웨어 패치가 무엇을 수정하는지와, 영향을 받는 애플리케이션을 전체 시스템 재부팅 없이 안전하게 다시 시작할 수 있는지 여부에 따라 달라집니다.
엔드포인트에서 소프트웨어 패치 배포를 놓치면 어떻게 되나요?
해당 엔드포인트는 패치로 해결하려 했던 소프트웨어 취약점에 여전히 노출되어 있습니다. 배치 일정을 놓친 것은 사소한 차질이 아닙니다. 이는 근본적인 코드 결함이 여전히 존재하며, 이를 악용할 수 있음을 의미합니다. 누락된 엔드포인트를 파악하려면, 패치가 배포되었음을 확인할 뿐 올바르게 설치되었는지는 확인하지 못하는 배포 로그에만 의존하지 말고, 해당 엔드포인트에 직접 쿼리를 보내 현재 소프트웨어 버전과 패치 상태를 확인해야 합니다.
많은 최신 패치 관리 솔루션은 누락된 배포를 추적하고, 자동으로 재시도하며, 미보완 부분을 파악하도록 설계되어 있어, 장기간 패치가 적용되지 않은 엔드포인트가 줄어듭니다.
효과적인 소프트웨어 패치 관리는 무엇을, 왜 배포하는지 이해하는 것에서 시작되며, 여기에는 패치가 가져오는 구체적인 코드 변경 사항과 패치가 올바르게 설치되지 않을 경우 어떤 일이 발생하는지까지 포함됩니다. 그 다음 단계는 노출 창을 가능한 한 신속하고 완벽하게 차단한 뒤, 실제로 성공했는지 확인하는 것입니다.
Tanium은 분산된 엔드포인트 환경 전반에 걸쳐 소프트웨어 패치 상태를 실시간으로 파악할 수 있게 해줌으로써, 팀이 취약점을 식별하고, 확신을 가지고 패치를 배포하며, 단순히 가정하는 대신 실제 수정 여부를 확인할 수 있도록 지원합니다. 에서 데모를 예약하여 엔터프라이즈 규모에서 어떻게 작동하는지 확인해 보세요.
