siem

4 개의 포스트

figma4분 읽기큐레이션 요약

에이전트를 활용해 Figma의 내부 시스템을 보호하는 방법 | Figma 블로그

Figma는 SIEM 경보 대응에 AI 에이전트를 도입해 과거 조사 기록 검색, 포렌식 분석, 보안 데이터 질의, 코드 수정과 PR 생성까지 자동화했다. 그 결과 경보의 해결까지 걸리는 시간을 71% 줄였으며, 온콜 엔지니어의 업무를 단순한 정보 수집에서 판단과 검토 중심으로 바꾸었다. 핵심은 기존 업무 흐름을 유지하면서 경보와 조사 지식을 지속적으로 축적·검색하는 시스템을 구축한 것이다. ## 보안 경보 대응의 병목 - Figma의 SIEM인 Panther는 클라우드 인프라, 엔드포인트, SaaS, ID 시스템을 점검한다. - 문제가 감지되면 Slack에 경보를 게시하고 Asana 티켓을 생성한다. - 기존 온콜 엔지니어는 다음 정보를 수동으로 모아야 했다. - 같은 경보가 과거에 발생했는지 - 이전 조사에서 어떤 결론을 내렸는지 - 관련된 Slack 대화가 있는지 - 문제를 해결할 예정인 PR이 존재하는지 - 클라우드 환경과 개발 도구가 빠르게 변하면서 경보의 유형과 대응 방법도 계속 바뀌었다. - 따라서 단순히 경보를 분류하거나 중복 제거하는 것만으로는 업무 부담을 충분히 줄일 수 없었다. ## 검색 시스템에서 에이전트 시스템으로의 확장 - 초기 목표는 새 경보가 발생했을 때 과거 온콜 엔지니어의 판단과 대응 기록을 찾아주는 retrieval layer를 만드는 것이었다. - 이후 시스템은 다음 기능을 수행하는 에이전트 구조로 확장됐다. - 경보 조사 - 보안 데이터 레이크와 감사 로그 질의 - 관련 코드 변경 작성 - PR 생성 - 과거 조사 결과를 기억하고 다음 대응에 활용 - Figma는 코드베이스에서도 에이전트를 활용해 Okta와 AWS 같은 민감한 도구의 설정 변경을 점검하고 있었다. - 그러나 SIEM이 발견하는 광범위한 운영·인프라 문제까지 다루기 위해서는 코드 분석을 넘어선 별도의 시스템이 필요했다. ## RAG 계층: 경보에 기억을 부여하기 - Figma는 AWS Bedrock Knowledge Bases와 Amazon Kendra를 이용해 검색 증강 생성(RAG) 기반의 경보 분류 시스템을 구축했다. - Panther 경보가 발생하면 Lambda 핸들러가 원본 payload를 표준화된 문서로 변환해 Kendra에 색인한다. - 다음과 같은 구조화된 정보를 추출해 검색 속성으로 저장한다. - `p_any_ip_addresses`에서 추출한 IP 주소 - `p_any_usernames` 및 공급자별 사용자 필드의 행위자 정보 - ARN에서 추출한 AWS 계정 ID - 경보 제목, 심각도, 태그, 생성 시각 - 경보 유형, 상태, 조사 맥락의 존재 여부 - 예시 속성에는 `alert_id`, `alert_type`, `severity`, `status`, `created_at`, `has_investigation_context`가 포함된다. ## 의미 검색과 최신성 반영 - 새로운 유사 경보가 발생하면 경보 제목을 주요 검색 벡터로 사용해 Bedrock에 의미 검색을 요청한다. - 검색 질의에는 조사 맥락이 있는 기록만 우선하도록 다음 조건을 추가한다. ```text {경보 제목} has_investigation_context=1 ``` - 경보 제목은 일반적으로 탐지 규칙 이름과 행위자 사용자 이름으로 구성된다. - 단순히 가장 유사한 기록을 찾는 것보다 최근 기록을 우선하도록 검색 결과를 편향시켰다. - 대응 절차와 환경이 계속 변하기 때문에, 6개월 전의 정확히 같은 경보보다 이틀 전에 발생한 유사 경보가 실무적으로 더 유용할 수 있다. - 이를 통해 검색 결과가 현재의 운영 방식과 최신 조사 관행을 더 잘 반영하게 된다. ## Slack 조사 기록의 자동 축적 - `investigation_context`는 온콜 엔지니어가 Slack 경보 스레드에 남긴 조사 결과와 판단을 의미한다. - 조사 내용이 없는 종료 경보는 단순히 “닫혔다”는 사실만 제공하므로 재사용 가치가 낮다. - Figma는 엔지니어가 기존처럼 Slack이나 Asana에 댓글을 남기기만 해도 해당 내용을 자동으로 원래 경보 문서에 추가한다. - 기존 문서의 조사 맥락 배열에 새 댓글을 추가하고, `has_investigation_context` 값을 1로 변경한 뒤 문서를 재색인한다. - 결과적으로 유용한 댓글 하나가 이후 발생하는 모든 유사 경보의 조사 비용을 낮춘다. - 별도의 annotation 도구나 새로운 수동 입력 절차를 요구하지 않고 기존 업무 흐름에서 지식이 축적된다는 점이 중요하다. ## 실용적인 적용 방향 - 처음부터 완전한 자율 에이전트를 만들기보다, 과거 대응 기록을 검색하는 좁은 문제부터 시작하는 것이 현실적이다. - 경보 데이터는 검색 가능한 구조화 필드와 사람이 작성한 조사 맥락을 함께 저장해야 한다. - 최신 대응 기록과 조사 내용이 있는 기록을 우선하는 검색 전략이 필요하다. - 별도의 문서화 작업을 추가하기보다 Slack·티켓 시스템의 기존 댓글을 자동으로 지식화하는 방식이 도입 장벽을 낮춘다. - AI가 분석과 코드 변경을 수행하더라도 PR 검토와 최종 판단은 보안 엔지니어가 맡는 구조가 효과적이다.

원문 읽기(새 탭에서 열림)
gitlab원문

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를 결합한 자동화 프레임워크를 구축하면, 저비용으로도 보안 모니터링 시스템의 건강 상태를 지속적으로 검증하고 신뢰도를 높일 수 있습니다.

kakao5분 읽기큐레이션 요약

수억 건의 보안 신호 속 진짜 위협 찾기 — AI로 보안 모니터링의 패러다임을 바꾸다

수억 건의 보안 이벤트를 사람이 규칙만으로 분석하는 방식은 오탐, 맥락 부족, 비용 증가 때문에 지속하기 어렵다. 글은 규칙 기반 필터와 AI 분석, 멀티모델 교차 검증, 자가 학습을 결합한 다단계 보안 모니터링 구조를 제안한다. 핵심은 모든 이벤트를 AI에 맡기는 것이 아니라, 정상 패턴과 노이즈를 먼저 걸러낸 뒤 맥락 판단이 필요한 위협만 정밀 분석하는 것이다. ## 대규모 보안 이벤트와 AI의 필요성 - 엔드포인트에서는 프로세스 실행, 네트워크 연결, 파일 변경, 권한 상승 등이 모두 이벤트로 수집된다. - 서비스가 확장될수록 이벤트는 기하급수적으로 증가하지만, 실제 공격의 비율은 극히 낮다. - 이벤트 증가에 맞춰 분석 인력을 계속 늘리는 방식은 지속 가능하지 않다. - 문제의 본질은 데이터의 양뿐 아니라, 여러 이벤트의 관계와 맥락을 이해해야 하는 복잡성에 있다. - 따라서 단순히 경보 수를 늘리는 것이 아니라, 실제 대응 가치가 높은 신호를 선별하는 시스템이 필요하다. ## 규칙 기반 탐지와 상관분석의 한계 - 규칙은 특정 명령어 실행이나 파일 생성처럼 명확한 패턴을 빠르게 탐지하지만, 실행 목적과 주체, 업무 맥락은 이해하지 못한다. - 정상적인 배포 작업과 악성 백도어 설치가 동일한 명령어를 사용할 수 있어 오탐이 많다. - 분석가의 경험과 근무 시간에 따라 판정 품질이 달라지는 문제도 발생한다. - 호스트 정보, 프로세스 이력, 네트워크 세션, 파일 변경 로그를 사건 단위로 조합하는 작업은 높은 인지 부담을 요구한다. - SIEM 상관분석은 여러 로그를 연결할 수 있지만, 사전에 정의된 공격 시나리오에 의존하므로 알려지지 않은 공격이나 변형된 행위에 취약하다. - 규칙이 늘어날수록 유지보수 비용과 매칭 성능 부담도 커진다. - 결국 기존 방식은 이벤트를 연결하는 데는 성공했지만, “왜 해당 행위가 위협인지”를 맥락적으로 설명하는 데 한계가 있다. ## 다단계 깔때기와 하이브리드 분석 - 수억 건의 이벤트를 모두 AI에 전달하지 않고, 단계별로 분석 대상을 줄이는 깔때기 구조를 사용한다. - 1단계에서는 규칙 기반 필터가 명백한 노이즈를 제거한다. - 2단계에서는 반복되는 정상 패턴을 학습해 예외 처리한다. - 3단계에서야 AI가 정밀 분석을 수행하므로 비용과 처리량을 관리할 수 있다. - 명확한 패턴은 규칙이 빠르게 처리하고, 복합적인 맥락 판단은 AI가 담당하는 하이브리드 방식을 채택한다. - 새로운 위협 유형이나 분석 범주가 추가되어도 동일한 파이프라인에서 처리할 수 있도록 확장성을 고려했다. ## 멀티모델 교차 검증과 운영 신뢰성 - 서로 다른 추론 특성을 가진 여러 AI 모델이 동일한 이벤트를 독립적으로 분석한다. - 모델 간 결과를 비교해 특정 모델의 편향, 오탐, 누락을 보완한다. - 판정이 일치하지 않으면 이를 불확실성 신호로 보고 분석가의 추가 검토를 유도한다. - 모델 장애, API 가용성 저하, 모델 업데이트에 따른 품질 변동에도 다른 모델로 전환할 수 있다. - 목표는 단순한 정확도 향상뿐 아니라 중단 없이 운영되는 복원력과 신뢰성 확보이다. ## 보안 환경의 맥락을 AI에 주입 - 범용 LLM에 이벤트만 전달하면 내부 서버 역할, 서비스 구성, 자동화 계정, 정상적인 네트워크 흐름을 알 수 없어 정상 작업을 공격으로 오인할 수 있다. - 이를 해결하기 위해 호스트 역할, 관련 서비스, 정상 행위 패턴 등을 구조화해 AI에 제공한다. - 중요한 것은 원본 데이터를 전달하는 것이 아니라, 올바른 판단에 필요한 배경 지식을 함께 설계하는 것이다. ## 개별 이벤트가 아닌 행위 흐름 분석 - `curl`로 파일을 내려받고 `chmod`로 권한을 바꾼 뒤 스크립트를 실행하는 행위는 정상 배포와 공격 모두에서 나타날 수 있다. - 개별 명령어만 보면 정상과 악성을 구별하기 어렵다. - 프로세스 실행 이력, 네트워크 세션, 파일 변경 등을 시간 순서로 연결해 호스트 단위의 전체 행위 흐름으로 분석한다. - 같은 명령어라도 실행 시점, 순서, 주체, 주변 맥락에 따라 위협성이 달라진다는 점을 활용한다. ## 표준화된 이벤트 스키마와 동적 피처 - 원본 이벤트에는 분석과 무관한 정보가 많아 토큰을 낭비하고 정확도를 떨어뜨릴 수 있다. - 통계 기반 이상 탐지와 행위 시퀀스 분석은 필요한 정보가 서로 다르다. - 표준화된 이벤트 스키마로 데이터를 정제하고, 탐지 유형별로 필요한 특징만 동적으로 구성한다. - 분석 관점에 맞는 피처를 선별해 토큰 효율과 판단 정확도를 함께 개선한다. ## WALT 기반 자가 학습 피드백 루프 - 초기에는 AI 분석 결과를 분석가가 수동으로 검토한 뒤 탐지 정책에 반영해야 했다. - 이를 자동화하기 위해 WALT(Whitelist-Assisted Learning and Tuning)를 구축했다. - AI가 반복적으로 정상이라고 판정하고 검증된 패턴은 자동으로 예외 정책에 등록된다. - 이후 동일한 이벤트는 AI 분석 전에 필터링되어 불필요한 분석과 오탐을 줄인다. - 수천 건의 탐지 정책이 자동 생성되어 운영 중이며, 시간이 지날수록 정상 패턴 학습이 축적된다. - 다만 필터링을 강화하면 비용과 속도는 개선되지만 실제 위협을 놓칠 위험이 있고, 멀티모델 검증은 신뢰성을 높이는 대신 비용을 증가시킨다. ## 비용·속도·정확도의 균형 - 모든 이벤트를 AI로 분석하면 수억 건 규모에서 비용과 지연 시간이 급증한다. - 따라서 사전 필터링으로 AI 투입량을 줄이고, 필요한 이벤트에만 고비용 분석을 적용해야 한다. - 시스템 설계에서는 탐지 누락 위험, 모델 호출 비용, 실시간 대응 속도, 모델 장애 대응력을 함께 조율해야 한다. - 글의 제공된 본문은 이 과제를 설명하는 도중 끝나므로, 이후의 구체적인 구현 방식과 최종 성과는 확인할 수 없다. 실무에서는 규칙을 AI로 전면 대체하기보다, 규칙으로 대량의 노이즈를 제거하고 AI에는 충분한 내부 맥락과 행위 흐름을 제공하는 방식이 현실적이다. 또한 멀티모델 불일치와 자동 생성 정책을 반드시 검증 대상으로 두어, 비용 절감이 탐지 누락으로 이어지지 않도록 운영해야 한다.

원문 읽기(새 탭에서 열림)
datadog3분 읽기큐레이션 요약

ChatOps로 클라우

Datadog은 Gartner의 2026년 Observability Platforms Magic Quadrant에서 ‘Leader’로 선정되었다고 소개한다. 제공된 내용은 이 평가의 세부 근거보다는 Datadog의 제품군과 기능 범위를 보여주는 웹사이트 메뉴 중심으로 구성되어 있어, 리더 선정의 구체적인 점수나 비교 분석은 확인할 수 없다. ## Gartner Magic Quadrant 리더 선정 - Datadog이 **Gartner® Magic Quadrant™ for Observability Platforms 2026**에서 Leader로 평가받았다는 소식을 전한다. - 상세 보고서와 평가 기준은 별도 Gartner 자료 링크로 연결된다. - 제공된 본문에는 다음과 같은 내용은 포함되어 있지 않다. - Gartner의 평가 점수 - 경쟁 업체와의 비교 - 리더로 선정된 구체적인 기술적 근거 - Gartner의 장단점 분석 ## 인프라 및 애플리케이션 모니터링 - 인프라 영역에서는 다음 기능을 제공한다. - 호스트 및 인프라 모니터링 - 메트릭 수집·분석 - 컨테이너와 Kubernetes 모니터링 - 네트워크, 서버리스, 스토리지 모니터링 - 클라우드 비용 및 GPU 모니터링 - Cloudcraft를 통한 클라우드 아키텍처 시각화 - 애플리케이션 영역에는 다음 제품이 포함된다. - APM(Application Performance Monitoring) - Universal Service Monitoring - 지속적 프로파일링 - Dynamic Instrumentation - AI 에이전트 관측성 ## 로그·데이터 관측성 - 로그 관리와 보안 분석을 위한 기능을 제공한다. - Log Management - Sensitive Data Scanner - Audit Trail - Observability Pipelines - 데이터 플랫폼 영역에서는 다음을 다룬다. - 데이터베이스 모니터링 - 데이터 스트림 모니터링 - 데이터 품질 모니터링 - 데이터 작업 및 잡 모니터링 ## 보안 통합 - Datadog은 관측성뿐 아니라 애플리케이션과 클라우드 보안 기능도 함께 제공한다. - 주요 보안 기능은 다음과 같다. - SAST, IAST, 소프트웨어 구성 분석(SCA) - IaC 보안 - CSPM과 CIEM - 취약점 관리 및 컴플라이언스 - Cloud SIEM - 워크로드 보호 - 애플리케이션·API 보호 - 시크릿 스캐닝 ## 사용자 경험과 소프트웨어 전달 - 디지털 경험 관측성 기능으로 실제 사용자 행동과 애플리케이션 품질을 분석한다. - 브라우저·모바일 RUM - 세션 리플레이 - Synthetic Monitoring - 오류 추적 - 제품 분석 및 실험 - 소프트웨어 개발·배포 과정도 관측 대상으로 포함한다. - CI Visibility - 테스트 최적화와 지속적 테스트 - 코드 커버리지 - Feature Flags - IDE 플러그인 - 내부 개발자 포털 ## 서비스 관리와 AI 기능 - 운영팀의 대응과 자동화를 지원하는 기능을 제공한다. - 이벤트 관리 - 서비스 카탈로그 - SLO 관리 - 인시던트 대응 - 워크플로 자동화 - 케이스 관리 - AI 관련 기능으로는 다음이 소개된다. - AI 에이전트 관측성 - Bits AI Agents와 Bits Chat - AI 기반 조사 및 보안 분석 - MCP Server와 Agent Builder - GPU 모니터링 및 AI 통합 ## 실용적인 결론 이 자료는 Datadog이 인프라·애플리케이션·로그·보안·디지털 경험·개발·AI를 하나의 플랫폼에서 통합하려는 전략을 보여준다. 다만 실제 도입을 검토할 때는 Gartner 보고서의 원문뿐 아니라 수집 비용, 데이터 보존 정책, 기존 도구와의 연동성, 팀별 사용성 및 벤더 종속성까지 별도로 비교해야 한다.

원문 읽기(새 탭에서 열림)