Visa의 첫 번째 Elastic Workflow가 통제된 인간 개입 AI 단계를 통해 경보 분류 시간을 10~20분에서 몇 초로 단축한 방법

Visa의 사이버 보안 엔지니어링 팀은 레거시 SIEM에서 Elastic으로 보안 운영을 현대화하는 과정의 일환으로, SOC에서 최초의 에이전틱 AI 워크플로우를 구축했습니다. 제한적인 인간 개입 AI 단계를 사용해 IR 준비가 된 케이스를 생성하는 4단계 파이프라인입니다. 고위험 메인프레임 탐지의 경우, 이전에는 수동 2차 쿼리가 필요했지만 분류 시간이 10~20분에서 몇 초로 줄었으며, 제어되고 감사 가능한 동일한 패턴을 이제 다른 탐지에 재사용할 수 있습니다.

Visa는 레거시 SIEM에서 Elastic으로 마이그레이션하고 있으며, 이 마이그레이션 과정에서 사이버 보안 엔지니어링 팀은 첫 번째 Elastic Workflows 파이프라인을 개념 검증으로 구축했습니다. 선택된 탐지 방식인 고위험 메인프레임 신원 탐지의 경우, 이전에 분석가들은 경보에서 후속 검색을 실행하여 책임 있는 사용자를 식별해야 했으며 결과는 분석가의 메인프레임 로그 경험에 따라 크게 달라졌습니다. 팀은 두 개의 Elasticsearch Query Language(ES|QL) 쿼리를 연결하고, IR 팀을 위한 구조화된 요약을 생성하는 제한적인 AI 단계를 추가했으며, 웹훅을 사용하여 케이스를 직접 IR 티켓팅 시스템으로 전달했습니다. 경보가 발동할 때, 분류 작업은 이제 10~20분이 아닌 몇 초 만에 완료되며, 동일한 4단계 패턴을 이제 다른 탐지에 적용할 수 있습니다.

Visa는 세계에서 가장 큰 결제 환경 중 하나를 안전하게 보호합니다. 레거시 SIEM에서 Elastic으로 광범위하게 현대화하는 과정에서, 사이버 보안 엔지니어링 팀은 Visa가 아직 확장 가능한 규모로 갖추지 못한 환경을 구축하고자 했습니다. 보안 운영 내에서 AI를 사용하는 통제되고 정당화 가능한 방식을 구축하는 것입니다. 그 기준은 구체적이었습니다. 모든 AI 단계는 감사 가능해야 하고, 범위가 한정적이어야 하며, 팀이 관리하는 데이터에 확실하게 기반을 두어야 합니다. 기준의 첫 번째 테스트 장소는 실행 시마다 인시던트 대응 팀이 수동 컨텍스트 수집에 10~20분을 소요한 후 조사를 시작할 수 있었던 고위험 메인프레임 신원 탐지였습니다.

탐지가 레거시 SIEM에서 실행되었을 때, 인시던트 대응 팀은 로그인하여 2차 검색을 실행하고 해당 활동의 배후에 있는 사용자를 파악해야 했습니다. 탐지를 통해 해당 이벤트를 식별합니다. 하지만 분석가는 여전히 행위자를 확인해야 했습니다.

팀의 관점은 간단합니다. 모든 실행 가능한 경보에 대해 IR 팀이 조치를 취하기 전에 2차 쿼리가 필요하다면, 파이프라인은 완전하지 않은 것입니다. 2차 쿼리를 파이프라인 자체의 상위 단계로 이동하면 IR 팀은 이미 보강되고 요약된 케이스를 받게 되고, 이는 검토를 위해 메인프레임 팀에 바로 전달할 수 있습니다.

Visa의 광범위한 프로젝트는 레거시 SIEM에서 Elastic으로 탐지 로직을 마이그레이션하는 것입니다. 이러한 마이그레이션은 규칙 변환 작업에 집중하는 경향이 있습니다. 팀은 엔지니어들이 변환 작업과 병행하여 새로운 플랫폼 기능을 시험해 볼 수 있는 여지를 마련했습니다.

팀의 사이버 보안 엔지니어는 Elastic Workflows 교육을 이수하고, 이미 잘 알고 있는 탐지를 선택하여 Elastic 솔루션 아키텍트와의 협력하에 첫 번째 버전을 구축했습니다. Elastic 팀은 엔지니어가 제공한 샘플에서 대표적인 테스트 데이터를 생성하고, 시작 워크플로우를 처음부터 새롭게 구축하여 엔지니어가 확장할 수 있는 템플릿으로 다시 전달했습니다.

기존 접근 방식에서는 데이터와 동일한 보안 플랫폼 내에서 네이티브 자동화를 제공할 수 없었습니다. Visa에서 SOAR 스타일의 오케스트레이션은 별도의 자동화 팀에서 관리하며, 탐지 자체와 다른 별도의 플랫폼에서 실행됩니다. Elastic Workflows를 사용하면 전체 파이프라인이 한 곳에서 실행됩니다. 탐지, 보강, 검증 및 전달이 엔지니어가 한 화면에서 읽고 편집할 수 있는 하나의 YAML 파일에 모두 네이티브로 포함됩니다.

Workflows가 적절한 출발점이었던 데에는 특정한 이유가 있습니다. Visa는 AI 단계가 입력받는 데이터, 출력하는 결과물, 그리고 모든 결정의 검증 방법에 대한 완전한 통제권을 필요로 했습니다. 규제 대상인 금융 서비스 환경에서 감사 가능성은 보안 운영에 있어 AI를 신뢰하기 위한 필수 조건입니다. Workflows는 완전히 정량화하고 정당화할 수 있는 패턴을 팀에 제공했으며, 각 단계가 단일 YAML 파일에 명확히 표시되어 Elastic의 로드맵에 있는 다른 에이전틱 기능으로 확장하기 전에 이를 확인할 수 있었습니다.

이전 워크플로우에서는 경보 후 조사가 이루어집니다. 탐지가 실행됩니다. IR 팀은 레거시 SIEM 시스템에 로그인합니다. 후속 검색을 실행하여 이벤트를 터미널과 사용자에게 다시 연결합니다. 메인프레임 로그는 그러한 작업에서 관대한 환경이 아닙니다.

세 가지 요인으로 인해 이전 상태는 비용이 많이 들었습니다,

• 2차 검색이 불가피했습니다. 한 번에 한 명의 사람만 터미널에 할당될 수 있지만, 터미널 값은 재사용됩니다. 플래그가 지정된 이벤트의 배후 사용자를 식별하기 위해, 분석가는 이벤트 시간 주변으로 해당 메인프레임 파티션의 해당 터미널에 대한 가장 가까운 이전 로그인을 조회해야 했습니다.
• 분석가의 기술이 매우 중요했습니다. 쿼리 언어와 메인프레임 이벤트 코드를 잘 아는 숙련된 분석가라면 신속하게 작업을 처리할 수 있습니다. 신입 분석가나 메인프레임 로그에 익숙하지 않은 분석가들은 눈에 띄게 더 오랜 시간이 걸렸습니다. 결과는 시간과 품질 모두에서 차이가 있었습니다.
• 메인프레임 이벤트 코드가 복잡합니다. 이벤트를 결과에 연결하는 단일 경로가 없습니다. 분석가들은 종종 문맥에 따라 의미가 달라지는 시스템 코드를 해석해야 했기 때문에 작업 속도가 느려지고 결과를 표준화하기가 더 어려웠습니다.

시간과 품질 모두 2차 검색에 달려 있습니다. 탐지 시스템은 해당 이벤트를 식별했지만, 분석가는 여전히 탐지 시스템의 출력에 포함되지 않은 조사를 진행하고 있습니다.

새로운 파이프라인은 Elastic Workflows 내에서 네 개의 단계가 연결된 형태로 실행됩니다.

1. 탐지(기본 ES|QL 쿼리): 5분 타이머와 10분 조회 윈도우에서 워크플로우는 메인프레임 로그에 대해 빠르고 한정적인 ES|QL 쿼리를 실행하여 대상 ID 활동을 찾습니다. 탐지는 의도적으로 정밀하게 이루어집니다. 팀은 실행당 한두 건을 초과하는 결과가 발생할 것이라고 기대하지 않으며, 실제로 경보는 1년에 몇 번만 발생합니다.
2. 보강(보조 ES|QL 쿼리): 반환된 각 이벤트에 대해 워크플로우는 기본 이벤트에서 터미널 값과 LPAR(메인프레임 파티션)을 가져와 이 터미널에 대한 가장 가까운 이전 로그인을 검색하는 후속 ES|QL 쿼리를 실행합니다. 터미널은 재사용되지만 한 번에 한 명의 사용자만 할당되므로, 가장 가까운 이전 로그인을 통해 해당 활동을 수행한 사용자를 식별합니다. 검증은 빠르게 진행됩니다. 결과를 만들어낸 동일한 쿼리를 엔지니어가 바로 확인할 수 있기 때문입니다.
3. AI 검증: 보강된 이벤트는 대규모 언어 모델(LLM) 지원 단계로 전달됩니다. 모델은 제한적인 프롬프트를 받습니다. 한 번에 한 사람만 터미널을 사용할 수 있다는 가정, 기본 경보 세부 정보, 그리고 보조 쿼리의 결과입니다. 수행하는 작업은 데이터가 결론을 뒷받침하는지 확인하고, 사용자의 이름과 ID, 원래 경보가 감지한 내용, 그리고 이 사람이 식별된 행위자인 이유를 포함하는 구조화된 요약을 생성하는 것입니다. 모델은 에스컬레이션 여부를 결정하지 않습니다. IR 팀이 결정합니다.
4. 전달(웹훅): 요약은 웹훅을 통해 IR 티켓팅 시스템으로 전달됩니다. 티켓이 생성될 때쯤이면 IR 엔지니어는 케이스를 구성하는 것이 아니라, 케이스를 읽고 있습니다.

여기서 가장 중요한 아키텍처상 특징은 전체 파이프라인이 보안 데이터와 동일한 플랫폼 내에서 네이티브로 실행된다는 점입니다. 별도의 SOAR가 존재하지 않으며, 유지관리해야 할 별도의 오케스트레이션 시스템도 없고, 탐지와 워크플로우 사이에 연결 고리도 없습니다.

주요 기술 특징

• 5분 타이머 및 10분 조회 기간으로 ES|QL 기본 쿼리를 실행합니다.
• ES|QL 보조 쿼리는 기본 이벤트에서 터미널과 LPAR 정보를 가져와 가장 가까운 이전 로그인을 찾습니다.
• 이전에 분석 비용이 많이 들었던 2차 수동 쿼리 대신 탐지 방식을 선택했습니다.
• LLM 기반 검증 단계에서 자유 형식 분석이 아닌 제한되고 구조화된 프롬프트를 받습니다.
• 컨텍스트 윈도우: 관련 기록 중 최근 5~15분만 모델에 전달되어 전송되는 토큰을 줄이고 모델의 작업 컨텍스트를 강화합니다
• Visa는 여러 서비스 제공업체 간에 전환하며, 플랫폼은 모델에 구애받지 않습니다.
• 워크플로우는 코드 편집기처럼 하나의 Kibana 화면에서 작성하고 테스트할 수 있는 단일 YAML 파일입니다.
• 웹훅은 구조화된 요약을 IR 티켓팅 시스템으로 직접 전달합니다

연결된 ES|QL 탐지 및 단일 워크플로우 내 보강

탐지와 보강을 분석가가 매개하는 두 단계가 아닌 하나의 연결된 흐름으로 처리한 것이 나머지 파이프라인을 가능하게 한 핵심 요소였습니다. ES|QL의 파이프 모델을 통해 팀은 플로우를 선언적으로 표현합니다. 기본 쿼리는 플래그가 지정된 이벤트를 식별하고, 보조 쿼리는 해당 작업을 수행한 것으로 추정되는 사람을 결정하는 터미널-사용자 매핑 계층을 추가합니다. 중간에 분석가 콘솔 세션이 없으며, 로그인해야 할 두 번째 도구도 없습니다. 이제 워크플로우 구조는 "사건이 일어났는가?"에서 멈추지 않고 분석가의 실제 질문("누가 이 작업을 수행했는가?") 구조와 일치합니다.

정교하게 범위를 좁힌 제한적인 AI 단계

AI 단계는 한 가지 특정 작업을 수행합니다. 보강 데이터가 결론을 뒷받침하는지 확인하고 IR 팀이 몇 초 안에 읽을 수 있는 구조화된 요약을 생성하는 것입니다. 탐지 로직을 생성하지는 않습니다. 에스컬레이션 여부를 결정하지 않습니다. 분석의 기초가 되는 가정(한 번에 한 사람만 터미널을 사용할 수 있음)이 설명되며, 이 가정에 따라 평가하기 위해 가장 가까운 이전 로그인이 제공됩니다.

이러한 한정적인 범위가 바로 핵심입니다. 팀의 선택은 "모델이 조사하도록 하는 것"이 아니라 "이미 쿼리가 반환한 내용을 모델이 검증하고 요약하도록 하는 것"이었습니다. 파이프라인에서 모든 AI 결정은 팀이 볼 수 있는 데이터를 팀이 제어하는 기준에 따라 평가하는 것입니다. 이것이 검증을 불투명하지 않고 감사 가능하게 만드는 이유입니다.

토큰 효율적인 컨텍스트 윈도우

모델은 절대 필요한 수준 이상의 데이터를 보지 않습니다. 파이프라인은 전달된 레코드 중 이벤트의 시간 윈도우, 즉 마지막 5분에서 15분에 관련된 것만 필터링하며, 이는 탐지가 구성되는 방식과 일치합니다. 결과적으로 더 작은 컨텍스트 윈도우가 생성되고, 결정당 토큰 수가 감소하며, 추론이 더 엄격해집니다. 모델이 질문과 관련 없는 레코드를 해석하려고 하지 않기 때문입니다.

보안 플랫폼 내 네이티브 자동화

전체 파이프라인은 데이터와 함께 Elastic 내에 존재합니다. 별도로 유지관리해야 할 오케스트레이션 플랫폼이 없고, 인시던트 중에 유지해야 할 취약한 통합도 없으며, 다른 팀과 워크플로우를 조정할 필요도 없습니다. YAML로 작성된 Workflows는 HTTP를 통해 다른 시스템을 호출할 수 있으므로, 플랫폼의 범위는 기본 환경을 포기하지 않고 확장됩니다. 특히 Visa의 경우 이는 중요한 의미가 있습니다. 현재 SOAR 스타일 오케스트레이션은 보안 데이터와는 다른 플랫폼에서 별도의 자동화 팀에 의해 관리되고 있습니다. 해당 팀은 이미 Elastic에 대한 API 액세스를 요청했으며, 사이버 보안 엔지니어링 팀은 현재 다른 도구에 있는 응답 작업을 흡수하기 위해 Workflows를 사용하는 것을 검토하고 있습니다. Visa 내부에서 단일 네이티브 자동화 환경으로 통합해야 할 필요성은 더 이상 이론적인 이야기가 아닙니다.

가장 눈에 띄는 결과는 속도이지만, 실질적으로 중요한 결과는 일관성입니다. 메인프레임 로그 해석은 이전에 Visa의 분류에서 가장 변동성이 큰 부분 중 하나였습니다. 숙련된 분석가는 2차 쿼리 작업을 신속하게 완료할 수 있었으나, 신규 분석가나 메인프레임 이벤트 코드에 익숙하지 않은 분석가는 훨씬 더 많은 시간이 소요되었으며, 결과의 변동성도 더 컸습니다.

어셈블리와 요약을 파이프라인에 포함시키면, 레거시 쿼리 언어와 메인프레임 이벤트 코드에 대한 분석가의 전문 지식에 의존하던 워크플로우 부분에서 분석가 작업에 더 이상 의존하지 않게 됩니다. IR 엔지니어는 구조화된 요약을 읽고 조치를 취할지 여부에 대해 판단을 내립니다.

탐지 자체는 매우 드물게 발생하며, 실제로 1년에 몇 번 정도만 발생했습니다. 이는 의도된 것입니다. 발생 빈도가 낮은 고위험 경보여서 2차 수동 쿼리 단계의 비용을 제거하는 것이 타당하므로 팀에서 이를 선택했습니다. 더 중요한 점은 이것이 Visa의 첫 번째 실제 프로덕션 워크플로우이며, 확립된 4단계 패턴이 이제 다른 탐지에도 적용될 준비가 되었다는 것입니다.

Visa의 IR 엔지니어가 경보 발생 시 보는 내용은 원래 이벤트가 포함된 티켓, 이름과 ID로 식별된 사용자, 경보 사유, 그리고 기본 데이터로 연결되는 링크입니다. 파이프라인이 2차 쿼리를 수행했고, LLM이 이를 검증하고 요약했으며, 웹훅이 티켓을 생성했습니다. 엔지니어의 첫 번째 행동은 쿼리 구성이 아닌 판단입니다.

인간은 여전히 의사 결정권자입니다. 파이프라인이 구성합니다. AI가 검증하고 요약합니다. 엔지니어는 오직 엔지니어만 할 수 있는 일을 합니다. 판단하고, 확인하고, 에스컬레이션하는 것입니다. 상위 단계로 보내는 작업은 반복 가능한 작업입니다. 엔지니어에게 남는 작업은 판단이 필요한 작업입니다.

이번이 Visa의 첫 번째 Workflows 프로젝트이지만 마지막이 아닌 이유는 4단계 구조는 이식 가능하기 때문입니다. 특정 탐지는 이례적이지만, 그와 관련된 운영 패턴은 그렇지 않습니다. 분석가가 조치를 취하기 전에 탐지에서 정해진 반복 가능한 후속 검색이 필요하다면, 동일한 4단계가 적용됩니다.

이 빌드에서 얻은 세 가지 원칙은 2차 쿼리로 인한 병목 현상이 있는 모든 탐지에 적용됩니다. 후속 조치가 항상 같은 방식으로 진행된다면 이는 분석가의 업무가 아니므로, 런북의 정의된 부분들을 파이프라인 자체에 자동화합니다. AI 단계에 감사 가능할 정도의 한정적인 작업을 제공합니다. 제한된 프롬프트, 구조화된 입력, 엔지니어가 데이터에 대해 검증할 수 있는 요약을 사용하는 것입니다. 윈도우 컨텍스트를 사용하여 모델이 쿼리가 반환한 전체 데이터가 아닌 이벤트 시점과 관련된 정보만 받도록 합니다. 첫 번째 원칙은 가장 보편적으로 적용됩니다. 나머지 두 가지는 AI를 정당화 가능한 상태로 유지하는 원칙들입니다.

4단계 패턴(탐지, 보강, 검증, 전달)은 이식성이 뛰어납니다. 팀에서는 마이그레이션 범위 내에서 동일한 연결형, AI 기반 요약, 웹훅 전달 방식의 이점을 누릴 수 있는 다른 탐지 사례들을 이미 파악했습니다. 팀은 Attack Discovery를 적극적으로 평가하고 있습니다. Martin에 따르면 이 기능은 Elastic에 관심을 갖게 된 계기입니다. 이러한 순서는 의도적인 것이었습니다. Workflows를 통해 Visa는 내부적으로 더 많은 상관관계 로직을 실행하는 기능으로 확장하기 전에 완벽하게 정량화하고 검증할 수 있는 패턴을 확보할 수 있었으며, 이는 규제 대상인 금융 서비스 SOC에 적합한 경로입니다. 팀은 위협 사냥을 위한 AI 에이전트를 병렬로 구축하고 있으며, 현재 별도의 자동화 그룹에서 처리하는 응답 작업을 Workflows가 어떻게 흡수할 수 있는지를 조사하고 있습니다. 이제 Elastic의 출시 주기를 따라가는 것도 작업의 일부입니다.

Visa는 세계 최대 규모의 결제 네트워크 중 하나이며, 그 규모에 걸맞은 보안 운영을 유지하고 있습니다. 조직에서 현재 Visa의 확장 규모로 마이그레이션하지 않아도, 첫 번째 탐지를 변환하든 전체 SOC를 재구축하든 동일한 원칙이 적용됩니다. 경보가 발생했을 때 조치를 취하기 전에 2차 쿼리가 필요하다면, 파이프라인은 불완전하며 4단계 패턴은 규모에 관계없이 모든 단계에서 작동합니다.

Elastic Workflows를 통해 조사 단계를 탐지 파이프라인의 상위 단계로 이동시킬 수 있는 방법을 알아보세요.