CharmingGroot

보안 로그의 공용어, OCSF

보안10분

보안 로그를 두 군데 이상에서 받으면 같은 문제를 만난다. 한 제품은 출발지 주소를 src_ip, 다른 제품은 sourceAddress라고 부르고, 심각도도 하나는 1~5, 하나는 high/low로 준다. 그래서 받는 쪽은 대개 자체 공통 스키마를 만들고 제품마다 변환 규칙을 짠다. 다들 같은 일을 각자 하는 셈이다.

**OCSF(Open Cybersecurity Schema Framework)**는 그 공통 스키마를 업계가 함께 만든 오픈 표준이다. 2022년 8월 AWS와 Splunk가 공동으로 시작했고(AWS 발표), 지금 운영위원회는 Splunk·AWS·IBM이다. 스키마는 Apache-2.0으로 GitHub에 공개돼 있고, 최신 릴리스는 1.9.0(2026-08-03)이다. 전체 구조는 스키마 브라우저에서 볼 수 있다.

네 층으로 이뤄진다

층무엇1.9.0 기준
범주큰 분류(시스템, 탐지·발견, IAM, 네트워크 …)8개
이벤트 클래스실제 이벤트 종류(네트워크 활동, 인증, 탐지 결과 …)79개
속성 사전모든 클래스가 같이 쓰는 필드 정의963개
객체여러 필드를 묶은 단위(엔드포인트, 사용자, 프로세스 …)192개

여기에 프로필(클라우드, 컨테이너, 보안 통제 등 상황별 추가 필드 묶음)과 확장(Linux·Windows·macOS 전용)이 붙는다. 핵심은 속성 사전이다. src_endpoint.ip는 어느 클래스에서 쓰든 같은 뜻이다.

숫자 ID가 뜻을 고정한다

OCSF 이벤트는 숫자로 자기 정체를 밝힌다.

category_uid = 4            네트워크
class_uid    = 4001         네트워크 활동 (범주 × 1000 + 번호)
activity_id  = 5            거절(Refuse)
type_uid     = 400105       class_uid × 100 + activity_id   ← 속성 사전이 이 계산을 요구

type_uid 하나만 보면 “네트워크 활동 중 거절”이라는 걸 바로 안다. 심각도(severity_id)도 0~6과 99로 고정돼 있어 제품마다 다른 척도를 한 줄로 세울 수 있다.

방화벽 로그 한 줄을 바꿔 보면

2026-10-04T09:12:33Z fw01 DENY TCP 203.0.113.50:51514 -> 10.0.0.5:22
{
  "class_uid": 4001, "category_uid": 4, "activity_id": 5, "type_uid": 400105,
  "time": 1791105153000, "severity_id": 1,
  "action_id": 2, "disposition_id": 2,
  "src_endpoint": { "ip": "203.0.113.50", "port": 51514 },
  "dst_endpoint": { "ip": "10.0.0.5", "port": 22 },
  "metadata": { "version": "1.9.0", "product": { "name": "example-firewall" },
                "profiles": ["security_control"] },
  "raw_data": "2026-10-04T09:12:33Z fw01 DENY TCP ...",
  "unmapped": { "rule_name": "block-external-ssh" }
}

클래스 정의는 네트워크 활동에 있다. action_id: 2(거부)와 disposition_id: 2(차단)는 보안 통제 프로필의 필드다. 원본은 raw_data에, 표준에 자리가 없는 값은 unmapped에 남긴다. 버리지 않는다.

로컬 맥북에서 공식 Python 도구 ocsf-lib 0.10.4로 1.9.0 스키마를 컴파일하고, 이 이벤트와 탐지 결과(detection_finding, 2004) 예제를 검사했다. 필수 필드, 열거값, type_uid 계산을 보는 작은 스크립트다. 둘 다 통과했고, 일부러 type_uid를 틀리고 severity_id=9를 넣고 metadata.version을 뺀 이벤트는 세 오류를 모두 잡아냈다.

정규화는 결국 허브에서 한다

OCSF는 아직 모든 장비가 따르는 규격이 아니다. OCSF 관리자와 운영위원회는 Splunk·AWS·IBM 같은 해외 기업으로 이뤄져 있고, 국내 보안 장비 중 OCSF로 로그를 내보낸다고 밝힌 제품은 공개 자료에서 찾기 어렵다. OCSF 데이터를 받는 AWS Security Lake의 연동 파트너 목록에도 국내 기업은 구축 컨설팅 파트너뿐이다. 해외 제품도 상당수는 장비 자체가 아니라 별도 변환기를 거쳐 OCSF로 바뀐다.

그래서 실제 현장에서는 장비 앞단이 아니라 수집 허브나 게이트웨이에서 정규화한다. 국내 사례로 인터파크트리플은 AWS 서비스 로그는 Security Lake에서 바로 OCSF로 받고, 온프레미스의 NAC·IPS·DLP·EDR 로그는 파이프라인 도구로 OCSF로 변환해 모았다(AWS 기술 블로그, 2024-10-23). 표준이 있어도 정규화 계층은 여전히 필요하다는 뜻이다.

그래도 해석은 사람 몫이다

방화벽의 DENY를 “거절(Refuse)“로 볼지 “실패(Fail)“로 볼지는 명세가 정해 주지 않는다. 클래스마다 활동 목록만 있고, 원본 로그를 어디에 맞출지는 매핑하는 사람이 고른다. 두 팀이 같은 로그를 다르게 매핑하면 같은 OCSF라도 질의 결과가 갈린다. 매핑 규칙을 문서로 남기고 버전을 붙여야 하는 이유다.

OCSF는 이벤트의 모양을 정한다. 위협 정보 사이의 관계(이 IP가 어느 공격 그룹과 이어지는지)는 STIX가, 서로 다른 소스를 하나의 그래프로 잇는 일은 RML 같은 매핑 도구가 맡는다. 서로 대체재가 아니라 층이 다르다.

정리

  • OCSF는 보안 이벤트의 공통 스키마를 업계가 같이 만든 오픈 표준이다(Apache-2.0, 1.9.0).
  • 범주 → 클래스 → 속성 사전 → 객체 네 층에, 상황별 프로필과 OS별 확장이 붙는다.
  • type_uid = class_uid × 100 + activity_id 같은 숫자 ID 규칙이 이벤트의 뜻을 고정한다.
  • 원본은 raw_data, 자리 없는 값은 unmapped에 남겨 정보를 잃지 않는다.
  • OCSF로 로그를 내보내는 국내 장비는 찾기 어렵고 해외 제품도 변환기를 거치는 경우가 많아, 정규화는 수집 허브나 게이트웨이에서 한다.
  • 어떤 활동으로 분류할지는 매핑하는 사람이 정하므로, 매핑 규칙을 문서와 버전으로 관리해야 한다.

참고