인터파크트리플의 보안 가시성 확보를 위한 SIEM 구축 사례

일상을 벗어난 모든 즐거움! 인터파크트리플은 광범위한 인벤토리로 전세계 어디든 넓고 깊은 비일상의 경험을 제공하고, 축적된 데이터로 고객을 이해하고 차별화된 컨텐츠로 상상 이상의 경험을 제공하며, 혁신을 주도하는 글로벌 기술 플랫폼을 운영하고 있습니다.

이러한 인터파크트리플에서는 지속적으로 고도화, 지능화되어 가는 위협에 효과적으로 대응하고 가시성 확보를 위하여 기존의 SIEM(Security Information and Event Management) 환경을 새롭게 개선하기 위하여, 표준화된 스키마 체계를 도입하고 SaaS 애플리케이션으로까지 데이터 수집 범위를 확대하여 Cloud-native의 SIEM을 구축하게 되었습니다. SIEM은 현대 기업의 보안 환경에서 중요한 역할을 합니다. 이를 통해 AWS 서비스 및 리소스에서 발생하는 보안 이벤트와 로그 데이터를 중앙에서 모니터링하고, 보안 가시성을 높여 잠재적인 위협을 신속하게 탐지하고 대응할 수 있습니다. 또한, 클라우드 기반의 SIEM 을 구성하면 클라우드에 완전히 통합할 수 있는 다양한 서비스와 도구를 이용할 수 있으며 필요에 따라 리소스를 동적으로 확장하거나 축소할 수 있어 비용 효율적입니다. 이번에 소개하는 SIEM 개선을 통해 인터파크트리플은 보안 가시성의 범위를 높였고, 보안 모니터링, 위협 탐지, 보안 분석 등의 작업을 통합하였으며, 보안 운영을 간소화하고 효과적인 체계 구축의 발판을 마련하였습니다.

배경

인터파크트리플은 온프레미스와 클라우드 인프라를 함께 사용하는 하이브리드 환경에서, 보안 데이터를 더 쉽게 분석하고, 조직 전체의 보안을 더욱 잘 이해하며, 워크로드, 애플리케이션, 데이터 보호를 개선하기 위해 지속적으로 노력하고 있습니다. 여기에 더 나아가, SaaS 애플리케이션의 보안 데이터를 모니터링하여 보안 분석가와 IT 관리자가 기업 보안 위협 가능성을 신속하게 파악하고 대응하기 위한 시스템을 구축하고자 하였습니다.

하지만, 온프레미스, 클라우드 및 SaaS 애플리케이션에서 운영되는 여러 서비스에서 발생되는 로그 데이터는 각자 서로 형식이 다르기 때문에 데이터에서 필요한 보안 인사이트를 얻는 방법을 결정하기가 어려웠습니다. 이러한 문제를 해결하기 위해 개방형 표준인 OCSF(Open Cybersecurity Schema Framework)를 채택하여 로그 및 이벤트 데이터를 정규화하여 수집하고 보안 분석 시 상관관계를 함께 분석하여 침해 사고 대응 시간을 줄이고자 하였습니다.

OCSF란?

OCSF(Open Cybersecurity Schema Framework)는 사이버 보안 데이터의 표준화된 스키마를 제공하는 표준 프레임워크입니다. OCSF는 다양한 보안 데이터 소스(로그, 이벤트, 메트릭 등)의 데이터를 통합하고 표준화할 수 있는 공통 스키마를 제공하여, 서로 다른 보안 솔루션 간 데이터 교환 및 분석을 가능하게 합니다. 또한 OCSF는 유연하게 확장될 수 있어 새로운 보안 데이터 유형이 등장하더라도 쉽게 적용할 수 있습니다.  Amazon Security Lake와 같은 솔루션은 OCSF 표준을 지원하여, 다양한 보안 데이터 소스의 데이터를 통합하고 분석할 수 있게 해줍니다. 현재 AWS Verified Access와 같은 AWS의 일부 서비스에서는 기본 로그 포맷을 OCSF로 제공하고 있으며, Security Lake에서는 OCSF를 지원하는 서비스를 더 확장할 예정입니다.

솔루션 및 구현 내용

그림 1. 인터파크트리플의 SIEM 아키텍처

인터파크트리플에서는 Cloud-native SIEM을 목표로 AWS AppFabric과 Security Lake를 활용하여 보안 데이터를 통합하고 정규화하고 있습니다. AWS AppFabric을 통해 다양한 SaaS 애플리케이션의 보안 데이터를 수집하고 OCSF 표준에 따라 정규화 합니다. 그리고 Security Lake를 사용하여 정규화된 보안 데이터를 중앙 집중식으로 저장하고 관리합니다. Security Lake는 OCSF 표준을 지원하므로, 다양한 형식의 보안 데이터를 표준화된 방식으로 수집할 수 있습니다.

다음으로, Amazon OpenSearch Service를 활용하여 Security Lake에 저장된 보안 데이터에 대해 시각화하고 실시간 분석을 수행합니다. OpenSearch Service는 강력한 검색 및 분석 기능을 제공하므로, 보안 분석가와 IT 관리자가 신속하게 보안 위협을 파악하고 대응할 수 있습니다.

OpenSearch Service에는 단기간만 보안 로그를 저장하고, Security Lake를 통해 구성된 Amazon S3에는 장기간 보안 로그를 저장합니다. 이때, S3의 수명 주기 정책을 사용하여 객체를 더 저렴한 스토리지 클래스로 전환하거나 아카이브 또는 삭제 하도록하여 비용 효율적 관리할 수 있습니다. S3에 저장된 데이터는 Amazon Athena를 통해 Ad-hoc한 쿼리를 실행한다거나 보안 감사시에 활용 될 수가 있습니다.

보안 데이터 수집

먼저 각 보안 데이터를 수집하여 Security Lake에 적재하는 파이프라인에 대해서 살펴보겠습니다. 보안 데이터 수집 대상은 크게 1) 온프레미스, 2) SaaS 애플리케이션, 3) AWS Native 서비스 이렇게 3가지로 구별됩니다. 각 수집 대상별로 파이프라인을 어떻게 구성하였는지 상세 아키텍처를 통해 살펴보도록 하겠습니다.

온프레미스 보안 데이터 수집 파이프라인

온프레미스 서버에서는 NAC(네트워크 접근제어), IPS(침입 방지 시스템), DLP(데이터 손실 방지), EDR(엔드 포인트 탐지 및 대응) 등과 같은 다양한 보안 장비로부터 발생되는 데이터를 수집하여 적재하고 있습니다. 이러한 데이터를 수집하여 S3로 적재하기 위한 솔루션으로 AWS 파트너사인 Cribl의 솔루션을 사용하고 있습니다. Cribl은 지표, 이벤트, 로그 등 다양한 관찰 가능한 데이터 소스를 파이프라인을 통해 활용할 수 있게 해주는 보안 분석 및 자동화 도구이면서 OCSF 포맷으로 변환해 줄 수 있는 기능을 제공해 줍니다.

그림 2. 온프레미스와 Security Lake 통합 아키텍처

1. 온프레미스의 보안 장비의 로그는 syslog를 통해 Cribl로 보내고, 보안 Database의 데이터는 Cribl이 수집하게 됩니다. 이때, 전송은 AWS Direct Connect의 전용선을 이용하기 때문에 높은 보안성과 일관된 성능을 보장받게 됩니다.
2. Cribl은 Multi-AZ로 구성하여 고가용성을 확보하고 앞단에 Internal NLB를 두어 고정 Private IP로 통신하게 됩니다.
3. Cribl에서 S3로 전송 시에는 Gateway Endpoint를 이용하여 S3로 전송합니다. 이렇게 구성하면 VPC에 Internet Gateway나 NAT Gateway가 필요하지 않고 추가 비용 없이 VPC에서 S3에 액세스할 수 있습니다.

SaaS 애플리케이션 보안 데이터 수집 파이프라인

SaaS 애플리케이션에서는 1password, Confluence, Github, Jira, Okta, Google Workspace의 데이터를 수집하여 적재하고 있습니다. 각 SaaS 애플리케이션에서 발생하는 로그들을 수집하기 위해 AppFabric을 사용하고 있습니다. AppFabric을 사용하면 손쉽게 SaaS 애플리케이션에 연결할 수 있고, SaaS 마다 다른 로그 포맷을 OCSF로 정규화하는 작업을 자동화할 수 있습니다.

그림 3. SaaS 애플리케이션과 Security Lake 통합 아키텍처

1. 수집하고자 하는 대상 SaaS에 AWS AppFabric을 연결합니다. 이를 위해, AppFabric에서 일회성 작업인 앱 번들을 만들고 나서 SaaS 별로 AppFabric의 애플리케이션 인증을 진행합니다. AppFabric을 사용할 때의 장점 중 하나는 코드를 전혀 작성하지 않아도 AppFabric이 SaaS 애플리케이션에 직접 연결된다는 것입니다.
2. AppFabric에서 SaaS의 보안 로그를 수집하여 S3로 적재합니다. 이 단계에서 보안 로그를 수집 및 OCSF로 정규화하여 Staging Bucket으로 전송합니다. 아쉽게도 글을 작성하는 이 시점에는 AWS AppFabric의 서울 리전이 출시 전이고, 다른 리전의 S3로 전송이 불가능하였습니다.
3. Tokyo 리전에 있는 Staging Bucket에 Object가 생성되면, 그 이벤트를 Amazon SQS(Simple Queue Service)로 전송하고 AWS Lambda가 트리거 되어 해당 Object를 Seoul 리전에 있는 Bucket으로 이동시킵니다. Lambda 코드에는 Security Lake의 Custom Source 저장 구조에 따른 경로 변경 작업들이 포함되어 있습니다. 해당 샘플 코드를 참고하여 작업하였습니다.

AWS Native 서비스 보안 데이터 수집 파이프라인

AWS의 Native 서비스에서는 Amazon Route 53의 DNS 쿼리 로그와 AWS Security Hub에 통합된 Findings, 그리고 AWS CloudTrail 로그를 수집하고 적재하고 있습니다. AWS 서비스의 경우에는 Security Lake 콘솔에서 클릭 몇 번 만으로 손쉽게 통합하여 수집 및 적재를 시작할 수 있고, 각 서비스에서 발생되는 로그를 OCSF로 정규화하는 작업을 자동화할 수 있습니다.

그림 4. AWS 서비스들과 Security Lake 통합 아키텍처

1. 수집하고자 하는 AWS서비스를 선택하여 활성화시켜 줍니다. 아래는 Security Lake의 콘솔에서의 설정 화면입니다.
2. 선택한 서비스가 활성화가 되게 되면 Security Lake는 자동으로 수집하여 OCSF로 정규화하여 S3 버킷에 저장합니다. 이 버킷은 Security Lake에 의해 생성되고 관리됩니다.

위에 설명 드린 총 3개의 보안 데이터 수집 파이프라인을 통하여 다양한 소스의 보안 데이터를 Security Lake에 통합하여 중앙 집중화하고 있으며, 보안 데이터는 Parquet 형식으로 S3에 저장하여 스토리지 공간을 절약하고 조회 시 성능을 높이고 있습니다. 또한, Security Lake를 구성하면 AWS Glue의 Crawler와 Data catalog가 자동으로 설정되기 때문에 S3에 저장된 데이터는 Athena에서 즉시 쿼리가 가능합니다.

보안 데이터 가시화

Security Lake에 중앙 집중화된 보안 데이터를 가시화하고 분석하기 위해 Opensearch Service로 데이터를 적재합니다. 이를 위해 Amazon OpenSearch Ingestion을 이용하여 데이터 파이프라인 구성을 하고 있습니다.

그림 5. Security Lake와 OpenSearch Service 통합 아키텍처

1. OpenSearch Ingestion은 오브젝트 생성에 대한 이벤트로부터 필요한 컨텍스트 정보를 얻기 위해 Security Lake의 구독자로 등록되어 있습니다.
2. Security Lake는SQS를 통해 구독자에게 알림을 보냅니다.
3. 알림을 받은 OpenSearch Ingestion은 S3 버킷에서 Parquet 형식의 보안 데이터를 읽고 보안 로그를 JSON 문서로 변환하여 OpenSearch Service로 색인 합니다.

OpenSearch Service에 저장된 다양한 소스의 데이터를 활용하여 필요한 대시보드, 알림, 리포팅 등을 구성하여 보안 분석가는 조직의 인프라에 대한 가시성을 확보하고, 이상 활동을 모니터링하고, 잠재적인 보안 위협을 실시간으로 탐지할 수 있습니다.

특히, OpenSearch의 대시보드를 구성하면 조직의 전반적인 보안 상황을 한눈에 파악할 수 있고, 실시간으로 보안 이벤트를 모니터링할 수 있습니다. 특정 이벤트의 확인을 넘어서 대시보드를 통해 현재 발생하는 현황 및 트렌드를 이해하는 것도 중요합니다. 몇 가지 대시보드를 살펴보며 어떤 인사이트를 가져볼 수 있는지 확인해 보겠습니다.

그림 6. 사용자 접속 기록 모니터링 대시보드

이 대시보드에서는 사용자 접속 기록을 모니터링하고 있습니다. 국가별 로그인 기록이라든지 로그인 성공, 실패 등과 같은 이상 패턴을 확인하고 알림을 받을 수가 있습니다. 이를 통해 무차별 암호 대입 공격과 같은 이상 활동에 대응할 수 있습니다. 접속하는 클라이언트의 OS 현황, 시간대별 로그인 시도 현황, TOP 10 정보를 보면 인증 관련 우리 회사의 트렌드를 파악해 볼 수가 있어, 기존에 로그 데이터로 만 존재하던 데이터에 가시성을 확보할 수가 있게 되었습니다. 로그인 실패가 많은 경우 왜 실패가 많은 지 찾아보게 되면서 새로운 인사이트를 얻을 수 있습니다.

그림 7. 리포지토리 관련 데이터 대시보드

이 대시보드에서는 리포지토리 관련한 데이터를 표현하고 있습니다. Public 하게 오픈되어 있는 비율은 얼마나 되고, 어떤 요청 타입이 많고 일자별 추이 등을 파악할 수 있습니다.

그림 8. CloudTrail 정보 기반 대시보드

이 대시보드에서는, AWS의 CloudTrail 정보를 기반으로 어카운트별 현황, 주요 이벤트 이름, 에러코드, 시간대별 이벤트 발생 현황, 요청하는 사용자 Agent 정보를 담고 있습니다.

일반적인 정보일 수 있지만 단순한 텍스트 데이터가 아니라 가시성을 갖는다는 것은 다른 의미를 가집니다. 해당 데이터가 갖는 수치, 시간대별, 일별 그리고 다른 데이터와의 연관성까지 연결하여 들여다보면 기존에는 들여다보지 못했던 인사이트를 찾아볼 수도 있고, 어떤 것을 개선해야 할지 또 우리 회사의 현황은 어떤 지를 파악할 수 있습니다. 더불어 대시보드에 표시된 정보는 PDF, CSV 등의 형식으로 보고서를 만들 수 있고, 이를 정기적으로 발송하여 리뷰 할 수 있습니다. 또, 이러한 보고서를 활용하여 경영진 등 다른 이해관계자들에게 보안 현황을 효과적으로 전달할 수 있습니다.

잠재적인 보안 위협을 탐지하고 신속하게 대응을 하기 위해서는 알림 채널로 경고를 전송할 수 있어야 합니다. 이를 위해, OpenSearch Service 에서는 알림 기능을 기본적으로 제공하고 있지만 Security Analytics를 이용하면 Detector를 만들고 Sigma 룰을 사전 정의하여 finding을 생성하고 탐지된 finding 기반으로 알림을 보내는 더욱 고도화된 알림 체계를 구성하실 수 있습니다.

그림 9. Security Analytics의 Overview 대시보드

위처럼 Security Analytics의 Overview 대시보드를 통해 Finding과 알림에 대한 정보를 손쉽게 확인하실 수 있습니다. 또한, 상관관계 엔진에서 생성된 정보를 시각화하여 제공하여 특정 상관관계에 집중하여 추가 인사이트를 얻을 수도 있습니다. 하나의 로그 소스뿐만 아니라 연관되는 다른 로그 소스와의 결합을 통해 위협을 파악하는 데 있어서 연관성을 빠르게 들여다볼 수 있습니다.

그림 10. Security Analytics의 상관관계 대시보드

마지막으로 앞서 언급한 Sigma 룰에 대해 살펴보겠습니다. Sigma는 네트워크에서 트래픽을 탐지할 때 Snort 또는 Suricata 엔진을 이용하고, 파일에서 탐지하는 경우는 YARA 룰을 이용합니다. 이와 같이 SIEM 시스템을 위한 Signature 포맷으로 로그 이벤트에 대해 탐지를 수행할 수 있는 공개된 표준 포맷으로, 이를 통해 탐지 패턴을 서로 공유할 수 있도록 하여 누구나 탐지에 활용할 수 있습니다. YAML로 구성된 문법으로 로그 이벤트에서 의심스러운 행위를 탐지하기 위한 패턴을 제공하고 있습니다. 오픈 서치에서는 이미 2,200 개 이상의 Sigma 탐지 룰을 제공하고 있고, MITRE ATT&CK과 정보가 매핑되어 있습니다. 이미 제공되는 룰을 통해 OpenSearch Service로 유입되는 이벤트에서 위협을 탐지하고 또는 고객이 직접 커스텀 룰을 만들어 손쉽게 룰 작성도 가능합니다.

그림 11. OpenSearch에서 기본 제공하는 Sigma 탐지 패턴 룰

Opensearch의 Security Analytics의 기능인 상관관계와 Sigma 탐지 패턴을 통해 SIEM 로서의 기능을 더욱 강화할 수 있습니다.

마무리

인터파크트리플의 Cloud-native SIEM 구축 사례는 복잡한 하이브리드 환경에서의 보안 데이터 통합과 분석의 중요성을 잘 보여줍니다. AWS Security Lake와 AppFabric을 활용한 OCSF 기반의 데이터 정규화는 다양한 소스의 보안 데이터를 효과적으로 통합하고 분석할 수 있게 해줍니다. 이러한 접근 방식은 보안 위협에 대한 가시성을 높이고 대응 시간을 단축시키는 데 크게 기여할 것입니다. 앞으로 이 시스템은 AI/ML 기술의 도입을 통해 더욱 지능적인 위협 탐지와 대응이 가능할 것으로 기대됩니다. 이 사례가 다른 기업들에게도 효과적인 보안 데이터 관리와 분석을 위한 좋은 참고가 되길 바랍니다.