도메인 분리 및 보안 인시던트 응답

  • 릴리스 버전: Washingtondc
  • 업데이트 날짜 2024년 02월 01일
  • 읽기9분

    • 보안 인시던트 응답에서는 도메인 분리가 지원됩니다. 도메인 분리를 사용하여 데이터, 프로세스 및 관리 작업을 도메인이라는 논리적 그룹으로 분할할 수 있습니다. 어떤 사용자가 데이터를 보고 액세스할 수 있는지를 포함하여 이러한 분리의 여러 측면을 제어할 수 있습니다.

    지원 수준: 표준

    • 기본 수준 지원을 포함합니다.
    • 비즈니스 논리: 서비스 제공자(SP)가 고객별로 프로세스를 만들거나 수정합니다. 사용 사례는 여러 SP 고객이 단일 인스턴스에서 애플리케이션을 올바르게 사용하는 것을 반영합니다.
    • 인스턴스 소유자는 특정 애플리케이션에 필요한 대로 테넌트별 최소 실행 가능한 제품(MVP) 비즈니스 논리 및 데이터 매개변수를 구성해야 합니다.

    샘플 사용 사례: 관리자가 한 테넌트에 대해서는 기록이 닫히지만 다른 테넌트에 대해서는 기록이 닫히지 않는 경우 설명이 필요하도록 설정할 수 있어야 합니다.

    지원 수준에 대한 자세한 내용은 도메인 분리를 위한 애플리케이션 지원을 참조하십시오.

    개요

    보안 인시던트 응답 애플리케이션에서 도메인 분리를 통해 서비스 제공업체(SP)는 서비스를 제공하는 고객 기반 전체에서 SOC(Security Operations Center) 및 SIR(Security Incident Response) 절차를 표준화하여 운영 비용을 절감하고 서비스 품질을 높일 수 있습니다. 워크플로우, 대시보드, 보고서 등을 위한 별도의 고객 작업 공간을 통해 고객 데이터가 분리되어 다른 클라이언트에 노출되지 않습니다.

    표 1. 버전 릴리스별 Security Incident Response의 도메인 분리 지원
    릴리스 지원 수준 메모
    제네바, 헬싱키 지원 안 함 데이터 수준 도메인 분리 시작
    Istanbul 데이터만
    Jakarta 수준 2(데이터, 요청자, 이행자) 새로운 기능: 타사 통합은 Threat Intelligence 통합을 포함하여 단일 통합 인스턴스에서 레벨 2 도메인 분리를 지원합니다.
    Kingston 수준 2(데이터, 요청자, 이행자) 새로운 기능: SIR에 대한 Sighting Search 통합은 여러 인스턴스에서 활성화되지만 모든 인스턴스는 여전히 단일 도메인에 있습니다. 예: 구성된 Splunk 통합 인스턴스가 두 개 있는 경우(SplunkCLOUD 및 SplunkCORP) 둘 다 구현이 원래 구성된 단일 도메인의 인시던트 응답 활동에 계속 활용됩니다.
    London 수준 2(데이터, 요청자, 이행자) 새로운 기능: 모든 통합은 여러 도메인에 걸쳐 상주합니다.
    Madrid 수준 2(데이터, 요청자, 이행자) 이제 모든 통합이 여러 도메인에 걸쳐 상주할 수 있습니다. 위 예에서 SplunkCloud는 domain1 및 SplunkCORP domain2일 수 있습니다.
    New York 수준 2(데이터, 요청자, 이행자) 모든 통합은 여러 도메인에 걸쳐 상주합니다.
    Orlando 표준 모든 통합은 여러 도메인에 걸쳐 상주합니다.
    Paris 표준 모든 통합은 여러 도메인에 걸쳐 상주합니다.

    애플리케이션의 보안 인시던트 응답 도메인 분리에는 다음과 같은 제품 기능이 포함됩니다.

    • 보안 경고는 ID/자격 증명/범위가 인시던트를 생성하고 보안 인시던트로 등록된 사용자의 적절한 도메인으로 전달됩니다.
    • 경보는 상태 저장 속성 또는 측정 가능한 이벤트를 나타내는 "옵저버블"을 생성합니다. 보안 인시던트 도메인의 보안 워크플로우는 응답을 오케스트레이션하는 데 사용됩니다.
    • 통합은 응답 자동화를 위해 보안 인시던트의 도메인에서 구성됩니다.
    • 기능은 응답 자동화를 위해 보안 인시던트의 도메인에서 구성됩니다. 이러한 기능(Kingston 릴리스 기준)은 다음과 같습니다.
      • 위협 조회
      • 옵저버블 보강
      • 구성 항목 보강
      • 실행 중인 프로세스 가져오기
      • 네트워크 통계 가져오기
      • 블록 요청
      • 호스트 격리
      • 검색 찾기
      • 이메일 검색 및 삭제
      • 주요 업데이트 공유자에 게시
    • 응답 자동화(예: 위협 조회 또는 관찰 검색)의 결과는 보안 인시던트의 도메인에 저장됩니다.
    • 다른 보안 인시던트는 공유된 옵저버블 집합을 기반으로 보안 인시던트의 동일한 도메인에서 상호 참조됩니다.
    • 다른 사용자는 보안 인시던트의 도메인에서 상호 참조됩니다.
    • 구성 항목은 보안 인시던트와 동일한 도메인에서 상호 참조됩니다.
    • 수동 응답 작업이 보안 인시던트의 도메인에 추가됩니다.
    • 지식베이스 문서와 실행서는 보안 인시던트의 도메인에서 참조됩니다.
    • 도메인의 인시던트와 관련된 보안 인시던트 응답 메트릭은 보고 뿐 아니라 대시보드에도 표시됩니다.
    주:
    앞의 경우에는 NOW Platform의 분리된 도메인에서 가시성이라는 가장 중요한 원칙이 적용됩니다. 항상 그렇듯이 상위 도메인의 인시던트는 하위 도메인의 아티팩트를 참조할 수 있지만 그 반대는 불가능합니다.

    Security Incident Response에서 도메인 분리가 작동하는 방식

    애플리케이션은 보안 인시던트 응답 보안 인시던트의 수명 주기를 종단 간 관리합니다. 다음 사용 사례는 도메인 분리를 인식합니다.

    • 고객 SOC 또는 MSP의 분석가에 대한 보안 인시던트를 생성하기 위한 이벤트 및 경고 수집은 다음과 같이 대응합니다.
      • 이메일 파서(플랫폼 기반, 사용자 보고 피싱, 사용자 지정)
      • 인시던트 작성 전 이벤트/경보 중복 제거
      • 옵저버블 자동 추출
      • 타사 SIEM 저장소의 애플리케이션
    • 인시던트와 관련된 아티팩트 보강(IP, URL, 도메인, 파일 해시):
      • 자산 보강(CMDB)
      • 사용자(플랫폼)
      • 자동화: 옵저버블 보강(예: WhoIs)
    • 아티팩트 및 알려진 위협과의 평판 또는 연관성을 활용하여 인시던트를 조사합니다
      • 오케스트레이션: Playbook 및 지식베이스 문서
      • 자동화: 위협 조회(예: VirusTotal), 사이팅 검색(예: Splunk), 실행 중인 프로세스 가져오기(예: Carbon Black)
    • 수행된 조사에 따라 인시던트에 관련된 위협 관련 아티팩트를 근절합니다.
      • 오케스트레이션: Playbook 및 지식베이스 문서
      • 자동화: 이메일 검색 및 삭제(예: Microsoft Exchange), 차단 IP(예: Palo Alto 방화벽)
    • 인시던트 응답 운영 또는 효율성 측정
      • Performance Analytics 대시보드: 생산성 및 인시던트 추세
      • 작업 메모에서 인시던트 조사 단계 재구성
      • 사후 인시던트 검토

    도메인 분리 설정

    에 대한 보안 인시던트 응답 도메인 분리를 설정하는 데는 추가 단계가 필요하지 않습니다. 인스턴스의 도메인이 분리되면 모든 보안 인시던트 응답 테이블이 도메인 열을 획득합니다.

    도메인 분리 데이터

    데이터는 도메인으로 분리될 수 있으며, 이는 다음을 의미합니다.

    • 한 도메인의 보안 인시던트를 다른 도메인에서 볼 수 없습니다.
    • 보안 인시던트에서 추출한 옵저버블은 동일한 도메인에 배치되며 다른 도메인에서 볼 수 없습니다.
    • Kingston 릴리스까지 구성된 타사 통합은 전역 도메인에 존재하며 인스턴스 내 다른 모든 도메인에서 액세스할 수 있습니다.
    • Madrid 릴리스에서는 도메인별로 타사 통합을 구성하고 활성화할 수 있습니다. 즉, 한 도메인에서 활성화되고 구성된 통합을 다른 도메인에서 활용할 수 없습니다.
    • 타사 통합(위협 조사, 억제 또는 근절용)을 사용하여 옵저버블에서 실행되는 자동화는 결과를 보안 인시던트의 도메인에 배치하며 다른 도메인에서 결과를 볼 수 없습니다.
    • 한 도메인에서 만든 오케스트레이션 워크플로우는 다른 도메인에서 볼 수 없습니다.
    • 호출되는 기능(preeding capabilities 기능 목록에 설명된 대로)은 호출되는 기능의 도메인별 구현과 함께 도메인 간에 일반적입니다. 예를 들어, IP에 대한 사이팅 검색은 한 도메인에서 Splunk 구현을 호출하고 다른 도메인에서 QRadar 구현을 호출할 수 있습니다.

    구성

    제품 구성의 모든 측면은 도메인 분리 환경에 자체 포함됩니다. 설정은 개별 도메인에 맞게 조정할 수 있습니다.
    주:
    아래 #2-5의 비즈니스 논리 및 프로세스는 테넌트 도메인 내에서 관리할 수 있습니다.

    다음 작업을 구성해야 합니다.

    1. 시스템 관리
    2. 보안 인시던트 응답 관리
    3. 보안 인시던트 이메일 설정
    4. 보안 인시던트 Playbook 설정
    5. 역량 구성

    테넌트 도메인이 자체 애플리케이션 데이터를 관리하는 방법How tenant domains manage their own application data

    • 테넌트 도메인 소유자는 보안 인시던트를 수집하기 위한 자체 이메일 구문 분석 규칙을 생성합니다.
    • 테넌트 도메인 소유자는 도메인 내에서만 사용할 특정 통합을 구성할 수 있습니다.
    • 테넌트 도메인 소유자는 고유한 인시던트 응답 워크플로우를 만들 수 있습니다.
    • 테넌트 도메인 소유자는 인시던트 응답 범주, 인시던트 응답 지식베이스 문서 및 Runbook을 생성하여 인시던트 응답 워크플로우와 연결할 수 있습니다.
    • 테넌트 도메인 사용자는 자신의 보안 인시던트를 만들고 닫습니다.

    인스턴스 소유자가 도메인 분리할 수 있는 비즈니스 논리 및 프로세스

    • 보안 인시던트 응답 사용자 및 그룹
    • 보안 인시던트 응답 통합(Madrid 릴리스부터)
    • 인시던트 생성을 위한 이메일 구문 분석 규칙
    • 여러 이벤트 또는 경보를 보안 인시던트로 통합하는 비즈니스 규칙
    • 인시던트 응답 오케스트레이션을 위한 워크플로우
    • 보안 인시던트 위험 점수 계산기
    • 보안 인시던트 에스컬레이션 경로
    • 보안 인시던트 SLA
    • 보안 인시던트 프로세스 정의
    • 보안 인시던트 사후 인시던트 검토 프로세스