사이버 보안

시그니처 추론에서 에이전트형 인공지능으로: 침입 탐지 시스템 설계는 어떻게 변화하는가

이 글은 SnortML이 알려진 공격의 새로운 변종을 탐지하도록 Snort 3의 기능을 확장하는 역할을 분석하고, 시간적 맥락과 다중 소스 조사를 추가하는 에이전트형 인공지능과 이를 비교한다. 또한 현재 접근 방식의 한계, 제안된 통합 아키텍처, 안전한 배포 요구 사항을 논의한다.

2026-07-06
6 분 읽기
11 조회수
فريق تحرير certi.news
시그니처 추론에서 에이전트형 인공지능으로: 침입 탐지 시스템 설계는 어떻게 변화하는가

침입 탐지 시스템은 알려진 시그니처에 거의 전적으로 의존하던 방식에서 벗어나, 기존 매칭과 머신 러닝 및 에이전트형 조사를 결합하는 하이브리드 아키텍처로 이동하고 있다. Stack Overflow 블로그에 게시된 분석에 따르면 SnortML은 Snort 3 내부의 저수준 감지 계층을 구성하는 반면, 에이전트형 인공지능은 시간과 소스 전반에서 이벤트를 연결하고 조사에서 다음 단계를 결정한다.

기존 시그니처의 문제는 부정확하다는 데 있는 것이 아니라, 탐지하도록 설계된 대상에 대해서만 정확하다는 데 있다. CVE-2024-12345와 같은 특정 취약점을 위한 사용자 지정 규칙은 오탐률을 매우 낮게 유지하면서 알려진 익스플로잇을 포착할 수 있지만, 동일한 취약 코드 경로를 통과하는 변형된 페이로드에는 반응하지 않을 수 있다. 새로운 익스플로잇이 실제 환경에 등장한 뒤 이를 분석하고, 규칙을 작성하고, 테스트하고, 배포하기까지 며칠 또는 몇 주가 걸릴 수 있으며, 취약점이 실제로 악용되고 있을 때 이는 위험한 공백이다.

Snort 3 내부에서 SnortML은 어떻게 작동하는가?

Cisco Talos는 2024년 3월 SnortML 엔진을 Snort 3 내부에서 기본적으로 작동하는 머신 러닝 탐지 엔진으로 소개했다. 이 엔진은 외부 클라우드 서비스에 의존하지 않으며, 규칙 평가에 사용되는 동일한 처리 경로 안에서 로컬 추론을 수행하고 1밀리초 이내에 결과를 출력한다.

구현은 시작 시 사전 학습된 TensorFlow 모델을 로드하는 snort_ml_engine 모듈과, 게시·구독 인터페이스를 통해 Snort 3의 기존 서비스 검사기에서 데이터를 수신하는 snort_ml 검사기로 구성된다. HTTP 검사기가 요청 분석을 완료하면 쿼리 문자열과 POST 본문을 이벤트 버스로 전송하고, SnortML은 이를 분류한 뒤 익스플로잇 시도를 포함할 가능성을 나타내는 확률값을 반환한다.

이 모델은 원시 바이트 값을 벡터 표현으로 변환하는 임베딩 계층 뒤에 LSTM 네트워크를 배치한다. 이를 통해 바이트 간의 관계와 맥락을 포착한 다음 LSTM이 그 순서와 시퀀스를 처리할 수 있다. 최종 완전 연결 계층은 결과를 하나의 확률값으로 축약한다. SnortML에 포함된 LibML은 행렬 연산을 가속하기 위해 XNNPACK 라이브러리를 사용한다. 자료에 따르면 AMD 4.7GHz 프로세서에서 한 번의 분류에는 약 350마이크로초가 걸린다.

Secure Firewall 10.0.0부터 SnortML은 256, 512 또는 1024바이트 길이에 적합한 모델을 자동으로 선택한다. 1024바이트를 초과하는 요청은 분류 전에 해당 길이에서 잘린다. 첫 번째 버전은 SQL 인젝션 탐지로 시작했으며, 2025년 말까지 XSS와 명령어 인젝션까지 범위가 확대되었다. 모델 업데이트는 규칙 콘텐츠 배포에 사용되는 동일한 Lightweight Security Package 시스템을 통해 제공된다.

하이브리드 접근 방식의 강점과 한계

SnortML은 시그니처 매칭을 대체하는 것이 아니라 그와 병렬로 작동한다. 모델은 알려진 범주에 속하는 공격의 새로운 변종을 포착할 수 있으며, 기존 시그니처는 확인된 패턴에 대해 낮은 잡음의 기준선을 제공한다. 두 경로가 동일한 페이로드에 대해 경보를 발생시키면 이는 머신 러닝만으로 생성된 경보보다 강한 신호로 볼 수 있지만, 각 메커니즘은 서로 다른 오류 특성을 계속 지닌다.

그러나 SnortML은 URI 쿼리 문자열이나 POST 본문과 같은 단일 HTTP 매개변수를 분석할 뿐, 요청 전후에 무슨 일이 있었는지 또는 해당 소스 주소가 이전 몇 분 동안 무엇을 했는지는 알지 못한다. 따라서 정찰, 열거, 맞춤형 익스플로잇이 이어지는 과정에서 어떤 단일 단계도 탐지 임계값을 넘지 않을 수 있다. 또한 현재 모델은 DNS 터널, TLS 계층 공격, SMB 익스플로잇 또는 HTTP가 아닌 프로토콜의 비정상적 동작을 볼 수 없다. 제공되는 모델이 HTTP 검사기의 데이터 경로에 연결되어 있기 때문이다.

약 350마이크로초의 처리 시간은 XNNPACK 덕분에 제한적이고 예측 가능하지만 실제 비용을 추가한다. 따라서 모델 성능은 규칙 집합의 규모, 프로토콜의 복잡성, 보안 장비의 처리 예산과 분리해서 보아서는 안 된다.

에이전트형 인공지능은 무엇을 추가하는가?

분석은 눈앞의 데이터만 평가하는 머신 러닝 모델, 고정된 단계를 따르는 SOAR 실행서, 그리고 여러 단계의 조사 상태를 유지하면서 이전 결과에 따라 다음에 무엇을 조사할지 결정하는 에이전트를 구분한다. 제시된 구상에 따르면 에이전트는 SIEM에 관련 이벤트를 질의하고, 위협 인텔리전스 플랫폼을 통해 파일 지문을 확인하며, 신원 공급자로부터 사용자 활동을 검색한 뒤, 대응을 권고하거나 인간 분석가에게 넘기기 전에 맥락을 종합할 수 있다.

이 글은 IBM이 2025년 4월 ATOM(Autonomous Threat Operations Machine) 플랫폼을 출시했고, Trend Micro가 2025년 8월 Agentic SIEM을 출시했다고 언급한다. 이러한 시스템은 보안 정보가 제공되는 단순한 대화형 인터페이스가 아니라, 다중 에이전트 조정 및 조사 플랫폼으로 제시된다. 분석은 인력 부족의 압박과 함께 이러한 시스템의 확산을 연결한다. 전 세계적으로 약 400만 개의 사이버 보안 일자리가 비어 있는 격차가 있으며, 2025년 설문에서는 보안 운영 센터 분석가의 82%가 경보량 때문에 실제 위협을 놓칠 것을 우려한다고 밝혔다.

이 아키텍처에서 Snort 3와 SnortML은 네트워크에 가까운 센서가 되어 실제로 관찰한 내용을 상위 추론 계층에 제공한다. 그러나 자동화 수준이 높아질수록 센서의 정확성이 더욱 중요해진다. 오탐은 분석가의 시간만 소모하는 것이 아니라 에이전트의 리소스를 소모하고, 잘못 구성된 환경에서는 격리 조치를 실행할 수도 있다. 또한 SnortML의 확률 결과를 활용하면 복합 신뢰도 점수를 만들 수 있다. 기존 시그니처와 0.97의 ML 점수를 함께 가진 경보는 ML만으로 0.61의 점수를 낸 경보와 다르게 처리해야 한다.

통합 아키텍처와 피드백 루프 문제

이 글은 생산성 요구 사항에 따라 AFPacket RSS 또는 DPDK를 사용하는 DAQ 기반 패킷 캡처 계층에서 시작해, MPSE Hyperscan 엔진과 SnortML을 병렬로 실행하는 탐지 계층으로 이어지는 아키텍처를 제안한다. 두 계층은 경보, 확률 점수, 플로 데이터가 포함된 JSON 형식의 이벤트를 통합 측정 버스로 전송한다.

그다음 작업은 전문 에이전트들에게 분배된다. 여기에는 분류, 중복 제거 및 위험도 평가를 담당하는 에이전트, 강화 및 위협 인텔리전스 에이전트, SIEM 로그와 신원 공급자 및 엔드포인트 데이터를 연결하는 조사 에이전트, 활동을 과거 패턴 및 알려진 캠페인과 비교하는 맥락 에이전트가 포함된다. 이 구상은 확인된 조사 결과를 대응 단계에서 흐름을 중단하지 않고 모델 및 규칙 엔진으로 되돌려 보내야 한다고 강조한다.

공격으로 확인되었지만 낮은 점수를 받았거나 시그니처와 일치하지 않은 페이로드는 학습 데이터 또는 새로운 규칙 작성의 입력으로 전환할 수 있다. 그러나 이 경로에는 인간 검증과 학습 데이터 오염을 탐지하는 메커니즘이 필요하다. 공격자가 자동화된 조사 결과를 조작해 오염된 샘플을 재학습 과정에 주입하려 할 수 있기 때문이다.

배포상의 제약과 실무 권고

분석은 SnortML의 현재 범위가 HTTP 매개변수로 제한되어 있다는 점, 에이전트 조정 프로토콜이 아직 성숙하지 않았다는 점, 모델 경보의 설명 가능성이 낮다는 점 등 다른 공백도 지적한다. 현재 출력은 확률 점수와 경보를 유발한 페이로드를 보여주지만, 입력의 어떤 바이트나 영역이 결과에 영향을 미쳤는지는 설명하지 않는다. 또한 자료에 따르면 난독화, 인코딩, 공백 조작, SQL 주석 삽입에 대한 모델의 견고성은 공개된 평가에서 공개적으로 설명되지 않았다.

실제로 이 글은 SnortML을 직접 경로에서 차단하는 방식이 아니라, 모니터링 포트에서 경보 전용 모드로 시작할 것을 권고한다. 일반적인 업무 주기를 포괄하는 최소 2주 동안 알려진 애플리케이션 트래픽에서 오탐을 측정한 다음, 선택적 인라인 배포를 활성화하기 전에 임계값을 조정해야 한다. 또한 ML 점수는 기존 시그니처를 대체하거나 단독 차단 트리거로 사용하는 것이 아니라, 복합 신뢰도 계산의 한 요소로 다뤄야 한다.

IP 주소 차단, 장치 격리 또는 자격 증명 재설정과 같은 영향이 큰 격리 조치는 인간 검토 절차 안에 두어야 한다. 분석의 핵심 결론은 자동화가 분류, 정보 보강, 상관관계 분석 및 컨텍스트 집계를 대규모로 맡을 수 있는 반면, 최종 대응 결정은 에이전트가 수집한 컨텍스트를 바탕으로 사람이 검토할 때 더 안전하다는 것이다.

뉴스 출처
Stack Overflow Blog
원문 보기 ↗
ف
작성자

فريق تحرير certi.news

같은 카테고리

추천 기사

모든 뉴스 보기