Security Watch방금 보안 공지를 보았는데 이제 무엇을 해야 할까요?

Christopher Budd

2003년 10월, 고객의 요청에 따라 Microsoft의 월간 보안 공지 릴리스 프로세스가 정례화되었습니다. 고객의 주요 요청 사항 중 하나는 보안 공지 릴리스 일정을 미리 알 수 있게 해 달라는 것이었습니다. Microsoft는 이에 부응하여 정기적이고 예측 가능한 방식으로 릴리스 프로세스를 정비하고 개선하기 위해 노력해 왔습니다.

Microsoft 보안 공지 사이트에서는 그림 1에 나타난 것처럼 최근 보안 공지와 이전 보안 공지를 검색할 수 있습니다. 2006년 8월에 해당하는 보안 공지의 예를 그림 2에서 볼 수 있습니다.

그림 1** Microsoft 보안 공지 사이트 **(더 크게 보려면 이미지를 클릭하십시오.)

Microsoft의 월간 보안 공지는 많은 고객들이 Microsoft 보안 업데이트 배포 프로세스를 개선하는 데 도움이 되었습니다. 예상 날짜에 보안 공지가 릴리스되기 때문에 고객들은 이 날짜에 맞춰 보안 업데이트를 처리하는 정기적인 자체 프로세스를 구축할 수 있습니다. 이러한 고객들은 Microsoft 월간 보안 공지가 릴리스될 예정 시기에 맞춰 자체 보안 업데이트 평가 및 배포 프로세스의 일정과 단계를 작성한 뒤 이 프로세스를 사용하여 체계적인 방식으로 업데이트를 분석, 테스트 및 배포함으로써 전반적인 보안 환경을 개선하고 작업 중단과 가동 중지 시간을 줄일 수 있습니다.

그림 2** 2006년 8월 보안 공지 **(더 크게 보려면 이미지를 클릭하십시오.)

그러나 보안 업데이트 평가와 배포를 정해진 절차 없이 수행하는 고객도 있습니다. 이처럼 비체계적인 방식으로 업데이트를 배포해도 문제가 발생하지 않을 수는 있지만, 기본적으로 이러한 방식은 보안 업데이트 관리를 위한 최선의 방법에 위배됩니다.

Microsoft에서는 보안 공지가 릴리스되는 방법과 시기에 대해서는 유용한 정보를 제공해 왔지만, 보안 공지와 관련하여 고객이 무엇을 해야 하는지 또한 보안 공지를 고객의 자체 프로세스에 어떻게 통합할 것인지에 대해서는 별다른 지침을 제공하지 않았습니다. 따라서 자신에게 유익한 프로세스가 무엇인지 또한 이러한 프로세스를 구축하는 최선의 방법이 무엇인지 모르는 고객이 있을 수 있습니다.

따라서 본 문서에서는 보안 업데이트 평가 및 배포를 위해 권장되는 단계와 프로세스에 대해 설명합니다. 이 단계는 조직의 규모에 상관없이 수행할 수 있습니다. 일부 대규모 조직의 경우 내부 조직 구조에 따라 이 단계를 여러 그룹에 배분하는 것이 좋습니다 소규모 조직일 경우 이 모든 단계를 한 그룹 또는 한 사람이 수행할 수 있습니다. 어떻게 책임을 할당하든 상관없이 이 모든 단계가 평가 및 배포 프로세스에 명시적으로 설명되어야 합니다. 이 프로세스의 개요가 그림 3에 나타나 있습니다.

그림 3** 보안 공지 평가 및 배포 프로세스 **

1. 고급 알림 받기

월간 보안 공지 프로세스의 첫 단계는 예정된 보안 업데이트에 대한 고급 알림을 반드시 받는 것입니다. Microsoft는 영업일 기준으로 표준 월간 릴리스 3일 전(매월 두 번째 화요일)에 태평양 표준시(GST -8)로 대략 오전 10시에 정보를 웹 사이트에 게시하므로 고급 알림 정보는 그전 주 목요일에 게시됩니다.

고급 알림은 실제 릴리스에 앞서 배포 계획에 도움이 될 정보를 제공하기 위한 것으로서, 포함되는 세부 정보의 수준은 공격에 도움이 될 정보는 공개하지 않아 보안 업데이트가 릴리스될 때까지 고객을 보호해야 한다는 요구에 따라 조정됩니다. 고급 알림은 예정된 업데이트에 대한 정보를 특정 버전 정보 없이 제품 이름을 기준으로(예: Microsoft® Windows® 또는 Microsoft Office) 집계합니다 각각의 항목은 해당 제품에 대해 릴리스될 보안 공지 수, 보안 공지 중 가장 높은 최대 심각도, 업데이트가 재시작을 요구하는지 여부 및 보안 공지에 적용될 검색 도구 등에 대해 자세히 설명합니다.

또한 고객이 놀라거나 혼동하지 않도록, 보안 공지와는 관련이 없지만 같은 날에 릴리스될 다른 업데이트에 대한 정보도 고급 알림에 포함됩니다. 특히 보안과는 무관하지만 MU(Microsoft Update)와 WU(Windows Update)를 통해 릴리스될 높은 우선 순위의 업데이트 수 및 Microsoft Windows 악성 소프트웨어 제거 도구의 업데이트에 대한 자세한 정보도 제공합니다.

마지막으로, MS06-019에서 "다른 사람 이름으로 보내기" 권한 변경에 대한 정보를 제공했던 것처럼 배포 지연을 초래할 수 있는 문제에 대한 정보를 제공합니다.

매달 새로운 고급 알림이 게시되는데 이때마다 SNSCE(Security Notification Service Comprehensive Edition)를 통해 알림이 전송됩니다. 사용자는 SNSCE(영문)에 가입할 수 있습니다.

2. 잠재적인 영향 평가

고급 알림을 받으면 먼저 예정된 릴리스가 자신의 환경과 얼마나 관련이 있는지 평가해야 합니다. 비록 영향을 받는 제품에 대해 제한된 정보만이 고급 알림에 포함되어 있을지라도 예정된 보안 공지가 자신의 환경과 관련이 있는지 여부는 충분히 판단할 수 있습니다.

예를 들어 고급 알림에서 최대 심각도 등급이 가장 높은 "긴급"이고 재시작을 필요로 하는 두 개의 Microsoft Exchange 공지에 대해 언급한 경우, 이 프로그램을 사용하지 않는다면 이 공지가 자신의 환경과는 무관하다는 것을 즉시 알 수 있습니다. 반대로 Exchange Server 2003을 사용한다면 재시작이 필요한 긴급 등급의 공지를 최대 두 개까지 화요일에 받게 될 것임을 알 수 있습니다.

고급 알림은 계획을 세울 때 공지 수, 심각도, 배포 시 재시작과 관련된 영향 등의 관점에서 조직에 미치는 최대한의 영향을 파악하기 위한 유용한 도구로 생각할 수 있습니다. 업데이트의 관련성 및 최대한의 영향을 평가한 후에는 다음과 같은 작업 항목이 포함된 일정을 만들 수 있습니다.

• 위험 평가, 테스트 및 배포를 담당할 직원
• 테스트 계획 및 테스트 환경 시간
• 배포 계획 및 예정된 재시작(해당하는 경우)

고급 알림에 포함된 정보는 변경될 수 있으므로 이 시점에서의 모든 일정은 임시 일정이어야 합니다. 또한 고급 알림에 포함된 정보는 제한적이므로 자세한 정보를 모두 확보하고 나면 변경이 발생할 수 있습니다.

끝으로 기능 변경 사항 등의 추가 정보가 있을 경우 고급 알림 후 실제로 보안 공지가 릴리스될 때까지의 시간을 활용하여 문제를 조사하고 환경에 미칠 수 있는 영향을 평가해야 합니다. 조사 결과에 따라 임시 일정을 수정해야 할 수도 있습니다.

3. 새로운 Microsoft 보안 공지 받기

Microsoft는 매월 두 번째 화요일에 보안 공지를 릴리스합니다. 오전 10시(태평양 표준시)에 릴리스하는 것이 목표지만 릴리스는 복잡하게 상호 연결된 큰 프로세스의 일부이므로 여러 가지 이유로 지연될 수 있습니다. 이번 릴리스에서는 보안 공지, 보안 업데이트, MBSA(Microsoft Baseline Security Analyzer) 및 WSUS(Windows Server® Update Service)와 같은 검색 및 배포 도구에 대한 업데이트, 새 버전의 EST(Enterprise Scan Tool)와 같은 새 검색 도구가 모두 Microsoft 웹 사이트에 게시됩니다.

Microsoft 보안 공지 페이지는 RSS 피드를 지원합니다. 보안 공지에 업데이트가 포함될 경우 RSS 피드도 업데이트되어 RSS 집계기와 뷰어를 업데이트합니다. 또한 SNS(Security Notification Service)와 SNSCE를 사용하여 알림이 외부로 전송되는데 전송 수단은 전자 메일과 MSN® 알림입니다.

새로운 보안 공지가 릴리스되었는지 확인하려면 제공되는 모든 알림 메커니즘에 등록해야 합니다. RSS 피드(영문) 및 SNS 및 SNSCE(영문)에 가입할 수 있습니다.

4. 보안 공지의 관련성 평가

새로운 보안 공지 검토 및 현재 환경과의 관련성 평가에 대한 책임은 명확하게 지정할 필요가 있습니다. 이러한 평가 과정의 중간 단계로서 보안 공지에서 구체적인 전체 정보를 가져와서 필요에 따라 임시 일정에 맞게 수정 및 조정할 수 있습니다. 앞에서 든 예의 경우, 제공될 긴급 보안 업데이트에 대해 Exchange 관리 팀에 알렸지만 그 후에 조직의 Exchange Server에는 해당 사항이 없음을 발견하였다면 이러한 리소스의 일정을 조정할 수 있습니다.

조직과 보안 공지의 관련성을 평가한 후에는 자신의 프로세스와 관련된 보안 공지로 넘어갈 수 있습니다.

5. 위험 평가 수행 및 공지 등급 설정

이 단계에서는 관련 공지의 위험 평가를 수행해야 합니다. 책임이 분담되어 있는 조직에서는 대개 보안 그룹에서 이 단계를 수행합니다. 각 Microsoft 보안 공지에는 최대 심각도 등급이 매겨져 있는데 이 등급은 영향을 받는 모든 제품의 모든 취약점 중 가장 높은 심각도를 반영합니다. 조직에 적용되는 Microsoft 심각도 등급은 사용자 환경의 버전에서 발생하는 문제의 심각도에 따라, 공지에 매겨진 최대 심각도 등급과 다를 수 있습니다. 보안 공지의 “요약” 섹션에 나오는 “심각도 및 취약점” 표를 살펴 보고 사용자 버전에 해당하는 특정 취약점 정보를 확인하는 것이 중요합니다.

그런 다음에는 각각의 취약점에 대해 완화 요소 같은 추가 기술 정보 및 자주 제기되는 질문 사항에 수록된 기술 세부 정보를 검토하고 위험 평가 결과를 현재 환경과 정책에 따라 조정해야 합니다. 위협적인 환경 또는 조직에 치명적인 특정 응용 프로그램 등과 같이 기술과는 관련이 없는 환경 요인에 대한 설명이 평가에 포함되어야 한다고 정책에 명시되어 있을 수도 있습니다.

이 프로세스가 끝날 때에는 각 공지의 위험 등급을 파악하고 관련 업데이트를 갖고 있어야 합니다. 앞에서 든 예의 경우 Exchange 관리 그룹은 보안 공지에 기술된 변경 사항에 따라 보안 업데이트를 "보통" 위험 수준으로 평가할 수 있습니다. 사용 중인 정책에 따라 일정을 적절하게 업데이트하고 변경해야 합니다. 예를 들면 보통 위험 수준의 업데이트인 경우 낮은 위험 수준의 업데이트에 비해 테스트 기간이 하루나 이틀 정도 더 필요하다고 정책에 명시되어 있을 수 있습니다.

특정 위험 등급의 공지에 대해서는 해결 방법도 구현할 것을 고려해야 한다고 정책에 명시되어 있는 경우도 있습니다. 예를 들면 긴급으로 평가된 모든 보안 업데이트의 경우 해결 방법을 가능한 빨리 검토해서 배포해야 한다고 정책에 언급되어 있을 수 있습니다. 이 경우 해결 방법에 대해 추가로 위험 평가를 수행하여 구현할 항목과 시기를 결정해야 합니다.

이 프로세스가 끝날 때는 각 업데이트의 관련 위험 등급이 포함된 현재 환경에 배포될 업데이트 목록을 갖고 있어야 합니다. 또한 테스트 및 배포 일정을 업데이트하는 데 사용할 구현될 해결 방법 목록도 갖고 있어야 합니다. 일정 변경 사항에는 정책에 의해 지정된 일정이 반영되어야 합니다. 예를 들면 모든 긴급 보안 업데이트의 경우 해결책이 24시간 내에 배포되고 업데이트는 7일 내에 배포되어야 한다고 정책에 명시되어 있을 수 있습니다.

6. 보안 업데이트 및/또는 해결 방법이 조직에 미치는 영향 파악

평가 프로세스에서는 보안 업데이트나 해결책이 현재 환경에 미치는 영향을 파악하는 것이 중요합니다. 책임이 분담되어 있는 조직에서는 보안 업데이트나 해결책에 의해 직접적인 영향을 받는 시스템의 관리 그룹에서 대개 이 단계를 수행합니다.

어떤 영향을 미칠 수 있는지 파악하면 보안 업데이트나 해결책으로 인해 발생하는 위험을 이해하고 확인하는 데 도움이 됩니다. 관련 정보는 보안 공지의 "이 보안 업데이트와 관련된 자주 제기되는 질문 사항" 섹션에서 찾을 수 있습니다. 보안 업데이트가 취약점을 해결하는 방법은 "취약점 세부 정보"의 취약점에 대한 FAQ에 설명되어 있습니다.

이 단계의 목표는 업데이트와 해결책의 위험 등급을 파악하는 것입니다. 앞의 예에서 Exchange 관리 그룹은 보안 공지에 기술된 변경 사항에 따라 보안 업데이트를 "보통" 위험 수준으로 평가할 수 있습니다. 사용 중인 정책에 따라 적절하게 일정을 수정해야 하는데, 예를 들면 "보통" 위험 수준의 업데이트인 경우 "낮은" 위험 수준의 업데이트에 비해 테스트 기간이 하루나 이틀 정도 더 필요하다고 정책에 명시되어 있을 수 있습니다.

또한 위험 등급이 일정에 미치는 영향에 따라 해결책을 배포할 때쯤 결정을 다시 검토해야 할 수도 있습니다. 예를 들면 테스트 기간을 이틀 정도 연장해야 하는데 이로 인해 정책에서 허용하는 기간보다 오래 시스템이 보호되지 않는 상태로 방치될 수 있는 경우 정책을 준수할 수 있도록 해결책의 배포를 다시 검토해야 합니다.

끝으로 이 단계에서 얻은 정보는 업데이트에 대한 테스트 계획을 세우는 다음 단계에 사용됩니다.

7. 테스트 계획 정의

효율성을 위해 테스트는 체계적이어야 하며 의미 있는 계획에 따라 수행되어야 합니다. 또한 현재 환경에서 문제가 발생할 가능성이 가장 큰 영역을 대상으로 해야 합니다. 환경은 각기 다르므로 효율적인 테스트 계획을 위한 표준 템플릿을 제공할 수는 없습니다.

책임이 분담되어 있는 조직에서는 대개 둘 이상의 그룹에서 테스트 계획을 수립합니다. 보안 업데이트나 해결책에 의해 직접적인 영향을 받는 기술이나 시스템을 관리하는 그룹이 특별한 전문 지식을 제공할 수 있습니다. 테스트 그룹은 테스트 케이스 작성, 테스트 도구 옵션 및 특정 일정과 관련된 전문 지식을 제공할 수 있습니다.

이 단계에서는 테스트 계획이 어떻게 보안 업데이트나 해결책의 위험 등급에 영향을 미치는지 확인하고 그에 따라 테스트 및 배포 일정을 변경해야 합니다. 예를 들어 업데이트를 완벽하게 테스트하는 테스트 계획을 세울 수 없다고 판단되는 경우 위험 등급을 올리고 배포를 잠시 미룬 다음 그 사이에 해결책을 구현할 수 있습니다.

8. 배포 계획 수립

배포란 보안 업데이트나 해결책이 제공하는 보호를 실제로 구현하는 프로세스입니다. 실제로 이 프로세스의 궁극적인 목표는 배포이므로 사용 가능한 배포 방법을 이해하고 이를 평가 요인에 포함시키는 것은 보안 위험을 평가하는 것만큼이나 중요합니다. 책임이 분담되어 있는 조직에서는 SMS(Systems Management Server)를 유지 관리하는 그룹과 같이 소프트웨어 업데이트 인프라 관리를 담당하는 그룹에서 주로 보안 업데이트의 가능한 배포 방법을 결정합니다. Active Directory와 같은 구성 관리 기술을 감독하는 그룹은 해결책의 가능한 배포 방법을 결정하는 데 관여할 수 있습니다.

이 단계의 목표는 가능한 배포 방법을 파악하고 이를 통해 보안 업데이트나 해결책을 배포하는 데 필요한 계획을 수립하는 것입니다. 이 단계에서는 가능한 배포 방법이 어떻게 일정에 영향을 미치고 필요한 변경을 수행하는지 파악해야 합니다. 예를 들어 WSUS에서 보안 업데이트를 지원하지 않는데 WSUS가 기본 배포 방법인 경우 원래 계획보다 업데이트 배포에 이틀을 더 할당해야 함을 판단할 수 있습니다. 그런 다음 이 배포 기간 동안 필요한 보호를 제공하기 위해 해결책을 구현하도록 결정할 수 있습니다.

배포 방법과 관련된 정보는 보안 공지의 "이 보안 업데이트와 관련된 자주 제기되는 질문 사항" 섹션에 포함되어 있습니다. 각 해결책과 함께 해결책을 구현하는 방법이 나열되는데 개별 해결책은 각각의 취약점과 연관되어 있습니다.

이 단계가 마지막 계획 단계입니다. 이 단계에서는 보안 위험과 관련된 평가 및 계획, 보안 업데이트와 해결책의 위험 등급, 테스트 및 배포와 같은 모든 요소를 반영하는 일정이 세워져 있어야 합니다. 지금까지 살펴본 것처럼 이러한 단계는 복잡하게 서로 관련되어 있지만 반드시 선형적인 관계는 아닙니다. 조직에 따라 이러한 단계가 동시에 수행될 수도 있고 순차적으로 수행될 수도 있습니다. 따라서 조직의 정책, 요구 사항 및 리소스를 토대로 이러한 단계의 구현에 대한 결정을 내려야 합니다. 이러한 단계에서 가장 중요한 사항은 특정 구조나 순서가 아니라, 각 단계가 다른 단계와 정보를 주고 받고 서로 응답하는 것입니다. 즉, 모든 구현에 있어 핵심은 융통성과 조정 가능성입니다.

9. 업데이트 및 해결책 테스트

테스트 단계에서는 앞에서 정의한 테스트 계획에 따라 테스트 환경에 보안 업데이트와 해결책을 배치합니다. 테스트 환경의 목적은 프로덕션 환경의 위험 요소를 복제하는 것입니다. 보안 업데이트나 해결책을 테스트함으로써 프로덕션 환경에 배포하기 전에 발생 가능한 문제를 찾을 수 있습니다.

테스트를 통해 문제가 확인되면 문제의 심각도와 문제 해결에 필요한 단계를 결정해야 합니다. 허용되는 정도의 영향만을 미치는 위험하지 않은 문제가 발견될 수도 있지만 그보다 심각한 문제일 경우에는 업데이트 배포 전에 해결해야 합니다. 문제를 용인하기로 결정한 경우에는 지원 담당자에게 문제를 보고하십시오.

문제를 해결하려는 경우에는 보안 업데이트 관련 문제에 대해 무료로 지원을 제공하는 Microsoft PSS(기술 지원 서비스)에 사례를 접수할 수 있습니다. PSS에 연락하는 방법은 support.microsoft.com/security에서 찾을 수 있습니다. 문제를 해결하려면 테스트 시간이 늘어나서 배포가 지연되므로 문제를 해결하기로 선택한 경우 일정에 미칠 수 있는 영향을 고려해야 합니다.

문제를 해결하거나 보고하여 테스트가 완료되면 보안 업데이트나 해결책을 프로덕션 환경에 배포할 수 있다고 인증할 수 있습니다.

10. 업데이트 및 해결책 배포

테스트를 통해 보안 업데이트나 해결책이 인증되면 배포 프로세스로 진행할 수 있습니다. 배포 시에는 보안 업데이트나 구성 변경 사항을 시스템에 실제로 적용하는 과정을 안내해 주는 계획에 따르십시오. 일반적으로 계획 수립에 관여했던 그룹이 실제 배포를 담당합니다.

업데이트 관리 인프라를 통해 보안 업데이트가 제대로 설치되지 않은 경우처럼 배포에서 문제가 발생한 경우 문제를 신중하게 조사해야 합니다. 문제로 인해 지연될 경우 시스템을 보호하기 위해 옵션을 다시 확인하고 해결책을 고려할 수도 있습니다.

프로덕션 환경에서 발생할 수 있는 모든 문제는 배포 이전에 테스트 프로세스에서 확인하는 것이 이상적입니다. 하지만 프로덕션 환경에 배포한 후 실제로 문제가 발생한다면 테스트 시 문제가 발생했을 때 수행했던 것과 동일한 단계를 수행해야 합니다. 문제를 평가한 다음 문제를 용인할지 아니면 해결하지 결정하십시오.

보안 업데이트가 성공적으로 적용되면 적절한 보호가 이루어지므로 이 프로세스의 궁극적인 목표가 달성된 것입니다. 그러나 보안 업데이트가 성공적으로 적용되지 않는다면 시스템이 공격받을 소지가 여전히 남아 있습니다.

업데이트가 성공적으로 이루어지지 않은 시스템이 있을 수 있기 때문에 배포 프로세스의 마지막 단계에서는 배포가 성공적인지 확인하기 위해 시스템을 감사하는데, 이는 매우 중요한 단계입니다. 일부 조직에서는 별도의 감사 그룹이 보안 팀과 연계하여 감사를 수행합니다. WSUS, MBSA, SMS 등의 Microsoft 도구를 사용하여 보안 업데이트가 성공적으로 적용되었는지 감사할 수 있습니다. 또한 보안 공지의 보안 업데이트 정보 섹션에도 보안 업데이트가 성공적으로 적용되었는지 확인하는 방법이 나와 있습니다.

결론

Microsoft의 월간 보안 공지 릴리스 덕분에 고객들은 보안 업데이트 관리에 있어 보다 정기적인 계획과 프로세스를 구현할 수 있게 되었습니다. 정기적인 절차와 프로세스를 만들면 시스템을 더 잘 보호할 수 있을 뿐 아니라 작업 중단과 가동 중지 시간을 최소화할 수 있습니다.

보안 업데이트 관리를 위한 프로세스는 조직별로 고유해야 하지만 각 프로세스에는 이 칼럼에서 권장하는 단계가 포함되어 있어야 합니다. 보안 및 업데이트 팀이 별도로 있어야 하는 것은 아니지만 반드시 보안 위험 평가를 수행하고 배포 계획을 수립해야 합니다.

여기서 핵심적인 개념은 계획의 중요성입니다. 훌륭한 계획을 세운다면 테스트나 배포 단계 등 실제 작업과 관련된 단계가 보다 원활하게 수행될 것이므로 결과적으로 성공적인 보안 업데이트 프로세스를 구축할 수 있습니다.

Christopher Budd는 MSRC(Microsoft Security Response Center)의 보안 프로그램 관리자로서, IT/보안 전문가 및 기타 소프트웨어 사용자와의 기술적인 커뮤니케이션을 담당하는 전문가입니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..