다음을 통해 공유

보안 모니터링 및 공격 탐지

게시 날짜: 2006년 8월 29일

이 페이지에서

소개
정의
중소 기업의 당면 과제
솔루션
요약
부록 A: 불필요한 이벤트 제외
부록 B: 그룹 정책 설정 구현

소개

이 문서에서는 중소 기업을 위한 보안 지침을 다룹니다. 다음 정보는 보다 안전하고 생산적인 컴퓨팅 환경을 구축할 수 있도록 도움을 줍니다.

요약 내용

최근 몇 년 동안 언론 매체를 통해 여러 심각한 악성 소프트웨어 위협 및 사고가 크게 보고되면서 보안 문제에 대한 인식이 증가했으며, 이로 인해 대부분의 기업에서는 이처럼 만연한 보안 문제를 방지하는 데 많은 시간과 리소스를 투입하게 되었습니다. 하지만 비즈니스 인프라에 대한 가장 큰 위협은 바이러스와 같은 외부 공격 형태보다는 내부 네트워크 자체에 더 많이 내재되어 있을 수 있습니다.

비즈니스 네트워크 내부에서 시작되는 공격은 손상 가능성이 매우 높으며, 그러한 공격이 신뢰할 수 있는 위치에 있고 회사 내 모든 네트워크 리소스에 액세스할 수 있는 직원에 의해 발생한 경우에는 손상 규모가 더욱 심각해질 수 있습니다. 현재 많은 회사들이 외부 및 내부 위협으로부터 제기되는 위험을 심각하게 검토한 후 발생할 수 있는 모든 공격을 탐지하고 네트워크를 모니터링할 수 있는 시스템을 구축하기로 결정하고 있습니다.

규정 제한을 준수해야 하는 회사의 경우에는 보안 모니터링 관행이 고려 사항이 아닌 필수적인 요구 사항입니다. 이와 동일한 규정이 보안 모니터링 레코드를 유지 및 보관해야 하는 방식과 기간까지도 규제할 수 있습니다. 네트워크 보호, 리소스 액세스 인력의 신원 추적 및 개인 정보 보호와 관련하여 규제 대상 회사에 부과되는 요구가 지속적으로 증가하고 규정 환경이 끊임없이 변화함에 따라 오늘날 전 세계 기업에서는 효과적인 보안 모니터링 솔루션을 구축해야 할 필요성이 절실하게 요구되고 있습니다.

규정 요구 사항을 준수할 필요가 없는 중소 기업에 보안 모니터링 및 공격 탐지가 중요한 문제로 대두되는 데는 몇 가지 이유가 있습니다. 이러한 이유에는 해당 업체의 인프라에 대한 공격이 성공했을 경우 회사가 직면하게 될 결과를 고려할 수 있습니다. 이러한 상황이 발생하면 비즈니스 운영이 중단될 뿐만 아니라 생산성 및 비용이 손실되는 결과를 낳게 됩니다. 또한 기업의 명성에 큰 타격을 입을 수 있는데, 이는 대체로 공격으로 인한 어떤 다른 손실보다도 회복하는 데 오랜 시간이 소요됩니다.

보안 모니터링 솔루션의 시작 지점으로 Microsoft® Windows®에 제공되는 보안 로그 기능을 사용할 수 있습니다. 하지만 보안 로그만으로는 사고 대처 방안을 계획하는 데 충분한 정보를 제공하지 못합니다. 해당 정보를 수집 및 쿼리하는 다른 기술과 함께 이러한 보안 로그를 사용하면 포괄적인 보안 모니터링 및 공격 탐지 솔루션의 핵심 구성 요소를 만들 수 있습니다.

보안 모니터링 및 공격 탐지 시스템의 주된 목표는 네트워크에서 악의적인 활동이나 절차상의 오류를 나타낼 수 있는 의심스러운 이벤트를 보다 쉽게 식별할 수 있도록 하는 것입니다. 이 문서에서는 Windows 기반 네트워크에 포함된 시스템의 요구를 해결하는 데 도움이 되는 계획을 구상하는 방법에 대해 설명합니다. 또한 이와 같은 시스템을 구현, 관리 및 확인하는 방법에 대한 지침도 제공합니다.

개요

이 문서는 효과적인 보안 모니터링 및 공격 탐지 솔루션을 디자인하고 구현하는 데 필요한 주요 개념과 문제를 중점적으로 다루는 네 개의 주요 섹션으로 구성되어 있습니다. 첫 번째 섹션은 현재 읽고 계신 "소개" 부분이며 나머지 섹션은 다음과 같습니다.

정의

이 섹션에서는 이 문서에 소개된 솔루션을 만들고 적용하는 부분과 관련된 프로세스를 이해하는 데 도움이 되는 정보를 제공합니다.

중소 기업의 당면 과제

이 섹션에서는 보안 모니터링 및 공격 탐지 시스템과 관련하여 중소 기업에서 직면하고 있는 일반적인 여러 과제에 대해 설명합니다.

솔루션

이 섹션에서는 이 문서에 소개된 솔루션을 개발, 구현, 관리 및 확인하는 방법에 대해 자세히 설명하며 두 가지 하위 섹션으로 나뉘어 있습니다. "솔루션 개발"에서는 사전 활동에 대해 설명하고 계획 단계를 구상합니다. "솔루션 배포 및 관리"에서는 보안 모니터링 및 공격 탐지 시스템을 배포, 관리 및 확인하는 데 도움이 되는 정보를 제공합니다.

이 내용을 읽어야 할 사람

이 문서에서는 특히 규정 제한으로 인해 데이터 액세스를 제어하고 ID를 보호해야 하는 중소 기업의 개인 정보 보호 및 보안 문제를 다룹니다. 따라서 이 문서의 대상은 기술 관리자 및 의사 결정권자부터 계획, 배포, 운영은 물론 회사 네트워크 보안을 담당하는 기술 구현자와 IT 전문가에 이르기까지 다양합니다.

이 문서의 일부 내용은 대부분의 기술 관련 의사 결정권자에게 유용하겠지만, 문서에 제공되는 모든 내용을 실제로 적용하려면 문서를 읽는 대상이 회사 네트워크 환경의 보안 및 위험 문제에 대해 잘 알고 Windows 이벤트 로깅 서비스를 충분히 이해하고 있어야 합니다.

페이지 위쪽

정의

이 문서에서는 MOF(Microsoft Operations Framework) 프로세스 모델과 MOF 보안 관리 및 사건 관리 SMF(서비스 관리 기능)를 사용합니다.

특히 이 문서에 소개된 솔루션에서는 보안 모니터링 및 공격 탐지와 관련하여 선형 배포 접근 방식보다는 연속 프로세스 접근 방식을 사용하도록 권장합니다. 뿐만 아니라 이 솔루션을 구축하려면 다음 그림에 나와 있는 단계를 수행해야 합니다.

그림 1. MOF 적용

보안 모니터링 솔루션은 보안 모니터링이라는 기본적인 특성 때문에 사실상 계획, 구현, 관리 및 테스트가 잇따라 진행되는 프로세스입니다. 비즈니스 네트워크에 대한 위협이 항상 변화하고 있으므로 비즈니스 네트워크에서 보안을 모니터링하는 시스템 역시 그에 따라 변화해야 합니다.

이 프로세스를 보안 모니터링에 적용하는 일은 다음과 같은 목표를 달성하려는 보안 관리 SMF에 적합합니다.

  • 기업 노출 진단 및 보호할 자산 확인

  • 위험을 허용 가능한 수준으로 낮추는 방법 확인

  • 보안 위험 완화 계획 수립

  • 보안 메커니즘의 효율성 모니터링

  • 효율성 및 보안 요구 사항을 정기적으로 재평가

MOF에 대한 자세한 내용은 MOF(Microsoft Operations Framework) 웹 사이트(https://www.microsoft.com/korea/technet/itsolutions/cits/mo/mof/default.mspx) 를 참조하십시오. 보안 관리 SMF 에 대한 자세한 내용은 www.microsoft.com/technet/itsolutions/cits/mo/smf/mofsmsmf.mspx를 참조하십시오.

위험 관리란 기업 내에서 허용 가능한 위험 수준을 결정하고, 현재의 위험을 평가하고, 허용 가능한 위험 수준에 도달하기 위한 방법을 찾고, 위험을 관리하는 프로세스를 말합니다. 이 문서에서도 일부 위험 개념과 위험 관리를 지원하는 단계에 대해 설명하기는 있지만, 위험 관리는 별도로 심층적인 연구가 필요한 주제입니다. 위험 분석 및 평가에 대한 자세한 내용은 보안 위험 관리 가이드 (https://www.microsoft.com/korea/technet/security/guidance/secrisk/srsgch01.asp) 를 참조하십시오.

페이지 위쪽

중소 기업의 당면 과제

중소 기업은 현재 효과적인 보안 모니터링 시스템을 구성하고 이러한 노력을 지원하는 정책을 수립하는 데 있어 많은 과제에 직면해 있습니다. 해결해야 할 과제는 다음과 같습니다.

  • 내부 및 외부 위협으로부터 전체 네트워크 환경을 보호해야 할 필요성과 이를 통해 얻게 되는 이점에 대한 이해

  • 설정된 정책을 회피하려 하는 시도를 방지 및 탐지하는 방법을 포함하는 효과적인 보안 모니터링 및 공격 탐지 시스템 디자인

  • 공격을 탐지하는 것은 물론 개선하기 위해 환경의 보안 수준에 대한 전체적인 상황을 제공하는 포괄적이고 효과적인 모니터링 정책 구현

  • 의심스러운 활동을 감지하는 관리 작업을 보다 쉽게 수행할 수 있도록 설정된 보안 정책과 보안 보고서를 서로 효율적으로 연결하는 정책 및 프로세스 관리

  • 비즈니스 요구 균형을 조정하면서 보안 모니터링 노력을 지원하는 효율적인 비즈니스 방법 및 정책의 구현과 적용

  • 유용성과 위험 완화의 균형을 유지할 수 있는 허용 가능한 위험 임계값 결정

페이지 위쪽

솔루션

앞에서 설명했듯이 포괄적인 보안 모니터링 프로세스는 수행해야 할 정밀 분석을 지원할 뿐만 아니라 공격 이전, 도중 및 이후에 정보를 제공할 수 있는 사전 예방적인 보안 수단이기도 합니다. 중앙 집중화된 보안 보고서 리포지토리를 제공하면 공격 발생 시 검사 단계에서 공격을 탐지하거나 공격 발생 직후 공격에 대해 효과적으로 대처하는 데 필요한 정보를 제공함으로써 침입 시도에 대한 영향을 줄일 수 있습니다.

디자인 및 정책을 최대로 활용하려면 개발의 개념화 단계에서 보안 모니터링을 구현하여 얻을 수 있는 이점을 반드시 이해해야 합니다. 보안 모니터링을 통해 얻게 되는 주요 이점은 다음과 같습니다.

  • 중소 기업의 취약점 규모를 줄이기 위해 보안 또는 업데이트 정책을 준수하지 않는 시스템을 확인하고 개선합니다.

  • 비정상적인 활동을 식별하여 실제 공격이 발생하기 전에 직원에게 침입 시도를 경고할 수 있는 정보를 생성합니다.

  • 보안 감사 정보를 생성하고 보호하여 정밀 분석 결과를 개선합니다. 이를 통해 규정 요구 사항을 충족시키고 발생할 수 있는 공격의 영향을 줄일 수 있습니다.

  • 전반적인 보안 향상을 위해 보안 수준의 분석을 지원합니다.

  • 고의적이든 우발적이든 관계없이 확립된 비즈니스 프로세스 외부에서 발생하는 활동을 감지합니다.

  • 네트워크에 있는 관리되지 않는 시스템의 식별 또는 취약한 장치의 개선을 지원합니다.

솔루션 개발

보안은 대부분의 기업에서 중요한 문제입니다. 대부분의 회사가 일반적인 잠금 장치부터 카드 기반 액세스 제어와 같은 정교한 보안 기술 등 다양한 방법을 사용하여 상당한 양의 리소스를 물리적 보안에 할당하지만, 여전히 많은 회사에서는 갈수록 의존도가 늘어나고 있는 데이터의 보안을 해결할 만한 역량을 갖추지 못하고 있습니다.

데이터 보안 및 모니터링 문제를 중요하게 생각하는 회사들은 일반적으로 방화벽을 사용한 경계에서의 데이터 보안에 중점을 둡니다. 하지만 이 방법은 다양한 공격 소스에 대한 취약점이 높은 편입니다. United States Secret Service 및 CERT Coordination Center에서 발표한 2004 E-Crime Watch Survey (영문) www.cert.org/archive/pdf/2004eCrimeWatchSummary.pdf)에 따르면, 사실상 확인된 공격자의 29%는 현재 근무 중인 직원, 계약 업체 및 퇴사한 직원 등 내부 소스에 속하는 것으로 나타났습니다. 이러한 정보를 고려할 때 외부에서 발생하는 위협 외에도 내부 위협으로부터 보호하기 위한 다층 보안 방법이 마련되어야 한다는 사실을 분명하게 알 수 있습니다.

사후 보안 차원에서 내부 및 외부 위협을 모두 해결하기 위해 사용되는 한 가지 방법은 보안 감사 로깅 프로세스를 구현하는 것입니다. Microsoft Windows NT® 3.1부터 현재 버전에 이르기까지 모든 Microsoft Windows 버전에서는 기본 제공 보안 이벤트 로그 파일을 사용하여 보안 이벤트를 기록합니다. 그러나 이 기본 제공 기능은 이미 발생한 침입에 대한 정밀 조사를 수행할 때는 유용할 수 있지만, 이 기능만을 사전 보호 방법으로 사용하여 예비 공격 활동을 식별하거나 침입이 발생하는 동안 그러한 시도를 해당 직원에게 경고하기는 어려울 것입니다.

앞에서도 언급했듯이, 보안 로그는 흔히 보안 사고가 발생한 후 사고를 정밀하게 분석할 때 사후 수단으로 사용됩니다. 하지만 US Secret Service 및 CERT에서 발표한 2005 Insider Threat Study (영문) (www.cert.org/archive/pdf/insidercross051105.pdf)의 주요 결과 분석에 따르면, 보안 로깅 및 모니터링은 사후 정밀 조사에 단독으로 사용하기보다 사전 탐지 수단으로 사용할 수 있다고 합니다. 또한 내부 및 외부에 있는 대부분 공격자는 로그를 변경하여 추적을 회피하려 하므로 시스템 로그를 보호하기 위한 조치가 필요합니다. 따라서 공격을 모니터링 및 탐지하는 데 사용할 수 있는 보안 로그를 비롯한 기타 방법은 올바르게 사용되고 보호될 경우 네트워크 보안 환경에서 중요한 도구가 될 수 있습니다.

이 문서에서는 시스템 보안 로그에 중점을 두고 있지만, 시스템 로그 자체는 보안 모니터링 및 공격 탐지 방법의 핵심일 뿐이며, 이 밖에도 설정된 보안 정책을 준수하지 않거나 현재 권장 취약점 패치를 구현하지 않은 시스템을 식별하고 개선하는 방법 등을 고려해야 합니다. 관리되지 않는 시스템이 네트워크에 액세스하지 못하도록 하기 위한 스위치 포트 보안 보고 및 무단 연결이나 패킷 검색을 방지하기 위한 무선 보안 모니터링을 비롯하여 내부 네트워크 인프라도 모니터링해야 합니다. 이러한 모니터링 주제의 대부분은 이 문서에서는 다루지 않지만, 각 주제 모두 포괄적인 보안 모니터링 솔루션에서 중요하게 다룰 만한 주제입니다.

보안 모니터링 구현

다음 하위 섹션에서는 보안 모니터링 시스템과 관련된 다양한 구현 고려 사항에 대해 설명합니다.

Windows 보안 이벤트 로깅

Microsoft Windows NT® 3.1부터 현재 버전에 이르기까지 모든 Microsoft Windows 버전에서는 기본 제공 보안 이벤트 로그 파일을 사용하여 보안 이벤트를 기록합니다. Microsoft Windows 기반 환경에서는 이 기능이 보안 모니터링을 위한 기초를 제공합니다. 하지만 이러한 정보를 서로 연결할 추가 유틸리티 또는 도구 없이 보안 이벤트 로그 기능만을 사용할 경우 정보가 분산되기 때문에 사전 보호 방법으로 사용하기가 어려워집니다.

그림 2. 이벤트 뷰어 보안 로그

위의 그림에 표시된 보안 이벤트 로그에서는 사용자 지정 파일 형식을 사용하여 보안 모니터링 데이터를 기록합니다. 텍스트 편집기를 사용하여 이러한 레코드를 읽을 수도 있지만, 이러한 로그에 기록된 모든 정보를 보려면 이벤트 뷰어 같은 관련 프로그램이 필요합니다. 보안 이벤트 로그 파일(SecEvent.evt)은 %systemroot%\System32\config 디렉터리에 있습니다. 이벤트 로그 액세스는 항상 이벤트 로그 서비스를 통해 제어되며 이벤트 로그 서비스는 각 로그에 액세스 제어를 적용합니다. 보안 로그에 대한 기본 권한은 시스템의 다른 로그에 비해 매우 엄격한 편이며, 기본적으로 관리자만이 보안 로그에 액세스할 수 있습니다.

보안 이벤트 로그에 기록되는 이벤트에는 성공 감사와 실패 감사의 두 가지 유형이 있습니다. 성공 감사 이벤트는 사용자, 서비스 또는 프로그램이 수행한 작업이 성공적으로 완료되었음을 나타냅니다. 실패 감사 이벤트는 성공적으로 완료되지 못한 작업에 대한 세부 정보를 제공합니다. 예를 들어, 사용자 로그온 실패는 실패 감사 이벤트의 예로서 로그온 감사를 사용하는 경우 보안 이벤트 로그에 기록됩니다.

컴퓨터 구성\Windows 설정\로컬 정책에 있는 감사 정책 그룹 정책 설정은 보안 로그에 기록되는 이벤트를 제어합니다. 감사 정책 설정은 Active Directory와 그룹 정책을 통해 사이트, 도메인 또는 조직 구성 단위(OU) 수준이나 로컬 보안 설정 콘솔에서 구성할 수 있습니다.

감사 이벤트 해석

감사 이벤트는 이 문서 전체에서 자세하게 다루는 부분이므로 감사 이벤트와 이벤트에 포함된 정보를 기본적으로 이해하고 있어야 합니다.

그림 3. 이벤트 속성 창

이벤트는 크게 이벤트 헤더, 이벤트 설명 및 이진 데이터의 세 부분으로 나뉘어 있으며,

이중 이벤트 헤더는 다음 필드로 구성됩니다.

표 1. 이벤트 헤더

필드 정의
날짜 이벤트가 발생한 날짜
시간 이벤트가 발생한 로컬 시간
유형 이벤트 위험 등급 또는 유형 분류. 보안 감사 이벤트의 경우에는 성공 감사 또는 실패 감사 유형을 말합니다.
소스 이벤트를 기록한 응용 프로그램. SQL Server와 같은 실제 프로그램, 드라이버 이름 또는 시스템 구성 요소(예: 보안)일 수 있습니다.
범주 이벤트 소스의 이벤트 분류. 그룹 정책 내에 구성될 수 있는 이벤트 유형에 해당하는 보안 감사 로그의 항목입니다.
이벤트 ID 이 코드는 특정 이벤트 유형을 식별합니다. 위의 그림에서 이벤트 ID는 680이며, 이 이벤트 ID는 자격 증명이 로컬 프로세스, 원격 프로세스 또는 사용자를 통해 인증 시스템으로 전달되었음을 나타냅니다.
사용자 이벤트를 발생시킨 사용자의 사용자 이름. 이 이름은 프로세스에 의해 발생된 경우 클라이언트 ID이며, 위장이 발생하지 않는 경우에는 기본 ID입니다. 보안 이벤트에서는 가능한 한 기본 및 위장 정보를 모두 표시합니다.
컴퓨터 이벤트가 발생한 컴퓨터의 이름.
이벤트 설명 필드는 사실상 이벤트마다 다를 수 있는 다양한 정보를 포함합니다. 예를 들어, 위의 그림에 표시된 이벤트 680에서는 **오류 코드:** 필드에 **0xC000006A** 가 지정되어 있는데, 이는 잘못된 암호를 입력했음을 의미합니다. 각 이벤트 유형은 이 필드에 이벤트 관련 정보를 표시합니다. Windows 보안 이벤트 로그의 이벤트에서는 이벤트 레코드의 이진 데이터 부분을 사용하지 않습니다. ###### 기술 문제 Windows 보안 이벤트 로깅을 기반으로 한 보안 모니터링 및 공격 탐지 시스템을 구현하려면 다음 문제를 해결해야 합니다. - **많은 양의 보안 이벤트 관리.** 생성될 많은 양의 보안 이벤트를 잘 처리하려면 각별히 주의하여 특정 보안 감사 이벤트를 추적해야 합니다. 이러한 고려 사항은 많은 양의 데이터를 생성할 수 있는 파일 및 개체 액세스 감사를 처리할 때 특히 중요합니다. - **중앙 리포지토리에서 이벤트 정보 저장 및 관리** . 이벤트 정보를 저장하는 과정에 모니터링 시스템 구성에 따라 테라바이트 수준의 데이터가 포함될 수도 있습니다. 이 고려 사항은 정밀 분석 요구를 고려할 때 가장 중요한 사항으로 해당 섹션에서 자세히 설명되어 있습니다. - **공격 패턴 식별 및 대응** . 공격을 나타낼 수 있는 활동 패턴을 식별하려면 검토자가 직접 또는 구성된 쿼리를 통해 제공된 정보 안에 숨어 있는 해당 활동과 관련된 이벤트를 찾아낼 수 있어야 합니다. 의심스러운 활동을 식별하고 나면 적시에 적절하게 대응하는 메커니즘이 있어야 합니다. - **직원의 보안 감사 제어 우회 제한.** 보안 전문가만이 감사 시스템을 관리하도록 네트워크에서 상위 권한을 가진 직원, 특히 관리자를 구분하여 감사 정보에 대한 액세스를 제한합니다. ###### 솔루션 계획 다음 활동은 보안 모니터링 및 공격 탐지 시스템을 구현하기 전에 수행해야 합니다. - 현재 보안 및 감사 설정 검토 - 관리자 역할 및 일반 사용자 작업 평가 - 비즈니스 정책 및 절차 검토 - 취약한 시스템 식별 - 고부가가치 자산 나열 - 중요하거나 의심스러운 계정 식별 - 권한이 있는 프로그램 나열 저장소 요구 사항에 대한 자세한 내용은 이 문서 뒷부분에 나오는 "정밀 분석 구현" 섹션을 참조하십시오. ###### 현재 보안 및 감사 설정 검토 기업에서는 현재 보안 감사와 보안 로그 파일 설정을 검토하여 이 문서에서 권장하는 변화에 대한 기준선을 제공해야 합니다. 이와 같은 검토는 솔루션을 구현한 후 정기적으로 수행해야 하며 이를 위해 다음 정보를 알고 있어야 합니다. - 현재의 효과적인 보안 감사 설정 - 이러한 설정을 적용할 수준(로컬 컴퓨터, 사이트, 도메인 또는 OU) - 현재 로그 파일 설정(최대 크기에 도달했을 때의 동작 및 크기 제한) - 적용할 수 있는 추가 보안 감사 설정(예: 백업 및 복원 권한 사용 감사) 이 문서 끝 부분에 나오는 "부록 B: 그룹 정책 설정 구현”의 내용을 참조하면 기록할 설정을 쉽게 식별할 수 있습니다. 보안 감사 설정에 대한 자세한 내용은 [Windows Server 2003 보안 소개](https://www.microsoft.com/korea/technet/security/guidance/secmod117.asp) (https://www.microsoft.com/korea/technet/security/guidance/secmod117.asp) 를 참조하십시오. ###### 관리자 역할 및 일반 사용자 작업 평가 효과적인 보안 모니터링 솔루션의 한 가지 핵심 요소는 관리자가 계정 소유자를 알고 이들의 역할 및 책임을 파악하도록 하는 것입니다. 예를 들어, 대부분의 회사에서는 도메인에 새 사용자 계정을 만들 수 있도록 도메인 관리 그룹에 관리자를 포함합니다. 하지만 비즈니스 정책에는 설치된 구축 시스템을 통해서만 새 계정을 만들 수 있도록 지정해야 합니다. 이러한 상황에서는 관리자 계정에서 계정 만들기 이벤트가 발생할 경우 즉각적인 조사가 이루어집니다. 일반적으로 사용자 계정은 관리자 계정에 비해 네트워크 리소스에 대한 액세스가 상당히 적은 편이므로 사용자 계정 작업을 평가하는 일은 대체로 매우 간단합니다. 예를 들어, 일반 사용자는 네트워크 경계에 있는 컴퓨터의 파일 시스템에 액세스할 필요가 없으므로 그러한 서버에서 일반 사용자의 활동을 거의 모니터링할 필요가 없습니다. ###### 비즈니스 정책 및 절차 검토 비즈니스 프로세스 및 절차의 검토는 관리자 역할 및 책임 평가에 가깝지만 이 평가로만 국한되지는 않습니다. 이와 같은 검토 절차의 중요한 구성 요소에는 사용자 만들기 프로세스 및 변경 제어 프로세스를 검사하는 작업이 있습니다. 승인 프로세스를 제공하는 메커니즘에 대한 검사와 네트워크에서 발생하는 모든 이벤트에 대한 감사 추적은 권한이 있는 감사 이벤트와 침입 시도 간의 상관 관계를 밝히는 데 매우 중요한 역할을 합니다. ###### 취약한 시스템 식별 취약한 시스템은 외부 공격자가 다른 접근 방식을 시도하기에 앞서 액세스 시도를 시험하거나 시작할 가능성이 높은 네트워크의 컴퓨터와 장치를 말합니다. 일반적으로 이러한 컴퓨터는 네트워크 경계에 있지만 내부 장치도 공격에 취약할 수 있으므로 완전히 무시해서는 안 됩니다. 따라서 취약한 시스템을 종합적으로 검토하면서 다음 요건을 갖추어야 합니다. - 모든 관련 업데이트 및 서비스 팩이 적용되었습니다. - 불필요한 서비스 및 사용자 계정이 사용되지 않습니다. - 가능한 경우 서비스가 로컬 서비스나 네트워크 서비스 계정에서 실행되도록 구성했습니다. - 사용자 계정 자격 증명이 필요한 서비스를 살펴보고 해당 액세스 수준이 필요한지(특히 이러한 계정에 관리자 권한이 있는 경우) 여부를 확인했습니다. - 보안 수준이 높은 정책 템플릿을 적용했습니다. **참고** 이 검토 프로세스는 경계에 있는 취약한 컴퓨터는 물론 다른 위치에 있는 컴퓨터에 대해서도 수행해야 합니다. 올바른 보안 관행에서는 이러한 검사 절차를 네트워크의 모든 컴퓨터에 적용합니다. 서비스가 안전하게 실행되도록 구성하는 방법에 대한 자세한 내용은 [서비스 및 서비스 계정 보안 계획 가이드](https://www.microsoft.com/korea/technet/security/topics/serversecurity/serviceaccount/default.mspx) (https://www.microsoft.com/korea/technet/security/topics/serversecurity/serviceaccount/default.mspx) 를 참조하십시오. ###### 고부가가치 자산 나열 대부분의 회사에서는 네트워크에 있는 고부가가치 자산을 이미 식별해 놓고 있겠지만, 각 자산에 대한 보호 수준을 적절하게 문서화하고 세부적으로 계획하여 이 정보를 조직 정책의 일부로 공식화하지는 않았을 수 있습니다. 예를 들어, 회사에서는 ACL(액세스 제어 목록)과 암호를 사용하여 NTFS 파일 시스템 파티션에 중요한 재정 레코드를 안전하게 저장할 수 있습니다. 하지만 조직 정책에서는 권한이 없는 사용자와 관리자가 액세스를 시도하지 못하도록 그러한 레코드를 보호된 파일로 식별하여 관리자와 사용자가 이 제한을 인식하도록 해야 합니다. 또한 이러한 파일을 보호하는 데 사용되는 ACL에 대한 변경 사항을 조사해야 합니다. 특히 소유권 변경 이벤트는 적절한 권한이 없는 파일에 대한 부정 액세스 시도를 나타낼 수 있으므로 소유권 변경과 관련된 경우에는 더욱 철저하게 조사해야 합니다. 소유권이 변경되는 경우는 매우 드물기 때문에 고부가가치 자산을 식별하고 문서화한 이후에는 소유권 변경 이벤트를 쉽게 찾아낼 수 있습니다. ###### 중요하거나 의심스러운 계정 식별 모든 중요 계정을 검토하여 감사 수준을 높여야 하는 계정을 식별해야 합니다. 이러한 계정에는 기본 관리자 계정, 엔터프라이즈, 스키마 또는 도메인 관리 그룹의 구성원, 그리고 서비스에서 사용되는 모든 계정이 포함됩니다. 중요 계정을 식별하는 일 외에도, 위험하다고 판단된 개인이나 의심스러운 활동에 참여했을 가능성이 있는 개인이 소유한 계정에 대한 보안 감사 수준을 조정해야 합니다. 개인 사용자 계정에 대한 감사 수준을 조정하는 방법에 대한 자세한 내용은 이 문서 뒷부분에 나오는 "정책 위반 및 임계값" 섹션을 참조하십시오. ###### 권한이 있는 프로그램 나열 공격자가 네트워크에 대한 정보를 찾으려면 해당 네트워크 안에 있는 시스템에서 프로그램을 실행해야 합니다. 기업에서 네트워크에서 실행하도록 허용된 프로그램을 제한하면 외부 공격의 위협을 크게 줄일 수 있습니다. 권한이 있는 프로그램 목록을 설정하려면 현재 권한이 부여되었거나 네트워크에서 필요한 프로그램으로 식별된 모든 프로그램에 대해 감사를 수행해야 합니다. 이와 같은 감사를 수행하는 과정에 알 수 없는 프로그램은 모두 의심스러운 프로그램으로 간주하여 즉시 조사해야 합니다. Microsoft Systems Management Server 2003은 소프트웨어 감사를 지원하지만 필수 요소는 아닙니다. **참고** 개발 중인 실행 프로그램이 승인된 프로그램 목록에 없을 수 있는 개발자 워크스테이션 같은 특정 컴퓨터에는 몇 가지 예외가 요구될 수도 있습니다. 하지만 보다 안전한 접근 방식에서는 개발 및 테스트를 가상 컴퓨터 환경이나 격리된 개발 네트워크 도메인에서만 수행해야 합니다. ##### 정책 위반 및 임계값 감지 기업에서 계획해야 하는 보안 문제 중 가장 큰 범주는 정책 위반입니다. 이러한 유형의 사고는 다음과 같습니다. - 설정된 프로세스 외부에서 사용자 계정 만들기 - 관리자 권한의 잘못된 사용 또는 무단 사용 - 대화형 로그온에 서비스 계정 사용 - 권한이 없는 사용자 계정에 의한 파일 액세스 시도 - 사용자 계정에 액세스 권한이 있는 파일 삭제 - 승인되지 않은 소프트웨어의 설치 및 실행 가장 일반적인 정책 위반 유형은 제한된 디렉터리 검색 등 우발적인 사용자 액세스 시도이지만, 이 문제는 액세스 제한 및 적절한 권한 정책을 통해 해결될 수 있으므로 이러한 위반은 그다지 중요하지 않습니다. 관리자 권한의 특성으로 인해 고의적이든 우발적이든 가장 많이 발생하는 이벤트 유형은 관리 정책 위반입니다. 관리자 계정 권한은 해당 업무를 수행하는 데 특정 유형의 권한이 필요한 개인에게 높은 수준의 시스템 액세스 권한을 부여합니다. 하지만 이러한 권한 부여를 통해 권한이 있는 범위 또는 프로세스를 벗어난 시스템 권한까지도 사용할 수 있도록 승인되는 것은 아닙니다. 관리자 계정을 통해 사용자 계정을 만들고 수정하며, 제한된 데이터를 보고, 데이터 액세스 권한을 수정하려면 이처럼 강력한 기능과 관련된 위험을 완화하기 위한 방법을 신중하게 고려해야 합니다. ###### 위협 모델링 아시다시피 일부 위협은 감사를 통해 줄일 수 있지만, 감사만으로는 감소되지 않고 많은 비용을 들여야만 낮출 수 있는 위협도 있습니다. 여기서 주목할 만한 부분은 모든 취약점이 네트워크에 위협적인 존재는 아니라는 점입니다. 줄일 수 있거나 줄여야 하는 취약점을 판단하려면 위협 모델링 원리를 적용하는 것이 효과적일 수 있습니다. 위협 모델링은 특정 환경의 컨텍스트에서 대응책을 보다 효율적으로 만들기 위해 위협 및 취약점을 보다 정확히 식별하는 데 사용할 수 있는 엔지니어링 기술입니다. 이 프로세스는 보통 세 가지 기본 단계로 구성됩니다. - 공격자 관점 이해 - 시스템 보안 프로파일 식별 - 관련 위협 확인 및 등급 지정 또 한 가지 특별한 점은 공격자 관점에서 네트워크 환경을 조사할 때 네트워크 액세스 권한 획득을 시도하도록 개인 사용자를 가장 크게 유혹하는 대상과 그러한 대상에 대한 공격이 성공하기 위한 조건을 확인해야 한다는 부분입니다. 취약한 대상을 식별한 후에는 환경을 확인하여 기존 보호 방법이 공격 조건에 어떤 영향을 미치는지를 파악할 수 있습니다. 이 프로세스를 통해 위험 수준에 따라 등급을 매길 수 있는 관련 위협, 해당 위협에 대해 가장 유용한 솔루션을 제공할 수 있는 개선 활동, 그리고 위협 감소가 해당 개선 가치에 영향을 줄 수 있는 다른 영역에도 유익하거나 유해한 방식으로 적용될 수 있는지 여부를 알 수 있습니다. 따라서 이러한 요구 사항에 기반을 둔 성공적인 네트워크 위협 모델링 프로세스에는 몇 가지 특별한 단계가 있습니다. 1. **중요 자산 식별.** 보안 리소스의 가장 적절한 소비 위치를 판단하는 과정에 업무 운영에 핵심적인 자산을 나열해야 합니다. 비즈니스 프로세스 소유자와 기술 소유자는 손상될 경우 회사에 손실을 끼칠 수 있는 자산을 세부적으로 인식하고 있으므로 이 프로세스에 이들을 포함해야 합니다. 2. **예상 공격 지점 식별** . 이 식별 단계에는 두 가지 서로 다른 관점도 포함됩니다. 첫 번째, 네트워크의 데이터가 있을 수 있는 경계 유형을 분류해야 합니다. 이러한 경계는 해당 데이터가 공개된 경우 발생할 수 있는 손상을 기반으로 한 중요 영역 및 공용 영역 내에 있습니다. 두 번째, 기술 관점에서는 중요 자산을 노출시킬 수 있는 예상 취약 지점과 경로를 통해 공격 지점을 검사합니다. 이러한 두 정보를 함께 활용하면 보안 노력의 중점을 중요한 정보를 평가할 수 있는 지점의 취약점으로 손쉽게 좁힐 수 있습니다. 3. **실제 자산 식별** . 중요 자산과 예상 액세스 지점이 밝혀지면 손상을 초래하기 위해 공격자가 수행할 수 있는 작업의 목록을 만들 수 있습니다. 그런 다음 이 목록을 사용하여 실제 특정 위협을 집중적으로 살펴볼 수 있습니다. 실제 위협을 식별하는 과정에는 다양한 방법을 사용할 수 있습니다. STRIDE는 사용할 수 있는 공격 유형(스푸핑, 조작, 거부, 정보 공개, 서비스 거부(DoS) 및 권한 상승)에 따라 위협을 검사하는 한 가지 방법입니다. 네트워크, 호스트 및 응용 프로그램 같은 논리적 계층별로 위협을 세분화하는 다른 반복적인 방법도 있습니다. 이 접근 방식은 조직이 해당 환경을 얼마나 잘 파악하고 있는가에 달려 있습니다. 4. **위협 분류 및 등급 지정** . 이 단계에서는 일반적인 위험 평가 및 관리 원칙을 이용하여 이러한 위협이 회사에 미칠 수 있는 잠재적인 영향과 악용 가능성에 따라 위협에 등급을 지정합니다. 사용되는 표준 공식은 다음과 같습니다. 위험 = 악용 가능성 x 잠재적인 비즈니스 영향 이러한 프로세스에서는 이 문서에서 다루지 않는 위험 평가에 도움이 될 만한 많은 방법과 도구가 사용됩니다. 위험 관리 및 이러한 방법에 대한 자세한 내용은 [보안 위험 관리 가이드](https://www.microsoft.com/korea/technet/security/guidance/secrisk/srsgch01.asp) (https://www.microsoft.com/korea/technet/security/guidance/secrisk/srsgch01.asp) 를 참조하십시오. 5. **개선 및 재평가.** 앞의 단계들을 수행하고 나면 회사에 영향을 줄 수 있는 실제 위협 목록이 작성됩니다. 각 위협은 해당 회사에 제시되는 위험의 순서대로 등급이 매겨집니다. 이 목록을 사용하면 나타난 비용 대비 이점의 비율을 평가하는 개선 노력에 중점을 둘 수 있습니다. 결국 특정 위험을 줄이기 위해 몇 가지 서로 다른 방법을 사용할 수 있으며 그 중 어떤 방법은 다른 취약점을 해결하여 보안 노력의 효율을 높일 수 있습니다. 개선 계획이 집행된 후라도 위협 모델링 방법은 가능한 한 효과적이고 포괄적인 보안 노력으로 자리잡을 수 있도록 하기 위해 끊임없이 재평가하며 정기적으로 수행해야 하는 반복적인 프로세스입니다. ###### 배경 조사 및 검토 대부분의 회사에서는 고용 조건으로서 고용 전에 예비 직원에 대한 배경 조사를 실시하지만 고용된 이후에는 조사하지 않습니다. 회사에서는 직원이 고용된 상태라 하더라도 배경 조사를 정기적으로 수행해야 합니다. 특히 제한된 정보에 액세스하는 요직을 맡고 있는 직원의 경우에는 더욱 필요합니다. ###### 컴퓨터 사용 정책 계약 컴퓨터 또는 네트워크 사용 계약에서는 직원에게 회사의 자산을 어떻게 사용할 수 있는지에 대한 정보를 알려 줄 뿐 아니라 네트워크 활동 및 컴퓨터 사용을 모니터링하는 정책과 이러한 정책의 위반을 초래할 수 있는 행위에 대해서도 알려 준다는 점에서 중요한 역할을 합니다. 사용 정책 설명은 이러한 문제를 명시적으로 정의할 때 법적 문서로도 사용되며 계약의 표시로 직원의 서명이 필요합니다. 직원이 내부 보안 모니터링 정책과 회사 자산의 적절한 사용에 대한 기대를 잘 알고 있다는 증거가 없으면 잘못된 행동을 했을 경우 악용자를 기소하기가 더욱 어려워집니다. 또한 회사 네트워크의 모든 액세스 지점에서 액세스를 시도하는 모든 사람에게 해당 네트워크가 사설 네트워크이고 무단 액세스가 금지되어 있으며 이와 같은 행위가 적발될 경우 형사 처벌될 것임을 알려 주는 액세스 및 무단 사용 경고를 표시해야 합니다. 예를 들어, Windows 운영 체제에는 사용자에게 보호된 회사 리소스에 대한 액세스를 시도하려고 하며 무단 액세스가 금지되어 있다는 정보를 알려 주는 데 사용할 수 있는 로그온 시도 이벤트 도중 경고문을 표시할 수 있는 기능이 있습니다. 이와 같은 문서의 정확한 표현 및 사용과 관련된 법적 문제에 대한 논의는 이 문서의 범위를 벗어나지만, 이러한 문서와 정책은 반드시 필요합니다. 사용 및 액세스 경고문의 예는 인터넷에서 많이 볼 수 있지만, 각별히 고려해야 하는 고유의 논리적이고 국제적인 법률 문제가 많으므로 이러한 정보는 반드시 적절한 자격을 갖춘 법률 고문과 상의하고 이들의 도움을 받아 작성해야 합니다. ###### 임무 구분 시스템의 다양한 기능이 보안, 성능 및 가용성 목적으로 네트워크에 분할되어 있는 것과 마찬가지로, IT 보안 부서의 채용 요구 사항을 개발할 때도 임무의 중복 및 구분을 고려해야 합니다. 중요한 데이터 및 시스템에 액세스하거나 제어하는 핵심적인 역할은 직원 구성원을 잃게 될 경우 발생할 정보 손실과 관련된 문제를 방지하고 내부 파괴 행위 시 보안 기능을 제공하기 위해 가능한 한 중복되어야 합니다. 예를 들어, 관리자 암호를 알고 있는 직원 구성원이 한 명뿐인 상황에서 이 직원이 관리자 암호를 알려 주지 않고 퇴사했다면 문제 발생 시 복구하기가 어렵습니다. 역할 중복 외에도, 중요한 역할을 구분해야 합니다. 특히 보안 모니터링의 경우 역할 구분은 매우 중요합니다. 네트워크를 관리하는 인력에게 보안 감사 정보를 관리할 책임을 부여해서는 안 되며, 보안 직원에게 관리자와 동일한 관리자 권한을 부여해서도 안 됩니다. 경우에 따라 관리 직원이 부서 정보를 보지 못하도록 보호하여 임무 구분을 보다 세부적으로 적용해야 할 수도 있습니다. 예를 들어, 어떤 회사에는 재정 또는 인적 자원과 같은 중요한 정보를 보호하기 위한 고유의 시스템이나 관리자 계정을 가진 조직 구성 단위가 있습니다. **참고** 관리자 계정 소유자가 그러한 임무 구분에 대한 대안을 찾는 것까지 막을 수는 없지만, 최소한 임무 구분 원칙을 사용하는 관리 기관의 인증된 사용에 대해서는 지침을 설정해야 합니다. ###### 보안 모니터링 확인 기능 보안 모니터링 솔루션을 구현하기 전에 정기적인 보안 모니터링 솔루션 테스트를 신중하게 계획해야 합니다. 보안 모니터링 솔루션을 확인하는 과정에는 초기 테스트도 중요하지만, 보안 환경이 끊임없이 변화함에 따라 정기적으로 실시할 테스트 일정도 반드시 편성해 두어야 합니다. 테스트에는 침입 시도와 관리자 권한 악용 사례 발생 시 솔루션이 적절히 작동하는지 여부를 판단하기 위해 이러한 활동에 대한 테스트가 포함됩니다. 하지만 보안 기법 및 공격 프로파일의 최신 변경 사항을 조사하여 변경이 필요한지 여부를 판단하는 일도 중요합니다. 공격자가 보안 구현 사항에 맞춰 공격을 바꿔 나감에 따라 비즈니스 네트워크의 위협은 계속 변화하고 있습니다. 또한 그에 따라 방어 및 모니터링 기술도 계속 발전해야만 효과를 발휘하게 될 것입니다. ###### 프로세스 구축 권한이 있는 이벤트를 권한이 없는 보안 이벤트와 구분하려면 설정된 필수 변경 제어 및 문제 관리 프로세스에 대한 계획을 세워야 합니다. 이러한 계획에서는 보안 로그 정보와 서로 연결할 수 있는 세부 문서 기록을 제공할 수 있습니다. 문제 추적은 대부분의 회사에서 지원 센터 티켓이나 다른 문제 추적 프로세스를 통해 보편화되었지만, 변경 제어는 대체로 무시되고 있습니다. 변경 제어는 필수 메커니즘이며, 문제가 되는 시스템이나 응용 프로그램을 찾아내기 위해 추세를 추적하는 데 사용하는 것은 물론, 필수 보안 메커니즘으로도 활용할 수 있습니다. 변경 제어 프로세스는 사전 예방 절차로 수행해야 하며, 사후 변경은 문제 관리 프로세스를 사용하는 부분으로 제한해야 합니다. 변경 제어 프로세스에서는 변경 전에 제출 및 승인이 이루어져야 하며 다음과 같은 세부 정보를 포함해야 합니다. - 승인자 이름 - 구현자 이름 - 변경 기간 - 변경 사유 - 변경 사항 - 변경이 적용되는 시스템 - 비즈니스 영향 - 변경의 실제 결과 설정해야 할 또 다른 프로세스는 감사 추적을 작성하여 무단 계정 변경으로부터 보호하는 사용자 추가/변경/삭제 절차를 통한 사용자 구축 프로세스입니다. 이러한 프로세스를 구축하기 전에 현재 사용자 계정에 대한 보안 감사를 수행하여 계정의 유효성을 확인하고 변경될 때마다 해당 목록을 정기적으로 확인해야 합니다. MIIS(Microsoft Identity Integration Server) 2003과 같은 자동 사용자 구축 및 ID 관리 솔루션을 사용하면 이와 같은 활동 이면에서 계정 변경 및 프로세스를 자동화하므로 많은 도움을 얻을 수 있습니다. 이러한 솔루션을 사용하더라도 관리자 계정은 여전히 새 계정을 만들 수 있지만 설정된 프로세스를 통해서도 계정이 만들어지므로 계정 생성 작업을 수행할 필요가 없습니다. 따라서 이벤트 624 같은 계정 생성과 관련된 이벤트는 자동 구축에 사용되는 설정된 다른 서비스 계정이나 MIIS 20003에만 연결되어야 합니다. 오늘날 언론을 통해 비즈니스 네트워크에 대한 외부 위협이 끊임없이 발표되고 있지만, 경험에 따르면 네트워크 및 회사 데이터는 잘못된 구성이나 절차상의 오류로 인한 손실 또는 손상에 훨씬 더 취약합니다. 외부 및 내부의 모든 위협으로부터 보호하는 일은 매우 중요합니다. 외부 위협으로부터 회사를 보호할 수 있도록 지원하는 많은 공급업체가 있지만 현재까지 네트워크 및 보안 담당 인력의 실수를 방지할 패키지를 판매하는 업체는 없는 상황입니다. 그러한 위험을 줄이는 최선의 방법은 네트워크에서 수행하는 변경 작업에 대한 안전한 프로세스 및 절차를 구현하고 적용하는 것입니다. ###### 보안 대응책 정의 보안 위반으로 인한 손상을 제한하려면 적절히 정의된 대응 계획을 개발하고 사고에 대처하기 위한 프로세스를 구축해야 합니다. 사고 보고서, 신속 대응 팀 구성 및 비상 시 대응 절차는 이에 대한 좋은 예입니다. 사고 대응 속도 및 효율성이 뛰어나면 조직의 보안 프로파일을 향상시키고 침입 시도로 야기될 수 있는 실제 손상과 인지되는 손상을 제한하게 됩니다. 설정된 보안 대응 프로세스를 구성하면 실제 사고로 인해 발생할 수 있는 손상을 제한하는 데 도움이 될 뿐 아니라, 사고 발생 시 모든 보안 위반 사항에 대해 통합된 즉각적인 대응을 하게 된다는 사실을 직원 및 다른 개인 사용자에게 알림으로써 일종의 억제 수단을 얻을 수도 있습니다. ###### 인적 자원 CERT 및 U.S. Secret Service에서 실시한 연구에 따르면, 회사에서 직원의 행동 변화나 위협을 인지하고 그에 대한 조치를 수행할 경우 내부 소스로부터 발생하는 공격을 상당 부분 방지할 수 있다고 합니다. 직원들은 불만을 가진 다른 직원을 알고 있거나 방문자가 의심스럽게 행동하는 경우 해당 인원에게 경고할 수 있으므로 회사에서 가장 소중한 보안 리소스는 직원일 것입니다. 실제로 외부 보안 감사 그룹에서 수행하는 첫 번째 조치 중 하나는 종이에 적힌 암호 정보를 찾거나 안전하지 않은 장치를 확인하거나 내부 네트워크에 직접 연결하여 침입을 시도하는 행위를 "신중히 검토"하는 것 등입니다. 회사 직원은 내부 및 외부 위협으로부터의 중요한 보호 계층 역할을 수행할 수 있습니다. 개방 정책을 통해 동료 및 교육 지원 인력이 의심스러운 직원의 비정상적인 컴퓨터 활동을 보고하는 행동에 대해 적극적으로 논의하도록 하면 침입 시도나 맬웨어 사고를 줄일 수 있습니다. 내부 교육은 직원에게 보고해야 할 컴퓨터 동작의 유형을 찾아내는 방법을 교육하는 수단으로도 유용하게 활용할 수 있습니다. 또한 교육은 사회 공학 공격을 방지하기 위한 예방책으로도 사용됩니다. ##### 보안 정책 위반과 감사 이벤트의 연결 보안 이벤트 정보를 서로 연결하려면 여러 시스템에서 보안 이벤트를 수집하고 이 데이터를 안전한 중앙 위치에 보관해야 합니다. 보안 정보를 서로 연결했으면 해당 직원이 이 중앙 리포지토리를 분석하여 위반이나 외부 공격을 식별할 수 있습니다. 이 리포지토리는 정밀 분석용으로는 물론, 공격을 탐지하고 취약점을 해결하기 위한 도구로도 중요한 역할을 합니다. 이 목적으로 사용되는 몇 가지 타사 솔루션도 있기는 하지만, 다음 Microsoft 제품 및 도구를 사용하면 보안 이벤트 로그와 다른 보안 모니터링 정보를 중앙 리포지토리에 서로 연결함으로써 이러한 솔루션 없이도 공격을 탐지하고 취약점을 해결할 수 있습니다. ###### EventCombMT EventCombMT(다중 스레드)는 [Windows Server 2003 보안 소개](https://www.microsoft.com/korea/technet/security/guidance/secmod117.asp) (https://www.microsoft.com/korea/technet/security/guidance/secmod117.asp)의 구성 요소이며, 이 도구는 여러 컴퓨터의 이벤트 로그에서 이벤트를 수집하고 구문을 분석할 수 있습니다. 이 도구는 다음과 같은 이벤트 로그를 검사할 때 사용자가 개수에 관계없이 매개 변수를 지정할 수 있도록 하는 다중 스레드 응용 프로그램으로 실행됩니다. - 이벤트 ID(단일 또는 여러 개) - 이벤트 ID 범위 - 이벤트 소스 - 특정 이벤트 텍스트 - 이벤트 기간(분, 시간 또는 일) [![](images/Cc875806.SMAAD4(ko-kr,TechNet.10).gif)](https://technet.microsoft.com/ko-kr/cc875806.smaad4_big(ko-kr,technet.10).gif) **그림 4. EventCombMT** 위의 그림에 표시된 계정 잠금과 같은 특정 검색 범주가 EventCombMT에 기본 제공됩니다. EventCombMT는 다음 이벤트에 대한 검색 기능을 갖추고 있습니다. - **529** . 로그온 실패(잘못된 사용자 이름 또는 암호) - **644** . 사용자 계정이 자동으로 잠김 - **675** . 도메인 컨트롤러에서 사전 인증 실패(잘못된 암호) - **676** . 인증 티켓 요청 실패 - **681** . 로그온 실패 보안 로그 파일에 없는 또 하나의 보안 관련 이벤트는 시스템 로그 파일에 기록되는 이벤트 12294입니다. 이 이벤트는 잠금 임계값이 없어 예비 공격자를 유혹하는 취약한 대상이 되는 관리자 계정으로부터의 공격 시도를 감지하는 데 사용할 수 있으므로 모든 검색에 이 이벤트를 추가해야 합니다. **참고** 이벤트 12294는 보안 로그가 아니라 시스템 로그에 SAM(보안 계정 관리자) 이벤트로 표시됩니다. EventCombMT는 Microsoft SQL Server™ 데이터베이스 테이블에 이벤트를 저장할 수 있어 장기적인 저장 및 분석 작업에 도움이 됩니다. 이벤트 로그의 정보가 SQL Server 데이터베이스에 저장되고 나면 SQL Query Analyzer, Microsoft Visual Studio® .NET 또는 타사 유틸리티 등 다양한 프로그램을 통해 액세스할 수 있습니다. ###### Log Parser 2.2 Log Parser는 Microsoft에서 개발한 도구로 로그의 데이터를 검색하고 로그를 SQL 데이터베이스 또는 CSV 파일로 업로드하여 이벤트 로그, CSV 파일 또는 기타 로그 형식(처음 고려한 용도의 IIS 로그 포함)으로 보고서를 생성하는 데 사용할 수 있습니다. 이 명령줄 스크립팅 도구를 리소스로 사용하여 이벤트 로그 정보를 중앙 위치에 상호 연결하고 해당 이벤트의 구문을 분석한 후 보고서를 생성할 수 있습니다. 스크립팅 및 명령줄 인터페이스는 좀 더 자세히 살펴볼 필요가 있지만 이 문서에서는 다루지 않겠습니다. Log Parser, Log Parser의 용도 및 스크립트 리소스에 대한 자세한 내용은 [Log Parser 2.2 (영문)](https://www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx) 페이지(www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx)와 " [How Log Parser 2.2 Works (영문)](https://www.microsoft.com/technet/community/columns/profwin/pw0505.mspx) " 기사(www.microsoft.com/technet/community/columns/profwin/pw0505.mspx) 를 참조하십시오. ###### EventQuery.vbs EventQuery.vbs는 Windows XP와 함께 제공되는 도구입니다. 이 도구를 사용하면 하나 이상의 이벤트 로그에서 이벤트 및 이벤트 속성을 나열할 수 있습니다. 이 스크립트를 사용하려면 명령 기반 스크립트 호스트(CScript.exe)가 실행 중이어야 합니다. 기본 Windows Script Host가 CScript로 설정되지 않은 경우 다음 명령을 실행하여 이 작업을 수행할 수 있습니다. ``` Cscript //h:cscript //s //nologo ``` 이 명령줄 유틸리티는 유연성이 매우 뛰어나며 다양한 매개 변수를 사용하여 출력에 적용되는 필터링 및 형식을 조정할 수 있습니다. 이 도구의 용도와 사용 가능한 매개 변수에 대한 자세한 내용은 Windows XP Professional 제품 설명서에서 [Managing event logs from the Command Line (영문)](https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/event_commandline.mspx?mfr=true) 항목(www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/event\_commandline.mspx?mfr=true) 을 참조하십시오. ###### 인터넷 정보 서비스 로깅 IIS(인터넷 정보 서비스)에서 사용할 수 있는 추가 로깅 기능에서는 사이트 방문자의 ID, 방문자가 액세스한 항목 및 방문자가 액세스한 시점에 대한 보고 기능을 제공합니다. IIS 로그는 사이트, 가상 폴더 및 파일에 대한 성공 또는 실패 액세스 시도를 기록하므로, 저장소 요구 사항을 최소화하고 불필요한 정보 기록을 제한하기 위해 해당 정보를 선택적으로 감사하도록 구성할 수 있습니다. 이러한 로그는 원시 파일 형식으로 저장한 후 앞에서 설명한 구문 분석 및 검사 도구 중 하나를 사용하여 필터링하거나, 정보를 SQL 데이터베이스 또는 다른 ODBC 호환 데이터베이스에 저장할 때 사용할 수 있는 ODBC 데이터베이스 로깅을 통해 중앙 집중화된 위치로 직접 필터링할 수 있습니다. 다음을 비롯하여 특정 이벤트 활동 및 순서를 자세히 모니터링해야 합니다. - 실행 파일 또는 스크립트를 실행하려 했지만 실패한 여러 명령 - 단일 IP 주소 또는 주소 범위로부터의 과도한 로그온 실패 시도. 이 시도는 DoS 시도 또는 권한 상승 시도를 나타낼 수 있습니다. - .bat 또는 .cmd 파일에 대한 액세스 또는 수정 실패 시도 - 실행 파일을 포함하는 폴더에 대한 파일 무단 업로드 시도 Windows Server 2003부터는 새로운 감사 기능이 IIS에 기본적으로 제공되어 IIS의 새로운 로깅 기능과 함께 사용하거나, 이벤트 로그에 직접 통합하거나, 사용자 지정 솔루션의 ASP 페이지를 통해 액세스할 수 있습니다. 이러한 기능과 각 기능의 구현 방법에 대한 자세한 내용은 IIS 설명서를 참조하십시오. ###### Microsoft Internet Security and Acceleration Server Microsoft ISA(Internet Security and Acceleration) Server는 VPN 및 프록시 캐싱 기능 등 추가 기능을 제공하는 고급 상태 저장 패킷 및 응용 프로그램 계층 방화벽입니다. ISA Server에서는 활성 방어 유틸리티 외에도, 네트워크 경계를 통해 전달되는 모든 활동을 모니터링하는 중앙 집중화된 로깅 도구로 작동할 수 있는 기능을 사용하여 보안 모니터링 기능을 수행할 수도 있습니다. ISA Server의 로깅 기능에는 방화벽 트래픽, 웹 프록시 활동 및 SMTP 메시지 차단 로그를 캡처할 수 있는 기능이 포함됩니다. 이러한 로그는 다음 스크린 샷에 표시된 기본 제공 실시간 로그 뷰어나 모니터링 대시보드를 사용하여 실시간으로 필터링, 쿼리 또는 모니터링할 수 있습니다. [![](images/Cc875806.SMAAD5(ko-kr,TechNet.10).gif)](https://technet.microsoft.com/ko-kr/cc875806.smaad5_big(ko-kr,technet.10).gif) **그림 5. Microsoft ISA Server 2004 실시간 로그 뷰어** ISA Server에는 기본 제공 기능 외에도 전자 메일 및 이벤트 로그 항목을 통해 경고를 표시하거나 서비스를 시작 또는 중지할 수 있는 경고 기능이 있습니다. 이벤트 로그에 의심스러운 활동을 기록하는 기능은 이 문서 전체 내용에서 특히 유용합니다. 이 기능을 사용하면 예상 공격 정보를 다른 감사 이벤트 로그 데이터와 함께 중앙 위치에 기록 및 저장할 수 있습니다. SA Server에서는 이러한 로깅 및 경고 기능 외에도 기본 제공 침입 탐지 도구를 사용할 수 있습니다. 이러한 기본적인 IDS(침입 탐지 서비스)는 인터넷 보안 시스템을 통해 사용권을 허가 받으며 여러 ID 패킷 필터, DNS 응용 프로그램 필터 및 POP 응용 프로그램 필터가 포함됩니다. 이러한 서비스는 일반적인 다양한 악용 사례를 감지할 수 있습니다. ISA Server의 침입 탐지 기능은 잠재적인 공격이 탐지될 때 이벤트를 기록하고 경고를 생성할 수 있습니다. 또한 서비스나 의심스러운 연결을 종료할 수도 있습니다. 탐지할 수 있는 주요 공격 프로파일은 다음과 같습니다. - WinNuke(Windows Out-of-Band 공격) - Land Attack - IP Half Scan 공격 - UDP Bomb - 포트 검사 - DNS 호스트 이름 길이 오버플로 공격 - 권한이 있거나 높은 TCP/IP 포트로 DNS 영역 이동 ISA Server를 사용하든 다른 방화벽 및 IDS 솔루션을 사용하든 관계없이 보안 모니터링 및 공격 탐지 시스템을 디자인할 때는 경계 네트워크(DMZ 및 차단된 서브넷)를 고려해야 합니다 ###### Microsoft Operations Manager 2005 MOM(Microsoft Operations Manager)은 엔터프라이즈 환경에 있는 여러 서버를 중앙에서 모니터링합니다. MOM 에이전트는 이벤트 로그에서 이벤트를 수집한 후 수집한 이벤트를 MOM 관리 서버로 전달합니다. 그러면 이벤트가 MOM 데이터베이스에 저장됩니다. MOM 2005 이상 버전은 MOM 에이전트를 실행하지 않는 컴퓨터에서 이벤트를 수집할 수 있습니다. MOM에서는 관리 팩 규칙을 사용하여 서버의 운영 효율성에 영향을 미치는 문제점을 식별합니다. 특정 이벤트를 모니터링하고 이러한 이벤트가 발생할 때마다 전자 메일이나 팝업 메시지를 통해 경고 알림을 전송하거나 호출기 장치로 직접 전송하기 위한 추가 규칙을 작성할 수 있습니다. MOM에서는 보안 모니터링 및 공격 탐지에 사용할 수 있는 많은 유용한 기능을 제공하지만, 기본적으로 MOM은 이러한 기능에 사용하기 위한 제품이 아닙니다. 향후 MOM 릴리스에서는 더욱 향상된 보안 로그 수집 기능을 제공하게 될 것입니다. ###### Microsoft Systems Management Server 2003 Microsoft SMS(Systems Management Server) 2003은 네트워크의 서버 및 워크스테이션을 중앙에서 모니터링하고 관리할 수 있습니다. SMS는 관리 작업을 위한 제품이지만 보안 업데이트 배포 및 보고를 관리하거나 무단 소프트웨어 설치를 보고함으로써 보안 모니터링 솔루션의 중요한 보안 관련 기능으로 사용할 수도 있습니다. SMS 인벤토리 기능은 보안 감사 및 모니터링 프로세스에서 중요한 역할을 하는 실시간 인벤토리 관리 솔루션으로 작동하므로 보안 모니터링 솔루션의 필수 요소로 사용될 수 있습니다. ##### 정밀 분석 구현 정밀 분석은 광범위한 주제이므로 이 문서에서는 이 주제와 관련된 모든 내용을 다루기는 불가능합니다. 특히 이 문서에서는 정밀 분석의 입증 처리 요구 사항이나 보안 이벤트 로그에서 제공하는 정보 이외의 정밀 데이터에 대해서는 다루지 않습니다. 정밀 분석을 사용하면 공격에 영향을 받는 시스템을 식별하고 보안 위반 시기, 위험 등급 및 결과를 판단할 수 있습니다. 효율성을 높이려면 정밀 분석용으로 수집된 정보에 다음 정보가 포함되어야 합니다. - 공격 시간 - 공격 기간 - 공격에 영향을 받는 시스템 - 공격 중 변경된 사항 다시 한 번 말하지만 입증 절차를 규제하는 법률에 대한 이해, 정밀 분석과 관련된 주요 데이터 유형, 분석, 증거 수집, 증거 보존 및 정밀 분석 방법은 매우 심층적인 주제이므로 이 문서에서는 자세히 다루지 않습니다. 하지만 보안 연구 전문 사이트에서 CERT의 [First Responders Guide to Computer Forensics (영문)](https://www.cert.org/archive/pdf/frgcf_v1.3.pdf) (www.cert.org/archive/pdf/FRGCF\_v1.3.pdf) 같은 훌륭한 자료를 확인할 수 있습니다. ###### 비즈니스 문제 정밀 분석에서는 실시간 사고 분석 대신 사고 발생 후에 조사하는 방식을 취하기 때문에 정밀 분석의 사용 계획은 다른 솔루션의 접근 방식과 차이가 있습니다. 따라서 여러 시스템의 이벤트 세부 내역을 장기간 보관해야 합니다. 이러한 추가 요건으로 인해 효과적인 정밀 분석 시스템은 중앙 집중화되어야 하며 적합한 데이터베이스 구조 내에 많은 레코드를 저장할 수 있는 상당한 저장 용량을 갖추어야 합니다. 비즈니스 관련 의사 결정의 부담을 덜어 주는 요인 중 하나는 정밀 분석을 위해 레코드를 보존해야 하는 기간과 사용해야 할 보존 주기 유형과 관련되어 있습니다. 이와 같은 요인은 정밀 분석 계획에 대한 저장소 및 장비 요구 사항에 많은 영향을 줄 수 있습니다. 다음 표는 정밀 분석 계획을 설정한 회사의 일반적인 보존 기간을 보여 줍니다. **표 2. 정밀 분석을 위한 저장 제한 기간**

저장소 요인 저장 제한 기간 설명
온라인 저장소(데이터베이스) 21일 이벤트 세부 정보에 대한 신속한 액세스 제공
오프라인 저장소(백업) 180일 대부분의 조직에 적합한 보관 제한 기간
규제된 환경 7년 규제된 회사의 보관 요구 사항
정보 기관 영구 정보 및 방어 조직 요구 사항
**참고** 규제된 업계의 일부 관행(예: 의학 레코드를 다루는 회사의 방법)에서는 설정된 보존 기간 대신에 "보존 제한" 측면에서 시간 제한 사양이 사용됩니다. 한 가지 고려해야 할 옵션은 온라인 데이터베이스를 사용하여 온라인 정밀 분석 데이터를 보존한 다음 이전 이벤트를 오프라인 보관을 위해 CSV(쉼표로 구분된 값) 텍스트와 같은 압축 가능한 형식으로 보관하는 것입니다. 필요한 경우 분석을 위해 CSV 파일을 온라인 데이터베이스로 다시 가져올 수도 있습니다. 선택한 모든 솔루션이 최근 이벤트에 대한 신속한 조사를 위한 비즈니스 요구 사항을 충족하며, 필요할 경우 이전 이벤트를 복구할 수 있는 추가 기능을 갖추고 있는지 확인합니다. 회사 내 보안 사고의 내역과 사용 가능한 리소스 목록을 활용하면 온라인 및 오프라인 저장소의 데이터 보존 기간이 효과적으로 결합된 계획을 손쉽게 작성할 수 있습니다. 가능한 경우, 실행할 보고서를 사용하여 대용량 데이터베이스 내에서 이벤트 수집 시스템을 테스트한 후 보고서가 실행되고 활용 가능한 정보를 제공하는지 충분히 확인합니다. 또한 정밀 분석 데이터에는 거의 액세스할 필요가 없기 때문에 이러한 데이터의 보안도 고려해야 합니다. 액세스해야 할 경우 몇 명의 선택된 신뢰할 수 있는 보안 인력에게만 액세스 권한을 부여해야 합니다. 이 정보에 대한 관리자 액세스는 추가적인 보안 감시 기능을 갖춘 설정된 변경 제어 프로세스 내에서 철저하게 규제되어야 합니다. 또한 그 밖의 사용자는 이 정보에 액세스하거나 정보 수집을 중단하거나 정보를 수정할 수 없어야 합니다. ###### 기술 문제 정밀 분석을 위한 보안 모니터링 솔루션을 계획할 때는 많은 이벤트를 안전하게 수집하여 저장하는 프로세스를 신중하게 구축해야 합니다. 보안 모니터링 요구 사항은 다른 솔루션 시나리오의 세부 요구 사항과 비슷하지만, 데이터베이스 저장을 위해 보다 많은 리소스와 효율적인 데이터 관리가 요구됩니다. 고려해야 할 주요 기술 문제는 다음과 같습니다. - 온라인 데이터를 위한 안전하고 신뢰할 수 있는 저장소 - 온라인 저장소로 사용할 고성능 대용량 디스크 공간 구축 - 오래된 이벤트를 보관 미디어로 저장할 신뢰할 수 있는 백업 시스템 - 안전한 보관 저장소 관리 프로세스 - 백업 저장소에서 정보를 가져오는 테스트된 복원 프로세스 데이터베이스 관리자는 OLTP(온라인 트랜잭션 처리) 데이터베이스 같은 다른 응용 프로그램에 대해서도 이와 유사한 문제를 겪고 있기 때문에 이러한 문제는 보안 모니터링에만 국한되지 않습니다. 하지만 OLTP와 같은 다른 트랜잭션 데이터베이스 응용 프로그램과 달리, 정밀 분석 데이터베이스는 읽기용보다는 엄청난 양의 쓰기용 볼륨을 처리해야 합니다. ###### 요구 사항 효과적인 정밀 분석 프로그램을 계획하려면 다음 요구 사항을 충족해야 합니다. - 올바른 보안 로깅 설정 구성 - 보안 로그 항목 검사 프로세스 설정 - 보안 로그에 대해 생성된 안전하고 중앙 집중화된 수집 지점 및 프로세스 - 보안 모니터링 정보의 신뢰할 수 있는 저장소 - 효과적인 보관 계획 및 일정 개발 각 조직마다 비즈니스 환경의 요구 사항, 기능 및 규정 제한에 대한 고려 수준이 다르므로 이러한 사항은 정밀 분석 솔루션의 주요 요인으로 작용합니다. #### 솔루션 배포 및 관리 공격을 식별하고 프로파일링하며 대응하는 능력은 보안 모니터링 및 공격 탐지 솔루션의 기본 목표입니다. 따라서 이 섹션에서는 주로 이벤트 로그에서 발견되는 진행 중인 공격을 나타낼 수 있는 관련 이벤트에 대해 자세히 설명합니다. 이를 고려할 경우 보안 모니터링 및 공격 탐지 계획은 다음 요구 사항을 충족해야 합니다. - 내부 정책 위반 감지 - 외부 소스로부터의 공격 식별 - 효율적이고 정확한 정밀 분석 사용 이 문서에 자세히 설명된 솔루션은 이러한 각각의 세 가지 요구 사항을 충족하기 위해 유사한 구성 요소를 사용합니다. 정밀 분석 기능을 구현할 때는 추가 요구 사항이 적용되는데 이에 대해서는 뒤에서 설명하겠습니다. ##### 보안 모니터링 및 공격 탐지 보안 모니터링 및 공격 탐지 솔루션을 개념화할 때는 다음 영역에 대한 적정 수준의 보안 감사를 계획해야 합니다. - 계정 관리 - 보호된 파일 액세스 - 보안 정책 변경 - 트러스트 생성 및 삭제 - 사용자 권한 사용 - 시스템 다시 시작 및 시간 변경 - 레지스트리 수정 - 알 수 없는 프로그램 실행 보안 모니터링 및 공격 탐지 시스템에서는 보안 이벤트 로그의 정보를 수집하여 이 정보를 중앙에 통합합니다. 그러면 보안 감사자가 이 데이터에서 의심스러운 활동이 있는지 분석할 수 있습니다. 또한 이 정보를 추후 정밀 분석이 필요할 때 사용할 수 있도록 저장 및 보관할 수도 있습니다. 이 솔루션의 주요 구성 요소 중 하나는 Microsoft Windows 2003 서비스 팩 1(SP1)과 Microsoft Windows XP 서비스 팩 2(SP2)의 사용자별 감사 기능을 구성할 수 있는 부분입니다. 사용자별 감사 기능을 사용하면 특정 계정에 대해 다양한 감사 수준을 지정할 수 있으므로 중요하거나 의심스러운 계정에 대해 보다 높은 세부 감사 수준을 적용할 수 있습니다. ###### 솔루션 전제 조건 보안 모니터링 및 공격 탐지 솔루션을 구성하려면 먼저 다음 조건을 충족해야 합니다. - 서버가 Windows Server 2003 SP1 이상을 실행하거나 Active Directory 도메인에 있어야 합니다. - 클라이언트 컴퓨터가 Active Directory 도메인의 구성원으로서 Windows XP SP2 이상을 실행해야 합니다. **참고** 회사 경계에 있는 컴퓨터가 도메인 안에 없는 경우에는 Active Directory 그룹 정책 설정을 사용하여 구성할 수 없습니다. 대신 로컬 정책 및 템플릿을 사용하여 구성할 수 있습니다. 이 문서에서는 공격의 특징적인 패턴을 식별하는 데 중점을 두며 사용 가능한 몇 가지 솔루션이 있다고 해도 보안 이벤트 검사에 사용할 특정 기술을 권장하지 않습니다. 적합한 수집 메커니즘을 결정한 후에는 이 문서에 나열된 이벤트와 이벤트 순서를 사용하여 의심스러운 행동을 식별하기 위한 쿼리 및 경고를 디자인할 수 있습니다. ##### 정책 위반 및 임계값 Microsoft Windows Server 2003 및 Microsoft Windows XP SP2에 새로 도입된 기능을 사용하면 개별 사용자 계정에 대한 감사 수준을 선택할 수 있습니다. 예를 들어, 특정 사용자의 모든 활동을 감사하는 과정에 모든 사용자의 로그온 및 로그오프 활동만 보고하도록 감사 수준을 설정할 수 있습니다. 사용자별 선택적 감사를 사용하면 특정 활동에 대한 감사 생성 시 특정 계정을 제외할 수 있으므로 보안 로그의 이벤트 볼륨을 줄일 수 있습니다. 이 기능을 사용하면 사용자 계정만 감사할 수 있지만, 이 경우 보안 및 배포 그룹은 감사할 수 없습니다. 또한 사용자별 선택적 감사 메커니즘을 사용해도 관리자 로컬 그룹에 속한 계정은 감사에서 제외할 수 없습니다. Windows Server 2003 및 Windows XP SP2에서 선택적 감사에 대한 사용자별 감사 정책을 설정하는 데 사용되는 명령줄 유틸리티는 Auditusr.exe입니다. 사용할 수 있는 선택적 감사 범주는 다음과 같습니다. - 시스템 이벤트 - 로그온/로그오프 - 개체 액세스 - 권한 사용 - 세부 추적 - 정책 변경 - 계정 관리 - 디렉터리 서비스 액세스 - 계정 로그온 Aauditusr.exe를 매개 변수 없이 명령줄에서 실행하면 현재의 선택적 감사 설정이 표시되며, 처음에는 비어 있습니다. 선택적 감사 매개 변수를 입력하는 방법에는 두 가지가 있습니다. 하나는 사용자마다 하나씩 수동으로 입력하는 방법이며, 다른 하나는 사용자별 감사 설정 파일을 가져와 여러 매개 변수를 한 번에 입력하는 것입니다. 다음은 Audituser.exe의 사용 예입니다. ``` Audituser.exe /parameter useraccount:”category” ``` (또는 쉼표로 구분된 범주 목록). 예를 들어, LocalUser라는 이름의 계정에 대해 시스템 이벤트 및 로그온/로그오프 이벤트의 실패 감사를 수행하려는 경우에는 다음 명령줄 항목을 사용합니다. ``` Audituser /if LocalUser:”System Event”,”Logon/Logoff” ``` 명령줄에서 다음 매개 변수를 사용할 수 있습니다. - **/is** – 포함 성공 항목을 추가하거나 변경 - **/is** – 포함 실패 항목을 추가하거나 변경 - **/is** – 제외 성공 항목을 추가하거나 변경 - **/is** – 제외 실패 항목을 추가하거나 변경 - **/r** – 특정 사용자 계정에 대한 모든 사용자별 감사 항목 제거 - **/r** – 모든 사용자 계정에 대한 모든 사용자별 감사 항목 제거 - **/e** – 설정을 지정된 파일 이름으로 내보내기 - **/i** – 지정된 파일 이름에서 설정 가져오기 사용자별 감사 설정 파일은 일반 텍스트 파일이며 다음 그림에 표시된 형식을 사용합니다. ![](images/Cc875806.SMAAD6(ko-kr,TechNet.10).gif) **그림 6. Auditusr.exe에서 가져오기 파일 예** **참고** 가져오기 파일은 성공적으로 가져왔음을 나타내는 “Auditusr 1.0” 줄로 시작해야 합니다. 따라서 위 그림에 표시된 감사 설정 파일을 가져오려면 다음 명령을 사용합니다. ``` Audituser /i path\\audit.txt ``` 이 유틸리티를 사용하면 감사 로깅 정보의 임계값을 설정하여 저장소 요구 사항을 줄이고 침입 시도 알림 가능성을 높일 수 있습니다. ##### 보안 정책 위반과 감사 이벤트의 상관 관계 이 섹션에서는 정책 위반의 소스가 외부인지 또는 내부인지를 구분하지 않지만, 회사 입장에서는 내부 정책 위반도 외부의 공격만큼 파괴적일 수 있음을 명심해야 합니다. 이 문서의 앞부분에서 설명했듯이 내부 소스에 의해 자행된 악의적인 공격의 비율이 높게 나타나고 있습니다. 하지만 이 비율에는 설정된 절차 범위 밖에서 상승된 권한의 부적절한 사용으로 인한 우발적인 손상은 포함되지 않습니다. 내부 소스에서 상승된 권한을 우발적으로나 고의적으로 악용할 위험이 있기 때문에 이러한 권한의 적절한 사용에 관한 정책 및 절차를 설정하고 서로 연결하기 위해 감사 추적을 설정하는 일이 중요합니다. 변경 관리 프로세스 및 문서화 정책을 설정하고 나면 감사 정보를 승인 및 비승인 이벤트에 맞추는 상관 관계를 개발할 수 있으며, 이를 통해 회사 내에서 비정상적인 행동을 쉽게 감지할 수 있습니다. 이 섹션에서는 추적할 수 있는 다양한 유형의 이벤트와 정책 및 프로세스를 적용하는 방식을 설명하여 이러한 상관 관계를 손쉽게 이해하도록 하고 있습니다. ###### 권한이 없는 컴퓨터 액세스 관리 및 지원 담당 직원이 터미널 서비스와 같은 원격 관리 기능을 사용하여 원격 시스템에 연결하거나 원격 시스템을 관리하는 경우가 점점 늘어나고 있습니다. 이러한 시스템에서는 대화형 로그온 시도를 모니터링해야 하며 각 연결 시도의 유효성을 확인해야 합니다. 유효성을 확인할 때는 다음 작업을 수행해야 합니다. - 서비스 계정 로그온 식별 - 권한이 없는 계정에 의한 액세스 시도 기록 - 일반적이지 않은 지역으로부터의 시도 조사 - 외부 IP 주소 범위로부터의 시도 나열 고부가가치 자산을 모니터링할 때는 각별히 주의해야 합니다. 이러한 주요 리소스는 엄격한 감사 모니터링과 액세스 제어 설정을 사용하여 구성된 특정 서버에 있어야 합니다. 다음 표에는 로그온 감사 이벤트가 나열되어 있으며, 이 이벤트가 고부가가치 자산 시스템에 나타날 때 권한이 있는 계정 목록과 비교해야 합니다. **표 3. 권한이 없는 컴퓨터 사용 이벤트**

이벤트 ID 발생 이벤트 설명
528 로그온 성공 워크스테이션 이름 및 사용자 계정 이름을 확인하십시오. 원본 네트워크 주소가 네트워크에 있는지 확인하십시오.
529 로그온 실패 – 알 수 없는 사용자 이름이거나 암호가 틀림 대상 계정 이름이 Administrator이거나 변경된 기본 관리자 계정인 로그온 시도를 확인하십시오. 계정 잠금 임계값보다 낮은 다수의 로그온 실패도 확인하십시오.
530 로그온 실패 - 시간 제한 허용된 시간 범위 외부에서의 로그온 시도를 나타냅니다. 사용자 계정 이름 및 워크스테이션 이름을 확인하십시오.
531 로그온 실패 – 현재 사용할 수 없는 계정 대상 계정 이름 및 워크스테이션 이름을 확인하십시오. 이 이벤트는 이전 사용자가 시도했던 침입을 나타낼 수 있으므로 조사해 볼 필요가 있습니다.
532 로그온 실패 – 지정한 사용자 계정이 만료됨 대상 계정 이름 및 워크스테이션 이름을 확인하십시오. 이 이벤트는 계약직 또는 임시직 직원의 악용 시도를 나타낼 수 있으므로 조사해 볼 필요가 있습니다.
533 로그온 실패 – 사용자가 이 시스템에 로그온이 허용되지 않았음 사용자가 제한된 워크스테이션에 로그온하려 할 수 있음을 나타냅니다.
534 로그온 실패 – 허용되지 않은 로그온 유형 대상 계정 이름, 워크스테이션 이름 및 로그온 유형을 확인하십시오. 이 이벤트는 그룹 정책 설정에서 서비스 계정을 사용한 대화형 로그온을 금지하는 경우 해당 계정의 자격 증명을 사용한 대화형 로그온 실패 시도를 나타냅니다.
535 로그온 실패 – 지정된 계정 암호가 만료됨 사용자가 암호가 만료된 계정을 사용하여 로그온을 시도하려 한다는 것을 나타냅니다. 해당 암호의 변경 또는 지원 호출 없이 반복해서 시도할 경우 즉각적인 조사가 필요할 수 있습니다.
536 로그온 실패 - NetLogon 구성 요소가 활성화되어 있지 않음 NetLogon 서비스가 작동 중인지 확인하십시오. 작동하지 않는 경우에는 이 이벤트를 즉시 조사해 볼 필요가 있습니다.
540 로그온 성공 이 이벤트는 이벤트 528에 해당하는 네트워크입니다.
###### 트로이 목마, 루트킷 및 맬웨어 이벤트 ID 592는 새 프로세스가 시작될 때마다 생성되므로 트로이 목마, 루트킷 및 기타 맬웨어가 설치되었는지 감지하는 데 특히 유용합니다. 이 이벤트가 발생하면 이미지 파일 이름이 승인된 프로그램 목록에 나열된 프로세스와 일치하지 않을 때마다 즉시 조사해야 합니다. 트로이 목마 및 키로거는 쉽게 식별할 수 있지만 루트킷은 겉으로 드러나지 않아 찾아내기가 어려운 편입니다. 연속해서 신속하게 시작되었다가 중지되는 알 수 없는 프로그램을 검색하면 루트킷을 찾아낼 수 있습니다. 하지만 루트킷이 시작될 때 운영 체제에서 루트킷을 감지할 수 없으므로 어떠한 세부 이벤트도 생성되지 않습니다. 그 밖의 맬웨어 시도는 전자 메일 첨부 파일이나 감염된 웹 사이트의 형태로 나타날 수 있으며, 실행 중인 계정에 새 프로그램을 시작할 수 있는 권한이 없으면 권한 상승을 시도할 수도 있습니다. 이러한 경우에는 권한이 없는 소프트웨어에서 조사해야 할 실패 이벤트를 생성하게 됩니다. 특히 다음 이벤트가 발생하는 경우가 이에 해당됩니다. - **LocalSystem으로 생성되는 프로세스.** LocalSystem으로 실행되는 프로세스는 승인된 프로그램 목록에 적절히 정의되어 있어야 하며 여기에는 Services.exe와 같은 프로세스가 포함될 수 있습니다. - **예기치 않은 시간에 생성된 프로세스.** 모니터링되는 시스템에서 예정된 배치 프로세스를 사용하지 않는 경우 백업, CGI 또는 스크립트 등 특정 활동이 발생하면 해당 활동을 조사해야 합니다. 그 밖의 경우에는 정기적으로 예정된 배치 시간 이외의 시간에 이러한 이벤트가 발생할 때 조사해야 합니다. **표 4. 이벤트 592**

이벤트 ID 발생 이벤트 설명
592 새 프로세스 만들기 승인되지 않은 프로세스 또는 예기치 않은 시작 시간이 있거나, 알 수 없는 프로그램이 시작되고 나서 곧바로 중지되는 경우가 있는지 이미지 파일 이름 및 사용자 이름 항목을 확인하십시오.
###### 파일 권한을 변경하여 리소스 액세스 관리자 권한을 사용하여 데이터의 소유권을 변경한 후 계정을 해당 데이터의 읽기 권한 목록에 추가하면 일반적으로 액세스가 거부되는 파일에 액세스할 수 있습니다. 또한 소유권과 권한을 원래 설정으로 다시 변경하여 Windows Server 2003에서 이러한 활동을 위장할 수도 있습니다. 이 문제는 일반적으로 매일 발생하는 많은 액세스 이벤트 볼륨으로 인해 평균적인 중소 기업 네트워크의 모든 파일에 대해 개체 액세스 감사를 구현해야 하는 역효과를 초래하므로 문제를 해결하는 과정에 고부가가치 자산 및 데이터를 반드시 식별해야 합니다. 또한 중요 파일 및 폴더에 대해 개체 액세스 감사를 사용할 수 있어야 합니다. ACL 항목만으로는 무단 액세스 시도를 적절히 방어하기에 부족합니다. 부정 활동을 효율적으로 감지하려면 모든 고부가가치 파일에 대해 다음 요인을 쉽게 식별할 수 있어야 합니다. - 액세스 시도의 대상이 된 개체 - 액세스를 요청하는 데 사용된 계정 - 무단으로 액세스된 계정 - 시도된 액세스 유형 - 이벤트 성공 여부 - 시도를 시작하는 데 사용된 시스템 기본 제공 이벤트 뷰어의 필터 설정만으로는 이 정보를 식별하기에 충분하지 않습니다. 따라서 EventCombMT 또는 다른 메커니즘을 사용하여 이 분석을 수행해야 합니다. 다음 표의 개체 액세스 감사 이벤트는 이러한 특징을 지닌 시도를 나타냅니다. **표 5. 파일 권한 변경 이벤트**

이벤트 ID 발생 이벤트 설명
560 기존 개체에 부여된 액세스 개체에 대해 액세스 요청이 허가되었음을 나타냅니다. 기본 로그온 ID, 클라이언트 사용자 이름 및 기본 사용자 이름을 확인하여 무단 액세스를 찾아내십시오. 액세스 필드를 확인하여 작업 유형을 판단하십시오. 이 이벤트는 실제 액세스 발생 여부가 아닌 액세스 요청만 감지합니다.
567 사용된 핸들과 관련된 권한 개체에 대한 액세스 유형의 첫 번째 인스턴스와 액세스 필드에 “WRITE_DAC”가 포함된 경우 해당 권한이 변경되었음을 나타냅니다. 핸들 ID 필드와 비교하여 이벤트 560에 연결하십시오.
###### 암호를 재설정하여 리소스 액세스 암호는 설정된 절차의 승인된 프레임워크 내에서만 변경해야 합니다. 올바르게 구성된 감사 수준에서는 다음 표에 나와 있는 계정 관리 이벤트를 기록하고 기록된 절차와 이러한 이벤트를 서로 연결하여 해당 절차를 따르지 않는 활동을 식별합니다. **표 6. 암호 재설정 이벤트**

이벤트 ID 발생 이벤트 설명
627 암호 변경 시도 요청자가 원래 암호를 제공한 암호 변경 요청을 나타냅니다. 기본 계정 이름과 대상 계정 이름을 비교하여 요청하는 계정이 변경된 계정인지를 확인하십시오.
628 사용자 계정 암호 설정 또는 재설정 암호 변경 프로세스라기보다는 관리 인터페이스를 통한 암호 재설정을 나타냅니다. 요청자는 지원 센터 계정 또는 셀프 서비스 암호 재설정 계정과 같은 권한이 있는 계정이어야 합니다.
698 디렉터리 서비스 복원 모드 암호 변경 도메인 컨트롤러에서의 디렉터리 서비스 복원 모드 암호 변경 시도를 나타냅니다. 워크스테이션 IP 및 계정 이름을 확인하십시오. 이 이벤트는 즉각적인 조사가 필요합니다.
###### 사용자 계정 수정 계정 추가, 삭제 또는 변경 같은 모든 계정 수정은 관리 수준의 직원으로부터 공식적인 요청에 의해 시작된 다단계 비즈니스 논리 프로세스를 포함하는 설정된 프로세스에 부합해야 합니다. 다음 표의 모든 이벤트는 공식적인 계정 수정 요청과 일치해야 하며, 그렇지 않을 경우에는 즉각적인 조사가 필요합니다. **표 7. 사용자 계정 변경 이벤트**

이벤트 ID 발생 이벤트 설명
624 사용자 계정 만들기 네트워크 계정 생성 작업이 발생했음을 나타냅니다.
630 사용자 계정 삭제 네트워크 계정 삭제 작업이 발생했음을 나타냅니다.
642 사용자 계정 변경 보안 관련 사용자 계정 변경 사항은 이벤트 627-630에서 다루지 않는 사항임을 나타냅니다.
685 사용자 계정 이름 변경 사용자 계정 이름 변경을 나타냅니다.
계정 관리 문제를 효과적으로 식별하려면 다음을 수행하도록 쿼리를 구성해야 합니다. - 올바르지 않거나 일반적이지 않은 계정 활동을 찾습니다. - 계정을 만들거나 수정할 수 있는 권한을 악용하는 관리자 수준의 계정을 식별하십시오. - 조직 보안 정책 외부에서 발생하는 계정 활동의 패턴을 찾아내십시오. 계정 만들기와 초기 로그온 및 암호 변경 사이의 간격을 확인하는 것도 중요합니다. 일반적으로 계정 만들기 프로세스에서는 새 사용자의 예상 시작 날짜를 기록하므로 새 계정이 미리 지정된 시간 안에 사용되지 않으면 계정을 사용할 수 없게 하고 지연 사유를 확인하기 위한 조사를 시작해야 합니다. ###### 그룹 구성원 변경 바람직한 보안 방법에는 최소 권한 원칙이 포함됩니다. 다시 말해 계정에 기능을 적절히 수행하는 데 필요한 최소한의 액세스 수준을 부여하는 것을 의미합니다. 이 방법을 적용하는 경우 대부분의 계정은 기본 도메인 사용자 그룹의 구성원과 회사 고유 보안 그룹의 추가 구성원입니다. 보안 그룹 구성원은 설정된 정책 지침 내에서만 변경해야 하며, 상승된 권한을 가진 계정과 관련된 경우에는 더욱 그렇습니다. 이러한 그룹 구성원 변경은 계정 관리에 사용되는 설정된 계정에 의해 수행되어야 하며 이러한 이벤트는 해당 변경에 대해 설정된 프로세스와 서로 연결되어야 합니다. 이 프로세스 외부에서 변경이 발생한 경우에는 즉시 조사해야 합니다. 다음 표의 계정 관리 감사 이벤트에서는 그룹 구성원 변경에 대해 자세히 설명합니다. **표 8. 그룹 구성원 변경 이벤트**

이벤트 ID 발생 이벤트 설명
631, 632,
633, 634,		 보안 글로벌 그룹 변경 대상 계정 이름 필드를 확인하여 변경된 그룹이 글로벌 그룹이거나 광범위한 액세스 권한을 가지고 있는지 알아보십시오.
635, 636,
637, 638,		 보안 로컬 그룹 변경 대상 계정 이름 필드를 확인하여 변경된 그룹이 관리자, 서버 운영자 또는 백업 운영자인지 알아보십시오.
639, 641,
668		 보안 그룹 변경 삭제, 만들기 또는 구성원 변경 이외의 그룹에 대한 변경 사항을 나타냅니다. 대상 계정 이름을 확인하여 권한이 높은 그룹이 변경되지 않았는지 알아보십시오.
659, 660, 661, 662 보안 유니버설 그룹 변경 대상 계정 이름 필드를 확인하여 Enterprise Admins와 같은 권한이 높은 그룹이 변경되지 않았는지 알아보십시오.
**참고** 배포 그룹 구성원은 보안 주체가 아니므로 네트워크 리소스에 액세스할 수 없습니다. 하지만 특정 배포 그룹의 구성원은 그룹에 따라 보안 문제를 일으킬 수 있습니다. 예를 들어, 사용자 계정을 관리 또는 실행 배포 그룹에 배치하면 사용자의 직위에 적합하지 않은 전자 메일 메시지가 사용자에게 전달될 수 있습니다. ###### 권한이 없는 계정 사용 시도 포리스트에 있는 첫 번째 Active Directory 도메인 컨트롤러를 승격하면 Domain Admin 및 Enterprise Admin 두 그룹의 구성원인 관리자 계정이 만들어집니다. 이 계정은 계정 잠금 설정에 영향을 받지 않는 유일한 계정이므로 특별히 보호해야 합니다. 따라서 계정 잠금 정책이 올바르게 적용되어 있더라도 이 계정은 사전 공격에 특히 취약합니다. 효과적인 보안 모니터링에서는 계정 이름 변경되더라도 이 관리자 계정을 사용한 모든 로그온 시도를 식별할 수 있어야 합니다. 관리 계정에 대한 보안 강화에 대한 자세한 내용은 [관리자 계정 보안 계획 가이드](https://www.microsoft.com/korea/technet/security/topics/serversecurity/administratoraccounts/default.mspx) (https://www.microsoft.com/korea/technet/security/topics/serversecurity/administratoraccounts/default.mspx) 를 참조하십시오. 또한 사용할 수 없거나 만료된 계정을 사용한 로그온 시도가 발생되면 이전 직원, 임시직 직원 또는 계약직 직원이 현재 자격 증명 없이 네트워크에 액세스하려고 했음을 알 수 있습니다. 이러한 이벤트는 즉시 조사해야 합니다. 다음 표는 무단 계정 사용을 식별하고 계정 로그온 및 로그온 감사 범주에 속하는 이벤트의 목록입니다. **표 9. 무단 로그온 이벤트**

이벤트 ID 발생 이벤트 설명
528 540 로그온 성공 528은 일반적인 이벤트입니다. 하지만 이벤트 540의 경우에는 대상 계정 이름을 확인하여 기본 관리자 계정에 의해 발생했는지 여부를 알아보아야 합니다.
529 로그온 실패 – 알 수 없는 사용자 이름 또는 암호 대상 계정 이름이 Administrator이거나 이름이 변경된 기본 관리자 계정인 경우에는 항상 조사해야 합니다. 로그온 실패 횟수가 잠금 임계값에 거의 다다른 경우에도 항상 조사해야 합니다. 또한 대상 계정 이름이 Administrator 또는 루트이거나 도메인 이름을 알 수 없는 시도도 확인하십시오.
531 로그온 실패 - 사용할 수 없는 계정 대상 계정 이름 및 워크스테이션 이름을 확인하여 출처를 파악하십시오. 이 이벤트는 이전 계정 사용자에 의한 예상 침입 시도로 간주하여 조사해야 합니다.
532 로그온 실패 - 만료된 계정 대상 계정 이름 및 워크스테이션 이름을 확인하여 출처를 파악하십시오. 이 이벤트는 이전 계정 사용자에 의한 예상 침입 시도로 간주하여 조사해야 합니다.
576 새 로그온에 할당된 특별 권한 새 계정 권한이나 감사 추적을 변경하는 기능을 부여할 수 있는 권한 할당을 나타냅니다. 로그온 ID 필드와 이벤트 528 또는 540을 비교하면 계정에 관리자에 해당하는 권한이 있는지 쉽게 알 수 있습니다.
계정 자격 증명의 무단 사용과 관련된 또 다른 보안 문제는 강력한 암호 정책과 짧은 암호 만료 시간 등 효과적인 암호 정책을 사용하는 것에서 비롯되기도 합니다. 이는 경우에 따라 암호를 기억할 수 있도록 적어 두거나 기록하는 사용자도 있기 때문입니다. 이 문제는 여러 암호 및 계정을 사용해야 하며 ID 관리 서비스의 도움이 없이 여러 ID 저장소를 보유하는 환경에서 특히 두드러지게 나타납니다. **참고** 이기종 환경의 암호 관리에 대한 자세한 내용은 [Microsoft Identity and Access Management Series (영문)](https://go.microsoft.com/fwlink/?linkid=14841) (https://go.Microsoft.com/fwlink/?LinkId=14841) 를 참조하십시오. 조직에서는 암호를 기록하는 사용자를 경계해야 합니다. 특히, 일반적인 시각에서 볼 때 권한이 없는 개인 사용자가 이 정보를 찾아 공격을 시도하는 데 사용할 수 있습니다. 이러한 유형의 침입은 위 표의 정보를 사용하여 모니터링할 수 있지만, 이를 위해서는 액세스할 해당 계정에 일반적으로 사용되는 워크스테이션 목록을 작성할 수 있도록 해당 사용자 계정의 로그온 성공 기록과 이 정보를 연결해야 합니다. **참고** 기본 제공 Active Directory 기능을 사용하여 사용자 계정을 특정 워크스테이션으로 제한할 수 있습니다. 하지만 이 기능을 사용하려면 네트워크에서 WINS(Windows Internet Naming Server) 등에서 제공하는 네트워크 기본 입/출력 시스템(NetBIOS) 명명 규칙을 지원해야 합니다. ###### 서비스 계정 자격 증명을 사용한 대화형 로그온 서비스는 시작될 때 로그온 자격 증명을 제공해야 합니다. 경우에 따라 특정 서비스에서는 도메인 계정을 사용하여 서비스를 실행하거나 원격 컴퓨터에 연결해야 합니다. 일부 서비스는 관리자 자격 증명이나 데스크톱과의 상호 작용을 필요로 할 수도 있습니다. Windows Server 2003 이상에서는 **–LocalService** 스위치를 사용하여 경고 서비스와 같은 일부 서비스 계정을 시작할 수 있습니다. 또한 네트워크 연결이 필요한 서비스는 네트워크 서비스 계정 NT AUTHORITY\\Network Service를 사용할 수 있습니다. 사용자 계정이 필요한 모든 서비스를 확인하여 사용된 계정이 강력한 암호로 보호되는지 알아보십시오. 보안 모니터링을 통해 이러한 계정의 로그온 이벤트가 관련 서비스가 시작될 때만 발생하는지 확인해야 합니다. 서비스 계정의 보안 강화에 대한 자세한 내용은 [서비스 및 서비스 계정 보안 계획 가이드](https://www.microsoft.com/korea/technet/security/topics/serversecurity/serviceaccount/default.mspx) (https://www.microsoft.com/korea/technet/security/topics/serversecurity/serviceaccount/default.mspx) 를 참조하십시오. 서비스 계정과 관련된 기본 보안 위협은 이러한 계정이 서비스가 아닌 대화형으로 로그온할 때 나타납니다. 이러한 이벤트는 서비스 계정이 침입자에 의해 손상되고 해당 계정을 사용하여 로그온될 때만 발생합니다. 손상된 서비스 계정에 관리자 권한이 있는 경우에는 침입자가 다양한 기능에 액세스할 수 있고 이로 인해 정상적인 네트워크 서비스가 중단될 수 있습니다. 따라서 서비스 계정에서 액세스할 수 있는 모든 리소스를 식별해야 하며 이 계정에 고부가가치 데이터 액세스와 관련된 원인을 알 수 없는 권한이 없도록 해야 합니다. 예를 들어, 서비스 계정에는 대개 로그 파일 디렉터리에 대한 쓰기 액세스 권한이 필요하지만 일반적으로 이 경우는 문제가 되지 않습니다. 데스크톱과 상호 작용할 수 있는 서비스 계정도 특별히 조사해 볼 필요가 있습니다. 이러한 계정은 공격자가 악용할 수 있는 기회가 좀 더 많기 때문입니다. 다음 표는 서비스 계정 자격 증명의 무단 사용을 식별하는 계정 로그온 및 로그온 감사 이벤트의 목록입니다. **표 10. 서비스 계정 자격 증명을 사용한 로그온 이벤트**

이벤트 ID 발생 이벤트 설명
528 로그온 성공 – 콘솔 공격 또는 터미널 서비스 로그온 유형 10, 서비스 계정 또는 로컬 시스템 계정이 이 이벤트와 관련된 경우 진행 중인 공격을 나타냅니다. 이 이벤트는 즉시 조사해야 합니다.
534 로그온 실패 – 허용되지 않은 로그온 유형 그룹 정책 설정에 의해 금지된 서비스 계정 자격 증명을 사용하여 대화형으로 로그온하려 했으나 실패한 시도를 나타냅니다. 이벤트가 발생하면 대상 계정 이름, 워크스테이션 이름 및 로그온 유형을 확인하십시오.
600 프로세스에 기본 토큰이 할당됨 서비스에서 명명된 계정을 사용하여 Windows XP 이상을 실행하는 시스템에 로그인하려 함을 나타냅니다. 조사하려면 이벤트 672, 673, 528 및 592의 정보와 연결하십시오.
601 사용자의 서비스 설치 시도 이 이벤트는 명확하게 정의된 허용 가능한 응용 프로그램 정책과 시스템 표준화 프로세스를 갖춘 비즈니스 환경에서는 대체로 발생하지 않습니다. 이러한 환경에서 변경 제어 프로세스가 연결되어 있지 않은 경우에는 이 이벤트를 조사해야 합니다.
###### 무단 프로그램 실행 관리자 수준 계정은 프로그램을 설치하고 실행할 수 있으므로 일반적으로 이러한 높은 권한을 필요로 하는 신뢰할 수 있는 사용자에게만 위임됩니다. 따라서 테스트되지 않은 소프트웨어와 관련된 위험으로 인해 새 응용 프로그램 요청, 테스트 및 승인을 위한 프로세스와 함께 승인되고 사용이 허가된 소프트웨어의 목록을 디자인해야 합니다. 승인되지 않은 응용 프로그램은 격리된 테스트 환경으로 제한해야 하며 설정된 변경 제어 프로세스를 벗어난 프로덕션 네트워크 환경에 설치해서는 안 됩니다. 또한 허용되더라도 승인된 소프트웨어 목록에 추가된 후에만 허용되어야 합니다. 다음 표는 권한이 없는 프로그램의 사용을 식별할 수 있는 프로세스 추적 이벤트의 목록입니다. **표 11. 권한이 없는 프로그램 실행 이벤트**

이벤트 ID 발생 이벤트 설명
592 새 프로세스 만들기 새 프로세스가 만들어졌음을 나타냅니다. 이미지 파일 이름 및 사용자 이름 필드를 확인하고 회사에 허용 가능한 프로그램 정책이 설정되어 있는 경우 권한이 있는 프로그램 목록과 비교하십시오. 또한 LocalSystem을 사용하여 명령 프롬프트를 시작하는 것은 감사 추적을 회피하기 위한 일반적인 방법이므로 이와 같은 경우가 있는지 살펴보십시오.
602 예정된 작업 만들기 이와 같은 이벤트가 예기치 않은 시간에 발생하는 경우 대상 이름 및 작업 이름을 확인하십시오.
**참고** 프로세스 추적 보안 감사를 수행하면 권한이 없는 프로그램을 식별할 수 있습니다. 하지만 프로세스 추적은 여러 개의 보안 로그 항목을 생성하므로 많은 이벤트로 인해 보안 감지 메커니즘의 작동 성능이 저하되지 않도록 주의해야 합니다. ###### 권한이 없는 리소스 액세스 다음 표에 나와 있는 개체 액세스 감사 이벤트는 사용 권한이 없는 리소스에 대한 사용자의 액세스 시도를 나타냅니다. **표 12. 권한이 없는 리소스에 대한 액세스 시도 이벤트**

이벤트 ID 발생 이벤트 설명
560 기존 개체에 대해 거부된 액세스 개체 이름 필드를 확인하여 액세스된 리소스를 알아보고 기본 사용자 이름 및 기본 도메인 필드 또는 클라이언트 사용자 이름 및 클라이언트 도메인 필드를 연결하여 출처를 파악하십시오.
568 감사된 파일에 대한 하드 링크 만들기 시도 사용자 또는 프로그램에서 파일이나 개체에 대한 하드 링크를 만들려고 했음을 나타냅니다. 계정에 개체한 대한 권한이 있는 경우 해당 계정에서는 설정된 하드 링크를 통해 감사 추적을 만들지 않고도 파일을 조작할 수 있습니다.
###### 권한이 없는 운영 체제 사용 권한이 없는 운영 체제를 사용할 경우 취약점 악용에 대한 보호 수준이 약화되는 것부터 파일 시스템의 데이터 손상 가능성이 늘어나는 것에 이르기까지 많은 문제가 발생할 수 있습니다. 관리자와 사용자는 다음 메커니즘을 통해 권한이 없는 운영 체제를 네트워크로 들여올 수 있습니다. - 로컬 또는 원격으로 네트워크에 연결된 개인 컴퓨터 - CD 부팅 가능한 운영 체제 사용 - Windows 운영 체제 다시 설치 - 가상 PC 이미지 사용 조직 정책에서는 사용자가 가상 사설망 또는 원격 액세스 서비스를 통해 원격 위치에서 네트워크에 연결하는 방법을 지정하고, 운영 체제 유형, 업데이트 수준 및 보호 수단(예: 개인 방화벽 및 바이러스 백신 소프트웨어) 설치 같은 시스템 연결 요구 사항을 포함할 수 있습니다. 원격 시스템을 비즈니스 보안 정책에 맞추는 방법에 대한 자세한 내용은 [Microsoft 가상 사설망으로 차단 서비스 구현 가이드](https://www.microsoft.com/korea/technet/security/prodtech/windowsserver2003/quarantineservices/default.mspx) (https://www.microsoft.com/korea/technet/security/prodtech/windowsserver2003/quarantineservices/default.mspx) 를 참조하십시오. 또한 사용자가 Windows XP 설치 CD를 사용하여 컴퓨터를 다시 시작한 후 관리되지 않는 운영 체제를 설치할 수도 있습니다. 이 경우 확인되지 않은 작업 그룹 이름이나 기본 작업 그룹 이름의 관리자 사용자 계정에 의한 로그온 시도를 찾아 이러한 활동 유형을 감지할 수 있습니다. **참고** 일부 오픈 소스 배포판은 로컬 시스템에 설치하지 않고도 운영 체제를 사용할 수 있도록 부팅 가능한 CD 형태로 제공됩니다. 운영 체제가 실제로 로컬 컴퓨터에 설치되지 않기 때문에 이러한 활동은 찾아내기가 어렵습니다. 하지만 사용자 계정의 로그온 시도는 이기종 네트워크 환경에서 "루트"로 표시되므로 예기치 않은 컴퓨터 이름이 있다면 권한이 없는 운영 체제가 사용되고 있는 것임을 알 수 있습니다. 컴퓨터 BIOS 설정의 CD로 부팅하는 기능을 사용하지 않도록 설정하고 BIOS 구성을 보호하는 암호를 설정하면 이러한 유형의 활동을 방지할 수 있습니다. 하지만 일부 환경에서는 이 방법이 통하지 않을 수도 있습니다. 가상 PC 이미지는 호스트 컴퓨터의 컴퓨터 환경 전체를 에뮬레이션합니다. 이 에뮬레이션에서는 특정한 컴퓨터 이름의 고유한 운영 체제, 사용자 계정, 디렉터리 서비스 구조 및 프로그램이 가상 환경에서 실행됩니다. 가상 PC 인스턴스는 호스트 시스템과는 별도로 시작, 실행 및 중지할 수도 있으므로 해당 호스트 컴퓨터에 어떠한 감사 이벤트도 만들 수 없습니다. 이 기능은 네트워크에 설정된 업데이트 프로세스를 통해 제어되지 않기 때문에, 이 기능을 가상 컴퓨터를 호스트 네트워크에 연결하고, IP 주소를 가져오고 공유 드라이브로 매핑하는 등의 기능과 함께 사용할 경우 암호 보호 약화에서 악용에 대한 취약점 증가에 이르기까지 다양한 보안 위험이 나타나게 됩니다. 가상 PC를 통해 이러한 위험이 발생한다고 가정하면 가상 PC 소프트웨어의 사용을 권한이 있는 직원으로 제한하고 가상 PC 인스턴스의 생성 및 사용에 관한 프로세스를 구축하고 문서화해야 합니다. 권한이 없는 운영 체제의 사용을 감지하려면 보안 모니터링 솔루션에서 다음을 감지할 수 있어야 합니다. - 인식되지 않은 사용자 계정, 컴퓨터 이름, 작업 그룹 또는 도메인 이름 - 중복된 IP 주소 또는 대역 외 IP 주소 - 기본 관리자 계정을 사용한 로그온 시도 다음 표에 나와 있는 프로세스 추적 이벤트를 사용하면 권한이 없는 운영 체제의 사용을 감지할 수 있습니다. **표 13. 권한이 없는 컴퓨터 사용 이벤트**

이벤트 ID 발생 이벤트 설명
529 로그온 실패 – 알 수 없는 사용자 이름 또는 암호 대상 계정 이름 필드가 Administrator 또는 루트이거나 도메인 이름을 알 수 없는 로그온 시도가 있는지 확인하십시오.
533 로그온 실패 – 사용자가 이 시스템에 로그온이 허용되지 않았음 사용자가 제한된 워크스테이션에 로그온하려 할 수 있음을 나타냅니다.
592 새 프로세스 만들기 이미지 파일 이름 및 사용자 이름 필드를 확인하여 프로그램이 해당 계정에서 지정된 용도로 사용되는 데 필요한 권한이 있는지 알아보십시오.
###### 신뢰 관계 구축 또는 파괴 신뢰 관계를 활용하면 한 도메인에 있는 계정이 다른 도메인에 있는 리소스에 액세스할 수 있습니다. 신뢰 관계를 구축하는 일은 분명 일시적인 작업이 아니며 설정된 변경 제어 프로세스 범위 내에서만 이루어져야 합니다. 또한 신뢰 관계의 파괴도 변경 제어 프로세스에서 승인되고 이 작업이 네트워크에 미치는 영향을 신중히 고려한 후에만 수행해야 합니다. 다음 표의 정책 변경 감사 이벤트는 신뢰 관계 활동을 나타냅니다. **표 14. 신뢰 관계 변경 이벤트**

이벤트 ID 발생 이벤트 설명
610
611
620		 다른 도메인과의 신뢰 관계가 생성, 삭제 또는 수정됨 이 이벤트는 신뢰 관계를 구축한 도메인 컨트롤러에 생성됩니다. 이 이벤트가 설정된 변경 제어 요청 프로세스에 연결되지 않은 경우에는 즉시 조사해야 합니다. 사용자 이름 필드를 확인하여 요청하는 계정을 알아보십시오.
###### 권한이 없는 보안 정책 변경 승인된 보안 정책 설정에 대한 변경 사항은 설정된 변경 제어 프로세스의 프레임워크 내에서만 발생해야 합니다. 변경 사항이 이 승인 프로세스 범위 외부에서 발생하는 경우에는 즉시 조사해야 합니다. 이러한 유형의 보안 정책 변경 사항은 다음과 같습니다. - 그룹 정책 설정 - 사용자 계정 암호 정책 - 사용자 계정 잠금 정책 - 감사 정책 - 보안 이벤트 로그에 적용하는 이벤트 로그 설정 - IPsec 정책 - 무선 네트워크(IEEE 802.1x) 정책 - 공용 키 및 EFS(암호화 파일 시스템) 정책 - 소프트웨어 제한 정책 - 보안 설정 - 사용자 권한 설정 - 사용자 계정 암호 정책 - 보안 옵션 대부분의 회사에서는 해당 환경에 다른 그룹 정책 설정을 추가할 수 있으므로 위의 목록에서는 최소 요구 사항만 제공합니다. 성공한 시도는 설정된 프로세스 내에서 이러한 변경 작업을 수행할 수 있는 권한을 가진 계정과 일치해야 하므로 보안 감사에서는 이러한 설정에 대한 변경 성공 및 실패 시도를 모두 식별해야 합니다. 다음 표는 그룹 정책 및 로컬 시스템 정책 변경을 식별하는 정책 변경 감사 이벤트의 목록입니다. **표 15. 정책 변경 이벤트**

이벤트 ID 발생 이벤트 설명
612 감사 정책 변경 감사 정책 변경을 나타냅니다. 권한이 부여되었는지 여부를 확인하려면 이 이벤트를 설정된 변경 제어 정책에 연결해야 합니다.
613
614
615		 IPsec 정책 변경 IPsec 정책 변경을 나타냅니다. 시스템이 시작되지 않고 발생하는 경우에는 조사해야 합니다.
618 암호화된 데이터 복구 정책 이 이벤트는 암호화된 데이터 복구 정책이 사용되고 있는 경우에 발생합니다. 지정된 정책이 아닌 다른 정책이 사용되고 있으면 조사해야 합니다.
**참고** 그룹 정책 설정에 대한 자세한 내용은 " [Security Policy Settings (영문)](https://technet2.microsoft.com/windowsserver/en/library/bcd7ea4c-f989-4cee-969a-920f62f555111033.mspx?mfr=true) " 섹션(https://technet2.microsoft.com/WindowsServer/en/library/bcd7ea4c-f989-4cee-969a-920f62f555111033.mspx?mfr=true)을 참조하십시오. ###### 자격 증명 손상 시도 공격자는 사용자 계정 자격 증명을 얻기 위해 사전 공격에서 사회 공학적인 방법에 이르기까지 몇 가지 접근 방식을 사용할 수 있습니다. 가장 잘 알려진 접근 방식은 단일 계정에 대한 사전 공격이지만, 사전 서비스 데이터베이스의 모든 계정에 대해 일련의 암호를 사용하는 또 다른 일반적인 접근 방식도 있습니다. 후자의 경우에는 공격자가 조직의 디렉터리 데이터베이스에 액세스할 수 있거나 사용자 이름을 추측하고 직원 목록을 보유하고 있을 가능성이 높습니다. 이러한 유형의 공격을 탐지하려면 계정 잠금 임계값이 트리거되지 않더라도 다수의 계정에 대한 여러 번의 로그온 실패를 감지할 수 있는 기능이 필요합니다. 암호 재설정은 계정 자격 증명 정보에 대한 제어 권한을 얻기 위한 또 하나의 방법입니다. 암호 재설정 또는 변경 작업은 성공 및 실패 모두에 대해 동일한 이벤트를 생성하기 때문에 공격자는 계정 잠금 정책을 회피하여 탐지를 벗어날 수 있습니다. 이러한 시도를 저지하려면 보안 모니터링 솔루션에서 여러 번의 암호 변경이나 재설정 시도를 식별할 수 있어야 합니다. 특히 설정된 정책 및 비즈니스 프로세스 프레임워크 외부에서 발생하는 시도를 반드시 식별해야 합니다. 암호 순환 사용은 사용자가 스크립트를 사용하여 여러 개의 암호를 차례대로 사용했다가 원래 암호부터 다시 사용함으로써 암호 재사용 정책을 회피하려 할 때 발생하며, 이러한 암호 순환 사용은 공격은 아니지만 여전히 보안을 위협하고 있습니다. 암호 순환 사용 시 암호 재설정 횟수는 암호 재사용 임계값과 거의 비슷하므로 일련의 627 이벤트로 나타납니다. 암호 최소 사용 기간 정책을 구현하면 이러한 시도를 저지할 수 있습니다. 다음 표는 인증 자격 증명에 대한 공격 시도로 인해 발생할 수 있는 이벤트의 목록이며, 이러한 이벤트는 합법적인 사용자가 암호를 잊어버리는 경우와 같이 정상적인 네트워크 작업 중에도 발생할 수 있습니다. **표 16. 인증 자격 증명 공격 이벤트**

이벤트 ID 발생 이벤트 설명
529 로그온 실패 – 알 수 없는 사용자 이름 또는 암호 대상 계정 이름이 Administrator이거나 암호 변경 권한이 부여되지 않은 다른 관리 수준 계정인 로그온 시도를 확인하십시오. 또한 잠금 임계값보다 낮은 다수의 로그온 실패를 확인하고, 이벤트 529 및 이벤트 539와 연결하여 연속 계정 잠금 패턴을 식별하십시오.
534 로그온 실패 – 허용되지 않은 로그온 유형 사용자가 네트워크, 대화형, 배치 또는 서비스 등 허용되지 않는 계정 유형을 사용하여 로그온하려 했음을 나타냅니다. 대상 계정 이름, 워크스테이션 이름 및 로그온 유형 필드를 확인하십시오.
539 계정 잠김 잠겨 있는 계정을 사용하여 로그온을 시도했음을 나타냅니다. 이벤트 529에 연결하여 연속 잠금 패턴을 확인하십시오.
553 재생 공격 탐지됨 Kerberos 같은 인증 패키지에서 사용자 자격 증명 재생을 통한 로그온 시도를 감지했음을 나타냅니다. 이 이벤트는 잘못된 네트워크 구성을 나타낼 수도 있지만 여하튼 즉시 조사해야 합니다.
627 암호 변경 시도 기존 계정 이름 필드가 대상 계정 이름 필드와 일치하지 않는 경우 계정 소유자가 아닌 사용자가 암호를 변경하려 했음을 나타냅니다.
628 사용자 계정 암호 설정 또는 재설정 이 활동을 지원 센터 계정 또는 사용자 셀프 서비스 암호 재설정 계정 등 권한이 있는 계정으로만 제한해야 합니다.
644 사용자 계정이 자동으로 잠김 연속 로그온 실패 시도 횟수가 계정 잠금 제한을 초과하여 계정이 잠겼음을 나타냅니다. 이벤트 529, 675, 681 및 676과 연결합니다(Windows 2000 Server에만 해당). 이 표의 이벤트 12294에 대한 항목도 참조하십시오.
675 사전 인증 실패 도메인에 가입되지 않은 컴퓨터 계정을 나타내거나 시간 동기화 문제를 나타냅니다. 이벤트 529와 연결하여 정확한 로그온 실패 이유를 찾아내십시오.
12294 계정 잠금 시도 기본 관리자 계정에 대한 Brute Force 공격이 발생한 것일 수 있음을 나타냅니다. 이 계정에는 계정 잠금 정책이 적용되지 않기 때문에 시스템 이벤트 로그에 SAM 이벤트 12294로 기록됩니다. 권한이 없는 운영 체제의 사용을 나타낼 수도 있으므로 이 이벤트 항목을 모두 조사해야 합니다. 알 수 없는 도메인의 도메인 이름 필드 확인
###### 취약점 악용 취약점은 모든 컴퓨터에 존재하며 개선하는 데 시간과 노력이 필요하기 때문에 공격자가 침입 시도 시 악용할 수 있는 주요 대상입니다. 취약점 발견 시점과 이러한 취약점을 악용하는 방법이 개발되는 시점 사이의 기간을 취약점 대 악용 기간이라고 하는데, 이 기간은 시간이 지남에 따라 점점 단축되고 있습니다. 또한 그에 따라 이러한 취약점을 보완할 패치를 개발, 테스트 및 배포하는 데 드는 시간도 짧아지고 있습니다. 취약점 악용에 대한 최선의 방어책은 여전히 환경 내에서 보안 업데이트를 신속하게 테스트 및 배포하는 효과적인 패치 관리 프로세스입니다. Microsoft SMS(Systems Management Server) 2003 또는 WSUS(Windows Software Update Service)는 이 프로세스를 지원할 수 있는 일부 서비스에 속합니다. 경계 네트워크에 있는 컴퓨터는 공격자가 가장 손쉽게 접근할 수 있으므로 이 문제와 관련하여 경계 네트워크에 대한 보안 모니터링에 특히 신경을 써야 합니다. 발생하는 공격을 탐지하기 위한 메커니즘을 사용하지 않을 경우 조직에서는 네트워크가 손상될 때까지 어떤 문제가 발생했는지를 알아낼 수 없습니다. 따라서 경계 네트워크에 있는 컴퓨터에 대해 다양한 감사 이벤트를 신중하게 모니터링하는 일은 매우 중요합니다. 앞에서 설명했던 이벤트 외에도, "자격 증명 손상 시도" 섹션에서 다룬 중요한 이벤트에는 무단 액세스 시도와 권한이 있는 ID의 사용도 있습니다. 다음 표는 이러한 공격을 식별할 수 있는 주요 이벤트의 목록입니다. **표 17. 권한 상승 취약점의 악용으로 인해 발생하는 취약점 이벤트**

이벤트 ID 발생 이벤트 설명
528 538 로컬 로그온 및 로그오프 이러한 이벤트가 경계 네트워크에서 발생할 경우 로그온 ID 필드와 연결합니다. 사용자 계정 이름, 시간 또는 워크스테이션 이름 필드에 예기치 않은 값이 포함되어 있으면 즉시 조사해야 합니다.
551 사용자가 로그오프 시도 토큰 누출로 인해 이벤트 538을 감사할 수 없지만 대신에 이벤트 551이 발생하므로 이 이벤트를 이벤트 538로 간주할 수 있습니다.
576 권한이 있는 로그온 관리자 계정 로그온 또는 TCP(신뢰할 수 있는 컴퓨팅 기초)를 조작할 수 있는 권한이나 Windows Server 2003 SP1 이상의 컴퓨터를 인계할 수 있는 권한을 가진 계정 로그온을 나타냅니다. 이전 버전의 Windows에서는 SeSecurityPrivilege 또는 SeDebugPrivelege 등 주요 권한과 관련된 경우에만 이 이벤트에 관심을 가졌습니다.
**참고** Windows Server 2003 이전 버전에서는 이벤트 576이 권한이 있는 사용 범주에 표시됩니다. 하지만 Windows Server 2003 이상에서는 로그온 범주에도 이 이벤트가 표시됩니다. 따라서 두 범주 중 하나와 관련된 감사 설정을 구성하면 이 이벤트가 표시됩니다. ###### 감사 회피 시도 비즈니스 네트워크 공격에 사용할 수 있는 방법이 다양한 것처럼, 이러한 시도를 숨기고 검색을 회피할 수 있는 기술도 다양합니다. 예를 들어, 공격자는 손상된 시스템이나 도메인에서 보안 정책을 변경하여 이벤트 로그가 의심스러운 활동을 기록하지 못하게 하거나 보안 로그를 고의적으로 삭제하여 감사된 정보를 검토하지 못하게 할 수 있습니다. 이러한 기술을 사용하여 보안 모니터링 솔루션을 회피하려는 시도를 감지할 수는 있지만, 침입 활동 추적을 숨기려는 시도 중에 발생할 수 있는 많은 동일한 이벤트가 일반적인 비즈니스 네트워크에서 정기적으로 발생하는 이벤트에 해당하므로 감지하기가 쉽지 않습니다. 다음 표에 나와 있는 여러 이벤트 유형을 확인하면 보안 위반 증거를 은폐하려는 공격자에 의한 회피 시도를 손쉽게 식별할 수 있습니다. **표 18. 이벤트 감사 회피 이벤트**

이벤트 ID 발생 이벤트 설명
512 Windows 시작 일반적으로 이벤트 513 이후에 발생합니다. 이 경우 예기치 않은 다시 시작을 조사해야 합니다.
513 Windows 시스템 종료 일반적으로 이벤트 512 전에 발생합니다. 고부가가치 컴퓨터는 권한이 있는 사용자만이 설정된 변경 제어 절차나 다른 절차에 따라 다시 시작해야 합니다. 어떤 서버에서든 이 이벤트가 발생할 경우 즉시 조사해야 합니다.
516 감사 실패 이 이벤트는 이벤트 수가 너무 많아 이벤트 로그 버퍼 용량이 부족하거나 보안 로그가 덮어쓰도록 설정되어 있지 않은 경우에 발생할 수 있습니다. 대부분의 컴퓨터에서는 모니터링되는 이벤트 유형을 제한하여 이러한 문제를 방지할 수 있지만, 고부가가치 컴퓨터나 취약한 컴퓨터는 보안을 위해 보다 철저하고 신중하게 모니터링해야 합니다.
517 보안 이벤트 로그 지우기 권한이 없는 경우에는 보안 이벤트 로그를 지울 수 없도록 해야 합니다. 클라이언트 사용자 이름 및 클라이언트 도메인 필드를 확인하여 권한이 있는 사용자와 절차가 승인된 레코드를 서로 연결하십시오.
520 시스템 시간 변경 이 작업을 통해 정밀 분석을 잘못된 방향으로 이끌거나 공격자에게 거짓 알리바이를 제공할 수 있습니다. 클라이언트 사용자 이름 및 클라이언트 도메인 필드를 확인하여 권한이 있는 사용자와 서로 연결하고, 프로세스 이름이 %windir%\system32\svchost.exe로 표시되어 있는지도 확인하십시오.
521 이벤트 기록 불가능 Windows에서 이벤트 로그에 이벤트를 쓸 수 없는 경우에 발생합니다. 이 이벤트가 모든 고부가가치 시스템에서 발생할 때마다 조사해야 합니다.
608 사용자 계정 권한이 할당됨 새 권한이 사용자 계정에 할당되는 경우에 발생합니다. 이벤트 로그는 사용자 계정 이름이 아닌 사용자 계정 SID(보안 식별자)와 함께 이 동작을 기록합니다.
609 사용자 계정 권한이 제거됨 사용자 계정에서 권한이 제거된 경우에 발생합니다. 이벤트 로그는 사용자 계정 이름이 아닌 사용자 계정의 SID와 함께 이 동작을 기록합니다.
612 감사 정책 변경 이 이벤트가 발생했다고 해서 반드시 문제가 있는 것으로 단정할 수는 없지만 공격자가 공격의 일환으로 감사 정책을 수정할 수 있습니다. 고부가가치 컴퓨터와 도메인 컨트롤러에서 이 이벤트를 모니터링해야 합니다.
621 시스템 액세스 권한이 계정에 부여됨 사용자에게 시스템에 대한 액세스 권한이 부여된 경우에 발생합니다. 액세스 권한이 대화형으로 표시되는 경우 사용자 이름 및 수정된 계정 필드를 확인해야 합니다.
622 시스템에서 시스템 액세스 권한이 제거됨 이 이벤트는 공격자가 이벤트 621과 관련된 증거를 제거하려고 했거나 다른 계정에 대해 서비스 거부를 시도하고 있음을 나타낼 수 있습니다.
643 도메인 보안 정책 변경 암호 정책이나 기타 도메인 보안 정책 설정을 수정하려는 시도가 있을 경우 발생합니다. 사용자 이름을 확인하고 권한 부여 레코드와 연결하십시오.
##### 정밀 분석 정밀 분석은 이 문서에 설명된 다양한 요소를 활용하지만, 보안 정보의 저장 및 분석에 중점을 두며 공격 발생 이후의 상황에 대처하는 데 사용되기 때문에 앞에서 설명했던 다른 모니터링 및 공격 탐지 솔루션과는 기본적으로 다릅니다. 대부분의 정밀 분석은 특정 사용자 또는 시스템과 관련된 이벤트 목록으로 시작됩니다. 정밀 분석을 위한 보안 모니터링을 수행하려면 다음 요소가 필요합니다. - 보관되어 있는 선택된 이벤트 유형 - 매일 발생하는 예상 이벤트 수 - 온라인, 오프라인 및 보관 저장소에 대한 시간 제한 설정 - 예상 이벤트 수를 처리할 수 있을 만한 규모의 데이터베이스 - 예상 일일 이벤트 로드를 처리할 수 있는 백업 시스템 - 보관 시스템 관리에 관한 정책 설정 정밀 분석 프로그램의 저장소 요구 사항은 다음 세 가지 주요 요인에 따라 결정됩니다. - 기록해야 할 이벤트 수 - 이러한 이벤트가 대상 컴퓨터에서 생성되는 비율 - 가용성을 제공하는 온라인 저장 기간 이전 섹션에서 설명한 내용과 비즈니스 요구를 잘 이해하면 이러한 세 가지 요인을 정확히 판단하여 적절한 저장소 요구 사항을 얻을 수 있습니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 요약 오늘날의 네트워크 환경에서 효과적이고 포괄적인 보안 모니터링 및 공격 탐지 솔루션이 모든 중소 기업에 더 이상 선택이 아닌 필수 요소라는 것은 명백한 사실입니다. 비즈니스 네트워크에서 발생할 수 있는 위협과 위험은 셀 수 없이 많으며, 여기에는 경계 외부에서 발생하는 위협은 물론 고의적 및 우발적인 형태의 내부 위협도 포함됩니다. 적절히 구현된 보안 모니터링 시스템에서는 모든 위험을 고려하는 것은 물론, 현재 비즈니스 네트워크 아키텍처와 해당 네트워크 시스템의 데이터를 위험에 빠뜨릴 수 있는 잠재적인 위협 및 활동의 특징까지도 철저하게 파악해야 합니다. Microsoft에서는 보안을 매우 중요한 부분으로 인식하고 있으며, 그에 따라 효과적인 보안 모니터링 및 공격 탐지 시스템을 구축하는 데 유용하게 사용할 수 있는 많은 도구를 선보이고 있습니다. Windows Server 2003 및 기타 Windows 버전 운영 체제에서는 이러한 보안 모니터링 솔루션의 기초로 보안 감사 로깅 기능을 기본적으로 제공합니다. 이 기능을 Microsoft Operations Manager 및 EventCombMT 등의 다른 구성 요소, 필수 비즈니스 정책 및 프로세스와 함께 사용하면 포괄적인 모니터링 시스템을 개발할 수 있습니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 부록 A: 불필요한 이벤트 제외 다음 표에 나열된 이벤트는 발생 빈도가 높고 보안 모니터링 솔루션에 포함될 경우 대체로 유용한 결과를 제공하지 않기 때문에 일반적으로 보안 모니터링 쿼리에서 제외됩니다. **표 A1. 불필요한 이벤트**

이벤트 ID 발생 이벤트 설명
538 사용자 로그오프 이 이벤트 발생 시간이 항상 사용자가 시스템의 사용을 중지한 시간을 나타내는 것은 아닙니다. 예를 들어, 컴퓨터가 종료되거나 네트워크 연결이 끊긴 경우 로그오프 이벤트가 기록되지 않을 수도 있습니다.
562 개체 핸들 닫힘 항상 성공으로 기록됩니다.
571 클라이언트 컨텍스트가 권한 부여 관리자에 의해 삭제됨 권한 부여 관리자를 사용하고 있는 경우에 발생합니다.
573 프로세스에서 AuthZ API(권한 부여 응용 프로그래밍 인터페이스)를 사용하여 비시스템 감사 이벤트 생성 예상된 활동입니다.
577
578		 권한이 있는 서비스 호출됨, 권한이 있는 개체 작업 발생되는 이벤트가 많지만, 일반적으로 이러한 이벤트에서는 발생한 작업을 설명하지 않으므로 동작을 파악하기에는 정보가 부족합니다.
594 개체 핸들이 복제됨 예상된 활동입니다.
595 개체에 대한 간접 액세스 권한 획득 예상된 활동입니다.
596 데이터 보호 마스터 키 백업 예상된 활동입니다. 기본 설정 내에서 90일마다 발생합니다.
597 데이터 보호 마스터 키 복구 예상된 활동입니다.
672 Kerberos AS 티켓 요청 로그온 이벤트 528 및 540의 감사 세부 정보를 이미 수집하고 있는 경우 추가 정보를 포함하지 않습니다. 이 이벤트는 Kerberos TGT가 부여되었음을 기록할 뿐, 실제 액세스는 이벤트 673을 통해 감사되는 서비스 티켓이 부여될 때까지 발생하지 않습니다. PATYPE이 PKINIT이면 스마트 카드를 통해 로그온되었음을 의미합니다.
680 계정 로그온 다른 이벤트를 통해 이미 기록된 활동
697 암호 정책 확인 API 호출됨 예상된 활동입니다.
768 포리스트 네임스페이스 충돌 이 이벤트는 보완과 관련이 없습니다.
769
770
771		 신뢰할 수 있는 포리스트 정보가 추가, 삭제 또는 수정됨 예상된 활동입니다. 트러스트 자체를 추가, 수정 또는 삭제하는 이벤트와 이 이벤트를 혼동해서는 안 됩니다.
832
833
834
835
836
837
838
839
840
841		 다양한 Active Directory 복제 이벤트 이 이벤트는 보안과 관련이 없습니다.
**참고** 감사에서 특정 정보를 제외할 경우 몇 가지 위험이 따르지만 이 정도의 위험은 분석 에이전트의 로드를 줄였을 때의 이점에 비하면 감수해도 무방한 수준입니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 부록 B: 그룹 정책 설정 구현 이 부록의 내용을 참조하여 환경에서 현재 설정을 확인할 수 있습니다. 이 부록에는 보안 모니터링 및 공격 탐지에 영향을 주는 추가 설정이 포함됩니다. 그룹 정책 보안 감사 이벤트를 올바르게 구성하려면 다음 표의 설정을 적용해야 합니다. **표 B1. 그룹 정책 보안 감사 설정**

정책 경로 정책 정책 설정 및 설명
로컬 정책/감사 정책 감사 계정 로그온 이벤트 이 이벤트는 컴퓨터에 액세스한 사용자를 기록하므로 모든 컴퓨터에 대해 감사 성공을 사용하십시오. 네트워크 액세스 권한은 있지만 자격 증명이 없는 공격자가 이러한 이벤트가 기록되는 동안 컴퓨터에서 리소스를 소비하도록 하여 서비스 거부(DoS) 공격을 개시할 수 있으므로 감사 실패를 사용할 때는 각별히 주의해야 합니다. 로그 공간이 부족할 경우 컴퓨터가 종료되도록 설정된 경우 감사 성공을 사용하면 DoS 공격이 발생할 수도 있으므로 이에 대해서도 각별히 주의해야 합니다. 관리자 로그온과 다른 의심스러운 항목을 연결하십시오.
로컬 정책/감사 정책 감사 계정 관리 성공 및 실패 이벤트를 모두 사용하십시오. 모든 감사 성공 항목을 관리자 권한과 연결하십시오. 실패는 모두 의심스러운 활동으로 간주해야 합니다.
로컬 정책/감사 정책 감사 디렉터리 서비스 액세스 기본 도메인 컨트롤러 그룹 정책에 따라 이 설정은 기본적으로 사용됩니다. Active Directory 사용자 및 컴퓨터 또는 ADSI Edit(Active Directory 서비스 인터페이스 편집기)에서 SACL(시스템 액세스 제어 목록)을 사용하여 중요 디렉터리 개체에 대한 감사 설정을 구성하십시오. SACL의 구현을 계획한 후 프로덕션 환경에 배포하기 전에 실제 테스트 환경에서 SACL을 테스트해야 합니다. 이 접근 방식을 사용하면 데이터가 너무 많아서 보안 로그가 오버로드되는 것을 방지할 수 있습니다.
로컬 정책/감사 정책 감사 로그온 이벤트 이 이벤트는 컴퓨터에 액세스한 사용자를 기록하므로 모든 컴퓨터에 대해 감사 성공을 사용하십시오. 네트워크 액세스 권한은 있지만 자격 증명이 없는 공격자가 과도한 실패를 생성하여 DoS 상황을 일으킬 수 있으므로 각별히 주의하여 감사 실패를 사용하십시오.
로컬 정책/감사 정책 감사 개체 액세스 이 설정을 사용할 때는 감사 볼륨이 너무 커질 수 있으므로 각별히 주의하십시오. SACL를 통해 고부가가치 폴더에 대해서만 감사 설정을 구성하고 해당되는 특정 액세스 유형에 대해서만 감사를 수행하십시오. 가능한 한 쓰기 이벤트만 감사하고 읽기 액세스 이벤트는 감사하지 마십시오.
로컬 정책/감사 정책 감사 정책 변경 감사 성공 및 실패를 모두 사용하십시오. 성공 이벤트를 관리자 권한과 연결하십시오.
로컬 정책/감사 정책 감사 권한 사용 이 구성에서는 매우 많은 이벤트가 생성되므로 권한 사용에 대한 감사는 사용하지 마십시오.
로컬 정책/감사 정책 감사 프로세스 추적 취약한 컴퓨터에 대해 이 설정을 사용하고 필요할 경우 시스템을 분리하여 예기치 않은 응용 프로그램의 실행을 즉시 조사하십시오. 이 설정으로 인해 이벤트 로그 공간이 부족해질 수 있으므로 CGI(Common Gateway Interface) 웹 서버, 테스트 시스템, 배치 프로세스를 실행하는 서버 또는 개발자 워크스테이션에서는 이 설정을 사용하지 미십시오.
로컬 정책/감사 정책 감사 시스템 이벤트 감사 성공 및 실패를 모두 사용하십시오.
로컬 정책/사용자 권한 할당 보안 감사 생성 이 설정은 기본적으로 로컬 시스템, 로컬 서버 및 네트워크 서비스에 할당됩니다. 이 권한은 서비스 계정 이외의 어떤 계정에도 적용해서는 안 됩니다. 공격자는 이 설정을 사용하여 보안 로그에 가짜 이벤트나 부정확한 이벤트를 생성할 수 있습니다.
로컬 정책/사용자 권한 할당 감사 및 보안 로그 관리 이 설정을 사용하면 관리자가 파일, 폴더 및 레지스트리에 대한 감사 설정을 변경하지 못하게 할 수 있습니다. 감사 설정을 변경하고 로컬 보안 정책 설정에서 관리자 그룹을 제거할 수 있는 권한을 가진 관리자 보안 그룹을 만드는 방법을 고려해 보십시오. 보안 그룹의 구성원만이 감사를 구성할 수 있도록 해야 합니다.
로컬 정책/보안 옵션 감사: 글로벌 시스템 개체 액세스 감사 이 설정은 뮤텍스, 세마포 및 MS-DOS 장치와 같은 명명된 시스템 개체에 SACL을 추가합니다. Windows Server 2003에서는 기본적으로 이 옵션을 사용하지 않습니다. 이 설정을 사용하면 이벤트 수가 너무 많아지므로 사용하지 마십시오.
로컬 정책/보안 옵션 감사: 백업 및 복원 권한 사용 감사 백업 및 복원 작업은 ACL을 회피하여 데이터를 도용할 수 있는 기회를 제공합니다. 이 설정을 사용하면 이벤트 수가 너무 많아지므로 사용하지 마십시오.
로컬 정책/보안 옵션 감사: 보안 이벤트를 기록할 수 없는 경우 즉시 시스템 종료 공격자가 이 설정을 사용하여 DoS 공격을 시도할 수 있으므로 신중히 고려한 후 고부가가치 컴퓨터에 대해서만 사용하십시오.
이벤트 로그 최대 보안 로그 크기 권장 설정은 예상 이벤트 볼륨과 보안 로그 보존 설정에 따라 결정됩니다. 이 설정은 64KB씩만 늘릴 수 있으며 평균 이벤트 크기는 0.5KB입니다. 고용량 환경에서는 이 설정을 250MB 정도로 높게 구성할 수 있지만 모든 이벤트 로그의 총 크기는 300MB를 초과할 수 없습니다.
이벤트 로그 로컬 게스트 그룹의 보안 로그 액세스 금지 이 설정은 Windows Server 2003에서 기본적으로 사용되며 변경해서는 안 됩니다.
이벤트 로그 보안 로그 유지 선택한 보존 방법이 “매일 이벤트 덮어쓰기”인 경우에만 이 설정을 사용하십시오. 이벤트를 폴링하는 이벤트 상관 관계 시스템이 사용되는 경우 기간은 폴링 주기 실패에 사용할 폴링 빈도의 3배 이상입니다.
이벤트 로그 보안 로그 보존 방법 보안 수준이 높은 환경에서는 이벤트 덮어쓰지 않음 설정을 사용하십시오. 이에 해당되는 경우 특히 보안 감사를 기록할 수 없는 경우 즉시 시스템 종료를 사용하는 경우에는 로그를 정기적으로 비우고 보관하는 절차를 설정하십시오.
[](#mainsection)[페이지 위쪽](#mainsection) **다운로드** [보안 모니터링 및 공격 탐지 문서 보기 (영문)](https://go.microsoft.com/fwlink/?linkid=71717) [](#mainsection)[페이지 위쪽](#mainsection)
  • Last updated on