Google의 대처 방식: 고품질, 확장성, 최신 기술을 갖춘 위협 탐지

* 본 아티클의 원문은 2025년 1월 8일 Google Cloud 블로그(영문)에 게재되었습니다.

Google의 보안 방식이 궁금하신가요? 새롭게 시작하는 'Google의 대처 방식' 시리즈에서는 Google 전문가들이 직접 전하는 인사이트, 견해, 중요한 팁을 통해 오늘날 가장 시급한 보안 주제, 문제, 우려 사항에 대처하는 Google의 접근 방식을 알아봅니다. 이번 편에서는 Tim Nguyen이 Google에서 최신 위협을 탐지하고 대응하는 방식의 중요한 측면과 원칙을 자세히 공유합니다.

Google의 위협 탐지 및 대응팀은 Google과 Alphabet 전반에서 악성 시스템과 네트워크 활동을 헌팅하는 업무를 맡고 있습니다. 세계 최대 규모의 Linux Fleet, 온갖 종류의 운영체제, Google Cloud의 인프라 및 서비스, 18만여 명의 직원을 보호하는 것이 이 팀의 주요 임무입니다.

Google Cloud의 탐지 엔진은 여러 다양한 코드 엔진을 결합하여 로그를 수집하고, 인텔리전스를 적용한 후 활용 가능한 신호로 변환하는 방식으로 작동합니다. 이 프로세스는 우선, 대량의 로그 파이프라인을 클라우드 데이터 웨어하우스로 스트리밍하며 여기에서 수개월 치의 과거 로그 데이터 세트 전체를 신속하게 쿼리할 수 있습니다.

추가 조사가 필요한 신호가 발견되면 이 신호를 분류 대기열로 전달해 탐지팀의 담당자가 검토하고 필요시 에스컬레이션하고 해결할 수 있게 합니다. 새로운 침해 지표는 주로 새로운 인텔리전스, 개선된 신호 체계, 보다 광범위한 노출 범위를 통해 발견되며, 발견 시 모든 과거 신호와 기기를 자동으로 검토하여 이러한 새로운 지표의 영향을 받았는지 여부를 확인하는 기능을 갖추고 있습니다.

이러한 노력은 특히 조직 전체로 확장하고자 할 때 무척 어렵게 느껴질 수 있습니다. Google Cloud에서는 최대한 효율적으로 중요한 의사 결정을 내릴 수 있도록 동일한 정보를 수집하고 처리하는 시간을 최소화하기를 원합니다.

Google의 탐지 및 대응팀은 서비스 수준 목표(SLO)에 따라 위협을 신속하게 탐지하고 대응합니다. 네트워크에서 탐지되기 전까지 공격자가 활동하는 시간인 드웰 타임(dwell time) 최대한 단축하기 위함입니다. 업계 평균 드웰 타임(dwell time)은 몇 주에 이르는 반면, Google Cloud는 이를 몇 시간 이내로 줄였습니다.

그렇다면 Google Cloud는 신속한 대응이라는 목표를 달성하면서 탐지 및 대응 역량을 광범위한 환경으로 확장하기 위해 어떤 전략을 활용할까요? 아래에서 성공적인 위협 탐지를 위한 비법을 구성하는 몇 가지 핵심 전략을 공유합니다.

1. 거의 모든 것의 자동화

침해 지표(IoC) 존재 여부에 대한 조사를 요청받으면 조직 내 '모든' 위치에서 이를 확인해야 합니다. 모든 기업용 워크스테이션, 운영체제, 프로덕션 서버, 가상 머신뿐 아니라 제품과 서비스의 기반이 되는 모든 리소스가 포함되므로 반복 업무가 불가피합니다. 이처럼 규모가 방대하고 IoC 유형까지 다양하다면 수작업으로는 처리가 불가능합니다.

Google Cloud의 모토는 데이터 수집을 줄이고 직접적인 분석을 늘리는 것입니다. 인간은 미묘한 의미 차이를 이해하고 판단을 내리고 모호한 정보를 해석하는 데 뛰어납니다. 탐지팀에서 적절한 결정을 내리는 데 더 많은 시간을 확보할 수 있도록 컨텍스트 구축 과정을 최대한 보강해야 합니다.

Google Cloud는 동일한 단계를 반복적으로 수행해야 하는 이벤트 분석이나 조사 과정에 사람 대신 머신을 활용하여 대부분의 작업을 자동화합니다. 특히 머신 원격 분석, 사용자 정보, 프로세스 실행 기록의 대다수를 자동으로 검색할 수 있도록 만들기 위해 노력하고 있습니다.

현재 약 97%의 이벤트는 자동 '헌팅'을 통해 생성되며, 이후 검토자에게 리스크 점수 및 조사할 위치에 관한 세부정보가 포함된 이벤트 정보가 전달됩니다. 이와 같이 처음부터 결정을 내리는 데 필요한 모든 컨텍스트 정보를 제공받은 검토자는 훨씬 짧은 시간 안에 보안 이벤트를 분류할 수 있습니다. 또한 자동화 시스템이 잘못된 조사 과정을 삭제하고 인간 검토자에게 조사 방향을 제시하여 실제 위협인지를 판단하는 데 도움을 줍니다.

자동화의 또 다른 중요한 장점은 이벤트 조사 비용을 낮출 수 있다는 데 있습니다. 로직 일부를 자동으로 복제하고 정보를 수집하고 팀에 제공하여 업무 속도를 높이고 문제 해결을 앞당길 수 있습니다. 이를 통해 개별 이벤트를 처리하는 데 드는 티켓당 비용을 대폭 절감하면서도 더 많은 이벤트를 처리합니다.

자연스럽게 자동화에는 생성형 AI가 광범위하게 사용됩니다. 예를 들어 대규모 언어 모델이 초안을 생성하면서 엔지니어가 핵심 요약을 작성하는 데 걸리는 시간이 53% 단축되었습니다. 게다가 사실에 기반한 정확성을 보이고 작문 권장사항을 따를 뿐만 아니라 그 이상의 콘텐츠 품질을 유지합니다.

한편, 자체 로그 소스를 보완해야 하거나 이벤트 조사를 위해 추가 정보를 찾아야 하는 경우도 있습니다. 항상 전문가의 직접적인 개입이 가능하도록 여지를 남겨두지만, 궁극적인 목표는 반복적인 작업에 에너지와 노력을 낭비하지 않고 더 큰 가치를 창출하며 발전해 나가는 것입니다.

2. 강력한 탐지를 위한 협업

자주 간과하는 사실이지만, 위협 탐지 및 대응팀은 단독으로 운영해서는 효과적일 수 없습니다. 효과적인 위협 탐지를 위해서는 여러 부서, 팀, 이해관계자와의 긴밀하고 지속적인 협업이 필요합니다.

Google의 모든 수동 및 자동 위협 헌팅은 위협 모델링에서 시작됩니다. 효과적인 탐지를 위해서는 정확한 탐지 대상을 제대로 이해해야 합니다. 따라서 우선적으로 프로젝트 책임자와 대화하여 시스템 작동 방식 모델을 정확하게 수립하고, 프로젝트 책임자가 원하는 탐지 목표를 명확하게 해야 합니다.

이후 탐지하려는 위협 유형을 이해한 다음 기존 로그를 검토하여 이 과정에 필요한 원격 분석 데이터가 충분한지 확인합니다. 데이터가 부족한 경우 팀과 협업해 추가 로그를 발급합니다. 경험상 사고 후 분석을 진행할 때 공격자의 행동을 보다 명확하게 분석하는 데 도움이 되는 정보가 누락된 경우가 많습니다. 따라서 로그를 개선하고, 조사를 위해 적절한 정보를 제공하고, 공격에 효과적으로 대응하는 과정이 협업을 통해 지속적으로 이루어져야 합니다.

3. 애셋 인벤토리 구축

과거에는 명확한 애셋 인벤토리나 기록 없이 사고에 대응해야 했습니다. 환경 내 모든 애셋에 대한 참조 없이 특정 시점에 호스트가 존재했는지, 정확히 언제 생성되었거나 종료되었는지, 공격자에게 공격받았는지 파악해야 한다고 상상해 보세요. 특정 애셋 클래스의 존재 자체를 인지하지 못하면 이 클래스는 인프라 침투가 발생할 최적의 진입점이 될지도 모릅니다.

애셋 인벤토리는 인프라 전체를 보호하는 데 필수적이며, 위협 탐지 및 대응 과정에서 중요한 질문에 대한 답을 제공하는 데 도움이 됩니다. 이때 클라우드 환경은 상당한 이점을 제공합니다. 클라우드를 통해 모든 리소스를 자동으로 인벤토리화하고, 애셋 생성 기록을 장기간 보관하고, 인프라를 프로그래매틱 방식으로 쿼리할 수 있기 때문입니다.

4. 코드 작성자가 분류까지 담당

Google에서는 탐지 코드를 작성한 사람이 직접 신호에 대응합니다. '새벽 3시에 알림이 발생했을 때, 당신이 직접 해결해야 한다면 이를 더 신중하게 설계하지 않겠는가?'라는 단순한 질문에서 비롯된 원칙입니다.

일반적으로 보안 탐지 조직에서는 탐지 코드를 작성하는 팀과 알림을 분류하는 팀이 따로 분리되어 있습니다. 하지만 이러한 구조에서는 불필요한 긴장 관계가 자주 발생할 수 있습니다. 보안 알림은 특성상 불필요한 경우가 있기 때문에 아무리 세심하게 탐지 코드를 작성하더라도 결국 과도한 알림으로 인해 분류팀의 업무가 마비되는 상황이 발생할 수 있습니다.

탐지 코드 작성자가 알림이 분류에 미치는 영향을 이해하지 못하면 탐지 품질을 높일 수 없습니다. 알림 피로는 실제로 큰 문제입니다. 팀원들이 번아웃과 좌절을 느끼고 둔감해지도록 만들어 중요한 알림을 놓치게 될 수도 있기 때문입니다. Google Cloud에서는 탐지 코드를 작성하는 팀이 분류까지 책임지도록 구성하여 탐지 품질에 대한 책임을 강화하고 알림을 통제하지 못하는 일이 발생하지 않도록 방지하고 있습니다.

5. 보안 엔지니어링은 곧 소프트웨어 엔지니어링

이제 모든 보안 원칙의 핵심에는 소프트웨어 엔지니어링이 자리하고 있습니다. 클라우드를 운영하고 이를 보호하는 탐지 인프라를 구축하려면 매일 코드를 작성해야 합니다. Google의 일상적인 워크플로에서 자동화 분석과 로직 코딩이 가장 큰 비중을 차지하며, 이 덕분에 내 업무를 다른 팀원이 분류하고 활용할 수 있습니다.

모든 보안 엔지니어가 코드를 읽고 작성하는 능력을 갖춰야 하는 이유가 여기에 있습니다.

Google의 일상적인 워크플로에서 분석과 로직 코딩이 가장 큰 비중을 차지하며, 이 덕분에 내 업무를 다른 팀원이 분류하고 활용할 수 있습니다. Google Cloud에서 보안 엔지니어에게는 위협 모델링, 로그 수집, 데이터 모델링, 신호 개발, 분석 자동화 및 분류, 사고 대응 등의 폭넓은 분야에 대한 책임감이 요구됩니다. 다른 회사에서는 이러한 작업을 2~4명이 나누어 담당할지도 모릅니다.

팀의 엔지니어링 역량을 강화하면서 자동화 범위를 확장했으며, 그 결과 처리해야 하지만 지속적인 가치를 창출하지 않는 반복 업무를 줄일 수 있게 되었습니다. 이 접근 방식에는 코드 문서화, 진행 상황 모니터링 및 추적, 탐지에 대한 스트레스 테스트 및 검증, 분석 및 대응 품질을 논의하는 주간 검토를 비롯해 소프트웨어 엔지니어링의 여러 권장사항을 적용하는 일도 포함됩니다.

간단히 도구를 구매하고 버튼 몇 개만 누르면 자동으로 탐지가 실행되길 바랄 수 있지만, 현실에서 탐지는 곧 코드입니다. 탐지에 엔지니어링 관행을 적용하면 탐지와 신호의 품질이 향상될 뿐 아니라, 전사적으로 탐지 및 대응 역량을 확장할 수 있습니다.

이 게시물은 Cloud Security 팟캐스트의 'Modern Threat Detection at Google(Google의 최신 위협 탐지)' 및 'How We Scale Detection and Response at Google: Automation, Metrics, Toil(Google에서 탐지와 대응을 확장하는 방법: 자동화, 측정항목, 반복 업무)' 에피소드에서 나온 인사이트를 참고해 작성했습니다. 자세히 알아보려면 직접 청취해 보세요.