배경(Problem)
TrustSOC를 기획할 때 가장 먼저 떠올린 대상은 ‘보안 조직을 운영할 수 있는 중견 기업 이상의 기업·단체’가 중소 중소·강소 기업, 스타트업, 그리고 하나의 서비스나 제품을 책임지는 작은 팀·그룹이었습니다.
흔히 말하는 대기업 SOC처럼 24시간 관제를 돌리고, SIEM·SOAR를 복합적으로 도입할 수 있는 조직이 아니라 개발자와 운영 담당자 몇 명이 “보안까지 책임지는” 환경이었습니다.
이런 조직들은 이미 어느 정도의 로그 수집 인프라는 가지고 있는 경우가 많습니다. 클루아드 콘솔, ELK 스택, 간단한 중앙 syslog, APM 도구 등으로 웹 서버와 애플리케이션, 시스템 로그를 모아두긴 합니다. 하지만 문제는 그 다음입니다. 공격 흔적이 로그에 남아 있더라도, 이를 실시간으로 탐지하고 인시던트 단위로 정리해 줄 사람과 도구가 없다는 점입니다. 사고가 터진 뒤에야 “그때 로그를 보니 이런 패턴이 있었구나” 하는 전형적인 사후 분석 패턴이 반복됩니다.
상용 SIEM/SOAR 솔루션이 이런 문제를 어느 정도 해결해 줄 수는 있습니다. 그러나 중소·강소 기업이나 스타트업 입장에서는 현실적인 선택지가 아닌 경우가 많습니다. 라이선스 비용과 인프라 비용, 초기 구축 컨설팅, 지속적인 룰 튜닝과 운영 인력까지 고려하면 전체 IT 예산에서 차지하는 비중이 너무 크거나 아예 예산을 확보하기가 어렵습니다. 설령 일부 기능만 도입하더라도 작은 팀이 이해하고 유지보수하기에는 복잡성과 러닝커브가 과도한 경우가 많습니다.
결국 이들 조직의 현실은 두 가지 사이에서 갈팡질팡합니다.
하나는 “로그는 잘 쌓이지만 아무도 제대로 보지 못하는 상태”, 다른 하나는 ”경보는 많이 울리지만, 정리된 맥락과 우선순위가 없어 대응이 늦어지는 상태”입니다. 둘 다 공통적으로 전문 SOC를 두기 어려운 작은 조직에게는 지속 가능한 형태의 탐지·분석·대응 체계가 없다는 사실을 보여줍니다.
TrustSOC는 바로 이 지점에서 출발했습니다.
우리가 상정한 페르소나는 예를 들어 직원 10인 내외 규모의 스타트업이나 기업이 아닌 팀이나 그룹과 같은 조직입니다. 이들은 이미 웹 서버와 애플리케이션 로그를 가지고 있고, Kubernetes나 VM 위에서 서비스를 운영하지만, Splunk나 QRadar 같은 대형 SIEM을 도입할 여력도, 전담 보안 인력을 둘 여유도 없습니다. 대신, “서버 로그만이라도 제대로 활용해서 ,최소한의 SOC 기능을 갖추고 싶다”는 요구는 분명히 존재합니다.
그래서 TrustSOC는 “대기업 수준의 완전한 SIEM”을 목표로 하지 않습니다. 그보다는 서버 또는 애플리케이션에 설치된 Agent → 로그 수집/전송 → 하이브리드 탐지(Rule/ML/YARA) → LLM 기반 인시던트 요약 및 대응 가이드 → Slack/ELK 알림으로 이어지는 작은 팀이 이해하고 운영할 수 있는 최소하지만 완결된 SOC 파이프라인을 만드는 것을 목표로 합니다. 고비용·고복잡도의 상용 솔룻현 대신, 소규모 조직도 스스로 운영 가능한 현실적인 보안 파이프라인을 제공하는 것이 이 프로젝트의 출발점이자 해결하고자 한 문제입니다.
서비스 소개(Solution)
TrustSOC는 거창한 엔터프라이즈 보안 플랫폼이라기보다는 중소·강소 기업, 스타트업 그리고 작은 서비스 팀을 위한 “로그 기반 미니 SOC”에 가깝습니다.
서버 또는 애플리케이션에 설치된 Agent가 로그를 수집해서 솔루션 서버로 보내면, 백엔드와 탐지 엔진이 이를 분석하고, 마지막으로 LLM이 해당 상황을 인시던트 단위로 요약하고, MITRE ATT&CK 관점에서 해석한 뒤, “무엇을 해야 하는지”에 대한 대응 가이드를 적어 줍니다.
관리자는 이 결과를 Slack이나 ELK 화면, 전용 대시보드에서 확인하고, 최종 차단이나 추가 조사는 관리자가 판단해서 진행해야 합니다. TrustSOC는 자동으로 방화벽을 변경하거나 계정을 잠그는 솔루션이 아니라, “상황을 정리해 주고, 우선순위를 잡아주는 조언자” 역할을 목표로 합니다.
주의) 시연 영상은 Agent를 이용한 테스트가 아닌 솔루션 서버가 정상적으로 분석 및 결과 생성이 가능한지를 테스트한 영상입니다.
아키텍처 및 핵심 기능
전체 아키텍처 구조
데이터 흐름 (수집 → 탐지 → LLM)
1.
로그 생성
•
웹 서버, 애플리케이션, OS, 컨테이너 등에서 로그가 파일/syslog 형태로 기록된다.
2.
Agent 수집
•
otel-agent 가 설정된 경로/소스,로부터 로그를 tail/수신한다.
•
정책(global<client<host)에 따라 수집 대상·필드·샘플링 비율을 결정하고, transform 단계에서 개인정보(PII)를 기본 마스킹한다.
3.
전송
•
otel-agent 는 로그를 OTLP/HTTP로 secure-forwarder 에 전송한다.
•
secure-forwarder 는 로컬 토큰을 검증한 뒤 Authorization, timestamp/nonce, payload hash, HMAC 서명 헤더를 붙여 솔루션 서버 Ingest API로 TLS1.3(조건부 mTLS) 연결을 사용해 전송한다.
4.
Ingest 및 저장
•
Backend는 토큰·타임스탬프·payload hash·멱등 키를 검증한다.
•
검증이 통과되면 raw_logs(및 필요 시 audit_logs)에 로그를 저장하고, 후속 처리(정규화/탐지)를 위한 큐나 워커에 작업을 전달한다.
5.
정규화 및 탐지
•
Normalizer/Enricher가 로그를 ECS-lite 형태로 정규화하고, 필요 시 GeoIP/ASN/User-Agent 정보를 보강한다.
•
Rule 엔진은 패턴/조건식 기반 탐지, ML 엔진은 롤업 피처 기반 이상 탐지, HEX/YARA 엔진은 파일/바이너리 패턴 탐치를 수행한다.
•
Hybrid 모듈이 이 결과를 결합해 최종 Event/Incident를 생성한다.
6.
LLM 분석
•
Backend는 관련 이벤트를 묶어 Incident를 만들고, LLM Advisor에게 Incident + evidence를 전달한다.
•
LLM Advisor는 ATT&CK 매핑, 요약, 대응 가이드를 생성해 다시 Backend로 반환한다.
7.
알림 및 조회
•
Backend는 이 결과를 DB에 저장하고, 전용 웹 대시보드에서 확인할 수 있다.
•
Slack/웹훅/ELK 등으로 전달해 관리자가 더 쉽게 확인할 수 있게 한다.
컴포넌트별 역할
1.
Agent
•
otel-agent
◦
파일/애플리케이션/시스템 로그를 수집하는 OpenTelemetry Collector 인스턴스
◦
transform/mask_pii, 샘플링, batch/queued_retry 등으로 수집·전송 안정성 확보
•
secure-forwarder
◦
로컬 OTLP/HTTP 엔드포인트
◦
로컬 토큰 검증 후 솔루션 서버로 TLS/(조건부)mTLS + 서명 전송
•
agent-controller
◦
솔루션 서버의 Control API를 주기적으로 풀링
◦
RULES_RELOAD, CERT_ROTATE, UPGRADE 등의 명령을 받아 설정 변경, 서비스 재시작 등을 수행하고 결과를 ACK
2.
Solution Server - Backend & DB
•
FastAPI 기반 Ingest/API 서버
•
멀티테넌시: X-Client-Id / X-Tenant-Id 기반 TenantContext → Postgres RLS 연동
•
주요 데이터 모델
◦
raw_logs: 원본 로그 저장
◦
events: 개별 탐지 이벤트(Rule/ML/YARA/Hybrid)
◦
incidents: 여러 이벤트를 묶은 인시던트 + LLM 분석 결과
◦
feature_rollup_*: ML용 롤업 피쳐
◦
evidence_refs: 파일/바이너리 증거 메타데이터
•
파티셔닁 및 ILM: 시계열 중심 테이블을 일/월 단위 파티션으로 운영
3.
Detect 엔진
•
Rule 엔진: YAML 기반 룰 정의(윈도, 조건식, severity, ATT&CK 매핑 포함)
•
ML 엔진: 롤업 피쳐 기반 이상 탐지(Isolation Forest, EWMA 등)
•
HEX/YARA 엔진: 파일/압축 해제 결과에 대한 시그니처 매칭
•
Hybrid Detect: 룰/ML/YARA 결과 + 향후 FP 페널티를 하나의 점수/심각도로 통합
4.
LLM Advisor
•
Incident + evidence를 입력으로 받아 ATT&CK 매핑·요약·대응 가이드를 생성
•
JSON Schema 검증, evidence 부족 시 HIL 요구, guardrail 적용
5.
외부 연동
•
Slack: 인시던트 요약 및 대응 가이드를 카드 형태로 전달
•
ELK/로그 플랫폼: raw_logs/events/incidents를 기반으로 타임라인/검색 UI 제공
•
Webhook/HIL: 인시던트 승인/반려, 외부 시스템 연계 등을 위한 후크
활용 라이브러리 및 개발 환경
TrustSOC는 Python 3.11을 중심으로 표준화된 수집/저장/탐지/LLM 스택과 VMware + Kubernetes 기반 개발 환경 위에서 개발되었습니다. 대규모 조직이 아닌 소규모 팀이 이해하고 유지보수할 수 있는 수준의 스택을 의도적으로 선택했습니다.
언어 및 런타임
•
Python 3.11
◦
Backend API 서버, 탐지 엔진, LLM Advisor, 에이전트 보조 모듈에 공통적으로 사용한 메인 언어/런타임.
◦
타입 힌트, 비동기 처리, 풍부한 라이브러리 생태계를 고려해 선택.
서버 사이드 기술 스택
•
FastAPI
◦
Python 기반 ASGI 웹 프레임워크.
◦
REST API 서버 구현에 사용했으며, OpenAPI 자동 문서화 지원
•
Uvicorn
◦
ASGI 서버.
◦
FastAPI 애플리케이션 실행에 사용.
•
SQLAlchemy
◦
ORM 및 SQL 표현 라이브러리.
◦
PostgreSQL과의 데이터 모델링 및 쿼리 작성에 활용.
•
Pydantic
◦
데이터 검증 및 설정 관리용 라이브러리.
◦
API 요청/응답 스키마 정의 및 LLM 응답 검증에 사용.
•
PostgreSQL
◦
관계형 데이터베이스.
◦
로그, 이벤트, 인시던트 등 주요 영속 데이터를 저장하는 DB로 사용.
에이전트·로그 수집 관련 스택
•
OpenTelemetry Collector
◦
벤더 중립 로그/매트릭/트레이스 수집기.
◦
파일/애플리케이션/시스템 로그 수집에 사용.
•
OTLP (OpenTelemetry Protocol)
◦
수집된 데이터를 전송하기 위한 프로토콜.
◦
에이전트 → 서버 간 표준 전송 포맷으로 사용.
탐지 및 LLM 관련 스택
•
Python 기반 이상 탐지 라이브러리
◦
시계열/행위 데이터의 이상 징후를 찾기 위해 Python 생태계의 의상 탐지/머신러닝 라이브러리를 활용.(Isolation Forest, EWMA 등)
•
YARA / yara-python
◦
파일/바이너리 패턴 매칭 도구.
◦
웹셀, 악성 스크립트 등 정적 패턴 탐지를 위해 사용.
•
Mistral-7B
◦
LLM 모델.
◦
인시던트 요약, MITRE ATT&CK 매핑, 대응 가이드 생성을 위해 사용한 기본 언어 모델.
•
Python LLM/HTTP 클라이언트
◦
Mistral-7B 호출을 위해 Python HTTP 클라이언트 및 관련 라이브러리 사용.
인프라·개발/운영 환경
•
VMware
◦
개발 및 테스트용 가상화 환경. (OS: Ubuntu 24.04 LTS)
◦
여러 VM 위에 에이전트, 서버, Kubernetes 노드를 구성하여 실제와 유사한 네트워크/시스템 환경을 재현.
•
Kubernetes
◦
컨테이너 이미지 빌드 및 실행에 사용.
◦
백엔드, 탐지 워커, LLM 서비스 등을 컨테이너로 배포·스케일링하는 데 사용.
•
Docker
◦
컨테이너 이미지 빌드 및 실행에 사용.
◦
개발/운영 환경을 동일한 이미지 기반으로 맞추기 위해 활용.
•
ELK 스택 (Elasticsearch·Logstash·Kibana)
◦
로그 저장 및 시각화 플랫폼.
◦
TrustSOC가 생성한 로그/이벤트를 외부에서 조회·분석하는 용도로 사용.
•
Slack
◦
협업 및 알림 도구.
◦
인시던트/이벤트 알림 채널로 연동.
•
Git 및 IDE
◦
git: 소스코드 버전관리. Github 레포지토리 사용.
◦
VS Code 등 Python 화적 IDE/에디터를 사용해 개발.
트러블 슈팅
1.
모듈 통합에서 발생된 문제
•
문제 설명:
◦
Backend와 탐지 엔진/LLM 엔진 간 통신 데이터의 파싱 문제로 모듈이 정상작동을 하지 않음.
•
해결 방법:
◦
요청/전송 데이터를 JSON 형식을 사용하고, 공통 파싱 정책을 적용함.
2.
Kubernetes 환경에서의 운영 문제
•
문제 설명:
◦
쿠버네티스에 이미지를 만들어 올릴 때 환경 변수 적용, 외부 연결 설정 등이 사전에 정의 되어 있지 않음.
•
해결 방법:
◦
디플로이 전에 서비스를 먼저 등록하고, 파일은 호스트에서 가져오도록 지정하는 등 세부적인 부분을 사전에 미리 정의해서 이미지 배포와 동시 사전 정의를 사용하도록 함.
3.
Agent의 로그 파일 접근 불가
•
문제 설명:
◦
로그 파일의 Lock 문제로 Agent가 파일에 접근을 하지 못함.
•
해결 방법:
◦
직접 파일을 접근하는 것이 아닌 LogScale과 tail을 이용해 최신 데이터를 불러오도록 우회 적용함.
팀 소개
저희 팀의 이름은 SentinelOne입니다. 그 이유는 감시병, 파수꾼(Sentinel)처럼 경계 태수를 갖추고 있다는 의미로, 빈틈 없는 보안을 상징하기 때문입니다.
•
팀 구성
◦
팀장
▪
전체 아키텍쳐 및 보안 모델 설계, Threat Modeling 수행
▪
프로젝트 마일스톤 관리 및 총괄.
▪
전체 파이프라인 통합 및 Kubernetes 구축·운영 테스트
◦
플레이어1
▪
Agent 설계 및 제작
▪
Go Routine 최적화 및 경량화 구현
◦
플레이어2
▪
LLM 모델 선정 및 LLM Advisor 모듈 개발
▪
프롬프트 최적화 및 전문가 승인(HIL) 로직 구현
◦
플레이어3
▪
Hybrid 탐지 로직 개발
▪
Hex/YARA 바이너리 분석 모듈 통합
◦
플레이어4
▪
REST API 설계 및 DB 스키마 설계
▪
FastAPI 기반 Ingest/API 구현