코드로서의 지속적 컴플라이언스 P1: 시그마

컴플라이언스는 항상 반응적인 프로세스로 존재해 왔습니다. 이는 표준이 길며, 업데이트에는 많은 노력이 필요하고 시간이 걸리며, 구현에도 더 많은 시간이 필요하며 감사 프로세스는 1년에 한 번 일어나기 때문입니다. SIEM 세계에서 시작하여, 나는 컴플라이언스를 일반적으로 외부 감사인에게 설명할 수 없는 공허한 결과나 쓸모없는 결과를 반환하는 캔된 보고서를 통해 다루었습니다. 반면, 보고서와 쿼리의 기본 논리는 모호하며 최소한 유지를 위해 많은 노력이 필요합니다. 이 작업을 성공하려면 특정 SIEM 기술의 상관 관계 규칙 엔진 또는 쿼리 언어를 마스터하고, 이를 제공하는 보고서 엔진을 구성해야 하며, 실제 환경은 동적이면서도 모든 데이터를 한 곳에 모으는데 수개월이 걸릴 수 있습니다. 이러한 작업을 완료할 무렵에는 SIEM 기술이 변경되거나 다른 고객과 작업해야 합니다. 그들은 전통적 ‘실시간 상관 관계’ 대신 검색 기반 보안 분석 시스템을 사용합니다. Qualys Policy Compliance, Tripwire와 같은 컴플라이언스 감사 기능을 갖춘 VM 스캐너 등과 같은 보안 감사 도구가 있는 경우 더 쉬워집니다. 그러나 후자의 도구는 종합적이거나 실시간적인 그림을 구축하지 않으며, SIEM 또는 일종의 보안 분석 플랫폼과 연결되지 않는 한 불가능합니다. massive 제품과 사람이년 걸리는 컨설팅 노력이 드는 GRC 기차면 최악입니다. 지루합니다. 비용 비효율적입니다. 가시성에서 보장된 격차가 있습니다. 디지털 시대에 우리에게는 너무 느립니다. NIST CSF나 GDPR을 처리하는 모든 것은 얼마나 좋은가요? 제 개인적인 의견(IMO)으로 컴플라이언스는 보안의 반영이므로, 사이버 보안을 제대로 수행하고 있다면 컴플라이언스는 자연스럽게 따라옵니다. 단, 반대는 작동하지 않습니다. 변화가 필요한 시간인가요? 예. 그리고 오늘 우리는 귀하의 컴플라이언스를 민첩하고 투명하며 비용 효율적인 프로세스로 만들기 위한 일련의 기사 시리즈를 시작할 것입니다. 현대의 디지털 비즈니스에 적합하게요.

Sigma 규칙의 진화와 컴플라이언스에의 연결

SIEM, SOC 및 위협 헌팅 작업을 위한 Sigma 규칙의 가속된 채택을 보안 산업에서 가장 긍정적인 변화 중 하나로 여깁니다. Sigma는 이미 위협 헌팅 쿼리에 대한 사실상 표준이기 때문에 이를 연속 컴플라이언스 관행을 확립하기 위해 적용하는 이 미친 아이디어가 생겼습니다. Sigma에 대해 듣지 못한 경우, 이는 이해하기 쉽고, 학습 경로가 빠르며, 플랫폼 독립적이며 오픈 소스 언어입니다. 규칙 및 소스 코드의 예 https://github.com/Neo23x0/sigma 시작하기 위한 튜토리얼 https://www.nextron-systems.com/2018/02/10/write-sigma-rules/Elastic stack, Splunk, ArcSight, QRadar, Qualys, Microsoft Windows Defender ATP, Logpoint, Greylog이 있다면 이미 보안 및 헌팅을 위해 Sigma 규칙의 가치를 얻을 수 있습니다. 이러한 플랫폼은 정보 보안/SOC의 일부일 가능성이 높으며, 컴플라이언스에 사용할 수 있는 대량의 데이터를 보유하고 있습니다. 또한, Elastic stack의 다양한 비즈니스 유닛에서 사용되는 프리미엄 또는 커뮤니티 버전을 보유하고 있을 가능성이 높습니다. 이를 통해 자동화된 컴플라이언스 제어용 데이터를 얻을 수 있습니다. Sigma의 발전과 전 세계적인 채택의 중요한 이유 중 하나는 MITRE ATT&CK의 원활한 지원입니다 https://attack.mitre.org. 정보 보안에서 오지 않은 사람들을 위해 설명하자면, MITRE ATT&CK는 사이버 보안의 블록체인 또는 화학의 원소 주기율표입니다. 따라서 우리는 학습하기는 더 쉽지만, 어떤 SIEM의 쿼리 언어보다 널리 채택된 오픈 소스 표준을 가지고 있으며, 순간적으로 TTP 귀속을 수행하기 위해 ATT&CK 방법론과의 태그를 지원합니다. 컴플라이언스 표준에 관련된 태그를 추가하면 무엇이 될까요? CSC 8.2에 따라 자동 제어하는 쿼리나 GDPR에 대한 개인 데이터를 처리하는 시스템을 찾는 쿼리? Sigma에게 이것은 또 하나의 태그에 불과하므로, 기술적으로는 진화의 논리적인 다음 단계입니다.

컴플라이언스를 위한 Sigma 규칙 작성 방법

개인적으로는 Sigma의 큰 지지자이지만, 이 시점에서 제가 규칙을 많이 작성하지 않는 것은 비밀이 아닙니다. 자세한 방법 가이드를 위해 Alex Yamposlkyi와 짧은 대화를 나누었습니다. Alex는 매우 활동적인 Sigma 규칙 개발자 중 하나로서, 양적으로 개발된 규칙 수에 있어 Florian Roth 다음으로 두 번째로 많은 사람입니다. 그는 몇 가지 매우 실용적인 통찰력을 제공했습니다.

AB: “Alex, 컴플라이언스를 위한 Sigma 규칙을 이미 개발한 적이 있습니까?”
AY: “예, 몇 달간 바쁘게 작업해 왔습니다. Sigma 공식 GitHub 리포지토리에서 몇 가지 예를 찾을 수 있습니다: https://github.com/Neo23x0/sigma/tree/master/rules/compliance 및 SOC Prime Threat Detection Marketplace에서: https://tdm.socprime.com/?sigmaTypes[]=Compliance ”

AB: “좋습니다. 컴플라이언스 Sigma 규칙을 만들 때 따르는 특정 알고리즘이 있나요?”
AY: “이것을 5단계 프로세스로 설명할 수 있을 것 같습니다:

1. 초기 CIS 제어를 학습하십시오 https://www.cisecurity.org/controls/cis-controls-list/
2. 조직 내의 로그 소스 중 특정 제어의 요구 사항을 충족할 수 있는 로그 소스를 이해하십시오.
3. 필요한 이벤트를 위해 SIEM 플랫폼을 검색하십시오.
4. 적절한 이벤트가 발견되면, 제어 규칙 논리를 결정하십시오: 로그 항목이 컴플라이언스에 대해 좋은 것인지 나쁜 것인지에 해당합니다. 스스로에게 물어보세요: 이 로그 항목이 제어를 통과했는지 실패했는지?
5. SIEM 독립성을 유지하면서 플랫폼 특정 검색 매개변수를 제거하여 Sigma 규칙으로 결과 이벤트를 코드화하십시오. 항목 #1의 태그를 추가하고 자동 검색을 예약하십시오.”

AB: “이것은 빠른 승리가 될 것 같습니다. 이를 단계별 지침으로 확장할 수 있을까요?”
AY: “예. 여기에 빠른 노트를 드립니다.

1. 구축 중인 제어의 특정 도메인을 선택하십시오. 예를 들어, CSC 도메인 #8에 해당하는 ‘악성코드 방어’입니다.
2. 이 제어의 설명을 더 깊이 파고드십시오. 우리 경우에는 8.2가 ‘조직의 안티-멀웨어 소프트웨어가 스캔 엔진 및 서명 데이터베이스를 정기적으로 업데이트하도록 보장’이라는 뜻입니다.
3. 제어를 통과하거나 실패하기 위해 시스템에서 필요한 일이 무엇인지 생각하십시오. 8.2의 경우 AV 서비스가 중지되거나 업데이트에 오류가 있으면 제어에 실패한 것입니다. 따라서 서비스 중지 및 업데이트 오류 이벤트에 대해 AV 이벤트 로그를 추적해야 합니다.
4. 이 특정 제어를 추적하는 것은 꽤 쉽습니다. AV 제품을 설치해야 합니다. 제 경우에는 Logstash를 사용하여 Elastic stack에 통합된 Symantec 제품이었습니다. 잠시 로그를 정렬한 후, 업데이트 다운로드 및 배포를 담당하는 이벤트를 찾을 수 있었습니다. 이는 ‘새 콘텐츠 다운로드됨’, ‘업데이트됨’이라는 문자열을 포함합니다.
5. 이러한 키워드를 포함하는 필드를 확인하여 간단한 Elastic 쿼리를 만들 수 있습니다: (event.name:(“Downloaded new content”)) OR (event.name:(“An update for”))
6. 이제 규칙 논리에 대한 결정을 내립니다: 이벤트가 있는 것이 좋은지 나쁜지. 우리 경우에서는 로그 항목이 있는 것이 긍정적이며, 제어가 통과됨을 의미합니다. 프로세스를 자동화하기 위해 Sigma 규칙을 코드화하고 플랫폼 특정의 저장된 검색 메커니즘에 적용합니다. 내 경우 환경에 특화된 시간 간격으로 Elastic stack에서 Watcher를 실행하도록 예약합니다.
7. Sigma 규칙을 작성해봅시다
8. 이 예에서 특정 기간 동안 이벤트가 누락되었을 경우 경고를 예약할 수 있습니다. 다른 예에서는 상황이 반대일 수 있으며 이벤트를 발견했을 때 경고가 필요할 수 있습니다.
9. 이제 우리 규칙은 모든 관련 태그가 필요하므로 다음 형식으로 추가할 것입니다태그:
   – CSC8.2
   – attack.impact
   – attack.t1489

사실, ATT&CK 및 컴플라이언스를 위해 태그를 혼합할 수 있습니다. 위의 예에서 ‘CSC8.2’는 CSC 도메인에 따른 해당 제어 번호입니다. ‘attack.persistence’는 MITRE ATT&CK 전술이며, attack.t1053는 제어가 중점을 두는 특정 기술입니다.

업데이트된 Sigma 코드는 다음과 같습니다Threat Detection Marketplace에 규칙을 게시하면 ‘‘ 버튼을 눌러 규칙에 대한 메타 데이터를 생성할 수 있습니다.‘태그’ 목록에서 규칙을 ISO, PCI, NIST CSF 등과 같은 모든 컴플라이언스 표준과 상호 연결할 수 있습니다.

우리의 대화는 SOC Prime Threat Bounty 프로그램에 대한 인터뷰 자료로 충분했으며 한 시간 더 진행되었습니다. 그때까지 Sigma for Compliance에 대한 피드백은 매우 환영합니다.
그리고 Elastic stack에서 최종 결과가 어떻게 보이는지 궁금하다면, 비디오를 확인해보십시오 https://my.socprime.com/en/continuous-compliance

/안전하세요