Elastic Security, 공개 탐지 규칙 리포지토리 개방

Elastic에서는 오픈 소스의 힘을 믿으며 커뮤니티의 중요성을 이해합니다. 커뮤니티를 최우선으로 함으로써, 우리는 사용자들을 위해 가능한 최고의 제품을 만들 수 있도록 하고 있습니다. Elastic Security를 통한 우리의 두 가지 핵심 목표는 대규모의 위협을 차단하고 모든 분석가에게 필요한 도구를 제공하는 것입니다. 오늘 우리는 새로운 GitHub 리포지토리 elastic/detection-rules를 열어서 보안 커뮤니티와 함께 일하면서 보다 큰 규모의 위협을 차단하고자 합니다.

Elastic Security의 탐지 엔진 출시는 Elastic Stack에 자동화된 위협 탐지를 더해주었습니다. Elastic Security Intelligence & Analytics 팀은 탐지 엔진의 초기 출시 이후 50개 이상의 규칙을 추가해 Linux, MacOS, Windows 운영 체제에서 공격자 기술의 가시성을 높였습니다. 적용 범위를 계속 확장해감에 따라, 탐지 범위가 확대되어 클라우드 서비스 및 사용자 행동과 같은 새로운 영역을 탐지할 수 있게 됩니다.

지난 몇 번의 릴리즈에서는 내부 리포지토리를 사용하여 탐지 엔진에 대한 규칙을 관리했습니다. Kibana Query Language(KQL) 구문, 스키마 사용 및 기타 메타데이터를 검증하는 새로운 기여에 대해 자동화된 테스트를 추가함으로써 반복적으로 테스트 절차를 개선해왔습니다. 규칙 개발이 성숙되어, 우리는 문제를 일으키지 않고 빠르게 이동할 수 있습니다.

우리의 elastic/detection-rules GitHub 리포지토리를 개방함으로써, 커뮤니티와 함께 공개적으로 규칙을 개발하게 되며, 커뮤니티를 기반으로 하는 여러분의 탐지를 환영합니다. 이것은 우리 모두가 공동 지식을 공유하고, 서로에게서 배우고, 함께 일함으로써 영향력을 발휘할 수 있는 기회입니다.

이 새 리포지토리의 내용

elastic/detection-rules GitHub 리포지토리에서 많은 MITRE ATT&CK® 기술에 대한 적용 범위와 함께 Elastic Security용으로 작성된 규칙을 찾을 수 있습니다. 우리의 현재 규칙 논리는 주로 KQL로 작성되어 있고 Elastic Common Schema(ECS)를 활용함으로써 우리는 규칙을 한 번만 쓰면 됩니다. ECS에서 정의된 필드 및 범주를 사용하여 규칙은 자동으로 Beats 로그 및 ECS에 적절하게 매핑되는 기타 데이터 소스와 함께 작동합니다.

rules/ 폴더 내에서 규칙은 TOML 파일에 저장되며 플랫폼별로 그룹화됩니다. 우리는 새로운 규칙을 더 쉽게 찾아 추가할 수 있도록 플랫 계층 구조로 단순성을 유지하려고 노력했습니다. Windows 전용 규칙을 찾고 계시다면, rules/windows로 이동하세요. 규칙을 찾는 데 여전히 어려움을 겪고 계시거나 규칙 간에 검색하려고 하시는 경우, 일치하는 메타데이터가 있는 파일을 표시하는 python -m detection_rules rule-search명령을 실행하여 CLI를 사용하실 수 있습니다.

모든 규칙에는 쿼리 자체 외에도 여러 개의 메타데이터 필드가 포함되어 있습니다. 이것은 제목, 설명, 노이즈 수준, ATT&CK 매핑, 태그 및 스케줄링 간격과 같은 정보를 캡처합니다. 분석가들이 분류를 수행하고, 알려진 오탐이나 조사에 도움이 되는 단계를 설명하는 것을 도울 수 있는 몇 가지 추가 필드도 있습니다. 규칙과 관련된 메타데이터에 대한 자세한 내용은 Kibana 규칙 작성 안내서 또는 기여 안내서의 규칙 메타데이터 요약 을 참조하세요.

이 규칙들이 내 탐지 엔진에 전달되는 방법

Elastic Cloud 관리 서비스를 사용하거나 전체 무료 기능을 포함하는 Elastic Stack 소프트웨어의 기본 배포를 사용하는 경우, 탐지 엔진으로 처음 이동할 때 최신 규칙을 얻게 됩니다. 업그레이드하는 경우, 탐지 엔진은 규칙이 추가 또는 변경되었음을 인식하고 해당 규칙을 업그레이드할지 여부를 결정하라는 메시지를 표시합니다. 업그레이드 후 단계에 따라 최신 규칙 사본을 받게 됩니다.

이 리포지토리를 사용하게 되는 사람들

이 리포지토리는 Elastic Security Intelligence & Analytics 팀이 규칙을 개발하고, 문제를 생성하고, 풀 리퀘스트와 대상 릴리즈들을 관리하는 곳입니다. 리포지토리를 공개함으로써 우리는 모든 외부 기여자들을 이 워크플로우에 초대하는 것입니다. 이것은 기여자들에게 우리의 개발 과정에 대한 가시성 및 규칙이 탐지 엔진과 함께 릴리즈될 명확한 경로를 제공하게 됩니다.

기여할 준비가 되셨으면, Elastic의 기여자 사용권 계약(CLA)에 서명해주세요. 이것은 모든 Elastic GitHub 리포지토리에 대한 표준이며, 우리가 여러분의 코드를 Elastic 사용자에게 자유롭게 배포할 수 있다는 것을 의미합니다.

위협 탐지에 접근하는 방법

일반적으로, 우리는 적대적 행동에 초점을 맞춘 탐지를 선호하는 경향이 있습니다. 보통 ATT&CK 기술에 집중한다는 뜻입니다. 이것은 규칙을 만들기 전에 기술이 어떻게 작용하는지 알아내기 위해 더 많은 연구와 노력이 필요하다는 것을 의미할 수 있습니다. 그러나 이런 접근법을 취함으로써 우리는 어제의 공격보다는 오늘과 내일의 공격을 탐지하고 저지하는 일을 더 훌륭히 해냅니다.

행동적 접근법을 취하는 것은 또한 우리에게 다양한 종류의 규칙이 필요하다는 것을 의미합니다. 일부는 극히 작은 이벤트를 탐색할 수 있고, 다른 일부는 여러 사건을 집계하거나 임계값 이상의 편차를 찾는 데 필요할 수 있습니다. Event Query Language(EQL)를 사용하면 여러 이벤트에 걸쳐 일련의 동작을 찾는 규칙을 작성할 수 있습니다.

물론, 우리는 때때로 하나의 기술로 모든 사용자들이 행동을 탐지하기는 어려울 수 있다는 것을 이해합니다. 그런 경우라면, 어떤 수를 써서라도, 더 시그니처적인 성격을 띄며 특정한 행동이나 도구를 대상으로 작성된 규칙을 얼마든지 추가해도 됩니다.

성숙한 탐지를 만드는 방법에 대해 더 자세하게 논의하려면 탐지 규칙 리포지토리의 철학에 대해 읽어보시기 바랍니다.

새로운 리포지토리가 필요한 이유

이전에 공개 규칙을 공유한 적이 있으시다면, 아마 MITRE, Sigma 또는 Elastic의 EQL 기반의 EQL Analytics Library에 의한 Cyber Analytics Repository(CAR)와 같은 다른 잘 알려진 GitHub 리포지토리를 알고 계실 것입니다. 그럼 이런 의문이 드실 수 있습니다. 왜 다른 리포지토리가 필요한가? 왜 이미 존재하는 것들을 사용하지 않는가?

놀랄 것도 없이, 이 질문에 대한 가장 좋은 대답은 다른 질문으로 시작됩니다. 다른 리포지토리가 존재하는 이유는 무엇일까요? CAR과 Sigma는 모두 의도적으로 언어나 플랫폼, 그리고 때로는 데이터 소스를 인식할 수 없다고 여깁니다. 한편, EQL Analytics Library는 특정 언어를 염두에 두고 작성되었습니다.

새로운 탐지 규칙 리포지토리로, 우리는 조금 다른 목적을 위해 노력하고 있습니다. 우리의 목표는 Elastic Security 사용자에게 다양한 데이터 소스에 걸쳐 작동 가능한 최상의 탐지 기능을 제공하는 것입니다. 우리는 ECS를 스키마의 훌륭한 이퀄라이저로 사용하여 여러 데이터 소스에 적용되는 규칙을 한 번 작성할 수 있습니다.

Elastic Stack은 여러 언어를 지원하므로, 우리의 규칙은 그것을 반영해야 합니다. 쿼리 언어는 전형적으로 다른 유형의 문제를 해결하기 위해 개발되며, 만약 다른 언어가 더 잘 작동한다면, 우리는 규칙 개발자들을 하나의 언어로 구속해서는 안됩니다. 현재 리포지토리에는 머신 러닝 이상 징후 탐지 작업을 사용하는 규칙과 함께 KQL 및 Lucene 규칙이 있습니다. 우리는 EQL을 Elastic Stack과 저장소로 가져오기 위해 열심히 작업 중입니다.

또한 최적의 Elasticsearch 성능을 위해 모범 사례가 준수되고 있는지도 확인할 수 있습니다. 예를 들어, process.path:*\\cmd.exe 검색은 와일드카드 검사를 수행해야 하는데, 단순한 키워드 확인보다 비용이 더 많이 듭니다. 선도적인 와일드카드를 포함하는 검색 대신, 우리는 process.name:cmd.exe를 사용하는 것을 추천할 수 있는데, 이것은 더 나은 성능과 가장 정확한 결과를 가져올 것입니다. 유사한 관점에서, ECS는 또한 process.command_line의 구문 분석된 버전인 process.args를 포함하고 있습니다. 우리는 구문 분석된 필드를 대신 사용할 것을 권장합니다. 왜냐하면 우리에게 더 나은 성능을 제공하며 사소한 공백이나 인용에 기초한 회피에 훨씬 덜 취약하다는 것을 의미하기 때문입니다. 윈-윈이죠.

다른 리포지토리로부터 규칙을 추가할 수 있는가?

자신의 환경 내에서 Kibana 역할이 적절한 권한을 가지고 있는 한 자신의 탐지 엔진에 규칙을 추가해도 좋습니다. elastic/detection-rules 리포지토리에 규칙을 추가하려고 하는 경우, 그 답은 당연히 “경우에 따라 다르다...”입니다. Elastic License에 따라 규칙이 하위 라이선스 될 수 있는 한, 이것은 공정한 게임입니다. 대부분의 경우 요구사항은 상당히 간단합니다. 즉, rule.author 어레이에 원본 작성자를 유지하고 그에 따라 NOTICE.txt 파일을 업데이트하여 원본 작성자에게 귀속성을 부여합니다. 다른 사람이 한 작업에 대해 대신 인정받고 싶지는 않으니, 부디 이 작업을 철저하게 하도록 도와주시기 바랍니다!

리포지토리의 라이선싱 접근 방식에 대한 자세한 내용은 README의 라이선싱 섹션을 참조하세요.

기여하는 방법

규칙 논리를 공유하고 싶으신가요? GitHub의 elastic/detection-rules에 동참하세요. 거기에 리포지토리를 탐색하고, 분기하고, 복제하고, 규칙을 만드는 데 대한 상세한 지시사항을 마련해 놓았습니다. 파일을 대량으로 편집하고 새로운 규칙을 더 쉽게 만들 수 있는 명령줄 도구도 포함되어 있습니다. 리포지토리에 새 규칙을 추가할 준비가 되면, python -m detection_rules create-rule을 실행하세요. 그러면 필요한 메타데이터를 입력하라는 메시지가 표시됩니다. 다른 규칙이나 템플릿에서 TOML 파일의 콘텐츠를 재사용할 때 발생하는 복사 및 붙여넣기 오류를 줄이기 때문에 CLI를 사용할 것을 권장합니다.

규칙이 양호한 상태일 때 python -m detection_rules test 명령을 실행하여 구문, 스키마 사용 등을 검증하는 단위 테스트를 로컬로 수행할 수 있습니다. 그런 다음, 풀 리퀘스트를 하시면 Intelligence & Analytics 팀의 누군가가 그 기여를 검토하게 됩니다. 변경을 요청하게 되는 경우, 권장되는 변경 사항을 여러분과 함께 작업할 것입니다. 

규칙에 대한 좋은 아이디어가 있지만 해당 아이디어에 대해 우리와 협업하거나 피드백을 받고 싶으시면, 새 규칙 문제를 자유롭게 생성해주세요. 여러분을 도와 함께 브레인스토밍을 할 수 있기를 기대합니다!

자세한 내용은 기여 안내서를 참조하세요.

이제 그 다음은?

새로운 규칙 리포지토리 및 워크플로우에 오신 것을 환영합니다! 여러분의 기여를 권장합니다. 여러분의 이름을 rule.author 필드에서 볼 수 있기를 기대합니다. 탐지 규칙 리포지토리는 나머지 Elastic Security와 함께 계속해서 진화할 것이며, 그 다음이 무엇이 될지 기대하고 있습니다.

스택에서 EQL의 개발을 추적하려면 이 GitHub 문제에 가입하세요. 또는 Elasticsearch 팀이 무엇을 하고 있는지 보기 위해 진행 중인 문서를 살펴보세요.

규칙을 작성하거나 새로운 detection rules GitHub 리포지토리를 탐색하는 데 있어 피드백이나 질문이 있는 경우, GitHub에서 문제를 생성하거나, detection-rules 태그를 사용하여 토론 포럼에 연락하거나, Elastic Slack Community의 #detection-rules 채널에서 저희를 찾아주세요.