Genians Security Center는 기업에 대한 위협을 식별하고 대응하기 위한 능동적이며 효율적인 Threat Hunting 전략을 연구하며 제시합니다. 'Threat Hunting'이란 발생할 수 있거나 진행되고 있는 위협을 제거하며, 그 결과를 보안 체계에 적용하는 능동적인 대응 전략입니다.
이를 통해 창의적이고 고도화되는 공격 전략에 지속적으로 대응할 수 있는 보안 수준을 만들 수 있습니다. 현재 사이버 보안의 공격자 진영은 연합하고 고도화되고 있으며, 해킹에 대한 사회적인 관심과 함께 화이트해커들의 노력으로 공격 기술은 가파르게 상향되고 있습니다.
이 끝나지 않는 게임에서 기울어진 운동장의 각도를 줄이기 위해서는 방어자 진영의 기술과 체계도 함께 성장해야 합니다. 고도화된 대응 체계와 기술을 통해 공격 시도를 무력화하고 국가, 기업, 개인에게 발생할 수 있는 리스크를 제거하고 안전하게 목표를 결정할 수 있는 진정한 위협 인텔리전스가 필요할 것 입니다. 이를 기반으로 이기는 게임을 할 수 있는 중장기적으로 성장 가능한 대응 전략을 제시해야 할 시대입니다.
하지만 현실은 어떨까요?
현재 공격을 직접적으로 마주하고 있는 최전선은 끝도없이 수위가 높아지는 댐을 맨손으로 흙을 올려가며 막는 것과 같습니다. 언제 구멍이 뚫리고 무너질지 모르는 그런 상황 말입니다. 창의적으로 움직이는 공격 진영과 달리 지나가버린 시간 속에 남은 흔적을 찾고 대응하기 위한 시스템과 체계를 유지하는 데도 리소스가 전부 소비되었다는 의미입니다.
창의적인 위협 가설 수립과 능동적인 공격 표면 관리는 언젠가는 해볼 수도 있는 밀려난 숙제일 뿐입니다. 이러한 만성적인 대응 전략 부채는 우리를 주기적인 번아웃과 무력감으로 몰아넣습니다. 어차피 모든 공격을 막을 수는 없다라는 냉소주의는 기존 대응 전략의 한계를 혁신하는 데 가장 큰 걸림돌입니다.
문제는 이 안전한 울타리를 유지하는 데 너무 많은 일들이 존재한다는 겁니다. 새로운 정책과 기술이 생겨남에 따라 성장에도 절대적인 시간이 존재하며 무한 복제가 되지 않는 인간이지만 목표와 해야하는 일은 굉장히 빠른 속도로 늘어나고 있습니다. 누군가 지쳐서 포기하면 구멍이 생기고 이 안전한 울타리에 위협이나 리스크가 발생할 수 있게 되어버립니다. 절대 지치거나 포기하지 않는 인간 대신 일을 해줄 존재가 있으면 좋을 것 같습니다.
놀라지 마세요. 이제는 그것이 가능한 시대가 되었습니다.
트랜스포머의 등장 이후 LLM이 빠른 속도로 보편화되면서 어느 정도의 지식이 있으면 할 수 있는 반복적인 작업들을 에이전트가 대신 해줄 수 있게 되었습니다. 우리는 그래서 물어보고 확인하는 일상적인 행위들은 대부분 LLM에 의존하고 있습니다. 약간 환각이 있더라도 프롬프트 개선을 통해서 어느정도의 적합하고 합당하다고 느끼는 결과물들을 확보하고 있습니다.
LLM을 사용하면서 가장 크게 느끼는 착각은 내가 하고 있다는 경험입니다. 물론 데이터 생태계를 만들고 프롬프트를 개선하고 결과를 확인하지만 실제로는 모델이 하는 거겠죠. 여기서 중요한 것은 어떤 일에 대한 방향과 설계를 하고 있다는 것을 인지하는 겁니다. 자신이 그 동안 해왔던 경험과 체계 그리고 아주 구체적인 목적 안에서 LLM을 적용하고 있을 뿐입니다.
그래서 개인적으로는 LLM이 빛을 내기 좋은 환경은 고품질 데이터와 효율적인 프롬프트보다 구체적인 목표와 체계가 더 중요하다고 생각합니다. 요즘 흔히 이야기하는 AI 에이전트와 워크플로우 중에 뭐가 더 중요하냐고 묻는다면 저는 당연하게도 워크플로우, 즉 목표이자 체계의 부산물입니다. 구체적으로 문제가 잘 정의되어있고 그걸 해결하기 위한 방향과 프로세스가 우선시 되어야 할 것 입니다.
하지만 보통 우리는 LLM에게 문제에 대한 해결 방안과 프로세스까지 의존하게 됩니다. LLM을 이용한 기술을 제어하지 못하고 목표와 체계를 맡기는 것은 그건 기술이 아닌 존재가 될 겁니다. 인간으로 기술을 제어하지 못한 책임으로 스카이넷이나 울트론 같은 존재가 나타나는 배드엔딩이 될 확률이 높아지고 있습니다.
이것은 도메인에 특화된 SLM이나 Graph와 RAG를 활용한다고 해도 크게 본질적으로는 달라지지 않을 것 같습니다. 서론이 좀 길었지만 시대의 변화가 발생했으며 우리는 설계자의 역할에 더 집중하는 것이 중장기적으로는 맞을 것 같다는 결론입니다.
대응 전략의 설계자로서 가장 먼저 해야 할 일은 공격자와 동일한 시선에서 보고 움직이는 것입니다. 조직의 위치를 기준으로 외부/내부에서 발생하는 위협 정보들을 수집하고 해석하고 직접적인 리스크를 제거하기 위한 결정을 만들어야 합니다. 외부에 공개되어 있거나 좀 더 전문적인 정보들을 수집하고 내부의 발생하고 있는 솔루션들의 경보들이 서로 상호보완적으로 성장할 수 있도록 위협생태계(ThreatEcosystem)를 만들 필요가 있습니다.
현대 위협생태계의 중요한 요소인 EDR은 내부에서 발생하는 위협 정보를 담당하게 됩니다. 특히 사용자가 직접 다루게 되는 PC나 노트북, 서버들을 통해 좀 더 구체적인 행위를 식별할 수 있는 역할입니다. 행위의 특징 상 지속적이며 구체적인 신호를 만들 수 있습니다. 이를 이용해서 컴플라이언스 위반이나 악성 위협으로 발전 가능성이 있는 리스크를 찾아내야 합니다.
이 목표를 달성하기 위한 이전 시대의 프로세스에서 가장 큰 문제는 내부의 신호를 줄이고 감추는 데 집중을 한 것입니다. 그 이유는 신호를 확인하고 해석하고 처리하고 관리하는 일이 많다는 겁니다. 그걸 위해서 운영할 수 있는 구조를 만들고 모니터링하게 되면서 위협 정보로서 활용하기보다는 제거 대상으로 만들어버렸습니다. 그런데 이 문제를 LLM이 적용된 AI 에이전트가 해결해 줄 수 있습니다.
요즘 많이들 쓰시는 워크플로우 자동화 도구들이 있습니다. 얼마 전 google에서 Opal을 공개했으며 opanai에서는 Agent Builder를 보여줬습니다. 기존 강자로는 make과 n8n이 있었으며 n8n에서도 에이전트 빌더 기능을 출시했습니다. 산업과 작업 환경에 따라 적합한 워크플로우와 AI 에이전트를 만들기에 좋은 시대입니다.
데이터와 코드를 다루는 분들이라면 직접 Lang[Chain|Grpah], Airflow와 같은 도구들을 활용하실 겁니다. 지식그래프(KnowledgeGraph)와 요즘 핫한 팔란티어의 온톨로지(Ontology), Graph와 Vector를 활용한 복잡한 데이터를 만들기도 하고 빅데이터를 처리하기 위해서 Spark나 BigQuery 같은 엔진을 워크플로우들과 함께 사용하기도 합니다. 이를 위해서 데이터를 위한 창고(warehouse)나 호수(lake)를 조성해야 하기도 하구요.
위협생태계를 구축하기 위해서는 정말 많은 것들을 고려해야 하는 것처럼 느껴지고 AI 에이전트가 먼저인가 워크플로우가 먼저인가라는 고민도 생기는 그런 상황에서 중요한 것은 이미 언급했듯이 목표를 정의하고 방향을 설계하는 것입니다. 위협생태계를 만드는 이유는 대응 진영의 체질 개선이며 이번 포스팅을 통해 공유해드리는 것은 워크플로우를 이용해 위협 해석 자동화하기입니다.
대부분의 조직들이 EDR과 같은 보안 솔루션을 도입한 후 겪고있는 문제는 탐지된 위협, 즉 신호를 해석하는 데 어려움을 겪고 있다는 겁니다. 아직 행위 이벤트에 대한 이해도가 산업 전반적으로 높은 상황도 아니며 공격 기술에 대한 도메인 지식이 함께 요구되기 때문이죠.
보안 담당자/실무자 분들과 기존 관제 조직들이 신경쓰기가 어려운 부분입니다. 탐지된 결과와 관련된 데이터만 있다면 기존 모니터링 방식의 운영 방식을 개선할 수 있습니다. GSC는 n8n을 사용하고 있으며. 그 이유는 다양한 서비스들과 연동이 안정적이기도 하고 셀프호스팅이 가능하다는 부분을 고려했습니다. EDR에서 발생하는 신호, 즉 위협(Threat)을 워크플로우를 통해 1차적인 해석과 분류를 하는 데 아래처럼 활용하고 있습니다.
[이미지2] 위협해석 AI Agent가 해석한 위협 이벤트
EDR에서는 위협 정보와 원본 행위 이벤트를 확인할 수 있도록 API를 제공하고 있습니다. API를 사용하기 위해서는 API 키 발급이 필요한데요. 일단 관리콘솔에 접속하셔서 인증을 하고나서 계정 정보에 중간 위치 정도에 API 키 생성 버튼이 있습니다. 클릭하셔서 생성되는 키 값을 별도로 저장하셔야 합니다.
n8n의 http request 노드에 Threat API를 호출하기 위한 URL(/api/events/threat)과 API 키 값을 넣고 필요에 따라 인자값들을 조절한 후 요청을 하게되면 관련 데이터들을 가져올 수 있게됩니다. 구체적인 API들과 관련된 세부 스펙들은 공식 문서를 참고하시는 걸 추천드립니다.
이제 LLM에게 줄 수 있는 데이터를 가져올 수 있게 되었는데요. 이 데이터를 AI Agent 노드에 전달해주면서 위협 해석을 위한 프롬프트를 만들면 되겠습니다. 정답이 있는 건 아니지만 도메인 지식이 있으면 유리한 것은 사실이며, 우리가 설계자로서 전환해야 하는 이유이기도 합니다.
LLM의 프롬프트를 주어서 데이터를 처리하는 것은 Agentic AI와 다른 부분이 있습니다. Agentic AI는 어느정도의 의사결정을 하는 것을 목표로 합니다. LLM을 워크플로우 안에서 데이터를 처리하기 위한 용도로 사용할지 Agent AI로 사용할지는 설계자의 결정입니다. 방향을 확실하게 예상할 수 없거나 워크플로우가 너무 길어지는 경우에는 의사결정을 할 수 있는 프롬프트와 Tooling을 할 필요가 생깁니다.
AI Agent의 기능의 범위를 너무 넓게 결정하면 프롬프트를 지속적으로 개선하고 많은 Tool을 주어도 의도와 벗어날 때가 있기도 하며, 의도와 다르게 동작할 수 있기때문에 토큰(비용)이 더 소비될 가능성이 생기게 됩니다. 그렇다고 너무 좁게 잡으면 워크플로우만으로 해결할 수 정도의 수준입니다.
해석된 위협 결과를 토대로 위협 헌팅이나 사고조사를 진행해야할 실제 악성인지 오탐/과탐이 발생해서 개선이 필요한지 분류할 필요가 있습니다. 그에 따라 실제 악성일 경우는 분석팀에게 요청하여 전문적인 위협헌팅이나 침해조사를 요청할 필요가 있습니다.
이와 반대로 오탐/과탐이 많이 발생하는 경우는 기존의 정책을 수정할 필요가 생깁니다. 이럴 경우는 EDR의 룰셋 정책에 해석된 결과를 반영하여 정말 불필요한 탐지 로직들을 예외처리하거나 고도화할 수 있도록 해야 합니다.
이처럼 위협해석된 결과를 토대로 기존에 사람이 해야하는 일들을 자동화할 수 있습니다. 디지털신호를 사람이 대응하는 것 자체가 적합하지 않은 전략이었습니다. 현대기술이 현재 산업의 운영상황의 한계를 추월했으며, 현재 조직의 상황을 파악한 후 워크플로우(AI Agent)로 대체 가능한 일들은 줄이시기를 바랍니다.
l3Iadk | Threat Hunter | Genians Security Center
지니언스 시큐리티 센터에서 공격자 관점의 위협 탐지와 EDR을 이용해 위협 사냥을 하고 있습니다.