패치 관리와 SLA

우선순위 지정은 무엇을 수정할지 알려 주고, 패치 관리는 실제로 이러한 수정을 전체 환경에 걸쳐 제때 완료하도록 체계적으로 추진하는 프로세스입니다.

SLAs (서비스 수준 계약)는 여러 심각도에 따라 얼마나 빨리 조치해야 하는지 정의합니다. 이러한 계약이 없으면 긴급한 수정이 미뤄지고 책임 소재가 사라집니다.

반복 가능한 주기를 통해 시스템을 최신 상태로 유지합니다:

• 식별 — 사용 가능한 패치를 식별합니다(공급업체 권고, 스캔 결과).
• 평가 — 적용의 관련성과 위험을 평가합니다.
• 테스트 — 비운영 환경에서 테스트합니다.
• 배포 — 통제된 단계별로 배포합니다.
• 확인 — 패치가 적용되었고 시스템이 정상인지 확인합니다.

각 단계에는 담당자와 증적이 있으며, 이는 더 넓은 VM 수명 주기를 반영합니다.

SLA는 의도를 기한으로 바꿉니다. 발견부터 조치 완료까지 허용되는 최대 시간을 심각도별로 설정합니다. 목표 예시는 다음과 같습니다:

• 치명적 / KEV: 7~15일(인터넷에 노출된 경우에는 더 빠르게).
• 높음: 30일.
• 중간: 90일.
• 낮음: 가능한 범위에서 처리 / 다음 주기.

SLAs를 사용하면 미해결 기간을 측정할 수 있고, 단순히 인지하는 데 그치지 않고 종료하도록 압박할 수 있습니다.

시간 제한을 CVSS만이 아니라 실제 위험에 연결하십시오. KEV에 등록되었거나 인터넷에 노출된 치명적 취약점에는 내부의 중간 수준 취약점보다 더 짧은 SLA를 적용해야 합니다.

참조 프레임워크가 도움이 됩니다. CISA는 연방 기관에 정해진 기한 내 KEV 조치를 의무화하며, 많은 기업은 CVSS와 관계없이 활발히 악용되는 취약점에 비슷하게 단축된 일정을 적용합니다.

패치로 인해 문제가 발생할 수 있습니다. 테스트를 스테이징 환경에서 수행하면 운영 환경에 영향을 주기 전에 회귀 문제를 발견할 수 있습니다:

• 먼저 대표 테스트 그룹에 적용합니다.
• 핵심 기능과 성능을 검증합니다.
• 기존 소프트웨어와 충돌하지 않는지 확인합니다.

속도와 안전성 사이에서 균형을 잡으십시오. 실제 환경에서 악용되는 KEV의 경우 일반 업데이트보다 더 큰 위험을 감수하고 더 빠르게 패치해야 합니다.

단계별로 배포합니다(링 배포). 파일럿 그룹에서 시작하여 더 넓은 링으로 확장한 다음 전체에 배포합니다. 다음 단계로 진행하기 전에 각 링의 상태를 모니터링하십시오.

항상 되돌리기 계획을 마련하십시오. 스냅샷, 패키지를 이전 버전으로 되돌리기 또는 구성 복원 등을 사용할 수 있습니다. 패치로 인해 서비스가 중단되면 조사하는 동안 신속하게 되돌릴 수 있어야 합니다.

수동 패치는 규모가 커지면 감당하기 어렵습니다. 중앙 집중식 도구를 사용하십시오:

• Windows에는 WSUS / SCCM / 인튠을 사용합니다.
• Linux 시스템 전체에는 구성 관리 도구(앤서블, 퍼펫, 셰프)를 사용합니다.
• 클라우드와 컨테이너에는 패치가 적용된 표준/기본 이미지를 다시 빌드합니다.

자동화는 일관성을 보장하고 패치 출시와 배포 사이의 시간을 줄입니다.

공급업체 지연, 취약한 레거시 시스템 또는 필수 가동 시간 때문에 즉시 패치할 수 없는 경우가 있습니다. 그동안 위험을 줄이기 위해 보완 통제를 적용하십시오:

• 네트워크 분할 / 방화벽 규칙.
• WAF 또는 IPS 시그니처를 통한 가상 패치.
• 취약한 기능 또는 서비스 비활성화.

이러한 방법은 시간을 벌어 주지만 실제 수정의 영구적인 대체 수단은 아닙니다.

지원 종료 시스템에는 패치가 전혀 없을 수 있습니다. 가능한 방법은 다음과 같습니다:

• 제한된 네트워크 구간에 격리합니다.
• 엄격한 접근 제어와 모니터링으로 보호합니다.
• 기한을 정해 이전 또는 폐기를 계획합니다.
• 만료일을 정해 잔여 위험을 공식적으로 수용합니다.

모든 내용을 문서화하십시오. 문서화되지 않은 채 방치된 패치 불가 시스템은 감사 및 침해 사고 위험이 됩니다.

프로그램이 실제로 약속을 지키는지 추적하십시오:

• 심각도별 MTTR과 SLA 목표 비교.
• SLA 준수율(기한 내 종료된 비율).
• 팀과 자산별 기한 초과 / 미해결 기간이 긴 발견 사항.
• 패치 적용 범위(최신 상태인 시스템 전체의 비율).

담당 팀별로 보고하여 책임 소재를 명확히 하고 지연 영역에 관심이 집중되게 하십시오.

배포 후에는 확인하십시오. 다시 스캔하여 CVE가 사라졌고 시스템이 정상인지 확인한 다음, 증적과 함께 발견 사항을 종료합니다. 반복되는 문제(계속 다시 나타나는 라이브러리, 만성적으로 지연되는 팀)는 프로세스 개선에 반영하십시오.

패치 관리를 잘 수행하면 우선순위가 지정된 위험을 측정 가능하고 기한 내에 줄일 수 있습니다.

조치 완료 SLA의 역할을 확인하십시오.

패치 관리는 식별, 평가, 테스트, 단계별 배포 및 확인을 통해 우선순위가 지정된 발견 사항을 완료까지 이끌며, 되돌리기 계획과 자동화가 이를 뒷받침합니다. SLAs는 심각도와 위험 수준에 따른 기한을 설정하므로(KEV 및 인터넷 노출 자산에는 더 짧게 설정) 수정이 제때 완료됩니다.

패치가 불가능한 경우에는 보완 통제와 문서화된 기간 제한형 위험 수용을 사용하십시오. MTTR, SLA 준수율 및 적용 범위를 측정하고, 얻은 교훈을 수명 주기에 반영하십시오.