# 프로세스
<a name="process"></a>

 철저하고 명확하게 정의된 인시던트 대응 프로세스를 개발하는 것은 성공적이고 확장 가능한 인시던트 대응 프로그램의 핵심입니다. 보안 이벤트가 발생하면 명확한 단계 및 워크플로가 적시에 대응하는 데 도움이 됩니다. 기존 인시던트 대응 프로세스가 이미 있을 수 있습니다. 현재 상태에 관계없이 인시던트 대응 프로세스를 정기적으로 업데이트, 반복, 테스트하는 것이 중요합니다.

# 인시던트 대응 계획 개발 및 테스트
<a name="develop-and-test-incident-response-plan"></a>

 인시던트 대응을 위해 작성해야 할 첫 번째 문서는 *인시던트 대응 계획*입니다. 인시던트 대응 계획은 인시던트 대응 프로그램 및 전략의 기초가 되도록 설계되었습니다. 인시던트 대응 계획은 일반적으로 다음 섹션을 포함하는 개요 수준의 문서입니다.
+ **인시던트 대응 팀 개요** - 인시던트 대응 팀의 목표와 기능을 간략하게 설명합니다.
+ **역할 및 책임** - 인시던트 대응 이해관계자를 나열하고 인시던트 발생 시 해당 이해관계자의 역할을 자세히 설명합니다.
+ **커뮤니케이션 계획** - 연락처 정보 및 인시던트 발생 시 커뮤니케이션 방법을 자세히 설명합니다.

   인시던트 커뮤니케이션의 백업으로 대역 외 통신을 사용하는 것이 모범 사례입니다. 안전한 대역 외 통신 채널을 제공하는 애플리케이션의 예는 [AWS Wickr](https://aws.amazon.com/wickr/)입니다.
+ **인시던트 대응 단계 및 수행할 조치** - 인시던트 대응의 단계(예: 탐지, 분석, 근절, 방지, 복구)를 열거합니다. 여기에는 해당 단계 내에서 취해야 할 상위 수준 조치가 포함됩니다.
+ **인시던트 심각도 및 우선순위 정의** - 인시던트의 심각도를 분류하는 방법, 인시던트의 우선순위를 지정하는 방법, 심각도 정의가 에스컬레이션 절차에 미치는 영향을 자세히 설명합니다.

 이러한 섹션은 규모 및 업종이 다른 회사 간에 공통적으로 사용되지만 각 조직의 인시던트 대응 계획은 고유합니다. 조직에 가장 적합한 인시던트 대응 계획을 수립해야 합니다.

# 아키텍처 다이어그램 문서화 및 중앙 집중화
<a name="document-and-centralize-architecture-diagrams"></a>

 보안 이벤트에 빠르고 정확하게 대응하려면 시스템과 네트워크가 어떻게 설계되는지 이해해야 합니다. 이러한 내부 패턴을 이해하는 것은 인시던트 대응뿐만 아니라 모범 사례에 따라 패턴이 설계된 애플리케이션 전반의 일관성을 확인하는 데에도 중요합니다. 또한 이 설명서가 최신 상태이고 새 아키텍처 패턴에 따라 정기적으로 업데이트되는지 확인해야 합니다. 다음과 같은 항목을 자세히 설명하는 설명서와 내부 리포지토리를 개발해야 합니다.
+ **AWS 계정 구조** - 다음을 알아야 합니다.
  +  AWS 계정이 몇 개 있나요?
  +  이러한 AWS 계정은 어떻게 구성되나요?
  +  AWS 계정의 비즈니스 소유자는 누구인가요?
  +  서비스 제어 정책(SCP)을 사용하시나요? 그렇다면 SCP를 사용하여 구현되는 조직 가드레일은 무엇인가요?
  +  사용할 수 있는 리전과 서비스를 제한하나요?
  +  사업부와 환경(개발/테스트/프로덕션) 간에는 어떤 차이가 있나요?
+ **AWS 서비스 패턴** 
  +  어떤 AWS 서비스를 사용하나요?
  +  가장 널리 사용되는 AWS 서비스는 무엇인가요?
+ **아키텍처 패턴** 
  +  어떤 클라우드 아키텍처를 사용하나요?
+ **AWS 인증 패턴** 
  +  개발자는 일반적으로 AWS에 어떻게 인증하나요?
  +  IAM 역할, 사용자 또는 둘 다 사용하나요? AWS에 대한 인증이 ID 제공업체(idP)에 연결되어 있나요?
  +  IAM 역할 또는 사용자를 직원 또는 시스템에 어떻게 매핑하나요?
  +  더 이상 권한이 없는 경우 어떻게 액세스 권한이 취소되나요?
+ **AWS 권한 부여 패턴** 
  +  개발자는 어떤 IAM 정책을 사용하나요?
  +  리소스 기반 정책을 사용하시나요?
+ **로깅 및 모니터링** 
  +  어떤 로깅 소스를 사용하며 어디에 저장되나요?
  +  AWS CloudTrail 로그를 집계하나요? 그렇다면 어디에 저장되나요?
  +  CloudTrail 로그를 쿼리하려면 어떻게 해야 하나요?
  +  Amazon GuardDuty를 활성화했나요?
  +  GuardDuty 조사 결과(예: 콘솔, 티켓팅 시스템, SIEM)에 액세스하려면 어떻게 해야 하나요?
  +  조사 결과 또는 이벤트가 SIEM에서 집계되나요?
  +  티켓이 자동으로 생성되나요?
  +  조사를 위해 로그를 분석하기 위한 도구에는 어떤 것이 있나요?
+ **네트워크 토폴로지** 
  +  네트워크의 디바이스, 엔드포인트 및 연결은 물리적 또는 논리적으로 어떻게 배열되나요?
  +  네트워크는 AWS와 어떻게 연결되나요?
  +  환경 간에 네트워크 트래픽은 어떻게 필터링되나요?
+ **외부 인프라** 
  +  외부용 애플리케이션은 어떻게 배포되나요?
  +  공개적으로 액세스할 수 있는 AWS 리소스에는 어떤 것이 있나요?
  +  외부로 향하는 인프라가 포함된 AWS 계정에는 어떤 것이 있나요?
  +  어떤 DDoS 또는 외부 필터링이 있나요?

 내부 기술 다이어그램과 프로세스를 문서화하면 인시던트 대응 분석가의 작업이 쉬워지므로 보안 이벤트에 대응할 수 있는 제도적 지식을 빠르게 얻을 수 있습니다. 내부 기술 프로세스를 철저히 문서화하면 보안 조사가 간소화될 뿐만 아니라 프로세스의 합리화 및 평가에도 도움이 됩니다.

# 인시던트 대응 개발 플레이북
<a name="develop-incident-response-playbooks"></a>

 인시던트 대응 프로세스를 준비하는 데 있어 가장 중요한 부분은 플레이북을 개발하는 것입니다. 인시던트 대응 플레이북은 보안 이벤트가 발생했을 때 따라야 할 일련의 권장 가이드와 단계를 제공합니다. 명확한 구조와 단계를 갖추면 대응 프로세스가 간소화되고 인적 오류의 가능성이 줄어듭니다.

# 플레이북 작성 대상
<a name="what-to-create-playbooks-for"></a>

 다음과 같은 인시던트 시나리오에 대한 플레이북을 만들어야 합니다.
+  **예상되는 인시던트** - 예상되는 인시던트에 대한 플레이북을 만들어야 합니다. 여기에는 서비스 거부(DoS), 랜섬웨어, 자격 증명 유출과 같은 위협이 포함됩니다.
+ **알려진 보안 조사 결과 또는 알림** - 알려진 보안 조사 결과 및 알림(예: GuardDuty 조사 결과)에 대한 플레이북을 만들어야 합니다. GuardDuty 조사 결과를 받고 '이제 어떡하지?'라고 생각할 수 있습니다. GuardDuty 조사 결과를 잘못 처리하거나 무시하는 것을 방지하려면 잠재적인 GuardDuty 조사 결과에 대한 플레이북을 만드세요. 일부 수정 세부 사항과 지침은 [GuardDuty 설명서](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html)에 나와 있습니다. GuardDuty는 기본적으로 활성화되어 있지 않으며 사용 시 별도의 비용이 발생한다는 점에 유의하세요. GuardDuty에 대한 자세한 내용은 부록 A: 클라우드 기능 정의 - [가시성 및 알림](visibility-and-alerting.md)에서 확인할 수 있습니다.

# 플레이북 포함 대상
<a name="what-to-include-in-playbooks"></a>

 플레이북에는 보안 분석가가 잠재적인 보안 인시던트를 적절히 조사하고 대응하기 위해 완료해야 할 기술 단계가 포함되어야 합니다.

 플레이북에 포함할 항목은 다음과 같습니다.
+  **플레이북 개요** - 이 플레이북은 어떤 위험 또는 인시던트 시나리오를 다루고 있나요? 플레이북의 목표는 무엇인가요?
+  **사전 조건** - 이 인시던트 시나리오에 어떤 로그 및 탐지 메커니즘이 필요한가요? 예상되는 알림은 무엇인가요?
+ ** 이해관계자 정보** - 관련자는 누구이며 연락처 정보는 어떻게 되나요? 관련된 각 이해관계자의 책임은 무엇인가요?
+ **대응 단계** - 인시던트 대응 단계 전반에서 어떤 전술적 단계를 수행해야 하나요? 분석가는 어떤 쿼리를 실행해야 하나요? 원하는 결과를 얻으려면 어떤 코드를 실행해야 하나요?
  + **탐지** - 어떻게 인시던트를 탐지하나요?
  + **분석** - 어떻게 영향 범위를 결정하나요?
  + **격리** - 범위를 제한하기 위해 어떻게 인시던트를 격리하나요?
  + **근절** - 환경에서 위협을 어떻게 제거하나요?
  + **복구** - 영향을 받은 시스템이나 리소스를 어떻게 프로덕션 환경으로 복구하나요?
+ **예상 결과** - 쿼리와 코드가 실행된 후 플레이북의 예상 결과는 무엇인가요?

 각 플레이북에서 일관된 정보를 확인하려면 다른 보안 플레이북에서 사용할 플레이북 템플릿을 생성하는 것이 유용할 수 있습니다. 이해관계자 정보와 같이 이전에 나열된 항목 중 일부를 여러 플레이북에서 공유할 수 있습니다. 그렇다면 해당 정보에 대한 중앙 집중식 문서를 만들고 플레이북에서 참조한 다음 플레이북에 명확한 차이점을 열거할 수 있습니다. 이렇게 하면 모든 개별 플레이북에서 동일한 정보를 업데이트할 필요가 없습니다. 플레이북에서 템플릿을 만들고 공통적이거나 공유되는 정보를 식별하면 플레이북 개발을 간소화하고 가속화할 수 있습니다. 마지막으로, 플레이북은 시간이 지남에 따라 진화할 가능성이 높으며, 단계가 일관성이 있음이 확인되면 자동화를 위한 요구 사항이 형성됩니다.

# 샘플 플레이북
<a name="sample-playbooks"></a>

 부록 B의 [플레이북 리소스](appendix-b-incident-response-resources.md#playbook-resources)에서 여러 가지 샘플 플레이북을 찾을 수 있습니다. 여기의 예시는 어떤 플레이북을 만들어야 하는지, 플레이북에 무엇을 포함해야 하는지에 대한 지침을 제공하는 데 도움이 될 수 있습니다. 그러나 비즈니스와 가장 관련성 있는 위험을 통합한 플레이북을 만드는 것이 중요합니다. 플레이북 내의 단계와 워크플로에 기술과 프로세스가 포함되어 있는지 확인해야 합니다.

# 정기 시뮬레이션 실행
<a name="run-regular-simulations"></a>

 조직은 시간이 지남에 따라 성장하고 진화하며, 위협 환경도 마찬가지입니다. 이러한 이유로 인시던트 대응 역량을 지속적으로 검토하는 것이 중요합니다. 이 평가를 수행하는 데 사용할 수 있는 한 가지 방법은 시뮬레이션입니다. 시뮬레이션은 위협 행위자의 전술, 기술 및 절차(TTP)를 모방하도록 설계된 실제 보안 이벤트 시나리오를 사용하며, 이를 통해 조직은 이러한 모의 사이버 이벤트에 실제 상황과 같이 대응하여 인시던트 대응 능력을 발휘하고 평가할 수 있습니다.

 시뮬레이션에는 다음과 같은 다양한 이점이 있습니다.
+  사이버 대비 상태를 검증하고 인시던트 대응자의 자신감을 높입니다.
+  도구 및 워크플로의 정확성과 효율성을 테스트합니다.
+  인시던트 대응 계획에 맞춰 커뮤니케이션 및 에스컬레이션 방법을 개선합니다.
+  덜 일반적인 벡터에 대응할 수 있는 기회를 제공합니다.

# 시뮬레이션 유형
<a name="types-of-simulations"></a>

 시뮬레이션에는 다음과 같은 세 가지 주요 유형이 있습니다.
+  **탁상 연습** - 시뮬레이션에 대한 탁상 접근 방식은 다양한 인시던트 대응 이해관계자가 참여하여 책임진 역할을 연습하고 확립된 커뮤니케이션 도구와 플레이북을 사용하는 토론 기반 세션입니다. 연습은 일반적으로 가상 장소, 실제 장소 또는 이들 장소의 조합에서 하루 종일 수행할 수 있어 언제든 촉진시킬 수 있습니다. 토론을 기반으로 하는 특성상 탁상 연습은 프로세스, 사람, 협업에 중점을 둡니다. 기술은 토론의 핵심 부분이지만 인시던트 대응 도구 또는 스크립트의 실제 사용은 일반적으로 탁상 연습의 일부가 아닙니다.
+  **퍼플 팀 연습** - 퍼플 팀 연습은 인시던트 대응 담당자(*블루 팀*)와 시뮬레이션된 위협 행위자(*레드 팀*) 간의 협업 수준을 높입니다. 블루 팀은 보안 운영 센터(SOC)의 직원으로 구성되지만 실제 사이버 이벤트 중에 관여하게 될 다른 이해관계자들도 포함될 수 있습니다. 레드 팀은 대개 보안 공격 교육을 받은 침투 테스트 팀 또는 주요 이해관계자로 구성됩니다. 레드 팀은 시나리오를 설계할 때 연습 진행자와 협력하여 시나리오가 정확하고 실현 가능한지 확인합니다. 퍼플 팀 연습에서는 인시던트 대응 작업을 지원하는 탐지 메커니즘, 도구 및 표준 운영 절차(SOP)에 주로 초점을 맞춥니다.
+ **레드 팀 연습** - 레드 팀 연습 중에 공격 팀(*레드 팀*)은 미리 정해진 범위에서 특정 목표 또는 일련의 목표를 달성하기 위해 시뮬레이션을 수행합니다. 방어 팀(*블루 팀*)은 훈련의 범위와 기간을 꼭 알 필요가 없습니다. 이를 모르면 실제 인시던트에 어떻게 대응하는지에 대한 더 현실적인 평가를 받을 수 있습니다. 레드 팀 연습은 침습적 테스트일 수 있으므로 주의가 필요하고 해당 연습이 환경에 실제로 해를 끼치지 않는지 확인하기 위한 관리 조치를 취해야 합니다.

**참고**  
AWS에서는 고객이 퍼플 팀이나 레드 팀 훈련을 실시하기 전에 [침투 테스트 웹 사이트](https://aws.amazon.com/security/penetration-testing/)에서 제공하는 침투 테스트 정책을 검토하도록 요구합니다.

 표 1에는 이러한 유형의 시뮬레이션의 몇 가지 주요 차이점이 요약되어 있습니다. 일반적으로 이러한 정의는 포괄적인 정의로 간주되며 조직의 요구 사항에 맞게 사용자 지정할 수 있다는 점에 유의해야 합니다.

*표 1 - 시뮬레이션 유형*


|   |  테이블탑 연습  |  퍼플 팀 연습  |  레드 팀 연습  | 
| --- | --- | --- | --- | 
|  요약  |  특정 보안 인시던트 시나리오 하나에 초점을 맞춘 종이 기반 연습. 이는 개괄적 또는 기술적일 수 있으며 일련의 종이 주입을 통해 구동됩니다. |  테이블탑 연습에 비해 더 사실적인 오퍼링. 퍼플 팀 연습 중 진행자는 참가자와 협력하여 연습 참여를 높이고 필요한 경우 훈련을 제공합니다. |  일반적으로 보다 진보된 시뮬레이션 오퍼링. 일반적으로 비밀 유지 수준이 높아서 참가자들이 연습의 모든 세부 사항을 알지 못할 수도 있습니다. | 
|  필요 리소스  |  제한된 기술 리소스 필요  |  다양한 이해관계자와 높은 수준의 기술 리소스 필요  |  다양한 이해관계자와 높은 수준의 기술 리소스 필요  | 
|  복잡성  |  낮음  |  중간  |  높음  | 

 정기적으로 사이버 시뮬레이션을 진행하는 것이 좋습니다. 각 연습 유형에는 참가자와 조직 전체에 대한 고유한 이점이 있으므로 덜 복잡한 시뮬레이션 유형(예: 탁상 연습)에서 시작하여 더 복잡한 시뮬레이션 유형(레드 팀 연습)으로 진행할 수 있습니다. 보안 성숙도, 리소스, 원하는 성과에 따라 시뮬레이션 유형을 선택해야 합니다. 일부 고객은 복잡성과 비용 때문에 레드 팀 연습을 선택하지 않을 수 있습니다.

# 연습 수명 주기
<a name="exercise-lifecycle"></a>

 선택한 유형에 관계없이 시뮬레이션은 일반적으로 다음 단계를 따릅니다.

1.  **핵심 연습 요소 정의** - 시뮬레이션의 시나리오와 목표를 정의합니다. 이 두 가지 모두 리더의 승인을 받아야 합니다.

1. **주요 이해관계자 식별** - 연습에는 최소한 연습 진행자와 참가자가 필요합니다. 시나리오에 따라 법무, 커뮤니케이션 또는 경영진과 같은 추가 이해관계자가 참여할 수 있습니다.

1. **시나리오 구축 및 테스트** - 특정 요소가 실현 가능하지 않은 경우 구축 중인 시나리오를 재정의해야 할 수 있습니다. 이 단계의 결과로 최종 시나리오가 도출될 것으로 예상됩니다.

1. **시뮬레이션 촉진** - 시뮬레이션 유형에 따라 어떤 방법으로 촉진시킬지 결정됩니다(종이를 사용한 시나리오 또는 고도로 기술적인 시뮬레이션 시나리오). 진행자는 연습 목표에 맞게 촉진 전략을 조정해야 하며 가능한 한 모든 연습 참가자를 참여시켜 최대한의 이점을 확보해야 합니다.

1. **사후 조치 보고서(AAR) 개발** - 잘 운영된 영역, 개선이 필요한 영역, 잠재적인 격차를 식별합니다. AAR은 시뮬레이션의 효과와 시뮬레이션된 이벤트에 대한 팀의 반응을 측정하여 향후 시뮬레이션을 통해 시간의 흐름에 따른 진행 상황을 추적할 수 있도록 해야 합니다.