손상된 ID 인시던트 응답 SOP 템플릿 만들기

  • 적용 대상: Microsoft Defender XDR

이 SOP 템플릿을 사용하여 유출된 신원 사고에 대한 재사용 가능한 표준 운영 절차(SOP)를 작성하세요. SOP를 게시하거나 업로드하기 전에 각 자리 표시자를 조직별 값으로 바꿉 있습니다.

메모

이 템플릿은 시작점으로 의도된 일반적인 예제입니다. 있는 그대로 사용하지 마세요. SOP로 게시하거나 업로드하기 전에 트리거, 의사 결정 지점, 쿼리, 에스컬레이션 경로 및 수정 단계를 비롯한 모든 섹션을 조직의 환경, 도구, 역할 및 정책과 일치하도록 사용자 지정합니다.

사전 요구 사항

이 SOP를 맞춤화하거나 게시하기 전에 다음 전제 조건을 확인하세요:

  • SOP를 소유한 사용자와 조직의 변경 내용을 승인할 수 있는 사용자를 확인합니다.
  • 분석가가 SOP에서 참조하는 SigninLogs 데이터 및 기타 원본에 액세스할 수 있는지 확인합니다.
  • SOP를 가이드북으로 업로드하려는 경우 조직의 인시던트 대응 사용자 지정에서 지원되는 파일 형식, 크기 제한 및 권한 요구 사항을 검토하세요.
  • 가이드북 텍스트 중심을 유지합니다. 텍스트 추출 품질을 줄일 수 있는 스크린샷, 그래프 및 복잡한 서식을 사용하지 않습니다.

SOP 메타데이터

다음 메타데이터 필드에 SOP 소유자, 범위 및 데이터 소스를 기록하세요.

  • 이름:<Compromised identity incident response SOP>
  • 버전:<v1.0>
  • 소유자:<Security operations team>
  • 적용 대상:<location>
  • 기본 데이터 원본:SigninLogs, <Defender XDR incident data>, <Identity provider logs>, <Email telemetry>및 <Endpoint telemetry>

Purpose

신원 유출 사고 대응 SOP를 사용하여 신원 유출을 나타내는 사고를 분류, 통제, 조사, 수정 및 방지하세요. 범위, 의사 결정 지점 및 에스컬레이션 경로를 사용자 지정하여 분석가가 영향을 주는 <User><Group>인시던트 중에 일관되게 대응할 수 있도록 합니다<Business unit>.

트리거(이 SOP를 호출하는 경우)

사고, 알림 또는 사용자 보고서에서 신원이 유출되었을 가능성을 시사할 때 유출된 신원 사건 대응 SOP를 발동하세요.

  • 경고 예제에는 Impossible travel, Unfamiliar sign-in properties, Password sprayMFA fatigue및 Suspicious inbox forwarding rules.
  • 예상치 못한 MFA 알림, 의심스러운 로그인 알림, 또는 하지 않은 계정 변경을 보고할 때 <User> 유출된 신원 사건 대응 SOP를 발동하세요.
  • 분석가가 비정상적인 위치, 위험한 IP 주소, 낯선 애플리케이션에서 성공적인 로그인을 관찰할 때 유출된 신원 사고 대응 표준 절차(SOP)를 발동하세요.

심사 단계

로그인 활동이 예상되는지 의심스러운지 확인하는 빠른 검사로 시작합니다.

로그인 활동 유효성 검사

영향을 받는 ID에 대한 최근 로그인 이벤트를 검토합니다. 쿼리를 실행하기 전에 사용자 필터를 바꿉다.

SigninLogs
| where UserPrincipalName =~ "<user@company.com>"
| where TimeGenerated > ago(48h)
| project TimeGenerated, IPAddress, Location, AppDisplayName, AuthenticationRequirement, ConditionalAccessStatus, ClientAppUsed
  1. 로그인 시간, IP 주소, 위치 및 애플리케이션을 인시던트 타임라인과 비교합니다.
  2. 사용자 또는 관리자가 설명할 수 없는 성공적인 로그인을 강조 표시합니다.
  3. 첫 번째 의심스러운 이벤트, 최신 의심스러운 이벤트 및 관련된 계정 또는 앱을 기록합니다.

자격 증명 손상 지표 검토

요약 보기를 사용하여 계정에 반복된 오류 패턴과 성공적인 액세스가 표시되는지 여부를 확인합니다.

SigninLogs
| where UserPrincipalName =~ "<user@company.com>"
| where TimeGenerated >= ago(7d)
| summarize
    Failures = countif(ResultType != 0),
    Successes = countif(ResultType == 0)
    by IPAddress, bin(TimeGenerated, 1h)
  1. 실패한 로그인이 급증한 뒤 하나 이상의 로그인 성공이 이어지는 패턴을 찾습니다.
  2. 동일한 IP 주소, 위치 또는 애플리케이션이 여러 시간 버킷에 표시되는지 여부를 확인합니다.
  3. 패턴이 암호 스프레이, 자격 증명 스터핑, 토큰 도난 또는 다른 의심되는 기술과 일치하는지 여부를 기록합니다.

사용자로 유효성 검사

다음 행동을 결정하기 전에 해당 사용자에게 의심스러운 활동을 직접 확인하세요.

  1. 승인된 채널을 통해 <User>에 문의하세요.
  2. 로그인, 위치, 디바이스, 애플리케이션 및 MFA 프롬프트를 인식하는지 여부를 묻습니다.
  3. 최근에 MFA 요청을 승인했는지, 프롬프트에 자격 증명을 입력했는지, 디바이스를 공유했는지 또는 이동했는지 묻습니다.
  4. 인시던트 레코드에서 사용자의 응답을 캡처합니다.

봉쇄 단계

전체 조사를 완료하기 전에 위험을 포함하지만 먼저 조직별 승인 논리를 적용합니다.

ID 유효성 검사

  1. ID가 서비스 주체인지 아니면 다른 비인간 ID(NHI)인지 확인합니다. 해당되는 경우 직접적인 계정 비활성화 작업을 중단하고, 보안 비밀을 교체하거나 액세스 권한을 철회하거나 ID를 비활성화하기 전에 <Service owner>에 알립니다.
  2. ID가 브레이크 글래스 계정인지 확인합니다. 그렇다면 조치를 취하기 전에 <Identity team lead>와 <Incident commander>에 알리고, 명시적인 승인 없이 계정을 절대로 비활성화하지 마세요.
  3. 영향을 받는 사용자가 선임 리더십, 임원 보조자 또는 다른 고감도 프로필인지 확인합니다. 그렇다면 사용자에게 연락하거나 중단 조치를 취하기 전에 <Incident commander> 및 <Communications lead>에 알리세요.

ID를 포함합니다

증거를 보존하고 비즈니스 혼란을 최소화하면서 유출된 신원을 통제하기 위해 다음과 같은 조치를 취하세요.

  1. 활성 세션을 취소하고 에 대한 <user@company.com>토큰을 새로 고칩니다.
  2. ID 유형에 따라 암호 재설정 또는 비밀 회전을 강제로 적용합니다.
  3. 위험이 활성 상태로 유지되고 비즈니스 승인이 허용되면 계정을 일시적으로 사용하지 않도록 설정합니다.
  4. 도구에서 이러한 작업을 지원할 때 알려진 악성 IP 주소, 디바이스, 애플리케이션 또는 토큰을 차단합니다.
  5. 인시던트 ID, 경고, 로그인 스크린샷 또는 내보내기 및 사용자 문을 비롯한 증거를 보존합니다.

조사 단계

조사 단계를 통해 가능한 진입 지점을 식별하고, 제어 격차를 검증하며, 폭발 반경을 정의하세요.

근본 원인 분석 수행

성공적인 로그인을 사용하여 공격자가 액세스 권한을 얻은 위치와 사용한 애플리케이션 경로를 식별합니다.

SigninLogs
| where UserPrincipalName =~ "<user@company.com>"
| where ResultType == 0
| order by TimeGenerated asc
| take 10
  1. 악의적으로 표시되는 첫 번째 확인된 로그인을 식별합니다.
  2. 해당 로그인을 경고 시간, 사용자 증언 및 피싱 또는 암호 스프레이 표시기와 비교합니다.
  3. 피싱, 암호 재사용, 악의적인 중간 활동, 토큰 도난 또는 MFA 피로와 같은 의심되는 근본 원인을 문서화합니다.

MFA 평가

MFA 상태와 동작을 검토하여 인증 제어가 실패했는지 또는 우회되었는지 확인하세요.

  1. 인시던트 당시 MFA를 <user@company.com> 사용하도록 설정했는지 여부를 확인합니다.
  2. 공격자가 MFA를 충족했는지, MFA를 무시했는지 또는 새 인증 방법을 등록했는지 확인합니다.
  3. 조건부 액세스, 인증 강도, 토큰 보호 또는 등록 컨트롤의 차이를 식별합니다.
  4. MFA 메서드를 다시 설정해야 하는지 또는 최근 MFA 변경 내용을 검토해야 하는지를 기록합니다.

폭발 반경 및 영향 분석

조사를 종료하기 전에 접근 범위와 잠재적 비즈니스 영향을 평가하세요.

  1. 이메일, 파일, 공동 작업 도구, 클라우드 리소스 또는 권한 있는 역할에 대한 액세스에 대한 인시던트 증거를 검토합니다.
  2. 의심스러운 받은 편지함 규칙, 전달 규칙, 동의 부여, 사서함 액세스, 횡적 이동 또는 권한 에스컬레이션을 확인합니다.
  3. 손상된 ID가 액세스한 관련 계정, 디바이스, 애플리케이션 및 워크로드를 식별합니다.
  4. 비즈니스 영향, 데이터 노출, 규제 또는 법적 보고 요구 사항을 예측합니다.

수정 단계

공격자 지속성을 제거하고 ID를 신뢰할 수 있는 상태로 반환하는 작업을 완료합니다.

복구 및 회복

  1. 암호를 재설정하고, 비밀을 회전하며, 모든 활성 세션에 대해 새 로그인이 필요합니다.
  2. 악의적인 받은 편지함 규칙, 전달 규칙, OAuth 앱 동의 또는 권한 없는 인증 방법을 제거합니다.
  3. 승인된 MFA 설정을 복원하고 필요한 경우 인증 방법을 다시 등록합니다.
  4. 엔드포인트 손상이 의심되는 경우 영향을 받는 디바이스를 스캔하거나 이미지로 다시 설치합니다.
  5. 역할 할당, 그룹 멤버 자격 및 애플리케이션 권한을 검토하고 권한 없는 액세스를 제거합니다.
  6. 완료된 작업, 소유자, 타임스탬프 및 증명 정보로 인시던트 레코드를 업데이트합니다.

방지 단계

인시던트에서 얻은 교훈을 사용하여 되풀이 가능성을 줄입니다.

재발 방지

  1. 피싱 방지 MFA, 더 강력한 조건부 액세스 정책 및 사용 가능한 경우 로그인 위험 제어를 적용합니다.
  2. 레거시 인증을 사용하지 않도록 설정하고 사용하지 않는 서비스 계정, 애플리케이션 또는 자격 증명을 제거합니다.
  3. 비정상적인 로그인, MFA 남용, 토큰 남용, 불가능한 이동 및 동의 활동에 대한 검색을 개선합니다.
  4. 피싱 또는 암호 재사용이 인시던트의 원인으로 작용한 경우 <User>, <Team> 또는 <Business unit>에게 맞춤형 사용자 보안 인식 지침을 제공하세요.
  5. 인시던트 후 이 SOP를 검토하고 조직의 자리 표시자, 에스컬레이션 경로 및 임계값을 업데이트합니다.

관련 콘텐츠

  • Last updated on