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

요약

여기서는 사이버 위협 인텔리전스 보고서의 파일 경로, 레지스트리 키, 명령줄 표시자를 보안 정보 및 이벤트 관리(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 평가 과정에서 사이버보안 벤더가 독립적으로 보고한 전문가가 선별한 공격 산출물로, 인간 분석가와 벤더가 실제로 문서화하는 구조적 패턴을 반영합니다. 아래 결과는 작업 흐름 동작, 구조적 정확성, 그리고 운영 로그 분석 및 탐지 워크플로우와 관련된 평가 결과에 초점을 맞추고 있습니다.

엔드 투 엔드 파이프라인에 대한 개요...

토론

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

재료

이 논문에 사용된 재료 목록

이름	회사	카탈로그 번호	댓글
컴퓨터 (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일.