보안 인시던트에 대응

이 문서의 지침은 엔터프라이즈 소유자, 조직 소유자, 보안 관리자 및 보안 팀을 대상으로 합니다. 그러나 이 문서에 설명된 몇 가지 작업을 수행하려면 엔터프라이즈 소유자 역할이 있어야 합니다. 일부 단계에서는 조직 소유자 또는 리포지토리 관리자와의 조정이 필요할 수 있습니다.

Introduction

이 가이드에서는 보안 인시던트에 대응하는 방법, 위협의 GitHub 유효성을 검사 및 조사하는 데 사용할 수 있는 표면 및 이를 포함하고 수정하는 데 사용할 수 있는 도구를 설명합니다.

중요

이 단계는 일반적인 지침입니다. 모든 인시던트가 고유하며 특정 상황에 따라 다른 접근 방식이 필요할 수 있습니다.

플랫폼 관련 질문을 지원할 수 있지만 GitHub 지원 시스템 및 리소스에 영향을 주는 보안 인시던트를 조사하고 대응하는 것이 가장 좋습니다.

필수 조건

이상적으로는 엔터프라이즈에 대해 감사 로그 스트리밍 및 원본 IP 주소 표시 유형 이 이미 활성화되어 있고(데이터를 SIEM(보안 정보 및 이벤트 관리) 시스템으로 스트리밍) 해당 데이터에 액세스할 수 있습니다. 엔터프라이즈에 대한 감사 로그 스트리밍을(를) 참조하세요.

당신의 응답 전체에 걸쳐

응답을 진행하면서 다음을 확인합니다.

증거 보존: 의심스러운 활동의 스크린샷을 찍고, 로그 또는 쿼리 결과를 내보내고, 정리하기 전에 영향을 받는 파일 또는 코드의 복사본을 저장합니다.
레코드 유지: 결과(예: 시간, 날짜, 손상 지표(IoC), 영향을 받는 리포지토리)를 문서화하고 각 결정을 기록합니다.
커뮤니케이션: 중요한 데이터가 위험에 처한 경우 관련 이해 관계자(예: 보안 리드 및 엔지니어링 관리자, 법률 및 개인 정보 보호 팀)에게 알리고 업데이트된 상태로 유지합니다.

1단계: 신호 평가 및 신속하게 유효성 검사

목표는 표시되는 신호가 실제 및 활성 위협이 될 가능성이 있는지 여부를 신속하게 확인하는 것입니다.

1. 식별

표시되는 신호의 특성을 확인합니다. 예를 들어 신호는 다음의 표시를 표시합니다.

자격 증명 손상 (유출된 비밀에 대한 경고, 외부 사이트에서 발견된 자격 증명 보고서)
무단 액세스 또는 계정 손상 (의심스러운 로그인, 익숙하지 않은 커밋 또는 변경에 대한 보고서)
데이터 반출 (의심스러운 파일 변경 또는 추가, 예기치 않은 워크플로 실행, 비정상적인 API 활동, 알 수 없는 리포지토리 만들기 또는 예기치 않은 리포지토리 표시 유형 변경에 대한 보고서)
악성 코드 삽입 (의심스러운 코드 변경, 예기치 않은 워크플로 실행, 추가된 새 파일의 보고서)
공급망 공격 (의심스러운 패키지 버전 보고서, 취약한 종속성에 대한 경고)

조직 또는 기업 전체에서 이러한 위협 신호를 식별하는 데 도움이 되도록 Common security incident investigation areas을 참조하세요.

초기 목표는 위협 신호를 식별 하여 유효성을 검사하고 대응 전략을 정하는 것이므로 조사 초기 단계에서 심층 검사에 너무 많은 시간을 할애하지 않는 것이 좋습니다 .

2. 유효성 검사

잠재적 위협이 진짜인지, 현재 활성 상태인지 여부를 확인하기 위한 증거를 확인합니다.

다음 GitHub 도구와 표면이 도움이 될 수 있습니다.

도구/표면	Purpose
보안 개요 및 보안 경고	조직 또는 기업 전체에서 보안 경고 검토
감사 로그	토큰 생성, 권한 변경 또는 리포지토리 표시 유형 변경과 같이 조사 중인 신호와 관련된 이벤트를 검색합니다.
활동 보기	특정 리포지토리에 대한 푸시, 커밋 및 분기 작업의 타임라인 보기
[

          GitHub 코드 검색](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | 리포지토리에서 특정 파일 이름 또는 코드 패턴과 같은 알려진 손상 지표 검색 |

각 도구에 대한 자세한 내용은 Investigation tools for security incidents을 참조하세요.

유효성 검사 단계는 빠를 수 있습니다 .

신호가 실제 및 활성 위협이 될 가능성이 있는지 여부를 결정하기에 충분한 증거를 수집하는 것을 목표로합니다.
신호를 가양성으로 신속하게 배제할 수 없는 경우 실제라고 가정합니다.
심층 조사는 나중에 수행할 수 있습니다.

3. 결정

수집된 증거에 따라 다음 세 가지를 결정합니다.

       **이것이 진짜 위협인가요?** 신호를 가양성으로 빠르게 자신 있게 배제할 수 없는 경우, 실제 신호로 간주하고 격리 조치를 진행합니다.

       **위협이 여전히 활성 상태입니까?** 공격자가 여전히 액세스 권한이 있거나 활동이 진행 중인 경우 먼저 즉각적인 봉쇄 작업의 우선 순위를 지정합니다. 침해가 과거의 기록으로 보이는 경우에도 조사와 수정을 수행해야 하지만, 응답을 계획하는 데 더 많은 시간이 있을 수 있습니다.

       **잠재적인 범위는 무엇인가요?** 침해가 단일 자격 증명, 리포지토리, 조직, 또는 전체 기업에까지 미칠 수 있는 범위를 고려해 보십시오. 이렇게 하면 응답을 적절하게 조정하는 데 도움이 됩니다.

의심스러운 경우 위협을 실제로 처리하고 증거가 허용하는 대로 응답을 축소합니다.

2단계: 위협 억제

다음 단계에서는 실제 및 활성 위협을 처리하고 있다고 가정합니다. 이제 목표는 지금까지 알고 있는 것을 사용하여 지속적인 위험을 즉시 줄이는 것입니다.

공격자의 액세스 및 기능을 제한하기 위해 수행할 수 있는 몇 가지 포함 작업이 있습니다.

중요

위협의 특성, 잠재적 범위 및 이 시점에서 가지고 있는 증거에 따라 작업을 선택해야 합니다. 모든 인시던트에 대해 이러한 작업을 모두 수행하지 않는 것이 좋습니다. 일부 작업은 다른 작업보다 더 파괴적이거나 파괴적이므로 위의 위협 특성에 대한 평가에 따라 각 작업의 위험과 이점을 평가해야 합니다.

손상된 자격 증명 해지

노출되거나 악용된 자격 증명의 경우 영향을 받는 자격 증명을 해지하여 추가 오용을 방지하기 위해 수행할 수 있는 가장 즉각적인 조치입니다.

API를 통해 해지

토큰이 다음 형식 중 하나이며 토큰의 리터럴 값이 알려진 경우 사용자(또는 다른 사람)는 REST API를 통해 요청을 제출하여 토큰을 해지할 수 있습니다. 취소을(를) 참조하세요.
- Personal access token (classic)
- Fine-grained personal access token
해지 및 포함 옵션

자격 증명 액세스를 차단하는 추가 옵션이 있습니다. 자격 증명 유형별 전체 목록은 GitHub 자격 증명 형식 참조을 참조하세요.
긴급 조치(주요 인시던트)

엔터프라이즈 소유자는 GitHub Enterprise Cloud 대량 긴급 조치를 취하여 기업 전체에서 액세스를 잠글 수 있습니다. 엔터프라이즈의 Enterprise Managed Users경우 여기에는 모든 사용자 토큰 및 키 삭제가 포함됩니다. 자동화를 중단시키고, 주요 인시던트를 위해서만 사용해야 하는 강력한 조치들입니다. 엔터프라이즈의 보안 인시던트에 대응을(를) 참조하세요.

액세스 제한

엔터프라이즈, 조직 또는 리포지토리에 대한 액세스를 제한하기 위해 수행할 수 있는 몇 가지 즉각적인 작업이 있습니다.

IP 허용 목록 구성

알 수 없거나 의심스러운 IP 주소가 조직 또는 엔터프라이즈에 액세스하지 못하도록 차단합니다. IP 허용 목록을 사용하여 엔터프라이즈에 대한 네트워크 트래픽 제한(엔터프라이즈 관리자) 및 조직에 허용되는 IP 주소 관리(조직 소유자)을 참조하세요.
손상되거나 의심스러운 사용자 제거

사용자를 제거하거나 계정을 일시 중단합니다. (조직 소유자)을 참조하세요.
리포지토리 표시 유형을 프라이빗으로 변경

영향을 받는 리포지토리의 가시성을 프라이빗으로 변경하고 다른 사용자가 추가로 변경할 수 있는 기능을 제한합니다. 예를 들어 중요한 코드가 조직에 속한 공용 리포지토리에 노출되었거나 악의적인 행위자가 리포지토리의 표시 설정을 프라이빗에서 퍼블릭으로 변경한 경우 리포지토리의 표시 유형을 변경할 수 있습니다. 리포지토리 표시 유형 설정(리포지토리 관리자 및 조직 소유자) 및 조직의 리포지토리 표시 유형 변경 제한(조직 소유자)을 참조하세요.
긴급 조치(주요 인시던트)

엔터프라이즈 소유자는 GitHub Enterprise Cloud 대량 긴급 조치를 취하여 기업 전체에서 액세스를 잠글 수 있습니다. 여기에는 모든 비소유자 액세스를 차단하도록 SSO를 잠그 고 조직 전체에서 모든 사용자 SSO 권한 부여를 취소하는 것이 포함됩니다. 자동화를 손상시키는 고충격 작업으로, 이러한 작업은 주요 인시던트에만 사용해야 합니다. 엔터프라이즈의 보안 인시던트에 대응을(를) 참조하세요.

악의적인 아티팩트 및 활동 사용 안 함

악성 워크플로 실행 중지

워크플로 또는 실행기를 GitHub Actions 활성 공격의 일부로 사용하는 것으로 의심되는 경우 다음 작업을 수행할 수 있습니다.
- 영향을 받는 리포지토리에 대해 진행 중인 워크플로 실행을 취소합니다. 워크플로 실행 취소을(를) 참조하세요.
- 조직의 영향을 받는 리포지토리 또는 특정 조직에 대해 사용하지 않도록 설정합니다 GitHub Actions . 조직에 대한 GitHub Actions 사용하지 않도록 설정 또는 제한(조직 소유자) 및 엔터프라이즈에서 GitHub Actions 대한 정책 적용(엔터프라이즈 관리자)을 참조하세요.
- 자체 호스팅 실행기를 제거합니다. 자체 호스트형 실행기 제거을(를) 참조하세요.
웹후크 사용 안 함

손상된 리포지토리 또는 조직 웹후크가 라이브 데이터 반출 채널로 사용되고 있다고 의심되는 경우 사용하지 않도록 설정할 수 있습니다. 웹후크 사용 중지하기을(를) 참조하세요.
유해한 브랜치 삭제

악성 코드 또는 워크플로가 포함된 분기를 식별한 경우 즉시 삭제하여 실행을 방지합니다. 리포지토리 내에서 분기 만들기 및 삭제을(를) 참조하세요.

3단계: 전체 조사

즉각적으로 봉쇄한 후에 이제 목표는 인시던트의 전체 범위와 영향을 이해하고, 모든 침해 지표(IoC) 및 지속성 메커니즘을 식별하며, 위협을 완전히 봉쇄하고 수정하는 데 필요한 모든 증거를 수집하는 것입니다.

중요

인시던트 응답은 선형 프로세스가 아닙니다. 새 IoC를 검색하거나 공격에 대해 자세히 이해할 때 조사, 포함 및 수정을 반복해야 할 수 있습니다.

당신이 본 신호와 지금까지 수집 된 증거에 따라, 무슨 일이 있었는지에 대한 작업 가설 을 개발하고 그 가설을 증명하거나 반증하는 데 필요한 추가 증거를 결정합니다.
```
       **AUTOTITLE**에 설명된 다양한 [조사 영역을 고려하여 조사를](/code-security/reference/security-incident-response/investigation-areas) 안내합니다.
```
조사를 한 줄의 조사로 제한하지 마세요. 많은 공격은 자격 증명 악용, 워크플로 파일 삽입 및 데이터 반출과 결합된 악성 패키지 설치와 같은 기술을 조합하여 사용합니다. 모든 잠재적인 공격 벡터를 조사하고 있는지 확인합니다.
지금까지 알려진 모든 IoC를 문서화하고, GitHub의 모든 표면에서 흔적을 찾으세요.
영향을 받는 모든 워크플로, 리포지토리 및 조직을 인벤토리하여 인시던트 범위를 체계적으로 캡처합니다.
- 리포지토리 이름, 영향을 받은 항목(코드, 비밀, 워크플로) 및 손상 타임라인을 포함합니다.
- 영향을 받는 모든 계정 및 자격 증명 목록을 만듭니다. 노출되거나 오용되었을 수 있는 토큰, SSH 키 또는 기타 자격 증명을 확인합니다.
증거에 대해 작업 이론의 유효성을 검사합니다.
- 수집한 증거를 검토합니다. 초기 가설을 지원하나요?
- 다른 설명을 고려해 보세요. 관찰한 활동에 다른 원인이 있을 수 있나요?
- 가설이 반증되면 증거에 따라 새로운 가설을 작성하고 필요에 따라 조사 단계를 반복합니다.
새로운 IoC 또는 즉각적인 조치가 필요한 진행 중인 활동의 증거를 발견하면 격리 조치로 돌아갑니다.

발생한 일과 근본 원인에 대한 이해가 높으면 결과를 문서화하고 수정을 진행합니다.

4단계: 수정

이제 목표는 손상의 모든 추적을 제거하고, 근본 원인을 수정하고, 시스템을 안전한 상태로 복원하는 것입니다. 수정 작업은 사용자가 직면한 악용에 따라 달라지지만 몇 가지 모범 사례는 다음과 같습니다.

토큰 및 비밀 회전

자격 증명이 손상되었는지 확실하지 않더라도 노출 가능성이 있으면 자격 증명을 교체합니다.

새 토큰 및 비밀을 생성하여 해지되었거나 노출되었을 수 있는 토큰을 대체합니다.
리포지토리, 환경 및 조직 수준에 저장된 GitHub 비밀을 회전합니다.
손상된 토큰을 사용하여 액세스되었을 수 있는 외부 시스템의 자격 증명을 업데이트합니다.
앞으로 정기적인 회전을 장려하기 위해 토큰 만료 정책을 사용하도록 설정하는 것이 좋습니다. Enterprise에서 개인용 액세스 토큰에 대한 정책 적용을(를) 참조하세요.

지속성 메커니즘 감사를 수행하다

초기 봉쇄 작업 후에도 액세스를 유지하기 위해 공격자가 설정했을 수 있는 지속성 메커니즘을 확인해야 합니다.

여기에는 다음과 같은 사항을 확인하는 것이 포함되지만 이에 국한되지는 않습니다.

추가되거나 수정되었을 수 있는 의심스럽거나 익숙하지 않은 워크플로 파일입니다.
익숙하지 않은 도메인을 가리키는 새 웹후크입니다.
새로운 자체 호스팅 주자.
자체 호스팅 실행기에 대한 수정.
새로 설치된 GitHub Apps 또는 OAuth app 권한.
리포지토리에 추가된 새 배포 키입니다.
새 이진 파일 또는 실행 파일.

종속성 감사 및 다시 설치

손상된 종속성은 공격 벡터 역할을 할 수 있습니다. 종속성에 대한 전체 감사를 수행하고 신뢰할 수 있는 원본에서 다시 설치해야 합니다.

취약한 종속성 및 사용 가능한 경우 Dependabot 악성 패키지에 대한 경고를 검토 Dependabot malware alerts 합니다. (Dependabot malware alerts는 현재 npm 에코시스템에서 사용할 수 있습니다.) 추가 맬웨어 경고를 조사하려면 type:malware을(를) GitHub Advisory Database에서 검색하고 종속성 그래프를 감사하여 일치 항목을 확인하십시오.
종속성을 정상 버전에 고정하거나 SHA를 커밋하고 패키지 레지스트리에서 다시 설치합니다.

시정 확인

수정 작업이 성공했음을 확인합니다.

경고를 검토 code scanning 하여 코드 취약성이 해결되었으며 새로운 취약성이 도입되지 않은지 확인합니다.
경고를 검토 secret scanning 하여 모든 리포지토리에 비밀이 노출되지 않고 모든 경고가 해결되었는지 확인합니다.
인시던트 후 며칠 및 몇 주 동안 감사 로그 및 기타 관련 표면을 계속 검토하고 모니터링합니다.

5단계 문서

나머지 단계와 향후 참조를 위해서는 철저한 설명서가 필요합니다.

조사 중에 검색된 모든 IoC를 기록합니다.
타임스탬프 및 각 작업을 수행한 사용자를 포함하여 수행된 모든 수정 단계를 문서화합니다.
영향을 받는 리포지토리, 워크플로 및 계정의 인벤토리를 유지 관리합니다.
결정된 사항과 그 뒤에 있는 추론을 문서화합니다.
규정 준수, 법적 또는 개인 정보 보호에 미치는 영향을 적어 둡니다. 이 인시던트가 알림이 필요한 데이터 위반인지 여부를 고려합니다.

6단계: 반영 및 강화

이제 목표는 인시던트로부터 배우고 유사한 인시던트 방지를 위해 보안 태세를 강화하는 것입니다.

       **시던트 요약**을 작성하십시오. 여기에는 첫 번째 표시부터 해결까지의 이벤트 타임라인과 근본 원인 분석, 수행된 결정 및 작업 및 학습된 교훈이 포함되어야 합니다.

보안 인시던트에서 미해결 작업 항목을 문제(예: 남은 수정 작업 및 학습된 교훈에 따라 구현해야 하는 보안 개선 사항)를 추적합니다.
아직 없는 경우, 회사 또는 팀에 최신의 보안 인시던트 대응 계획이 있는지 확인하세요. 여기에는 정의된 역할 및 책임, 에스컬레이션 경로, 통신 프로토콜, 심각도 분류 조건 및 일반적인 위협 유형에 대한 단계별 대응 절차가 포함되어야 합니다. Copilot 는 특정 요구 사항 및 리소스에 따라 이 계획을 생성하고 구체화하는 데 도움이 될 수 있습니다. 추가 지침 은 인시던트 대응이란?을 참조하세요.

다음 단계

아직 보안 태세를 강화하지 않은 경우 향후 인시던트의 위험을 줄이는 것이 좋습니다. Protecting against security threats을(를) 참조하세요.

이 기사에서