사이버 위협 인텔리전스를 계산 가능한 탐지 패턴으로 전환하는 구조화된 워크플로우

요약

여기서는 사이버 위협 인텔리전스 보고서의 파일 경로, 레지스트리 키, 명령줄 표시자를 보안 정보 및 이벤트 관리(SIEM) 탐지 규칙을 위한 검증된 정규 표현식으로 변환하는 프로토콜을 제시합니다. 이는 대형 언어 모델(LLM)과 그래프 지원 컴포넌트 라벨링을 이용한 앙상블 추출입니다.

초록

보안 운영 센터(SOC)는 정기적으로 사이버 위협 인텔리전스(CTI) 보고서를 운영 탐지 콘텐츠로 전환합니다. 이 워크플로우에서 지속적인 병목 현상은 추출된 침해 지표(IOC), 특히 파일 경로, 레지스트리 키, 명령줄 문자열을 보안 정보 및 이벤트 관리(SIEM) 상관관계 규칙에 삽입하기 적합한 배포 가능한 정규 표현식(regexe)으로 변환하는 것입니다. 이전 연구들이 자동화된 인디케이터 오브 컴필레이션(IOC) 추출을 개선했지만, 추출된 문자열을 검증된 정규 표현 패턴으로 변환하는 것은 여전히 대부분 수작업이며 전문 지식이 필요하고 오류가 발생하기 쉽습니다. 이 프로토콜의 목표는 IOC에서 정규 표현식으로의 변환을 위한 표준화되고 재현 가능한 절차를 제공하는 것입니다. 워크플로우는 다섯 단계로 구성됩니다: (1) 이기종적인 CTI 보고서를 통합된 Markdown 표현으로 파싱; (2) 합의 투표를 통한 다중 대형 언어 모델(LLM)을 이용한 IOC 추출; (3) 추출된 IOC의 규칙 기반 정규화, 분류 및 중복 제거; (4) IOC 구성 요소의 그래프 지원 라벨링(keep-group) 또는 discard(non-capture-group)로 분류; 그리고 (5) 원래 IOC 문자열에 대한 진단 검증을 포함한 반복적 정규 표현 생성. 유용성 평가를 위해 워크플로우는 3,156개의 CTI 보고서에 적용되었고, 결과 정규 식은 10개의 MITRE 대적 전술, 기법, 공통 지식(ATT&CK) 평가 시나리오에서 독립적으로 수집된 2,400개 이상의 진실 문자열과 비교하여 평균 명중률 99.1%, IOC 간 평균 불일치율 0.8%를 기록했습니다. 따라서 프로토콜은 IOC에서 정규 표현식으로의 변환을 재현 가능한 구현체로 문서화하며, 현재 범위, 운영 가정, 알려진 실패 사례를 명확히 명확히 설명합니다.

서론

사이버 범죄는 공공 및 민간 부문 조직에 상당한 운영 및 재정적 부담을 계속 가하고 있습니다. 2023년 미국 내 사이버 범죄로 인한 손실은 125억 달러를 초과^{했으며, 이는} 악성 활동의 규모와 지속성을 보여줍니다. 이러한 환경 속에서 보안 운영 센터(SOC)는 위협을 실시간으로 탐지, 분석, 대응하는 주요 작전 단위 역할을 합니다.
많은 SOC 워크플로우에서 감지 논리는 보안 정보 및 이벤트 관리(SIEM) 플랫폼 내의 규칙 기반 메커니즘을 통해 구현되며, 이는 해석 가능하고 결정적이며 기존 SOC 워크플로우와 호환되기 때문에 널리 사용됩니다. 다양한 규칙 유형 중에서, 상관관계 기반 SIEM 규칙은 여러 이벤트, 호스트, 시간 창에 걸친 공격 행동을 식별하는 데 특히 중요합니다. 이 규칙들 내에서 정규 표현식(regexe)은 재사용 가능한 탐색 원시 함수로 기능하며, 분석가들은 이를 자기 완성형 탐지기로 배포하는 대신 필드 제약 조건, 플랫폼별 필터, 이벤트 상관관계 논리를 추가하는 더 넓은 탐지 규칙 안에 내장시킵니다.

실제로 SOC 분석가는 보안 공급업체, 독립 연구자, MITRE Adversarial Tactics, Techniques, and Common Knowledge⁽ATT&CK)와 같은 공개 지식 기반에서 발행된 사이버 위협 인텔리전스(CTI) 보고서에서 도출된 침해 지표(IOC)로 규칙 개발을 시작하는 경우가 많습니다. 이 IOC 문자열에는 파일 경로, 명령줄 조각, 레지스트리 키 또는 공격 중 관찰된 기타 구조화된 아티팩트가 포함될 수^{있습니다.} 이러한 문자열을 SIEM 상관관계 규칙에 적합한 정규 표현 패턴으로 변환하는 작업은 규칙 작성 워크플로우에서 반복되는 작업입니다.

이 번역 단계는 실용적인 운영 병목 현상입니다. 의미 있는 변이를 포착할 만큼 일반적이면서도 의도치 않은 일치를 피할 만큼 정밀한 정규식 패턴을 작성하려면 전문 지식이 필요합니다; 작은 구문 오류나 어떤 구성 요소를 보존하거나 일반화할지 잘못된 결정으로 인해 유용한 탐지 규칙이 효과가 없어질 수 있습니다. 이 작업은 수작업이고 반복적이며 세부적인 작업이기 때문에 신흥 위협에 대한 탐지 배치가 지연될 수 있고, 더 경험 많은 분석가의 검토가 필요하며, 운영 SOC ^4,5 환경에서 분석가의 업무량을 증가시킬 수 있습니다.

IOC에서 정규 표현식으로의 번역에서 핵심 과제는 IOC의 어떤 부분이 안정적이고 공격자와 관련된 동작을 인코딩하여 보존해야 하는지, 그리고 어떤 부분이 환경이나 호스트에 따른 변동성을 반영하여 일반화되어야 하는지 결정하는 것입니다. 예를 들어, HKEY_CLASSES_ROOT\CLSID와 같은 표준 레지스트리 루트, System32와 같은 시스템 디렉터리, rundll32.exe와 같은 알려진 실행 파일은 일반적으로 명시적으로 유지해야 하며, 사용자 프로필 경로, 호스트별 보안 식별자(SID), 전역 고유 식별자(GUID)는 일반적으로 추상화되어야 합니다. 이질적인 IOC 유형 간에 일관되게 이 작업을 수행하는 것이 번역 작업을 결코 간단하지 않게 만듭니다. 이 프로토콜 전반에 걸쳐 전자는 보존 또는 포획 그룹 구성 요소로, 후자는 추상적 또는 비포획 그룹 구성 요소로 부릅니다.

이전 연구에서는 자연어 처리와 엔터티 추출 기법을 이용해 비정형 텍스트에서 위협 인텔리전스를 자동 추출하는 연구가 있었다 ^6,7. 최근에는 대형 언어 모델(LLM^)을 이용해 CTI 보고서에서 직접 탐지 규칙을 생성하는 연구가 여러 연구로 진행되었습니다. 이러한 접근법은 규칙 작성 워크플로우의 일부가 언어 모델의 도움을 받을 수 있음을 보여주지만, 캡처 그룹 의미를 보존하고 하위 SIEM 배포에 적합한 정규 표현식 패턴을 생성하는 구체적인 운영 문제에 일반적으로 집중하지 않습니다. 상호 보완적인 작업들은 TINKER⁹와 같은 지식 그래프 기반 표현과 ThreatRaptor 10과 같은 CTI 기반 로그 헌팅 쿼리 생성 등 다양한 방식으로 CTI 콘텐츠를 구조화하여 하위 사용을 위해 구조화한 작업을 제공했습니다. ThreatRaptor¹⁰은 비구조화된 CTI를 정규 표현 패턴 대신 정규 표현 패턴으로 변환하는 방식입니다.

동시에 이전 연구들은 예제 기반 방법, 신경 번역, 생성 및 복구 방식을 이용한 자동 정규 표현 합성을 탐구해 왔습니다 11,12,13,14,15,16. 하지만 이러한 방법들은 일반적으로 IOC 기반 탐지 맥락보다는 대표적인 예시나 자연어 설명을 대량으로 사용하는 환경에 맞게 설계되었습니다. SOC 워크플로우에서 IOC 문자열은 종종 희소하고 구조적으로 이기종적이며 운영 의미론과 밀접하게 연관되어 있습니다. 이러한 불일치는 기존 정규 표현식 생성 방법이 전반적으로 부족하다는 주장보다는 IOC에서 정규 표현식 변환에 맞춘 워크플로우를 촉진합니다.

여기서 제시된 프로토콜은 SOC 감지 워크플로우의 IOC에서 정규형체로의 변환 단계에 초점을 맞추고 있습니다. IOC 추출은 수동 분석, 자동화 도구 또는 이 두 가지의 조합에서 비롯된 상류 입력으로 취급됩니다; 프로토콜은 완전한 SIEM 규칙을 생성하려고 시도하지 않습니다. 대신, IOC 문자열을 문법적으로 유효하고 의미적으로 해석 가능하며 운영 배포에 적합한 정규 표현식 패턴으로 변환하는 체계적인 절차를 제공합니다. 현재 IOC 범위는 의도적입니다: 파일 경로, 레지스트리 키, 명령줄 표시기는 안정적이고 가변적인 구조 구성 요소를 모두 포함하며, 이는 정규 표현식 일반화의 이점을 얻는 반면, IP 주소, 도메인, 해시와 같은 원자 표시기는 정확히 일치 조건이나 평판 스타일 조회를 통해 더 자연스럽게 작동화되어 주 범위 밖에 위치합니다. 이러한 범위 내에서 프로토콜은 유사한 입력 형식과 도구 전제 조건을 공유하는 SOC 환경 간에 이식 가능하도록 설계되었습니다.

프로토콜

다음 5단계 워크플로우를 사용하여 CTI 보고서를 검증된 정규 표현식 패턴과 추적 가능한 중간 출력으로 변환합니다(개요는 그림 1 참조).

1. 시스템 설정

1. 필수 조건을 설치하세요.
   1. Python 3.8 이상, requirements.txt에 나열된 모든 Python 의존성, 그리고 Neo4j 그래프 데이터베이스를 설치하세요.
      1. 선택한 대형 언어 모델에 대해 하나 이상의 응용 프로그래밍 인터페이스(API) 접근 권한을 확인하고, Neo4j 서비스가 실행 중이며 로컬 머신에서 접근 가능한지 확인하세요.
   2. 재료 표가 완성되었는지 확인하세요.
      1. Python 인터프리터 버전, 파이프라인 의존성, Neo4j 버전, 그리고 Portable Document Format(PDF) 텍스트 추출 백엔드 등 런타임 의존성이 나열되어 있는지 확인하세요.
      2. LLM 구성 옵션, 예를 들어 LLM 제공자, 모델명과 버전, 온도, 추론-노력 옵션, 집합 투표 설정 등이 나열되어 있는지 확인하세요.
      3. 입력 및 출력 포맷이 나열되어 있는지 확인하고, 지원되는 입력 파일 포맷과 지원하는 내보내기 포맷이 포함되는지도 확인하세요.
2. 웹 사용자 인터페이스(UI)를 실행하세요.
   1. 터미널을 열고 참조 구현 루트 디렉터리로 이동한 후, 문서화된 실행 명령어(참조 구현에서는 cd langchain_pipeline 이어서 streamlit run app_v2.py)로 애플리케이션을 실행하세요.
   2. 애플리케이션이 http://localhost:8501 에서 로드되고 사이드바 설정 패널이 보이는지 확인하세요.
3. LLM 제공자를 설정하세요.
   1. 사이드바의 LLM 구성 섹션에서 LLM 제공자를 선택하고 모델명을 입력한 후 유효한 애플리케이션 프로그래밍 인터페이스(API) 키를 제공합니다.
   2. 제공자, 모델명, 모델 버전, 온도, 추론-노력 옵션, 재료 테이블의 접근 날짜를 기록하세요.
      참고. 참조 구현에서는 단일 LLM IOC 추출이 재료 표에 나열된 기본 상업용 LLM을 기본값으로 사용하며, 온도 = 0.0입니다; 정규 표현식 생성은 기본적으로 온도 = 0.3입니다.
4. 앙상블 투표를 활성화하세요(선택 사항이지만 재현 가능한 결과를 위해 권장).
   1. 사이드바의 앙상블 투표 옵션을 활성화하여 최소 득표 기준(최소 투표 ≥ 2 권장)을 충족하는 IOC만 유지하도록 하세요.
   2. 제공자, 모델 이름, API 키, 모델별 실행 반복 수를 지정하여 추가 LLM 인스턴스를 추가하세요.
      1. 각 제공자의 반복 횟수와 선택된 최소 투표 임계값을 기록하세요.
         참고. 앙상블 투표는 선택 사항입니다. 비활성화되면 파이프라인은 단일 LLM 추출을 수행하며 합의 필터는 건너뛸 수 있습니다. 기본 앙상블 설정은 구성된 모델당 반복 = 1개, min_votes = 2개입니다.
5. Neo4j에 연결하세요.
   1. 사이드바의 Neo4j Connection 섹션에서 연결 URI(예: bolt://localhost:7687), 사용자 이름, 비밀번호를 입력하세요.
   2. 인터페이스가 성공적인 연결을 보고하는지 확인하세요. 활성 연결 없이 진행하지 마세요.
6. 모든 자격 증명을 확보하세요.
   1. LLM API 키와 Neo4j 비밀번호를 민감한 자격 증명으로 간주하세요. 소스 파일, 내보낸 보고서, 스크린샷 대신 환경 변수나 비밀 관리자에 저장하고, 누수가 의심되면 즉시 키를 교체하세요.
      참고. 이 소프트웨어 프로토콜은 화학 훈제 후드, 생물안전 캐비닛 또는 기타 물리적 격리 장비를 요구하지 않습니다; 기관의 데이터 보안 정책에 따라 기밀 CTI 보고서와 자격 증명을 처리합니다.

2. 1단계: 문서 구문 분석

1. 절차.
   1. 메인 인터페이스의 처리 탭으로 이동하세요.
   2. 지원되는 형식(.pdf, .docx, .md, .txt, .html)으로 CTI 보고서를 업로드하세요.
   3. "다음 단계 실행"을 클릭하면 1단계 실행, "모든 단계를 실행"하면 전체 파이프라인을 순차적으로 실행합니다.
2. 1단계 체크포인트를 확인해.
   1. 입력 문서의 Markdown 미리보기가 표시되어 있는지 확인하세요.
   2. 파일 경로, 레지스트리 키, 명령줄 조각, 섹션 경계가 미리보기에서 온전한지 확인하세요.
   3. 기술적 문자열이 잘리거나 서식이 빠진 경우, 소스 파일을 수정하거나 외부 변환기로 문서를 사전 처리한 후 다시 업로드하세요.

3. 2단계: IOC 추출

1. 절차.
   1. LLM 구성(그리고 활성화된 경우 앙상블 투표)을 확인하세요.
   2. "다음 단계 실행"을 클릭하여 2단계를 실행하세요.
2. 2단계 체크포인트를 확인해.
   1. 인터페이스가 세 가지 최상위 키(파일 경로, 명령줄, 레지스트리 키)를 포함한 자바스크립트 객체 표기법(JSON) 형식으로 IOC 컬렉션을 표시하는지 확인하세요.
   2. 앙상블 투표가 활성화되었을 때, 각 보유 IOC에 대해 투표 수와 기여 모델 메타데이터가 기록되는지 확인하세요.
      참고. 2단계 시스템과 인간 프롬프트, 그리고 5단계 생성 및 최적화 프롬프트는 보충 파일 1 (Supplemental_File_1_Prompts.txt)으로 공개됩니다.

4. 3단계: IOC 분석 및 분류

1. 절차.
   1. "다음 단계 실행"을 클릭하여 3단계를 실행하세요.
2. 3단계 체크포인트를 확인해.
   1. 각 보유된 IOC가 표준화된 카테고리, 소스 태그, 그리고 이용 가능한 원본 추출 키와 함께 나열되어 있는지 확인하세요.

5. 4단계: Neo4j 보조 IOC 정상화

1. 절차.
   1. Neo4j 연결이 활성화되어 있는지 확인해 주세요.
   2. "다음 단계 실행"을 클릭하여 4단계를 실행하세요.
   3. 각 IOC 정규화 출력을 검사하여 경로 및 명령줄 구성 요소에 대해 keep/discard 라벨이 생성되는지, 그리고 레지스트리 키가 연속된 정규 서브스트링을 생성하는지 확인하세요.
2. 4단계 검문소를 확인해.
   1. 각 IOC 유형(파일 경로, 레지스트리 키, 명령줄 표시기)마다 정규화된 IOC 테이블이 생성되는지 확인하세요.
   2. 각 항목에 원본 값, 정규화된 값, 그리고 유지(keep) 또는 버려진 요소/상태 쌍의 구성 요소 목록이 포함되어 있는지 확인하세요.
      참고. 상세한 Neo4j 스키마, 사이퍼 쿼리, 결정 규칙, 레지스트리 키 정규화 절차는 보충 파일 2에 나열되어 있습니다; 실제 예제는 대표 결과에 제공되어 있습니다.

6. 5단계: 정규 표현식 생성 및 점수 매기기

1. 절차.
   1. "다음 단계 실행"을 클릭하여 5단계를 실행하세요. 각 정규화된 IOC와 금지 토큰 리스트가 정규 표현식 생성 및 결정론적 검증을 위해 제출되었는지 확인하세요.
   2. 후보가 검증에 실패하면, 최적화 루프가 정규식을 정제하여 준수 후보가 생성되거나 반복 제한에 도달할 때까지 허용합니다.
   3. 최종 정규식이 준수에서 최고 점수 부분 일치로 폴백된 IOC의 진단 출력, 최적화 이력, 반복 횟수를 점검합니다(used_fallback = 참으로 기록됨).
2. 5단계 체크포인트를 확인해.
   1. 각 유지된 IOC마다 최종 정규 표현식이 생성되는지 확인하세요.
   2. 후보 점수, 최적화 이력, 이슈 목록, 반복 횟수가 기록되었는지 확인하세요.
   3. 추정 토큰 사용량과 지연 시간을 포함한 각 IOC 텔레메트리가 기록되었는지 확인하세요.
      참고. 상세한 정규 표현식 검증 규칙, 점수 산정 공식, 반복 제어 매개변수는 보조 파일 2에 나열되어 있습니다.

7. 분석 및 검증

1. 분석 탭을 열어 IOC 분포, 앙상블 투표 결과(활성화 시), 정규 표현식 품질 요약, 최적화 통계를 검토하세요. 이 요약을 활용해 추출 불균형이나 반복적인 최적화 실패와 같은 이상 현상을 감지하세요.

8. 수출 결과

1. 내보내기 탭에서 내보내기 형식(일반 텍스트, JSON, YAML)을 선택하고 정규 표현식 집합을 다운로드하세요. 내보내는 정규식에 관련 점수와 분류 메타데이터가 포함되어 있는지 확인하세요.
2. 파싱된 문서, 추출된 IOC, 정규화된 표현, 후보 정규 표현식, 최종 출력을 포함한 전체 JSON 보고서를 생성하고 다운로드할 수 있습니다. 이 보고서를 재현성 기록으로 보존하세요.

9. 문제 해결

1. 1단계에서 잘렸거나 빈 PDF 콘텐츠가 반환되면, 재업로드 전에 외부 변환기나 광학 문자 인식 도구로 문서를 사전 처리하고, 기술적 아티팩트가 마크다운 미리보기에서 여전히 보이는지 확인하세요.
2. 2단계에서 합의 IOC가 너무 적게 반환된다면, 임계값을 변경하기 전에 제공자, 모델, API 키, 반복 개수, 최소 투표 설정을 확인하세요. 환각과 지나치게 엄격한 투표를 구분하기 위해 제외된 후보자들을 검사했습니다.
3. 4단계에서 모든 구성 요소를 폐기로 표시하면, Neo4j 연결성을 확인하고 분석하는 IOC 유형에 맞는 경로, 레지스트리, 명령줄 인터페이스(CLI) 어휘가 그래프에 포함되어 있는지 확인하세요.
4. 5단계에서 컴파일은 하지만 일치에 실패하거나 과도하게 일반화되는 정규식이 생성된다면, 후보를 재생성하기 전에 최적화 이력, 진단 실패 위치, 과도한 일반화 검사를 점검하세요.

10. 최종 프로토콜 출력 확인.

1. 파싱된 Markdown 파일, IOC 집합(앙상블 투표가 활성화되면 합의로 검증, 비활성화되면 단일 모델), 분류된 IOC 테이블, 그리고 그래프로 정규화된 IOC 표현이 모두 포함되어 있는지 확인하세요.
2. SIEM 호환 정규 표현식 집합, 분석 요약, 전체 JSON 보고서가 모두 포함되어 있는지 확인하고, JSON 보고서를 재현성 기록으로 보관하세요.

결과

이 절에서는 IOC-정규 표현 프로토콜이 만들어낸 대표적인 결과를 제시하고, 그 운영 적용 가능성을 평가하는 데 사용된 참고 평가를 요약합니다. 참고 평가는 MITRE ATT&CK 기법과 관련된 3,156건의 CTI 보고서를 처리하고, 230,000개 이상의 문장을 분석했으며, 63,000개 이상의 IOC 후보를 추출하고, 10개의 MITRE ATT&CK 평가 시나리오에서 독립적으로 수집된 2,400개 이상의 진실 문자열에 대해 생성된 정규 식을 평가했습니다. 이 현장 진실 문자열은 MITRE AT&CK 평가 과정에서 사이버보안 벤더가 독립적으로 보고한 전문가가 선별한 공격 산출물로, 인간 분석가와 벤더가 실제로 문서화하는 구조적 패턴을 반영합니다. 아래 결과는 작업 흐름 동작, 구조적 정확성, 그리고 운영 로그 분석 및 탐지 워크플로우와 관련된 평가 결과에 초점을 맞추고 있습니다.

엔드 투 엔드 파이프라인에 대한 개요는 그림 1에 제공되며, 캡처 그룹 찾기 및 정규 표현 생성 단계를 요약하여 나머지 대표 결과를 구성합니다.

1단계: 문서 파싱 출력

그림 2는 입력된 CTI 보고서를 통합된 Markdown 표현으로 구싱하는 1단계 출력 을 보여줍니다. 성공적으로 실행되면 인터페이스는 섹션 경계와 관련성 표시자를 포함한 문서의 구조화된 미리보기를 표시합니다.

올바른 실행은 일관된 단락 분할과 파일 경로, 레지스트리 키, 명령줄 조각과 같은 기술적 산출물의 보존으로 표시됩니다. 이 단계에서 과도한 절단이나 서식 손실은 후속 분석에 영향을 줄 수 있으므로 진행 전에 반드시 해결해야 합니다.

2단계: 합의 기반 IOC 추출

그림 3 은 다중 LLM 앙상블 투표를 통해 후보 IOC를 추출하는 2단계 출력을 보여줍니다. 결과적으로 생성된 인터페이스는 투표 집계와 기여 모델이 주석을 달린 JSON 형식의 IOC 컬렉션을 제공합니다.

구성 최소 합의 임계값을 충족하는 IOC만 유지됩니다. 이 단계에서 제외되는 IOC는 일반적으로 모델별 환각이나 모호한 텍스트 조각을 반영합니다. 이들의 배제는 예상되고 바람직한 결과로, 집단 투표가 올바르게 작동하고 있음을 나타냅니다.

3단계: IOC 분석 및 분류

표 2는 각 프로토콜 단계별 예상 출력, 자동 검증 단계, 분석가 대상 품질 관리 검사를 요약합니다.

그림 4 는 2단계 앙상블 투표에서 합의 기준을 충족하지 못한 IOC 후보자들과 분석가 점검을 위해 인터페이스가 표면에 나타난 모습을 보여줍니다. 이러한 후보들은 일반적으로 모델별 환각이나 모호한 텍스트 조각을 반영합니다. 따라서 그림 4 와 그림 5 는 동일한 3단계 프로세스의 대안적 관점보다는 2단계에서 버려진 세트와 3단계에서 유지된 세트라는 서로 다른 단계 출력에 해당합니다.

그림 5 는 3단계에서 JSON 파싱, 규칙 기반 분류, IOC 중복 제거 후 생성된 유지된 IOC 테이블을 보여줍니다. 각 유지된 IOC마다 스테이지는 표준화된 카테고리, 소스 태그, 그리고 가능한 경우 원본 추출 키를 기록한 후 IOC를 다운스트림 정규화로 넘깁니다.

4단계: IOC 유형 간 그래프 보조 IOC 정규화

그림 6, 그림 7, 그림 8은 현재 연구에서 다루는 세 가지 IOC 범주인 파일 경로, 레지스트리 키, 명령줄 표시기의 대표적 정규화 결과를 보여줍니다. 각 범주별로 그래프는 CTI 보고서에서 추출한 원본 IOC와 그래프 보조 분석을 통해 생성된 정규화된 표현을 비교한 것입니다.

모든 IOC 유형에 걸쳐 프로토콜은 각 IOC를 의미 구성 요소로 분해하고, 그래프 데이터베이스에 인코딩된 구조화된 지식을 사용하여 계층적 관계를 해결합니다. 현재 구현에서는 Neo4j가 정규화된 경로, 레지스트리, CLI 노드를 저장하고, 인접 관계를 사용해 구성 요소가 인식된 체인에 속하는지 테스트합니다. 이 역할은 탐지 공학²에서 구조화된 ATT&CK 지식의 사용과 유사합니다.

중요한 점은, 이 정규화 단계가 IOC 구성 요소를 분석 기록에서 조용히 제거하는 대신 유지(keep) 또는 폐기(discard)로 라벨을 붙여 명시적 의미 역할을 기록한다는 것입니다. 정규화된 문자열은 주로 keep 컴포넌트에서 재구성되며, discard 컴포넌트는 하위 정규 표현식 생성 및 검증을 위한 메타데이터로 남아 있습니다.

이 단계의 올바른 실행은 의미 있는 구조적 맥락을 유지하고 서로 다른 IOC 유형에서 일관된 캡처 그룹 표지(capture-groups labeling)를 보이는 정규화된 IOC로 표시됩니다. 원본 표현과 정규화된 표현 간의 시각적 비교는 캡처 그룹 해상도가 일관되게 적용되었고 의도치 않은 정보 손실 없이 적용되었음을 검증하는 실용적인 품질 관리 메커니즘을 제공합니다.

5단계: 보조 제약 기반 선택을 이용한 정규 표현식 생성

그림 9 는 프로토콜이 정규화된 IOC로부터 반복적 검증 워크플로우를 통해 구조적으로 준수하는 정규 표현식을 생성하는 5단계 출력물을 보여줍니다. 이 구현은 초기 생성 프롬프트, 후보가 IOC와 일치하지 않을 때 진단 재프롬프트, 버림 인식 검증, 그리고 제한 재시도 루프를 결합합니다.

정규화된 IOC와 그에 따른 유지/폐기 구성 요소 명세가 주어지면, 워크플로우는 먼저 초기 정규 표현식 후보를 생성합니다. 후보자는 IOC와 비교해 테스트되고, 매칭 실패 시 진단적으로 재프롬프트되며, 금지된 버려진 토큰이 있는지 확인하고, 무작위 음수 문자열을 사용해 과도한 일반화 여부를 평가합니다.

여러 후보가 기본 검증 검사를 만족하면, 프로토콜은 보조 제약 기반 선택 메커니즘을 적용하여 하위 사용을 위해 대표적인 정규 표현식을 유지합니다. 현재 구현에서는 후보를 'Score = n_cg - n_wc'로 채점하며, 여기서 'n_cg'은 대표된 유지 구성 요소의 수이고 'n_wc'는 정규 표현식에 존재하는 버려졌거나 매핑되지 않은 토큰의 수입니다.

선택 함수는 다음과 같이 정의됩니다:

점수 = n_cg − n_wc

이는 더 일반적인 형태인 점수 = α·n_cg − β·n_wc의 동일 가중치 특수화(α = β = 1)입니다. 여기서 n_cg는 표현된 유지 구성 요소의 개수를, n_wc는 정식식이 다시 도입한 버려진 구성 요소 또는 매핑되지 않은 추가 토큰의 수를 나타냅니다. 구현은 또한 각 IOC에 대한 반복 횟수, 이슈 리스트, 추정 토큰 소비, 캐시 사용량, 지연 텔레메트리도 기록합니다. 동일 가중치 설정은 참조 구현의 간단한 결정론적 기본값으로 사용되었으며; 이 구성요소는 누락된 Keep 컴포넌트와 재도입된 폐기 컴포넌트를 동일하게 바람직하지 않게 취급하기 때문에, 거짓 음성과 오탐이 서로 다른 운영 비용을 초래하는 배포 환경에서는 다른 가중치가 선호될 수 있습니다.

최종 정규식은 이러한 제약 조건을 가장 잘 만족하는 후보로 선택됩니다. 예를 들어, ( ... )?와 같이 필수 캡처 그룹 구성 요소를 선택적 구성 안에 배치하는 정규식은 의미적 일관성을 약화시켜 선택에서 제외됩니다. 이 선택 단계는 생성 과정의 보조 단계이며, 독립적인 품질 지표로 제공되기를 목적으로 하지 않습니다.

CTI 처리의 분석 개요

그림 10 은 모든 처리된 문서에 걸친 CTI 분석 결과를 개괄적으로 보여줍니다. 참고 평가에서 3,156개의 CTI 보고서에 대한 IOC 추출은 63,000개 이상의 IOC 후보를 생성했으며, 여기에는 12,195개의 파일 경로, 2,302개의 레지스트리 키, 10,286개의 명령줄 표시기가 포함되었으며, 나머지 후보는 비정규 표현식 대상 IOC 유형에 속했습니다.

이 카운트는 추출된 지표가 현재 프로토콜이 목표로 하는 세 가지 IOC 범주에 집중되어 있음을 고수준 검증할 수 있게 하면서도, 많은 추출된 아티팩트가 여전히 정규 표현식 생성 범위 밖에 있음을 보여줍니다. 워크플로우를 재현할 때는 처리된 CTI 보고서 수, 총 IOC 후보, 카테고리별 수치, 추출 시 사용된 제공자, 모델, 모델 버전, 온도, 반복 횟수, 합의 임계값을 보고하세요.

참조 평가에서는 생성된 정규 식이 10개의 MITRE ATT&CK 평가 시나리오에서 독립적으로 수집된 2,400개 이상의 진실 문자열과 비교하여 평균 명중률 99.1%, 평균 교차 대회 불일치율 0.8%를 달성했습니다. 이 원고에서는 불일치율을 의미 특이성 측정으로 사용한다: 한 IOC에서 생성된 정규식이 다른 IOC와 연관된 근거 진실 문자열과 일치할 때 불일치가 발생한다. 이 수치는 하위 규칙 논리와 배포 맥락에 따라 달라지는 종단 간 운영 경고 오탐률로 해석해서는 안 됩니다.

이 분포는 CTI 코퍼스의 구조적 구성을 반영하며, 사용자가 추출된 지표가 예상되는 IOC 유형과 일치하는지 검증할 수 있게 합니다. 예상 비율에서 큰 편차가 있으면 상류 파싱 또는 추출 문제를 나타낼 수 있으므로, 하류 정규화 및 정규 표현 생성으로 진행하기 전에 반드시 검토해야 합니다.

정규 표현식 최적화 동작 분석

그림 11 은 정규 표현식 생성 및 정제화 과정에서 수행되는 동작들을 요약합니다. 이 분포는 초기 정규 표현식 생성, LLM 기반 최적화 단계, 재시도 기반 재생의 세 가지 유형의 행동을 포함합니다.

LLM 기반 최적화는 관찰된 모든 행동의 51.7%를 차지합니다. 이러한 보급률은 초기 생성만으로는 캡처 그룹 제약 조건과 배제 요구사항을 충족하는 정식을 만들기에는 종종 부족함을 의미합니다. 대신, 반복적이고 반복적으로 후보 정규식을 정제하기 위해 반복적으로 적용됩니다.

이 분포는 비효율성을 반영하기보다는, 복잡한 IOC 입력에서 구조적으로 준수하는 정규 식을 생성할 때 최적화 워크플로우가 프로토콜의 필수적이고 필수적인 구성 요소임을 보여줍니다.

확장성 테스트 LLM으로 생성된 무작위 표본 6,000 IOC에 대한 별도의 확장성 특성화(재료 표 참조)에서는 IOC당 중앙 지연 시간이 2.95초, 평균 지연 시간이 23.18초로 보고되었습니다. 같은 특성화에서, 구문 유효 정규식(regex) 컴파일은 99.56%에 도달했고, 전체 생성 성공률은 99.4%, 평균 추정 토큰 사용은 IOC당 약 3,986개의 토큰이었고, 워크플로우는 IOC당 평균 약 7.89개의 LLM 호출을 필요로 했습니다. 매칭-디버그 루프에서 1차 통과 성공률은 56.46%, 비캡처 그룹 검증 루프에서는 72.92%였습니다. 이러한 측정은 배치 사용을 위한 계산 비용과 운영 처리량을 특성화하는 데 도움을 줍니다.

현재 참조 특성화에서 모델 재훈련에 샘플링 출력 하위 집합에 대한 전문가 검토는 사용되지 않았으며; 보고된 결과는 자동화된 파이프라인 실행과 위에서 설명한 하위 평가 데이터셋을 반영합니다.

운영 증거와 실패 처리. 그림 12는 프로토콜이 생성한 내보된 SIEM 정규 표현 파일의 구조와 대표 파일 경로, 레지스트리 키, 명령줄 패턴에 대한 규칙 수준 검증 증거를 보여줍니다. 그림 13은 해당 전체 JSON 보고서를 보여주며, 이 보고서는 모든 단계 출력(추출, 분석, 정규화된 IOC와 생성된 정규 표현 패턴 및 각 IOC 검증 플래그를 포함)을 노출하며, 하위 공구가 소비하는 주요 산출물입니다. 그림 14는 잡음이 많은 CTI 입력을 프로토콜이 처리하는 방식을 보여줍니다: 분석에서 디팽(deanged)되고 여백이 섞인 파일 경로가 플래그화되어 수정되고, 정규 %TEMP% 템플릿에 정규화된 후 컴파일되고 일치하는 정규 표현식으로 변환됩니다. 이 작업 예제는 원시 IOC 텍스트가 정형에서 벗어날 때 프로토콜이 어떻게 동작하는지 문서화하여 그림 12와 그림 13의 운영 증거를 보완합니다.

그림 1: IOC에서 정규 표현식 프로토콜의 전체 아키텍처. 그림은 종단 간 파이프라인을 요약한 것입니다. 업스트림 IOC 추출기가 생성한 후보 IOC 문자열은 분해되어 Windows 문서에서 채워진 Neo4j 그래프의 참조 노드와 비교되며(1단계), 이 그래프는 알려진 경로, 레지스트리, 명령줄 구성 요소를 검색합니다(2단계). 변수 또는 환경별 조각은 버려짐으로 라벨링되어 정규화된 재구성에서 제외되고, 컴포넌트 메타데이터에 보존되어 정규화된 IOC를 생성합니다(3단계). 이 정규화된 IOC들은 LLM 기반 정규 표현식 생성 단계(4단계)로 넘어가며, 후보 정규식이 생성되며, 이 표현식들은 점수를 매기고 캡처 그룹 제약 조건과 버려진 토큰 규칙에 대해 반복적으로 최적화된 후 최종 정규 표현식(6단계)을 선택합니다(6단계). 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 2: 1단계 문서 파싱 출력. 원본 CTI 보고서와 파싱된 문서 미리보기를 나란히 비교한 결과입니다. 왼쪽 패널에는 원본 CTI 보고서가 PDF 형식으로 표시되어 있고, 오른쪽 패널에는 파서가 생성한 통합 Markdown 표현이 표시됩니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 3: 다중 LLM 앙상블 투표를 이용한 합의 기반 IOC 추출. 인터페이스는 앙상블 기반 IOC 추출 과정과 그 중간 결과를 보여줍니다. 빨간 상자는 IOC 추출에 참여하는 설정된 LLM 인스턴스를 강조하며, 선택된 제공자와 각 모델별로 반복 추출 실행 횟수를 포함합니다. 파란색 상자는 사용자가 정의한 합의 임계값을 나타내며, 이는 IOC가 유지되기 위해 필요한 최소 발생 횟수를 명시합니다. 모든 모델과 반복에서 추출 결과를 집계한 후, 임계값보다 적게 나타난 후보 IOC는 폐기됩니다. 주황색 상자는 합의 기준을 충족하고 하위 분석 단계로 넘어가는 최종 보유 IOC 세트를 보여줍니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 4: 2단계에서 앙상블 투표로 폐기된 IOC. 집단 투표 중 최소 득표 기준을 충족하지 못한 IOC 후보자들의 나란히 모습을 분석가의 검토를 위해 공개된 모습입니다. 버려진 후보들은 일반적으로 모델별 환각이나 모호한 텍스트 조각을 반영하며, 3단계 분류 단계로 넘어가지 않습니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 5: 표준화된 분류가 적용된 유지 IOC 세트. 3단계 처리 후 유지된 IOC 후보 항목은 표준화된 카테고리, 소스 태그, 원본 추출 키가 있을 경우 함께 표시됩니다. 이 표는 정규화 단계에서 사용되는 구조화된 IOC 입력을 제공합니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 6: 그래프 보조 분석을 이용한 파일 경로 IOC 정규화. 원본 파일 경로 IOC와 그 정규화된 표현의 나란히 비교. 그래프 기반 탐색 쿼리는 정규화된 이름으로 알려진 경로 구성 요소와 각 구성 요소를 유지(keep) 또는 버려짐(discard)으로 라벨링합니다. 따라서 드라이브 식별자와 변수 파일명 조각은 컴포넌트 레코드에서 폐기되도록 표시할 수 있으며, 정규화된 형태는 주로 하위 패턴 구축에 필요한 구조적 세그먼트를 통해 재구성됩니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 7: 그래프 보조 분석을 이용한 레지스트리 키 IOC 정규화. 계층적 레지스트리 구조의 그래프 지원 해석을 통한 레지스트리 키 IOC의 정규화. 축약된 루트 키는 정식 레지스트리 하이브로 확장되며, 분석기는 호스트 자리 표시자, SID 유사 값, GUID와 유사한 토큰을 건너뛰면서 가장 긴 연속된 알려진 레지스트리 서브스트링을 추출합니다. 출력은 각 보존 구성 요소에 대한 유지/폐기용 라벨을 기록하고, 하위 처리를 위한 정준 레지스트리 경로를 생성합니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 8: 그래프 보조 분석을 이용한 명령줄 IOC 정규화. 원본 명령줄 IOC와 그 정규화된 표현의 비교. 이 프로토콜은 인용 문자열을 보존하면서 명령줄을 토큰화하고, 가능하면 Neo4j 조회를 통해 선두 명령 토큰을 정규화하며, 내장된 경로 유사 또는 레지스트리 유사 조각을 재귀적으로 분석합니다. 안정적인 명령 관련 구성 요소는 keep, 변수 인수들은 discard로 표시되며, 최종 정식 명령 구조는 유지된 요소들로부터 재구성됩니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 9: 정규 표현식 후보의 제약 기반 선택. 각 정규화된 IOC마다 반복 검증 워크플로우를 통해 여러 정규 후보가 생성됩니다. 제약 기반 점수 메커니즘을 적용하여 지정된 캡처 그룹 구성 요소를 보존하면서도 원치 않는 변수 서브스트링을 제한하는 최종 정규식을 선택합니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 10: CTI 보고서 내 추출된 IOC 분포. CTI 보고서에서 식별된 전체 지표 수와 파일 경로, 레지스트리 키, 명령줄 표시기 전반에 걸친 분포를 보여주는 IOC 추출 결과 요약. 이 뷰는 CTI 콘텐츠 커버리지와 추출 동작을 고수준으로 검증할 수 있게 합니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 11: 정규 표현식 생성 중 최적화 행동의 분포. 정규 표현식 생성 중 수행된 동작들의 분해, 초기 생성, LLM 기반 최적화, 재시도 기반 재생 등이 포함됩니다. LLM 기반 최적화는 전체 행동의 51.7%를 차지하며, 반복적 정제가 캡처 그룹 제약 조건을 만족하는 정규 표현식을 생성하는 프로토콜의 필수 구성 요소임을 보여줍니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 12: 대표적인 내보내진 정규 표현식 파일. 프로토콜에서 생성된 SIEM 정규식 내보내기(siem_rules.txt)의 샘플 내용. 각 항목에는 소스 IOC, 추론된 카테고리(파일 경로, 레지스트리 키, 명령줄), 그리고 검증된 정규 표현식 패턴이 포함됩니다. 첨부된 검증 표는 각 규칙 유형에 대한 올바름을 확인하기 위해 사용되는 예상 동작과 시스템 증거를 요약합니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 13: 대표적인 전체 JSON 보고서. 대표적인 CTI 보고서에서 다섯 단계 프로토콜 전반을 실행한 후 생성된 종단 간 파이프라인 출력. JSON 문서는 소스 파일, 파싱된 섹션 수, 카테고리별로 그룹화된 추출된 IOC, 소스 태그가 포함된 3단계 분류 레코드, 4단계 정규화 차이, 그리고 IOC별 검증 플래그가 있는 5단계 정규 표현 패턴을 기록합니다. 보고서는 또한 하위 도구가 부분적 실패를 감지할 수 있도록 하는 최상위 성공 및 오류 메타데이터를 공개합니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

그림 14: 실패하거나 잡음이 많은 입력: 식별 및 수정. 프로토콜이 노이즈가 있는 IPC를 식별하고 복구하는 사례입니다. 원시 입력 %T E M P%\malware[.]exe는 환경 변수 토큰에 삽입된 공간이 포함되어 있고 파일 확장자가 defanged되어 플래그가 붙습니다. 수정 단계는 삽입된 공백을 제거하고 문자 그대로의 점을 복원합니다; 4단계 정규화는 그 후 %TEMP%를 정식 Windows 임시 디렉터리 템플릿으로 확장합니다; 5단계는 수정된 정규화된 IOC를 컴파일하고 일치시키는 정규식을 생성합니다. 이 예시는 토론에서 논의한 노이지 입력 처리를 보여줍니다. 이 그림의 더 큰 버전을 보시려면 여기를 클릭해 주세요.

원소	유형	가치 / 스키마	예시	주석
노드 라벨	레이블	:P	윈도우, System32, cmd.exe	Windows 파일 경로 구성 요소를 저장합니다
노드 라벨	레이블	:등록부	소프트웨어, 마이크로소프트, 윈도우 NT	루트 하이브 아래에 레지스트리 키 구성 요소를 저장합니다
노드 라벨	레이블	:CLI	powershell.exe, -실행정책, 우회	명령 토큰과 매개변수를 저장합니다
노드 속성	스트링	이름	cmd.exe	원래 탄피; 정규화된 출력에서 디스플레이에 사용됨
노드 속성	스트링	name_lower	cmd.exe	소문자 형태; 모든 MATCH 쿼리의 조회 키로 사용됩니다
관계	지향된 가장자리	(a)-[:다음]->(b)	(Windows)-[:NEXT]->(System32)	두 끝 모두 같은 라벨을 공유합니다; 윈도우 시스템에서 네이티브 인접 인코딩
제약	고유성	n.name_lower 라벨별로 고유	-	:P ath, :Registry, :CLI 에 적용됨
데이터 출처	방송 범위	윈도우 8, 10, 11	-	그래프에 채워진 클라이언트 OS
데이터 출처	방송 범위	윈도우 서버 2012, 2016, 2019, 2022	-	그래프에 채워진 서버 OS

표 1: IOC 정규화에 사용되는 Neo4j 그래프 스키마(4단계). 세 개의 노드 라벨(경로, 레지스트리, CLI), 공유 속성 스키마(이름, name_lower), 네이티브 정렬 간선에 사용되는 방향 인접 관계, 고유성 제약 조건, 그리고 그래프를 채우는 Windows 클라이언트 및 서버 버전을 나열합니다.

무대	기대 출력	자동 검증	분석가 대상 품질 관리
1단계: 문서 구문 분석	통합 마크다운 텍스트, LLM 처리 전 4,000자 단위로 청크되었습니다.	—	파일 경로, 레지스트리 키, 명령줄 조각, 섹션 경계가 파싱을 통과하는지 확인하기 위해 Markdown 미리보기를 시각적으로 확인; 기술 문자열이 잘렸다면 백엔드를 전환하세요.
2단계: IOC 추출	세 가지 최상위 키(파일 경로, 명령줄, 레지스트리 키)를 가진 JSON; 집단 투표가 활성화되면 IOC 표별 집계와 기여 모델 메타데이터가 포함됩니다.	합의 임계값 필터(min_votes)는 설정된 임계값 이하의 투표 수를 가진 IOC를 제외합니다.	조정 전에 환각과 지나치게 엄격한 투표를 구분하기 min_votes위해 제외된 후보자를 검사합니다.
3단계: IOC 분석 및 분류	분류된 IOC 목록: 각 IOC는 표준화된 카테고리, 소스 태그, 원본 추출 키가 있을 경우 함께 제공됩니다.	정규식 기반 규칙과 IOC 패턴 휴리스틱을 통한 표준화된 범주 매핑; (IOC, 카테고리) 쌍 중복 제거.	모호하거나 노이즈가 있는 후보에 대한 분류된 출력의 스팟 체크(그림 4A).
4단계: Neo4j 보조 정상화	구성 요소 수준 유지/폐기 라벨이 포함된 IOC 기준 정규화된 형태.	Windows 참조 그래프에 대해 (i)-(iii) 사이퍼 쿼리; Neo4j가 사용할 수 없을 때 결정론적 전처리 예비 조치입니다.	모든 버려지는 경우를 검사하여 그래프 커버리지 공백을 식별하고; 필요 시 벤더나 환경별 참조를 통해 그래프 데이터를 확장할 수 있습니다.
5단계: 정규 표현식 생성 및 점수 매기기	후보 점수, 최적화 이력, 반복 횟수, 그리고 IOC별 텔레메트리가 포함된 IOC별 최종 정규 표현식.	매칭 테스트, 정적 품질 검사, 경계 인식 금지 토큰 검사, 5개의 결정론적 음의 표본에 대한 과도한 일반화 검사; 최고 점수 부분 경기(used_fallback 플래그)로 복귀.	대체 정규식에 대한 최적화 이력 검토; 재생 전 IOC 고장 위치 진단 검사.

표 2: 단계 출력 및 검증 요약. 각 프로토콜 단계(1–5)를 예상 산출물, 파이프라인에서 생성된 자동 검증 증거(정규 표현식 컴파일 상태, 히트율, 크로스 IOC 불일치율, 최적화 반복 횟수), 그리고 분석가 대상 품질 관리 검사(시각적 비교, 버려진 후보 검사, 카테고리 검토)에 매핑합니다.

보조 파일 1: LLM 프롬프트를 그대로 적용합니다. 2단계 IOC 추출과 5단계 정규 표현식 생성 및 최적화에 사용되는 버바팀 시스템과 인간 프롬프트입니다. 이 파일을 다운로드하려면 여기를 클릭해 주세요.

보조 파일 2: 4단계와 5단계 구현 세부사항. 4단계 그래프 보조 IOC 정규화와 5단계 정규 표현 검증, 점수 부여 및 반복 제어를 지원하는 알고리즘 및 구현 세부사항. 이 파일을 다운로드하려면 여기를 클릭해 주세요.

토론

비구조화된 CTI 보고서를 실행 가능한 탐지 로직으로 변환하는 작업은 운영 보안 워크플로우에서 여전히 시간이 많이 걸리고 오류가 잦은 작업입니다. 이전에는 IOC 추출 수준이나 고수준 규칙 생성 수준에서 자동화를 탐구한 바 있지만, 실무자들은 추출된 IOC 문자열을 구조적으로 올바르고 의미적으로 정밀하며 하위 SIEM 사용에 적합한 정규 식으로 변환하는 데 여전히 상당한 도전에 직면해 있습니다. 여기서 제시된 프로토콜은 각 단계별 워크플로우를 통해 명확한 중간 산출물을 생성하고 다음 단계로 결과를 전달하기 전에 명시적 검증을 적용하는 과정을 통해 그 공백을 해결합니다. 그림 14 는 이러한 사례 중 하나로, 디팽(deanged)되고 여백이 섞인 파일 경로를 식별, 수정, 정규화하여 컴파일용 정규식으로 변환하는 사례를 기록합니다; 프로토콜의 노이지 입력 처리와 현재 범위는 아래에 열거된 제한사항들과 함께 논의됩니다.

이 프로토콜의 핵심 기여 중 하나는 워크플로우를 검사 가능한 중간 출력이 있는 단계별로 명시적으로 분해한다는 점입니다. 구현은 이제 구체적으로 설명되었습니다: 문서 파싱은 LLM 처리를 위한 마크다운과 청크된 텍스트를 생성합니다; IOC 추출은 파일 경로, 레지스트리 키, 명령줄 표시기에 대한 구조화된 JSON을 방출합니다; 규칙 기반 IOC 분석은 추출된 값을 표준화하고 중복 제거; Neo4j 보조 정규화는 각 IOC 구성 요소를 유지(keep) 또는 폐기(discard)로 표시합니다; 그리고 정규 표현식 생성은 후보 선택 전에 매칭 디버깅, 버림 검증, 과도한 일반화 검사를 적용합니다.

프로토콜은 정규 표현식 생성을 단발적인 예측 문제로 않고 반복적인 구성 작업으로 다룹니다. 구현은 초기 생성 프롬프트, 자동 매치 진단, 제한 정제 루프, 컴포넌트 기반 점수 함수를 사용하여 구조적으로 중요한 IOC 요소를 보존하면서도 버려졌거나 매핑되지 않은 서브스트링에 페널티를 적용합니다. 이 반복적 설계와 각 단계마다 적용되는 결정론적 검증기는 크고 이기종적인 평가 집합에서 구조적으로 충실한 정규 표현식 패턴 생성을 지원합니다. 참조 평가에서는 이 워크플로우가 3,156개의 CTI 보고서에 적용되어 2,400개 이상의 독립적인 진실 문자열과 비교하여 평균 명중률 99.1%, 평균 교차 IOC 불일치율 0.8%를 얻었습니다. 이 현장 진실 문자열은 MITRE AT&CK 평가 과정에서 사이버보안 업체가 보고한 전문가가 선별한 산출물이기 때문에, 이 평가는 프로토콜의 출력을 자동화된 분석가가 문서화한 IOC 패턴과 암묵적으로 비교하는 것입니다.

대표적인 결과에서 보듯, 워크플로우가 중첩된 파일 경로나 긴 명령줄 문자열과 같은 복잡한 IOC 구조를 처리할 때 반복적 최적화가 특히 중요합니다. 참고 평가 결과에 따르면, 가장 흔한 비매칭 사례는 공격자가 그래프 데이터베이스에 표현되지 않거나 CTI 보고서에 명시적으로 문서화되지 않은 맞춤형 실행 파일이나 매개변수를 사용할 때 발생합니다. 운영 중에는 이러한 실패 모드가 무음 오류가 아닌 예상 경계 조건으로 처리되어야 하며, 그래프 커버리지, 소스 보고서 완전성, 정규 식-디버깅 텔레메트리 검토를 촉발해야 합니다.

이 프로토콜은 세 가지 대안 방법군과 비교할 수 있습니다. 첫째, TransRegex¹¹과 Regex+¹²와 같은 예제 기반 정규 연합 기법은 엄선된 양정 및 음수 문자열 예제 집합에서 정규 표현을 학습합니다. 이 방법들은 대표적인 예제 세트가 있을 때는 잘 작동하지만, CTI에서 보고된 각 IOC가 일반적으로 단일 대표 문자열로 나타나고, 필요한 일반화 경계가 예제 커버리지보다는 운영 의미론에 의해 결정되는 SOC 맥락에는 직접적으로 덜 적용됩니다. 둘째, Bartoli 등이 도입한 유전적 프로그래밍 접근법(^13,14)은 진화적 연산자를 통해 정규 식의 공간을 탐색하며, 일반적으로 일치 문자열과 비일치 문자열로 표시된 라벨링된 말뭉치를 필요로 합니다; 추출 패턴의 배치 구성에 적합하지만 비구조화된 CTI 내러티브를 직접 소비하지는 않습니다. 셋째, 최근의 신경 및 LLM 기반 접근법^15,16은 자연어 설명을 정규 표현 문자열로 직접 번역합니다; 이 방법들은 잘 지정된 프롬프트에 강력하지만, 단일 샷 사용 시 문법적으로 유효하지만 필요한 캡처 그룹 구성 요소를 누락하거나 관련 없는 IOC 변형에 과도하게 일반화되는 정규 식을 생성할 수 있습니다. 본 프로토콜은 (i) 큐레이션된 예제 집합이나 자연어 쿼리 대신 비구조화된 CTI 보고서를 입력으로 받고, (ii) 어떤 정규 표현식도 생성되기 전에 그래프 지원 정규화를 통해 각 IOC를 유지와 폐기, 그리고 (iii) 제한이 있는 반복 루프 내에서 결정적 매치, 버리기, 과도한 일반화 검사로 각 후보 정규식을 검증함으로써 이러한 지침을 보완합니다. 목표는 기존 방법들에서 자체 벤치마크를 능가하는 것이 아니라, 중간 결정이 SOC 분석가가 검사 및 감사 가능한 재현 가능한 IOC에서 정규 표현법으로의 파이프라인을 제공하는 것입니다.

프로토콜은 입력된 CTI 보고서의 품질에 대해 여러 가정을 합니다. 이 프로토콜은 (i) 문서 파싱 후 IOC 문자열이 복구 가능한 텍스트 형태로 나타나며, 즉 파일 경로, 레지스트리 키, 명령줄 표시기가 이미지, 스크린샷, 또는 난독화된 인코딩에만 내장되어 있지 않다는 가정을 합니다; (ii) CTI에 보고된 IOC 조각들은 구조적 앵커를 보존할 만큼 충분히 완전합니다(예: 레지스트리 키는 하이브 접두사를 유지하고, 파일 경로는 Windows 문서 그래프에서 인식 가능한 최소 하나의 디렉터리 앵커를 유지하며, 명령줄은 호출 실행 파일 또는 알려진 모듈 참조를 유지함); 그리고 (iii) 보고된 IOC는 프로토콜이 의존하는 캡처 그룹 구성 요소를 제거하도록 축소, 편집 또는 재작성되지 않습니다. 이러한 가정을 충족하는 CTI 보고서에는 대부분의 MITRE ATT&CK 기술 설명, 공급업체 권고문, 사고 대응 보고서, 잘 구성된 위협 공지가 포함됩니다. 주로 스크린샷에 의존하거나, 주변 맥락이 없는 매우 축약된 IOC 목록, 명시적인 IOC 문자열이 없는 자유 텍스트 의역은 의도된 작동 범위를 벗어나 추출 호출율이 감소하고 정규화가 덜 충실할 것으로 예상됩니다; 이러한 보고서는 파이프라인에 들어가기 전에 상류 이미지-텍스트 전처리나 분석가 검토를 통해 혜택을 받을 수 있습니다.

이 프로토콜을 적용할 때 고려해야 할 몇 가지 제한 사항이 있습니다. 첫째, 현재 구현은 도메인, 이메일 산출물, 사용자 에이전트 문자열, 동작 시퀀스와 같은 광범위한 IOC 범주보다는 파일 경로, 레지스트리 키, 명령줄 표시기에 집중하고 있습니다. 이는 의도적인 범위 선택으로, 원자 지표는 일반적으로 정확 일치 워크플로우로 잘 처리되며, 현재 프로토콜은 정규 표현식 일반화의 이점을 얻는 가변 구조 IOC를 대상으로 합니다; 그럼에도 불구하고 그래프에 현재 표현되지 않은 IOC 유형에 대한 적용 제한을 가집니다. 둘째, 현재의 실패 시나리오는 세 가지 주요 범주로 나뉩니다: 운영 체제 그래프에 없는 비네이티브 경로 또는 명령줄 인수, 관련 유틸리티나 구조에 대한 불완전한 그래프 커버리지, 그리고 중요한 명령 조각이나 명령어가 보고되지 않는 CTI 소스 자체의 불완전성. 셋째, 참조 평가에서 사용된 교차 IOC 불일치 지표는 배포된 SIEM 논리 하에서 종단 간 경고 오탐이 아니라 생성된 정규 식의 의미적 특이성을 측정합니다.

LLM 변동성 및 버전 관리 하에서의 재현성. IOC 추출과 정규 표현식 생성 단계가 상업용 LLM 엔드포인트에 의존하기 때문에, 재현성에 영향을 미치는 두 가지 변수: 제공자 측 모델 업데이트와 호출당 샘플링 확률입니다. 첫 번째 문제를 완화하기 위해, 재료 테이블의 모든 LLM 관련 필드는 정확한 모델 식별자와 참조 평가에 사용된 접근 날짜를 기록하며, 프로토콜은 제공자가 특정 모델 스냅샷을 노출할 때마다 핀을 권장합니다. 두 번째 문제를 완화하기 위해 참조 구현은 IOC 추출 온도를 0.0으로 고정하고, 정규 표현식 생성 단계에서만 0이 아닌 온도를 사용하며, 2단계와 5단계의 집합 투표와 결정론적 검증기가 잔여 변동을 흡수합니다. 이 결과를 재현할 때는 정확한 모델 버전, 접근 날짜, 온도, 그리고 사용된 앙상블 투표 임계값을 기록해야 합니다; 이 축들 중 어느 하나에서 실질적인 편차가 발생하면 명중률과 불일치 지표가 변동할 것으로 예상되어야 합니다.

여러 복구 가능한 고장 모드는 이를 발생시킨 단계 수준에서 다룰 수 있습니다. 1단계 파싱 실패 (예: 스캔된 PDF에서 빈 마크다운이나 잡음이 생기는 경우): 입력을 광학 문자 인식이나 외부 변환기로 전처리한 후 다시 업로드하는 경우; 진행 전에 파싱된 섹션 수와 총 문자 수가 0이 아닌지 확인하세요. 2단계 추출 실패 (IOC가 반환되지 않거나 환각된 항목): 앙상블 투표 임계값(최소 투표 ≥ 2) 증가, 추가 모델 인스턴스 활성화, 또는 LLM 온도를 낮추기; API 연결성을 확인하고, 구성된 모델이 JSON 형식의 출력을 수용하는지 확인합니다. 4단계 정규화(모든 IOC 구성 요소는 폐기로 표시됨): Neo4j 참조 그래프를 벤더 또는 환경별 경로 구성 요소와 레지스트리 루트로 확장; Cypher 가져오기 스크립트와 유지/폐기 결정 규칙은 보충 파일 2에 나열되어 있습니다. 5단계 정규 표현식 실패 (used_fallback = 참, 또는 반복된 버림-검증 거부): 실패한 검증자를 식별하기 위해 각 IOC 최적화 이력 필드를 점검함; 만약 IOC에 안정적인 유지-구성 요소가 정말로 부족하다면, 해당 IOC에 대해 수동 정규 표현식 작성을 고려하거나 자동 규칙 생성에서 제외하고 분석가 검토를 위해 분류된 IOC 테이블에 남겨두는 것을 고려해 보세요.

위의 한계와 일치하여, 생성된 정규식은 자급자족 검출기보다는 광범위한 SOC 탐지 콘텐츠 내에서 재사용 가능한 탐색 원시 자료로 다루는 것이 가장 좋습니다. 운영 환경에서는 분석가가 플랫폼별 필드 로직, 화이트리스트, 출처 검사 또는 상관관계 조건과 결합하여 비범하지만 악의적이지 않은 경로에서 발생하는 무해한 일치를 억제할 수 있습니다.

향후 작업에는 인간이 작성한 정규식과의 체계적 비교, 추가 IOC 범주에 대한 광범위한 평가, 구조화된 분석가 피드백 연구, 공격자가 만든 유틸리티 및 명령어에 대한 그래프 커버리지 확대, 배포 환경 전반에 걸친 엔드 투 엔드 지연 및 비용의 더 완전한 보고가 포함될 수 있습니다. 그럼에도 불구하고, 현재 프로토콜은 IOC에서 정규 표현식으로의 번역을 재현 가능하고 운영적으로 해석 가능한 프레임워크로 제공하며, 그 강점과 현재의 한계를 모두 문서화합니다.

재료

이 논문에 사용된 재료 목록

이름	회사	카탈로그 번호	댓글
컴퓨터 (CPU)	—	≥ 4 코어 권장	GPU 불필요
LangChain	LangChain	≥ 0.1.x	LLM 오케스트레이션 프레임워크
LLM (IOC 추출, 단일 모델)	OpenAI	gpt-5.1	앙상블 투표가 비활성화된 경우 IOC 추출(2단계)에 사용됨. 온도 = 0.0; max_workers = 5. 접근: 2025-12-15.
LLM (정규식 생성)	OpenAI	gpt-5.1	정규식 생성(5단계)에 사용됨. 다운스트림 검증 전 온도 = 0.3. 접근: 2025-12-15.
LLM (확장성 특성화)	OpenAI	gpt-5.1	대표적인 결과에 보고된 6,000-IOC 확장성 실행에 사용됨. 접근: 2025-12-15.
메모리 (RAM)	—	≥ 16 GB 권장	문서 처리에 필요
Neo4j	Neo4j, Inc.	≥ 5.x	IOC 정규화를 위한 그래프 데이터베이스
Neo4j Python 드라이버	Neo4j, Inc.	≥ 5.x	Neo4j에 대한 Python 인터페이스
운영 체제	Microsoft / Apple / Linux	Windows, macOS, 또는 Linux	크로스 플랫폼 지원
PDF 파싱 — 기본 백엔드	Microsoft	MarkItDown ≥ 0.0.x	1단계 백엔드; PDF/DOCX/HTML/TXT 입력을 마크다운으로 변환. 파싱된 출력은 LLM 처리 전에 4,000 문자 단위로 청크화됨. 접근: 2025-12-15. https://github.com/microsoft/markitdown
파이프라인 구성(2단계 — IOC 추출)	—	참조 기본값	단일 LLM 모드: 온도 = 0.0, max_workers = 5. 앙상블 투표 모드 기본값: 구성된 모델당 반복 = 1, 최소 투표 = 2.
파이프라인 구성(5단계 — 정규식 생성)	—	참조 기본값	생성 온도 = 0.3. 검증: IOC당 5개의 결정론적 부정 샘플의 overgen_random_tests. 반복 제한: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	필요한 런타임 환경
정규식 엔진	Python 표준 라이브러리	re 모듈	정규식 검증 및 테스트에 사용
Streamlit	Streamlit Inc.	≥ 1.25	웹 기반 사용자 인터페이스
참조 구현 소스 코드	저자 / GitHub | GitHub 저장소		Streamlit 인터페이스, LangChain 파이프라인, Neo4j 보조 정규화, 정규식 생성, 유효성 검사 유틸리티 및 예제 구성 파일에 대한 소스 코드. https://github.com/SOCautomatic/cti-ioc-regex-pipeline에서 사용 가능. 접근: 2026년 6월 11일.