security-automation

5 개의 포스트

figma

에이전트를 활용해 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 검토와 최종 판단은 보안 엔지니어가 맡는 구조가 효과적이다.

github

GitHub가 모든 저장소에 지속적인 소유자를 부여한 방법 (새 탭에서 열림)

Michael Recachinas는 GitHub의 스태프 보안 엔지니어로, 대규모 보안 프로그램을 이끌고 있습니다. 주요 업무는 취약점 관리, 보안 개발 수명주기(SDL) 도구, 개발자 중심의 보안 자동화이며, 조직이 안전한 선택을 쉽게 할 수 있는 시스템을 구축하는 데 집중합니다. ### 대규모 보안 프로그램 운영 - GitHub에서 대규모 보안 프로그램을 주도합니다. - 다양한 팀과 시스템에 적용할 수 있는 확장성 높은 보안 체계를 구축합니다. ### 주요 전문 분야 - **취약점 관리:** 보안 취약점을 식별하고 추적·개선하는 프로세스 - **보안 개발 수명주기 도구:** 개발 과정 전반에 보안을 통합하는 도구와 체계 - **보안 자동화:** 개발자의 업무 흐름 속에서 보안 조치를 자동화하는 기술 ### 개발자 중심의 보안 철학 - 보안을 별도의 부담으로 만들기보다 개발자가 자연스럽게 따를 수 있도록 설계합니다. - “안전한 선택이 가장 쉬운 선택”이 되도록 시스템과 자동화 기능을 구축합니다. - 대규모 환경에서도 일관되게 작동하는 실용적인 보안 솔루션을 지향합니다.

github

GitHub은 시크릿 스캐닝을 활용해 받은편지함을 0으로 만든 방법 (새 탭에서 열림)

Michael Recachinas는 GitHub의 스태프 보안 엔지니어로, 대규모 취약점 관리와 보안 개발 생명주기 도구를 이끌고 있다. 개발자가 보안상 올바른 선택을 쉽게 할 수 있도록, 대규모 환경에서 작동하는 보안 시스템과 자동화 기술을 구축해 온 전문가다. ### GitHub에서의 역할 - GitHub의 대규모 보안 프로그램을 주도한다. - 주요 업무는 다음과 같다. - 취약점 관리 - 보안 개발 생명주기(SDLC) 도구 - 개발자 중심의 보안 자동화 ### 전문성과 경력 - 대규모 시스템을 설계하고 운영한 경험을 보유하고 있다. - 보안 프로세스를 개발자의 업무 흐름에 자연스럽게 통합하는 데 집중한다. - 조직이 보안을 별도의 부담으로 느끼기보다, 안전한 선택을 쉽게 실행하도록 만드는 것을 목표로 한다. 제공된 내용은 기술 블로그 본문이 아니라 저자 소개에 해당하므로, 특정 기술이나 구현 방법에 대한 추가적인 요약은 어렵다.

slack

에이전트를 활용한 (새 탭에서 열림)

Slack 보안 엔지니어링 팀은 수십억 건의 이벤트를 처리하는 보안 탐지 시스템의 알림 조사를 AI 에이전트로 효율화했다. 단일 프롬프트에 복잡한 조사 절차를 모두 맡기는 대신, 목적과 출력 형식이 명확한 여러 모델 호출을 연결해 조사 과정을 통제하는 구조를 택했다. Director·Expert·Critic 에이전트가 협력하고 서로의 결과를 검증함으로써 조사 품질의 일관성, 근거 교차검증, 환각 완화를 달성하려는 접근이다. ## 단일 프롬프트 프로토타입의 한계 - 초기 프로토타입은 약 300단어의 프롬프트와 MCP 서버, 코딩 에이전트 CLI를 실행 환경으로 사용했다. - 프롬프트는 다음 다섯 부분으로 구성됐다. - **Orientation**: 보안 분석가 역할 정의 - **Manifest**: 사용할 데이터 소스 설명 - **Methodology**: 조사 절차 지시 - **Formatting**: 조사 결과를 Markdown 보고서로 출력 - **Classification**: 대응 등급 분류 - MCP의 stdio 모드 서버를 통해 일부 보안 데이터 소스를 안전하게 도구 호출 방식으로 노출했다. - 어떤 경우에는 여러 데이터 소스의 증거를 훌륭하게 연결했지만, 다른 경우에는 충분한 검증 없이 편리하거나 잘못된 결론으로 빠르게 진행했다. - “가정을 의심하라”, “여러 출처로 검증하라”와 같은 지침을 프롬프트에 추가했지만, 프롬프트는 가이드라인일 뿐 세부적인 실행 흐름을 강제하기에는 한계가 있었다. ## 단계별 모델 호출과 구조화된 출력 - 복잡한 조사 전체를 하나의 프롬프트로 처리하지 않고, 조사 과정을 여러 개의 단순한 작업으로 분해했다. - 각 작업은 다음 요소를 갖는다. - 명확하게 정의된 단일 목적 - 애플리케이션이 해석하기 쉬운 구조화된 출력 - 다음 단계로 전달할 제한된 컨텍스트 - 각 모델 호출 결과는 JSON 스키마로 제한할 수 있는 구조화된 출력 형식으로 생성된다. - 구조화된 출력은 작업 간 계약 역할을 하므로, “증거를 의심하라” 같은 추상적인 지침도 독립적인 검토 작업으로 분리할 수 있다. - 다만 구조화된 출력에도 주의점이 있다. - 스키마가 지나치게 복잡하면 모델 실행 자체가 실패할 수 있다. - 모델이 형식을 형식적으로만 충족하거나, 여전히 환각을 포함할 수 있다. - 이 방식의 핵심 효과는 모델의 행동을 프롬프트 수준이 아니라 애플리케이션의 워크플로 수준에서 통제할 수 있다는 점이다. ## 페르소나 기반 조사 설계 - Slack은 메타 프롬프트와 다중 페르소나 자기협업 관련 연구, 보안 테이블톱 훈련에서 설계 아이디어를 얻었다. - 하나의 모델 호출 안에서 여러 페르소나를 연기하게 하는 대신, 각 페르소나를 독립적인 모델 호출로 구현했다. - 각 에이전트와 작업의 조합은 별도의 구조화된 출력 형식을 가지며, 애플리케이션이 호출 순서와 컨텍스트 전달을 orchestration한다. - 독립 호출 구조에서는 에이전트별로 모델 버전, 프롬프트, 지시사항, 도구, 출력 형식을 다르게 설정할 수 있다. ## Director·Expert·Critic 협업 구조 ### Director 에이전트 - 조사 전체를 시작부터 끝까지 진행하는 조사 책임자다. - 조사에 필요한 질문을 만들고 이를 도메인 전문가에게 전달한다. - 조사 진행 상황을 계획하고 정리하기 위해 저널링 도구를 사용한다. - 전문가의 결과와 Critic의 평가를 바탕으로 다음 조사 단계를 결정한다. ### Expert 에이전트 - 특정 도메인 지식과 데이터 소스를 담당한다. - Director의 질문에 답하기 위해 관련 도구를 호출하고 조사 결과를 생성한다. - 현재 네 종류의 전문가가 있다. - **Access**: 인증, 권한 부여, 경계 보안 서비스 - **Cloud**: 인프라, 컴퓨트, 오케스트레이션, 네트워킹 - **Code**: 소스 코드 및 구성 관리 분석 - **Threat**: 위협 분석과 위협 인텔리전스 데이터 - 각 전문가는 자신에게 필요한 데이터 소스에 집중하므로, 하나의 에이전트가 모든 영역을 무분별하게 조사하는 문제를 줄인다. ### Critic 에이전트 - 전문가 결과를 검토하는 메타 전문가다. - 사전에 정의한 평가 기준에 따라 각 발견 사항의 품질을 평가하고 정량화한다. - 전문가의 주장에 분석 내용을 추가하고, 각 발견 사항에 신뢰도 점수를 부여한다. - 가장 신뢰할 수 있는 결과를 바탕으로 타임라인을 구성해 Director에게 전달한다. - 전문가 그룹과 약한 적대적 관계를 형성함으로써 증거 해석의 편차와 환각을 완화한다. ## 반복형 조사 루프 - Director가 조사 질문을 제시한다. - 관련 Expert들이 각자의 데이터 소스를 조사해 발견 사항을 생성한다. - Critic이 발견 사항을 검토하고 신뢰도와 품질을 평가한다. - Critic은 중요한 결과를 선별하고 신뢰할 수 있는 증거를 이용해 사건 타임라인을 만든다. - Director는 검증된 발견 사항과 타임라인을 이용해 추가 조사가 필요한지, 다음 질문은 무엇인지 결정한다. - 이 루프를 통해 한 번의 응답으로 결론을 내리기보다, 질문·조사·검증·진행 결정이 반복되는 조사 프로세스를 구현한다. ## 지식 피라미드와 모델 비용 최적화 - 하위 단계에서는 도메인 전문가가 복잡한 데이터 소스를 직접 조회한다. - 이 과정은 도구 호출이 많고 반환된 데이터를 분석하는 데 많은 토큰이 필요하므로 상대적으로 비용이 높을 수 있다. - Critic은 전문가가 생성한 많은 결과를 검토해 중요하고 신뢰할 만한 발견 사항을 추린다. - 이후 상위 단계의 에이전트는 정제된 결과와 타임라인만 전달받아 더 높은 수준의 판단을 수행한다. - 이를 통해 모든 단계에서 가장 크고 비싼 모델을 사용하는 대신, 조사 단계별 요구 사항에 맞춰 모델을 선택할 수 있다. - 즉, 많은 원시 데이터를 처리하는 단계와 최종 판단을 내리는 단계를 분리해 비용과 성능을 함께 조정하는 구조다. ## 실용적인 설계 시사점 - 복잡한 보안 조사를 하나의 거대한 프롬프트에 담기보다, 목적이 명확한 작업과 구조화된 출력으로 분해하는 것이 안정적이다. - 에이전트 간 역할을 분리하고 독립적인 검토자를 두면 증거 검증과 환각 완화에 도움이 된다. - 데이터 소스별 전문 에이전트를 두면 각 모델이 불필요한 도구를 사용하거나 모든 영역을 피상적으로 조사하는 문제를 줄일 수 있다. - 모델 호출을 독립적으로 설계하면 작업별로 모델 크기, 도구, 프롬프트, 출력 스키마를 최적화할 수 있다. - 다만 구조화된 출력만으로 정확성이 보장되지는 않으므로, 다중 출처 검증과 별도 Critic 단계, 신뢰도 평가를 함께 구성하는 것이 중요하다.

kakao

YEYE가 지켜보고 있다–카카오의 공격 표면 관리 이야기 (새 탭에서 열림)

카카오는 복잡해지는 외부 공격 표면을 체계적으로 관리하기 위해 통합 ASM(Attack Surface Management) 도구인 'YEYE'를 개발하여 운영 중입니다. YEYE는 자산 식별부터 취약점 스캐닝, 데이터 연관 분석까지 자동화하며, 이를 'DSR(Daily Security Review)'이라는 매일의 보안 프로세스와 결합해 실질적인 리스크를 선제적으로 제거합니다. 이를 통해 기술적 자동화와 인적 리뷰가 유기적으로 연결된 견고한 보안 방어 체계를 구축하고 있습니다. ### 공격 표면 관리의 핵심, YEYE와 DSR * 2023년 탄생한 YEYE는 산재된 보안 도구를 통합하여 외부 접점이 있는 IP, 도메인, 포트, 모바일 앱 등 모든 디지털 자산을 가시화합니다. * 단순한 도구 도입에 그치지 않고, 매일 오전 외부 피드와 공개 취약점을 검토하는 DSR(Daily Security Review) 프로세스를 통해 사람에 의한 심층 분석을 병행합니다. * 이를 통해 보안 검수를 받지 않은 자산 노출이나 최신 CVE 이슈에 대해 공격자보다 한발 앞선 대응 체계를 유지합니다. ### 자산의 체계적 정의와 데이터 모델링 * 자산을 범위(In/Out), 타입(Domain/IP/Port 등), 식별 여부(Known/Unknown)로 분류하여 자산이 확장되더라도 일관된 관리 규칙을 적용합니다. * 다양한 소스에서 수집된 정보를 표준화하고 레이블링(Labeling)하여 데이터의 근본적인 성격을 정의하고 활용도를 높입니다. * 자산과 취약점, CVE, 담당자 정보를 다형성 구조로 연결하여 특정 보안 이슈 발생 시 영향 범위를 즉각적으로 파악하고 조치 이력을 추적할 수 있습니다. ### 대규모 스캔 환경의 기술적 최적화 * **네트워크 병목 해소:** 내부 물리 서버의 대역폭 한계를 극복하기 위해 퍼블릭 클라우드를 병행 운영함으로써 대규모 동시 요청 시 발생하는 지연 문제를 해결했습니다. * **병렬 스캔 구조 구현:** 오픈소스 스캐너의 단일 프로세스 한계를 넘기 위해 스케줄러와 큐, 다수의 워커가 독립적으로 작동하는 분산 병렬 처리 구조를 직접 설계했습니다. * **비용 및 성능 균형:** 고사양 서버를 무조건 투입하기보다 스캔 특성에 맞는 최소 스펙을 도출하고, 적정 스펙의 서버를 효율적으로 분산 확장하는 가성비 기반 인프라를 구축했습니다. * **서비스 영향 최소화:** 스캔 트래픽을 공격으로 오해하지 않도록 고정 IP와 전용 User-Agent 정보를 제공하며, 초당 호출 수와 타임아웃 등 핵심 파라미터를 정밀하게 튜닝했습니다. 공격 표면 관리는 단순히 자산을 찾는 기술을 넘어, 수집된 데이터를 자산 중심으로 연결하고 매일 반복되는 리뷰 프로세스를 내재화할 때 완성됩니다. 대규모 인프라를 운영하는 조직이라면 네트워크 병목과 비용 효율을 고려한 분산 스캔 구조를 설계하고, 서비스 부하를 고려한 정밀한 튜닝을 통해 공격자보다 먼저 약점을 찾아내는 체계를 갖출 것을 권장합니다.