다음을 통해 공유


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

Power Platform Well-Architected 보안 체크리스트 권장 사항에 적용:

남동:11 국지적 문제부터 재해 복구까지 다양한 사고를 포괄하는 효과적인 인시던트 대응 절차를 정의하고 테스트하세요. 어떤 팀이나 개인이 절차를 실행하는지 명확하게 정의합니다.

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

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

잠재적인 위험과 실현된 위험을 완화하기 위한 협업적 접근 방식을 보여주는 개념 미술입니다.

그러나 워크로드를 보호할 책임도 있습니다. 모든 커뮤니케이션, 조사 및 검색 활동은 워크로드 팀과 SecOps 팀 간의 공동 노력이라는 것이 중요합니다.

이 가이드는 귀하와 귀하의 워크로드 팀이 공격을 신속하게 감지, 분류 및 조사하는 데 도움이 되는 권장 사항을 제공합니다.

정의

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

주요 디자인 전략

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

인시던트 알림 할당

보안 경고는 팀과 조직의 적절한 사람에게 전달되어야 합니다. 인시던트 알림을 받을 수 있도록 워크로드 팀에 지정된 연락 창구를 설정하세요. 이러한 알림에는 손상된 리소스와 시스템에 대해 최대한 많은 정보가 포함되어야 합니다. 경고에는 다음 단계가 포함되어야 팀에서 조치를 신속하게 수행할 수 있습니다.

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

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

분류 팀과 함께 조사

인시던트 알림을 받은 팀원은 사용 가능한 데이터를 기반으로 적절한 사람을 포함하는 분류 프로세스를 설정할 책임이 있습니다. 브리지 팀 이라고도 불리는 분류 팀은 의사소통 방식과 프로세스에 동의해야 합니다. 이 인시던트에는 비동기식 토론이나 브리지 통화가 필요합니까? 팀은 조사 진행 상황을 어떻게 추적하고 전달해야 합니까? 팀은 어디에서 인시던트 자산에 액세스할 수 있나요?

인시던트 대응은 시스템의 아키텍처 레이아웃, 구성 요소 수준의 정보, 개인 정보 보호 또는 보안 분류, 담당자 및 주요 연락처와 같은 문서를 최신 상태로 유지하는 중요한 이유입니다. 정보가 부정확하거나 오래된 경우 브리지 팀은 시스템 작동 방식, 각 영역의 책임자, 이벤트의 영향을 파악하는 데 귀중한 시간을 낭비하게 됩니다.

추가 조사를 위해서는 적절한 사람을 참여시키십시오. 인시던트 관리자, 보안 담당자 또는 워크로드 중심 책임자를 포함할 수 있습니다. 분류에 집중하려면 문제 범위를 벗어난 사람을 제외하세요. 때때로 별도의 팀이 사건을 조사합니다. 처음에 문제를 조사하고 사건을 완화하려고 시도하는 팀이 있을 수도 있고, 광범위한 문제를 확인하기 위해 심도 있는 조사를 위해 포렌식을 수행할 수 있는 또 다른 전문 팀이 있을 수도 있습니다. 포렌식 팀이 조사를 수행할 수 있도록 워크로드 환경을 격리할 수 있습니다. 어떤 경우에는 동일한 팀이 전체 조사를 처리할 수도 있습니다.

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

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

발견 단계에서는 즉각적인 조치 과정과 의사소통 계획을 결정하는 것이 중요합니다. 시스템의 실행 상태에 변경 사항이 있습니까? 추가 악용을 막기 위해 공격을 어떻게 억제할 수 있습니까? 팀에서 책임 있는 공개와 같은 내부 또는 외부 커뮤니케이션을 보내야 하나요? 감지 및 응답 시간을 고려하십시오. 특정 기간(종종 몇 시간 또는 며칠) 내에 일부 유형의 위반을 규제 당국에 보고해야 할 법적 의무가 있을 수 있습니다.

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

시스템을 종료하지 않는 경우 시스템 기능에 영향을 주지 않고 문제를 해결하는 방법을 결정하십시오.

인시던트에서 복구

보안 인시던트를 재난처럼 다루십시오. 수정에 전체 복구가 필요한 경우 보안 관점에서 적절한 DR 메커니즘을 사용하십시오. 회복 과정은 재발 가능성을 방지해야 합니다. 그렇지 않고 손상된 백업에서 복구하면 문제가 다시 발생합니다. 동일한 취약점이 있는 시스템을 재배포하면 동일한 인시던트가 발생합니다. 장애 조치 및 장애 복구 단계와 프로세스를 검증합니다.

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

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

복구 메트릭은 문제를 해결하는 데 걸리는 시간을 측정합니다. 서비스가 종료되는 경우 복구 시간과 관련하여 긴급한 상황이 발생할 수 있습니다. 시스템을 안정화하려면 수정 사항, 패치, 테스트를 적용하고 업데이트를 배포하는 데 시간이 걸립니다. 추가 피해와 사건 확산을 방지하기 위한 봉쇄 전략을 결정합니다. 환경에서 위협을 완전히 제거하기 위한 근절 절차를 개발합니다.

트레이드오프: 신뢰성 목표와 수정 시간 사이에는 트레이드오프가 있습니다. 인시던트가 발생하면 다른 비기능적 또는 기능적 요구 사항을 충족하지 못할 가능성이 높습니다. 예를 들어, 인시던트를 조사하는 동안 시스템의 일부를 비활성화해야 하거나 인시던트의 범위를 확인할 때까지 전체 시스템을 오프라인 상태로 전환해야 할 수도 있습니다. 비즈니스 의사 결정자는 사고 중에 허용 가능한 대상이 무엇인지 명시적으로 결정해야 합니다. 해당 결정에 책임이 있는 사람을 명확하게 지정하십시오.

인시던트에서 배우기

인시던트는 설계 또는 구현의 격차나 취약한 지점을 드러냅니다. 이는 기술 설계 측면, 자동화, 테스트를 포함하는 제품 개발 프로세스, 사고 대응 프로세스의 효율성에 대한 교훈을 바탕으로 추진되는 개선 기회입니다. 취해진 조치, 타임라인, 조사 결과를 포함하여 상세한 인시던트 레코드를 유지합니다.

근본 원인 분석, 회고 등 체계적인 인시던트 후 검토를 수행하는 것이 좋습니다. 검토 결과를 추적하고 우선 순위를 지정하고, 학습한 내용을 향후 워크로드 설계에 활용하는 것을 고려하세요.

개선 계획에는 BCDR(비즈니스 연속성 및 재해 복구) 훈련과 같은 보안 훈련 및 테스트에 대한 업데이트가 포함되어야 합니다. BCDR 훈련을 수행하기 위한 시나리오로 보안 손상을 사용하십시오. 훈련을 통해 문서화된 프로세스가 어떻게 작동하는지 검증할 수 있습니다. 인시던트 대응 플레이북이 여러 개 있어서는 안 됩니다. 인시던트의 규모와 그 영향이 얼마나 광범위하거나 국지적인지에 따라 조정할 수 있는 단일 소스를 사용하십시오. 훈련은 가상의 상황을 기반으로 합니다. 위험도가 낮은 환경에서 훈련을 실시하고 훈련에 학습 단계를 포함시킵니다.

인시던트 후 검토 또는 사후 분석을 수행하여 대응 프로세스의 약점과 개선 영역을 식별합니다. 인시던트에서 배운 교훈을 바탕으로 인시던트 대응 계획(IRP)과 보안 통제를 업데이트하세요.

필요한 커뮤니케이션 보내기

사용자에게 중단 사실을 알리고 내부 이해 관계자에게 수정 및 개선 사항을 알리는 커뮤니케이션 계획을 구현합니다. 향후 인시던트를 방지하려면 조직의 다른 사람들에게 워크로드 보안 기준의 변경 사항을 알려야 합니다.

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

Power Platform 간편 사용

다음 섹션에서는 보안 인시던트 대응 절차의 일부로 사용할 수 있는 메커니즘을 설명합니다.

Microsoft Sentinel

Microsoft Power Platform용 Microsoft Sentinel 솔루션을 통해 고객은 다음을 포함한 다양한 의심스러운 활동을 감지할 수 있습니다.

  • 권한이 없는 지역에서 Power Apps 실행
  • Power Apps로 의심스러운 데이터 파괴
  • Power Apps의 대량 삭제
  • Power Apps를 통한 피싱 공격
  • 퇴사하는 직원에 의한 Power Automate 흐름 활동
  • 환경에 추가된 Microsoft Power Platform 커넥터
  • Microsoft Power Platform 데이터 손실 방지 정책 업데이트 또는 제거

자세한 내용은 Microsoft Power Platform용 Microsoft Sentinel 솔루션 개요를 참조하십시오

Microsoft Purview 활동 로깅

Power Apps, Power Automate, 커넥터, 데이터 손실 방지 및 Power Platform 관리 활동 로깅은 Microsoft Purview 규정 준수 포털에서 추적하고 볼 수 있습니다.

자세한 내용은 다음을 참조하세요.

고객 Lockbox(프리뷰)

Microsoft 직원(하위 프로세서 포함)이 수행하는 대부분의 작업, 지원, 문제 해결에는 고객 데이터에 대한 액세스가 필요하지 않습니다. Power Platform 고객 Lockbox를 통해 Microsoft는 드물게 고객 데이터에 대한 데이터 액세스가 필요할 때 고객이 데이터 액세스 요청을 검토 및 승인(또는 거부)할 수 있는 인터페이스를 제공합니다. 이는 고객이 시작한 지원 티켓이나 Microsoft에서 식별한 문제에 대한 응답으로 Microsoft 엔지니어가 고객 데이터에 액세스해야 하는 경우에 사용됩니다. 자세한 내용은 Power Platform 및 Dynamics 365의 고객 Lockbox를 사용하여 고객 데이터에 안전하게 액세스를 참조하세요.

보안 업데이트

서비스 팀은 시스템의 보안을 보장하기 위해 정기적으로 다음을 수행합니다.

  • 가능한 보안 취약점을 식별하는 서비스의 검색.
  • 키 보안 제어가 효과적으로 작동하는지 확인하기 위한 서비스 평가.
  • 외부 취약점 인식 사이트를 정기적으로 모니터링하는 Microsoft Security Response Center(MSRC)에서 식별된 취약점에 노출되는지 확인하기 위한 서비스 평가.

또한 이러한 팀은 식별된 문제를 식별 및 추적하고 필요한 경우 위험을 완화하기 위한 신속한 조치를 취합니다.

보안 업데이트에 대해 확인하는 방법

서비스 팀은 서비스 가동 중지를 요구하지 않는 방식으로 위험 완화를 적용하려고 노력하고 있으므로 관리자는 대개 보안 업데이트에 대한 메시지 센터 알림을 볼 수 없습니다. 보안 업데이트에 서비스 영향이 필요한 경우 계획된 유지 관리로 간주되며 예상되는 영향 시간과 작업이 수행되는 기간과 함께 게시됩니다.

보안에 대한 자세한 내용은 Microsoft 보안 센터를 참조하십시오.

유지 관리 기간 관리

Microsoft는 보안, 성능, 가용성을 보장하고 새로운 기능을 제공하기 위해 정기적으로 업데이트 및 유지 관리를 수행합니다. 이 업데이트 프로세스는 보안 및 사소한 서비스 개선을 매주 제공하며, 각 업데이트는 스테이션에 정렬된 안전한 배포 일정에 따라 지역별로 배포됩니다. 환경의 기본 유지 관리 기간에 대한 자세한 내용은 서비스 인시던트에 대한 정책 및 통신을 참조하십시오. 유지 관리 기간 관리도 참조하세요.

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

조직 정렬

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

보안 체크리스트

전체 권장 사항 세트를 참조하세요.