01. 보안업무 자동화를 위한 SOAR

점점 복잡해지는 보안환경 변화에 대응하기 위한 가장 좋은 솔루션으로 SOAR가 소개되고 있다. 실제 현업에서 SOAR 도입을 통해 업무 효율 증대의 도입 효과를 낼 수 있으려면 어떠한 구축 전략과 목표를  설정해야 하는지 알아보자. 

SOAR(Security Orchestration, Automation and Response)는 2015년 가트너에서 처음 사용한 용어로 SOAR를 통해 사람(People), 기술(Technology) 그리고 프로세스(Process)를 조율하고 자동화함으로써 조직에서 사고 대응 효율성과 일관성을 개선할 수 있도록 도와준다. 즉, 다양한 사이버 위협에 대해, 대응 수준을 자동(Automation) 으로 분류하고, 업무 표준화를 달성할 수 있다.

현재 보안 환경은 복잡성과 관리상의 오버헤드를 줄이고 효율성을 높여야 할 필요성에 따라 보안 기술의  융합이 가속화되고 있다. 

SOAR 또한 복잡한 보안 관리 환경을 최적화를 위해 아래 [그림 1] 처럼 SOA + SIRP + TIP 3가지로 요소로 융합 구성되어 있다.

[그림 1] SOAR 구성요소

SOAR의 업무처리 프로세스를 살펴보면 Incident가 접수되면 Playbook을 통해 침해 분석에 필요한 공격자 IP의 IOC/평판정보와 내/외부 모든 로그를 분석하고 판단하여, 보안장비로 차단 명령을 내려 자동 차단된다. 이어서, 침해대응 보고서가 생성되고, 문자와 메일 발송으로 상황전파까지 모든 과정이 보안 담당자 혹은 관제 전문가의 개입없이 자동으로 이루어 진다.

이렇듯 SOAR가 자동으로 업무를 수행하기 위해서는 자동화에 필요한 데이터와 정보, 판단 기준, 그리고 보안 장비를 제어 할 수 있는 대응 기능까지 SOA + SIRP + TIP 아키텍처 구성요소의 융합이 필요한데 항목별로 살펴보자.

02. SOAR 도입을 위한 사전 준비

1) 자동화 프로세스 변화

SOC의 보안수준을 유지 및 향상하기 위해서는 사람, 기술, 프로세스의 유기적인 조화가 중요하다. 이 3가지 요소 중 보다 중요한 것을 꼽으라면 프로세스 일 것이다. 프로세스가 없다면 침해 발생 시 사람들은 무엇을 해야 할지 모르고, 우왕좌왕 할 것이다. 즉 프로세스가 중요한 이유는 행동 절차를 정의하지 않으면 보안 담당자들의 업무 처리는 임의적이고, 할 때마다 다를 수 있다.  SOAR에서도 동일하다. Playbook 생성 시 사이버 공격 유형별 혹은 보안 업무별로 프로세스 기준이 없다면 표준화된 자동화 업무 프로세스로 전환이 불가능 할 것 이다. [그림 2] 처럼 보유하고 있는 솔루션 별로 포지션과 역할을 먼저 정의를 하고, Playbook 실행에 필요한 데이터와 정보들은 수집되고 있는지, 그리고, 최종 차단 장비에 맞는 차단 API 지원 여부를 파악해야 한다. 

[그림 2] IGLOO 플랫폼 자동화 프로세스

SOAR가 도입된다고 해서 모든 업무가 자동화 되는 건 아니다. 정밀분석이나 부서간 협의, Playbook 생성/관리 등의 업무는 관제 전문가 직접 수행을 해야 한다. 긴 시간 동안 단순 반복 업무들 중심으로 Playbook 자동화를 추진하면 된다. 즉, 사람이 직접해야 할 일과 기계가 해야 할 일들이 있다. 사람과 기계의 특성에 맞는 업무 R&R을 정의하면 된다. 

2) 업무 자동화를 위한 Playbook 설계

Playbook을 만들기 위해서는 무작정 Playbook을 만들어 보자는 접근보다는 기존 업무 환경과 프로세스 파악 등의 설계 단계가 필요하다. 즉, 어떤 업무를 자동화할 것인가 선별하는 작업이 필요하다. 기본적으로 SIEM에서 발생하는 경보는 모두 Playbook 처리 하겠다라고 한다면 다음과 같은 준비가 필요하다. 

 ① SIEM 경보를 최적화하고, 공격 유형별로 룰 그룹화 분류 작업

 ② 선별 : 수년 동안 경험에 의해 대응 프로세스가 명확한 탐지 룰 – Playbook 자동화

                ​(접수 → 분석 → 대응 → 완료까지 전 과정 자동화 적용 룰로 분류)

                Playbook을 통한 초동 분석 후 대응 단계로 이관 하여 관제 전문가 직접 대응

 ③ 분석 : 공격 유형별로 분석에 필요한 데이터와 정보들이 존재하는지 파악

 ④ 차단 : 공격 형태에 따라 차단 적용할 보안 장비를 정의

                ​SOAR와 차단 보안장비 간 차단 API 개발 여부를 사전에 파악 필요

                ​(SOAR 차단 API를 지원하는 보안장비로 도입하는 것을 권고)

 ⑤ 상황전파 : 대상자 정의와 메일과 SMS 단문자 시스템 연계 확인

 ⑥ Case 선별 : 동일 공격에 대해 이벤트 처리 기준을 정의

[그림 3] 공격 유형별 Playbook 설계

3) 자동 침해대응을 위한 Playbook 생성

Playbook 생성을 위한 업무 환경 파악 후 전체적인 설계가 되었다면 SIEM 룰 별로 자동 처리할 Playbook을 생성하면 된다. 아래 [그림 4]는 현재 관제 전문가가 웹 취약점 공격 분석 시 정/오탐 판단하는 과정으로 판단 항목들을 일일이 SIEM에서 검색하고, 엑셀등에서 관련 정보를 조회하는 침해대응 과정이다. SIEM 경보가 발생할 때 마다 이런 과정은 반복된다. 몇 년 근무한 노련한 관제전문가는 정/오탐 판단에 필요한 정보들이 머릿속에 다 저장되어 있으며, 마치 머신 처럼 티켓 처리를 하는 수준에 있다. 이런 업무들을 Playbook에 적용하여 자동화를 하면 된다. 앞서 설계 단계에서 언급하였듯이 보안관제 전문가가 침해대응 분석 시 필요로 하는 데이터들이  SOAR,  SIEM, 자산 시스템 등에 필요시 즉시 조회 가능한 형태로 저장 및 등록이 되어 있어야 한다.

[그림 4]는 보안 전문가의 직접대응 프로세스를 Playbook으로 구현하여 자동화된 대응 프로세스이다. 살펴 보면, 침해대응에 필요한 데이터와 정보를 조회 한 후 정의한 조건에 따라 국내/해외 IP에 따라 국내 IP면 무시 처리로 티켓 종결 될 것이며, 해외IP이면 다음 단계로 넘어간다. 다음 단계에서는 위협 인텔리전스(CTI) 정보와 비교하여 유해IP면 다음 단계로 넘어가고, 그렇지 않으면 메일 발송으로 상황전파 후 티켓 종결된다. 이렇듯 단계별로 관제 전문가가 판단 항목별로 정/오판 판단하듯이 Playbook에서 정의하면 어떤 방화벽에서 차단 할 것인가까지 자동으로 프로세스에 따라 대응하게 된다. Playbook 설계 단계에서 공격 유형별 분석 과정을 정확히 파악해야만 정확한 자동 대응 프로세스를 만들 수 있을 것 이다. 

보안 담당자나 관제 전문가가 변경되더라도 분석 노하우가 축적된 SOAR Playbook을 통해 일정 수준 이상의 일관된 대응 프로세스 표준화를 유지할 수 있게 된다.

[그림 4] 단계별 대응 Playbook

[그림 4]의 Playbook은 단계별 대응이 달라지는 프로세스였다. 다음 [그림 5] Playbook은 우리 인프라에 어떤 영향을 미쳤는지 판단 항목 전체에 대해 공격 행위 분석 후 정/오탐 판단하는 Playbook이다. 이 Playbook에는 상위기관으로 부터 받은 BlackList IP나 IPS 탐지된 IP등 다양한 경보에 자동 분석 프로세스로 적용할 수 있다. [그림 5]에서 보듯이 침해 분석 하듯이 분석API를 통해 SIEM에 수집되어 있는 ① FW 허용로그와 IPS, WAF의 탐지이력과 WEB Access log를 통해 서버 접근 여부를 조회하여 침해 흔적을 찾을 수 있다. ② Decision 설정을 통해 FW, IPS, WAF, WEB 로그 이력이 있으면 다음 분석 단계로 넘어간다. 그리고, ③ 해외IP와 위협정보를 비교하게 된다. 물론, 종결되지 않게 하려면 두 단계를 합쳐서 한번에 데이터 조회 후 몇 개 장비 이상에서 흔적을 찾으면 대응하도록 설정할 수도 있다. ④ 절차에 의해 자동으로 방화벽 차단을 할 수 있으나 관리자나 관제 전문가에게 “방화벽 차단 승인＂을 받아야만 다음 단계로 넘길 수도 있다. 정확한 판단을 위한 전문가의 개입이다. ⑤ 관리자 승인 이후 방화벽 차단이 된다. 그리고, ⑥ 침해대응 이력 관리를 위해 사전에 정의한 대응 문구가 삽입되어 자동 티켓팅이 완료된다. ⑦ Playbook 전체 침해대응 과정을 보고서로 생성되어 이력 관리와 보고를 위한 출력물 형태로 지원 된다.

[그림 5] 침해 분석용 Playbook과 자동 생성된 보고서

좋은 Playbook은 어떻게 만들 수 있냐?, 좋은 Playbook의 정의는 무엇이냐?와 같은 질문을 많이 받는다. 위의 두 Playbook 사례에서 보았듯이 Playbook에 많은 API와 APP, 그리고 Action Flow를 지원하기 때문에 Playbook 설계를 어떻게 하냐에 따라 다양한 형태로 구현은 가능하다. 즉, 분석 결과에 따라 단계별 대응이 달라지는 Playbook이냐, 공격IP 행위 분석을 위한 Playbook이냐 등으로 경보와 업무 프로세스에 맞게 유연하게 생성하면 된다. 

Playbook과 Incident 관제 전문가 모드를 융합하여 침해 대응 프로세스를 구성할 수도 있다. 정/오탐 판단에 필요한 각종 로그 검색과 정보 수집 등의 단순 반복 과정은 기계(Playbook)가 수행하고, 사람(관제 전문가)은 공격 재연과 보안장비 차단 승인 등의 업무만 [그림 6] 처럼 수행하게 된다. 물론 Playbook에서 초동 분석 후 대응과 승인, 혹은 완료 단계까지 자유롭게 원하는 단계를 선택하여 보낼 수 있다. 사람은 좀 더 고급 업무에 집중하도록 구성하는 것이 이 기능의 목표이다.

[그림 6] Playbook과 관제 전문가 모드 융합 침해대응 프로세스

03. SOAR와 AI 시스템 관계 정의

1) SOAR와 AI 시스템 상호 보완적 관계로 발전

복잡한 보안 환경 변화와 데이터 홍수와 Alert 대응과정에서 보안 담당자와 관제 전문가의 분석 및 대응 속도는 한계에 도달한지 이미 오래되었다. 그래서 이를 해결하고자 수많은 시스템이 출시되었으나 반쪽 효과 뿐이었다. 필자가 경험상 내린 결론은 SOAR와 AI 시스템이 융합되어 상호 보완적 관계로 발전해야만 보안 업무 자동화의 완성도를 높일 수 있다는 것이다. 

냉정하게 보안 현실을 들여다 보면 많은 보안관제가 IPS/TMS 중심으로 운영이 되고 있으며 수십만 건에 달하는 Alert들 때문에 알려진 공격 대응하기에도 힘들다. 발생하는 DMZ존 IPS 한대에서 일일 탐지 건수가 평균 7만~50만 건이다. 탐지 유형을 세부적으로 살펴 보면 60% 이상은 Flooding, Scan성의  Anomaly 공격이며, 40%는 Signature 공격이 탐지된다. 이중에 한정된 인력과 10년 이상 관제센터 노하우를 통해 공격 위협성 높은 10%의 웹해킹과 악성코드 중심으로 관제가 이루어 진다. 문제는 IPS 한대만 있는 것이 아니다. 산하기관 혹은 계열사 대상 관제센터인 경우 평균 20대 IPS를 관제 대상으로 모니터링 분석을 한다. 관제 전문가 2명이 24시간 교대 근무를 해도 약 10만 건 되는 IPS Alert을 분석하기는 불가능 하다. 그래서 SOAR와 AI시스템이 융합되어 상호 보완적 관계로 지속 발전이 되어야만 이 문제점을 해결 할 수 있다.  만약 SOAR만 도입되어 자동 로그 분석하고 대응 해 준다고 해도 시그니처 공격들의 정/오탐 판단에 필수인 IPS Payload 자동 분석은 불가능하며, 결국 사람이 해야 할 몫이다. 접수되는 티켓마다 사람이 건건이 분석해야 한다면 자동화의 의미는 없을 것 이다. 

IPS Payload를 자동 정/오탐 분석해주는 시스템이 바로 AI시스템이다. SOAR의 지능적 자동화를 위해 AI시스템을 동시 구축을 권장 드린다. 그 외 IPS에서 과반수 이상 탐지되는 Anomaly 공격들은 인프라 보안 장비들에서 행위분석 중심의 로그 검색과 국내/해외 IP구분과 CTI해당 여부, 과거 공격이력, 반복 접근 등으로 Playbook을 구성하고, Decision 판단 결과에 따라 공격IP의 차단 여부와 기간을 설정하면 된다. 그러면 IPS에서 탐지는 이벤트 전체를 대응 할 수 있게 된다. 그러면 관제 전문가를 줄여도 되는 것 아니냐는 말씀들을 많이 하시지만 Playbook을 정교하게 개선하고, 처리 결과를 분석하는 과정이 필요하다. 그리고, 신규 공격에 맞는 Playbook을 생성하여 지속적으로 관제 자동화를 유지 관리해야 한다.

[그림 8] SOAR와 AI 시스템의 상호 보완적 관계

04. 구축 전략과 도입 효과

본문 서두에서 언급한 것 처럼 현재 보안 환경은 복잡성과 관리상의 오버헤드를 줄이고 효율성을 높여야 하기 때문에 보안 기술 융합이 가속화되고 있다. SOAR 도입에 있어 제조사의 명확한 구축 전략과 목표가 있어야 한다. 이에 이글루 솔루션간의 융합을 통해  지능적 자동화 SOAR 플랫폼이 아래 [그림5-9]이다. 서로 다른 역할을 하는 보안 업무별 전문 솔루션들이지만 SOAR를 중심으로 유기적 연결을 통해 하나의 플랫폼으로 동작한다. 솔루션이 도입 될 때 마다 모니터링해야 하는 관리 화면이 증가해서는 안된다. One UI와 SSO구성, 공통 데이터 관리는 기본적으로 제공이 되어야 한다. 즉, SOAR UI에서 침해분석 시 필요한 위협 정보와 자산/취약점 정보와 침해 로그 분석까지 클릭 한번으로 모두 확인 가능해야 한다. 또한 야간 관제를 못하는 산하기관에 긴급 차단이 필요한 경우 SOAR 차단 Proxy 서버를 통해 해당 기관 방화벽으로 차단 정책을 바로 적용할 수 있어야 한다. 자체적으로 IGLOO CTI 솔루션을 운영한다면 산하기관으로 차단 권고IP를 일괄 배포하여 산하기관 SIEM에서 경보 발생과 SOAR를 통한 자동 차단으로 단순 업무가 해결될 수 있고, 상황전파와 대응 시간 또한 단축 될 수 있다.

[그림 9] 지능적 자동화 SOAR 플랫폼

도입 효과를 내려면 도입 목적이 명확하면 된다. 무엇보다 중요한 부분은 보안 관리자 혹은 관제 전문가의 자동화 전환에 대한 확고한 의지가 필요하다. 또한 앞서 언급한 제조사 구축 전략도 동일하게 중요한 요소이다. 

대표적인 도입 효과로 SOAR 통해 SIEM 경보 100% 자동화 처리, IPS 이벤트 100% 자동화 처리를 들 수 있다. 상위기관에서 차단 권고하는 IP 자동 등록 및 차단 등 업무 자동화를 하고자 하는 부분이 명확하면 된다. 이미 IGLOO SOAR 도입한 기관중에서는 자동화에 따라 일일 대응 건수가 몇천건에서 10만건까지 늘어나게 되었다. Next 관제방법론을 위해 새로운 관제 범위 확대와 업무를 통해 SKILL-UP 할 수 있는 공격자의 전략과 전술, 그리고 그 과정(TTPs) 분석과 장기간 심층 분석 업무를 준비하고 있다.  

앞서 사례에서도 보듯이 건수에 대한 부분은 확연히 도입 전과 후는 차이가 발생한다. 그러나 필자는 침해대응 건수의 관점 보다는 관제 전문가들의 경보 피로도에 더 집중하고 싶었다. Orca의 경보 피로도 보고서를 보면 보안 경보는 넘쳐나고, 이런 경보 피로도는 이직과 중요한 경보의 누락을 유발한다고 한다. 관제 전문가들의 경보 번아웃이 경보가 많이 발생 해서 인지, 아니면 발생한 경보에 대해 건 by 건 정/오탐 분석하기 위해 확인하는 단순 반복적 과정 때문인가를 확인해 봤다.후자가 더 힘들다고 한다. 단순 경보 처리가 아니라 침해분석을 하면 피로도를 못 느낀다고 한다.

세일즈포스의 설문조사 결과를 보면 직장에서 자동화를 사용한 결과 89%가 직업에 만족하고, 84%는 회사에 만족한다고 한다. 즉, 생산성이 향상되다 보니 시간 절약으로 일과 삶의 균형이 잡히고, 직업과 직장에 만족도 또한 높아 졌다고 한다.

단순 대응 건수의 증가보다는 직원들의 업무 만족도와 성장에 포인트를 두면 좋을 것 같다.

[그림 10] SOAR 도입 효과