네트워크 분석 및 침입 정책은 침입 탐지 및 방지 기능의 일부로 함께 작동합니다.

• 침입 탐지란 용어는 일반적으로 네트워크 트래픽에서 잠재적인 침입을 수동적으로 모니터링 및 분석하고 보안 분석을 위한 공격 데이터를 저장하는 프로세스를 말합니다. 'IDS'라고 하기도 합니다.

• 침입 방지란 용어에는 침입 탐지의 개념이 포함되지만, 악성 트래픽이 네트워크를 통과할 때 이를 차단 또는 변경하는 기능이 추가됩니다. 'IPS'라고 하기도 합니다.

침입 방지 구축에서 시스템이 패킷을 검토할 때:

• 네트워크 분석 정책은 특히 침입 시도의 신호가 될 수 있는 변칙 트래픽을 향후에 평가할 수 있도록 트래픽을 해독하고 전처리하는 방법을 제어합니다.

• 침입 정책은 침입 및 전처리 규칙(집합적으로 침입 규칙이라고도 함)을 사용하여 패턴 기반의 공격에 대한 디코딩된 패킷을 검사합니다. 침입 정책은 변수 집합과 페어링되는데, 이를 통해 네트워크 환경을 올바르게 반영하는 지정된 값을 사용할 수 있습니다.

네트워크 분석과 침입 정책 모두 상위 액세스 제어 정책에 의해 호출되지만 그 시점은 다릅니다. 시스템이 트래픽을 분석하기 때문에, 네트워크 분석(디코딩 및 전처리) 단계는 침입 방지(추가 전처리 및 침입 규칙) 단계보다 이전에 또는 별도로 발생합니다. 네트워크 분석 및 침입 정책은 폭넓고 심층적인 패킷 검사를 제공합니다. 이 둘을 함께 사용하면 호스트 및 호스트 데이터의 가용성, 무결성 및 기밀성을 위협할 수 있는 네트워크 트래픽을 탐지하고 알리고 방지할 수 있습니다.

시스템에서는 상호 보완하고 함께 작동하는 비슷한 이름의 여러 네트워크 분석 및 침입 정책(예: Balanced Security and Connectivity)을 제공합니다. 시스템이 제공하는 정책을 사용하면 Cisco Talos(Talos Intelligence Group)의 경험을 활용할 수 있습니다. Talos는 이 정책에 대해 침입 및 검사기 규칙 상태뿐 아니라 검사기의 초기 구성과 기타 고급 설정을 제공합니다.

또한 사용자 지정 네트워크 분석 및 침입 정책을 만들 수 있습니다. 사용자 지정 정책의 설정을 조정하여 가장 중요하다고 생각되는 방식으로 트래픽을 검사할 수 있으며, 따라서 매니지드 디바이스의 성능과 디바이스가 생성하는 이벤트에 효과적으로 대응하는 능력 모두를 향상시킬 수 있습니다.

웹 인터페이스에서 유사한 정책 편집기를 사용하여 네트워크 분석 및 침입 정책을 생성, 수정, 저장 및 관리합니다. 정책 유형 중 하나를 수정할 때 탐색 패널이 웹 인터페이스의 왼쪽에 표시되며, 오른쪽에는 다양한 구성 페이지가 표시됩니다.

추가 지원 및 정보는 다음 비디오를 참조하십시오.

• Snort 3 요약 개요

• Snort 3 확장 개요

Snort 검사 엔진은 Secure Firewall Threat Defense (이전 명칭: Firepower Threat Defense) 디바이스의 필수 요소입니다. 검사 엔진은 트래픽을 실시간으로 분석하여 심층 패킷 검사를 제공합니다. 네트워크 분석 및 침입 정책은 Snort 검사 엔진의 기능을 활용하여 침입을 탐지하고 보호합니다.

Snort 3는 Snort 검사 엔진의 최신 버전으로 이전 버전의 Snort와 비교하여 크게 개선되었습니다. Snort의 이전 버전은 Snort 2입니다. Snort 3는 더 효율적이며 더 우수한 성능과 확장성을 제공합니다.

Snort 3는 Snort 2에 비해 동일한 리소스로 더 많은 트래픽을 검사하도록 아키텍처가 재설계되었습니다. Snort 3를 사용하면 트래픽 파서를 간단하고 유연하게 삽입할 수 있습니다. 또한 Snort 3의 새로운 규칙 syntax(명령문)를 통해 규칙을 더 쉽게 작성하고 해당하는 공유 개체 규칙을 볼 수 있습니다.

이 밖에 Snort 3의 중요한 변경 사항은 다음과 같습니다.

• 여러 Snort 인스턴스를 사용하는 Snort 2와 달리 Snort 3는 여러 스레드를 단일 Snort 인스턴스와 연결합니다. 이렇게 하면 메모리가 줄어들고 Snort 다시 로드 시간이 개선되며 더 많은 침입 규칙과 더 큰 네트워크 맵이 지원됩니다. Snort 스레드의 수는 플랫폼에 따라 다르며 각 플랫폼의 Snort 2 인스턴스 수와 동일합니다. 사용량은 거의 투명합니다.

• 위협 방어별 Snort 버전 - Snort 검사 엔진은 위협 방어에 고유하며, Secure Firewall Management Center(이전 명칭: Firepower Management Center)에는 고유하지 않습니다. Management Center에서는 여러 위협 방어를 관리할 수 있으며, 각각 Snort 버전 Snort 2 및 Snort 3를 사용합니다. management center의 침입 정책은 고유하지만, 시스템은 디바이스의 선택한 검사 엔진에 따라 침입 방지를 위해 Snort 2 또는 Snort 3 버전의 침입 정책을 적용합니다. 디바이스의 검사 엔진에 대한 자세한 내용은 Snort 3 검사 엔진의 내용을 참조하십시오.

• 디코더 규칙 - 패킷 디코더 규칙은 기본 침입 정책에서만 실행됩니다. 시스템은 다른 정책에서 활성화한 디코더 규칙을 무시합니다.

• 공유 개체 규칙 - Snort 3에서는 일부 공유 개체(SO) 침입 규칙(GID(제너레이터 ID)가 3인 규칙)을 지원하지는 않습니다. 지원되지 않는 활성화된 공유 개체 규칙은 트리거되지 않습니다.

• 보안 인텔리전스를 위한 멀티 레이어 검사 - Snort 2는 멀티 레이어 트래픽에서 2개의 레이어를 검사합니다. Snort 3는 레이어에 관계없이 가장 안쪽 IP 주소를 탐지합니다.

• 플랫폼 지원 - Snort 3는 threat defense 7.0 이상이 필요합니다. ASA FirePOWER 또는 NGIPSv에서는 지원되지 않습니다.

• 매니지드 디바이스 - 7.0 버전의 management center는 버전 6.4, 6.5, 6.6, 6.7 및 7.0 Snort 2 위협 방어와 버전 7.0 Snort 3 위협 방어를 동시에 지원할 수 있습니다.

• Snort 버전 전환 시 트래픽 중단 - Snort 버전을 전환하면 트래픽 검사가 중단되고 구축 중에 일부 패킷이 삭제될 수 있습니다.

• 일관된 정책 - 매니지드 위협 방어에 활성화된 기본 Snort 엔진 버전에 관계없이 management center에 구성된 액세스 제어 정책, 침입 정책 및 네트워크 분석 정책은 정책 적용 시 원활하게 작동합니다. management center 7.0 이상 버전의 모든 침입 정책에는 Snort 2 버전과 Snort 3 버전의 두 가지 버전이 있습니다. 침입 정책은 일관적입니다. 즉, 두 가지 버전의 정책(Snort 2 버전 및 Snort 3 버전)이 있더라도 공통 이름, 기본 정책 및 검사 모드를 사용한다는 점에서 일관됩니다. 침입 정책의 Snort 2 버전과 Snort 3 버전은 규칙 설정 측면에서 다를 수 있습니다. 그러나 침입 정책이 디바이스에 적용되면 시스템은 디바이스에서 활성화된 Snort 버전을 자동으로 식별하여 해당 버전에 대해 구성된 규칙 설정을 적용합니다.

• LSP(Lightweight Security Package) - Snort 3 차세대 침입 규칙 및 구성 업데이트를 위해 SRU(Snort 규칙 업데이트)를 교체합니다. 업데이트를 다운로드하면 Snort 3 LSP 및 Snort 2 SRU가 모두 다운로드됩니다.

  management center 및 위협 방어 7.0 이상 버전에서 LSP 업데이트는 새로운 침입 규칙과 업데이트된 침입 규칙 및 검사기 규칙, 기존 규칙의 수정된 상태, 수정된 기본 침입 정책 설정을 제공합니다. management center를 6.7 이하 버전에서 7.0 버전으로 업그레이드하면 LSP와 SRU가 모두 지원됩니다. 또한 LSP 업데이트는 시스템 제공 규칙을 삭제하고, 새로운 규칙 범주와 기본 변수를 제공하며, 기본 변수 값을 변경할 수 있습니다. LSP 업데이트에 대한 자세한 내용은 최신 버전의 Firepower Management Center 구성 가이드에 있는 침입 규칙 업데이트 항목을 참조하십시오.

• Snort 2와 Snort 3 규칙 및 사전 설정 매핑 - Snort 2와 Snort 3 규칙은 매핑되며, 이 매핑은 시스템에서 제공됩니다. 그러나 이는 일대일 매핑이 아닙니다. 시스템에서 제공하는 침입 기반 정책은 Snort 2 및 Snort 3에 대해 미리 구성되어 있으며, 규칙 세트가 다르더라도 동일한 침입 방지 기능을 제공합니다. Snort 2 및 Snort 3에 대한 시스템 제공 기본 정책은 동일한 침입 방지 설정에 대해 서로 매핑됩니다. 자세한 내용은 Snort 2 및 Snort 3 기본 정책 매핑 보기를 참조하십시오.

• Snort 2 및 Snort 3 규칙 재정의 동기화 - 위협 방어를 7.0으로 업그레이드하는 경우 위협 방어의 검사 엔진을 Snort 3 버전으로 업그레이드할 수 있습니다. Management Center에서는 Talos에서 제공하는 매핑을 사용하여 침입 정책 내 Snort 2 버전의 기존 규칙에 있는 모든 재정의를 해당 Snort 3 규칙으로 매핑합니다. 그러나 업그레이드 후에 추가 재정의가 수행되거나 버전 7.0의 새 위협 방어를 설치한 경우 수동으로 동기화해야 합니다. 자세한 내용은 Snort 2 규칙과 Snort 3 동기화를 참고하십시오.

• 사용자 지정 침입 규칙 - Snort 3에서 사용자 지정 침입 규칙을 생성할 수 있습니다. 또한 Snort 2에 대해 존재하는 사용자 지정 침입 규칙을 Snort 3로 가져올 수 있습니다. 자세한 내용은 Snort 3의 사용자 지정 규칙를 참고하십시오.

• 규칙 그룹 - management center에서는 모든 Snort 3 규칙을 규칙 그룹으로 그룹화합니다. 규칙의 논리적 그룹인 규칙 그룹을 사용하면 간편한 관리 인터페이스를 통해 규칙 액세스 가능성과 규칙 탐색을 개선하고 규칙 그룹의 보안 수준을 보다 효과적으로 제어할 수 있습니다.

  management center 7.3.0부터는 여러 레벨의 규칙 그룹에 대한 규칙 탐색이 지원되어 보다 유연하고 논리적으로 규칙을 그룹화할 수 있습니다. MITER 프레임워크가 추가되어 MITER 프레임워크를 사용하여 규칙을 탐색할 수 있습니다. MITRE는 규칙 그룹의 또 다른 범주이며 Talos 규칙 그룹의 일부입니다.

  참고	MITRE에 대한 자세한 내용은 https://attack.mitre.org를 참조하십시오.

  규칙은 여러 MITRE ATT&CK 규칙 그룹, 규칙 범주 규칙 그룹, 여러 "자산 유형" 규칙 그룹, 악성코드 캠페인 등과 같은 다양한 규칙 그룹의 일부일 수 있습니다. 사용 가능한 규칙 그룹이 침입 정책 편집기에 나열되며 정책을 개선하도록 선택될 수 있습니다.

  이 다단계 계층 구조를 사용하면 마지막 요소인 "리프 규칙 그룹"까지 이동할 수 있습니다. 이러한 규칙 그룹은 특정 유형의 취약성, 유사한 대상 시스템 또는 유사한 위협 범주 등 서로 관련된 규칙 집합을 포함합니다. 규칙 그룹에는 4개의 보안 레벨이 연결되어 있습니다. 보안 레벨을 변경하거나 규칙 그룹을 추가 또는 제거할 수 있으며, 네트워크에 표시된 트래픽과 일치하는 규칙에 대한 규칙 작업을 변경할 수 있습니다. 이는 보안, 성능 및 오탐 방지 사이의 균형을 유지하기 위해 수행됩니다.

  Snort 3 침입 정책을 편집하려면 Snort 3 침입 정책 편집의 내용을 참조하십시오.

  침입 이벤트에서의 규칙 그룹 보고에 대해서는 규칙 그룹 보고의 내용을 참조하십시오.

• Snort 2 엔진과 Snort 3 엔진 간의 전환—Snort 3를 지원하는 위협 방어는 Snort 2도 지원할 수 있습니다. Snort 3에서 Snort 2로 전환하는 것은 효율성 측면에서 권장되지 않습니다. 그러나 전환이 필요한 경우 Snort 3 검사 엔진의 지침을 따르십시오.

  중요사항	Snort 버전을 자유롭게 전환할 수는 있지만 한 버전의 Snort 버전에서 침입 규칙 변경 사항이 다른 버전에서는 자동으로 업데이트되지 않습니다. 한 버전의 Snort에서 규칙에 대한 규칙 작업을 변경하는 경우 Snort 버전을 전환하기 전에 다른 버전의 변경 사항을 복제하십시오. 시스템에서 제공하는 동기화 옵션은 침입 정책의 Snort 2 버전에 대한 변경 사항을 Snort 3 버전으로 동기화하기만 하며 그 반대로는 동기화하지 않습니다.

시스템이 액세스 제어 배포의 일부로 트래픽을 분석할 때, 네트워크 분석(디코딩 및 전처리) 단계는 침입 방지(침입 규칙 및 고급 설정) 단계보다 이전에 또는 별도로 발생합니다.

다음 다이어그램은 인라인, 침입 방지 및 AMP for Networks 구축에서 트래픽 분석의 순서를 간소화된 형식으로 보여줍니다. 또한 액세스 제어 정책이 다른 정책을 호출하여 트래픽을 검토하는 방법 및 그러한 정책이 호출되는 순서를 보여줍니다. 네트워크 분석 및 침입 정책 선택 단계는 강조 표시됩니다.

인라인 구축(즉, 관련 설정을 라우팅, 스위칭 또는 투명한 인터페이스 또는 인라인 인터페이스 쌍을 사용하여 디바이스에 구축하는 경우)의 경우, 시스템은 예시된 프로세스의 거의 모든 단계에서 추가 검사 없이 트래픽을 차단할 수 있습니다. 보안 인텔리전스, SSL 정책, 네트워크 분석 정책, 파일 정책 및 침입 정책은 모두 트래픽을 삭제 또는 수정할 수 있습니다. 수동으로 패킷을 검사하는 네트워크 검색 정책만으로는 트래픽의 흐름에 영향을 줄 수 없습니다.

마찬가지로 프로세스의 각 단계에서 패킷은 시스템이 이벤트를 생성하도록 할 수 있습니다. 침입 및 프리프로세서 이벤트(침입 이벤트로 총칭)는 패킷 또는 패킷의 내용에 보안 위험이 있음을 나타내는 것입니다.

팁	다이어그램에는 SSL 검사 설정에서 암호화 트래픽의 통과를 허용하는 경우 또는 SSL 검사를 설정하지 않은 경우, 액세스 제어 규칙이 암호화 트래픽을 처리한다는 점이 반영되어 있지 않습니다. 기본적으로, 시스템에서는 암호화된 페이로드의 침입 및 파일 검사를 비활성화합니다. 이는 암호화 연결이 침입 및 파일 검사가 구성된 액세스 제어 규칙과 일치하는 경우 오탐을 줄이고 성능을 높이는 데 도움이 됩니다.

단일 연결의 경우, 다이어그램에 나타난 것처럼 시스템은 액세스 제어 규칙에 앞서 네트워크 분석 정책을 선택하지만, 일부 전처리(특히 애플리케이션 레이어 전처리)는 액세스 제어 규칙 선택 이후에 발생한다는 점에 유의하십시오. 이는 사용자 지정 네트워크 분석 정책에서 전처리를 구성하는 방식에 영향을 주지 않습니다.

새로운 액세스 제어 정책을 생성하는 것이 시스템을 사용하여 트래픽 플로우를 관리하는 첫 과정 중 하나입니다. 기본적으로, 새로 만든 액세스 제어 정책은 트래픽을 검토하기 위해 시스템 제공 네트워크 분석 및 침입 정책을 호출합니다.

다음 다이어그램은 인라인 침입 방지 배포에서 새로 만든 액세스 제어 정책이 트래픽을 초반에 처리하는 방식을 보여줍니다. 전처리 및 침입 방지 단계는 강조 표시됩니다.

다음 방식을 참고하십시오.

• 기본 네트워크 분석 정책이 액세스 제어 정책에서 처리된 모든 트래픽의 전처리를 제어하는 방식. 초기에는 시스템이 제공한 Balanced Security and Connectivity(균형 잡힌 보안 및 연결성) 네트워크 분석 정책이 기본값입니다.

• 액세스 제어 정책의 기본 작업은 시스템이 제공한 Balanced Security and Connectivity(균형 잡힌 보안 및 연결성)에 의해 결정된 대로 모든 비 악성 트래픽을 허용합니다. 기본 작업에서 트래픽 통과를 허용하므로 침입 정책이 악성 트래픽을 검사하고 잠재적으로 차단하기 전에 검색 기능이 트래픽에서 호스트, 애플리케이션, 사용자 데이터를 검사할 수 있습니다.

• 정책은 기본 보안 인텔리전스 옵션(전역 차단 및 차단 금지 목록)을 사용하고, SSL 정책 내에서 암호화된 트래픽을 해독하지 않으며, 액세스 제어 규칙을 사용하여 네트워크 트래픽의 특수 처리 및 검사를 수행하지 않습니다.

침입 방지 배포를 조정하기 위해 취할 수 있는 간단한 조치는 시스템 제공 네트워크 분석 및 침입 정책의 서로 다른 집합을 기본값으로 사용하는 것입니다. Cisco는 시스템에서 이러한 정책의 여러 쌍을 제공합니다.

또는, 사용자 지정 정책을 생성하고 사용하여 침입 방지 배포를 맞춤화할 수 있습니다. 검사기 옵션, 침입 규칙 및 이 정책에 구성된 기타 고급 설정으로 네트워크의 보안 요구를 해결할 수 없는 경우가 있을 수 있습니다. 네트워크 분석 및 침입 정책을 설정하여 시스템이 침입 탐지를 위해 네트워크에서 트래픽을 처리하고 검사하는 방식을 매우 세부적으로 구성할 수 있습니다.