Skip to main content

The Forrester Wave™: XDR 플랫폼, 2026년 2분기

보고서 보기
회사 소개파트너지원|로그인
Elastic logo
무료 체험판 시작영업팀에 문의하기

Elastic 및 Tines의 자동화된 SIEM 조사를 통한 오탐 감소

By
Aaron Jewitt

SOC 팀이 직면하는 가장 큰 SIEM 관리 문제 중 하나는 오탐으로 인해 분석가의 피로가 누적되고 가시성 격차가 발생한다는 것입니다. 그 외에도 보안 분야에서 가장 어려운 과제 중 하나는 오탐 문제를 가중시키지 않으면서 SaaS 액세스 토큰이 손상된 시점을 탐지하는 것입니다. 

At Elastic, the InfoSec 팀은 Tines와 같은 도구를 사용하여 SIEM 경고 조사를 자동화함으로써 이러한 두 가지 문제를 해결합니다. 이 블로그 게시물에서는 워크플로우를 간소화하고, 오탐을 줄이며, 분석가가 실제 위협에 집중할 수 있도록 지원한 방법을 공유합니다.

SIEM 알림 초기 조사 자동화

이전 블로그 게시물에서 Elastic InfoSec 팀이 사용자 및 개체 행동 분석 (UEBA) 을 감지하는 규칙 패키지를 만든 방법에 대해 썼어요.더 많은 데이터 소스를 포함하도록 경고 패키지를 확장하면서 SOC 분석가들에게 변칙적이지만 무해한 활동 (예: 한 달에 한 번만 발생하거나 알려진 스캐너에서 발생한 API 토큰 활동) 으로 인한 오탐이 너무 많이 발생하고 있다는 사실을 알게 됐어요.이로 인해 문제가 생겼어요. 오탐으로 인한 잡음이 심할 수 있는 탐지 규칙을 만들지 아니면 탐지 기능이 없어서 가시성에 격차가 생길 수 있다는 걸 받아들일지 결정해야 했어요.오탐지가 많고 잡음이 많은 탐지는 분석가의 피로로 인해 나름의 가시성 격차가 생깁니다.그런데 이 문제로 인해 새로운 생각이 떠올랐어요. 경보에 대한 초기 조사를 자동화하여 알려진 오탐은 닫고 닫을 수 없는 오탐은 에스컬레이션할 수 있다면 어떨까요? 

많은 SaaS 공급자 및 UEBA 탐지 규칙의 경우, 활동이 관리형 워크스테이션과 같은 신뢰할 수 있는 장치에서 발생하면 규칙을 닫을 수 있음을 확인했습니다. 초기 조사 플레이북 작업은 많은 경우 원래 알림의 정보(예: source.ip)를 사용한 다음, 해당 source.ip에 대해 Elasticsearch의 다른 인덱스 패턴을 쿼리하는 것입니다. 쿼리 결과가 있으면 해당 알림은 오탐으로 닫을 수 있습니다. 예를 들어, AWS Secret Key 활동에 대한 UEBA 알림이 표시되면 다음 쿼리 그룹을 실행하여 활동이 신뢰할 수 있는 장치에서 발생했는지 확인하고 알림을 분류합니다:

  • Elastic Agent가 해당 source.ip를 사용하는 워크스테이션이나 서버에서 당사 Fleet Server로 성공적으로 연결되었음을 보여주는 프록시 로그가 있습니까?

  • 해당 source.ip가 당사에서 관리 및 제어하는 AWS, GCP 또는 Azure 네트워크 영역의 공용 IP 범위에 속합니까?

  • source.ip가 Okta, Terraform, Tines, Qualys 또는 Snyk과 같은 승인된 타사 애플리케이션에 속합니까?

  • 지난 2시간 동안 해당 source.ip에서 성공한 FIDO2 싱글 사인온 인증 로그인이 있었습니까?

이러한 후속 Elasticsearch 쿼리 중 하나라도 결과가 반환되면 이 AWS API 키 활동은 승인된 것으로 간주하고 경고를 닫을 수 있습니다. 모든 쿼리가 0개의 결과를 반환하면 해당 활동이 의심스러운 것으로 판단하여 추가 조사를 위해 SOC 팀원에게 에스컬레이션합니다. 위의 모든 Elasticsearch 쿼리는 _search API를 사용하여 완료할 수 있으며, Signals API를 사용하여 경고를 닫고 태그를 지정함으로써 전체 프로세스를 자동화할 수 있습니다.

Elastic의 SIEM 탐지 결과를 보안 오케스트레이션, 자동화 및 대응(SOAR) 시스템으로 Alert Actions 기능을 사용하여 전송함으로써, SOAR를 활용해 적용 가능한 모든 경보에 대해 이러한 조사 쿼리를 자동으로 실행할 수 있습니다. 쿼리 결과를 바탕으로 경보를 자동으로 종료하거나 분석가에게 에스컬레이션할 수 있습니다. 

이 자동화된 분류 기능을 통해 SOC 인력을 대폭 늘리지 않으면 조사하기에 너무 많은 노이즈가 발생했을 전체 탐지 클래스를 생성할 수 있습니다. 당사의 자동화된 워크플로우는 현재 사람의 개입 없이 하루 3,000건 이상의 알림을 분류하고 종료하고 있습니다. 숙련된 분석가가 동일한 방식으로 분류하려면 알림당 15분 이상이 소요될 것입니다. 이 자동화 없이 동일한 탐지를 수행하려면 94명의 정규직 직원이 추가로 필요할 것입니다. 이 차트는 당사 SIEM에서 지난 30일간의 알림 수치를 보여줍니다:

30일간의 경고
30일간의 경고

이 자동화된 분류 워크플로우는 사용자 지정 스크립트를 사용하여 생성할 수 있지만, 이 블로그에서는 Tines를 사용하여 이 자동화를 구축하는 방법을 보여드립니다. Elastic InfoSec 팀이 사용하는 방식이며 간단히 말해 스크립팅보다 쉽기 때문에 이 방식을 탐색하기로 했습니다. Tines를 사용하면 전담 개발 팀 없이도 자동화를 쉽게 구축하고 수정할 수 있다는 것을 확인했습니다.

모든 SOAR로 알림 전송

위에서 언급했듯이 첫 번째 단계는 Elastic Security에서 경보 콘텐츠를 가져와 원하는 SOAR 솔루션으로 전달하는 것입니다. 이를 위해 Elastic Security의 Alert Actions 기능을 사용하며, 이 기능은 경보가 트리거될 때마다 사용자 지정 작업을 수행합니다.

탐지(detection) 규칙을 구성할 때 규칙 조치를 추가하는 옵션이 있습니다. 여기에서 원하는 커넥터 유형을 선택할 수 있습니다.

규칙 작업 커넥터 선택 보기
규칙 작업 커넥터 선택 보기

경보를 Tines로 보내는 가장 쉬운 방법은 Elastic에서 기본 제공되는 Tines 커넥터를 구성하고 사용하는 것입니다. 이 커넥터는 처리를 위해 경보를 Tines 스토리로 보냅니다.

다른 옵션은 Webhook 커넥터를 사용하는 것입니다. 이 커넥터는 매우 유연하여 알림의 일부 또는 전체 내용을 ndjson 형식으로 수신 Webhook에 보낼 수 있습니다. Elastic은 Tines 커넥터가 존재하기 전부터 내부적으로 Tines를 사용해 왔으므로, 대부분의 자동화 작업에서 여전히 Webhook 커넥터를 사용합니다. 알림을 한 번에 하나씩 Webhook으로 보내거나 단일 ndjson으로 모두 함께 보낼 수 있습니다. 사용자 지정 스크립트를 사용하는 경우 이 커넥터를 사용하여 알림을 수신하고 처리할 수 있으며, Tines Webhook 작업과도 함께 작동합니다. 알림의 전체 내용을 Webhook으로 보내려면 콘텐츠 유형이 application/x-ndjson; charset=utf-8로 설정된 POST 작업을 사용하도록 Webhook 커넥터를 구성해야 합니다.

Webhook 커넥터 구성 설정
Webhook 커넥터 구성 설정

규칙에 작업을 추가할 때 구성된 Webhook 커넥터를 선택하고 구성에서 다음 mustache 구문을 사용하여 전체 경보를 ndjson으로 Webhook에 전송하십시오.

웹훅 구성에 대한 경보 작업
웹훅 구성에 대한 경보 작업

태그를 사용하여 자동화 라우팅

이러한 자동화를 구축할 때 처음에는 각 경보에 대해 개별적으로 사용자 지정 자동화 경로를 구축하기 시작했지만, 이것이 확장되지 않는다는 것을 매우 빠르게 알게 되었습니다. 이에 대한 해결책으로 탐지 규칙에 사용자 지정 태그를 사용하여 규칙을 적절한 분류 경로로 라우팅하기로 했습니다. 전체 경보를 Tines로 전송하며, 여기에는 signal.rule.tags 필드에 배열로 포함된 태그가 포함됩니다. 규칙에 대해 어떤 자동화된 검사가 수행될지 설명하기 위해 Triage:{option} 이라는 명명 규칙을 사용하기로 결정했습니다. 탐지 규칙은 여러 개의 서로 다른 태그를 가질 수 있습니다.

선별 태그 목록
선별 태그 목록

다음은 당사에서 사용 중인 자동 분류 태그에 대한 설명입니다:

  • 분류: 모두 는 자산, PMFA 및 워크스테이션 자동 분류 경로를 통해 경보를 라우팅하며, 쿼리 중 하나라도 true를 반환하면 경보가 닫힙니다. 쿼리 중 true를 반환하는 것이 없으면 경보가 에스컬레이션됩니다.

  • 분류: 자산은 다양한 인덱스 패턴을 확인하여 소스 IP가 Elastic이 소유하거나 어떤 방식으로든 관리하는 자산에서 오는지 판단합니다. 여기에는 Elastic에 저장하는 당사의 내부 자산 데이터베이스, 내부 네트워크 영역, 당사의 Elastic Cloud 공용 IP, CI/CD 시스템, 그리고 Okta나 Tines와 같은 승인된 타사 시스템의 공용 IP 공간이 포함됩니다.

  • Triage: PMFA 는 Okta Verify 또는 Windows Hello를 사용하는 패스키와 같은 피싱 방지 MFA를 사용하여 성공적으로 인증된 Okta 감사 로그를 확인합니다. 당사는 Okta 통합을 사용하여 Okta 감사 로그를 수집합니다.

  • 분류: 워크스테이션은 Nginx 프록시 로그를 확인하여 Elastic Defend에서 해당 IP 주소를 통해 Fleet 서버로 성공적으로 연결되었는지 확인합니다. Elastic은 분산형 기업으로서 직원들이 전 세계 어디에서나 근무할 수 있지만, Elastic Defend 에이전트가 정기적으로 연결되므로 일반적으로 경보를 생성한 동일한 IP에서 Elastic 직원의 관리형 워크스테이션이 연결되었음을 확인할 수 있습니다.

  • 분류: 신규 직원 은 인사 시스템에서 내보낸 모든 직원의 일일 보고서가 포함된 자산 데이터베이스를 확인하여 사용자가 신규 직원인지 확인합니다. 이는 일반적으로 신규 직원이 계정을 구성할 때는 작동하지만 기존 직원에게는 거의 경보를 울리지 않는 Slack UEBA와 같은 특정 범주의 탐지 규칙에 중요합니다.

  • 분류: 1h는 Tines에 나머지 분류 작업을 수행하기 전에 경고 분류를 1시간 동안 일시 중지하라고 지시해요.이는 사용자 완전히 새로운 워크스테이션을 구성하는 등의 이벤트에 유용할 수 있어요. 워크스테이션이 제대로 등록되고 Elastic Defend를 설치하는 엔드포인트 관리 시스템에 등록되면 알림이 종료될 수 있어요.

  • 트리아지: 24시간 은 Tines가 처리를 시작하기 전에 전체 24시간 동안 경고 트리아지를 일시 중지하도록 지시합니다. 이는 모든 컴퓨터, 사용자 및 클라우드 계정의 일일 인벤토리를 수집하는 자산 데이터베이스의 일부와 같이 데이터가 매일 업데이트되는 일부 트리아지 경로에서 필요할 수 있습니다.

  • 트리아지: 사용자 지정은 경보에 필요할 수 있는 모든 사용자 지정 트리아지 경로를 위한 것입니다. 이에 대한 좋은 예는 Azure에서 계정을 생성하거나 비활성화하는 데 사용되는 권한이 높은 API 키를 Okta와 같은 타사 제공업체에 제공했고, 해당 API 토큰이 Okta에 속하지 않는 IP 주소에서 사용될 경우 경보를 받으려는 시나리오입니다. 이 경보 및 자동화된 트리아지를 통해 Okta의 API 키 저장소가 손상되어 Okta IP 공간 외부에서 사용되는 경우에 대비하여 “신뢰하되 검증”할 수 있습니다.

자동화를 위한 구성 요소

이제 전체 경보를 JSON으로 SOAR에 전송하고 있으므로, 이를 분류 경로를 통해 전송한 다음 Slack이나 PagerDuty와 같은 다른 소스로 보낼 수 있습니다. Tines에는 스토리를 구축하는 데 사용할 수 있는 조치 유형이 7가지 있습니다: 

  • Webhook 작업 은 Webhook(HTTP 콜백)을 통해 수신한 이벤트를 전송합니다. 이는 Tines의 스토리에 이벤트를 보내는 기본 방법입니다.

  • 이메일 보내기 작업은 작업 옵션에 지정된 수신자에게 이메일을 보냅니다.

  • 이메일 수신(Receive Email) 작업은 공식적으로 IMAP 작업으로 알려져 있으며, IMAP 서버에서 새 이메일을 감지하거나 고유하게 생성된 이메일 주소로 이메일이 전송될 때 이벤트를 발생시킵니다.

  • 이벤트 변환(Event Transformation) 작업 에는 수신된 이벤트의 콘텐츠를 수정하는 여러 모드가 있습니다. 이러한 작업은 매우 유연하고 강력합니다.

  • HTTP 요청 작업은 다양한 메서드를 사용하여 지정된 URL로 HTTP 요청을 보냅니다.

  • 트리거 작업 은 들어오는 이벤트의 필드 내용을 미리 정의된 규칙과 비교하며, 규칙이 일치하면 이벤트 방출이 트리거됩니다. 이는 “If Then(만약 ~라면)” 논리 작업으로 생각할 수 있습니다.

  • Send to Story 작업은 다른 Tines 스토리(하위 스토리)로 이벤트를 전송합니다. 하위 스토리가 작업을 완료하면 Send to Story 작업이 이벤트를 방출합니다. Send to Story 작업은 여러 곳에서 작업을 재사용하려는 코드의 함수나 라이브러리와 유사합니다.

이러한 작업을 사용하여 매달 수천 시간의 업무를 절감하는 자동화를 구축할 수 있습니다.

간소화된 자동화 우선순위 지정 워크플로우 예시:

Tines 선별 스토리
Tines 선별 스토리

이 자동화 사례에서는 Webhook으로 들어오는 새 경보를 처리하고, 이벤트 변환 작업을 사용하여 ndjson을 더 쉽게 참조할 수 있는 객체로 구문을 분석한 다음, 트리거 작업을 사용하여 해당 경보가 거쳐야 할 분류 경로를 결정합니다.

대부분의 HTTP 요청 작업은 Elasticsearch _search API에 대한 쿼리입니다. 이러한 후속 쿼리에서는 source.ip 또는 user.email와 같이 원래 경보의 필드를 사용하여 경보를 분류합니다. 

Tines에는 Elasticsearch와 상호 작용하기 위한 여러 템플릿을 포함하여 수백 개의 사전 구축된 작업 템플릿이 제공됩니다.’Query an Elasticsearch index for all records’ 템플릿을 사용한 다음 페이로드를 수정하여 경고의 소스 IP를 사용하여 쿼리를 추가할 수 있습니다. 대부분의 쿼리는 특정 source.ip 에서 발생하는 모든 이벤트를 찾고 있기 때문입니다. 속도와 성능을 향상하려면 쿼리에”size”: 1 옵션을 추가하는 것이 좋습니다. 이렇게 하면 Elasticsearch가 지난 4시간 이내에 source.ip와 일치하는 결과를 찾는지 반환합니다.

{
  "size": 1,
  "query": {
    "bool": {
      "must": [],
      "filter": [
        {
          "bool": {
            "should": [
              {
                "match_phrase": {
                  "source.ip": "<<extract_source_ip.source_ip>>"
                }
              }
            ]
          }
        },
        {
          "range": {
            "@timestamp": {
              "format": "strict_date_optional_time",
              "gte": "now-4h",
              "lte": "now"
            }
          }
        }
      ],
      "should": [],
      "must_not": []
    }
  }
}

각 쿼리 작업 후, 결과가 발견되었는지 확인하는 트리거 작업이 있습니다. 적중 횟수가 0보다 크면 Signals API를 사용하여 경보를 닫습니다. 결과가 0개이면 처리를 계속하여 다음 작업으로 넘어갑니다. 모든 작업이 0개의 결과를 반환하면, Slack으로 경보를 보내 분석가에게 조사를 알립니다.

다음은 쿼리 결과가 있는지 확인하는 트리거 작업에 대한 설정 예시입니다:

작업 트리거 설정
작업 트리거 설정

Elasticsearch 쿼리를 실행하고 결과가 있으면 경보를 닫는 논리를 사용하여, 이러한 작업을 여러 개 연결함으로써 알려진 정상 IP 주소에서 발생하는 경보를 닫는 포괄적인 스토리를 구축할 수 있습니다.

관리형 워크스테이션 분류 예시

아래의 예시 스토리 브랜치에서는 당사가 관리하는 워크스테이션이나 서버에서 발생하는 모든 경보를 처리하고 있습니다. Elastic은 전 세계에 분산된 기업이며 대다수의 직원이 재택근무를 하고 있기 때문에, 직원이 어떤 IP 주소로 인터넷에 연결할지 예측할 방법이 없으며 많은 경우 공용 IP 주소가 하루에도 여러 번 변경될 수 있습니다. 전 세계를 이동하는 이러한 워크스테이션의 공용 IP를 안정적으로 찾기 위한 당사의 솔루션은 InfoSec 인프라 앞에 위치한 Nginx 프록시에 Elastic Agent를 배포하는 것입니다. 

이 데이터를 사용하여 이제 Elastic Agent, Auditbeat 또는 Endgame 트래픽을 당사 클러스터로 보내는 프록시를 통한 성공적인 연결을 식별할 수 있습니다. 당사의 모든 클라우드 서버 시스템에는 Auditbeat 또는 Elastic Agent가 설치되어 있으므로, 이러한 쿼리는 CI/CD 및 DevOps 파이프라인을 실행하기 위해 비밀 키를 정기적으로 사용하는 서버 시스템의 공용 IP 주소도 탐지합니다.

다음은 소스 IP에서 관리형 워크스테이션 또는 서버를 확인하기 위해 Tines 스토리에서 사용하는 경로입니다. 트리거 작업에서 나오는 점선은 트리거 작업이 true를 반환하지 않을 경우 스토리가 흐르는 경로입니다.

워크스테이션 스토리 분기
워크스테이션 스토리 분기

경고 닫기 Story로 전송

경보를 닫을 때마다 Tines에서 Send to Story 작업을 사용한다는 점을 눈치채셨을 것입니다. 이 작업은 선택한 필드를 Webhook을 통해 Tines의 새로운 스토리로 전송하며, 그곳에서 경보를 닫고 태그를 지정합니다. Send to Story를 사용하면 메인 스토리를 더 쉽게 유지관리할 수 있으며, 신호 ID별 중복 제거와 같은 추가 기능을 더해 두 개의 서로 다른 분류 브랜치에서 동일한 경보를 두 번 닫으려 하지 않도록 할 수 있습니다. 또한 스로틀(throttle) 작업을 사용하여 많은 경보가 한꺼번에 들어올 경우 API에 과부하가 걸리지 않도록 할 수 있습니다. 

또한 Signals API를 사용하여 규칙 태그를 업데이트하며, 이는 메트릭 및 경보 상태 추적에 유용할 수 있습니다. 자동화된 분류 워크플로우로 종료하는 모든 경보에는 자동 분류 태그가 지정되므로, 월별 분류된 경보 수를 추적하고 SIEM UI에서 경보가 자동화에 의해 종료되었는지 분석가에 의해 종료되었는지 쉽게 확인할 수 있습니다.

경고 닫기 스토리로 보내기
경고 닫기 스토리로 보내기

오픈 얼러트를 슬랙으로 에스컬레이션하는 중

다양한 자동 분류 경로를 통해 경보를 병렬로 전송하는 동시에, 5분 동안 처리를 일시 중지하는 경로로도 스토리를 전송합니다. 이 5분간의 일시 중지를 통해 다른 분기에서 신뢰할 수 있는 소스 IP에서 발생한 것으로 확인된 경보를 완료하고 닫을 시간을 확보합니다. 5분간의 일시 중지 후, signals search API에 요청을 보내 경보가 여전히 열려 있는지 확인합니다. 경보가 여전히 열려 있으면, 경보가 자동으로 분류되지 않았음을 SOC 분석가에게 알리기 위해 경보 Slack 채널로 메시지를 보냅니다.

열린 경보를 Slack으로 에스컬레이션
열린 경보를 Slack으로 에스컬레이션

이 스토리에 더 많은 기능을 추가하려면 Tines를 사용하여 스토리에 다른 분기를 쉽게 생성하고 추가 기능을 더할 수 있습니다. 예를 들어, 특정 시간 내에 중요 또는 높은 심각도의 경보를 확인해야 하는 SLA가 있는 경우, 1시간 동안 대기한 후 Elastic SIEM에서 해당 경보가 확인되었는지 확인하는 로직을 추가할 수 있습니다. 경보가 여전히 열려 있고 누구에게도 할당되지 않은 경우, PagerDuty로 경보를 보내거나 다른 팀에 두 번째 Slack 메시지를 보내 에스컬레이션할 수 있습니다.

PagerDuty로 에스컬레이션
PagerDuty로 에스컬레이션

Tines에는 Elastic Security에서 케이스를 작업하기 위한 템플릿도 포함되어 있습니다. 이 브랜치에서 몇 가지 추가 작업을 수행하면 새 케이스를 열고, 온콜 분석가에게 배정하며, 경보 세부 정보를 케이스에 추가할 수 있습니다.

우리가 직면한 과제

보안에 완벽한 것은 없으며, 모든 보안 제어에는 위협 행위자가 이를 우회할 방법이 존재합니다. 완벽하지 않다고 해서 노력할 가치가 없는 것은 아닙니다. 분명한 약점 중 하나는 이러한 경보가 내부 위협에 대해서는 효과가 제한적이라는 점입니다. 만약 위협 행위자가 손상된 워크스테이션, 서버 또는 기업 VPN 연결을 통해 피벗팅하는 경우, 알려진 정상 IP 주소에서 발생할 수 있으며 자동 분류 워크플로우가 있는 규칙의 경우 경보가 자동으로 닫히게 됩니다. 

이에 대해 두 가지 주장이 있습니다. 첫째, 이러한 자동화가 없으면 수백 명의 추가 직원 없이는 대부분의 탐지 기능을 배포하는 것이 불가능합니다. 약점이 있더라도 이러한 자동화된 탐지는 없는 것보다 더 나은 가시성을 제공합니다. 분류된 경보는 위협 탐색에 사용될 수 있으며 호스트 또는 사용자에 대한 여러 개의 개별 탐지 규칙에 대해 경고하는 탐지에 포함되어 여전히 가치를 제공할 수 있습니다.

둘째, 위협 행위자들이 전략을 바꾸도록 강요할 수 있다면 (예: 강제로 보안 침해 워크스테이션이나 서버 중 하나를 피벗하도록 강요하면 탐지 가능성이 크게 높아져요.저희 워크스테이션과 서버는 Elastic Defend고도로 계측되어 있고 천 개가 넘는 탐지 규칙을 가지고 있어요.위협 행위자가 SaaS 자격 증명이나 API 비밀 토큰을 손상시킬 때 보통 손상된 호스트를 통하지 않고 자체 인프라에서 직접 서비스에 연결하는 걸 봤어요.

이러한 탐지 기능을 구축할 때의 또 다른 큰 과제는 섀도우 IT(Shadow IT)와 현대 IT 시스템에서 타사와의 모든 상호 연결 및 신뢰 관계입니다. 섀도우 IT는 회사 내 팀이 적절한 채널을 거치지 않고 자체 IT 시스템을 설정하여 자산 인벤토리에 시스템을 추가하거나 Elastic Agent 또는 auditbeat를 설치하지 않는 상황을 설명하는 용어입니다.

이러한 트리아주 워크플로우를 구축하고 "알려진 정상 IP"가 무엇인지 정의할 때, 회사 소유가 아닌 IP 주소에서 승인된 방식으로 사용되는 API 토큰이 있다는 사실을 필연적으로 발견하게 될 것입니다. 이러한 토큰은 일반적으로 GitHub Actions와 같은 다양한 서드파티 자동화나 Qualys 또는 Snyk와 같은 스캔 애플리케이션에서 사용됩니다. 이를 추적하고 예외를 구축하는 데 시간이 걸릴 수 있지만, 섀도우 IT를 식별하고 제거하는 과정에서 매우 가치 있는 작업이 될 수 있습니다.

경우에 따라 Okta, GitHub 또는 Elastic Cloud와 같은 타사 제공업체는 공용 IP 공간을 게시하므로 해당 IP에서 발생하는 활동을 필터링하기 위한 추가 검사를 구축할 수 있습니다. Tines 클라우드 테넌트를 사용하는 경우 https://<tenant-domain>/info에서 테넌트의 현재 공용 IP를 검색할 수 있습니다.

탐지 사례

이러한 자동화는 원래 단일 탐지 규칙을 위한 솔루션으로 시작되었지만, 다양한 시나리오에서 매우 유용하다는 것을 확인했습니다. 많은 탐지 규칙에 대해 다음과 같이 자문해 볼 수 있습니다. “이 경보가 우리가 확인한 우리 소유의 IP 주소에 의해 트리거된 경우, 우리 SOC가 경보를 종료할 것인가?” 우리는 이것이 타사 서비스에 대한 대부분의 행동 기반 탐지 규칙에 해당한다는 것을 확인했으며, 이는 자동화된 분류를 위한 좋은 후보가 됩니다.    

 

이 워크플로우로 구축할 수 있는 탐지에 대한 아이디어를 제공하기 위해, 초기 분류를 자동화하는 탐지 목록을 소개합니다. 이러한 탐지 중 일부는 이 자동화된 분류 워크플로우와 함께 작동하도록 구축된 사용자 정의 탐지이지만, 상당수는 오탐을 일부 제거하기 위해 분류 태그를 추가한 기존 탐지입니다.

 

새로운 수준의 보호 달성

이 블로그 게시물에서는 Elastic InfoSec 팀이 Tines를 사용하여 많은 경보의 초기 분류를 자동화하는 방법을 보여드렸습니다. 이 자동화를 통해 효율성을 높이는 동시에 가시성을 훨씬 더 향상할 수 있으며, 실제 위협을 조사하는 데 시간을 할애할 수 있게 되었습니다. Tines를 사용하여 지난 30일 동안 50,000건 이상의 경보를 완전히 조사하고 처리할 수 있었습니다. 이러한 각 경보는 트리거된 후 몇 초 이내에 철저히 조사되고 처리되었습니다. 이것 없이는 네트워크에서 동일한 수준의 보호를 유지하는 것이 불가능할 것입니다. 

직접 사용해 보고 싶으시다면, Elastic Cloud 14일 무료 체험판과 항상 무료로 제공되는 Tines 커뮤니티 에디션을 통해 이러한 워크플로우가 얼마나 강력한지 무료로 확인해 보실 수 있습니다.

이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

Elastic Cloud 무료 체험판 등록하기

선택하신 클라우드 서비스 제공자에서 완전히 로드된 배포를 이용하세요. Elasticsearch의 개발사로서, Elastic이 클라우드에 있는 여러분의 Elastic 클러스터에 기능과 지원을 제공해드립니다.

무료 체험판 시작