취약성 관리 모범 사례
조직의 시스템에 취약성이 많을수록 공격자가 접근하여 비즈니스, 직원 및 고객에게 피해를 입힐 수 있는 기회가 많아집니다.
취약성 관리 프로세스를 설계하고 구현할 때는 다음과 같은 모범 사례를 고려하세요.
#1. 정기적인 취약성 검사 수행
취약성 스캐너는 애플리케이션 내에서 잠재적인 취약성 및 기타 보안 위험을 식별하는 데 사용되는 자동화된 도구입니다. 스캔이 자동화되고 예약할 수 있으므로 보안 팀의 추가 오버헤드가 최소화됩니다.
조직은 취약성 검사를 수행해야 합니다:
- 일정한 간격으로: 보안팀은 일정한 주기(매일, 매주 등)로 취약성 스캔을 예약해야 합니다. 이를 통해 환경에 새로 발견되거나 도입된 취약점을 식별하는 데 도움이 됩니다.
- 새 소프트웨어: 새 애플리케이션을 배포하기 전과 후에 소프트웨어의 취약성을 검사해야 합니다. 이를 통해 조직의 환경에 새로운 보안 위험이 도입되지 않도록 할 수 있습니다.
- 새로운 취약성이 발표될 때: Log4J 취약점과 같은 일부 취약성은 즉각적인 조치가 필요합니다. 새로운 주요 취약점이 발표되면 조직은 임시 취약점 검사를 수행하여 위험 노출을 확인해야 합니다.
취약성 평가 프로그램을 설계할 때는 다양한 취약성의 가시성을 고려하는 것도 중요합니다. 취약성 검사는 기업 네트워크 외부와 내부에서 다양한 권한 수준(인증되지 않은 사용자, 인증된 사용자, 관리자)으로 수행하는 것이 이상적입니다.
#2. 즉시 패치 적용
소프트웨어 제조업체는 제품 중 하나에서 새로운 취약점을 발견하면 이를 해결하기 위한 패치를 개발하여 배포합니다. 패치가 발표되고 배포되면 사이버 범죄자들은 몇 시간 내에 패치를 검색하고 악용하기 시작할 수 있습니다.
조직은 가능한 한 빨리 패치를 적용하도록 계획해야 합니다. 패치 전략의 몇 가지 핵심 요소는 다음과 같습니다:
- 패치 우선순위 지정: 일부 패치는 중요한 취약성을 해결하고 다른 패치는 고가의 IT 자산에 영향을 미칠 수 있습니다. 패치는 조직의 사이버 위험 노출에 대한 잠재적 영향을 극대화하기 위해 우선순위를 정해야 합니다.
- 패치 테스트: 관리자는 패치를 프로덕션 시스템에 배포하기 전에 실제 환경에서 테스트하는 것이 가장 이상적입니다. 이를 통해 패치의 효과를 검증하고 새로운 보안 문제가 발생하지 않도록 할 수 있습니다.
- 자동화된 롤아웃: 조직은 일반적으로 적용해야 할 패치가 많으며 일부는 여러 시스템에 영향을 미칠 수 있습니다. 패치를 대규모로 빠르고 효과적으로 적용하려면 자동화된 패치 워크플로우가 필수적입니다.
- 업데이트 유효성 검사: 업데이트가 적용된 후에는 취약성 스캐너를 사용하여 패치된 시스템을 다시 평가해야 합니다. 이를 통해 패치가 성공적으로 적용되었으며 새로운 보안 위험이 발생하지 않았는지 확인할 수 있습니다.
#3. 위험 우선순위 지정 수행
거의 모든 애플리케이션에는 하나 이상의 취약점이 포함되어 있으며, 이는 일반적으로 조직이 효과적으로 패치할 수 있는 것보다 더 많은 취약한 시스템을 보유하고 있다는 것을 의미합니다. 보안팀은 리소스와 노력을 어디에 투입할지 결정할 때 패치 우선순위를 정해야 합니다.
보안팀이 패치 적용 시기 및 적용 여부를 고려할 때 염두에 두어야 할 몇 가지 사항은 다음과 같습니다:
- 심각도 등급: 많은 취약성에는 문제의 심각도를 설명하는 공통 취약성 점수 시스템(CVSS) 점수가 연관되어 있습니다. 다른 모든 것이 동일하다면, 중요한 취약점은 높음, 중간 또는 낮음 취약점보다 먼저 패치되어야 합니다.
- 시스템 중요도: 패치는 조직에서 중요도가 다른 시스템의 취약성을 해결할 수 있습니다. 예를 들어, 조직의 '핵심' 데이터베이스의 취약점이 덜 중요한 시스템의 취약점보다 더 심각하게 악용될 경우 훨씬 더 큰 영향을 미칠 수 있습니다.
- 영향 범위: 일부 취약성은 단일 시스템에 존재할 수 있지만 다른 취약성은 조직 전체에 영향을 미칠 수 있습니다. 영향을 받는 시스템 수가 많은 취약성은 일부 디바이스에만 영향을 미치는 취약성보다 먼저 패치를 적용해야 할 수 있습니다.
- 리소스 요구 사항: Windows 운영체제 업데이트와 같은 일부 패치는 자동으로 적용되도록 설계된 반면, 다른 패치는 수동 비즈니스 작업이 필요합니다. 패치를 적용하는 데 필요한 노력과 패치의 영향도 비교 검토해야 합니다.
결국, 조직은 모든 취약점을 패치할 수 없으며, 패치할 때마다 다른 곳에서 더 수익성 있게 사용할 수 있는 리소스를 소모하기 때문에 패치할 필요도 없습니다. 패치 대상과 시기는 위협에 따라 결정해야 합니다:
#4. 시스템 구성 관리
일부 취약성은 애플리케이션 코드의 오류로 인해 발생합니다. 예를 들어 SQL 인젝션 및 버퍼 오버플로 취약성은 보안 코딩 모범 사례를 따르지 않아서 발생합니다. 그러나 애플리케이션을 배포하고 구성할 때 다른 취약성이 도입됩니다.
새로운 보안 취약성이 발생할 수 있습니다:
조직은 모든 기업 애플리케이션과 시스템에 대해 보안 기준 구성을 정의하고 적용하여 이를 관리할 수 있습니다. 이 기준의 사용은 정기적인 감사 및 구성 관리 시스템을 통해 시행되어야 합니다.
#5. 위협 인텔리전스 활용
위협 인텔리전스는 조직이 직면할 가능성이 가장 높은 위협과 사이버 공격 캠페인에 대한 인사이트를 제공합니다. 같은 업계, 관할권 또는 규모의 다른 조직이 특정 위협의 표적이 되고 있다면 귀하의 비즈니스도 표적이 될 가능성이 높습니다.
위협 인텔리전스는 취약성 개선 및 완화 노력의 우선순위를 정하는 데 매우 유용할 수 있습니다. 익스플로잇이 진행 중인 취약점은 가능하면 즉시 패치해야 합니다.
패치를 적용할 수 없는 경우, 조직은 악용 위험을 줄이기 위해 모니터링 및 가능한 모든 예방 조치를 시행해야 합니다.
#6. 인시던트 대응과 통합
취약성 관리와 사고 대응은 서로 연관되어 있고 상호 보완적인 노력입니다.
이상적으로 취약성 관리는 보안 위험이 악용되기 전에 제거하여 사고 대응의 필요성을 없애줍니다. 하지만 항상 그런 것은 아닙니다.
조직이 사이버 공격을 받는 경우 취약성 관리 데이터에 액세스하면 사고 대응 프로세스를 신속하게 진행할 수 있습니다. 인시던트 대응팀(IRT) 이 조직의 시스템에 특정 취약성이 존재한다는 사실을 알게 되면 근본 원인 분석 및 수정 작업을 신속하게 진행할 수 있습니다.
다른 한편으로, 인시던트 대응에서 얻은 인텔리전스는 취약성 개선 노력에도 정보를 제공할 수 있습니다.
인시던트 대응자는 알려지지 않은 취약점을 식별하거나 관리되지 않는 취약점이 활발하게 악용되고 있음을 발견할 수 있습니다. 이 데이터는 보안팀이 고위험 취약성을 해결하고 위험 우선순위를 업데이트하여 향후 유사한 사고가 발생하지 않도록 방지하는 데 도움이 될 수 있습니다.
#7. 지속적인 개선 수용
취약성 관리는 대부분의 조직에서 지속적인 프로세스입니다. 매일 새로운 취약성이 발견되고 공개되기 때문에 대부분의 보안팀은 평가해야 할 취약성과 적용해야 할 패치가 계속 쌓여 있습니다.
취약성을 완전히 제거하는 것은 불가능하므로 보안팀은 시간이 지남에 따라 취약성 관리 프로그램을 개선하는 데 집중해야 합니다.
고려해야 할 몇 가지 메트릭은 다음과 같습니다:
- 프로덕션 시스템에 도달한 취약성 수입니다.
- 새로운 취약점을 식별하는 데 걸리는 평균 시간.
- 취약성 패치에 걸리는 평균 시간
- 중요하거나 심각도가 높은 취약성을 패치하는 데 걸리는 평균 시간입니다.
- 프로덕션 시스템의 총 취약성 수입니다.
#8. 규정 준수 요구 사항 고려
기업은 보안 및 취약성 관리 프로그램을 개발할 때 다양한 규정과 표준을 고려해야 합니다. 악용된 취약성은 민감한 데이터가 침해되는 일반적인 방법이며, 기업은 이러한 위험을 관리해야 합니다.
패치 관리 계획 및 프로세스를 정의할 때 보안팀은 다양한 시스템에서 처리하는 데이터의 유형과 해당 데이터의 규제 영향을 고려해야 합니다.
예를 들어 일부 시스템은 컴플라이언스 요건으로 인해 패치 프로세스에서 우선순위를 정해야 할 수도 있습니다.
피드백