다음을 통해 공유

보안 인시던트 대응에 대한 권장 사항

  • 아티클

Azure Well-Architected Framework 보안 검사 목록 권장 사항에 적용됩니다.

SE:12 지역화된 문제에서 재해 복구에 이르기까지 다양한 인시던트 범위를 다루는 효과적인 인시던트 대응 절차를 정의하고 테스트합니다. 프로시저를 실행하는 팀 또는 개인을 명확하게 정의합니다.

이 가이드에서는 워크로드에 대한 보안 인시던트 대응을 구현하기 위한 권장 사항을 설명합니다. 시스템에 보안 손상이 있는 경우 체계적인 인시던트 대응 접근 방식을 사용하면 보안 인시던트 식별, 관리 및 완화에 걸리는 시간을 줄일 수 있습니다. 이러한 인시던트가 소프트웨어 시스템 및 데이터의 기밀성, 무결성 및 가용성을 위협할 수 있습니다.

대부분의 기업에는 중앙 보안 운영 팀(SOC(보안 운영 센터) 또는 SecOps라고도 함)이 있습니다. 보안 운영 팀의 책임은 잠재적인 공격을 신속하게 탐지, 우선 순위 지정 및 심사하는 것입니다. 또한 팀은 보안 관련 원격 분석 데이터를 모니터링하고 보안 위반을 조사합니다.

잠재적 및 실현된 위험을 완화하기 위한 공동 작업 접근 방식을 보여 주는 개념 아트입니다.

그러나 워크로드를 보호할 책임도 있습니다. 모든 커뮤니케이션, 조사 및 헌팅 활동은 워크로드 팀과 SecOps 팀 간의 공동 작업입니다.

이 가이드에서는 사용자와 워크로드 팀이 공격을 신속하게 탐지, 심사 및 조사하는 데 도움이 되는 권장 사항을 제공합니다.

정의

용어 정의
경고 인시던트에 대한 정보가 포함된 알림입니다.
경고 충실도 경고를 결정하는 데이터의 정확도입니다. 충실도가 높은 경고에는 즉각적인 조치를 취하는 데 필요한 보안 컨텍스트가 포함됩니다. 충실도가 낮은 경고에는 정보가 부족하거나 노이즈가 포함되어 있습니다.
거짓 긍정 발생하지 않은 인시던트를 나타내는 경고입니다.
인시던트 시스템에 대한 무단 액세스를 나타내는 이벤트입니다.
사고 대응 인시던트와 관련된 위험을 감지, 대응 및 완화하는 프로세스입니다.
심사 보안 문제를 분석하고 완화의 우선 순위를 지정하는 인시던트 대응 작업입니다.

주요 디자인 전략

사용자와 팀은 잠재적인 손상에 대한 신호 또는 경고가 있을 때 인시던트 대응 작업을 수행합니다. 충실도가 높은 경고에는 분석가가 쉽게 결정을 내릴 수 있는 충분한 보안 컨텍스트가 포함되어 있습니다. 충실도가 높은 경고는 가양성의 수가 적습니다. 이 가이드에서는 경고 시스템이 낮은 충실도 신호를 필터링하고 실제 인시던트를 나타낼 수 있는 충실도가 높은 경고에 초점을 맞추고 있다고 가정합니다.

인시던트 알림 할당

보안 경고는 팀과 organization 적절한 사용자에게 도달해야 합니다. 워크로드 팀에서 인시던트 알림을 받을 수 있는 지정된 연락 지점을 설정합니다. 이러한 알림에는 손상된 리소스 및 시스템에 대한 가능한 한 많은 정보가 포함되어야 합니다. 경고에는 다음 단계가 포함되어야 팀이 작업을 신속하게 수행할 수 있습니다.

감사 내역을 유지하는 특수 도구를 사용하여 인시던트 알림 및 작업을 기록하고 관리하는 것이 좋습니다. 표준 도구를 사용하면 잠재적인 법적 조사에 필요할 수 있는 증거를 보존할 수 있습니다. 책임 당사자의 책임에 따라 알림을 보낼 수 있는 자동화를 구현할 기회를 찾습니다. 인시던트 중에 명확한 통신 및 보고 체인을 유지합니다.

SIEM(보안 정보 이벤트 관리) 솔루션 및 organization 제공하는 SOAR(보안 오케스트레이션 자동화 응답) 솔루션을 활용합니다. 또는 인시던트 관리 도구를 조달하고 organization 모든 워크로드 팀에 대해 표준화하도록 장려할 수 있습니다.

심사 팀을 사용하여 조사

인시던트 알림을 받는 팀 구성원은 사용 가능한 데이터를 기반으로 적절한 사용자를 포함하는 심사 프로세스를 설정해야 합니다. 종종 브리지 팀이라고 하는 심사 팀은 의사 소통 모드와 프로세스에 동의해야 합니다. 이 인시던트에는 비동기 토론 또는 브리지 호출이 필요한가요? 팀은 조사 진행 상황을 어떻게 추적하고 전달해야 하나요? 팀에서 인시던트 자산에 액세스할 수 있는 위치는 어디인가요?

인시던트 대응은 시스템의 아키텍처 레이아웃, 구성 요소 수준의 정보, 개인 정보 또는 보안 분류, 소유자 및 핵심 연락 지점과 같은 문서를 최신 상태로 유지하는 중요한 이유입니다. 정보가 부정확하거나 오래된 경우 브리지 팀은 시스템의 작동 방식, 각 영역에 대한 책임, 이벤트의 영향을 이해하려고 노력하는 귀중한 시간을 낭비합니다.

추가 조사를 위해 적절한 사람들을 참여시킵니다. 인시던트 관리자, 보안 책임자 또는 워크로드 중심 잠재 고객을 포함할 수 있습니다. 심사를 집중하려면 문제의 scope 외부에 있는 사용자를 제외합니다. 경우에 따라 별도의 팀이 인시던트 조사를 합니다. 처음에 문제를 조사하고 인시던트 완화를 시도하는 팀과 광범위한 문제를 확인하기 위해 심층 조사를 위해 법의학을 수행할 수 있는 다른 전문 팀이 있을 수 있습니다. 작업 환경을 격리하여 포렌식 팀이 조사를 수행할 수 있도록 할 수 있습니다. 경우에 따라 동일한 팀이 전체 조사를 처리할 수 있습니다.

초기 단계에서 심사 팀은 잠재적인 벡터와 시스템의 기밀성, 무결성 및 가용성( CIA라고도 함)에 미치는 영향을 결정합니다.

CIA의 범주 내에서 피해의 깊이와 수정의 긴급성을 나타내는 초기 심각도 수준을 할당합니다. 심사 수준에서 더 많은 정보가 발견되면 시간이 지남에 따라 이 수준이 변경될 것으로 예상됩니다.

검색 단계에서는 즉각적인 작업 및 통신 계획을 결정하는 것이 중요합니다. 시스템의 실행 상태에 변경 내용이 있나요? 추가 악용을 막기 위해 공격을 포함하려면 어떻게 해야 할까요? 팀은 책임 있는 공개와 같은 내부 또는 외부 통신을 보내야 하나요? 검색 및 응답 시간을 고려합니다. 특정 기간(종종 몇 시간 또는 며칠) 내에 규제 기관에 일부 유형의 위반을 보고할 법적 의무가 있을 수 있습니다.

시스템을 종료하기로 결정한 경우 다음 단계는 워크로드의 DR(재해 복구) 프로세스로 이어지고 있습니다.

시스템을 종료하지 않으면 시스템 기능에 영향을 주지 않고 인시던트를 수정하는 방법을 결정합니다.

인시던트에서 복구

보안 인시던트가 재해처럼 처리합니다. 수정에 완전한 복구가 필요한 경우 보안 관점에서 적절한 DR 메커니즘을 사용합니다. 복구 프로세스는 되풀이 가능성을 방지해야 합니다. 그렇지 않으면 손상된 백업에서 복구하면 문제가 다시 발생합니다. 동일한 취약성이 있는 시스템을 다시 배포하면 동일한 인시던트가 발생합니다. 장애 조치(failover) 및 장애 복구(failback) 단계 및 프로세스의 유효성을 검사합니다.

시스템이 계속 작동하는 경우 시스템의 실행 중인 부분에 미치는 영향을 평가합니다. 적절한 성능 저하 프로세스를 구현하여 다른 안정성 및 성능 목표를 충족하거나 다시 조정하도록 시스템을 계속 모니터링합니다. 완화로 인해 개인 정보를 손상시키지 마세요.

진단은 벡터와 잠재적인 수정 및 대체가 식별될 때까지 대화형 프로세스입니다. 진단 후 팀은 적절한 기간 내에 필요한 수정 사항을 식별하고 적용하는 수정 작업을 진행합니다.

복구 메트릭은 문제를 해결하는 데 걸리는 시간을 측정합니다. 종료 시 수정 시간에 대한 긴급성이 있을 수 있습니다. 시스템을 안정화하려면 수정, 패치 및 테스트를 적용하고 업데이트를 배포하는 데 시간이 걸립니다. 추가 피해 및 인시던트 확산을 방지하기 위한 봉쇄 전략을 결정합니다. 환경에서 위협을 완전히 제거하는 근절 절차를 개발합니다.

절충: 안정성 목표와 수정 시간 사이에는 절충이 있습니다. 인시던트 중에는 다른 비기능적 또는 기능적 요구 사항을 충족하지 못할 수 있습니다. 예를 들어 인시던트 조사 중 시스템 일부를 사용하지 않도록 설정해야 하거나 인시던트 scope 확인할 때까지 전체 시스템을 오프라인으로 전환해야 할 수도 있습니다. 비즈니스 의사 결정자는 인시던트 중에 허용되는 대상이 무엇인지 명시적으로 결정해야 합니다. 해당 결정에 대한 책임이 있는 사람을 명확하게 지정합니다.

인시던트에서 알아보기

인시던트가 디자인 또는 구현에서 간격 또는 취약한 지점을 발견합니다. 이는 기술 디자인 측면, 자동화, 테스트를 포함하는 제품 개발 프로세스 및 인시던트 대응 프로세스의 효율성에 대한 교훈으로 구동되는 개선 기회입니다. 수행된 작업, 타임라인 및 결과를 포함하여 자세한 인시던트 레코드를 유지 관리합니다.

근본 원인 분석 및 회고와 같은 구조화된 인시던트 후 검토를 수행하는 것이 좋습니다. 이러한 검토의 결과를 추적하고 우선 순위를 지정하고 향후 워크로드 디자인에서 학습한 내용을 사용하는 것이 좋습니다.

개선 계획에는 BCDR(비즈니스 연속성 및 재해 복구) 훈련과 같은 보안 훈련 및 테스트에 대한 업데이트가 포함되어야 합니다. BCDR 훈련을 수행하기 위한 시나리오로 보안 손상을 사용합니다. 드릴은 문서화된 프로세스의 작동 방식을 확인할 수 있습니다. 인시던트 응답 플레이북이 여러 대 있으면 안 됩니다. 인시던트 크기 및 효과의 광범위하거나 지역화된 정도에 따라 조정할 수 있는 단일 원본을 사용합니다. 드릴은 가상의 상황을 기반으로 합니다. 저위험 환경에서 훈련을 수행하고 학습 단계를 훈련에 포함합니다.

인시던트 후 검토 또는 사후 평가를 수행하여 대응 프로세스의 약점 및 개선 영역을 식별합니다. 인시던트에서 배운 단원에 따라 IRP(인시던트 대응 계획) 및 보안 제어를 업데이트합니다.

필요한 통신 보내기

사용자에게 중단을 알리고 내부 이해 관계자에게 수정 및 개선 사항을 알리기 위한 통신 계획을 구현합니다. 향후 인시던트 방지를 위해 organization 다른 사용자에게 워크로드의 보안 기준 변경 내용을 알려야 합니다.

내부 사용을 위한 인시던트 보고서를 생성하고 필요한 경우 규정 준수 또는 법적 목적으로 생성합니다. 또한 SOC 팀이 모든 인시던트에 사용하는 표준 형식 보고서(정의된 섹션이 있는 문서 템플릿)를 채택합니다. 조사를 종료하기 전에 모든 인시던트에 연결된 보고서가 있는지 확인합니다.

Azure 촉진

Microsoft Sentinel 은 SIEM 및 SOAR 솔루션입니다. 이는 경고 검색, 위협 가시성, 주도적 헌팅, 위협 대응을 위한 단일 솔루션입니다. 자세한 내용은 Microsoft Sentinel이란?을 참조하세요.

내부 프로세스를 통해 보안 작업에 직접 알림을 받을 수 있도록 Azure 등록 포털에 관리자 연락처 정보가 포함되어 있는지 확인합니다. 자세한 내용은 알림 설정 업데이트를 참조하세요.

클라우드용 Microsoft Defender Azure 인시던트 알림을 수신하는 지정된 연락 지점을 설정하는 방법에 대한 자세한 내용은 보안 경고에 대한 메일 알림 구성을 참조하세요.

조직 맞춤

Azure용 클라우드 채택 프레임워크 인시던트 대응 계획 및 보안 작업에 대한 지침을 제공합니다. 자세한 내용은 보안 작업을 참조하세요.

보안 검사 목록

전체 권장 사항 집합을 참조하세요.

보안 검사 목록