security-monitoring

GitLab CI/CD 및 Duo를 이용한 탐지 테스트 자동화 (새 탭에서 열림)

GitLab의 신호 엔지니어링(Signals Engineering) 팀은 보안 모니터링 파이프라인이 예기치 않게 중단되는 '침묵하는 실패'를 방지하기 위해 자동화된 탐지 테스트 프레임워크인 **WATCH(Weekly Attack Testing for Continuous Health)**를 개발했습니다. 이 프레임워크는 스테이징 환경에서 실제 악성 행위를 시뮬레이션함으로써 로그 수집부터 SIEM 탐지, SOAR 알림 라우팅에 이르는 전체 과정을 엔드투엔드(End-to-End)로 검증합니다. 이를 통해 보안팀은 인프라 변경이나 설정 오류 속에서도 핵심 탐지 로직이 상시 정상 작동한다는 확신을 얻을 수 있습니다. ### 기존 탐지 검증 방식의 한계 * **로그 재주입의 맹점:** 단순히 과거의 악성 로그를 SIEM에 다시 밀어 넣는 방식은 실제 로그 소스에서 SIEM으로 데이터가 흐르는 '로그 수집(Ingestion)' 단계의 오류를 포착할 수 없습니다. * **배포와 실행의 간극:** '코드로서의 탐지(Detections as Code)' 파이프라인은 탐지 규칙이 성공적으로 배포되었는지는 확인할 수 있지만, 실제 환경에서 해당 규칙이 트리거되어 경보까지 이어지는지는 보장하지 못합니다. * **환경의 가변성:** 로그 스키마 변경, SIEM 업데이트, 파이프라인 오설정 등 탐지 시스템을 망가뜨릴 수 있는 변수는 무수히 많으며, 이는 실제 사고 발생 시 경보가 울리지 않는 치명적인 결과로 이어질 수 있습니다. ### WATCH 프레임워크의 작동 원리 * **무작위 스케줄링:** 매주 GitLab CI/CD 파이프라인이 활성화된 모든 테스트를 탐색하고, 이를 일주일 중 무작위 시간대에 분산 배치합니다. 이는 테스트가 예측 가능해지는 것을 막고 실제 위협 상황과 유사한 환경을 조성합니다. * **사전 알림 및 등록:** 테스트 실행 직전, WATCH는 SOAR 시스템에 '사전 알림'을 보내 예상되는 탐지 항목을 등록하고 추적 가능한 기록을 생성합니다. * **공격 시뮬레이션:** 스테이징 환경에서 관리자 계정 비밀번호 재설정이나 수상한 API 호출과 같은 실제 공격 행위를 스크립트로 실행합니다. * **알림 상관관계 분석:** SIEM에서 발생한 경보가 실제 침해 사고인지 WATCH 테스트인지 판별하기 위해 '실행 시간, 행위자 식별자(IP/ID), 탐지 규칙 ID'라는 세 가지 요소를 대조합니다. 이를 통해 테스트 경보가 실제 사고 대응팀(SIRT)으로 에스컬레이션되는 것을 방지합니다. ### GitLab CI/CD를 활용한 파이프라인 구조 * **`schedule_pipelines` 단계:** 전체 테스트를 그룹화하고 무작위 실행 시간이 설정된 하위 파이프라인을 생성하여 일주일간의 테스트 일정을 관리합니다. * **`run_tests` 단계:** 할당된 시뮬레이션을 실제로 수행하며, 실행 통계와 SOAR 레코드 ID를 저장하여 후속 단계에서 검증할 수 있도록 준비합니다. * **`pages` 단계:** SOAR 시스템을 쿼리하여 경보가 정상적으로 생성 및 라우팅되었는지 최종 확인합니다. 결과는 GitLab Pages 대시보드에 업데이트되며, 탐지 실패 시 보안팀의 슬랙 채널로 즉시 알림을 보냅니다. 상용 침해 및 공격 시뮬레이션(BAS) 도구는 비용이 많이 들고 개별 기업의 특수한 탐지 스택에 맞춤화하기 어렵습니다. GitLab의 WATCH 사례처럼 자사의 CI/CD 인프라와 SOAR를 결합한 자동화 프레임워크를 구축하면, 저비용으로도 보안 모니터링 시스템의 건강 상태를 지속적으로 검증하고 신뢰도를 높일 수 있습니다.

eBPF를 활용한 실시간 파일 모니터링 확장: 분당 수십억 개의 커널 이벤트를 필터링하는 방법 (새 탭에서 열림)

Datadog은 현대적인 대규모 인프라에서 신뢰할 수 있는 파일 무결성 모니터링(FIM) 시스템을 구축하기 위해 기존의 주기적 스캔이나 `auditd` 방식 대신 eBPF 기술을 채택했습니다. 이들은 커널 수준에서 실시간 가시성을 확보함으로써 프로세스 및 컨테이너 맥락이 포함된 상세한 보안 데이터를 수집하는 데 성공했습니다. 특히 초당 수십억 건에 달하는 방대한 이벤트를 처리하기 위해, 데이터의 94%를 커널 내부에서 미리 걸러내고 에이전트 단위에서 로컬 규칙 검사를 수행하는 2단계 필터링 아키텍처를 통해 시스템 성능 저하 없이 보안 가시성을 극대화했습니다. ### 기존 모니터링 방식의 기술적 한계 * **주기적 파일 시스템 스캔:** 스캔 사이에 발생했다가 복구된 공격자의 변경 사항을 감지할 수 없으며, 파일이 '어떻게', '왜', '누구에 의해' 변경되었는지에 대한 맥락 정보가 부족합니다. * **inotify:** 파일 이벤트와 프로세스 또는 컨테이너 간의 상관관계를 파악하는 데 필요한 시스템 레벨의 컨텍스트를 제공하지 못합니다. * **auditd:** 시스템 부하가 높은 환경에서 과도한 오버헤드가 발생하며, 대규모 환경에서의 확장성 문제가 고질적인 단점으로 지적됩니다. ### eBPF를 활용한 심층 가시성 확보 * **실시간 커널 모니터링:** eBPF를 통해 커널에서 직접 실시간 파일 활동을 관찰함으로써, 파일 변경 사실뿐만 아니라 이를 유발한 프로세스와 컨테이너 정보까지 포함된 풍부한 보안 데이터를 확보했습니다. * **데이터 폭증의 난제:** 모든 인프라에서 발생하는 파일 관련 이벤트가 분당 100억 건을 넘어서며, 이벤트당 약 5KB인 데이터를 모두 전송할 경우 초당 수 테라바이트의 네트워크 트래픽이 발생하는 심각한 규모의 문제에 직면했습니다. ### 에이전트 기반의 로컬 규칙 필터링 * **에지(Edge)에서의 결정:** 수집된 모든 데이터를 백엔드로 전송하는 대신, 각 호스트의 에이전트에서 로컬 보안 규칙에 따라 데이터를 1차 검증합니다. * **트래픽 절감:** 로컬 필터링을 통해 백엔드로 전송되는 데이터를 분당 100억 건에서 약 100만 건 수준으로 획기적으로 줄여, 네트워크 비용과 시스템 자원 소모를 최소화했습니다. ### 커널 내부 프리필터링(In-kernel prefiltering)을 통한 최적화 * **링 버퍼(Ring Buffer) 드롭 방지:** 에이전트가 처리할 수 있는 속도보다 더 빠르게 이벤트가 생성될 경우 데이터 유실이 발생하는데, 이를 막기 위해 처리 로직의 상당 부분을 커널 내 eBPF 프로그램으로 이동시켰습니다. * **2단계 평가 모델:** * **커널 내부 필터링:** 'Approvers'와 'Discarders' 개념을 도입하여, 무관한 시스템 호출(syscall)의 94%를 유저 공간으로 넘기기 전에 커널 단계에서 즉시 폐기합니다. * **유저 공간 평가:** 커널을 통과한 선별된 이벤트에 대해서만 유저 공간에서 상세한 맥락 정보를 결합하고 복잡한 상관관계 분석을 수행합니다. ### 실용적인 제언 대규모 시스템에서 FIM을 구현할 때는 단순한 데이터 수집보다 '불필요한 데이터의 조기 차단'이 성능의 핵심입니다. eBPF를 활용하되 모든 로직을 커널에 넣기보다는, 커널 내에서의 가벼운 필터링과 유저 공간에서의 심층 분석을 결합한 하이브리드 접근 방식을 취하는 것이 확장성과 보안성을 모두 잡는 전략이 될 수 있습니다.

ChatOps를 통한 클라우드 보안 가시성 향상 (새 탭에서 열림)

Datadog은 대규모 AWS 환경에서 발생하는 막대한 API 호출을 효율적으로 감시하기 위해 서버리스 기반의 보안 모니터링 및 알림 파이프라인을 구축했습니다. 이 시스템은 모든 API 활동을 실시간으로 분석하여 잠재적 위협과 설정 오류를 탐지하며, Slack과 Duo를 활용한 사용자 직접 확인 절차를 통해 보안팀의 운영 부담을 최소화합니다. 결과적으로 적은 인력으로도 수많은 계정의 보안 상태를 높은 가용성으로 유지할 수 있는 중앙 집중형 구조를 완성했습니다. ### 데이터 필터링과 위험도 분류 * **로그 중심의 선택적 집중:** 모든 API 호출을 실시간 감시하는 것은 불가능하므로, 보안상 의미 있는 API를 식별하여 로그(Log), 알림(Notify), 경고(Alert)의 세 단계로 분류했습니다. * **단계별 대응 체계:** 단순 변경(CreateGroup 등)은 추후 조사를 위해 로그로 남기고, 권한 변경(CreateUser 등)은 실행한 엔지니어에게 직접 확인을 요청하며, 치명적인 설정 오류(보안 그룹을 0.0.0.0/0으로 개방 등)는 즉시 보안팀에 경고를 보냅니다. * **엔지니어 직접 검증:** 알림 단계에서는 해당 API를 호출한 엔지니어에게 Slack 메시지를 보내 본인이 수행한 작업인지 확인하게 함으로써, 계정 탈취 여부를 확인하는 동시에 보안팀의 오탐(False-positive) 분석 업무를 획기적으로 줄였습니다. ### 중앙 집중형 아키텍처 및 파이프라인 * **교차 계정 데이터 통합:** 15개 이상의 AWS 계정에서 발생하는 이벤트를 하나의 중앙 보안 계정으로 수집하기 위해 CloudWatch 이벤트 규칙과 SNS, SQS를 조합했습니다. * **지연 및 비용 최적화:** CloudWatch가 SQS로 직접 데이터를 보내지 못하는 제약을 SNS를 통해 해결했으며, Lambda를 2분마다 트리거하여 SQS 큐의 데이터를 처리함으로써 실시간성과 알림 피로도 사이의 균형을 맞췄습니다. * **인프라 코드화:** Terraform을 사용하여 모든 AWS 계정에 동일한 데이터 수집 설정을 신속하고 일관되게 배포할 수 있는 구조를 갖췄습니다. ### 보안 오케스트레이션과 자동화 로직 * **워크플로우 자동화:** 보안 오케스트레이션 플랫폼인 Komand(현 Rapid7 InsightConnect)를 도입하여 복잡한 결정 트리와 브랜칭 로직을 구현했습니다. * **상세 분석 플러그인:** 커스텀 플러그인을 통해 호출자 identity, API 파라미터 내용, 요청 시간 등을 정밀하게 파싱하여 경고 여부를 결정합니다. * **다중 인증(MFA) 연동:** 엔지니어가 Slack 알림에서 본인의 작업임을 승인하면 Duo Push를 통해 2차 인증을 거치게 되며, 응답이 없거나 본인 작업이 아니라고 응답할 경우에만 보안팀에 비상 호출(PagerDuty)이 전달됩니다. * **가시성 확보:** 모든 워크플로우 실행 결과는 Elasticsearch로 전송되어 대시보드화되며, 이를 통해 보안 이벤트 추세와 시스템 효율성을 측정합니다. 대규모 클라우드 환경을 운영하는 조직이라면 모든 이벤트를 보안팀이 직접 처리하려 하기보다, 이처럼 자동화된 오케스트레이션과 사용자 참여형 검증 시스템을 구축하여 '확장 가능한 보안(Scalable Security)'을 실현하는 것이 권장됩니다.