SIEM 기본 사항 (1부): 가장 먼저 해결해야 할 데이터 수집 문제

소개이 시리즈의 목표는 독자들에게 SIEM에 대해 올바른 사고방식을 갖도록 하고 성공하기 위해 어떻게 준비해야 하는지를 설명하는 것입니다. 저는 데이터 과학자는 아니며 그렇게 주장하지 않지만, ‘좋은 데이터’가 없이는 보안 분석에서 결과를 기대하는 것이 무모하다고 확신합니다. 그래서 저는 항상 ‘보안 분석은 무엇보다도 데이터 수집 문제이다’라고 말하며 SIEM 기초 블로그의 1부가 데이터 수집 접근법에 초점을 둔 이유입니다.

(이미지 출처 – https://thelead.io/data-science/5-steps-to-a-data-science-project-lifecycle)이 이미지는 많은 데이터 과학자들이 프로젝트를 계획할 때 활용하는 OSEMN 프레임워크의 시각화입니다. 팀이 데이터를 정보로 변환하는 방법이며, SIEM 사용의 전체 목적은 데이터를 저장하는 것이 아니라, 보안을 개선할 수 있는 새롭고 유용한 정보를 생성하는 것입니다.

데이터를 수집하고 정리하는 것은 간단하지 않습니다. 사실, 많은 데이터 과학자들은 이러한 각 단계를 별개의 전문 분야나 영역으로 봅니다. 이러한 것을 이해하지 못하는 이유는 많은 팀들이 SIEM에서 가치를 찾지 못하는 이유이기도 합니다; 모든 마케팅 과대 광고는 프로세스의 각 단계마다 최종 사용자가 얼마나 많은 노력을 기울여야 하는지를 간과하게 쉽기 때문이며 이는 환경과 위협 환경이 변화함에 따라 좋은 팀이 지속적으로 반복하는 것입니다.

ETL에 대해 잠시 얘기해보겠습니다. 이는 다음 섹션 중 일부를 설명하는 데 도움을 줍니다.

1. 추출 – 실제로 데이터 소스가 특정 형식으로 로그를 출력하게 하는 것입니다. 이 단계는 구성을 통해 새로운 원본 데이터를 데이터 세트에 도입할 수 있는 유일한 단계임을 유의해야 합니다.
   • 예: 특정 형식(키-값 쌍 또는 쉼표로 구분된 목록)을 가진 원격 syslog를 사용하여 로그 소스를 ‘X, Y, Z’ 필드를 보고하도록 구성
2. 변환 – 데이터의 형식과 구조를 더 잘 맞추기 위해 수정하는 것입니다.
   • 예: JSON 로그 파일을 구문 분석 파일, 매핑 파일, 사용자 정의 스크립트 등을 사용하여 별개의 일반 텍스트 이벤트로 구문 분석
3. 적재 – 데이터를 데이터베이스에 기록하는 것
   • 예: 소프트웨어를 사용하여 일반 텍스트 이벤트를 해석하고 데이터를 데이터베이스에 INSERT 문 또는 기타 공개 API로 보내기
4. 적재 후 변환 – ETL 프로세스의 공식적인 부분은 아니지만, SIEM의 매우 현실적인 구성 요소입니다.
   • 예: 데이터 모델링, 필드 추출 및 필드 별칭 사용

획득데이터 수집은 소규모에서는 간단합니다. 그러나 SIEM은 소규모가 아니며, 신뢰할 수 있는 관련 데이터를 어떻게 획득할 수 있는지 파악하는 것이 중요합니다.신뢰할 수 있는 전달이 섹션에서는 추출과 적재에 초점을 맞추겠습니다.

• 추출
  • 내 데이터 소스는 어떤 출력을 할 수 있는가?
  • 어떤 필드와 형식을 사용할 수 있는가?
  • 어떤 전송 방법이 가능한가?
  • 이 장치가 리스너로 데이터를 ‘푸시’할 수 있는가, 아니면 요청을 통해 ‘풀’어야 하는가?
• 적재
  • 어떻게 데이터를 적시에 신뢰성 있게 전달할 수 있는가?
  • 리스너가 다운되면 어떻게 되는가? 중단 중에 푸시된 데이터를 놓칠까?
  • 풀 요청이 성공적으로 완료되도록 어떻게 보장할 것인가?

SIEM 세계에서는 종종 ‘추출’ 기능이 ‘적재’ 기능과 함께 제공됩니다. 특히 추가 소프트웨어(커넥터, 비트, 에이전트)가 사용될 때 특히 그렇습니다.

그러나 이 둘 사이에는 ‘이벤트 브로커‘가 위치합니다. 데이터가 네트워크를 통해 전달되어야 하기 때문에, 이벤트 브로커는 로드 밸런싱, 이벤트 캐싱 및 큐잉을 처리할 수 있는 Kafka 및 Redis와 같은 기술입니다. 때때로 이벤트 브로커는 타겟 스토리지에 실제로 데이터를 기록하는 데 사용될 수 있지만, 일종의 데이지 체인 방식으로 전통적인 ‘로더’로 출력될 수도 있습니다.

이러한 요소들에 대해 파이프라인을 구축하는 올바른 방법이나 잘못된 방법은 실제로 없습니다. 대부분은 사용하는 SIEM 기술에 의해 결정됩니다. 그러나 이러한 것들이 어떻게 작동하는지 알고 있으며 공학적 솔루션을 통해 각자의 고유한 문제를 해결할 준비가 되어 있어야 합니다.로그 소스 선택SIEM 공급업체가 그렇다고 해서 마구잡이로 데이터를 수집하지 마십시오. 항상 계획을 세우고 선택한 데이터 수집에 대한 타당한 이유를 가지고 있어야 합니다. 이 시점에서 ‘관련성 있는 데이터’를 선택할 때 스스로 다음과 같은 질문을 해야 합니다.

1. 정보 이해
   • 이 활동을 통해 어떤 활동을 가시적으로 볼 수 있습니까?
   • 이 데이터 소스는 얼마나 권위 있는가?
   • 이 데이터 소스가 필요한 모든 가시성을 제공합니까, 아니면 추가적인 소스가 필요합니까?
   • 이 데이터를 사용하여 다른 데이터 세트를 강화할 수 있습니까?
2. 관련성 판단
   • 이 데이터가 보안 정책에 의해 설정된 정책, 표준 또는 목표를 충족하는 데 어떻게 도움이 될 수 있습니까?
   • 이 데이터가 특정 위협 / 위협 행위자 탐지를 어떻게 향상할 수 있습니까?
   • 이 데이터를 사용하여 기존 운영에 대한 새로운 통찰을 어떻게 생성할 수 있습니까?
3. 완전성 측정
   • 디바이스가 우리가 원하는 형식으로 필요한 데이터를 이미 제공합니까?
   • 그렇지 않다면, 구성할 수 있습니까?
   • 데이터 소스가 최대 장황도를 위해 구성되어 있습니까?
   • 이 데이터 소스를 유용하게 만들기 위해 추가적인 보강이 필요합니까?
4. 구조 분석
   • 데이터가 인간 읽기 가능한 형식입니까?
     • 이 데이터가 읽기 쉬운 이유는 무엇이며 동일한 유형의 데이터에 이와 유사한 형식을 채택해야 합니까?
   • 데이터가 기계 읽기 가능한 형식입니까?
     • 파일 형식은 어떠한가, 기계가 이 파일 형식을 어떻게 해석할 것인가?
   • 데이터는 어떻게 제공됩니까?
     • 키-값 형식인가, 쉼표로 구분된 형식인가, 아니면 다른 것인가?
   • 이 형식에 대한 좋은 문서가 있습니까?

정보 이해에서 발생하는 일반적인 문제는 로그 소스 자체와 네트워크 아키텍처에 대한 내부 문서화 부족 또는 전문성 부족에서 비롯됩니다. 적절성을 판단하려면 보안 전문가와 정책 소유자의 입력이 필요합니다. 모든 경우에, 경험이 풍부하고 지식이 있는 인력이 초기에 참여하는 것이 전체 작업에 유리합니다.삭제이제 더 흥미로운 데이터 스크러빙 주제로 넘어가 봅시다. 익숙하지 않으면 다음과 같은 질문을 자신에게 던지게 될지도 모릅니다:

• 안녕하세요, 그냥 작동해야 하지 않나요?
• 데이터가 이미 깨끗하지 않은 이유는 무엇인가요? 기술자가 데이터에 커피를 쏟았나요?
• 위생은 개인적인 문제 같은데 – 이것에 대해 HR이 의견을 내야 하나요?

현실은 기계가 훌륭하지만, 지식이 부족하다는 것입니다(*아직까지는). 그들이 가진 유일한 지식은 우리가 그들에게 구축한 지식입니다.예를 들어, 사람은 ‘Rob3rt’라는 텍스트를 보고 ‘Robert’를 의미한다는 것을 이해할 수 있습니다. 그러나 기계는 영어에서 숫자 ‘3’이 종종 문자 ‘e’를 나타낼 수 있다는 것을 사전 지식으로 제공받지 못하면 알지 못합니다. 더 실생활에 가까운 예는 ‘3000’ vs ‘3,000’ vs ‘3K’와 같은 형식 차이를 처리하는 것입니다. 우리는 모두 같은 의미라는 것을 알지만, 기계는 ‘3,000’의 ‘,’에 걸리고 ‘K’를 ‘000’으로 해석하지 못합니다.SIEM의 경우, 이는 로그 소스 전반에 걸쳐 데이터를 분석할 때 중요합니다.예제 1 – 예시 A

이 예제에서는 ‘필드 이름’과 ‘필드 데이터’가 로그 소스 ‘웹 프록시’와 ‘NGFW’ 간에 다르다는 것을 확인할 수 있습니다. 이 형식으로 복잡한 사용 사례를 구축하려고 시도하는 것은 매우 어렵습니다. 다음은 문제점 차이의 분석입니다:

1. 타임스탬프: 웹 프록시는 Epoch(Unix) 형식을 사용하고 NGFW는 Zulu(ISO 8601) 형식을 사용합니다.
2. 소스 IP: 웹 프록시에는 IPv4 주소가 있고 NGFW에는 IPv4-매핑 IPv6 주소가 있습니다.
3. 소스 호스트: 웹 프록시는 FQDN을 사용하고 NGFW는 사용하지 않습니다.
4. 요청 URL: 프록시는 전체 요청을 사용하고 NGFW는 도메인만 사용합니다.
5. 트래픽/작업: 프록시는 ‘허용됨’을 사용하고 NGFW는 ‘승인됨’을 사용합니다.

이것은 실제 필드 이름이 다른 것에 추가된 것입니다. 스크러빙이 부실한 NoSQL 데이터베이스에서는 Alpha 로그를 찾기 위해 사용되는 쿼리 용어가 Beta 로그를 사용할 때 크게 달라집니다.

이 점을 충분히 강조하지 않았더라도, 샘플 탐지 사용 사례를 살펴보겠습니다:

• 사용 사례: 사용자 성공적으로 알려진 악성 웹사이트 방문 탐지.
• 환경: 웹 프록시는 NGFW 앞에 위치하며 웹 트래픽을 처음으로 보는 장치입니다.
• 주의사항
  • 웹 프록시와 NGFW는 동일한 차단 목록을 갖고 있지 않습니다. 웹 요청은 웹 프록시를 통해 통과할 수 있지만 나중에 NGFW에 의해 거부될 수 있습니다.
  • 요청은 비투명한 방식으로 프록시에서 NGFW로 전달됩니다. 즉, 소스 IP 및 호스트 이름이 웹 프록시의 IP 및 호스트 이름으로 대체되며 NGFW 로그만 분석하면 요청의 실제 소스를 알 수 없습니다.
• 설명:
  • 이 예에서 ‘악성’은 SIEM에 저장된 알려진 악성 URL의 조회 테이블과 URL을 비교하는 일종의 변수라고 가정합니다.

쿼리는 다음과 같이 보일 것입니다:

• SELECT RQ_URL, SRC_IP, SRC_HST
  WHERE Device == NGFW AND RQ_URL = Malicious AND Action = Permitted
• SELECT Request URL, Source IP, Source Host,
  WHERE Device == Web Proxy AND Request URL = Malicious AND Traffic = Accepted

하지만, 알려진 주의사항을 고려하면 단일 쿼리의 결과를 분석하는 것은 다음과 같은 데이터를 제공할 뿐입니다:

• NGFW – 궁극적인 차단/거부 상태는 알려져 있습니다. 실제 소스는 알 수 없습니다.
• 웹 프록시 – 궁극적인 차단/거부 상태는 알 수 없습니다. 실제 소스는 알려져 있습니다.

우리는 이제 동일한 기간에 발생한 두 이벤트에 따라 ‘최선의 추측’일 뿐인 어떤 불확실한 타임스탬프 논리를 사용하여 결합해야 하는 2개의 관련 정보를 가지고 있습니다 (휴).어떻게 고칠까요?앞서 나왔던 것들을 기억하시나요?

• 변환 – 데이터의 형식과 구조를 더 잘 맞추기 위해 수정하는 것입니다.
  • 예: 구분 파일, 매핑 파일, 사용자 정의 스크립트 등을 사용하여 JSON 로그 파일을 개별 일반 텍스트 이벤트로 구문 분석
• 적재 후 변환 – ETL 프로세스의 공식적인 부분은 아니지만, SIEM의 매우 현실적인 구성 요소입니다.
  • 예: 데이터 모델링, 필드 추출 및 필드 별칭 사용

설명할 수 있는 모든 기술과 옵션이 너무 많지만 변환 기술을 이해하기 위한 기본 용어를 다뤄보겠습니다:

• 구성 – 기술적으로 변환 기술은 아니지만, 일반적으로 데이터 구조 및 형식 문제를 해결하는 가장 좋은 방법입니다. 소스에서 문제를 해결하고 나머지는 건너뛰세요.
• 파싱/필드 추출 – 정규 표현식(regex)을 사용하여 문자열을 패턴에 따라 문자(또는 문자열 그룹)로 분할하는 변환 작업(수집 전). 구조가 고정되어 있는 경우 동적 값을 잘 처리하지만, 와일드카드가 너무 많으면 성능 저하를 초래할 수 있습니다.
• 매핑 – 정적 입력 및 출력 라이브러리를 사용하는 변환 작업. 필드 이름 및 값을 할당하는 데 사용할 수 있습니다. 동적 입력을 잘 처리하지 않습니다. 그러나 매핑 테이블이 작을 경우 파싱보다 효율적일 수 있습니다.
• 필드 별칭 – 매핑과 유사하지만 적재 후 발생하며 반드시 SIEM에 저장된 실제 내용을 변경하지 않습니다.
• 데이터 모델 – 필드 별칭과 유사하며 검색 시 발생합니다.
• 필드 추출 – 파싱과 비슷하며 플랫폼에 따라 수집 전 또는 수집 후 발생할 수 있습니다.

일련의 구문 분석기를 생성하여 공통 필드 스키마를 적용하고, ‘허용됨’에서 ‘승인됨’으로 트래픽 필드를 매핑하고, 웹 프록시가 원본 소스 IP 및 호스트를 전달하도록 구성하고, NGFW가 FQDN과 함께 호스트 이름을 기록하도록 구성하고, 타임스탬프를 변환하고 IPv4 주소를 추출하는 함수를 사용했다고 가정해 봅시다. 우리의 데이터는 이제 다음과 같이 보입니다:예제 1 – 예시 B

NGFW가 단순히 DNS 해상을 통해 소스에서 보강된 전체 요청 URL을 제공하지 못한다고 가정해 봅시다. 우리의 ‘이상적인 의사 논리’는 이제 다음과 같습니다:

• SELECT 소스 IPv4, 소스 FQDN, 요청 URL
  WHERE 장치 == NGFW AND 요청 URL == 악성 AND 트래픽 == 승인됨

프록시를 올바르게 소스 정보를 전달하도록 구성했기 때문에 더 이상 두 데이터 소스와 불확실한 타임스탬프 논리에 의존할 필요가 없습니다. 또한 공통으로 형식화된 소스 정보를 입력으로 사용하여 조회 테이블과 일부 세련된 논리를 사용하면 트래픽과 관련된 전체 요청 URL이 무엇인지 쉽게 파악할 수 있습니다.예제 2마지막 예로, 네트워크 전반에서 승인된 악성 웹 트래픽을 보여주는 보고서를 만들고 싶다고 가정해 봅시다; 하지만 Segment A의 트래픽만 웹 프록시를 통과하고 Segment B의 트래픽만 NGFW를 통과합니다.

잘못된 데이터 스크러빙으로 만들어진 쿼리는 다음과 같습니다:

• SELECT 요청 URL, RQ_URL, 소스 IP, SRC_IP, 소스 호스트, SRC_HST
  WHERE (요청 URL = 악성 AND 트래픽 = 승인됨) OR (RQ_URL = 악성 AND 작업 = 승인됨)

올바른 데이터 스크러빙으로 만들어진 쿼리는 다음과 같습니다:

• SELECT 요청 URL, 소스 IPv4, 소스 FQDN,
  WHERE 요청 URL = 악성 AND 트래픽 = 승인됨

공통 형식, 스키마 및 값 유형은 쿼리 성능을 향상시키고 검색 및 컨텐츠 구축을 훨씬 더 쉽게 만듭니다. 기억해야 할 필드 이름의 집합이 제한되어 있으며 필드 값은 대부분 NGFW의 요청 URL을 제외하고는 동일하게 보일 것입니다.

이 점을 충분히 강조하지 않았더라도, 신속한 분석 및 컨텐츠 개발에 있어 얼마나 우아하고 효과적인지를 강조할 수 없습니다.결론효과적인 SIEM 사용에는 (a) 계획, (b) 강력한 기능 간 협업, (c) 데이터를 초기부터 구조화하려는 명확한 의도가 필요하다는 것을 매우 장황하게 설명한 것입니다. 초기 단계에 투자하는 것은 나중에 빠른 승리를 얻도록 설정합니다.

이 기사를 재미있게 보셨다면 다른 사람들과 공유해 주시고 ‘SIEM 기본사항 (2부): 알림 사용, 대시보드, 및 보고서 효과적으로 사용하기‘을 주목해주시기 바랍니다. 이 기사를 정말 좋아하셨고 지원을 보여주고 싶으시다면, 위협 탐지 마켓플레이스(무료 SIEM 컨텐츠), ECS 프리미엄 로그 소스 팩(Elastic용 데이터 스크러버) 및 예측 유지보수(여기에서 논의된 데이터 수집 문제 해결)를 확인할 수 있습니다.