Elastic SIEM 탐지
Elastic Security 7.6 릴리즈에서는, Elastic SIEM 탐지를 통해 SOC 팀에게 SIEM 규칙 환경을 제공하는 현대적인 탐지 엔진의 탄생을 소개합니다. 탐지 엔진은 Elasticsearch 분석 엔진을 위해 설계된 세트에서 가져와 Kibana의 새로운 분산 실행 플랫폼에서 실행됩니다. 이 포스팅에서는 Elastic SIEM의 탐지 흐름에 대한 간단한 개요를 알려드리고 이러한 탐지가 우리 사용자를 위해 원활하게 작동하도록 하는 데 도움이 되는 새로운 UI와 백엔드 기능에 대해 얘기해보겠습니다.
본격적으로 탐지에 대해 다루기 전에 먼저 잠깐 알려드리자면, SIEM 앱을 사용해볼 준비가 되신 경우, 저희 소기업과 가정용 SIEM 블로그 시리즈를 확인해 보세요. 이 시리즈는 저희의 무료 Elasticsearch Service 체험판으로 클라우드에서 설정하고 Beats를 사용해 여러분의 시스템에서 SIEM으로 안전하게 데이터를 수집하고 스트리밍하는 방법 등에 대해 다룹니다. (생각하시는 것보다 훨씬 더 쉽습니다!) 또한 하이브리드 배포를 위한 시작 안내서도 제공해드리고 있습니다.
신호 관리를 위한 UI 워크플로우
Elastic SIEM 탐지의 기본은 신호입니다. 이 신호는 신호 탐지 규칙 조건이 충족될 때 생성되는 Elasticsearch 문서입니다. 가장 간단한 사례에서는 규칙에서 정의된 쿼리와 일치하는 각 이벤트에 대해 하나의 신호 문서가 생성됩니다. 신호 문서는 일치하는 문서의 필드 사본을 포함하며, 별개의 신호 인덱스에 저장됩니다. 원래의 이벤트는 신호가 생성될 때 변경되지 않습니다.
신호는 SIEM 앱에서 표면화됩니다. 실무자가 처음 새로운 신호를 볼 때, 이 신호는 개방된 상태입니다. 분석을 하고 다음 단계를 결정한 후, 실무자는 이 신호를 닫힌 상태로 변경합니다. 이러한 모든 변경은 SIEM 앱의 Detections 보기에서 관리할 수 있습니다.
신호 수 히스토그램은 개방된 신호를 보여주며 다음과 같은 주요 속성에 대한 빠른 비교를 할 수 있게 해줍니다.
- 점수, 심각도, 유형, 이름 또는 MITRE ATT&CK™ 전술 이름
- 소스 또는 대상 IP 주소
- 이벤트 작업 또는 카테고리
- 호스트 또는 사용자 이름
타임라인에서 신호를 조사하는 것이 다음 단계입니다.
규칙을 생성할 때 타임라인 템플릿을 지정하지 않은 경우, 신호 문서로 타임라인이 채워집니다. 타임라인 템플릿을 지정한 경우, 사용자가 저장한 것으로 타임라인이 채워지게 되며, 특정 유형의 규칙에 대한 조사의 속도가 빨라집니다.
실무자는 전용 `외부 경보` 탭에서 Elastic Endpoint Security, Suricata, Zeek와 같은 외부 경보 시스템으로부터의 경보를 볼 수 있습니다. 또한 수많은 기업들이 가치가 높은 외부 경보를 위한 신호를 생성하는 규칙을 구현하여 신호를 위한 개선된 조사 워크플로우의 이점을 활용할 수 있도록 하고 있습니다.
분석가가 만족할 정도로 하나의 신호나 신호 세트를 조사한 후에는 신호를 개별적으로 또는 대량으로 닫을 수 있습니다. 신호는 필요한 경우 다시 개방될 수도 있습니다. 향후 릴리즈에서 신호의 폐쇄를 자동화하는 방법들에 대해 현재 작업 중입니다.
규칙 생성을 위한 UI 워크플로우
신호가 나타나기 시작하게 하려면, 탐지가 실행할 규칙이 필요합니다! SIEM 탐지를 위한 규칙 생성은 간단하고 이해하기 쉽습니다. 다음 세 가지 단계를 따르면 됩니다.
1) 규칙이 실행될 때마다 사용될 쿼리를 생성합니다. 이 쿼리는 Lucene 구문, KQL, 저장된 검색일 수 있으며 또는 저장된 타임라인으로부터 쿼리를 가져올 수 있습니다. (규칙 쿼리를 위한 훨씬 더 많은 옵션이 향후 릴리즈를 위해 현재 개발 중입니다.)
2) 규칙을 설명하는 몇 가지 정보(제목, 설명 등)를 추가합니다.
3) 규칙이 실행되어야 하는 간격 일정과 온전성 검사를 위해 추가 룩백 시간 일정을 정합니다. 해당 사용자의 수집 파이프라인에서 발생할 수 있는 지연을 허용하기 위해 일반적으로 일정 정도의 룩백 시간을 권장합니다. 또한 규칙이 정확히 예정된 간격으로 실행된다는 보장이 없고 따라서 실행 간에 지연이 발생할 수도 있기 때문에 약간의 룩백 시간을 권장하기도 합니다. 오버로드된 작업 관리자의 작업자 대기열이나 충분하지 않은 컴퓨팅 리소스가 이러한 지연의 원인이 될 수 있습니다.
이 세 가지가 검색 규칙을 구성하는 기본 구성 요소입니다. MITRE ATT&CK 전술과 테크닉에 따라 이 규칙을 분류하기 위한 설정과 아울러 추가 참고 자료를 위한 링크도 제공해드리고 있습니다.
사용자들은 또한 기존 규칙에 대해 개별적으로 또는 대량으로 규칙을 (사용자 정의를 위해) 복제, 비활성화, 내보내기 및 삭제하는 등의 작업을 수행할 수 있습니다. 일반적인 규칙 관리에 대한 더 자세한 정보를 위한 안내서도 마련해 놓았습니다.
미리 빌드된 규칙
규칙은 개발하기 어려울 수 있고 테스트하는 데 시간이 많이 소요됩니다. 이 때문에, 탐지는 Elastic Security의 인텔리전스 및 분석 팀이 개발한 92개의 미리 빌드된 규칙으로 시작되며 프로덕션 환경의 Elastic에서 방대하게 사용되었습니다. 중요한 최신 위협들에 대응하는 새로운 규칙이 계속해서 개발되고 있습니다. 버튼을 한 번 클릭하기만 하면 이 새로운 규칙을 로드하여 실행 준비가 완료됩니다! 여기에서 미리 빌드된 규칙을 사용하고 조정하는 것에 대해 더 자세히 읽어보실 수 있습니다.
탐지 구현 세부 정보
Elastic Stack의 경보가 Kibana에 통합되어 일급 객체로 경보를 지원하게 된 직후, Elastic SIEM은 경보를 탐지의 기초로 활용했습니다. UI 이면에서 탐지는 경보 API 위에 겹쳐진 API를 사용합니다. SIEM 탐지 API는 편리함, 워크플로우(개방 신호와 폐쇄 신호 등), 보안의 도메인 세부 사항(MITRE ATT&CK 식별 등), KQL 지원을 제공해줍니다.
규칙은 API 키를 생성한 다음 해당 API 키를 활용하여 사용자를 위해 요청을 함으로써 이면에서 실행됩니다. 이러한 규칙은 search after를 이용해 일치하는 이벤트를 찾고 bulk create를 이용해 이벤트의 정보를 단일 인덱스의 단일 문서로 복사합니다. 신호는 규칙 세부 사항 및 규칙과 일치하는 원래의 이벤트 문서 세부 사항으로 이루어집니다.
단일 규칙 실행에서 100개 이상의 일치되는 문서가 발견되는 경우, 마지막 100개의 일치만이 내림차순 `@timestamp` 정렬 순서에 따라 신호 인덱스에 복사됩니다. 사용자가 신호 탐지 규칙 페이지를 처음 방문할 때 신호 인덱스는 Kibana 스페이스당 자동 생성됩니다. 인덱스 이름 형식은 `.siem-signals-
SIEM 신호 인덱스의 매핑은 Elastic Common Schema(ECS)와 신호가 무엇인지에 대한 우리의 정의를 사용자 정의한 매핑의 조합입니다. 일치하는 문서가 규칙 쿼리에서 탐색되면, 소스 인덱스로부터 필드를 복사하게 되며, 소스 문서의 필드가 ECS를 준수하는 경우 결과적인 신호 필드는 검색 가능하게 됩니다. 소스 인덱스의 필드가 ECS의 일부가 아닌 경우, 그래도 신호의 `_source`에 저장되며 타임라인과 애플리케이션의 다른 부분 내에서 조회 가능합니다. 그러나 검색은 할 수 없습니다.
확장성
탐지 UI는 새로 개발된 Kibana 경보 프레임워크와 Kibana 작업 관리자 위에 구축됩니다. 이 두 가지는 수평과 수직 확장 기능을 제공하며 당시에 이용 가능한 하드웨어 중 가장 적합한 것을 사용할 수 있는 유연성을 갖추게 해줍니다. Kibana 작업 관리자 작업자는 수직 확장을 활용하여 수가 증가할 수 있으며 또는 별개의 Kibana 인스턴스에서 복제되고 수평적으로 확장될 수 있습니다.
여러 Kibana 인스턴스가 실행 중일 때, 작업 관리자는 인스턴스에 걸쳐 작업의 균형을 맞추기 위해 조정을 하게 됩니다. 기본이 10인 kibana.yml 파일 내에서 max_workers의 수를 업데이트함으로써, Kibana 노드당 보다 효율적으로 리소스를 적절하게 할당하기 위해 수직적으로 확장하거나 축소할 수 있습니다.
신호 중복 제거
규칙이 실행 중일 때, 규칙의 쿼리에 일치하는 것으로 발견되는 이벤트를 기반으로 신호를 발생시킵니다. 때로는 별개의 규칙들에서 쿼리가 겹쳐서 또는 어떤 규칙을 연속 두 번 실행하고 긴 추가 룩백 시간으로 인해 동일한 신호를 포착하여 중복 신호가 생성될 수 있습니다. 중복 신호가 신호 표에 나타나지 않도록 방지하기 위해, 우리는 소스 이벤트가 비롯되는 인덱스, 소스 이벤트의 문서 ID, 소스 이벤트의 버전 번호, 실행되는 규칙 ID를 기반으로 신호를 식별합니다. 이러한 속성을 해싱함으로써, 고유한 신호만 신호 인덱스에 추가되도록 합니다.
오류
때로는 규칙의 쿼리에 있는 구문 오류로 인해 오류가 나타나게 되거나 규칙의 실행 기간 동안 다른 문제가 발생하게 됩니다. 규칙 세부 사항 페이지의 오류 탭에서 이것을 버블업합니다. 앞으로 규칙 실행 정보의 가시성과 일반적인 규칙 모니터링을 확장할 계획입니다.
그리고 여기에서 실패 기록을 볼 수 있습니다. 이것은 규칙 실행 중에 발생한 마지막 오류 5개를 표시합니다.
미래의 SIEM 탐지
이 Elastic SIEM 탐지 베타 작업을 하고 출시함에 있어 가장 흥분되는 부분은 Elastic SIEM 토론 포럼과 저희의 개방 기능 추적 목록에 대해 초기부터 계속해서 이어지고 있는 커뮤니티 피드백입니다.
탐지를 훨씬 더 강력하게 만들기 위한 큰 계획이 있으며, 집계, 머신 러닝 작업, EQL을 포함하기 위해 규칙 쿼리를 확장하는 것은 그 몇 가지 중 하나일 뿐입니다. 좋은 보안 사용 사례라고 할 수 있는 것에 대해 생각 중이시거나 현재 진행되는 일에 대해 질문이 있으시면, 함께 해주세요!