AWS Security Hub와 OpenSearch를 활용한 SIEM 구성 및 활용 방안

AWS Security Hub는 고객의 Amazon Web Services(AWS) 환경의 보안 현황에 대하여 통합된 가시성을 제공하며, 또한 고객의 AWS 환경을 국제 보안 표준 및 AWS의 보안 권장 사항과 비교하여 차이점을 파악할 수 있도록 돕습니다. 이는 Security Hub가 SIEM(Security Information and Event Management)과 유사한 점을 가지고 있음을 보여줍니다.

그렇지만, Security Hub는 SIEM을 대체할 수 있는 독자적인 도구로 설계되지는 않았습니다. 예를 들어서, Security Hub는 AWS 관련 보안 분석 결과만 수집하며 AWS CloudTrail 로그와 같은 대용량의 이벤트 로그를 직접 수집하지 않습니다. 따라서, AWS 관련하여 확인된 보안 분석 결과들을 온프레미스(On-premise) 또는 기타 비 AWS 워크로드의 다른 유형의 조사 결과와 통합하여 관리하여야 하거나, 대용량의 이벤트 로그를 수집하고 분류하여 관리해야 하는 경우에는 Security Hub와 함께 별도의 SIEM 도구를 사용하는 것이 권장되어 집니다.

Security Hub와 SIEM 도구를 함께 사용할 경우에 얻을 수 있는 다른 이점들도 또한 있습니다. 이러한 이점들로는 Security Hub보다 더 오랜 기간 동안 로그를 저장할 수 있거나, 여러 환경의 관리자 계정에서 분석 결과를 모아서 집계하거나, Security Hub 분석 결과를 서로 다른 계정 및 다른 로그 소스와 상호 연관시킬 수 있도록 하는 기능 등을 예로 들 수 있습니다.

이 블로그 게시물에서는 Amazon OpenSearch Service(구 Amazon Elasticsearch Service)를 SIEM으로 사용하고, Security Hub를 통합하여 위에서 예로든 세 가지 사례를 달성하는 방법을 보여드리고자 합니다. Amazon OpenSearch Service는 AWS 완전 관리형 서비스로서, Elasticsearch와 Kibana의 배포, 관리 및 확장을 손쉽게 구현할 수 있도록 서비스를 제공합니다. OpenSearch Service는 분산형 RESTful 검색 및 분석 엔진으로, 다양한 요청에 대해서 증가하는 사용 사례에 적절하게 대응할 수 있도록 디자인되어 있습니다.

Amazon OpenSearch Service는 다른 AWS 서비스들의 로그를 직접 로드할 수도 있고, Amazon Kinesis를 연동하거나, 혹은 Beats-Logstash와 같은 전통적인 에이전트 기반으로 로그를 수집하고 Kibana를 통한 시각화를 구현하는 방식과 같이 그 활용도가 다양하게 확장될 수 있습니다. OpenSearch Service 역시 활성화하여 바로 사용할 수 있는 독자적인 SIEM 도구는 아니지만, 사용자 정의 기능들을 구현하여 SIEM 도구로서 활용될 수 있습니다.

AWS Security Hub 및 SIEM 사용 사례

AWS Security Hub를 AWS Organizations에서 활성화함으로써, 다양한 AWS 및 파트너 서비스의 모든 보안 분석 결과를 한 화면에서 볼 수 있는 이점을 즉시 얻을 수 있습니다. 일부 조직들은 한 단계 더 나아가서, 다음과 같은 이유들로 SIEM 도구와 함께 Security Hub를 연계하여 사용하고 싶어 합니다.

Security Hub의 보안 분석 결과를 서로 다른 계정 및 다른 로그 소스와 상호 연관시키고자 : 고객이 SIEM 도구와 Security Hub를 연계시키는 가장 일반적인 이유입니다. Security Hub 분석 결과 외에 애플리케이션 로그, 데이터베이스 로그, 파트너 로그, 각종 보안 도구의 로그 등 다양한 로그 소스가 있는 경우 이러한 로그 소스들을 단일 SIEM 솔루션으로 통합하는 것이 좋습니다. 그런 다음 Security Hub 분석 결과와 기타 여러 로그들을 통합된 환경에서 확인하고, 의미 있는 연관관계에 대한 적절한 경고를 생성할 수 있습니다.
마지막 업데이트 날짜 이후 90일 이상 지나간 분석 결과를 보관하고자 : 일부 조직에서는 마지막 업데이트 날짜 이후 90일 이상 지나간 보안 로그들을 저장하고자 하거나, 또는 그렇게 하는 것이 요구되어 집니다. 이러한 고객들은 과거에 있었던 이벤트에 대한 조사를 위해서, 또는 보안 감사나 규정 준수 목적으로 장기간 로그를 보관하고자 합니다. 이 경우, SIEM 도구와 Security Hub를 연계시킴으로써 분석 결과를 Amazon OpenSearch Service에서 사용하는 전용 Amazon Simple Storage Service(Amazon S3)버킷에 저장할 수 있습니다.
여러 관리자 계정에 대한 분석 결과들을 통합 집계하고자 : Security Hub는 여러 개의 계정을 사용하시는 고객을 위해서 관리자 계정을 지정하여 통합관리 할 수 있는 기능이 제공됩니다. 즉, 지정된 Security Hub 관리자 계정을 통해서 고객은 구성원 계정들의 데이터를 중앙에서 확인하고 그 설정을 통합하여 관리할 수 있습니다. 또한 고객은 간혹 여러 개의 Security Hub 관리자 계정을 소유하기도 합니다. 이는 고객이 AWS Organizations 내에 여러 개의 Organizations를 구성하여 조직을 관리하는 상황에 해당 합니다. 이러한 경우, 모든 Security Hub 관리자 계정을 하나의 Kibana SIEM에 기반한 단일 OpenSearch Service와 연계시킴으로써 전체 환경을 한눈에 파악할 수 있습니다. 이 관련 블로그 게시물에서는 이러한 사용 사례에 대해 자세히 설명하고 여러 AWS 리전 및 관리자에 걸쳐 Security Hub 분석 결과를 중앙 집중화하는 방법을 보여 줍니다. 여기에 더해서 본 블로그 게시글은 완전한 SIEM 경험을 위해 Kibana와 함께 OpenSearch Service를 사용하는 방법을 소개함으로써 중앙 집중화된 관리 방식에 대한 좀 더 발전적인 구현방안을 제공합니다.

솔루션 구성도

Amazon OpenSearch Service를 활용한 SIEM 구현 다이어그램

< 그림1. Amazon OpenSearch Service를 활용한 SIEM 구현 >

그림 1에 표시된 솔루션은 Amazon OpenSearch Service를 사용하여 SIEM을 생성할 때 얼마나 유연하게 통합이 이루어질 수 있는지를 보여 줍니다. 이 솔루션을 사용하면 여러 계정에 걸쳐 분석 결과를 집계하고, S3 버킷에 결과를 무한정 저장하며, 시각화를 위해 여러 AWS 및 비 AWS 서비스를 한 곳에서 상호 연관시킬 수 있습니다. 본 블로그 게시글에서는 Security Hub와의 통합을 다루고 있지만, 아래와 같이 다른 AWS 서비스도 통합하여 구현할 수 있습니다.

이러한 각 서비스는 전용 대시보드들을 OpenSearch SIEM 솔루션 내에 가지고 있습니다. 이를 통해서 고객은 SIEM 도구가 수집하는 각 서비스와 관련된 분석 결과 및 데이터를 간편하게 확인할 수 있습니다. OpenSearch Service는 또한 고객이 필요에 따라서 통합된 단일 대시보드를 생성하고 여러 서비스를 통합하여 관리할 수 있도록 하는 기능도 제공합니다.

사전 요구사항

모든 계정 및 리전에서 Security Hub와 AWS Config를 사용하도록 설정하는 것이 권장됩니다. 이러한 구성에 대한 좀 더 세부적인 내용은 Security Hub 및 AWS Config 설명서를 참조하십시오. 또한 Security Hub 및 AWS Config를 AWS Organizations와 통합하여 설정을 간소화하고 조직의 모든 현재 및 미래의 계정에서 이러한 서비스들을 자동으로 사용하도록 설정하는 것 역시 권장됩니다.

솔루션의 실행 및 활용

고객의 AWS 환경에서 이 솔루션을 구현하고 실행하려면, 아래의 링크에 포함된 AWS CloudFormation 템플릿을 사용하여 구현하거나, 본 블로그 게시글 뒷부분에 나와 있는 단계에 따라서 사용자가 직접 지정하여 구현하는 (비 AWS 서비스들, 다중 조직간 배포 또는 기존 OpenSearch Service 환경 내에서 실행 등) 배포방식을 구현할 수 있습니다. 이 링크를 통해서 GitHub의 Amazon OpenSearch Service에서 SIEM 구현 방법을 확인하시고 실행하십시오.

이 솔루션을 사용하기에 앞서 그림 2에서 보이는 바와 같이, 이 솔루션 안에 Security Hub 요약 대시보드가 어떻게 표시되는지를 살펴보도록 하겠습니다. 해당 대시보드에 실제 내용이 포함되도록 하기 위해서는 GitHub README의 3. Configuring OpenSearch Dashboards를 따라서 구현 하여야 합니다.

< 그림2. 솔루션에 포함된 미리 정의된 대시보드들 >

본 솔루션의 OpenSearch Service 대시보드 환경을 통해, Security Hub의 모든 주요 보안 분석 결과와 관련된 내용들을 표시하고 강조할 수 있습니다.

여기에는 Security Hub에 통합되어 집계되는 모든 서비스들(GuardDuty, AWS Identity and Access Management (IAM) Access Analyzer, Amazon Inspector, Amazon Macie, AWS Systems Manager Patch Manager)이 포함됩니다. 더불어서 해당 대시보드에는 보안 분석 결과들과 보안 표준 적용 현황이 모두 표시되며 AWS 계정, 분석 결과 유형, 보안 표준 또는 서비스 통합을 기준으로 필터링할 수 있습니다. 그림 3은 본 솔루션을 구축할 경우에 보이는 대시보드에 대한 프리뷰를 보여주고 있습니다.

< 그림3. 대시보드 프리뷰 >

사용 사례 1: Security Hub의 보안 분석 결과를 서로 다른 계정 및 다른 로그 소스와 상호 연관시켜서 적절한 보안경보를 생성하기

이 솔루션은 OpenSearch Service 및 Kibana를 사용하여 Security Hub 분석 결과들과 다른 AWS 및 비 AWS 시스템의 로그들을 모두 검색할 수 있도록 해줍니다. 이후, Security Hub와 다른 이벤트 로그 간의 특정 상관관계를 기반으로 Kibana 내에서 보안경보를 생성할 수 있습니다. Security Hub는 대규모의 로그 통합 및 보안 분석 결과의 수집을 지원하지만, SIEM 도구처럼 상관관계 규칙을 만들 수는 없습니다. 하지만 OpenSearch Service의 SIEM을 사용하면 이러한 상관관계 규칙을 생성할 수 있습니다. 특히 동일한 자원에 대해서 여러 AWS 보안 서비스들이 각각의 분석 결과들을 생성하는 경우에는 조금 더 면밀하게 살펴보는 것이 중요합니다. 왜냐하면 이런 경우, 잠재적으로 더 높은 수준의 위협이나, 다중 위협 요소들을 가지고 있을 수 있기 때문입니다. 고객의 환경에 따라서 Security Hub를 도입한 초기에는 분석 결과의 수가 많을 수 있습니다. 그렇기 때문에, 효과적인 보안 관리를 위해서는 우선순위를 산정하여 즉각적인 보안 조치를 해야 하는 분석 결과를 구분할 필요성이 있습니다. Security Hub는 기본적으로 분석 결과들에 대해서 여러 가지 필터링 규칙들(대상 자원, 계정, 심각도, 그 외 여러 다른 세부 내용에 대한)을 제공하고 있습니다. 이렇게 필터링된 분석 결과들에 대해서 OpenSearch Service 기반의 SIEM을 통해 다양한 방식(이메일, Amazon SNS, Amazon Chime, Slack – AWS Chatbot, 커스텀 webhook 연동)으로 경보를 생성하여 공지를 발송할 수 있습니다. 그러고 나서 이렇게 생성된 경보 공지에 대해서 추가로 대응(티켓 관리 시스템, 보안 대응 전담 대화방, 또는 통합 보안 사고관리 시스템)해 나갈 수 있습니다.

사용 사례 1을 위한 솔루션 개요

< 그림4. 솔루션 개요 구성도 >

그림 4는 사용 사례 1에 대한 솔루션의 개요를 보여줍니다. 이 솔루션을 사용하려면 AWS 계정에서 Security Hub 및 GuardDuty가 활성화되어 있어야 합니다. Security Hub를 비롯한 AWS 서비스의 로그는 S3 버킷으로 수집되고, 그런 다음 자동으로 추출, 변환 및 로드(ETL)된 뒤, AWS Lambda를 사용하여 OpenSearch Service 기반의 SIEM 시스템으로 취합됩니다. 이렇게 취합된 로그를 이용하여 대시보드를 통한 시각화 및 여러 로그 간의 상관관계를 분석할 수 있습니다. 또한 OpenSearch Service 기반의 SIEM 솔루션을 이용하여 CloudTrail 인증 실패 등과 같이, 장애 감지에 사용될 수 있는 규칙들도 생성할 수 있으며, 해당 규칙에 따라서 필요한 로그들을 Amazon SNS를 활용하여 특정 이메일로 전송되도록 구현할 수 있습니다.

사용 사례 1을 솔루션으로 구현하기

이제 OpenSearch에 집계된 로그를 대상으로 하여, 사용자가 정의한 특정 규칙과 일치하는 경우 이메일을 통한 경보가 전달될 수 있도록 워크플로를 설정해 보겠습니다.

Step 1: OpenSearch Dashboards에 분석 결과를 생성하고 시각화하기

Security Hub 및 기타 AWS 서비스는 분석 결과를 Amazon S3의 중앙 집중식 통합 로그 버킷으로 내보냅니다. 여기에는 AWS 보안 분석에서 자주 사용되는 CloudTrail 로그, VPC 흐름 로그 및 GuardDuty 결과 등이 함께 취합될 수 있습니다. 본 단계에서는 이러한 보안 분석에 사용되는 로그들을 각 OpenSearch Dashboards에서 불러와서 의미 있는 데이터로 시각화합니다.

OpenSearch Dashboards 살펴보기

가상의 보안 사고 로그들을 생성합니다. “GuardDuty에서 샘플 결과 생성“을 참조해서 생성할 수 있습니다.
OpenSearch Dashboards에서 Discover 화면으로 이동합니다. Discover 화면은 아래 그림 5에서 보여주는 것처럼 검색 바, 인덱스/디스플레이 필드 리스트, 그리고 시계열 표시창 의 3가지 주요 기능으로 구성되어 있습니다.

< 그림5. OpenSearch Dashboards >
OpenSearch Dashboards에서 log-aws-securityhub-* 또는 log-aws-vpcflowlogs-* 또는 log-aws-cloudtrail-* 또는 원하는 다른 인덱스 패턴을 선택하고 event.module을 가용 필드(Available fields)에서 선택해서 표시 필드(Selected fields)에 나타나도록 추가합니다. 이때, event.module은 로그가 어디에서부터 유래되었는지를 나타내 주는 필드입니다. Security Hub의 경우에는, @log-type에서 Security Hub의 로그가 표시되지만, 실제로 Security Hub에 집계되는 로그가 어디서 왔는지를 표시해 주는 필드는 event.module입니다. (even.module에는, Amazon Inspector나 Firewall Manager, Amazon Macie와 같이 Security Hub 분석 결과로 집계되기 전의 유래가 표시됩니다.) event.module을 추가한 다음에는 필터링을 통해서 원하는 보안 분석 결과의 유래를 한정시킬 수 있습니다. (예를 들자면, Add Filter → “event.module”을 Field로 선택하고, Operator “is”, Value “inspector”를 선택하여 Amazon Inspector에서 유래된 결과만을 볼 수 있습니다.) 본 블로그에서처럼 실제 업무환경이 아닌 테스트환경에서 다양한 로그를 다루고자 할 경우에는 Kinesis Data Generator를 활용하여 가상의 사용자 정의 로그들을 생성할 수 있습니다. 또는 다른 샘플 로그 생성기들을 활용하실 수도 있습니다.
본 솔루션에는 아래와 같이 다른 보안 분석 관련 대시보드들이 포함되어 있으며, 이들에 대해서도 필드와 필터링을 적용하여 시각화할 수 있습니다.
- CloudTrail Summary
- VpcFlowLogs Summary
- GuardDuty Summary
- All – Threat Hunting

Step 2: 로그 기준에 따라 보안 경보 구성하기

다음으로, 로그 기준에 따라서 보안 경보를 구성합니다. 먼저 보안 경보를 받을 대상을 선정하고, 무엇을 모니터링할 지를 설정합니다.

보안 경보 구성

OpenSearch Dashboards 왼쪽 메뉴에서 Alerting을 선택합니다.
Amazon SNS에 대한 세부 내용을 구성하기 위해서, Destinations 탭을 선택하고, Add destinations를 클릭합니다. 그리고 아래의 파라미터들을 이용하여 세부 내용을 작성합니다 :
- Name: aes-siem-alert-destination
- Type: Amazon SNS
- SNS Alert: arn:aws:sns:<AWS-REGION>:<111111111111>:aes-siem-alert
  - <111111111111> 부분을 실제 AWS account ID로 대체 합니다.
  - <AWS-REGION> 부분을 실제 region 정보로 대체합니다. (예를 들자면 us-east-1)
- IAM Role ARN: arn:aws:iam::<111111111111>:role/aes-siem-sns-role
  - 역시 <111111111111> 부분을 실제 AWS account ID로 대체 합니다.
Create 를 선택하여 Alert 대상 설정을 마무리합니다.

< 그림6. E-mail Alert 대상 설정 >
이제 모니터링할 대상을 지정하기 위해서 OpenSearch Dashboards의 왼쪽 메뉴의 Alerting을 다시 선택해 줍니다. 여기서는 모니터링 대상으로 “CloudTrail”에서 생성된 “authentication failure” 이벤트를 대상으로 합니다. 로그 시간을 정규화하기 위해서 @timestamp와 event.ingested 중 하나를 선택합니다. 시간의 기준이 실제 로그의 발생 시간(@timestamp)인지, SIEM가 로그를 수신한 시간(event.ingested)인지의 차이입니다. 발생부터 수신까지의 시간 지연이 큰 경우에는 event.ingested를 사용합니다. 만약 보다 세부적인 조건을 정의하기를 원한다면 Define using extraction query를 사용하여 더욱 세세하게 필터링 조건을 정의할 수 있습니다.
Monitors 탭으로 가서 Create monitor를 클릭합니다.

아래의 파라미터들을 입력합니다. (나머지는 default 값을 그대로 사용합니다.)

Monitor Name : Authentication failed
Monitor defining method : Extraction query editor
Data Source – Index : log-aws-cloudtrail-* (수동으로 입력해 줍니다)

Define extraction query : 아래의 내용으로 입력합니다.

{
    "query": {
        "bool": {
            "filter": [
            {"term": {"eventSource": "signin.amazonaws.com"}},
            {"term": {"event.outcome": "failure"}},
            {"range": {
                "event.ingested": {
                "from": "{{period_end}}||-20m",
                "to": "{{period_end}}"}}
                }
            ]
        }
    }
}

스케줄 관련해서는 아래의 값을 사용합니다.
- Frequency : By interval
- Monitor schedule : Every 3 minutes
Create를 선택하여 모니터링을 생성합니다.

Step 3: Amazon SNS를 통해서 이메일로 경보를 발생시키기 위한 트리거 생성

이제 SNS를 호출하기 위한 경보 발생 조건(트리거)을 생성합니다. Step 2에서 생성한 모니터링 조건이 부합될 경우 경보를 발생시키기 위한 설정입니다. 경보는 기본적으로, 모니터링 조건에 맞는 결과값이 0보다 클 경우에 발생됩니다. 여기서는 이러한 조건을 수정하지 않고 다만 트리거의 이름만 설정해 주도록 하겠습니다.

트리거 생성

Create trigger를 선택하고 Trigger name 부분에 이름을 설정해줍니다. 여기서는 “Authentication failed trigger”라고 정해 주겠습니다.
스크롤을 내려서 Configure actions 부분으로 갑니다.

< 그림7. 트리거 생성 >
트리거가 수행할 행위를 설정해 줍니다. 여기서는 SNS를 발생시키도록 하겠습니다. 아래의 파라미터를 설정해서 이메일 본문에 포함될 내용까지 모두 설정해 줍니다.
- Action name: Authentication failed action
- Destination: aes-siem-alert-destination – (Amazon SNS) 를 선택합니다.
- Message subject: (SIEM) Auth failure alert
- Action throttling: “Enable action throttling” 선택하고, 10분마다 트리거 되도록 제약을 걸어줍니다.
- Message: 아래의 메시지를 복사해서 텍스트 박스에 붙여 넣습니다. 모두 붙여 넣은 다음, 아래쪽에 있는 “Send test message“를 클릭해서 실제로 메일이 잘 전송되는지를 확인합니다.
```
Monitor {{ctx.monitor.name}} just entered alert status. Please investigate the issue.
- Trigger: {{ctx.trigger.name}}
- Severity: {{ctx.trigger.severity}}
- @timestamp: {{ctx.results.0.hits.hits.0._source.@timestamp}}
- event.action: {{ctx.results.0.hits.hits.0._source.event.action}}
- error.message: {{ctx.results.0.hits.hits.0._source.error.message}}
- count: {{ctx.results.0.hits.total.value}}
- source.ip: {{ctx.results.0.hits.hits.0._source.source.ip}}
- source.geo.country_name: {{ctx.results.0.hits.hits.0._source.source.geo.country_name}}
```
< 그림8. Action 구성 >
몇 분 안에 경보 이메일이 전송될 것입니다. 경보 메일의 전송 이력 및 현황을 확인하기 위해서는 아래의 방법을 따르도록 합니다 :
1. OpenSearch Dashboards의 좌측 메뉴에서 Alerting을 선택합니다.
2. Monitors 탭으로 가서, 위에서 생성한 Authentication failed 모니터링 조건을 클릭합니다.
3. History 창을 통해서 설정한 경보의 상태를 확인할 수 있습니다.
< 그림9. E-mail Alert >

사용 사례 1은, 어떻게 다양한 Security Hub 분석 결과를 OpenSearch Service SIEM 솔루션을 활용해서 연동시키는지를 보여주고 있습니다. 더 나아가, AWS Security Hub 분석 결과와 Amazon EventBridge를 연관시키는 절차를 따라 본 솔루션을 더 발전시켜서 보다 복잡한 상관관계에 대한 정보를 구성할 수 있습니다. 그런 다음에 다시 이렇게 구성된 정보를 한 화면에서 볼 수 있도록 OpenSearch Service SIEM 솔루션을 활용할 수 있습니다.

사용 사례 2: 마지막 업데이트 날짜 이후 90일 이상 지나간 분석 결과들 보관하기

Security Hub는 최대 90일까지 이벤트를 저장할 수 있습니다. 하지만 고객에 따라서는 90일 이상 지나간 이벤트에 대해서도 원하는 주기만큼 저장할 수 있도록 유연한 저장 정책을 필요로 하는 경우가 있습니다. 이럴 경우에도 Amazon OpenSearch Service 기반의 SIEM 솔루션을 활용하면, 중앙 집중화된 S3 버킷을 생성하고 Security Hub의 분석 결과 및 다른 다양한 서비스의 로그를 통합하여 수집하고 저장할 수 있습니다. 물론, 해당 버킷의 데이터는 고객이 원하는 만큼 유지될 수 있습니다.

즉, S3 버킷에 통합된 데이터를 무기한으로 저장하거나, S3 객체 수명주기 정책을 설정해서 원하는 보존기간을 지정할 수 있습니다. S3에서 제공하는 수명주기 정책은 다양한 S3 저장소 클래스 간에 객체를 이전하고 또, 특정 보존 기간 이후에는 삭제될 수 있도록 자유로운 구현이 가능합니다. 다른 대안으로 S3 Intelligent-Tiering을 사용하면 사용자의 엑세스 패턴에 따라서 Amazon S3가 자동으로 데이터를 적절한 저장소 클래스로 전환합니다. 수명주기 정책이나 S3 Intelligent-Tiering을 사용하면 Security Hub 또는 OpenSearch Service에서 더 이상 유효하지 않은 데이터를 보존 처리하거나, 백업하는 방식으로 S3에 저장된 데이터 비용을 최적화할 수 있습니다.

이 솔루션에서는 aes-siem-xxxxxxxx-log 라는 이름으로 중앙 집중 저장 버킷이 생성되며, OpenSearch Service에서 사용하는 데이터에 대해서 제약 없이 저장되도록 구성되어 있습니다. Amazon S3 사용자 가이드에는 중앙 집중 저장 버킷에 대해서 사용자가 명시적으로 S3 수명주기 정책을 구성하는 방법이 나와 있습니다. 또는 사용자가 S3 Intelligent-Tiering 구성 방법에서 설명한 대로 직접 구현하여, 데이터가 지정된 저장소 클래스 간에 자동으로 전환되고 보존되도록 할 수 있습니다.

데이터를 보존 처리(Archive)한 이후에는, Amazon Athena를 이용하면 OpenSearch Service에서는 이미 제외된 과거 데이터가 보존된 S3 버킷에 쿼리를 수행할 수 있습니다. 해당 S3 버킷을 중앙 집중화된 보안 이벤트의 보존소(repository)처럼 활용할 수 있기 때문입니다.

사용 사례 3 : 여러 관리자 계정에서 분석 결과를 모아서 집계하기

하나 이상의 Organization을 운영 중인 고객의 경우에는 다수의 Security Hub 관리자 계정들을 가지고 있을 수 있습니다. 이러한 상황에서는 여러 Security Hub 관리자 계정에서 확인된 분석 결과들을 하나의 S3 버킷으로 통합하여 중앙 집중 저장소로 활용하고, 아카이브, 백업 및 해당 통합 S3 버킷에 대한 쿼리를 수행할 수 있으며, 이렇게 통합된 S3 버킷을 기반으로 OpenSearch Service에서 단일 SIEM을 생성하면 관리할 모니터링 도구의 수를 최소화할 수 있습니다.

이를 위해서는 각각의 Security Hub 분석 결과를 저장하는 버킷에서 S3 객체 복제 기능을 사용하여 자동으로 하나의 통합된 S3 버킷으로 그 결과들을 복사하도록 구성합니다. 각 계정 간의 복제를 허용하기 위해 올바른 버킷 권한을 설정하는 방법에 대한 자세한 설명은 이 링크를 참조하십시오. 또는 리전 간 복제가 보안 규정상 요구될 경우, 이 관련 블로그의 게시물을 참조하면 리전 간 Security Hub 분석 결과들이 하나의 S3 버킷에 통합될 수 있도록 구성할 수 있습니다.

AWS Security Hub 이벤트 데이터 보존을 위해서 교차 계정 간 S3 복제를 구성할 경우에, 이 솔루션 내에 Lambda 함수를 이용하여 중앙 집중화된 S3 버킷으로부터 OpenSearch Service로 데이터를 가져올 수 있습니다. 해당 Lambda 함수는 로그 데이터를 자동으로 정규화하고 강화한 뒤, OpenSearch Service로 가져오는 기능을 수행합니다. 따라서 사용자는 S3 버킷 내 데이터 저장소만 설정하면 Lambda function이 자동으로 데이터를 가져오게 됩니다.

마무리

이 블로그 게시물에서는 SIEM과 함께 Security Hub를 사용하여 90일 이상의 분석 결과를 저장하고, 여러 환경의 관리자 계정에서 분석 결과를 모아서 집계하고, Security Hub 분석 결과를 서로 다른 계정 및 다른 로그 소스와 상호 연관시킬 수 있도록 하는 방법을 살펴보았습니다. 여기서 소개된 솔루션을 사용하면, Security Hub과 SIEM을 연동시켜서 더 유연하게 활용할 수 있게 됩니다. 본 블로그에서는 OpenSearch Service에 기반한 자체적인 SIEM을 생성하고 활용할 수 있도록 하는 하나의 솔루션을 다루었습니다. 여기에서 더 나아가서 “분석 도구와 BI 도구를 활용하여 AWS Security Hub 분석 결과 시각화하기” 블로그를 참조하면 본 솔루션 외에도 다양한 방법으로 Security Hub 분석 결과를 통합하고 시각화 할 수 있는 방법들을 확인할 수 있습니다.
또한 “AWS OpenSearch Service 기반의 SIEM 활용 워크샵“을 통해서 더 많은 내용을 익히실 수 있습니다.
이 게시물에 대해 질문이 있는 경우에는 re:Post 내 Security Hub 포럼에 새 글타래를 생성하시거나, AWS Support를 통해서 지원을 받으실 수 있습니다.

– Ely Kahn, AWS Principal Product Manager
– Anthony Pasquariello, AWS Senior Solutions Architect
– Aashmeet Kalra, AWS Principal Solutions Architect
– Grant Joslyn, AWS Solutions Architect
– Akihiro Nakajima, AWS Senior Solutions Architect

이 글은 AWS Security Blog의 How to use AWS Security Hub and Amazon OpenSearch Service for SIEM 한국어 번역입니다. 번역 및 감수는 AWS Security SA이신 황재훈님이 해주셨습니다.

Amazon Web Services 한국 블로그