클라우드 인시던트 대응 — EC2 침해 시 첫 30분 액션 플랜

EC2 침해 사건의 심각성과 황금 시간의 중요성

클라우드 환경에서 EC2 인스턴스 침해는 조직의 가장 치명적인 보안 위협 중 하나입니다. Verizon DBIR 2024 보고서에 따르면, 클라우드 환경에서의 초기 침입부터 탐지까지 평균 수일이 소요되며, 침해 탐지 후 대응 시간이 얼마나 빠른지가 피해 규모를 결정합니다. 특히 첫 30분은 공격자가 추가 침투를 시도하거나 증거를 제거하기 전에 행동할 수 있는 "황금 시간"입니다.

이 글에서는 EC2 인스턴스 침해 직후 첫 30분 동안 보안 팀과 클라우드 엔지니어가 취해야 할 구체적이고 실행 가능한 액션 플랜을 제시합니다. 증거 보존, 네트워크 격리, 근본 원인 파악, 자동화된 대응까지 단계별 프로세스를 다루겠습니다.

EC2 침해 탐지의 현실과 대응 체계의 필요성

AWS 환경에서 EC2 침해는 여러 방식으로 탐지됩니다. GuardDuty가 비정상적인 로그인 시도를 감지하거나, CloudTrail 로그에서 권한 상승이 관찰되거나, Security Hub가 의심스러운 네트워크 활동을 플래그할 수 있습니다. 또는 외부 보안 운영 센터(SOC)가 침투 시도를 보고할 수도 있습니다.

IBM의 2024년 데이터 침해 비용 보고서에 따르면, 침해 탐지부터 격리까지의 시간이 하루 단축될 때마다 평균 250,000달러 이상의 비용을 절감할 수 있습니다. 특히 클라우드 환경에서는 공격자가 몇 분 안에 추가 리소스를 배포하거나 데이터를 유출할 수 있으므로, 빠른 대응 체계가 필수적입니다.

조직의 규모, 클라우드 성숙도, 기존 보안 도구와 관계없이 첫 30분 동안은 동일한 우선순위를 따라야 합니다. 이를 위해서는 사전 준비된 플레이북, 자동화 스크립트, 그리고 명확한 책임 분담 체계가 필요합니다.

0-5분: 침해 인지 및 초기 대응팀 소집

침해가 탐지되는 순간, 즉시 취할 행동들을 정리했습니다. 이 단계에서는 침해의 범위를 제한하고 증거 손실을 방지하는 것이 목표입니다.

1단계: 인시던트 선언과 팀 활성화

침해 신호가 포착되면 보안 팀장에게 즉시 보고합니다. 동시에 다음 역할의 담당자들을 소집합니다: 클라우드 인프라 엔지니어, 데이터베이스 관리자, 네트워크 담당자, 법무 담당자. 이들은 병렬로 작업하게 될 것입니다.

조직에 Seekurity SOAR와 같은 보안 오케스트레이션 도구가 있다면, 인시던트 선언과 동시에 자동화된 플레이북이 트리거되어 알림 발송, 대시보드 생성, 로그 수집을 자동으로 시작할 수 있습니다.

2단계: 침해된 EC2 인스턴스 파악

AWS Console 또는 CLI를 통해 침해된 인스턴스의 상세 정보를 즉시 기록합니다. 다음 명령어로 인스턴스 정보를 조회합니다.

aws ec2 describe-instances --instance-ids i-0123456789abcdef0 --region us-east-1

이 명령어 출력으로부터 다음 정보를 추출하고 기록합니다: 인스턴스 ID, 인스턴스 타입, 시작 시간, 현재 상태, 보안 그룹, 연결된 IAM 역할, 네트워크 인터페이스(ENI), 연결된 EBS 볼륨, 퍼블릭 IP 주소. 이 정보는 이후 분석과 격리 과정에서 필수적입니다.

3단계: 침해 신호의 출처 추적

침해가 어떻게 탐지되었는지 확인합니다. GuardDuty 콘솔을 확인하여 구체적인 위협 유형(Trojan, CryptoCurrency:EC2/BitcoinTool.B 등)을 파악합니다. CloudTrail 로그에서 의심스러운 API 호출 시간을 기록합니다.

aws cloudtrail lookup-events --lookup-attributes AttributeKey=InstanceId,AttributeValue=i-0123456789abcdef0 --region us-east-1 --max-items 50

이 출력으로부터 침해 직전의 모든 API 활동을 시간 순서대로 기록합니다. 누가(어떤 IAM 사용자 또는 역할), 언제, 어떤 행동을 했는지를 파악하는 것이 중요합니다.

5-15분: 네트워크 격리와 증거 보존

이 단계에서는 침해된 인스턴스의 추가 확산을 막으면서 증거를 보존합니다. 주의할 점은 인스턴스를 즉시 종료하면 메모리 내 증거가 손실된다는 것입니다.

1단계: 보안 그룹 수정을 통한 네트워크 격리

침해된 인스턴스가 속한 보안 그룹을 즉시 수정하여 아웃바운드 연결을 차단합니다. 이렇게 하면 공격자가 데이터를 유출하거나 추가 도구를 다운로드하는 것을 방지할 수 있습니다.

aws ec2 revoke-security-group-egress --group-id sg-0123456789abcdef0 --ip-permissions IpProtocol=-1,IpRanges='[{IpCidr=0.0.0.0/0}]' --region us-east-1

아울러 인바운드 규칙도 검토하여 불필요한 포트(예: SSH 22번, RDP 3389번)가 인터넷에 노출되어 있는지 확인합니다. 포렌식 조사에 필요한 경우를 제외하고는 이들을 모두 차단합니다.

2단계: EBS 스냅샷 생성 - 증거 보존의 핵심

침해된 인스턴스에 연결된 모든 EBS 볼륨의 스냅샷을 즉시 생성합니다. 이는 나중의 포렌식 조사를 위한 필수 증거입니다.

aws ec2 describe-instances --instance-ids i-0123456789abcdef0 --query 'Reservations[0].Instances[0].BlockDeviceMappings[*].Ebs.VolumeId' --region us-east-1

이 명령어로 인스턴스에 연결된 모든 볼륨 ID를 추출한 후, 각 볼륨에 대해 스냅샷을 생성합니다.

aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "Incident snapshot - [timestamp]" --tag-specifications 'ResourceType=snapshot,Tags=[{Key=IncidentID,Value=INC-2024-001},{Key=PreservedDate,Value=2024-01-15T14:32:00Z}]' --region us-east-1

스냅샷 생성 시 반드시 태그를 지정하여 나중에 쉽게 식별할 수 있도록 합니다. 인시던트 ID, 생성 날짜, 분석 상태 등을 태그로 포함시킵니다.

3단계: 메모리 덤프 및 실시간 로그 수집

Linux 기반 EC2 인스턴스라면, 메모리 포렌식 도구를 사용하여 메모리 상태를 덤프합니다. 공격자의 도구, 명령어, 열린 네트워크 연결 등이 메모리에 남아 있을 가능성이 높습니다.

sudo dd if=/dev/mem of=/mnt/forensics/memory.dump bs=4M

또한 현재 프로세스 목록, 네트워크 연결 상태, 열린 파일 디스크립터 등을 즉시 수집합니다.

ps auxf > /mnt/forensics/processes.txt
netstat -tunap > /mnt/forensics/netstat.txt
lsof -P -n > /mnt/forensics/lsof.txt
ss -tunap > /mnt/forensics/ss.txt

이들 파일을 S3의 보호된 버킷에 업로드하여 안전하게 보존합니다.

15-25분: 근본 원인 파악과 영향 범위 확인

증거를 보존한 후, 침해가 어떻게 발생했는지, 그리고 얼마나 광범위한 영향을 미쳤는지를 파악합니다.

1단계: IAM 역할과 권한 검토

침해된 인스턴스에 연결된 IAM 역할의 정책을 확인합니다. 공격자가 이 역할을 악용하여 조직의 다른 리소스에 접근했을 가능성이 있습니다.

aws ec2 describe-instances --instance-ids i-0123456789abcdef0 --query 'Reservations[0].Instances[0].IamInstanceProfile' --region us-east-1

이 출력으로부터 IAM 역할 이름을 얻은 후, 다음 명령어로 정책을 조회합니다.

aws iam list-attached-role-policies --role-name [역할-이름]

특히 AdministratorAccess나 과도한 권한을 가진 정책이 연결되어 있지 않은지 확인합니다. 만약 있다면, 공격자가 EC2 인스턴스를 디딤돌로 사용하여 조직 전체의 AWS 환경을 제어할 수 있다는 의미입니다.

2단계: CloudTrail을 통한 API 이상 활동 추적

침해된 인스턴스의 IAM 역할을 사용한 모든 API 호출을 조회합니다. 공격자가 추가 EC2 인스턴스를 생성하거나, S3 버킷을 나열하거나, 데이터베이스에 접근했을 수 있습니다.

aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=[역할-이름] --start-time 2024-01-15T10:00:00Z --region us-east-1

조회 결과에서 다음을 확인합니다: 불필요한 EC2 인스턴스 생성, S3 버킷 리스트 조회, RDS 데이터베이스 수정, IAM 권한 변경, 다른 계정으로의 역할 복사(cross-account 공격 가능성).

3단계: 감염된 다른 인스턴스 탐지

GuardDuty와 Security Hub 콘솔을 확인하여 같은 시기에 다른 EC2 인스턴스에서도 의심스러운 활동이 탐지되었는지 확인합니다. 공격자가 네트워크 내부를 옆으로 이동(lateral movement)했을 가능성이 있습니다.

aws securityhub get-findings --filters '{"ResourceType": [{"Value": "AwsEc2:Instance", "Comparison": "EQUALS"}], "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}], "LastObservedAt": [{"Value": "2024-01-15", "Comparison": "GREATER_THAN_OR_EQUAL"}]}' --region us-east-1

이 명령어는 최근 며칠간 Security Hub에서 탐지된 모든 EC2 관련 위협을 나열합니다. 같은 기간에 여러 인스턴스가 문제를 보이고 있다면 네트워크 전체 감염을 의심해야 합니다.

25-30분: 자동화 및 확장성 있는 대응 시작

이 마지막 5분은 추가 감염 방지와 향후 분석을 위한 자동화된 조치를 시작하는 단계입니다.

1단계: 지속성 메커니즘 제거

공격자가 인스턴스에 설치한 백도어나 지속성 메커니즘을 파악합니다. Linux 인스턴스라면 cron 작업, systemd 서비스, SSH 키를 확인합니다.

crontab -l
ls -la /etc/cron.d/
ls -la ~/.ssh/
cat ~/.ssh/authorized_keys

의심스러운 항목이 발견되면, 증거 보존을 위해 먼저 이를 파일로 기록한 후 제거합니다.

sudo su -
cat /root/.ssh/authorized_keys > /mnt/forensics/unauthorized_keys.txt
echo "" > /root/.ssh/authorized_keys

2단계: AWS 리소스에 대한 액세스 차단

침해된 인스턴스의 IAM 역할에 대한 모든 신규 세션을 즉시 무효화합니다. AWS는 기존 임시 자격증명도 곧 만료되도록 하는 방식으로 공격자의 접근을 차단합니다.

aws iam attach-role-policy --role-name [역할-이름] --policy-arn arn:aws:iam::aws:policy/DenyAllOutsideEC2 --region us-east-1

또는 더 강력한 방법으로, 역할의 모든 기존 신뢰 관계를 수정하여 이 인스턴스에서의 세션을 완전히 차단할 수 있습니다.

3단계: FRIIM CSPM을 활용한 설정 규정 준수 확인

침해가 보안 설정의 미흡으로 인해 발생했는지 확인합니다. FRIIM CSPM은 EC2 보안 그룹 설정, IAM 정책, 암호화 설정, 네트워크 ACL 등 모든 클라우드 설정을 실시간으로 모니터링합니다. 다음과 같은 항목들을 검토합니다:

• EC2 인스턴스가 불필요하게 인터넷에 노출되었는지 여부
• IAM 역할에 과도한 권한이 부여되었는지 여부
• EBS 볼륨 암호화 설정
• CloudTrail 로깅 활성화 여부
• Security Group 규칙의 과도한 개방 여부

4단계: 자동화된 대응 플레이북 시작

조직에 Seekurity SOAR가 있다면, 이 단계부터는 자동화된 플레이북이 큰 역할을 할 수 있습니다. 다음과 같은 자동화 작업들이 병렬로 실행됩니다:

• 피해 인스턴스의 모든 로그를 중앙 로깅 시스템으로 자동 수집
• AWS CloudTrail, VPC Flow Logs, Application Logs의 병렬 분석
• 영향받은 리소스의 자동 태깅 및 격리
• 상위 경영진과 필요한 부서에 자동 알림 발송
• 법적 준수 요건에 따른 증거 보존 자동화

# Seekurity SOAR 플레이북 예시 (YAML)
name: EC2 Incident Response
trigger: "ec2_compromise_detected"
actions:
  - collect_cloudtrail_logs:
      instance_id: "${INSTANCE_ID}"
      lookback_hours: 24
  - collect_vpc_flow_logs:
      eni_id: "${ENI_ID}"
  - isolate_security_group:
      group_id: "${SECURITY_GROUP_ID}"
      action: "revoke_all_egress"
  - create_ebs_snapshots:
      volumes: "${VOLUME_IDS}"
      tags:
        IncidentID: "${INCIDENT_ID}"
        PreservedTime: "${CURRENT_TIME}"
  - notify_stakeholders:
      recipients: ["ciso@company.com", "incident-response-team@company.com"]
      priority: "CRITICAL"

30분 이후: 지속적인 조사와 복구

첫 30분이 종료된 후에도 대응은 계속됩니다. 이 단계에서는 다음 항목들을 진행합니다.

1단계: 상세 포렌식 분석

EBS 스냅샷으로부터 별도의 분석 인스턴스를 생성하여 깊이 있는 포렌식 조사를 수행합니다. 침해가 언제 시작되었는지, 공격자가 설치한 도구는 무엇인지, 어떤 데이터가 접근되었는지를 파악합니다. 특히 메모리 덤프 분석(Volatility 등의 도구 사용)은 공격자가 남긴 흔적을 드러낼 수 있습니다.

2단계: 데이터 유출 여부 확인

침해된 인스턴스가 S3, RDS, Redshift, DynamoDB 등의 데이터 리소스에 접근했는지 CloudTrail을 상세히 분석합니다. 만약 접근했다면, 해당 데이터가 실제로 유출되었는지 확인하기 위해 다음을 검토합니다:

• S3 버킷의 "Copy" 또는 "GetObject" API 호출 여부
• 데이터베이스의 대량 SELECT 쿼리 실행 여부
• VPC 엔드포인트나 외부 IP로의 대용량 데이터 전송 여부

3단계: 영향 범위 공식화

조사 결과를 바탕으로 영향받은 데이터의 범위, 유출 가능성, 비즈니스 영향을 공식적으로 문서화합니다. 이는 경영진 보고, 규제 기관 보고, 고객 공지 등에 사용됩니다.

EC2 침해 대응 체크리스트 및 자동화 설정

조직이 이러한 대응을 일관되게 실행하기 위해서는 사전 준비가 필수적입니다. 다음은 EC2 침해 대응을 자동화하고 표준화하기 위한 체크리스트입니다.

사전 준비 단계

• 모니터링 인프라 구축: GuardDuty, CloudTrail, VPC Flow Logs를 모두 활성화하고, 로그를 중앙 S3 버킷(쓰기 전용, 삭제 불가능한 설정)으로 전송합니다. FRIIM CWPP를 사용하여 EC2 인스턴스 내부의 의심스러운 활동도 모니터링합니다.
• 자동화 스크립트 사전 준비: 위에서 제시한 CLI 명령어들을 Lambda 함수로 변환하여 버전 제어 시스템에 저장합니다. 인시던트 발생 시 빠르게 실행할 수 있도록 합니다.
• 포렌식 환경 사전 구성: EBS 스냅샷을 마운트할 별도의 "포렌식 인스턴스"를 미리 AMI 형태로 준비합니다. 필요한 도구(메모리 분석, 파일 시스템 분석 등)를 미리 설치합니다.
• 역할과 책임 문서화: 누가 어떤 결정을 내릴 권한이 있는지 명확히 합니다. 예를 들어, 누가 인스턴스 격리를 승인할 수 있는지, 누가 CEO에게 보고할지 등을 정의합니다.

모니터링 및 탐지 자동화

첫 단계부터 탐지가 자동화되려면 다음과 같은 설정이 필요합니다.

#!/bin/bash
# GuardDuty 조사 대상 설정 (자동 및 대규모 스캔 활성화)
aws guardduty create-detector --finding-publishing-frequency FIFTEEN_MINUTES --region us-east-1
aws guardduty update-detector --detector-id [detector-id] --enable --finding-publishing-frequency FIFTEEN_MINUTES --region us-east-1
# CloudTrail 멀티 리전 로깅 활성화
aws cloudtrail create-trail --name incident-response-trail --s3-bucket-name incident-logs-bucket --is-multi-region-trail --region us-east-1
aws cloudtrail start-logging --trail-name incident-response-trail --region us-east-1
# VPC Flow Logs 활성화 (모든 VPC)
aws ec2 describe-vpcs --query 'Vpcs[*].VpcId' --region us-east-1 | xargs -I {} aws ec2 create-flow-logs --resource-type VPC --resource-ids {} --traffic-type ALL --log-destination-type s3 --log-destination arn:aws:s3:::vpc-flow-logs-bucket/vpc-logs --region us-east-1

EventBridge를 통한 자동화 트리거

GuardDuty의 위협 탐지 시 자동으로 대응 플레이북이 시작되도록 EventBridge 규칙을 설정합니다.

{
  "Name": "EC2-Compromise-Detection",
  "EventPattern": {
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {
      "type": [
        "Trojan.EC2/DNS.ExfiltrationDNS.C!DNS",
        "Trojan.EC2/BlackholeTraffic.EC2",
        "CryptoCurrency.EC2/BitcoinTool.B!DNS",
        "EC2.Malware.Unknown",
        "EC2.NetworkPermissions.UnauthorizedAccess"
      ]
    }
  },
  "Targets": [
    {
      "Arn": "arn:aws:lambda:us-east-1:123456789012:function:incident-response-automation",
      "RoleArn": "arn:aws:iam::123456789012:role/eventbridge-lambda-role"
    }
  ]
}

이 EventBridge 규칙이 트리거되면, Lambda 함수가 자동으로 실행되어 위의 30분 액션 플랜을 자동화합니다.

실제 사례: 클라우드 미디어 기업의 EC2 침해 대응

한 클라우드 기반 비디오 스트리밍 기업이 2024년 초 EC2 인스턴스 침해를 경험했습니다. 공격자는 취약한 SSH 키 관리로 인해 인스턴스에 접근했으며, 비트코인 마이닝 도구를 설치했습니다.

대응 시간 비교

이 기업은 또한 다음과 같은 개선 효과를 경험했습니다:

• 비용 감소: 마이닝 공격으로 인한 EC2 인스턴스 과다 사용으로 월 약 12,000달러 손실이 예상되었으나, 빠른 격리로 2시간 내에 중단되어 약 1,000달러 손실로 제한
• 증거 보존: 표준화된 포렌식 절차로 인해 법적 소송에 사용 가능한 완벽한 증거 체인 확보
• 재발 방지: 근본 원인 파악 단축으로 인해 같은 주에 SSH 키 관리 정책 개선 조치 시행

이 기업은 첫 30분 액션 플랜을 도입한 후, FRIIM CSPM을 추가 도입하여 SSH 포트가 인터넷에 노출된 모든 인스턴스를 식별하고 자동으로 수정했습니다. 또한 Seekurity SIEM/SOAR를 구축하여 위협 탐지부터 대응까지의 전 과정을 자동화했습니다.

일반적인 오류와 해결 방법

오류 1: 증거 손실을 위해 인스턴스를 즉시 종료

많은 조직이 침해 직후 인스턴스를 즉시 종료합니다. 그러나 이렇게 하면 메모리에 있던 공격자의 도구, 열린 네트워크 연결, 실행 중인 프로세스 정보가 모두 손실됩니다. 대신 먼저 EBS 스냅샷과 메모리 덤프를 수집한 후 인스턴스를 종료해야 합니다.

오류 2: CloudTrail 로그의 불완전한 수집

일부 조직은 CloudTrail 설정에서 데이터 이벤트(Data Events)를 활성화하지 않아, S3 GetObject나 DynamoDB 스캔 같은 중요한 API 호출을 놓칩니다. 모든 API 호출을 추적하려면 데이터 이벤트도 반드시 로깅해야 합니다.

오류 3: IAM 역할 권한 검토의 지연

침해된 인스턴스의 IAM 역할이 과도한 권한을 가지고 있다면, 공격자는 매우 짧은 시간 안에 조직 전체의 AWS 환경을 손상시킬 수 있습니다. 첫 30분 내에 이를 반드시 확인하고 차단해야 합니다. 사전에 IAM 최소 권한 원칙을 적용하고 정기적으로 감사하는 것이 중요합니다.

오류 4: 네트워크 격리 실패

보안 그룹만 수정해서는 부족합니다. Network ACL, 라우트 테이블, VPC 엔드포인트도 함께 검토해야 합니다. 또한 인스턴스가 NAT 게이트웨이를 통해 인터넷 접근이 가능한지도 확인해야 합니다.

향후 클라우드 인시던트 대응의 발전 방향

클라우드 인시던트 대응 분야는 빠르게 발전하고 있습니다. 향후 주목할 기술 동향은 다음과 같습니다.

자동화 및 AI의 심화

현재의 수동적 대응 플레이북은 AI 기반 자동화로 발전할 것입니다. 탐지부터 격리, 근본 원인 파악, 복구까지의 전 과정이 자동으로 이루어질 것으로 전망됩니다. KYRA AI Sandbox와 같은 AI 기반 분석 도구는 이런 방향의 선두주자입니다.

클라우드 네이티브 포렌식의 표준화

클라우드 환경의 포렌식은 기존의 온프레미스 포렌식과 완전히 다릅니다. 메모리 덤프, EBS 스냅샷, CloudTrail 로그, VPC Flow Logs 등 클라우드 특화 증거를 체계적으로 수집하고 분석하는 방법론이 더욱 정교해질 것입니다.

멀티 클라우드 환경에서의 통합 대응

조직이 AWS, Azure, GCP 등 여러 클라우드를 사용함에 따라, 통합된 인시던트 대응 플랫폼의 필요성이 증가할 것입니다. 이미 여러 SIEM과 SOAR 솔루션이 멀티 클라우드 지원을 강화하고 있습니다.

규제 요구사항의 강화

GDPR, HIPAA, PCI DSS 등의 규제는 침해 탐지 후 일정 시간 내 보고할 것을 요구합니다. 첫 30분 액션 플랜과 같은 구조화된 대응은 이러한 규제 요구사항을 충족하기 위해 필수적이 될 것입니다.

결론 및 즉시 실행 계획

EC2 침해 시 첫 30분은 조직의 피해를 최소화하고 공격자의 추가 활동을 차단할 수 있는 황금 시간입니다. 이 시간을 효과적으로 활용하려면 사전 준비와 자동화가 필수적입니다.

핵심 요약

• 0-5분: 인시던트 선언, 침해 인스턴스 파악, CloudTrail 초기 분석
• 5-15분: 보안 그룹을 통한 네트워크 격리, EBS 스냅샷 생성, 메모리/실시간 로그 수집
• 15-25분: IAM 역할 권한 검토, API 이상 활동 추적, 다른 인스턴스 감염 확인
• 25-30분: 지속성 메커니즘 제거, IAM 역할 접근 차단, FRIIM CSPM을 통한 설정 검토, Seekurity SOAR 자동화 시작

즉시 실행할 사항

• 1주일 내: GuardDuty, CloudTrail, VPC Flow Logs가 모든 AWS 계정과 리전에서 활성화되어 있는지 확인하고, 활성화되지 않은 부분을 즉시 활성화합니다.
• 2주일 내: 위의 CLI 명령어들을 조직의 자동화 프레임워크(Lambda, Systems Manager, 또는 내부 자동화 도구)에 통합하여 한 번의 클릭으로 대응 절차가 시작되도록 구성합니다.
• 1개월 내: 포렌식 분석을 수행할 수 있는 인스턴스 AMI를 준비하고, EC2 침해 대응 플레이북을 조직 내 모든 관련 팀에 배포합니다.
• 3개월 내: FRIIM CWPP, FRIIM CSPM, Seekurity SIEM/SOAR 등의 고급 클라우드 보안 도구 도입을 검토하여 탐지와 대응 자동화 수준을 한 단계 업그레이드합니다.

조직의 규모나 현재 보안 성숙도에 관계없이, 기본적인 30분 액션 플랜을 준비하는 것은 모든 조직의 필수 과제입니다. 이를 통해 침해의 영향을 수십 배 줄일 수 있습니다.