[Sigma Rule] 제18화: Sigma + Cloud Security 통합

이번 글에서는 Sigma를 클라우드 보안과 어떻게 통합해 활용할지 실전 관점으로 정리해드리겠습니다.

SigmaHQ 공식 문서는 Sigma가 AWS, Azure Sentinel 같은 SIEM/로깅 플랫폼 전반에서 공통 탐지 포맷으로 쓰일 수 있으며, CI/CD로 배포 가능한 YAML 기반 규칙이라는 점을 강조합니다.

Recorded Future의 클라우드 탐지 연구도 AWS, Azure, GCP에서 수집한 클라우드 로그를 기반으로 Sigma 규칙을 생성해 악성 행위를 탐지하는 접근을 제시합니다.

 

◎ 왜 클라우드에 Sigma가 필요한가

• 클라우드는 온프레미스와 달리 자원이 빠르게 생성·삭제되고, 계정·권한·API 호출이 공격의 중심이 됩니다. 
• 그래서 네트워크 중심 탐지만으로는 부족하고, CloudTrail, Azure Activity Log, GCP Audit Log 같은 관리 평면 로그를 정교하게 봐야 합니다. 
• Sigma는 이런 로그를 벤더 중립적인 규칙으로 정리해 주므로, 특정 SIEM이나 CSP에 종속되지 않고 탐지 로직을 공유할 수 있습니다.

 

• 클라우드 보안의 또 다른 문제는 서비스마다 로그 구조가 다르다는 점입니다.
• 예를 들어 AWS CloudTrail은 userIdentity, eventName, sourceIPAddress처럼 중첩 구조를 많이 쓰고, Azure와 GCP는 각각 다른 필드 체계를 가집니다.
• Sigma는 logsource와 field mapping을 통해 이 차이를 추상화합니다.

 

◎ 어떤 로그를 먼저 봐야 하나요

 - 클라우드 Sigma 통합은 보통 세 축으로 시작하시면 좋습니다.

• AWS: CloudTrail, VPC Flow Logs, GuardDuty finding logs.
• Azure: Azure Activity Log, Entra ID sign-in logs, MDE/Defender telemetry.
• GCP: Cloud Audit Logs, VPC Flow Logs, Cloud IAM 이벤트.

 - Recorded Future 보고서도 세 플랫폼 모두에서 아티팩트 삭제, 명령 실행, 열거 같은 행위를 Sigma로 탐지할 수 있다고 설명합니다.

 - 즉, “관리 이벤트 + 인증 이벤트 + 네트워크 이벤트”를 우선적으로 표준화하는 것이 핵심입니다.

 

◎ Sigma 규칙 작성 원칙

• Sigma의 강점은 클라우드 환경에서도 행동 중심으로 규칙을 쓸 수 있다는 점입니다. 
• 예를 들어 AWS Root 계정 사용을 탐지하는 규칙은 Sigma 공식 문서의 예시처럼 간단하게 작성할 수 있습니다.

title: AWS Root Credentials description: Detects AWS root account usage logsource:   product: aws   service: cloudtrail detection:   selection:     userIdentity.type: Root   filter:     eventType: AwsServiceEvent   condition: selection and not filter level: medium

• 이 규칙은 클라우드에서 가장 중요한 위험 중 하나인 루트 계정 사용을 명시적으로 잡습니다.
• 또한 falsepositives에 정당한 운영 작업을 적어두면, 튜닝과 리뷰가 훨씬 쉬워집니다.

 

◎ AWS에서 자주 쓰는 탐지

 - Recorded Future의 연구는 AWS에서 Stratus Red Team과 Pacu 같은 도구를 이용해 로그 아티팩트를 만들고, 이를 Sigma로 탐지하는 방식을 보여줍니다. 

 - 실무적으로는 아래 세 가지가 특히 중요합니다.

• 보안 그룹 인그레스 열기: AuthorizeSecurityGroupIngress와 포트 22/3389 같은 노출 패턴.
• CloudTrail 삭제: DeleteTrail, StopLogging 같은 로깅 무력화 행위.
• IAM 권한 변화: CreateAccessKey, AttachUserPolicy, PutUserPolicy 같은 권한 상승 시도.

 - 예를 들어 보안 그룹 22번 포트 개방은 다음처럼 탐지할 수 있습니다.

title: AWS Security Group Open SSH logsource:   product: aws   service: cloudtrail detection:   selection:     eventName: AuthorizeSecurityGroupIngress     requestParameters.toPort: 22   condition: selection level: high

• 이처럼 행위 이름과 파라미터를 함께 보는 방식이 클라우드 Sigma 규칙의 핵심입니다.

 

 

◎ Azure와 GCP는 어떻게 다를까요

• Azure에서는 구독 수준 관리 이벤트와 로그인 이벤트가 중요합니다. 
• 예를 들어 권한 상승, 역할 할당, 조건부 액세스 우회, 앱 등록 변경 같은 행위가 우선순위가 높습니다. 
• GCP는 IAM 정책 변경, 서비스 계정 키 생성, Audit Log 삭제, 방화벽 규칙 변경이 중요 포인트입니다.

 

• Sigma는 이런 차이를 logsource와 백엔드 변환으로 흡수합니다.
• 즉, 규칙 본문은 비슷하게 유지하면서도, 각 플랫폼에 맞는 필드명으로 변환해 배포할 수 있습니다.
• 이게 바로 클라우드 보안에서 Sigma가 강력한 이유입니다.

 

◎ 클라우드 Sigma 운영 절차

 - 실무에서는 아래 순서로 가시면 안정적입니다.

• CloudTrail / Azure / GCP 로그 온보딩을 먼저 완료합니다.
• 가장 위험한 계정·권한·로깅 무력화 시나리오부터 Sigma 규칙을 작성합니다.
• sigma-cli로 원하는 SIEM 쿼리로 변환합니다.
• 변환 결과를 클라우드별 샌드박스에서 테스트합니다.
• 오탐 필터와 계정 화이트리스트를 추가합니다.

 - 이 과정에서 중요한 것은 “클라우드 전용 규칙”을 따로 많이 만드는 것이 아니라, 공통 규칙 템플릿을 잘 설계하는 것입니다.

 - 예를 들어 AWS와 GCP의 권한 키 생성은 표현은 다르지만 의도는 비슷합니다.

 - 이런 경우 ATT&CK 매핑과 함께 Sigma 상위 템플릿을 두고 플랫폼별 필드만 바꾸는 방식이 좋습니다.

 

◎ CI/CD와 클라우드의 궁합

• SigmaHQ는 이미 Sigma를 Git 기반 CI/CD에 올리기 좋은 구조라고 설명합니다. 
• 클라우드 보안에서는 여기에 IaC와 정책 코드를 함께 묶는 것이 좋습니다. 
• 예를 들어 Terraform으로 AWS 계정을 운영한다면, Terraform 변경과 Sigma 규칙 변경을 같은 PR에서 검토할 수 있습니다. 
• 그러면 인프라 변경과 탐지 변경의 시간차가 줄어들고, “생겼는데 못 본 공격”을 줄일 수 있습니다.

 

◎ 실전 예시

 - 다음과 같은 우선순위로 시작하시면 효과가 큽니다.

• AWS: DeleteTrail, StopLogging, CreateAccessKey, AuthorizeSecurityGroupIngress.
• Azure: 역할 변경, 앱 등록, 비정상 로그인.
• GCP: IAM 정책 변경, 서비스 계정 키 생성, Audit Log 삭제.

 - AWS, Azure, GCP의 관리 평면 이벤트를 우선 보시고, 이후에는 VPC Flow Logs, WAF, DNS 같은 네트워크·가시성 로그로 확장하시면 효과가 큽니다.

 

◎ 마무리

• Sigma와 Cloud Security의 결합은 단순히 규칙을 한 번 더 쓰는 일이 아닙니다. 
• 클라우드 로그를 표준화된 탐지 언어로 다루고, AWS/Azure/GCP를 하나의 관점에서 관찰하는 운영 체계를 만드는 일입니다. 
• 지금 시작하신다면, 가장 먼저 관리 평면 로그부터 잡고 계정·권한·로깅 무력화 행위를 중심으로 규칙을 쌓아가시는 것이 가장 효율적입니다.