팔로우 모든 탐지 팀은 이 순간을 알고 있습니다. 규칙이 작성되거나 다운로드되고, 검토되며, SIEM의 쿼리 언어로 번역되어 배포됩니다. 상태는 사용 가능으로 표시되고, 규칙 수는 증가하며, 커버리지 보고서는 더 푸르게 됩니다.
이 중 어떤 것도 규칙이 작성된 공격을 탐지할 것인지 여부를 알려주지 않습니다. 규칙은 잘 작성되었어도 아무 것도 찾지 못할 수 있습니다. 그 이유는 규칙의 논리, 데이터, 또는 번역이 현실과 조용히 불일치할 수 있기 때문입니다. 작동하더라도 탐지할 것이 없는 규칙과 작동하지 않는 규칙이 동일하게 보이기 때문에 문제는 오랜 시간 숨겨질 수 있습니다.
이 글에서는 작동하는 규칙과 손상된 규칙을 구분하는 요소, 규칙이 일반적으로 어떠한 점에서 잘못되는지, 그리고 규칙이 배포되기 전에 작동을 증명하고 그 후에도 계속 작동하도록 SOC Prime을 사용하여 할 수 있는 일을 설명합니다.
“작동”이 실제로 의미하는 것
작동하는 탐지 규칙은 세 가지 동작을 수행합니다. 그것이 목표로 하는 행동에 대한 올바른 논리를 표현합니다. 실제로 그 행동을 포함하는 데이터에서 실행됩니다. 그리고 실행되는 플랫폼에 대해 올바르게 작성됩니다. 이 중 하나라도 실패하면, 규칙은 활성화되고 오류를 발생시키지 않더라도 손상된 것입니다.
이 방식은 각 실패가 서로 다른 원인과 해결책을 가지고 있기 때문에 도움이 됩니다:
- 논리 문제 는 규칙 자체에 존재합니다. 행동의 변형을 잡기에는 너무 좁거나, 정상 활동에 맞춰질 정도로 광범위합니다.
- 데이터 문제 는 환경에 존재합니다. 규칙이 필요로 하는 이벤트가 기록되지 않거나, 수집되지 않았거나, 규칙이 의존하는 필드가 누락되어 있습니다.
- 번역 문제 는 언어 간 이동에서 발생합니다. 규칙이 플랫폼의 쿼리 구문으로 변환될 때 규칙의 의미가 변경됩니다.
대부분의 팀은 규칙을 작성할 때 첫 번째 문제를 조심스럽게 확인합니다. 두 번째와 세 번째는 규칙이 누군가의 인식 없이 손상되기 쉬운 지점입니다.
작동하는 규칙이 잘못된 경로로 가는 지점
행동과 일치하지 않는 논리. 도구의 파일 이름에만 키가 있는 규칙은 파일 이름을 변경하여 쉽게 피할 수 있습니다. 필터링 없이 일반적인 명령줄 패턴에 키가 있는 규칙은 관리자에게 하루 종일 맞춰질 수 있습니다. 어느 실수도 배포 시에는 드러나지 않습니다. 첫 번째는 공격자가 지나갔을 때 드러나고, 두 번째는 경고 소음으로 드러납니다.
존재하지 않는 데이터. 명령줄 인수를 기반으로 하는 프로세스 생성 규칙은 명령줄 로그가 활성화되지 않은 경우 무용지물입니다. 이벤트가 필드 없이 도착하기 때문입니다. 이는 한 번도 탑재되지 않은 로그 소스, 전송이 중단된 에이전트에도 해당됩니다. 규칙은 일정에 맞춰 실행되고 아무 것도 찾지 못하며 건강하게 보입니다.
다른 장소에서 다른 의미를 가진 필드. 같은 개념이 제품마다 다른 이름을 가질 수 있으며, 서로 다른 벤더의 데이터 모델도 별도의 계약입니다. 스플렁크 CIM과 마이크로소프트 센티넬 ASIM은 좋은 예입니다: 한 곳에 존재하는 필드가 다른 곳에 존재하지 않을 수 있습니다. 문자 대 문자 포트를 사용하면 대상이 결코 채우지 않는 필드를 참조하는 규칙이 생성됩니다.
의미를 변경하는 번역. 자동 번역기는 간단한 선택 논리를 잘 처리하지만, 상관규칙과 고유 기능은 보통 사람이 검토해야 합니다. 플랫폼은 또한 대소문자 구분, 와일드카드, 정규 표현식과 같은 세부 사항을 처리하는 방법이 다릅니다. 규칙은 “성공적으로” 번역될 수 있지만 원본과 다르게 작동할 수 있습니다.
좋은 규칙을 폐기하는 플랫폼 제한. SIEM은 실행 가능한 규칙 수를 제한합니다. 팀은 종종 새로운 규칙을 위한 공간을 만들기 위해 작동 중인 규칙을 비활성화하므로, 커버리지는 아무도 결정하지 않은 채 감소합니다.
그것이 중요한 이유
이러한 문제들 각각이 규칙 수와 대시보드를 변경하지 않습니다. 배포된 규칙을 세는 커버리지 수치가 보호를 과장한다는 것입니다. 그 차이는 보통 사건 중 드러납니다. 누군가가 규칙이 발동해야 했지만 절대 그럴 수 없었다는 것을 발견할 때 말입니다.
두 번째 비용이 있습니다: 조용한 규칙은 모호합니다. 아무 것도 발동되지 않으면 환경이 깨끗한 것인지, 텔레메트리가 누락된 것인지, 논리가 잘못된 것인지 알 수 없습니다. 이후에 이를 해결하려면 하나씩 논리, 데이터, 번역을 확인해야 합니다. 초기 증거를 모아 최신 상태로 유지하는 것이 훨씬 저렴합니다.
SOC Prime이 규칙이 작동하는 것을 증명하는 데 어떻게 도움이 되는가
탐지 검증은 정말 질문의 연쇄입니다: 이 규칙은 무엇이 필요한가, 내 환경은 그것을 제공하는가, 규칙이 내 데이터에 예상대로 작동하는가, 그렇지 않다면 무엇이 변경되어야 하는가? SOC Prime은 각 단계를 지원합니다.
탐지 요구 사항을 이해하십시오
검증은 어떤 테스트보다 먼저 시작됩니다. SOC Prime은 탐지 내용에 대한 맥락 정보를 제공합니다. 여기에는 의도된 행동, 텔레메트리 요구 사항, MITRE ATT&CK 매핑, 잠재적 허위 양성 및 기타 메타데이터가 포함됩니다. 이는 탐지 엔지니어가 그들의 환경에 적용 가능한 탐지인지 여부를 결정하고 테스트 전에 어떤 사전 요구 사항이 있어야 하는지 판단하는 출발점을 제공합니다. 예를 들어 명령줄 로그를 필요로 하는 규칙은 나중에 알아내는 대신 처음부터 이를 알려줍니다.
사용 가능한 텔레메트리를 평가하십시오
규칙에 필요한 것이 무엇인지 알았으면 다음 질문은 그것을 가지고 있는지 여부입니다. Prime Hunt는 팀이 사용 가능한 데이터와 잠재적 탐지 커버리지 간의 관계를 평가하는 데 도움을 줄 수 있습니다. 데이터 감사는 사용 가능한 로그 데이터를 분석하고 이를 MITRE ATT&CK에 매핑하여 잠재적 가시성 간격을 식별합니다. 이는 탐지 커버리지 부족이 누락된 텔레메트리가 아닌 탐지 내용의 부족에서 오는 것인지 여부를 결정하는 데 도움을 줍니다. 이들은 두 가지 매우 다른 문제이며 두 가지 매우 다른 해결책이 있습니다.
조직 데이터에 대해 탐지를 테스트하십시오
Prime Hunt는 연결된 환경의 실제 데이터를 대상으로 한 탐지 스캔을 실행할 수도 있습니다. 실제 데이터에 대한 탐지를 테스트하면 이론적 검증에만 의존하지 않고 환경 내의 내용이 어떻게 작동하는지에 대한 증거를 제공합니다. 스캔 결과는 관련 매치를 생성하는 탐지를 식별하고 추가 조사가 필요하거나 조정이 필요한 것들을 강조합니다.
탐지 논리를 조사하고 개선하십시오
탐지에 수정이 필요할 때, SOC Prime은 Prime Core와 Prime Architect를 통해 탐지 엔지니어링 기능을 제공합니다. 탐지 내용은 리뷰, 맞춤화, 번역, 대상 환경에 대한 최적화가 가능합니다. 이는 스키마 차이, 필드 매핑, 쿼리 언어, 환경별 요구 사항을 해결하며 모든 문제 있는 탐지를 새로운 개발 작업으로 취급하지 않습니다.
실제로, 이것은:
- 가동 중인 플랫폼에 맞게 번역하십시오. 플랫폼에 있는 모든 Sigma 규칙은 이미 모든 지원 SIEM 언어와 형식으로 번역되어 있으므로 스택에 대한 쿼리를 바로 선택하여 배포할 수 있습니다. 맞춤형 또는 자체 Sigma 규칙의 경우, Prime Architect의 번역 작업 공간을 사용하여 SIEM, EDR, XDR, 또는 데이터 레이크의 기본 쿼리 언어로 변환하십시오. Sigma는 소스로 유지되므로 한 번의 변경이 각 플랫폼에서 수동 편집되지 않고 다시 번역될 수 있습니다.
- 테이블, 필드 및 값을 스키마에 매핑하십시오. 맞춤 필드 매핑을 사용하면 비표준 테이블, 필드 및 값을 기본값에 매핑할 수 있는 프로필을 정의할 수 있습니다. 한 번 프로필을 생성한 후, 규칙을 배포하거나 쿼리를 보낼 때마다 이를 적용하십시오.
- 환경에 맞는 필터를 추가하십시오. 필터는 배포 전에 탐지 논리에 조건을 추가하여 특정 사용자, 호스트 또는 기타 항목 집합을 포함하거나 제외합니다. 이를 통해 알려진 양성 활동이 좋은 규칙을 시끄러운 규칙으로 바꾸지 않도록 하면서 규칙 자체를 다시 작성하지 않습니다.
- 배포 설정을 프리셋으로 저장하십시오. 프리셋은 쿼리 기간, 심각도 및 규칙 상태와 같은 매개변수를 저장하여 배포가 일관되게 유지됩니다.
- 검증, 최적화 및 미세 조정하십시오. 번역 작업 공간은 또한 탐지 내용의 검증 및 최적화를 수행합니다. 이로 인해 리뷰가 대체되지는 않으며, 모든 필드를 대상 스키마와 비교하고, 특히 상관 논리 및 플랫폼 고유 기능과 같은 플래그가 지정된 항목을 주의 깊게 살펴보십시오. 스키마와 필터링을 넘어서는 변경 사항은 직접 코드를 편집하고 다시 번역하며 카스텀 저장소에 업데이트 또는 새로운 규칙으로 저장하십시오.
- AI 지원 작업 공간으로 연구하고 조정하십시오. 규칙이 목표로 하는 행동을 연구하고 논리의 변경을 해결하는 데 사용하십시오. 엔지니어는 모든 변경 사항을 배포 전에 검토하여 제어 상태를 유지합니다.
커버리지 간격 식별
탐지 검증은 탐지되지 않는 내용을 알아내야 합니다. Prime Hunt의 데이터 감사는 사용 가능한 텔레메트리와 탐지 내용을 기반으로 커버리지 분석을 제공합니다. 이는 팀이 불충분한 가시성으로 인한 간격과 누락되거나 부적절한 탐지 규칙으로 인한 간격을 구별하는 데 도움을 줍니다. 그 구별은 다음 엔지니어링 작업에 대한 정보를 제공합니다: 더 많은 데이터를 수집하고, 기존 탐지를 조정하거나, 추가 탐지 내용을 식별하고 개발하십시오.
시간이 지나면서 계속 검증하십시오
탐지 효과는 환경 및 탐지 내용이 발전함에 따라 변합니다. Prime Hunt와의 반복 검증은 팀이 초기 검증 결과에 영원히 의존하지 않고 현재 데이터를 기반으로 탐지를 재평가할 수 있게 합니다. 이는 로그 구성, 데이터 스키마, 인프라스트럭처, 탐지 내용이 자주 변경되는 환경에서 가장 중요합니다.
증명 대신 가정
배포된 규칙은 주장입니다. 실제 데이터에서 테스트된 규칙은 증거입니다. 차이는 알아채기 쉽지 않습니다. 왜냐하면 둘 다 규칙 목록에서 동일하게 보이고, 둘 다 공격이 도착하기 전까지 조용하기 때문입니다.
SOC Prime은 팀이 이 격차를 좁힐 수 있도록 돕습니다. 명확한 탐지 요구 사항과 사용 가능한 텔레메트리에 대한 솔직한 점검으로 시작하여 귀사의 데이터와 함께 탐지를 테스트하고, 맞지 않는 부분을 수정할 수 있는 도구를 제공합니다. 그런 다음 커버리지 분석은 남아 있는 간극이 더 많은 데이터를 요구하는지, 더 좋은 조정 또는 새로운 내용을 필요로 하는지를 보여주며, 반복 검증을 통해 환경이 변화함에 따라 현재의 해답을 유지합니다. 가장 중요한 규칙부터 시작하고, 실제로 발동할 규칙을 알아냅니다.
