5단계. 사용 사례 개발 및 테스트
적용 대상:
- Microsoft Defender XDR
SOC(보안 운영 센터)에 Microsoft Defender XDR 배포하는 권장 방법은 SOC 팀의 현재 도구, 프로세스 및 기술 집합에 따라 달라집니다. 수백 개의 보안 원본이 아닌 경우 수십 개의 데이터로 인해 플랫폼 간에 사이버 위생을 유지하는 것은 어려울 수 있습니다.
보안 도구는 상호 관련되어 있습니다. 보안 기술에서 하나의 기능을 켜거나 프로세스를 변경하면 다른 기능이 중단됩니다. 이러한 이유로 SOC 팀이 사용 사례를 정의하고 우선 순위를 지정하는 방법을 공식화하는 것이 좋습니다. 사용 사례는 다양한 팀에서 SOC 작업에 대한 요구 사항 및 테스트 프로세스를 정의하는 데 도움이 됩니다. 메트릭을 캡처하여 올바른 역할과 작업의 혼합이 올바른 기술 집합으로 올바른 팀에 정렬되는지 확인하는 방법을 만듭니다.
사용 사례 프로세스 개발 및 공식화
SOC는 SOC 감독 팀에서 규제하는 사용 사례를 개발하기 위한 높은 수준의 표준 및 프로세스를 정의해야 합니다. SOC 감독 팀은 비즈니스, IT, 법률, HR 및 기타 그룹과 협력하여 SOC 팀의 Runbook 및 플레이북으로 전환할 SOC에 대한 사용 사례의 우선 순위를 지정해야 합니다. 사용 사례의 우선 순위는 규정 준수 또는 개인 정보 보호와 같은 목표를 기반으로 합니다.
사용 사례 개발과 관련된 SOC 감독 활동은 다음과 같습니다.
- 요구 사항
- 인력 배치 또는 교육 요구 사항
- 소프트웨어 라이선스
- 공급업체 계약
- 계획 관리
- 사용 사례 레지스트리 유지 관리
- 템플릿 유지 관리/업데이트
Runbook 및 플레이북 만들기 프로세스를 용이하게 하려면 사용 사례 의사 결정 트리를 만듭니다. 이 그림에서는 예제를 보여줍니다.
상위 수준의 사용 사례 표준이 정의되고 승인되면 다음 단계는 실제 사용 사례를 만들고 테스트하는 것입니다. 다음 섹션에서는 피싱 방지 및 위협 및 취약성 검사 시나리오를 예로 사용합니다.
사용 사례 예제 1: 새 피싱 변형
사용 사례를 만드는 첫 번째 단계는 스토리 보드를 사용하여 워크플로를 간략하게 설명하는 것입니다. 다음은 위협 인텔리전스 팀에 대한 새로운 피싱 익스플로잇 알림을 위한 고급 스토리 보드의 예입니다.
사용 사례 워크플로 호출(예: 1)
스토리 보드가 승인되면 다음 단계는 사용 사례 워크플로를 호출하는 것입니다. 다음은 피싱 방지 캠페인의 예제 프로세스입니다.
사용 사례 예제 2: 위협 및 취약성 검사
사용 사례를 사용할 수 있는 또 다른 시나리오는 위협 및 취약성 검사용입니다. 이 예제에서 SOC는 자산 검사를 포함하는 승인된 프로세스를 통해 자산에 대한 위협 및 취약성을 수정해야 합니다.
다음은 자산 Microsoft Defender 취약성 관리 대한 대략적인 스토리보드의 예입니다.
사용 사례 워크플로 호출(예: 2)
위협 및 취약성 검사를 위한 예제 프로세스는 다음과 같습니다.
사용 사례 출력 및 학습된 단원 분석
사용 사례를 승인하고 테스트한 후에는 사용자, 프로세스 및 관련된 Microsoft Defender XDR 기술과 함께 보안 팀 간의 격차를 식별해야 합니다. Microsoft Defender XDR 기술을 분석하여 원하는 결과를 달성할 수 있는지 확인해야 합니다. 검사 목록 또는 행렬을 통해 추적할 수 있습니다.
예를 들어 피싱 방지 시나리오 예제에서 SOC 팀은 이 테이블에서 검색을 수행했을 수 있습니다.
| SOC 팀 | 요구 사항 | 요구 사항을 충족하는 사람 | 요구 사항을 충족하는 프로세스 | 관련 기술 | 갭 식별됨 | 사용 사례 변경 로그 | 제외(Y/N) |
|---|---|---|---|---|---|---|---|
| 위협 인텔리전스 및 분석 팀 | 데이터 원본이 위협 인텔리전스 엔진을 제대로 공급하고 있습니다. | 위협 인텔리전스 분석가/엔지니어 | 데이터 피드 요구 사항 설정, 승인된 원본의 위협 인텔리전스 트리거 | Microsoft Defender for Identity, 엔드포인트용 Microsoft Defender | 위협 인텔리전스 팀은 자동화 스크립트를 사용하여 Microsoft Defender XDR API를 위협 인텔 엔진과 연결하지 않았습니다. | 위협 엔진에 데이터 원본으로 Microsoft Defender XDR 추가 사용 사례 실행 책 업데이트 |
N |
| 모니터링 팀 | 데이터 원본이 모니터링 대시보드에 제대로 공급되고 있습니다. | 계층 1,2 SOC 분석가 -모니터링 & 경고 | 보안 & 규정 준수 센터 보안 점수를 보고하기 위한 워크플로 |
Microsoft Defender XDR 경고 조사 보안 점수 모니터링 |
SOC 분석가가 보안 점수를 개선하기 위해 성공적인 새 피싱 변형 검색을 보고하는 메커니즘이 없습니다. | 보고 워크플로에 보안 점수 개선 사항을 추적하기 위한 프로세스 추가 | N |
| 엔지니어링 및 SecOps 팀 | 변경 제어 업데이트는 SOC 팀 Runbook에서 이루어집니다. | 계층 2 SOC 엔지니어 | SOC 팀 Runbook에 대한 제어 알림 절차 변경 | 보안 디바이스에 대한 승인된 변경 내용 | SOC 보안 기술에 대한 Microsoft Defender XDR 연결을 변경하려면 승인이 필요합니다. | SOC Runbook에 Microsoft Defender for Cloud Apps, Defender for Identity, 엔드포인트용 Defender, 보안 & 규정 준수 센터 추가 | Y |
또한 SOC 팀은 위에서 설명한 Defender 취약성 관리 시나리오와 관련하여 아래 표에 설명된 검색을 수행할 수 있습니다.
| SOC 팀 | 요구 사항 | 요구 사항을 충족하는 사람 | 요구 사항을 충족하는 프로세스 | 관련 기술 | 갭 식별됨 | 사용 사례 변경 로그 | 제외(Y/N) |
|---|---|---|---|---|---|---|---|
| SOC 감독 | 승인된 네트워크에 연결된 모든 자산이 식별되고 분류됩니다. | SOC 감독, BU 소유자, 애플리케이션 소유자, IT 자산 소유자 등 | 위험에 따라 자산 범주 및 특성을 검색하고 나열하는 중앙 집중식 자산 관리 시스템입니다. | ServiceNow 또는 기타 자산. Microsoft 365 디바이스 인벤토리 |
자산의 70%만이 발견되었습니다. Microsoft Defender XDR 수정 추적은 알려진 자산에만 유효합니다. | Microsoft Defender XDR 100% 적용 범위가 있는지 확인하기 위한 성숙한 자산 수명 주기 관리 서비스 | N |
| 엔지니어링 & SecOps Teams | 자산의 높은 영향 및 중요한 취약성은 정책에 따라 수정됩니다. | SecOps 엔지니어, SOC 분석가: 취약성 & 규정 준수, 보안 엔지니어링 | 고위험 및 위험 취약성을 분류하기 위한 정의된 프로세스 | Microsoft Defender 취약성 관리 대시보드 | 엔드포인트용 Defender는 Microsoft 권장 활동의 수정 계획 또는 구현이 없는 높은 영향, 높은 경고 디바이스를 확인했습니다. | 정책당 30일 이내에 수정 작업이 필요할 때 자산 소유자에게 알리기 위한 워크플로를 추가합니다. 자산 소유자에게 수정 단계를 알리는 발권 시스템을 구현합니다. | N |
| Teams 모니터링 | 위협 및 취약성 상태 회사 인트라넷 포털을 통해 보고됨 | 계층 2 SOC 분석가 | 자산의 수정 진행률을 보여 주는 Microsoft Defender XDR 자동 생성된 보고서 |
Microsoft Defender XDR 경고 조사 보안 점수 모니터링 |
자산의 위협 및 취약성 상태 대한 보기 또는 dashboard 보고서가 자산 소유자에게 전달되지 않습니다. | Create 자동화 스크립트는 organization 대한 고위험 및 중요한 자산 취약성 수정의 상태 채웁 수 있습니다. | N |
이러한 예제 사용 사례에서 테스트는 각 팀의 책임에 대한 기준선으로 설정된 SOC 팀의 요구 사항에 몇 가지 차이를 드러냈습니다. 사용 사례 검사 목록은 SOC 팀이 새 SOC 또는 기존 SOC 요구 사항과 Microsoft Defender XDR 통합할 준비가 되었는지 확인하는 데 필요한 만큼 포괄적일 수 있습니다. 이 프로세스는 반복 프로세스이므로 사용 사례 개발 프로세스 및 사용 사례 출력 콘텐츠는 자연스럽게 학습된 단원을 통해 SOC의 Runbook을 업데이트하고 완성하는 역할을 합니다.
프로덕션 Runbook 및 플레이북 업데이트
모든 간격에 대한 사용 사례 테스트가 수정되면 학습된 단원과 수집된 메트릭을 SOC 팀의 프로덕션 Runbook(운영 프로세스) 및 플레이북(인시던트 응답 및 에스컬레이션 절차)에 통합할 수 있습니다.
SOC 팀 Runbook 및 플레이북의 유지 관리는 다양한 방법으로 구성할 수 있습니다. 각 SOC 팀은 자체 책임을 져야 하거나 모든 팀이 중앙 리포지토리에서 공유할 수 있는 단일 중앙 집중식 버전이 있을 수 있습니다. 개별 조직에 대한 Runbook 및 플레이북 관리는 업무의 크기, 기술 집합, 역할 및 분리를 기반으로 합니다. Runbook이 업데이트되면 플레이북 업데이트 프로세스를 따라야 합니다.
에스컬레이션에 표준 프레임워크 사용
플레이북은 사용 사례의 성공적인 통합 및 테스트에 따라 SOC 팀이 실제 이벤트가 발생할 때 따라야 하는 단계입니다. 따라서 SOC는 인시던트 대응을 위한 업계 최고의 표준 중 하나가 된 NIST 인시던트 대응 표준 과 같은 인시던트 대응에 대한 공식화된 접근 방식을 따르는 것이 필수적입니다.
NIST 4단계 인시던트 대응 프로세스에는 다음 4단계가 포함됩니다.
- 준비
- 검색 및 분석
- 포함, 제거 및 복구
- 인시던트 후 활동
예: 준비 단계 작업 추적
에스컬레이션 플레이북의 핵심 기초 중 하나는 각 SOC 팀이 이벤트 또는 인시던트 이전, 도중 및 후에 수행해야 하는 일에 대해 모호성이 거의 없도록 하는 것입니다. 따라서 단계별 지침을 나열하는 것이 좋습니다.
예를 들어 준비 단계에는 작업의 if/then 또는 XoR 행렬이 포함될 수 있습니다. 새 피싱 변형 예제 사용 사례의 경우 이러한 행렬은 다음과 같을 수 있습니다.
| 에스컬레이션이 보증되는 이유는 무엇인가요? | 다음 단계 |
|---|---|
| 위험 트리거 500/시간으로 평가된 > SOC 모니터링의 경고 | 플레이북 A, 섹션 2, 활동 5(플레이북 섹션에 대한 링크 포함)로 이동합니다. |
| eCommerce에서 잠재적인 DDoS 공격을 보고했습니다. | 플레이북 B-섹션 C, 활동 19 호출(플레이북 섹션에 대한 링크 포함) |
| 임원은 스피어 피싱 시도로 의심스러운 이메일을보고 | 플레이북 5, 섹션 2, 활동 5(플레이북 섹션에 대한 링크 포함)로 이동합니다. |
준비 단계를 실행한 후 조직은 NIST에서 설명한 대로 나머지 단계를 호출해야 합니다.
- 검색 및 분석
- 포함, 제거 및 복구
- 인시던트 후 활동
다음 단계
팁
더 자세히 알아보고 싶으신가요? 기술 커뮤니티: Microsoft Defender XDR Tech Community의 Microsoft 보안 커뮤니티와 Engage.