DEEP DIVE REPORT

OCSF 기반 SIEM 데이터 정규화: 탐지 규칙 이식성과 운영 비용 개선 가이드

SecurityDesk
2026.08.07 조회 7

개요 및 특징

보안 운영 센터(SOC)에서 가장 큰 부담 중 하나는 수백 가지 로그 소스의 이질적인 데이터 형식을 다루는 것이다. 각 벤더와 제품이 고유한 필드명, 구조, 이벤트 분류 체계를 사용하면서, SIEM 환경에서는 로그 수집부터 탐지 규칙 작성, 인시던트 대응까지 모든 단계에서 수동 매핑과 재작업이 반복된다. Open Cybersecurity Schema Framework(OCSF)는 이러한 문제를 해결하기 위해 탄생한 오픈 표준이다. 2024년 11월 Linux Foundation 프로젝트로 전환된 OCSF는 이제 주요 보안 벤더들의 적극적인 참여 속에 버전 1.10.0 개발 단계에 도달했다.

핵심 구성 요소

OCSF 분류 체계는 데이터 타입, 속성 사전(attribute dictionary), 이벤트 클래스, 카테고리, 프로파일, 익스텐션(확장)의 다섯 가지 기본 구성 요소로 이루어진다.

  • 데이터 타입, 속성, 배열: 스칼라 데이터 타입은 문자열, 정수, 부동소수점, 부울 등의 원시 타입 위에 정의된다. 복합 데이터 타입은 객체(object)라 부르며, 프로세스, 디바이스, 사용자, 맬웨어, 파일 등 컨텍스트적으로 관련된 속성들의 집합이다.
  • 이벤트 클래스(Event Class): 속성 사전에서 특정 속성들의 집합을 구조화하여 이벤트의 시맨틱스를 상세히 설명한다. 각 이벤트 클래스는 스키마에서 고유한 ID를 가진다.
  • 카테고리(Category): 이벤트 클래스를 높은 수준으로 그룹화한다. Network Activity, System Activity, Findings 등 도메인별 컨테이너 역할을 하며, 문서화, 검색, 보고, 스토리지 파티셔닝, 접근 제어 등에 활용된다.
  • 프로파일(Profile): 이벤트 클래스와 객체에 추가로 관련된 속성을 오버레이한다. System Activity 이벤트 클래스에 Security Control 프로파일을 적용하면 맬웨어 탐지 정보, MITRE ATT&CK 객체, 디스포지션 등의 속성이 추가된다.
  • 익스텐션(Extension): 핵심 스키마를 수정하지 않고도 스키마를 확장할 수 있게 한다. 새로운 속성, 객체, 이벤트 클래스, 카테고리, 프로파일 모두 익스텐션에서 정의 가능하다.

네 가지 페르소나

OCSF는 스키마 생태계에서 네 가지 사용자 페르소나를 정의한다.

  • 저작자(Author): 스키마를 생성하거나 확장하는 역할
  • 생성자(Producer): 이벤트를 스키마에 네이티브로 생성하거나 다른 스키마에서 변환하여 생성하는 역할
  • 매핑 담당자(Mapper): 다른 소스에서 이벤트를 번역하거나 스키마로 변환하는 역할
  • 분석가(Analyst): 데이터를 검색하고, 스키마에 대해 규칙이나 분석을 작성하거나, 리포트를 생성하는 최종 사용자

핵심 특징

OCSF는 저장소 형식, 데이터 수집 방식, ETL 프로세스에 종속되지 않으며, 스키마 정의 파일과 결과 스키마는 JSON으로 작성된다. 스키마 브라우저(schema.ocsf.io)에서 카테고리, 이벤트 클래스, 사전, 데이터 타입, 프로파일, 익스텐션을 탐색하고 검증 서버 API를 통해 이벤트를 검증할 수 있다.

동작 원리·기술 스택

OCSF의 기술적 설계는 벤더 중립성과 형식 독립성을 핵심 원리로 한다. JSON 기반 스키마 정의를 통해 Elastic, Splunk, Microsoft Sentinel 등 다양한 SIEM 플랫폼에 적용 가능하도록 설계되었으며, 계층적 객체 구조를 통해 보안 이벤트의 컨텍스트를 풍부하게 표현할 수 있다.

Required/Recommended 속성 체계

OCSF는 속성마다 Required와 Recommended 두 가지 레벨을 정의한다. Required 속성은 이벤트의 핵심 식별에 필요하며 누락 시 스키마 검증에서 차단된다. Recommended 속성은 컨텍스트 보강에 활용되며, 가능한 한 채우는 것이 좋다. 이 체계는 데이터 품질을 구조적으로 개선하며, 하위 파이프라인(탐지, 상관 분석, 리포팅)의 신뢰성을 높인다.

Observables 배열과 메타데이터

Observables 배열을 활용하면 이벤트의 핵심 속성을 공통 위치에서 노출할 수 있어 분석가의 검색 효율이 크게 개선된다. metadata.correlation_uid를 사용하면 동일한 스캔 또는 인시던트와 관련된 여러 이벤트를 하나로 묶을 수 있다.

{
  "metadata": {
    "product": "Endpoint Security Agent",
    "version": "4.2.1",
    "schema_version": "1.0.0",
    "device": "ocsf-bridge-v1"
  },
  "class_uid": 3002,
  "class_name": "Process Activity",
  "category_uid": 3,
  "category_name": "System Activity",
  "activity_id": 1,
  "severity_id": 4,
  "time": 1709164800000,
  "actor": {
    "process": {
      "name": "svchost.exe",
      "pid": 4288,
      "file": {
        "path": "C:\\Windows\\System32\\svchost.exe",
        "hashes": [
          {
            "type_id": 256,
            "algorithm": "SHA-256",
            "value": "a1b2c3..."
          }
        ]
      }
    }
  }
}

스키마 검증 API

OCSF는 검증 서버 API를 제공하여 이벤트가 스키마에 부합하는지 프로그래매틱하게 검증할 수 있다. Elastic은 OCSF 스키마 브라우저의 검증 서버 API를 내부 파이프라인에서 활용한다.

사용 사례 및 장단점

OCSF의 실질적 가치를 평가하려면 주요 SIEM 및 보안 플랫폼 벤더들의 지원 수준과 도입 효과를 확인해야 한다.

주요 벤더 지원 현황

  • Elastic: OCSF의 초기 기여자 중 하나다. Elastic SIEM의 통합 이벤트 모델(IEM)이 OCSF와 유사한 개념을 채택했으며, OCSF 스키마를 Elastic Stack으로 가져오는 공식 변환기가 제공된다.
  • Splunk: Common Information Model(CIM)을 자체 표준으로 운영해 왔다. 그러나 OCSF와의 매핑 연구를 진행 중이며, Splunkbase에 OCSF 관련 기술 애드온이 이미 게시된 상태다.
  • Microsoft Sentinel: ASIM 함수를 통해 이미 이벤트 정규화를 제공하지만, OCSF와의 상호운용성도 지속적으로 개선하고 있다. MITRE ATT&CK 매핑이 두 프레임워크에서 공통으로 중요시됨을 고려할 때, OCSF의 ATT&CK 객체와의 자연스러운 연동이 기대된다.
  • Fastly: OCSF를 보안 이벤트 로그의 기본 포맷으로 채택하고 있다.
  • 기타: CrowdStrike, Palo Alto Networks, Tenable 등 주요 엔드포인트 및 취약점 관리 벤더들도 OCSF 컨트리뷰터 리스트에 포함되거나 스키마 확장을 검토 중이다.

운영 효과

  • 탐지 규칙 개발 시간 단축: 통일된 스키마를 사용하면 새로운 로그 소스가 도입될 때 별도의 필드 매핑 없이 표준 필드명으로 규칙을 작성할 수 있다. Elastic의 사례에 따르면 OCSF 기반 정규화로 탐지 규칙 개발 시간이 40~60% 단축되었다.
  • 교차 벤더 상관 분석 가능: metadata.correlation_uid와 공통 속성 구조를 통해 엔드포인트 이벤트, 네트워크 이벤트, IAM 이벤트를 하나의 쿼리로 상관 분석할 수 있으며, 공격 체인(attribution chain) 추적 시간이 현저히 줄어든다.
  • 벤더 교체 리스크 최소화: SIEM 벤더를 교체할 경우 기존 탐지 규칙의 OCSF 필드 기준 재작성으로 인해 규칙의 핵심 논식은 유지되며, 벤더 특정 함수나 쿼리 문법만 변경하면 되므로 마이그레이션 비용이 크게 절감된다.

한계 및 제약

  • OCSF가 비교적 새로운 표준인 만큼, 모든 벤더가 네이티브로 지원하지는 않는다.
  • 기존 ECS나 ASIM에 익숙한 팀의 경우 학습 곡선이 존재한다.
  • 파이프라인 재설계 시 초기 투자 비용과 시간이 필요하다.

기존 솔루션 비교

보안 데이터 정규화 분야에는 이미 Elastic Common Schema(ECS), Microsoft ASIM, CIS LEE Taxonomy 등 여러 표준이 존재한다. OCSF가 기존 표준과 어떻게 다른지 살펴본다.

ECS(Elastic Common Schema) 대비

ECS는 Elasticsearch/Lucene 생태계에 최적화된 스키마다. Elastic Stack 사용자에게는 자연스러운 선택이지만, Elastic 생태계 외의 환경에서는 활용도가 제한적이다. OCSF는 저장소 형식과 독립적으로 설계되었으며, JSON, Parquet, Avro 등 다양한 형식과 호환된다. ECS가 평탄화된 필드 구조를 선호하는 반면, OCSF는 계층적 객체 구조를 통해 컨텍스트를 더 풍부하게 표현할 수 있다.

ASIM(Azure Schema Definition for Ingestion and Modeling) 대비

ASIM은 Microsoft Azure Sentinel 중심의 함수 기반 접근법이다. 이벤트 함수를 통해 표준화된 접근을 제공하지만, 스키마의 유연성과 확장성이 OCSF보다 제한적이다. OCSF의 익스텐션과 프로파일 메커니즘은 도메인별 커스터마이징을 공식적으로 지원하며, 벤더가 자체 확장을 추가해도 핵심 스키마와의 호환성을 유지할 수 있다.

CIS LEE Taxonomy 대비

CIS LEE Taxonomy는 데이터 소스 분류 체계를 제공하지만, 필드 수준의 스키마 정의를 제공하지 않는다. OCSF는 카테고리(분류)와 이벤트 클래스(구체적인 이벤트 타입), 속성 사전(필드 정의)까지 포괄하는 완전한 스키마 프레임워크다.

비교 테이블

비교 항목 OCSF ECS ASIM
벤더 중립성 Linux Foundation 관리 Elastic 중심 Microsoft 중심
형식 독립성 JSON/Parquet/Avro Elasticsearch 최적화 Azure Sentinel 최적화
확장성 공식 익스텐션/프로파일 커스텀 필드 제한적
스키마 검증 검증 서버 API 제한적 제한적
커뮤니티 오픈 컨소시엄 Elastic 커뮤니티 Microsoft 커뮤니티

도입 고려사항

기존 SIEM 환경에서 OCSF 기반 정규화 체계로 이동하는 것은 단순한 스키마 변경이 아니다. 필드 매핑, 파이프라인 재설계, 탐지 규칙 검증이라는 세 단계가 체계적으로 수행되어야 한다.

단계 1: 데이터 소스 인벤토리 및 매핑

기존 환경의 모든 로그 소스를 식별하고, 각 소스의 필드를 OCSF 이벤트 클래스와 속성에 매핑한다. 이 단계에서 주의할 점은 OCSF 이벤트 클래스의 Required 속성은 반드시 채워야 하며, Recommended 속성은 가능한 한 채우는 것이 좋다.

단계 2: 파이프라인 재설계

기존 ETL 파이프라인에서 OCSF 스키마로 변환하는 로직을 구현한다. Observables 배열을 활용하면 이벤트의 핵심 속성을 공통 위치에서 노출할 수 있어 분석가의 검색 효율이 크게 개선된다.

단계 3: 탐지 규칙 회귀 테스트

가장 중요한 단계다. 기존 탐지 규칙을 OCSF 필드 기준으로 재작성한 후, 실제 로그 데이터를 사용하여 규칙이 의도대로 작동하는지 검증한다.

  • 기존 규칙의 조건이 OCSF 필드로 정확히 매핑되었는지 확인
  • Enum 값 매핑이 올바른지 검증 (예: severity_id 값 범위 확인)
  • Observables 배열을 활용한 검색 쿼리가 정확히 작동하는지 테스트
  • 프로파일이 적용된 이벤트에서 추가 속성이 접근 가능한지 확인
  • 기존 규칙 대비 새로운 규칙의 정밀도(precision)와 재현율(recall)이 동일하거나 개선되었는지 비교

단계 4: 점진적 롤아웃

모든 규칙을 한 번에 전환하지 말고, 우선 핵심 이벤트 클래스(예: Process Activity, Network Activity, Authentication)부터 전환한 후 점진적으로 확장한다. 전환 기간 동안 기존 규칙과 새 규칙을 병행 운영하여 일관성을 검증한다.

권장 사항

보안 운영 팀이 OCSF를 도입할 때 가장 먼저 해야 할 일은 소규모 파일럿 프로젝트다. 핵심 이벤트 클래스 2~3개를 선택해 매핑 파이프라인을 구축하고, 탐지 규칙 회귀 테스트를 통해 안정성을 검증한 후 점진적으로 확장하는 것이 바람직한 접근 방식이다.

참고문헌

  1. OCSF 공식 웹사이트
    https://ocsf.io/

  2. Understanding the Open Cybersecurity Schema Framework (White Paper)
    https://github.com/ocsf/ocsf-docs/blob/main/overview/understanding-ocsf.md

  3. OCSF Schema Repository
    https://github.com/ocsf/ocsf-schema

  4. OCSF Schema Browser
    https://schema.ocsf.io

  5. OCSF Schema FAQ
    https://github.com/ocsf/ocsf-docs/blob/main/faqs/schema-faq.md

  6. Linux Foundation — OCSF Technical Charter
    https://github.com/ocsf/governance/blob/main/OCSF%20Technical%20Charter.pdf


본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.

댓글 (0)

댓글을 작성하려면 로그인이 필요합니다.

로그인

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!

IT 도구 서랍

→ Unix: 2025-01-15T09:30:00
→ 날짜: 1736934600

→ ASCII: ABC
→ 문자: 65 66 67

ASCII 코드표 — 클릭하면 입력란에 추가

DecHex약어설명
DecHex문자
DecHex문자

→ 유니코드: 홍길동
→ 문자: \ud64d\uae38\ub3d9