OCSF는 보안 데이터 레이크를 균등화하는 핵심 요소입니까?
오늘날의 사이버 공격을 감지하고 멈추려면 다양한 보안 도구를 균형 있게 조합해야 합니다. 그러나 보안 로그 데이터를 통합하기 위해 팀이 소비한 시간과 자원은 잠재적인 공격을 찾는 데 필요한 분석을 수행하는 합리적인 비용입니다. OSCF(Open Cybersecurity Schema Framework) 프로젝트는 팀이 분석 소요 시간을 줄이고 환경 보호에 더 많은 시간을 보내도록 만드는 변화를 끌어내려고 합니다. 지금부터 새로운 접근법이 중요하고 시기 적절한 이유에 대해 살펴보겠습니다.
각 로그에 로그 검색, 집계 또는 감지에 사용 가능한 필드를 정의하는 스키마가 있어야만 보안 로그 이벤트 데이터를 유용한 자료로 사용할 수 있습니다. 예를 들어 네트워크 연결 로그에 연결이 시작된 소스 IP 및 요청에 대한 응답을 받고 서비스를 제공하는 목적지 IP가 있고, 스키마에는 src 및 dest와 같은 필드가 있으므로 보안 분석가가 해당 필드에 대한 쿼리를 만들 수 있다는 사실을 파악합니다.
그러나 해당 스키마의 로그 유형이나 도구에 대한 의견이 분분합니다. 같은 예에서 CrowdStrike는 네트워크 로그의 IP 주소를 ip로 목적지를 RemoteAddressIP4로 추출합니다. PAN 방화벽은 소스 IP src 및 목적지 dst를 호출합니다. 일부 로그는 체계적이지 않으며 소스 및 목적지 IP는 로그 이벤트 내의 로그 형식 및 IP 위치를 이해해야만 판단할 수 있습니다.
경우에 따라 분석가는 방대한 로그 하위 집합에 대한 쿼리를 만들기를 원할 수 있습니다. 예를 들어 모든 네트워크 전반에 대해 알고 싶어 하고 특정 IP 주소에 연결된 호스트가 있습니다. 이 경우 각 로그 유형에 대한 스키마가 필요하며 해당 스키마가 일치해야 합니다. 수작업을 줄이고 데이터를 수집 및 분석하는 더 나은 방법이 있다면 금상첨화일 겁니다.
로그 정규화 도전 과제
지금까지 Salesforce는 모든 단일 로그의 단일 필드 전체를 나열하는 정교한 내부 솔루션인 "DDI(Events Data Dictionary)"를 사용하여 이 문제를 해결했으며, 로그를 구문 분석하고 사전을 스키마로 적용하는 DFE(데이터 필드 추출 규칙)을 정의했습니다. 감지 및 대응 아키텍처에서는 "Normalizer"로 명명된 시스템에서 이 프로세스가 발생합니다.
정규화 후 기존의 체계적이지 않은 로그를 포함한 모든 로그에 일치하는 스키마 및 쿼리할 수 있는 필드 집합이 있습니다. CrowdStrike 로그에서 RemoteAddressIP4를 추출하고 이름을 IPDestination으로 변경합니다. 이와 마찬가지로 PAN 로그의 dst가 IPDestination으로 바뀝니다. 분석가는 모든 로그를 쿼리하고 IPDestination == [...]을(를) 질문하여 특정 IP가 연결되었는지 여부를 확인하려는 경우 간단하게 쿼리를 작성합니다.
이상적으로는 놀라운 방법입니다. 분석가가 검색할 수 있습니다. 그러나 로그 정규화 시 자체 도전 과제가 발생합니다.
- 데이터 사전에 수백 개의 필드가 있고 대다수는 NULL이므로 많은 공간을 낭비합니다.
- 새 로그 유형을 가져오면 필드가 앞서 정의한 항목과 일치하지 않고 이상하고 극단적인 사례(예: 로그 유형에 따른 사용자, 사용자 이름, 사용자 이메일은 다른 의미입니다)를 야기합니다.
- regex를 작성하거나 규칙을 구문 분석하여 새 로그 소스를 온보딩하는 일부로 모든 새 로그 유형이나 하위 로그 유형을 수동으로 구문 분석해야 합니다.
- 로그 구조 변경, 필드 추가 또는 교체 시 기존 규칙이 관련 필드의 구문 분석을 빠뜨릴 수 있습니다. 이는 주요 데이터 품질 문제입니다.
- 또한 규칙을 대규모로 승인하거나 추적하는 좋은 방법은 없습니다. 규칙이 복제될 가능성이 높습니다. 규칙 사용 중지는 상당한 위험을 동반하므로 규칙 집합을 유지하거나 업데이트하기 어렵습니다. 이로 인해 새 규칙이 오래된 규칙 기능을 덮어쓰는 역행이 발생할 수 있습니다.
따라서 관련 비용이 많아집니다. 팀은 이벤트 감지 및 대응에 기본적으로 중점을 두는 대신 전제 조건으로 이 데이터의 수동 정규화에 시간을 소비하게 됩니다.
OCSF 채택
OCSF(Open Cybersecurity Schema Framework)는 BlackHat(2022년 8월)에서 오픈 스키마 표준으로 공식 발표되었으며, 여러 사이버 보안 소스의 데이터를 일반화하는 최초의 프로젝트입니다. 이 프레임워크는 공급업체 간 상호 호환되는 간소화된 분류를 전달하여 모든 보안 팀이 많은 시간이 소요되는 사전 정규화 과업 없이 데이터 수집 및 분석을 효율적이고 빠르게 실현하도록 돕기 위해 고안되었습니다.
기존 보안 표준 및 프로세스와 맞으며, 모든 환경, 응용 프로그램, 솔루션 공급자에서 채택할 수 있는 오픈 표준을 확보하는 것을 목표를 삼고 있습니다. OCSF는 데이터 사전 접근법과 유사한 오픈 소스 프레임워크이며, 위에 명시된 두 가지 초기 문제를 해결하고 분석가 사용을 기반으로 도식화되는 필드 하위 집합을 정의하여 접근법으로 인해 야기된 문제점에도 대처하려고 합니다.
최고 신뢰 책임자 Vikram Rao는 다음과 같이 말합니다. "모든 기업이 디지털 전환 압박에 직면해 있습니다. 그러나 인터넷 수준의 디지털 신뢰도를 충족하는 보안 태세를 구축하기란 매우 어렵습니다. OCSF 등 새로운 표준은 복잡성을 줄여 보안 팀이 위협 분석 및 공격 방지와 같이 영향력 있는 작업에 몰두할 수 있도록 만들어 줍니다."
테스트 실행
Salesforce 감지 및 대응 엔지니어링 팀은 OCSF를 평가하고 Salesforce 생성 로그에 이 스키마를 적용하고, 이벤트 데이터 사전의 사용자 정의된 스키마 대신 OCSF 정의 스키마를 사용하여 출력 로그에 현재 정규화 접근법을 도입할지 고려했습니다.
OCSF를 정확히 이해하기 위해 먼저 가상 Salesforce 보안 감지 이벤트를 OCSF 형식으로 전환 및 평가하는 활동을 진행했습니다. 다음은 현재 DDI 형식 및 OCSF 형식을 비교한 스크린샷입니다.
활동을 진행하고 OCSF 스키마를 살펴보는 동안 잠재적으로 사용할 수 있는 흥미로운 필드를 발견했습니다. 예를 들어 정정 조치 개체의 경우 이 필드는 사고를 분류하는 동안 분석가 다운스트림에 유용하고 추가 조치 수행을 지원하는 설명 및 Knowledge 자료 기사를 연결하는 데 도움이 됩니다.
내부 팀과의 작업 및 결국 OCSF 호환 로그 프로듀서가 되는 내부 응용 프로그램 로그 sfdc_applog의 변환 프로토타이핑, 평가에 많은 힘을 기울였습니다. 앞으로도 계속해서 협력해 주시기를 바라겠습니다. 공동 작업을 진행하고 이 스키마를 사용하여 로그를 표준화하려는 경우 OCSF GitHub [여기]에서 시작하고 원하는 방향으로 나아갈 수 있습니다.
박수갈채
오픈 사이버 보안 스키마 프레임워크 프로젝트는 공급업체 중립 프레임워크에서 데이터 분류를 간소화하여 보안 팀이 데이터 정규화에 소요되는 시간을 줄이고 방어에 더 많은 시간을 보내도록 돕기 위해 고안되었습니다. OCSF를 위해 contributions from Cloudflare, CrowdStrike, DTEX, IBM Security, IronNet, JupiterOne, Okta, Palo Alto Networks, Rapid7, Salesforce, Securonix, Sumo Logic, Tanium, Trend Micro, Zscaler에서 많은 노력을 기울였습니다.
Salesforce는 OCSF의 초기 채택자로서 흥미로운 여정을 이어왔습니다. 초창기에 몇 가지 상위 로그 유형 이벤트를 OCSF로 변환했습니다. 이는 위대한 첫 걸음이었고 다양한 내부 팀이 참여하여 프레임워크 및 행방을 파악하는 데 도움을 주었습니다. OCSF는 여러 이해당사자들이 표준을 채택하고 발전을 지원한 보안 분야의 오픈 표준이자 공동의 노력이 맺은 결과물이며, 모든 조직에서 보안 데이터 레이크를 균등화하는 가능성을 제시합니다.
마지막으로 OCSF가 가장 큰 영향을 미치기 위해서는 클라우드 공급자 및 보안 공급업체가 로그를 OCSF 스키마로 정렬 및 제공해야 합니다. 이 분야에 있는 모든 분들이 한계를 없애고 OCSF를 보안 커뮤니티의 표준으로 만드는 일에 협력해 주실 것을 부탁드립니다.