보안 도메인: 운영 보안
운영 보안 도메인을 통해 ISV는 위협 행위자가 직면한 수많은 위협에 대해 강력한 보안 완화 기술을 구현할 수 있습니다. 이는 운영 환경 및 소프트웨어 개발 프로세스를 보호하여 보안 환경을 빌드하도록 설계되었습니다.
인식 교육
보안 인식 교육은 보안 위반의 90% 이상과 관련된 인적 오류로 인한 위험을 최소화하는 데 도움이 되므로 조직에서 중요합니다. 직원이 보안 조치 및 절차의 중요성을 이해하는 데 도움이 됩니다. 보안 인식 교육이 제공되면 사용자가 잠재적 위협을 인식하고 대응하는 방법을 알고 있는 보안 인식 문화의 중요성을 강화합니다. 효과적인 보안 인식 교육 프로그램에는 소셜 엔지니어링, 암호 관리, 개인 정보 보호 및 물리적 보안과 같이 사용자가 직면할 수 있는 광범위한 topics 및 위협을 다루는 콘텐츠가 포함되어야 합니다.
컨트롤 번호 1
다음과 같은 증거를 제공하세요.
이 organization 정보 시스템 사용자(관리자, 고위 임원 및 계약자 포함)에게 확립된 보안 인식 교육을 제공합니다.
새 사용자를 위한 초기 교육의 일부로 사용됩니다.
정보 시스템 변경에 필요한 경우.
조직에서 정의한 인식 교육 빈도입니다.
개별 정보 시스템 보안 인식 활동을 문서화 및 모니터링하고 organization 정의된 빈도를 통해 개별 학습 레코드를 유지합니다.
의도: 새 사용자를 위한 교육
이 하위 지점은 역할과 관계없이 모든 직원과 organization 참여하는 신입 직원을 위해 설계된 필수 보안 인식 교육 프로그램을 수립하는 데 중점을 둡니다. 여기에는 관리자, 고위 임원 및 계약자가 포함됩니다. 보안 인식 프로그램은 organization 정보 보안 프로토콜, 정책 및 모범 사례에 대한 기본 지식을 부여하여 organization 모든 구성원이 통합된 보안 표준 집합에 부합하여 복원력 있는 정보 보안 환경을 만들도록 설계된 포괄적인 커리큘럼을 포함해야 합니다.
지침: 새 사용자를 위한 교육
대부분의 조직은 플랫폼 기반 보안 인식 교육과 정책 설명서 및 레코드와 같은 관리 설명서의 조합을 활용하여 organization 전체의 모든 직원에 대한 교육 완료를 추적합니다. 제공된 증거는 직원이 교육을 완료했음을 보여줘야 하며, 보안 인식 요구 사항을 설명하는 지원 정책/절차를 통해 백업해야 합니다.
예시 증거: 새 사용자 교육
다음 스크린샷은 새 직원의 온보딩을 추적하는 데 사용되는 Confluence 플랫폼을 보여줍니다. 배정, 역할, 부서 등을 포함하여 신입 사원을 위한 JIRA 티켓이 제기되었습니다. 새로운 시작 프로세스를 통해 보안 인식 교육이 선택되어 2023년 2월 28일 기한까지 완료되어야 하는 직원에게 할당되었습니다.
스크린샷은 직원이 보안 인식 교육을 성공적으로 완료할 때 Knowb4에서 생성된 완료 인증서를 보여줍니다. 완료 날짜는 할당된 기간 내에 있는 2023년 2월의 21st 입니다.
의도: 정보 시스템 변경.
이 하위 지점의 목적은 organization 정보 시스템에 중대한 변경이 있을 때마다 적응형 보안 인식 교육이 시작되도록 하기 위한 것입니다. 소프트웨어 업데이트, 아키텍처 변경 또는 새로운 규정 요구 사항으로 인해 수정이 발생할 수 있습니다. 업데이트된 교육 세션을 통해 모든 직원에게 새로운 변경 내용과 보안 조치에 미치는 영향에 대한 정보를 제공하므로 그에 따라 작업 및 결정을 조정할 수 있습니다. 이러한 사전 예방적 접근 방식은 시스템 변경으로 인해 발생할 수 있는 취약성으로부터 organization 디지털 자산을 보호하는 데 매우 중요합니다.
지침: 정보 시스템 변경.
대부분의 조직은 플랫폼 기반 보안 인식 교육과 정책 설명서 및 레코드와 같은 관리 설명서의 조합을 활용하여 모든 직원에 대한 교육 완료를 추적합니다. 제공된 증거는 다양한 직원이 organization 시스템의 다양한 변경 내용을 기반으로 교육을 완료했음을 입증해야 합니다.
예시 증거: 정보 시스템 변경.
다음 스크린샷은 다양한 직원에게 보안 인식 교육을 할당하고 피싱 시뮬레이션이 발생함을 보여 줍니다.
플랫폼은 시스템 변경이 발생하거나 테스트가 실패할 때마다 새 학습을 할당하는 데 사용됩니다.
의도: 인식 학습 빈도입니다.
이 하위 지점의 목적은 주기적인 보안 인식 학습을 위한 organization 특정 빈도를 정의하는 것입니다. 이는 매년, 반기 또는 organization 의해 결정되는 다른 간격으로 예약될 수 있습니다. organization 빈도를 설정하여 사용자가 새로운 보호 조치 및 정책뿐만 아니라 위협의 진화하는 환경에 대해 정기적으로 업데이트되도록 합니다. 이 방법은 모든 사용자 간에 높은 수준의 보안 인식을 유지하고 이전 교육 구성 요소를 강화하는 데 도움이 될 수 있습니다.
지침: 인식 교육 빈도입니다.
대부분의 조직에는 보안 인식 교육을 위한 요구 사항 및 절차를 간략하게 설명/구현하고 학습 빈도를 정의하는 관리 설명서 및/또는 기술 솔루션이 있습니다. 제공된 증거는 정의된 기간 내에 다양한 인식 학습을 완료하고 organization 정의된 기간이 존재한다는 것을 보여 주어야 합니다.
예시 증거: 인식 학습 빈도입니다.
다음 스크린샷은 보안 인식 정책 설명서의 스냅샷과 해당 설명서가 존재하고 유지 관리됨을 보여 줍니다. 정책은 정책의 scope 섹션에 설명된 대로 organization 모든 직원이 보안 인식 교육을 받아야 합니다. 교육은 관련 부서에서 매년 할당하고 완료해야 합니다.
정책 문서에 따르면 organization 모든 직원은 과제 후 20일 이내에 매년 3개 과정(교육 1회 및 평가 2회)을 완료해야 합니다. 과정은 이메일을 통해 발송되고 KnowBe4를 통해 할당되어야 합니다.
제공된 예제에서는 정책의 스냅샷만 보여 줍니다. 전체 정책 문서가 제출될 것이라는 기대가 있습니다.
두 번째 스크린샷은 정책의 연속이며, 연간 학습 요구 사항을 의무화하는 문서의 섹션을 보여 줍니다. organization 정의한 인식 교육 빈도는 매년 로 설정되어 있음을 보여줍니다.
다음 두 스크린샷은 앞에서 언급한 학습 평가의 성공적인 완료를 보여 줍니다. 스크린샷은 두 명의 다른 직원으로부터 촬영되었습니다.
의도: 설명서 및 모니터링.
이 하위 지점의 목적은 각 사용자의 보안 인식 교육 참여에 대한 세심한 레코드를 만들고, 유지 관리하고, 모니터링하는 것입니다. 이러한 레코드는 organization 정의된 기간 동안 보존되어야 합니다. 이 설명서는 규정 및 내부 정책을 준수하기 위한 감사 가능한 추적 역할을 합니다. 모니터링 구성 요소를 사용하면 organization 의 효과를 평가할 수 있습니다.
교육, 개선 영역 식별 및 사용자 참여 수준 이해 정의된 기간 동안 이러한 레코드를 유지함으로써 organization 장기적인 효과 및 규정 준수를 추적할 수 있습니다.
지침: 설명서 및 모니터링.
보안 인식 학습을 위해 제공할 수 있는 증거는 학습이 organization 수준에서 구현되는 방법에 따라 달라집니다. 여기에는 교육을 플랫폼을 통해 수행되는지 아니면 사내 프로세스를 기반으로 내부적으로 수행되는지 여부가 포함될 수 있습니다. 제공된 증거는 기간 동안 모든 사용자에 대해 완료된 학습의 기록 레코드가 존재하고 이를 추적하는 방법을 보여 주어야 합니다.
예시 증거: 설명서 및 모니터링.
다음 스크린샷은 참가 날짜, 학습 완료 및 다음 학습이 예약된 시기를 포함하여 각 사용자의 기록 학습 기록을 보여줍니다. 이 문서의 평가는 각 직원에 대한 보안 인식에 대한 교육 기록을 최신 상태로 유지하기 위해 정기적으로 그리고 적어도 일년에 한 번 수행됩니다.
맬웨어 보호/맬웨어 방지
맬웨어는 맬웨어 특성에 따라 운영 환경에 발생하는 보안 영향을 변경할 수 있는 조직에 상당한 위험을 초래합니다. 위협 행위자가 랜섬웨어 스타일 맬웨어 공격의 성장을 통해 실현된 맬웨어의 수익이 성공적으로 창출될 수 있음을 깨달았습니다. 맬웨어를 사용하여 위협 행위자가 환경을 손상하여 중요한 데이터(예: 원격 액세스 트로이 목마/루트킷)를 손상할 수 있는 수신 지점을 제공할 수도 있습니다. 따라서 조직은 이러한 위협으로부터 보호하기 위해 적절한 메커니즘을 구현해야 합니다. 사용할 수 있는 방어는 AI(인공 지능)를 사용한 바이러스 백신(AV)/EDR(엔드포인트 검색 및 응답)/EDPR(엔드포인트 검색 및 보호 응답)/추론 기반 검사입니다. 맬웨어의 위험을 완화하기 위해 다른 기술을 배포한 경우 인증 분석가에게 이것이 의도에 부합하는지 여부를 살펴볼 수 있는 사람을 알려주세요.
컨트롤 번호 2
맬웨어 방지 솔루션이 모든 샘플링된 시스템 구성 요소에서 활성화되고 다음 조건을 충족하도록 구성되었다는 증거를 제공하세요.
액세스 중인 검사가 활성화되고 서명이 1일 이내에 최신 상태인 바이러스 백신이 있으면 입니다.
맬웨어가 검색될 때 맬웨어 또는 경고 및 격리를 자동으로 차단하는 바이러스 백신의 경우
또는 EDR/EDPR/NGAV인 경우:
정기적인 검사가 수행되고 있습니다.
감사 로그를 생성하고 있습니다.
는 지속적으로 최신 상태로 유지되며 자체 학습 기능을 갖추고 있습니다.
알려진 맬웨어를 차단하고 매크로 동작을 기반으로 하는 새로운 맬웨어 변형을 식별하고 차단하며 전체 허용 범위를 갖습니다.
의도: 액세스 중 검사
이 하위 지점은 샘플링된 모든 시스템 구성 요소에 맬웨어 방지 소프트웨어가 설치되어 있고 액세스 시 검사를 적극적으로 수행하고 있는지 확인하도록 설계되었습니다. 또한 컨트롤은 맬웨어 방지 솔루션의 서명 데이터베이스를 1일 기간 내에 최신 상태로 유지하도록 규정합니다. 최신 서명 데이터베이스는 최신 맬웨어 위협을 식별하고 완화하여 시스템 구성 요소가 적절하게 보호되도록 하는 데 매우 중요합니다.
지침: 액세스 중인 검사**.**
AV의 활성 instance 평가된 환경에서 실행 중임을 입증하려면 맬웨어 방지 사용을 지원하는 분석가와 합의한 샘플 집합의 모든 디바이스에 대한 스크린샷을 제공합니다. 스크린샷은 맬웨어 방지 소프트웨어가 실행 중이며 맬웨어 방지 소프트웨어가 활성화되어 있음을 보여 줘야 합니다. 맬웨어 방지에 대한 중앙 집중식 관리 콘솔 있는 경우 관리 콘솔 증거가 제공될 수 있습니다. 또한 샘플링된 디바이스가 연결되고 작동 중임을 보여 주는 스크린샷을 제공해야 합니다.
예시 증거: 액세스 중 검사**.**
다음 스크린샷은 Windows Server 디바이스에서 가져온 것으로, 호스트 이름 "IaaS-Web-app"에 대해 "Microsoft Defender"가 사용하도록 설정되어 있음을 보여 줍니다.
다음 스크린샷은 Windows Server 디바이스에서 찍은 것으로, 맬웨어 방지 보안 인텔리전스 버전이 Windows 이벤트 뷰어에서 로그를 업데이트한 Microsoft Defender 보여 줌. 호스트 이름 "IaaS-Web-app"에 대한 최신 서명을 보여 줍니다.
이 스크린샷은 windows Server 디바이스에서 가져온 것으로, Microsoft Defender 맬웨어 방지 보호 업데이트를 보여 줍니다. 이는 맬웨어 정의가 호스트 이름 "IaaS-Web- app"에 대한 최신 상태임을 보여 주는 위협 정의 버전, 버전 및 마지막 업데이트를 명확하게 보여 줍니다.
의도: 맬웨어 방지 블록.
이 하위 지점의 목적은 탐지 시 맬웨어를 자동으로 차단하거나 경고를 생성하고 검색된 맬웨어를 보안 격리 영역으로 이동하도록 맬웨어 방지 소프트웨어가 구성되어 있는지 확인하는 것입니다. 이렇게 하면 위협이 감지될 때 즉각적인 조치를 취하고, 취약성 창을 줄이고, 시스템의 강력한 보안 태세를 유지할 수 있습니다.
지침: 맬웨어 방지 블록.
맬웨어 방지 사용을 지원하는 샘플의 모든 디바이스에 대한 스크린샷을 제공합니다. 스크린샷은 맬웨어 방지가 실행 중이며 맬웨어, 경고 또는 격리 및 경고를 자동으로 차단하도록 구성되어 있음을 보여 줘야 합니다.
예시 증거: 맬웨어 방지 블록.
다음 스크린샷은 호스트 "IaaS-Web-app"이 Microsoft Defender 맬웨어 방지용 ON으로 실시간 보호로 구성되어 있는 것을 보여줍니다. 설정에서 설명한 대로 맬웨어가 디바이스에 설치되거나 실행되는 것을 찾아서 중지합니다.
의도: EDR/NGAV
이 하위 지점은 EDR(엔드포인트 검색 및 응답) 또는 NGAV(차세대 바이러스 백신)가 샘플링된 모든 시스템 구성 요소에서 정기적으로 검사를 수행하는지 확인하는 것을 목표로 합니다. 검사 활동 및 결과를 추적하기 위해 감사 로그가 생성됩니다. 검사 솔루션은 지속적으로 업데이트되며 새로운 위협 환경에 적응할 수 있는 자체 학습 기능을 보유하고 있습니다.
지침: EDR/NGAV
샘플링된 시스템의 모든 에이전트가 에서 보고하고 해당 상태 활성 상태임을 보여 주는 EDR/NGAV 솔루션의 스크린샷을 제공합니다.
예시 증거: EDR/NGAV
OpenEDR 솔루션의 다음 스크린샷은 호스트 "IaaS-Web-app"에 대한 에이전트가 활성 상태이고 보고 중임을 보여줍니다.
OpenEDR 솔루션의 다음 스크린샷은 실시간 검사가 사용하도록 설정되어 있음을 보여줍니다.
다음 스크린샷은 시스템 수준에서 설치된 에이전트에서 실시간으로 얻은 동작 메트릭을 기반으로 경고가 생성됨을 보여 줍니다.
OpenEDR 솔루션의 다음 스크린샷은 감사 로그 및 경고의 구성 및 생성을 보여 줍니다. 두 번째 이미지는 정책이 활성화되고 이벤트가 구성되어 있음을 보여줍니다.
OpenEDR 솔루션의 다음 스크린샷은 솔루션이 지속적으로 최신 상태로 유지됨을 보여 줍니다.
의도: EDR/NGAV
이 하위 지점의 초점은 EDR/NGAV가 알려진 맬웨어를 자동으로 차단하고 매크로 동작에 따라 새로운 맬웨어 변형을 식별하고 차단하는 기능을 갖도록 하는 것입니다. 또한 솔루션에 전체 승인 기능이 있으므로 organization 다른 모든 것을 차단하면서 신뢰할 수 있는 소프트웨어를 허용하여 추가 보안 계층을 추가할 수 있습니다.
지침: EDR/NGAV
사용되는 솔루션 유형에 따라 솔루션의 구성 설정을 보여 주는 증거를 제공할 수 있으며, 솔루션에 Machine Learning/추론 기능이 있을 뿐만 아니라 검색 시 맬웨어를 차단하도록 구성됩니다. 솔루션에서 구성이 기본적으로 구현되는 경우 공급업체 설명서에서 유효성을 검사해야 합니다.
예시 증거: EDR/NGAV
OpenEDR 솔루션의 다음 스크린샷은 보안 프로필 v7.4가 실시간 검사를 적용하고, 맬웨어를 차단하고, 격리하도록 구성되어 있음을 보여줍니다.
보안 프로필 v7.4 구성의 다음 스크린샷은 솔루션이 알려진 맬웨어 서명을 검색하는 기존의 맬웨어 방지 방법을 기반으로 하는 "실시간" 검사와 중간 수준으로 설정된 "추론" 검사를 모두 구현한다는 것을 보여줍니다. 이 솔루션은 의심스럽거나 예기치 않거나 악의적인 방식으로 동작하는 파일과 코드를 확인하여 맬웨어를 검색하고 제거합니다.
스캐너는 보관 파일의 압축을 풀고 내부 파일을 스캔하여 보관 파일에서 마스킹할 수 있는 잠재적인 맬웨어를 검색하도록 구성됩니다. 또한 스캐너는 Microsoft Office 파일 내에서 마이크로 스크립트를 차단하도록 구성됩니다.
다음 스크린샷은 보안 프로필 v.7.4가 Windows Server 디바이스 'IaaS-Web-app' 호스트에 할당되었음을 보여 줍니다.
다음 스크린샷은 Windows Server 디바이스 'IaaS-Web-app'에서 찍은 것으로, OpenEDR 에이전트가 호스트에서 활성화되고 실행되고 있음을 보여 줍니다.
맬웨어 보호/애플리케이션 제어
애플리케이션 제어는 무단 애플리케이션이 데이터를 위험에 빠뜨리는 방식으로 실행되지 않도록 차단하거나 제한하는 보안 사례입니다. 애플리케이션 제어는 회사 보안 프로그램의 중요한 부분이며 악의적인 행위자가 애플리케이션 취약성을 악용하지 못하도록 방지하고 위반 위험을 줄이는 데 도움이 될 수 있습니다. 애플리케이션 제어를 구현하면 네트워크 또는 중요한 데이터가 위험에 노출될 경우 애플리케이션이 실행되지 않으므로 기업과 조직은 애플리케이션 사용과 관련된 위험과 위협을 크게 줄일 수 있습니다. 애플리케이션 제어는 운영 및 보안 팀에 사이버 위험을 완화하기 위한 안정적이고 표준화되고 체계적인 접근 방식을 제공합니다. 또한 조직에서 해당 환경의 애플리케이션에 대한 전체적인 그림을 제공하여 IT 및 보안 조직이 사이버 위험을 효과적으로 관리하는 데 도움이 될 수 있습니다.
컨트롤 번호 3
다음을 보여주는 증거를 제공하세요.
비즈니스 근거가 있는 소프트웨어/애플리케이션의 승인된 목록이 있습니다.
가 존재하며 최신 상태로 유지됩니다.
각 애플리케이션은 승인 프로세스를 거치고 배포 전에 로그오프합니다.
해당 애플리케이션 제어 기술은 문서화된 대로 샘플링된 모든 시스템 구성 요소에서 활성, 사용 및 구성됩니다.
의도: 소프트웨어 목록
이 하위 지점은 승인된 소프트웨어 및 애플리케이션 목록이 organization 내에 존재하고 지속적으로 최신 상태로 유지되도록 하는 것을 목표로 합니다. 목록의 각 소프트웨어 또는 애플리케이션에 해당 필요성의 유효성을 검사하기 위한 문서화된 비즈니스 근거가 있는지 확인합니다. 이 목록은 소프트웨어 및 애플리케이션 배포를 규제하는 신뢰할 수 있는 참조 역할을 하므로 보안 위험을 초래할 수 있는 무단 또는 중복 소프트웨어를 제거하는 데 도움이 됩니다.
지침: 소프트웨어 목록
디지털 문서(Word, PDF 등)로 유지 관리되는 경우 승인된 소프트웨어 및 애플리케이션 목록이 포함된 문서입니다. 승인된 소프트웨어 및 애플리케이션 목록이 플랫폼을 통해 유지 관리되는 경우 플랫폼의 목록 스크린샷을 제공해야 합니다.
예시 증거: 소프트웨어 목록
다음 스크린샷은 승인된 소프트웨어 및 애플리케이션 목록이 Confluence Cloud 플랫폼에서 유지 관리됨을 보여 줍니다.
다음 스크린샷은 요청자, 요청 날짜, 승인자, 승인 날짜, 제어 메커니즘, JIRA 티켓, 시스템/자산을 포함한 승인된 소프트웨어 및 애플리케이션 목록이 유지 관리됨을 보여 줍니다.
의도: 소프트웨어 승인
이 하위 지점의 목적은 각 소프트웨어/애플리케이션이 organization 내에서 배포되기 전에 공식적인 승인 프로세스를 거치는지 확인하는 것입니다. 승인 프로세스에는 기술 평가 및 임원 등록이 포함되어 운영 및 전략적 관점이 모두 고려되도록 해야 합니다. 이 엄격한 프로세스를 도입함으로써 organization 검사되고 필요한 소프트웨어만 배포되어 보안 취약성을 최소화하고 비즈니스 목표에 부합하도록 보장합니다.
지침
승인 프로세스가 수행되고 있음을 보여주는 증거를 제공할 수 있습니다. 서명된 문서, 변경 제어 시스템 내에서 추적 또는 Azure DevOps/JIRA와 같은 항목을 사용하여 변경 요청 및 권한 부여를 추적하여 제공할 수 있습니다.
예제 증거
다음 스크린샷은 JIRA Software의 전체 승인 프로세스를 보여 줍니다. 'Jane Doe' 사용자가 'IaaS-Web-app' 및 'IaaS-VM- 백 엔드' 서버에 'Qualys 클라우드 에이전트 허용'을 설치하도록 요청했습니다. 'Andrew Smith'는 요청을 검토하고 '맬웨어 방지에 대한 비즈니스 요구 사항에 따라 승인됨'댓글로 승인했습니다. Qualys에서 제공하는 업데이트 및 패치입니다. 승인할 소프트웨어입니다.'
다음 스크린샷은 애플리케이션이 프로덕션 서버에서 실행되도록 허용하기 전에 Confluence 플랫폼에서 발생한 티켓을 통해 승인이 부여되는 것을 보여줍니다.
의도: 앱 제어 기술
이 하위 지점은 애플리케이션 제어 기술이 모든 샘플링된 시스템 구성 요소에서 활성화되고 활성화되고 올바르게 구성되었는지 확인하는 데 중점을 둡니다. 기술 구현 및 유지 관리에 대한 지침 역할을 하는 문서화된 정책 및 절차에 따라 기술이 작동하는지 확인합니다. 이 organization 활성, 사용 및 잘 구성된 애플리케이션 제어 기술을 사용하여 권한 없는 소프트웨어 또는 악성 소프트웨어의 실행을 방지하고 시스템의 전반적인 보안 태세를 개선하는 데 도움이 될 수 있습니다.
지침: 앱 제어 기술
애플리케이션 제어가 설정된 방법과 각 애플리케이션/프로세스가 구성된 방법을 보여 주는 해당 기술의 증거를 자세히 설명하는 설명서를 제공합니다.
예시 증거: 앱 제어 기술
다음 스크린샷은 승인된 소프트웨어 및 애플리케이션만 적용하도록 GPO(Windows 그룹 정책)가 구성되어 있음을 보여 줍니다.
다음 스크린샷은 경로 제어를 통해 실행할 수 있는 소프트웨어/애플리케이션을 보여 줍니다.
참고: 이러한 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 모든 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 화면 스크린샷이어야 합니다.
패치 관리/패치 및 위험 순위
패치 관리(패치라고도 함)는 강력한 사이버 보안 전략의 중요한 구성 요소입니다. 여기에는 소프트웨어, 운영 체제 및 애플리케이션에 패치 또는 업데이트를 식별, 테스트 및 적용하는 체계적인 프로세스가 포함됩니다. 패치 관리의 주요 목표는 보안 취약성을 완화하여 시스템 및 소프트웨어가 잠재적 위협에 대해 복원력을 유지하도록 하는 것입니다. 또한 패치 관리에는 패치 우선 순위 지정에서 중요한 요소의 위험 순위가 포함됩니다. 여기에는 심각도 및 organization 보안 태세에 미치는 잠재적 영향에 따라 취약성을 평가하는 작업이 포함됩니다. 조직은 취약성에 위험 점수를 할당하여 리소스를 효율적으로 할당할 수 있으며, 새로운 위협에 대한 사전 대응적 입장을 유지하면서 위험 및 고위험 취약성을 신속하게 해결하는 데 집중할 수 있습니다. 효과적인 패치 관리 및 위험 순위 전략은 보안을 향상시킬 뿐만 아니라 IT 인프라의 전반적인 안정성과 성능에 기여하여 조직이 끊임없이 진화하는 사이버 보안 위협 환경에서 복원력을 유지할 수 있도록 지원합니다.
안전한 운영 환경을 유지하려면 애플리케이션/추가 기능 및 지원 시스템을 적절하게 패치해야 합니다. 위협 행위자가 취약성을 악용할 수 있는 기회를 줄이기 위해 식별(또는 공개 릴리스)과 패치 간의 적절한 기간을 관리해야 합니다. Microsoft 365 인증은 '패치 창'을 규정하지 않습니다. 그러나 인증 분석가는 합리적이지 않거나 업계 모범 사례에 부합하지 않는 기간을 거부합니다. 이 보안 제어 그룹은 애플리케이션/추가 기능 타사 소프트웨어 라이브러리 및 코드 베이스가 위험 순위에 따라 패치되어야 함에 따라 PaaS(Platform-as-a-Service) 호스팅 환경에 대한 scope 있습니다.
컨트롤 번호 4
패치 관리 정책 및 절차 설명서에서 다음을 모두 정의한다는 증거를 제공합니다.
위험/높음 및 중간 위험 취약성에 적합한 최소 패치 창입니다.
지원되지 않는 운영 체제 및 소프트웨어의 서비스 해제.
새 보안 취약성을 식별하고 위험 점수를 할당하는 방법
의도: 패치 관리
패치 관리는 PCI-DSS, ISO 27001, NIST(SP) 800-53, FedRAMP 및 SOC 2와 같은 많은 보안 규정 준수 프레임워크에 필요합니다. 좋은 패치 관리의 중요성은 지나치게 강조될 수 없습니다.
소프트웨어, 펌웨어 및 취약성 완화의 보안 및 기능 문제를 해결할 수 있으므로 악용 기회를 줄이는 데 도움이 됩니다. 이 제어의 목적은 위협 행위자가 가진 기회의 창을 최소화하여 scope 환경 내에 존재할 수 있는 취약성을 악용하기 위한 것입니다.
다음 측면을 포괄적으로 다루는 패치 관리 정책 및 절차 설명서를 제공합니다.
위험/높음 및 중간 위험 취약성에 적합한 최소 패치 창입니다.
organization 패치 관리 정책 및 절차 설명서는 위험/높음 및 중간 위험으로 분류된 취약성에 적합한 최소 패치 창을 명확하게 정의해야 합니다. 이러한 프로비저닝은 위험 수준에 따라 취약성을 식별한 후 패치를 적용해야 하는 최대 허용 시간을 설정합니다. 이러한 시간 프레임을 명시적으로 명시함으로써 organization 패치 관리에 대한 접근 방식을 표준화하여 패치되지 않은 취약성과 관련된 위험을 최소화했습니다.
지원되지 않는 운영 체제 및 소프트웨어의 서비스 해제.
패치 관리 정책에는 지원되지 않는 운영 체제 및 소프트웨어의 서비스 해제에 대한 프로비전이 포함됩니다. 더 이상 보안 업데이트를 받지 않는 운영 체제 및 소프트웨어는 organization 보안 상태에 심각한 위험을 초래합니다. 따라서 이 컨트롤은 정책 설명서에 정의된 대로 이러한 시스템을 적시에 식별 및 제거 또는 교체하도록 합니다.
- 새로운 보안 취약성을 식별하고 위험 점수를 할당하는 방법을 설명하는 문서화된 절차입니다.
패치는 위험을 기반으로 해야 하며, 취약성이 위험할수록 더 빨리 수정해야 합니다. 식별된 취약성의 위험 순위는 이 프로세스의 필수적인 부분입니다. 이 컨트롤의 의도는 모든 식별된 취약성이 위험에 따라 적절하게 순위가 매겨지도록 하기 위해 수행되는 문서화된 위험 순위 프로세스가 있는지 확인하는 것입니다. 조직은 일반적으로 공급업체 또는 보안 연구원이 제공하는 CVSS(Common Vulnerability Scoring System) 등급을 활용합니다. 조직에서 CVSS를 사용하는 경우 organization 내부 위험 평가에 따라 순위를 변경할 수 있도록 프로세스에 다시 순위 지정 메커니즘이 포함되는 것이 좋습니다. 경우에 따라 애플리케이션이 환경 내에 배포된 방식으로 인해 취약성이 적용되지 않을 수 있습니다. 예를 들어 organization 사용되지 않는 특정 라이브러리에 영향을 주는 Java 취약성이 릴리스될 수 있습니다.
참고: 순수하게 Platform as a Service 'PaaS/Serverless' 환경에서 실행 중인 경우에도 코드 베이스 내의 취약성(예: 타사 라이브러리)을 식별할 책임이 있습니다.
지침: 패치 관리
정책 문서를 제공합니다. 지정된 컨트롤에 대한 모든 요소를 포함하는 organization 정의된 프로세스를 자세히 설명하는 정책 및 절차 설명서와 같은 관리 증거를 제공해야 합니다.
참고: 논리적 증거는 organization VMP(취약성 관리 프로그램)에 대한 추가 인사이트를 제공하는 지원 증거로 제공할 수 있지만 자체적으로 이 제어를 충족하지는 않습니다.
예시 증거: 패치 관리
다음 스크린샷은 패치 관리/위험 순위 정책의 코드 조각과 다양한 수준의 위험 범주를 보여줍니다. 그 다음에 분류 및 수정 기간이 수행됩니다. 참고: ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
정책 문서를 지원하는 (선택 사항) 추가 기술 증거의 예
취약성 추적 스프레드시트, 취약성 기술 평가 보고서 또는 온라인 관리 플랫폼을 통해 발생한 티켓의 스크린샷과 같은 논리적 증거는 제공될 정책 설명서에 설명된 프로세스의 구현을 지원하는 데 사용되는 취약성의 상태 및 진행률을 추적합니다. 다음 스크린샷은 SCA(소프트웨어 컴퍼지션 분석) 도구인 Snyk를 사용하여 코드 베이스에서 취약성을 검사하는 방법을 보여 줍니다. 이 다음에는 이메일을 통해 알림이 표시됩니다.
참고: 이 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 모든 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
다음 두 스크린샷은 새 취약성이 Snyk에 의해 플래그가 지정될 때 수신된 이메일 알림의 예를 보여 줍니다. 메일에 영향을 받는 프로젝트와 경고를 수신하기 위한 할당된 사용자가 포함되어 있는 것을 볼 수 있습니다.
다음 스크린샷은 식별된 취약성을 보여줍니다.
참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
예제 증거
다음 스크린샷은 코드 베이스 내에서 취약성을 검색하도록 구성되고 사용하도록 설정된 GitHub 보안 도구를 보여 줍니다. 경고는 이메일을 통해 전송됩니다.
다음에 표시된 이메일 알림은 플래그가 지정된 문제가 끌어오기 요청을 통해 자동으로 해결된다는 확인입니다.
예제 증거
다음 스크린샷은 스프레드시트를 통한 취약성의 내부 기술 평가 및 순위를 보여 줍니다.
예제 증거
다음 스크린샷은 검색된 각 취약성에 대해 DevOps에서 발생한 티켓을 보여 줍니다.
변경 내용을 구현하기 전에 별도의 직원이 평가, 순위 지정 및 검토합니다.
컨트롤 번호 5
다음을 입증할 수 있는 증거를 제공합니다.
샘플링된 모든 시스템 구성 요소가 패치되고 있습니다.
지원되지 않는 운영 체제 및 소프트웨어 구성 요소가 사용되지 않는다는 입증 가능한 증거를 제공합니다.
의도: 샘플링된 시스템 구성 요소
이 하위 지점은 organization 내에서 샘플링된 모든 시스템 구성 요소가 적극적으로 패치되고 있는지 확인하기 위해 확인 가능한 증거가 제공되도록 하는 것을 목표로 합니다. 증거는 패치 관리 로그, 시스템 감사 보고서 또는 패치가 적용되었음을 보여 주는 문서화된 절차를 포함하지만 이에 국한되지 않습니다. 서버리스 기술 또는 PaaS(Platform as a Service)를 사용하는 경우 가장 최근의 보안 버전의 라이브러리 및 종속성이 사용 중인지 확인하기 위해 코드 베이스를 포함하도록 확장해야 합니다.
지침: 샘플링된 시스템 구성 요소
샘플의 모든 디바이스 및 지원 소프트웨어 구성 요소에 대한 스크린샷을 제공하여 패치가 문서화된 패치 프로세스에 따라 설치되었음을 보여 줍니다. 또한 코드 베이스의 패치를 보여주는 스크린샷을 제공합니다.
예제 증거: 샘플링된 시스템 구성 요소
다음 스크린샷은 Linux 운영 체제 가상 머신 'IaaS- VM-Backend'의 패치를 보여 줍니다.
예제 증거
다음 스크린샷은 Windows 운영 체제 가상 머신 'IaaS-Web-app'의 패치를 보여 줍니다.
예제 증거
Microsoft Intune, 클라우드용 Defender 등과 같은 다른 도구에서 패치를 유지 관리하는 경우 이러한 도구에서 스크린샷을 제공할 수 있습니다. OpenEDR 솔루션의 다음 스크린샷은 OpenEDR 포털을 통해 패치 관리가 수행됨을 보여 줍니다.
다음 스크린샷은 scope 서버의 패치 관리가 OpenEDR 플랫폼을 통해 수행됨을 보여 줍니다. 분류 및 상태 아래에 표시되어 패치가 발생했음을 보여 줍니다.
다음 스크린샷은 서버에 성공적으로 설치된 패치에 대한 로그가 생성되었음을 보여줍니다.
예제 증거
다음 스크린샷은 코드 기본/타사 라이브러리 종속성이 Azure DevOps를 통해 패치되는 것을 보여 줍니다.
다음 스크린샷은 Snyk에서 검색한 취약성에 대한 수정이 오래된 라이브러리를 resolve 위해 분기에 커밋되고 있음을 보여줍니다.
다음 스크린샷은 라이브러리가 지원되는 버전으로 업그레이드되었음을 보여 줍니다.
예제 증거
다음 스크린샷은 GitHub Dependabot을 통해 코드 기본 패치가 유지 관리됨을 보여 줍니다. 닫힌 항목은 패치가 발생하고 취약성이 해결되었음을 보여줍니다.
의도: 지원되지 않는 OS
공급업체에서 유지 관리하지 않는 소프트웨어는 초과 근무로 인해 수정되지 않은 알려진 취약성으로 인해 고통을 겪게 됩니다. 따라서 지원되지 않는 운영 체제 및 소프트웨어 구성 요소를 프로덕션 환경 내에서 사용하면 안 됩니다. IaaS(Infrastructure-as-a-Service)가 배포되는 경우 이 하위 지점에 대한 요구 사항은 인프라와 코드 베이스를 모두 포함하도록 확장되어 기술 스택의 모든 계층이 지원되는 소프트웨어 사용에 대한 organization 정책을 준수하도록 합니다.
지침: 지원되지 않는 OS
실행 중인 OS 버전을 표시하지 않는 증거를 수집하기 위해 분석가가 선택한 샘플 집합의 모든 디바이스에 대한 스크린샷을 제공합니다(스크린샷에 디바이스/서버 이름 포함). 이 외에도 환경 내에서 실행되는 소프트웨어 구성 요소가 지원되는 버전의 소프트웨어를 실행하고 있다는 증거를 제공합니다. 이 작업은 내부 취약성 검사 보고서의 출력(인증된 검사가 포함됨) 및/또는 Snyk, Trivy 또는 NPM 감사와 같은 타사 라이브러리를 검사 도구의 출력을 제공하여 수행할 수 있습니다. PaaS에서 실행되는 경우 타사 라이브러리 패치만 적용해야 합니다.
예시 증거: 지원되지 않는 OS
Azure DevOps NPM 감사의 다음 스크린샷은 웹앱 내에서 지원되지 않는 라이브러리/종속성이 활용되지 않음을 보여줍니다.
참고: 다음 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
예제 증거
GitHub Dependabot의 다음 스크린샷은 웹앱 내에서 라이브러리/종속성이 활용되지 않음을 보여줍니다.
예제 증거
OpenEDR을 통한 Windows 운영 체제용 소프트웨어 인벤토리의 다음 스크린샷은 지원되지 않거나 오래된 운영 체제 및 소프트웨어 버전을 찾을 수 없음을 보여줍니다.
예제 증거
다음 스크린샷은 Windows Server 2019 Datacenter(x64) 및 OS 전체 버전 기록(서비스 팩, 빌드 버전 등)을 보여 주는 OS 요약 아래 OpenEDR의 스크린샷입니다. 지원되지 않는 운영 체제를 찾을 수 없는지 확인합니다.
예제 증거
Linux 운영 체제 서버의 다음 스크린샷은 지원되지 않는 Linux 운영 체제가 없는지 확인하는 배포자 ID, 설명, 릴리스 및 코드 이름을 비롯한 모든 버전 세부 정보를 보여 줍니다.
예시 증거:
Nessus 취약성 검사 보고서의 다음 스크린샷은 지원되지 않는 OS(운영 체제) 및 소프트웨어가 대상 머신에서 발견되지 않음을 보여줍니다.
참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 제출된 모든 ISV 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
취약성 검색
취약성 검사는 organization 컴퓨터 시스템, 네트워크 및 웹 애플리케이션에서 가능한 약점을 찾아 보안 위반 및 중요한 데이터 노출로 이어질 수 있는 구멍을 식별합니다. 취약성 검사는 종종 업계 표준 및 정부 규정(예: PCI DSS(결제 카드 산업 데이터 보안 표준)에 의해 요구됩니다.
"PCI DSS 규정 준수에 대한 2020 보안 메트릭 가이드"라는 보안 메트릭의 보고서에는 '공격자가 시스템을 손상시키는 취약성이 있는 것으로 organization 평균적으로 166일이 걸렸습니다. 손상되면 공격자는 평균 127일 동안 중요한 데이터에 액세스할 수 있으므로 이 제어는 scope 환경 내에서 잠재적인 보안 약점을 식별하기 위한 것입니다.
조직은 정기적인 취약성 평가를 도입하여 환경 내에서 약점과 불안을 감지할 수 있으며, 악의적인 행위자가 환경을 손상시키는 진입점을 제공할 수 있습니다. 취약성 검사는 환경 내에서 누락된 패치 또는 잘못된 구성을 식별하는 데 도움이 될 수 있습니다. 이러한 검사를 정기적으로 수행하면 organization 이러한 취약성 검사 도구에서 일반적으로 포착되는 문제로 인해 손상 위험을 최소화할 수 있는 적절한 수정을 제공할 수 있습니다.
컨트롤 번호 6
다음을 보여주는 증거를 제공하세요.
분기별 인프라 및 웹 애플리케이션 취약성 검사가 수행됩니다.
환경이 IaaS, 하이브리드 또는 온-프레미스인 경우 전체 공용 공간(IP/URL) 및 내부 IP 범위에 대해 검사를 수행해야 합니다.
참고: 여기에는 환경의 전체 scope 포함되어야 합니다.
의도: 취약성 검사
이 컨트롤은 organization 인프라 및 웹 애플리케이션을 대상으로 분기별로 취약성 검사를 수행하도록 하는 것을 목표로 합니다. 검사는 공용 IP 및 URL과 같은 공용 공간과 내부 IP 범위를 모두 포괄하는 포괄적이어야 합니다. 검사 scope organization 인프라의 특성에 따라 달라집니다.
organization 하이브리드, 온-프레미스 또는 IaaS(Infrastructure-as-a-Service) 모델을 구현하는 경우 검사는 외부 공용 IP/URL과 내부 IP 범위를 모두 포함해야 합니다.
organization PaaS(Platform-as-a-Service)를 구현하는 경우 검사는 외부 공용 IP/URL만 포함해야 합니다.
또한 이 컨트롤은 검사에 환경의 전체 scope 포함해야 하므로 구성 요소를 선택 취소하지 않아야 합니다. 목표는 organization 기술 스택의 모든 부분에서 취약성을 식별하고 평가하여 포괄적인 보안을 보장하는 것입니다.
지침: 취약성 검사
지난 12개월 동안 수행된 각 분기의 취약성 검사에 대한 전체 검사 보고서를 제공합니다. 보고서는 전체 공용 공간이 포함되고 해당하는 경우 각 내부 서브넷의 유효성을 검사하기 위해 대상을 명확하게 명시해야 합니다. 매 분기마다 모든 검사 보고서를 제공합니다.
예시 증거: 취약성 검사
다음 스크린샷은 보안되지 않은 열린 포트를 식별하기 위해 외부 인프라의 Nmap을 통해 수행된 네트워크 검색 및 포트 검사를 보여줍니다.
참고: 완전한 취약성 검사를 제공해야 한다는 기대가 있으므로 Nmap을 자체적으로 사용하여 이 컨트롤을 충족할 수 없습니다. Nmap 포트 검색은 아래에 예시된 취약성 관리 프로세스의 일부이며 외부 인프라에 대한 OpenVAS 및 OWASP ZAP 검사로 보완됩니다.
스크린샷은 외부 인프라에 대한 OpenVAS를 통한 취약성 검사를 보여 줍니다.
다음 스크린샷은 동적 애플리케이션 보안 테스트를 보여주는 OWASP ZAP의 취약성 검사 보고서를 보여줍니다.
예시 증거: 취약성 검사
Tenable Nessus Essentials 취약성 검사 보고서의 다음 스크린샷은 내부 인프라 검사가 수행됨을 보여 줍니다.
이전 스크린샷은 호스트 VM에 대한 분기별 검사를 위한 폴더 설정을 보여 줍니다.
위와 아래 스크린샷은 취약성 검사 보고서의 출력을 보여줍니다.
다음 스크린샷은 발견된 모든 문제를 다루는 보고서의 연속성을 보여 줍니다.
컨트롤 번호 7
다음을 보여 주는 다시 검사 증거를 제공하세요.
- Control 6에서 식별된 모든 취약성의 수정은 정책에 정의된 최소 패치 창에 따라 패치됩니다.
의도: 패치
취약성 및 잘못된 구성을 신속하게 식별, 관리 및 수정하지 못하면 organization 손상 위험이 증가하여 잠재적인 데이터 위반이 발생할 수 있습니다. ISO 27001 및 PCI DSS와 같은 다양한 보안 프레임워크의 모범 사례에 부합하는 organization 전반적인 보안 태세 및 환경에서 문제를 올바르게 식별하고 수정하는 것이 중요합니다.
이 컨트롤의 의도는 organization 재검사에 대한 신뢰할 수 있는 증거를 제공하여 Control 6에서 식별된 모든 취약성이 수정되었음을 보여주는 것입니다. 수정은 organization 패치 관리 정책에 정의된 최소 패치 창과 일치해야 합니다.
지침: 패치
컨트롤 6에서 식별된 모든 취약성이 컨트롤 4에 정의된 패치 창에 따라 수정되었는지 확인하는 다시 검사 보고서를 제공합니다.
예제 증거: 패치
다음 스크린샷은 2023년 8월 2일의 취약성을 보여 주는 scope 환경(이 예제의 토르라는 단일 컴퓨터)의 네서스 스캔을 보여줍니다.
다음 스크린샷은 패치 정책 내에 정의된 패치 창 내에 있는 2일 후에 문제가 해결되었음을 보여 줍니다.
참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV가 제출되었습니다.
증거 스크린샷은 로그인한 모든 URL과 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
NSC(네트워크 보안 컨트롤)
네트워크 보안 제어는 ISO 27001, CIS 제어 및 NIST 사이버 보안 프레임워크와 같은 사이버 보안 프레임워크의 필수 구성 요소입니다. 조직에서 사이버 위협과 관련된 위험을 관리하고, 무단 액세스로부터 중요한 데이터를 보호하고, 규정 요구 사항을 준수하고, 적시에 사이버 위협을 감지 및 대응하고, 비즈니스 연속성을 보장하도록 지원합니다. 효과적인 네트워크 보안은 organization 내부 또는 외부에서 광범위한 위협으로부터 조직 자산을 보호합니다.
컨트롤 번호 8
다음을 입증할 수 있는 증거를 제공합니다.
- NSC(네트워크 보안 제어)는 scope 환경의 경계에 설치되고 경계 네트워크와 내부 네트워크 사이에 설치됩니다.
하이브리드, 온-프레미스, IaaS도 다음과 같은 증거를 제공하는 경우
- 모든 공용 액세스는 경계 네트워크에서 종료됩니다.
의도: NSC
이 컨트롤은 NSC(네트워크 보안 제어)가 organization 네트워크 토폴로지 내의 주요 위치에 설치되어 있는지 확인하는 것을 목표로 합니다. 특히 NSC는 scope 환경의 경계와 경계 네트워크와 내부 네트워크 사이에 배치되어야 합니다. 이 제어의 목적은 이러한 보안 메커니즘이 organization 디지털 자산을 보호하는 효과를 최대화하기 위해 올바르게 배치되었는지 확인하는 것입니다.
지침: NSC
NSC(네트워크 보안 제어)가 경계에 설치되고 경계와 내부 네트워크 간에 구성되어 있음을 입증하기 위해 증거를 제공해야 합니다. 이는 NSC(네트워크 보안 컨트롤)의 구성 설정 스크린샷과 방화벽 또는 NSG(Azure 네트워크 보안 그룹), Azure Front Door 등과 같은 해당 기술에 적용되는 scope 스크린샷을 제공하여 수행할 수 있습니다.
예시 증거: NSC
다음 스크린샷은 웹앱 'PaaS-web-app'의 스크린샷입니다. 네트워킹 블레이드는 모든 인바운드 트래픽이 Azure Front Door를 통과하는 반면 애플리케이션에서 다른 Azure 리소스로의 모든 트래픽은 VNET 통합을 통해 Azure NSG를 통해 라우팅 및 필터링됨을 보여 줍니다.
"액세스 제한" 내의 거부 규칙은 Front Door(FD)를 제외한 인바운드를 방지하며, 트래픽은 애플리케이션에 도달하기 전에 FD를 통해 라우팅됩니다.
예시 증거: NSC
다음 스크린샷은 Azure Front Door의 기본 경로와 애플리케이션에 도달하기 전에 트래픽이 Front Door를 통해 라우팅되는 것을 보여줍니다. WAF 정책도 적용되었습니다.
예시 증거: NSC
첫 번째 스크린샷은 인바운드 및 아웃바운드 트래픽을 필터링하기 위해 VNET 수준에서 적용된 Azure 네트워크 보안 그룹을 보여줍니다. 두 번째 스크린샷은 SQL Server가 인터넷을 통해 라우팅할 수 없으며 VNET 및 프라이빗 링크를 통해 통합되어 있음을 보여 줍니다.
이렇게 하면 SQL 서버에 도달하기 전에 NSG에서 내부 트래픽 및 통신을 필터링할 수 있습니다.
Intent**:** 하이브리드, 온-프레미스, IaaS
이 하위 지점은 하이브리드, 온-프레미스 또는 IaaS(Infrastructure-as-a-Service) 모델을 운영하는 조직에 필수적입니다. 내부 네트워크에 대한 진입 지점을 제어하고 외부 위협에 대한 잠재적 노출을 줄이는 데 중요한 경계 네트워크에서 모든 공용 액세스가 종료되도록 합니다. 규정 준수의 증거에는 방화벽 구성, 네트워크 액세스 제어 목록 또는 공용 액세스가 경계 네트워크 이상으로 확장되지 않는다는 주장을 입증할 수 있는 기타 유사한 설명서가 포함될 수 있습니다.
예시 증거: 하이브리드, 온-프레미스, IaaS
스크린샷은 SQL Server가 인터넷을 통해 라우팅할 수 없으며 VNET 및 프라이빗 링크를 통해 통합되어 있음을 보여 줍니다. 이렇게 하면 내부 트래픽만 허용됩니다.
예시 증거: 하이브리드, 온-프레미스, IaaS
다음 스크린샷은 네트워크 세분화가 scope 가상 네트워크 내에 있음을 보여 줍니다. 다음과 같이 VNET은 각각 NSG가 적용된 세 개의 서브넷으로 나뉩니다.
공용 서브넷은 경계 네트워크 역할을 합니다. 모든 공용 트래픽은 이 서브넷을 통해 라우팅되고 특정 규칙을 사용하여 NSG를 통해 필터링되며 명시적으로 정의된 트래픽만 허용됩니다. 백 엔드는 공용 액세스 권한이 없는 프라이빗 서브넷으로 구성됩니다. 모든 VM 액세스는 서브넷 수준에서 자체 NSG가 적용된 Bastion 호스트를 통해서만 허용됩니다.
다음 스크린샷은 포트 443에서만 인터넷에서 특정 IP 주소로 트래픽이 허용됨을 보여줍니다. 또한 RDP는 Bastion IP 범위에서 가상 네트워크로만 허용됩니다.
다음 스크린샷은 백 엔드가 인터넷을 통해 라우팅할 수 없으며(NIC에 대한 공용 IP가 없기 때문) 트래픽이 Virtual Network 및 Bastion에서만 시작되도록 허용됨을 보여 줍니다.
이 스크린샷은 Azure Bastion 호스트가 유지 관리 목적으로만 가상 머신에 액세스하는 데 사용됨을 보여 줍니다.
컨트롤 번호 9
모든 NSC(네트워크 보안 제어)는 규칙 기반 내에서 명시적으로 정의되지 않은 트래픽을 삭제하도록 구성됩니다.
NSC(네트워크 보안 제어) 규칙 검토는 적어도 6개월마다 수행됩니다.
의도: NSC
이 하위 지점은 organization 모든 NSC(네트워크 보안 제어)가 규칙 기반 내에서 명시적으로 정의되지 않은 네트워크 트래픽을 삭제하도록 구성되도록 합니다. 목표는 지정되지 않거나 잠재적으로 악의적인 모든 트래픽을 차단하면서 권한 있는 트래픽만 허용하여 네트워크 계층에서 최소 권한 원칙을 적용하는 것입니다.
지침: NSC
이를 위해 제공되는 증거는 인바운드 규칙을 표시하고 이러한 규칙이 종료되는 규칙 구성일 수 있습니다. 공용 IP 주소를 리소스로 라우팅하거나 인바운드 트래픽의 NAT(네트워크 주소 변환)를 제공하여
예시 증거: NSC
스크린샷은 기본 규칙 집합과 모든 NSG의 기본 규칙을 다시 설정하고 모든 트래픽이 금지되도록 하는 사용자 지정 Deny:All 규칙을 포함한 NSG 구성을 보여줍니다. 추가 사용자 지정 규칙에서 Deny:All 규칙은 허용되는 트래픽을 명시적으로 정의합니다.
예시 증거: NSC
다음 스크린샷은 Azure Front Door가 배포되고 모든 트래픽이 Front Door를 통해 라우팅됨을 보여 줍니다. 잠재적인 악성 페이로드에 대한 인바운드 트래픽을 필터링하고 차단하는 "방지 모드"의 WAF 정책이 적용됩니다.
의도: NSC
정기적인 검토가 없으면 NSC(네트워크 보안 제어)가 오래되고 비효율적이 되어 organization 사이버 공격에 취약해질 수 있습니다. 이로 인해 데이터 위반, 중요한 정보 도난 및 기타 사이버 보안 인시던트가 발생할 수 있습니다. 정기적인 NSC 검토는 위험을 관리하고, 중요한 데이터를 보호하고, 규정 요구 사항을 준수하고, 적시에 사이버 위협을 감지하고 대응하며, 비즈니스 연속성을 보장하는 데 필수적입니다. 이 하위 지점에서는 NSC(네트워크 보안 제어)가 최소 6개월마다 규칙 기본 검토를 받아야 합니다. 정기적인 검토는 특히 동적으로 변화하는 네트워크 환경에서 NSC 구성의 효과와 관련성을 유지하는 데 매우 중요합니다.
지침: NSC
제공된 모든 증거는 규칙 검토 모임이 발생했음을 입증할 수 있어야 합니다. 이 작업은 NSC 검토의 회의록과 검토에서 수행된 작업을 보여 주는 추가 변경 제어 증거를 공유하여 수행할 수 있습니다. 제출을 검토하는 인증 분석가가 이러한 모임 검토 문서(즉, 6개월마다)를 최소 두 개 이상 확인해야 하므로 날짜가 있는지 확인하세요.
예시 증거: NSC
이러한 스크린샷은 6개월 간의 방화벽 검토가 존재하며 세부 정보는 Confluence Cloud 플랫폼에서 유지 관리됨을 보여 줍니다.
다음 스크린샷은 모든 규칙 검토에 Confluence에서 만든 페이지가 있음을 보여 줍니다. 규칙 검토에는 허용되는 트래픽, 포트 번호, 프로토콜 등을 비즈니스 근거와 함께 요약한 승인된 규칙 집합 목록이 포함되어 있습니다.
예시 증거: NSC
다음 스크린샷은 DevOps에서 유지 관리되는 6개월 규칙 검토의 다른 예를 보여 줍니다.
예시 증거: NSC
이 스크린샷은 DevOps에서 수행되고 티켓으로 기록되는 규칙 검토의 예를 보여 줍니다.
이전 스크린샷은 비즈니스 근거와 함께 설정된 문서화된 규칙 목록을 보여 주며, 다음 이미지는 실제 시스템에서 티켓 내의 규칙 스냅샷 보여 줍니다.
컨트롤 변경
모든 변경 내용이 반복 가능한 구조화된 프로세스를 거치도록 하는 데는 확립되고 이해된 변경 제어 프로세스가 필수적입니다. 조직에서는 모든 변경 내용이 구조화된 프로세스를 거치도록 함으로써 변경 내용을 효과적으로 관리하고, 피어를 검토하고, 적절하게 테스트한 후 로그오프할 수 있습니다. 이는 시스템 중단의 위험을 최소화하는 데 도움이 될 뿐만 아니라 부적절한 변경이 도입되어 잠재적인 보안 인시던트 위험을 최소화하는 데도 도움이 됩니다.
컨트롤 번호 10
다음을 보여주는 증거를 제공하세요.
프로덕션 환경에 도입된 모든 변경 내용은 다음을 포함하는 문서화된 변경 요청을 통해 구현됩니다.
변경의 영향입니다.
백아웃 절차의 세부 정보입니다.
테스트를 수행합니다.
승인된 담당자의 검토 및 승인
의도: 변경 제어
이 컨트롤의 의도는 요청된 변경 내용이 신중하게 고려되고 문서화되었는지 확인하는 것입니다. 여기에는 변경이 시스템/환경의 보안에 미치는 영향을 평가하고, 문제가 발생할 경우 복구에 도움이 되는 백아웃 절차를 문서화하고, 변경 성공의 유효성을 검사하는 데 필요한 테스트를 자세히 설명하는 것이 포함됩니다.
적절한 권한 부여 및 로그오프 없이 변경을 수행하는 것을 금지하는 프로세스를 구현해야 합니다. 변경은 구현되기 전에 권한을 부여해야 하며, 변경이 완료되면 로그오프해야 합니다. 이렇게 하면 변경 요청이 제대로 검토되고 권한이 있는 누군가가 변경에 서명했습니다.
지침: 변경 제어
변경, 백아웃 프로시저, 테스트의 영향에 대한 세부 정보가 변경 요청 내에서 유지됨을 보여 주는 변경 요청 샘플의 스크린샷을 공유하여 증거를 제공할 수 있습니다.
예시 증거: 변경 제어
다음 스크린샷은 할당되는 새 XSS(교차 사이트 스크립팅 취약성)와 변경 요청에 대한 문서를 보여 줍니다. 아래 티켓은 해결될 여정에서 티켓에 설정되거나 추가된 정보를 보여 줍니다.
다음 두 티켓은 시스템 변경의 영향과 문제가 발생할 경우 필요할 수 있는 백아웃 절차를 보여 줍니다. 변경 및 백아웃 절차의 영향은 승인 프로세스를 거쳤으며 테스트를 위해 승인되었습니다.
다음 스크린샷에서 변경 내용 테스트가 승인되었으며 오른쪽에 변경 내용이 승인 및 테스트된 것을 볼 수 있습니다.
프로세스 전반에 걸쳐 작업을 수행하는 사람, 작업을 보고하는 사람 및 작업을 승인하는 사람은 다른 사람임을 확인합니다.
다음 티켓은 이제 프로덕션 환경에 대한 구현을 위해 변경 내용이 승인되었음을 보여줍니다. 오른쪽 상자에는 테스트가 작동하고 성공했으며 이제 변경 내용이 Prod Environment에 구현되었음을 보여 주며,
예제 증거
다음 스크린샷은 개발자/요청자가 아닌 다른 사람이 구현하고 승인하기 전에 변경 내용에 권한을 부여해야 한다는 것을 보여주는 Jira 티켓 예제를 보여 줍니다. 변경 내용은 권한이 있는 사용자가 승인합니다. 스크린샷의 오른쪽은 변경 내용이 완료되면 DP에 의해 서명되었음을 보여줍니다.
변경 후 티켓에서 완료되면 로그오프되었으며 작업이 완료되고 닫힌 것을 표시합니다.
참고: - 이러한 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 로그인한 URL과 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
컨트롤 번호 11
다음과 같은 증거를 제공하세요.
다음과 같은 별도의 환경이 존재합니다.
개발 및 테스트/스테이징 환경은 프로덕션 환경에서 업무를 분리합니다.
의무 분리는 액세스 제어를 통해 적용됩니다.
중요한 프로덕션 데이터는 개발 또는 테스트/스테이징 환경에서 사용되지 않습니다.
의도: 별도의 환경
대부분의 조직의 개발/테스트 환경은 프로덕션 환경과 동일한 활력으로 구성되지 않으므로 보안이 떨어집니다. 또한 보안 문제가 발생하거나 고객을 위한 서비스 제공에 해가 될 수 있으므로 프로덕션 환경 내에서 테스트를 수행해서는 안 됩니다. 조직은 업무 분리를 적용하는 별도의 환경을 유지 관리함으로써 변경 내용이 올바른 환경에 적용되도록 할 수 있으므로 개발/테스트 환경을 위한 경우 프로덕션 환경의 변경을 구현하여 오류 위험을 줄일 수 있습니다.
개발 및 테스트를 담당하는 직원이 프로덕션 환경에 불필요하게 액세스할 수 없도록 액세스 제어를 구성해야 하며 그 반대의 경우도 마찬가지입니다. 이렇게 하면 무단 변경 또는 데이터 노출 가능성이 최소화됩니다.
개발/테스트 환경에서 프로덕션 데이터를 사용하면 손상 위험이 증가하고 organization 데이터 위반 또는 무단 액세스에 노출될 수 있습니다. 의도를 사용하려면 개발 또는 테스트에 사용되는 모든 데이터를 해당 용도로 특별히 삭제, 익명화 또는 생성해야 합니다.
지침: 별도의 환경
개발/테스트 환경 및 프로덕션 환경에 사용되는 다양한 환경을 보여 주는 스크린샷을 제공할 수 있습니다. 일반적으로 각 환경에 액세스할 수 있는 다른 사용자/팀이 있거나 가능하지 않은 경우 환경은 다른 권한 부여 서비스를 활용하여 사용자가 잘못된 환경에 실수로 로그인하여 변경 내용을 적용할 수 없도록 합니다.
증거 예: 별도의 환경
다음 스크린샷은 개발/테스트를 위한 환경이 프로덕션과 분리되어 있음을 보여 줍니다. 이는 리소스를 컨테이너로 논리적 그룹화할 수 있는 방법인 Azure의 리소스 그룹을 통해 수행됩니다. 분리를 달성하는 다른 방법은 다른 Azure 구독, 네트워킹 및 서브넷 등이 될 수 있습니다.
다음 스크린샷은 이 리소스 그룹 내의 개발 환경 및 리소스를 보여 줍니다.
다음 스크린샷은 이 리소스 그룹 내의 프로덕션 환경 및 리소스를 보여 줍니다.
예시 증거:
다음 스크린샷은 개발/테스트를 위한 환경이 프로덕션 환경과 분리되어 있음을 보여 줍니다. 환경의 적절한 분리는 각 환경과 연결된 서로 다른 권한을 가진 다른 사용자/그룹을 통해 이루어집니다.
다음 스크린샷은 개발 환경 및 이 리소스 그룹에 액세스할 수 있는 사용자를 보여줍니다.
다음 스크린샷은 이 리소스 그룹에 액세스할 수 있는 프로덕션 환경 및 사용자(개발 환경과 다른)를 보여줍니다.
지침:
프로덕션 데이터베이스(중요한 정보 수정) 및 개발/테스트 데이터베이스에 대해 동일한 SQL 쿼리의 출력 스크린샷을 공유하여 증거를 제공할 수 있습니다. 동일한 명령의 출력은 다른 데이터 집합을 생성해야 합니다. 파일이 저장되는 경우 두 환경 내에서 폴더의 내용을 보는 것도 서로 다른 데이터 집합을 보여 주어야 합니다.
예제 증거
스크린샷은 프로덕션 데이터베이스의 상위 3개 레코드(증거 제출의 경우 상위 20개 제공)를 보여줍니다.
다음 스크린샷은 다른 레코드를 보여 주는 개발 데이터베이스의 동일한 쿼리를 보여줍니다.
참고: 이 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
보안 소프트웨어 개발/배포
소프트웨어 개발 활동에 관련된 조직은 종종 보안과 TTM(Time to Market) 압력 간의 경쟁 우선 순위에 직면하지만 SDLC(소프트웨어 개발 수명 주기)를 통해 보안 관련 활동을 구현하면 비용을 절감할 뿐만 아니라 시간을 절약할 수 있습니다. 보안이 사후 고려 사항으로 남아 있는 경우 문제는 일반적으로 DSLC(테스트 단계) 중에만 식별되며, 이는 종종 더 많은 시간이 걸리고 수정하는 데 비용이 많이 들 수 있습니다. 이 보안 섹션의 목적은 개발된 소프트웨어에 코딩 결함이 도입될 위험을 줄이기 위해 보안 소프트웨어 개발 사례를 따르도록 하는 것입니다. 또한 이 섹션에는 소프트웨어의 보안 배포에 도움이 되는 몇 가지 컨트롤이 포함되어 있습니다.
컨트롤 번호 12
설명서가 존재하고 유지 관리됨을 보여주는 증거를 제공하세요.
는 보안 소프트웨어 개발을 지원하며 OWASP 상위 10개 또는 SANS 상위 25개 CWE와 같은 보안 코딩에 대한 업계 표준 및/또는 모범 사례를 포함합니다.
개발자는 매년 관련 보안 코딩 및 보안 소프트웨어 개발 교육을 받습니다.
의도: 보안 개발
조직은 소프트웨어가 안전하게 개발되고 취약성으로부터 자유로워지도록 최선을 다해야 합니다. 이를 달성하기 위해 보안 코딩 기술을 촉진하고 전체 소프트웨어 개발 프로세스 전반에 걸쳐 안전한 개발을 촉진하기 위해 강력한 보안 SDLC(소프트웨어 개발 수명 주기) 및 보안 코딩 모범 사례를 설정해야 합니다. 소프트웨어의 취약성 수와 심각도를 줄이려는 의도입니다.
코드가 안전하게 개발되도록 모든 프로그래밍 언어에 대한 코딩 모범 사례 및 기술이 존재합니다. 개발자에게 다양한 유형의 소프트웨어 취약성 클래스와 이러한 취약성을 소프트웨어에 도입하는 것을 중지하는 데 사용할 수 있는 코딩 기술을 교육하도록 설계된 외부 교육 과정이 있습니다. 이 제어의 의도는 또한 모든 개발자에게 이러한 기술을 가르치고 이러한 기술이 잊혀지지 않도록하거나 매년 이를 수행하여 새로운 기술을 학습시키는 것입니다.
지침: 보안 개발
문서화된 SDLC 및/또는 지원 설명서를 제공하면 안전한 개발 수명 주기가 사용 중이며 모든 개발자가 보안 코딩 모범 사례를 홍보하기 위한 지침이 제공됩니다. SDLC의 OWASP 및 OWASP SAMM(Software Assurance MaturityModel)을 살펴봅니다.
예시 증거: 보안 개발
보안 소프트웨어 개발 정책 문서의 예는 다음과 같습니다. 다음은 안전한 개발 및 코딩 사례를 보여 주는 Contoso의 보안 소프트웨어 개발 절차에서 추출한 것입니다.
참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 모든 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
지침: 보안 개발 교육
외부 교육 회사에서 교육을 수행하는 경우 또는 개발자가 교육에 참석했다는 것을 보여주는 학습 일기 또는 기타 아티팩트 스크린샷을 제공하여 인증서를 통해 증거를 제공합니다. 이 학습이 내부 리소스를 통해 수행되는 경우 학습 자료의 증거도 제공합니다.
예시 증거: 보안 개발 교육
다음 스크린샷은 DevOps 팀의 직원에게 OWASP 상위 10개 교육 연간 교육에 등록하도록 요청하는 이메일입니다.
다음 스크린샷은 비즈니스 근거 및 승인을 통해 교육이 요청되었음을 보여줍니다. 그런 다음 학습에서 가져온 스크린샷과 그 사람이 연간 교육을 완료했음을 보여주는 완료 레코드가 표시됩니다.
참고: 이 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
컨트롤 번호 13
다음을 위해 코드 리포지토리가 보호된다는 증거를 제공하세요.
모든 코드 변경 내용은 기본 분기와 병합되기 전에 두 번째 검토자가 검토 및 승인 프로세스를 거칩니다.
적절한 액세스 제어가 있습니다.
모든 액세스는 MFA(다단계 인증)를 통해 적용됩니다.
프로덕션 환경에 적용된 모든 릴리스는 배포 전에 검토 및 승인됩니다.
의도: 코드 검토
이 하위 지점의 의도는 소프트웨어에 취약성을 초래할 수 있는 코딩 실수를 식별하기 위해 다른 개발자가 코드 검토를 수행하는 것입니다. 코드 검토 수행, 테스트 수행 등을 위해 권한 부여를 설정해야 합니다. 배포 전에. 권한 부여 단계에서는 컨트롤 12에 정의된 SDLC를 뒷받침하는 올바른 프로세스가 수행되었는지 확인합니다.
목표는 모든 코드 변경 내용이 기본 분기에 병합되기 전에 두 번째 검토자가 엄격한 검토 및 승인 프로세스를 거치도록 하는 것입니다. 이 이중 승인 프로세스는 코딩 오류, 보안 취약성 또는 애플리케이션의 무결성을 손상시킬 수 있는 기타 문제를 파악하는 것을 목표로 하는 품질 관리 조치의 역할을 합니다.
지침: 코드 검토
코드가 피어 검토를 거치고 프로덕션 환경에 적용되기 전에 권한이 부여되어야 한다는 증거를 제공합니다. 이 증거는 변경 티켓 내보내기를 통해 코드 검토가 수행되었으며 변경 내용이 승인되었음을 보여 주거나 Crucible과 같은 코드 검토 소프트웨어를 통해 이루어질 수 있습니다.
예시 증거: 코드 검토
다음은 코드 변경 내용이 원래 개발자가 아닌 다른 사용자가 검토 및 권한 부여 프로세스를 거치는 것을 보여 주는 티켓입니다. 이는 할당자가 코드 검토를 요청했으며 코드 검토를 위해 다른 사람에게 할당됨을 보여줍니다.
다음 이미지는 이미지 오른쪽의 강조 표시된 섹션에 표시된 대로 원래 개발자가 아닌 다른 사람에게 코드 검토가 할당되었음을 보여 주며, 왼쪽에서 코드를 검토하고 코드 검토자가 '통과한 코드 검토' 상태 부여했습니다. 이제 티켓은 라이브 프로덕션 시스템에 변경 내용을 적용하기 전에 관리자의 승인을 받아야 합니다.
다음 이미지는 검토된 코드가 라이브 프로덕션 시스템에 구현되도록 승인되었음을 보여줍니다. 코드 변경이 완료되면 최종 작업이 로그오프됩니다. 프로세스 전반에 걸쳐 코드의 원래 개발자, 코드 검토자 및 승인을 제공하고 로그오프할 수 있는 관리자 등 3명이 참여합니다. 이 컨트롤에 대한 기준을 충족하기 위해 티켓이 이 프로세스를 따를 것으로 예상합니다.
참고: 이 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
예시 증거: 코드 검토
위에 표시된 프로세스의 관리 부분 외에도 최신 코드 리포지토리 및 플랫폼과 함께 분기 정책 적용 검토와 같은 추가 컨트롤을 구현하여 이러한 검토가 완료될 때까지 병합이 수행되지 않도록 할 수 있습니다. 다음 예제에서는 DevOps에서 이 작업을 수행했음을 보여 줍니다.
다음 스크린샷은 기본 검토자가 할당되고 검토가 자동으로 필요하다는 것을 보여줍니다.
예시 증거: 코드 검토
Bitbucket에서 분기 정책 적용 검토를 수행할 수도 있습니다.
다음 스크린샷에서 기본 검토자가 설정됩니다. 이렇게 하면 변경 내용이 기본 분기에 전파되기 전에 병합에 할당된 개인의 검토가 필요합니다.
후속 두 스크린샷은 적용되는 구성 설정의 예를 보여 줍니다. 사용자 Silvester가 시작한 완료된 끌어오기 요청뿐만 아니라 기본 분기와 병합되기 전에 기본 검토자 Andrew의 승인이 필요했습니다.
증거가 제공되면 엔드 투 엔드 프로세스가 입증될 것이라는 기대가 있습니다. 참고: 분기 정책이 있는 경우(또는 다른 프로그래밍 방식의 방법/제어) 및 승인 티켓/레코드가 부여되는 경우 구성 설정을 보여 주는 스크린샷이 제공되어야 합니다.
의도: 제한된 액세스
이전 컨트롤에서 앞서 특정 프로젝트에서 작업하는 개별 사용자에 대한 액세스를 제한하기 위해 액세스 제어를 구현해야 합니다. 액세스를 제한하여 무단 변경이 수행될 위험을 제한하여 안전하지 않은 코드 변경을 도입할 수 있습니다. 코드 리포지토리를 보호하기 위해 최소 권한 있는 접근 방식을 취해야 합니다.
지침: 제한된 액세스
다양한 권한을 포함하여 액세스가 필요한 개인으로 제한된 코드 리포지토리의 스크린샷을 통해 증거를 제공합니다.
예시 증거: 제한된 액세스
다음 스크린샷은 Azure DevOps에서 구현된 액세스 제어를 보여 줍니다. "CloudDemo 팀"에는 두 명의 멤버가 있고 각 멤버에는 서로 다른 권한이 있는 것으로 표시됩니다.
참고: 다음 스크린샷은 이 컨트롤을 충족할 것으로 예상되는 증거 및 형식 형식의 예제를 보여 줍니다. 이는 광범위하지 않으며 실제 사례는 액세스 제어 구현 방법에 따라 다를 수 있습니다.
사용 권한이 그룹 수준에서 설정된 경우 Bitbucket에 대한 두 번째 예제와 같이 각 그룹 및 해당 그룹의 사용자에 대한 증거를 제공해야 합니다.
다음 스크린샷은 "CloudDemo 팀"의 구성원을 보여줍니다.
이전 이미지는 Andrew Smith가 아래의 Silvester보다 프로젝트 소유자로서 훨씬 더 높은 권한을 가지고 있음을 보여줍니다.
예제 증거
다음 스크린샷에서는 그룹 수준에서 설정된 권한을 통해 Bitbucket에서 구현된 액세스 제어를 구현합니다. 리포지토리 액세스 수준의 경우 한 사용자가 있는 "관리자" 그룹과 다른 사용자가 있는 "개발자" 그룹이 있습니다.
다음 스크린샷은 각 사용자가 다른 그룹에 속하며 기본적으로 다른 수준의 권한을 가지고 있음을 보여 줍니다. Andrew Smith는 관리자이며 Silvester는 개발자 그룹의 일부이며 개발자 권한만 부여합니다.
의도: MFA
위협 행위자가 소프트웨어의 코드 베이스에 액세스하고 수정할 수 있는 경우 취약성, 백도어 또는 악성 코드를 코드 베이스에 도입하여 애플리케이션에 도입할 수 있습니다. 공격자가 나중에 SolarWinds의 오리온 소프트웨어 업데이트에 포함 된 파일에 악성 코드를 주입 한 2020 년 SolarWinds 공격인 가장 공개 된이 인스턴스가 이미 있습니다. 18,000명 이상의 SolarWinds 고객이 악성 업데이트를 설치했으며, 맬웨어가 탐지되지 않고 확산되었습니다.
이 하위 지점의 의도는 MFA(다단계 인증)를 통해 코드 리포지토리에 대한 모든 액세스가 적용되는지 확인하는 것입니다.
지침: MFA
모든 사용자가 MFA를 사용하도록 설정한 코드 리포지토리의 스크린샷을 통해 증거를 제공합니다.
예시 증거: MFA
코드 리포지토리가 Azure DevOps에 저장되고 유지 관리되는 경우 테넌트 수준에서 MFA를 설정하는 방법에 따라 AAD(예: "사용자별 MFA")에서 증거를 제공할 수 있습니다. 다음 스크린샷은 MFA가 AAD의 모든 사용자에게 적용되며 Azure DevOps에도 적용됨을 보여 줍니다.
예시 증거: MFA
organization GitHub와 같은 플랫폼을 사용하는 경우 다음 스크린샷과 같이 '조직' 계정의 증거를 공유하여 2FA가 사용하도록 설정되어 있음을 보여줄 수 있습니다.
GitHub에서 organization 모든 멤버에 대해 2FA가 적용되는지 확인하려면 다음 스크린샷과 같이 organization 설정 탭으로 이동할 수 있습니다.
GitHub의 "사람" 탭으로 이동하면 다음 스크린샷과 같이 organization 내의 모든 사용자에 대해 "2FA"를 사용하도록 설정할 수 있습니다.
의도: 리뷰
이 컨트롤의 의도는 다른 개발자가 개발 환경에 릴리스를 검토하여 코딩 실수와 취약성을 초래할 수 있는 잘못된 구성을 식별하는 데 도움을 주기 위한 것입니다. 릴리스 검토가 수행되고 테스트가 수행되었는지 확인하기 위해 권한 부여를 설정해야 합니다. 프로덕션 환경에서 배포하기 전입니다. 권한 부여입니다. 단계는 SDLC 원칙을 뒷받침하는 올바른 프로세스가 수행되었는지 확인할 수 있습니다.
지침
테스트/개발 환경에서 프로덕션 환경으로의 모든 릴리스가 초기자와 다른 사람/개발자가 검토하고 있다는 증거를 제공합니다. 연속 통합/지속적인 배포 파이프라인을 통해 수행되는 경우 제공된 증거가 검토가 적용된다는 것을 표시해야 합니다(코드 검토와 동일).
예제 증거
다음 스크린샷에서는 CI/CD 파이프라인이 Azure DevOps에서 사용되고 있음을 확인할 수 있습니다. 파이프라인에는 개발 및 프로덕션이라는 두 단계가 포함되어 있습니다. 릴리스가 트리거되어 개발 환경에 성공적으로 배포되었지만 아직 두 번째 단계(프로덕션)로 전파되지 않았으며 Andrew Smith의 승인을 보류 중입니다.
일단 개발에 배포되면 보안 테스트는 관련 팀에서 발생하며, 배포를 검토할 수 있는 적절한 권한이 있는 할당된 개인이 보조 검토를 수행하고 모든 조건이 충족되는 것을 만족하는 경우에만 승인을 부여하여 릴리스를 프로덕션으로 만들 수 있습니다.
배포 전 조건이 트리거되었고 검토 및 승인이 보류 중임을 알리는 할당된 검토자가 일반적으로 수신하는 이메일 경고입니다.
검토자는 이메일 알림을 사용하여 DevOps의 릴리스 파이프라인으로 이동하여 승인을 부여할 수 있습니다. 승인을 정당화하는 주석이 추가된 것을 볼 수 있습니다.
두 번째 스크린샷에서는 승인이 부여되었고 프로덕션으로의 릴리스가 성공한 것으로 표시됩니다.
다음 두 스크린샷은 예상되는 증거의 샘플을 보여 줍니다.
기록 릴리스와 배포 전 조건이 적용되고 프로덕션 환경에 배포하기 전에 검토 및 승인이 필요하다는 증거가 표시됩니다.
다음 스크린샷은 개발 및 프로덕션 모두에 성공적으로 배포되었음을 확인할 수 있는 최근 릴리스를 포함한 릴리스 기록을 보여줍니다.
참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
계정 관리
사용자 계정이 정보 시스템, 시스템 환경 및 데이터에 대한 액세스를 허용하는 기반을 형성하기 때문에 보안 계정 관리 사례가 중요합니다. 사용자 자격 증명의 손상으로 사용자 계정을 올바르게 보호해야 합니다. 이 경우 환경에 대한 발판과 중요한 데이터에 대한 액세스를 제공할 수 있을 뿐만 아니라 사용자의 자격 증명에 관리 권한이 있는 경우 전체 환경 또는 키 시스템에 대한 관리 제어를 제공할 수도 있습니다.
컨트롤 번호 14
다음과 같은 증거를 제공합니다.
기본 자격 증명은 샘플링된 시스템 구성 요소에서 비활성화, 제거 또는 변경됩니다.
서비스 계정을 보호(강화)하기 위한 프로세스가 진행 중이며 이 프로세스가 수행되었습니다.
의도: 기본 자격 증명
인기가 낮아지고 있지만 위협 행위자가 기본 및 잘 문서화된 사용자 자격 증명을 활용하여 프로덕션 시스템 구성 요소를 손상할 수 있는 경우가 여전히 있습니다. 이 예제는 Dell iDRAC(통합 Dell 원격 액세스 컨트롤러)를 사용하는 것입니다. 이 시스템을 사용하여 Dell Server를 원격으로 관리할 수 있으며, 위협 행위자가 서버의 운영 체제를 제어하는 데 활용할 수 있습니다. root::calvin의 기본 자격 증명은 문서화되어 있으며 위협 행위자가 조직에서 사용하는 시스템에 액세스하기 위해 활용할 수 있는 경우가 많습니다. 이 컨트롤의 의도는 보안을 강화하기 위해 기본 자격 증명을 사용하지 않도록 설정하거나 제거하는 것입니다.
지침: 기본 자격 증명
이 제어를 지원하기 위해 증거를 수집할 수 있는 다양한 방법이 있습니다. 모든 시스템 구성 요소에서 구성된 사용자의 스크린샷은 CMD(명령 프롬프트)를 통해 Windows 기본 계정의 스크린샷과 Linux /etc/shadow 및 /etc/passwd 파일의 스크린샷을 통해 계정이 비활성화되었는지를 보여 주는 데 도움이 됩니다.
예시 증거: 기본 자격 증명
다음 스크린샷은 기본 계정에 잠긴 암호가 있고 새 생성/활성 계정에 사용 가능한 암호가 있음을 보여 주는 /etc/shadow 파일을 보여 줍니다.
암호 해시가 '!'와 같은 잘못된 문자로 시작하는 것을 관찰하여 암호를 사용할 수 없음을 나타내려면 /etc/shadow 파일이 필요합니다. 다음 스크린샷에서 "L"은 명명된 계정의 암호를 잠그는 것을 의미합니다. 이 옵션은 암호를 암호화할 수 없는 값과 일치하는 값으로 변경하여 암호를 사용하지 않도록 설정합니다(암호 시작 부분에 a!를 추가함). "P"는 사용 가능한 암호임을 의미합니다.
두 번째 스크린샷은 Windows 서버에서 모든 기본 계정이 비활성화되었음을 보여 줍니다. 터미널(CMD)에서 'net user' 명령을 사용하면 각 기존 계정의 세부 정보를 나열하여 이러한 모든 계정이 활성 상태가 아님을 확인할 수 있습니다.
CMD에서 net user 명령을 사용하면 모든 계정을 표시하고 모든 기본 계정이 활성화되지 않은 것을 확인할 수 있습니다.
의도: 기본 자격 증명
서비스 계정은 종종 상승된 권한으로 구성되기 때문에 위협 행위자가 대상으로 지정합니다. 서비스 계정 암호의 만료로 인해 기능이 중단되는 경우가 많으므로 이러한 계정은 표준 암호 정책을 따르지 않을 수 있습니다. 따라서 organization 내에서 다시 사용하는 약한 암호 또는 암호로 구성할 수 있습니다. 특히 Windows 환경 내에서 또 다른 잠재적인 문제는 운영 체제가 암호 해시를 캐시하는 것일 수 있습니다. 다음 중 하나를 수행하면 큰 문제가 될 수 있습니다.
서비스 계정은 디렉터리 서비스 내에서 구성됩니다. 이 계정은 권한 수준이 구성된 여러 시스템에서 액세스를 사용할 수 있으므로 또는
서비스 계정은 로컬이며, 환경 내의 여러 시스템에서 동일한 계정/암호가 사용될 가능성이 높습니다.
이전 문제는 위협 행위자가 환경 내에서 더 많은 시스템에 액세스하도록 유도할 수 있으며 권한 및/또는 횡적 이동의 추가 상승으로 이어질 수 있습니다. 따라서 이러한 서비스 계정 중 하나가 손상될 경우 위협 행위자가 서비스 계정을 점령하지 못하도록 보호하거나 위험을 제한하여 서비스 계정이 제대로 강화되고 보호되도록 하기 위한 것입니다. 컨트롤을 사용 권한 제한, 복잡한 암호 사용 및 일반 자격 증명 회전을 포함할 수 있는 이러한 계정의 강화를 위해 공식적인 프로세스가 있어야 합니다.
지침
인터넷에는 서비스 계정을 강화하는 데 도움이 되는 많은 가이드가 있습니다. 증거는 organization 계정의 보안 강화를 구현한 방법을 보여 주는 스크린샷 형식일 수 있습니다. 몇 가지 예(여러 기술을 사용할 것으로 예상됨)는 다음과 같습니다.
Active Directory 내의 컴퓨터 집합으로 계정 제한
대화형 로그인이 허용되지 않도록 계정을 설정합니다.
매우 복잡한 암호 설정
Active Directory의 경우 "계정이 중요하며 위임할 수 없습니다" 플래그를 사용하도록 설정합니다.
예제 증거
각 개별 환경에 종속되는 서비스 계정을 강화하는 방법에는 여러 가지가 있습니다. 다음은 사용할 수 있는 몇 가지 메커니즘입니다.
다음 스크린샷은 서비스 계정 "_Prod SQL 서비스 계정"에서 '계정이 중요하고 위임될 연결' 옵션이 선택되어 있는 것을 보여줍니다.
이 두 번째 스크린샷은 서비스 계정 "_Prod SQL 서비스 계정"이 SQL Server 잠겨 있으며 해당 서버에만 로그인할 수 있음을 보여줍니다.
다음 스크린샷은 서비스 계정 "_Prod SQL 서비스 계정"이 서비스로만 로그인할 수 있음을 보여줍니다.
참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
컨트롤 번호 15
다음과 같은 증거를 제공합니다.
고유한 사용자 계정은 모든 사용자에게 발급됩니다.
사용자 최소 권한 원칙은 환경 내에서 수행되고 있습니다.
강력한 암호/암호 정책 또는 기타 적절한 완화 방법이 있습니다.
프로세스가 진행 중이며 적어도 3개월마다 수행되어 3개월 이내에 사용되지 않는 계정을 사용하지 않도록 설정하거나 삭제합니다.
의도: 보안 서비스 계정
이 컨트롤의 의도는 책임입니다. 고유한 사용자 계정으로 사용자를 발급하면 사용자 활동을 개별 사용자에게 추적할 수 있으므로 사용자는 자신의 작업에 대한 책임을 져야 합니다.
지침: 보안 서비스 계정
증거는 서버, 코드 리포지토리, 클라우드 관리 플랫폼, Active Directory, 방화벽 등을 포함할 수 있는 scope 시스템 내 구성 요소에서 구성된 사용자 계정을 보여 주는 스크린샷을 통해서입니다.
예시 증거: 보안 서비스 계정
다음 스크린샷은 scope Azure 환경에 대해 구성된 사용자 계정과 모든 계정이 고유하다는 것을 보여 줍니다.
의도: 권한
사용자는 자신의 작업 기능을 수행하는 데 필요한 권한만 제공해야 합니다. 이는 사용자가 의도하거나 의도치 않게 데이터에 액세스하거나 수행하지 않아야 하는 위험을 제한하기 위한 것입니다.
악의적인 행위. 이 원칙에 따라 악의적인 위협 행위자가 대상으로 지정할 수 있는 잠재적인 공격 노출 영역(즉, 권한 있는 계정)도 줄입니다.
지침: 권한
대부분의 조직은 그룹을 활용하여 organization 내의 팀에 따라 권한을 할당합니다. 증거는 다양한 권한 있는 그룹과 이러한 권한이 필요한 팀의 사용자 계정만 보여주는 스크린샷일 수 있습니다. 일반적으로 이 작업은 필요한 권한과 비즈니스 타당성 및 그룹 멤버 자격의 유효성을 검사하기 위한 팀 구성원 계층 구조가 올바르게 구성된 각 정의된 그룹을 정의하는 지원 정책/프로세스로 백업됩니다.
예를 들어 Azure 내에서 소유자 그룹은 매우 제한적이어야 하므로 이를 문서화해야 하며 해당 그룹에 할당된 사용자 수가 제한되어 있어야 합니다. 또 다른 예는 코드를 변경할 수 있는 제한된 수의 직원일 수 있으며, 그룹은 이 권한을 구성해야 하는 것으로 간주되는 직원과 함께 이 권한으로 설정할 수 있습니다. 인증 분석가가 구성된 그룹 등과 문서를 상호 참조할 수 있도록 문서화해야 합니다.
예시 증거: 권한
다음 스크린샷은 Azure 환경에서 최소 권한의 원칙을 보여 줍니다.
다음 스크린샷은 AAD(Azure Active Directory)/Microsoft Entra 다양한 그룹의 사용을 강조 표시합니다. 개발자, 수석 엔지니어, 보안 운영이라는 세 가지 보안 그룹이 있는지 확인합니다.
그룹 수준에서 "개발자" 그룹으로 이동하면 할당된 역할만 "애플리케이션 개발자" 및 "디렉터리 읽기 권한자"입니다.
다음 스크린샷은 "개발자" 그룹의 멤버를 보여 줍니다.
마지막으로 다음 스크린샷은 그룹의 소유자를 보여줍니다.
"개발자" 그룹과 달리 "보안 작업"에는 작업 요구 사항에 부합하는 다른 역할(예: "보안 운영자")이 할당됩니다.
다음 스크린샷은 "보안 작업" 그룹의 일부인 다른 멤버가 있음을 보여 줍니다.
마지막으로 그룹에는 다른 소유자가 있습니다.
글로벌 관리자는 매우 권한 있는 역할이며 조직은 이러한 유형의 액세스를 제공할 때 수락하려는 위험 수준을 결정해야 합니다. 제공된 예제에는 이 역할을 가진 두 명의 사용자만 있습니다. 이는 공격 표면과 영향이 감소하도록 하기 위한 것입니다.
의도: 암호 정책
사용자 자격 증명은 종종 organization 환경에 액세스하려는 위협 행위자의 공격 대상입니다. 강력한 암호 정책의 의도는 사용자가 강력한 암호를 선택하도록 강요하여 위협 행위자가 무차별 암호로 강제 적용할 가능성을 완화하는 것입니다. "또는 기타 적합한 완화"를 추가하려는 의도는 조직에서 NIST특별 발행물 800-63B와 같은 업계 발전에 따라 사용자 자격 증명을 보호하는 데 도움이 되는 다른 보안 조치를 구현할 수 있음을 인식하는 것입니다.
지침: 암호 정책
강력한 암호 정책을 보여 주는 증거는 조직 그룹 정책 개체 또는 로컬 보안 정책 "계정 정책 → 암호 정책" 및 "계정 정책 → 계정 잠금 정책" 설정의 스크린샷 형식일 수 있습니다. 증거는 사용 중인 기술에 따라 달라집니다. 즉, Linux의 경우 /etc/pam.d/common-password 구성 파일일 수 있으며, Bitbucket의 경우 관리 포털 내의 "인증 정책" 섹션 [암호 정책 관리 | Atlassian지원 등
예시 증거: 암호 정책
다음 증거는 in-scope 시스템 구성 요소 "CONTOSO-SRV1"의 "로컬 보안 정책" 내에 구성된 암호 정책을 보여줍니다.
다음 스크린샷은 WatchGuard 방화벽에 대한 계정 잠금 설정을 보여줍니다.
다음은 WatchGuard 방화벽에 대한 최소 암호 길이의 예입니다.
참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 제출된 모든 ISV 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
의도: 비활성 계정
비활성 계정은 사용자가 계정에 로그인하려고 하지 않을 때 플래그가 지정되지 않을 수 있는 무차별 암호 대입 공격의 대상이 되거나 사용자의 암호가 재사용되어 인터넷의 사용자 이름/암호 덤프 내에서 사용할 수 있는 암호 데이터베이스 위반을 통해 손상될 수 있습니다. 위협 행위자가 계정 손상 활동을 수행해야 하는 공격 노출 영역을 줄이려면 사용하지 않는 계정을 사용하지 않도록 설정/제거해야 합니다. 이러한 계정은 휴가 프로세스가 제대로 수행되지 않거나, 장기 질병을 앓고 있는 직원 또는 출산/육아 휴직을 하는 직원 때문일 수 있습니다. 조직에서는 이러한 계정을 식별하는 분기별 프로세스를 구현하여 공격 노출 영역을 최소화할 수 있습니다.
이 제어는 일반 계정 검토 및 사용되지 않는 계정의 적시 비활성화를 보장하여 위험을 줄이기 위해 지난 3개월 이내에 사용되지 않은 계정을 사용하지 않도록 설정하거나 삭제하기 위해 프로세스를 마련하고 최소 3개월마다 수행해야 합니다.
지침: 비활성 계정
증거는 두 배여야 합니다.
먼저 scope 환경 내의 모든 사용자 계정의 "마지막 로그온"을 보여 주는 스크린샷 또는 파일 내보내기입니다. AAD(Azure Active Directory)와 같은 중앙 집중식 디렉터리 서비스 내의 계정뿐만 아니라 로컬 계정일 수 있습니다. 이는 3개월보다 오래된 계정이 활성화되지 않음을 보여 줍니다.
둘째, ADO(Azure DevOps) 또는 JIRA 티켓 내에서 또는 로그오프해야 하는 종이 레코드를 통해 완료되는 작업의 다큐멘터리 증거일 수 있는 분기별 검토 프로세스의 증거입니다.
예시 증거: 비활성 계정
다음 스크린샷은 클라우드 플랫폼이 액세스 검토를 수행하는 데 활용되었음을 보여 줍니다. 이 작업은 Azure에서 ID 거버넌스 기능을 사용하여 수행되었습니다.
다음 스크린샷은 검토 기록, 검토 기간 및 상태 보여 줍니다.
검토를 구성하는 dashboard 및 메트릭은 organization 모든 사용자인 scope 및 검토 결과뿐만 아니라 분기별 빈도와 같은 추가 세부 정보를 제공합니다.
검토 결과를 평가할 때 이미지는 미리 구성된 조건에 따라 권장 작업이 제공되었음을 나타냅니다. 또한 할당된 개인이 검토 결정을 수동으로 적용해야 합니다.
다음에서 모든 직원에게 권장 사항과 근거를 제공하는 것을 관찰할 수 있습니다. 앞에서 설명한 대로 권장 사항을 수락하거나 검토를 적용하기 전에 무시하기로 결정하는 것은 할당된 개인이 요구합니다. 최종 결정이 권장 사항에 위배되는 경우 그 이유를 설명하는 데 증거가 제공될 것으로 기대됩니다.
컨트롤 번호 16
모든 코드 리포지토리 및 클라우드 관리 인터페이스에 대한 액세스를 포함하여 모든 원격 액세스 연결 및 모든 비 콘솔 관리 인터페이스에 대해 MFA(다단계 인증)가 구성되어 있는지 확인합니다.
이러한 용어의 의미
원격 액세스 – 지원 환경에 액세스하는 데 사용되는 기술을 나타냅니다. 예를 들어 원격 액세스 IPSec VPN, SSL VPN 또는 Jumpbox/Bastian 호스트입니다.
비 콘솔 관리 인터페이스 – 시스템 구성 요소에 대한 네트워크 관리 연결을 나타냅니다. 원격 데스크톱, SSH 또는 웹 인터페이스를 통해 이 작업을 수행할 수 있습니다.
코드 리포지토리 – 앱에 맬웨어를 도입할 수 있는 악의적인 수정으로부터 앱의 코드 베이스를 보호해야 합니다. MFA는 코드 리포지토리에서 구성해야 합니다.
클라우드 관리 인터페이스 – CSP(클라우드 서비스 공급자) 내에서 일부 또는 모든 환경이 호스트되는 위치입니다. 클라우드 관리를 위한 관리 인터페이스는 여기에 포함되어 있습니다.
의도: MFA
이 컨트롤의 의도는 MFA( 다단계 인증 )를 구현하여 환경에 대한 보안 액세스를 통해 권한 있는 계정에 대한 무차별 암호 대입 공격에 대한 완화를 제공하는 것입니다. 암호가 손상된 경우에도 모든 액세스 및 관리 작업이 권한 있고 신뢰할 수 있는 직원에 의해서만 수행되도록 MFA 메커니즘을 보호해야 합니다.
보안을 강화하려면 MFA를 사용하여 원격 액세스 연결 및 비 콘솔 관리 인터페이스 모두에 대한 추가 보안 계층을 추가하는 것이 중요합니다. 원격 액세스 연결은 권한 없는 항목에 특히 취약하며 관리 인터페이스는 높은 권한 기능을 제어하여 강화된 보안 조치가 필요한 중요한 영역을 모두 만듭니다. 또한 코드 리포지토리에는 중요한 개발 작업이 포함되며, 클라우드 관리 인터페이스는 organization 클라우드 리소스에 대한 광범위한 액세스를 제공하여 MFA로 보호해야 하는 추가 중요한 지점이 됩니다.
지침: MFA
증거는 MFA가 이전 범주에 맞는 모든 기술에 대해 사용하도록 설정되어 있음을 보여줘야 합니다. 이는 MFA가 시스템 수준에서 사용하도록 설정되어 있음을 보여 주는 스크린샷을 통해서일 수 있습니다. 시스템 수준별로 MFA를 사용하도록 설정된 계정의 예뿐만 아니라 모든 사용자에 대해 사용하도록 설정되어 있다는 증거가 필요합니다. 이 기술이 MFA 솔루션으로 백업되는 경우 사용 중임을 입증하는 증거가 필요합니다. 의미는 다음과 같습니다. 기술이 MFA 공급자를 가리키는 Radius 인증을 위해 설정된 경우, 해당 기술이 가리키는 Radius Server가 MFA 솔루션이며 해당 계정이 이를 활용하도록 구성되어 있음을 증명해야 합니다.
예시 증거: MFA
다음 스크린샷은 AAD/Entra에서 MFA 조건부 정책을 구현하여 organization 2단계 인증 요구 사항을 적용하는 방법을 보여 줍니다. 다음에서 정책이 "on"인 것을 볼 수 있습니다.
다음 스크린샷은 MFA 정책이 organization 내의 모든 사용자에게 적용되고 사용하도록 설정되어 있음을 보여줍니다.
다음 스크린샷은 MFA 조건을 충족할 때 액세스 권한이 부여됨을 보여 줍니다. 스크린샷의 오른쪽에서 MFA가 구현된 후에만 사용자에게 액세스 권한이 부여된다는 것을 알 수 있습니다.
예시 증거: MFA
MFA 등록 요구 사항과 같은 추가 컨트롤을 구현하여 등록 시 사용자가 새 계정에 액세스하기 전에 MFA를 구성해야 합니다. 모든 사용자에게 적용되는 MFA 등록 정책의 구성 아래에서 확인할 수 있습니다.
제외 없이 적용할 정책을 보여 주는 이전에 스크린샷의 연속에서 다음 스크린샷은 모든 사용자가 정책에 포함되어 있음을 보여 줍니다.
예시 증거: MFA
다음 스크린샷은 "사용자별 MFA" 페이지에서 MFA가 모든 사용자에게 적용됨을 보여 줌을 보여줍니다.
예시 증거: MFA
다음 스크린샷은 환경에 대한 원격 액세스에 사용되는 Pulse Secure에 구성된 인증 영역을 보여 줍니다. 인증은 MFA 지원용 Duo SaaS 서비스에 의해 백업됩니다.
이 스크린샷은 'Duo - 기본 경로' 인증 영역에 대해 "Duo-LDAP"를 가리키는 추가 인증 서버가 사용하도록 설정되어 있음을 보여 줍니다.
이 마지막 스크린샷은 이 서버가 MFA용 Duo SaaS 서비스를 가리키는 것을 보여 주는 Duo-LDAP 인증 서버에 대한 구성을 보여 줍니다.
참고: 이전 예제에서는 전체 스크린샷이 사용되지 않았습니다. 그러나 모든 ISV 제출 증거 스크린샷은 URL, 로그인한 사용자 및 시스템 시간 및 날짜를 보여 주는 전체 스크린샷이어야 합니다.
보안 이벤트 로깅, 검토 및 경고
보안 이벤트 로깅은 organization 보안 프로그램의 필수적인 부분입니다. 조정된 경고 및 검토 프로세스와 결합된 적절한 보안 이벤트 로깅은 조직이 보안 및 방어 보안 전략을 강화하기 위해 organization 사용할 수 있는 위반 또는 시도된 위반을 식별하는 데 도움이 됩니다. 또한 적절한 로깅은 조직 인시던트 대응 기능에 중요한 역할을 하며, 이러한 기능은 손상된 데이터와 누가 손상되었는지 정확하게 식별할 수 있고, 손상 기간, 정부 기관에 자세한 분석 보고서 제공 등과 같은 다른 활동에 영향을 줄 수 있습니다.
보안 로그를 검토하는 것은 조직이 보안 위반 또는 정찰 활동을 나타낼 수 있는 보안 이벤트를 식별하는 데 중요한 기능입니다. 이 작업은 매일 수동 프로세스를 통해 수행하거나 감사 로그를 분석하고 수동 검사를 위해 플래그를 지정할 수 있는 상관 관계 및 변칙을 찾는 데 도움이 되는 SIEM(보안 정보 및 이벤트 관리) 솔루션을 사용하여 수행할 수 있습니다.
데이터 및 운영 환경에 미치는 영향을 최소화하려면 중요한 보안 이벤트를 즉시 조사해야 합니다. 경고는 직원에게 잠재적인 보안 위반을 즉시 강조 표시하여 organization 보안 이벤트를 가능한 한 빨리 포함할 수 있도록 적시에 대응하는 데 도움이 됩니다. 경고가 효과적으로 작동하도록 함으로써 조직은 보안 위반의 영향을 최소화하여 조직 브랜드를 손상시키고 벌금 및 평판 손상을 통해 재정적 손실을 부과할 수 있는 심각한 위반의 가능성을 줄일 수 있습니다.
컨트롤 번호 17
보안 이벤트 로깅이 scope 환경 전체에서 다음과 같은 적용 가능한 이벤트를 기록하도록 설정되었다는 증거를 제공하세요.
시스템 구성 요소 및 애플리케이션에 대한 사용자/s 액세스
권한이 높은 사용자가 수행한 모든 작업입니다.
잘못된 논리 액세스 시도.
권한 있는 계정 만들기/수정.
이벤트 로그 변조.
보안 도구 사용 안 함; 예를 들어 이벤트 로깅입니다.
맬웨어 방지 로깅; 예를 들어 업데이트, 맬웨어 검색, 검사 실패가 있습니다.
의도: 이벤트 로깅
시도된 위반과 실제 위반을 식별하려면 환경을 구성하는 모든 시스템에서 적절한 보안 이벤트 로그를 수집하는 것이 중요합니다. 이 컨트롤의 의도는 올바른 유형의 보안 이벤트를 캡처한 다음, 검토 및 경고 프로세스에 전달하여 이러한 이벤트를 식별하고 대응하는 데 도움이 되도록 하는 것입니다.
이 하위 지점에서는 ISV가 시스템 구성 요소 및 애플리케이션에 대한 사용자 액세스의 모든 인스턴스를 캡처하도록 보안 이벤트 로깅을 설정해야 합니다. 이는 organization 내에서 시스템 구성 요소 및 애플리케이션에 액세스하는 사용자를 모니터링하는 데 중요하며 보안 및 감사 목적 모두에 필수적입니다.
이 하위 지점에서는 높은 수준의 권한을 가진 사용자가 수행한 모든 작업이 기록되어야 합니다. 권한이 높은 사용자는 organization 보안 태세에 영향을 미칠 수 있는 중요한 변경을 수행할 수 있습니다. 따라서 해당 작업의 레코드를 유지하는 것이 중요합니다.
이 하위 지점에는 시스템 구성 요소 또는 애플리케이션에 대한 논리적 액세스를 얻기 위한 잘못된 시도의 로깅이 필요합니다. 이러한 로깅은 무단 액세스 시도 및 잠재적 보안 위협을 검색하는 기본 방법입니다.
이 하위 지점에는 권한 있는 액세스 권한이 있는 계정을 만들거나 수정하는 모든 로깅이 필요합니다. 이러한 유형의 로깅은 시스템 액세스 수준이 높고 공격자가 대상으로 지정할 수 있는 계정에 대한 변경 내용을 추적하는 데 매우 중요합니다.
이 하위 지점에는 이벤트 로그를 변조하려는 모든 시도의 로깅이 필요합니다. 로그를 변조하는 것은 무단 활동을 숨기는 방법이 될 수 있으므로 이러한 작업을 기록하고 조치를 취하는 것이 중요합니다.
이 하위 지점에는 이벤트 로깅 자체를 포함하여 보안 도구를 사용하지 않도록 설정하는 모든 작업의 로깅이 필요합니다. 보안 도구를 사용하지 않도록 설정하는 것은 공격 또는 내부 위협을 나타내는 빨간색 플래그일 수 있습니다.
이 하위 지점에는 업데이트, 맬웨어 검색 및 검사 실패를 포함하여 맬웨어 방지 도구와 관련된 활동의 로깅이 필요합니다. 맬웨어 방지 도구의 적절한 작동 및 업데이트는 이러한 활동과 관련된 organization 보안 및 로그가 모니터링에 도움이 되는 데 필수적입니다.
지침: 이벤트 로깅
스크린샷 또는 구성 설정을 통해 모든 샘플링된 디바이스 및 관련성의 시스템 구성 요소에 대한 증거를 제공하여 이러한 유형의 보안 이벤트가 캡처되도록 로깅을 구성하는 방법을 보여 주어야 합니다.
예제 증거
다음 스크린샷은 Azure의 여러 리소스에서 생성된 로그 및 메트릭의 구성을 보여 줍니다. 그러면 중앙 집중식 Log Analytic 작업 영역으로 수집됩니다.
첫 번째 스크린샷에서 로그 스토리지 위치가 "PaaS-web-app-log-analytics"인 것을 볼 수 있습니다.
Azure에서 아래와 같이 감사, 보안 및 진단 로그에 액세스하기 위해 Azure 리소스에서 진단 설정을 사용하도록 설정할 수 있습니다. 자동으로 사용할 수 있는 활동 로그에는 이벤트 원본, 날짜, 사용자, 타임스탬프, 원본 주소, 대상 주소 및 기타 유용한 요소가 포함됩니다.
참고: 다음 예제에서는 이 컨트롤을 충족하도록 제공할 수 있는 증거 유형을 보여 줍니다. 이는 organization scope 환경에서 보안 이벤트 로깅을 설정하는 방법에 따라 달라집니다. 다른 예로는 Azure Sentinel, Datadog 등이 있습니다.
Azure 앱 Services에서 호스트되는 웹앱에 대한 "진단 설정" 옵션을 사용하여 생성되는 로그와 스토리지 및 분석을 위해 전송되는 위치를 구성할 수 있습니다.
다음 스크린샷에서 '액세스 감사 로그' 및 'IPSecurity 감사 로그'는 Log Analytic 작업 영역에 생성되고 캡처되도록 구성됩니다.
또 다른 예는 동일한 중앙 집중식 Log Analytic 작업 영역에 생성된 로그를 보내도록 구성된 Azure Front Door에 대한 것입니다.
"진단 설정" 옵션을 사용하기 전과 마찬가지로 생성되는 로그와 스토리지 및 분석을 위해 전송되는 위치를 구성합니다. 다음 스크린샷은 '액세스 로그' 및 'WAF 로그'가 구성되었음을 보여 줍니다.
마찬가지로 Azure SQL 서버의 경우 "진단 설정"은 생성되는 로그와 스토리지 및 분석을 위해 전송되는 위치를 구성할 수 있습니다.
다음 스크린샷은 SQL 서버에 대한 '감사' 로그가 생성되어 Log Analytics 작업 영역으로 전송되는 것을 보여 줍니다.
예제 증거
AAD/Entra의 다음 스크린샷은 권한 있는 역할 및 관리자에 대한 감사 로그가 생성되고 있음을 보여 줍니다. 정보에는 상태, 활동, 서비스, 대상 및 초기자가 포함됩니다.
다음 스크린샷은 로그인 로그를 보여 줍니다. 로그 정보에는 IP 주소, 상태, 위치 및 날짜가 포함됩니다.
예제 증거
다음 예제에서는 Virtual Machines(VM)와 같은 컴퓨팅 인스턴스에 대해 생성된 로그에 중점을 둡니다. 데이터 수집 규칙이 구현되었으며 보안 감사 로그를 포함한 Windows 이벤트 로그가 캡처됩니다.
다음 스크린샷은 "Galaxy-Compliance"이라는 샘플링된 디바이스의 구성 설정의 또 다른 예를 보여줍니다. 설정은 '로컬 보안 정책' 내에서 사용하도록 설정된 다양한 감사 설정을 보여 줍니다.
다음 스크린샷은 사용자가 샘플링된 디바이스 "Galaxy-Compliance"에서 이벤트 로그를 지워온 이벤트를 보여줍니다.
참고: 이전 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자와 증거 검토를 위한 시간 및 날짜 스탬프가 있어야 합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.
컨트롤 번호 18
최소 30일 분량의 보안 이벤트 로깅 데이터를 즉시 사용할 수 있으며 90일의 보안 이벤트 로그가 유지된다는 증거를 제공합니다.
의도: 이벤트 로깅
경우에 따라 손상 또는 보안 이벤트와 이를 식별하는 organization 간에 시간 차이가 있습니다. 이 제어의 목적은 organization 인시던트 대응 및 필요할 수 있는 모든 포렌식 조사 작업을 돕기 위해 기록 이벤트 데이터에 액세스할 수 있도록 하는 것입니다. organization 보안 인시던트에 대한 신속한 조사 및 대응을 용이하게 하기 위해 분석에 즉시 사용할 수 있는 최소 30일 분량의 보안 이벤트 로깅 데이터를 유지하도록 합니다. 또한 심층 분석을 위해 총 90일 분량의 보안 이벤트 로그가 보존됩니다.
지침: 이벤트 로깅
일반적으로 증거는 중앙 집중식 로깅 솔루션의 구성 설정을 표시하여 데이터가 유지되는 기간을 보여 주는 것입니다. 30일 분량의 보안 이벤트 로깅 데이터는 솔루션 내에서 즉시 사용할 수 있어야 합니다. 그러나 데이터가 보관되는 경우 90일 분량의 데이터를 사용할 수 있음을 입증해야 합니다. 내보낸 데이터의 날짜가 포함된 보관 폴더를 표시할 수 있습니다.
예시 증거: 이벤트 로깅
중앙 집중식 Log Analytic 작업 영역을 사용하여 클라우드 리소스에서 생성된 모든 로그를 저장하는 컨트롤 17의 이전 예제에 따라 로그가 각 로그 범주의 개별 테이블에 저장되는 것을 아래에서 확인할 수 있습니다. 또한 모든 테이블에 대한 대화형 보존 기간은 90일입니다.
다음 스크린샷은 Log Analytic 작업 영역의 보존 기간에 대한 구성 설정을 보여 주는 추가 증거를 제공합니다.
예제 증거
다음 스크린샷은 AlienVault 내에서 30일 분량의 로그를 사용할 수 있음을 보여 줍니다.
참고: 공용 문서이므로 방화벽 일련 번호는 수정되었지만 ISV는 분석가에게 공개해야 하는 PII(개인 식별 정보)를 포함하지 않는 한 수정 없이 이 정보를 제출해야 합니다.
다음 스크린샷은 5개월 전으로 거슬러 올라가는 로그 추출을 보여 줌으로써 로그를 사용할 수 있음을 보여 줍니다.
참고: 공용 문서이므로 공용 IP 주소가 수정되었지만 ISV는 분석가와 먼저 논의해야 하는 PII(개인 식별 정보)를 포함하지 않는 한 수정 없이 이 정보를 제출해야 합니다.
참고: 이전 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자와 증거 검토를 위한 시간 및 날짜 스탬프가 있어야 합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.
예제 증거
다음 스크린샷은 로그 이벤트가 Azure 내 콜드 스토리지에서 30일 동안 라이브로 유지되고 90일 동안 유지되는 것을 보여줍니다.
참고: 구성된 보존을 보여 주는 구성 설정 외에도 로그가 90일 동안 보존되는지 확인하기 위해 90일 기간의 로그 샘플이 제공됩니다.
참고: 이러한 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자 및 증거 검토를 위한 시간 및 날짜 스탬프가 필요합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.
컨트롤 번호 19
다음을 보여주는 증거를 제공하세요.
로그는 주기적으로 검토되고 있으며 검토 프로세스 중에 식별된 잠재적인 보안 이벤트/변칙이 조사 및 해결됩니다.
의도: 이벤트 로깅
이 컨트롤의 의도는 주기적인 로그 검토가 수행되고 있는지 확인하는 것입니다. 보안 이벤트 경고를 제공하도록 구성된 경고 스크립트/쿼리에서 선택하지 못할 수 있는 변칙을 식별하는 것이 중요합니다. 또한 로그 검토 중에 식별되는 모든 변칙이 조사되고 적절한 수정 또는 작업이 수행됩니다. 여기에는 일반적으로 변칙에 조치가 필요한지 확인한 다음 인시던트 응답 프로세스를 호출해야 할 수 있는 심사 프로세스가 포함됩니다.
지침: 이벤트 로깅
로그 검토가 수행되고 있음을 보여주는 스크린샷에서 증거를 제공합니다. 이는 매일 완료되는 양식을 통해 또는 를 사용하여 JIRA 또는 DevOps 티켓을 통해 수행될 수 있습니다.
이를 표시하기 위해 게시되는 관련 메모가 수행됩니다. 변칙에 플래그가 지정된 경우 로그 검토의 일부로 식별된 변칙이 후속 조치된 다음 이후에 수행된 활동을 자세히 설명하는 것을 보여주기 위해 이 동일한 티켓 내에 문서화할 수 있습니다. 이렇게 하면 수행되는 모든 활동을 추적하기 위해 특정 JIRA 티켓이 발생하라는 메시지가 표시되거나 로그 검토 티켓 내에 문서화될 수 있습니다. 인시던트 대응 작업이 필요한 경우 인시던트 대응 프로세스의 일부로 문서화해야 하며 이를 입증하기 위해 증거를 제공해야 합니다.
예시 증거: 이벤트 로깅
이 첫 번째 스크린샷은 사용자가 'Domain Admins' 그룹에 추가된 위치를 식별합니다.
다음 스크린샷은 실패한 여러 로그온 시도 다음에 성공적인 무차별 암호 대입 공격을 강조 표시할 수 있는 성공적인 로그인이 이어지는 위치를 식별합니다.
이 마지막 스크린샷은 정책 설정을 통해 암호 정책 변경이 발생한 위치를 식별하므로 계정 암호가 만료되지 않습니다.
다음 스크린샷은 위의 이전 규칙을 트리거하여 SOC의 ServiceNow 도구 내에서 티켓이 자동으로 발생한다는 것을 보여줍니다.
참고: 이러한 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자 및 증거 검토를 위한 시간 및 날짜 스탬프가 필요합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.
컨트롤 번호 20
다음을 보여주는 증거를 제공하세요.
경고 규칙은 해당하는 경우 다음 보안 이벤트에 대한 조사를 위해 경고가 트리거되도록 구성됩니다.
권한 있는 계정 만들기/수정.
권한 있는/고위험 활동 또는 작업.
맬웨어 이벤트.
이벤트 로그 변조.
IDPS/WAF 이벤트(구성된 경우).
의도: 경고
이는 환경 위반 및/또는 데이터 위반을 가리킬 수 있는 보안 이벤트가 발생했음을 강조 표시할 수 있는 몇 가지 유형의 보안 이벤트입니다.
이 하위 지점은 권한 있는 계정을 만들거나 수정할 때 조사를 트리거하도록 경고 규칙이 특별히 구성되도록 하기 위한 것입니다. 권한 있는 계정 만들기 또는 수정의 경우 로그를 생성해야 하며, 새 권한 있는 계정을 만들거나 기존 권한 있는 계정 권한이 변경될 때마다 경고가 트리거되어야 합니다. 이렇게 하면 무단 또는 의심스러운 활동을 추적하는 데 도움이 됩니다.
이 하위 지점은 권한 있거나 위험이 높은 활동 또는 작업이 수행될 때 적절한 직원에게 알리도록 경고 규칙을 설정하는 것을 목표로 합니다. 권한 있는 활동 또는 고위험 활동 또는 작업의 경우 이러한 활동이 시작될 때 적절한 담당자에게 알리도록 경고를 설정해야 합니다. 여기에는 방화벽 규칙 변경, 데이터 전송 또는 중요한 파일에 대한 액세스가 포함될 수 있습니다.
이 하위 지점의 의도는 맬웨어 관련 이벤트에 의해 트리거되는 경고 규칙의 구성을 의무화하는 것입니다. 맬웨어 이벤트는 기록될 뿐만 아니라 조사를 위한 즉각적인 경고를 트리거해야 합니다. 이러한 경고는 응답 시간을 신속하게 처리하기 위해 원본, 맬웨어의 특성 및 영향을 받는 시스템 구성 요소와 같은 세부 정보를 포함하도록 설계되어야 합니다.
이 하위 지점은 이벤트 로그를 변조하면 조사에 대한 즉각적인 경고가 트리거되도록 설계되었습니다. 이벤트 로그 변조와 관련하여 로그에 대한 무단 액세스 또는 로그 수정이 감지될 때 경고를 트리거하도록 시스템을 구성해야 합니다. 이렇게 하면 이벤트 로그의 무결성이 보장되며, 이는 포렌식 분석 및 규정 준수 감사에 매우 중요합니다.
이 하위 지점은 IDPS(침입 감지 및 방지 시스템) 또는 WAF(웹 애플리케이션 방화벽)가 구성된 경우 조사를 위해 경고를 트리거하도록 설정되도록 합니다. IDPS(침입 감지 및 방지 시스템) 또는 WAF(웹 애플리케이션 방화벽)가 구성된 경우 반복된 로그인 실패, SQL 삽입 시도 또는 서비스 거부 공격을 제안하는 패턴과 같은 의심스러운 활동에 대한 경고를 트리거하도록 설정해야 합니다.
지침: 경고
경고 구성의 스크린샷과 수신되는 경고의 증거를 통해 증거를 제공해야 합니다. 구성 스크린샷은 경고를 트리거하는 논리와 경고를 보내는 방법을 보여 줍니다. SMS, Email, Teams 채널, Slack 채널 등을 통해 경고를 보낼 수 있습니다.
예시 증거: 경고
다음 스크린샷은 Azure에서 구성되는 경고의 예를 보여 줍니다. 첫 번째 스크린샷에서 VM이 중지되고 할당을 취소할 때 경고가 발생했음을 확인할 수 있습니다. 이는 Azure에서 구성된 경고의 예를 보여 줍니다. 컨트롤 설명에 지정된 모든 이벤트에 대해 경고가 생성되었음을 보여 주는 증거가 제공될 것으로 예상합니다.
다음 스크린샷은 Azure 리소스 그룹 수준뿐만 아니라 Azure App Service 수준에서 수행되는 모든 관리 작업에 대해 구성된 경고를 보여 줍니다.
예제 증거
Contoso는 Contoso Security에서 제공하는 타사 SOC(보안 운영 센터)를 활용합니다. 이 예제에서는 SOC에서 활용하는 AlienVault 내의 경고가 Contoso Security의 SOC 팀 샐리 골드 멤버에게 경고를 보내도록 구성되어 있음을 보여 줍니다.
다음 스크린샷은 Sally가 수신하는 경고를 보여 줍니다.
참고: 이러한 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출해야 하며, 로그인한 사용자 및 증거 검토를 위한 시간 및 날짜 스탬프가 필요합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.
정보 보안 위험 관리
정보 보안 위험 관리는 모든 조직이 적어도 매년 수행해야 하는 중요한 활동입니다. 조직은 위협을 효과적으로 완화하기 위해 위험을 이해해야 합니다. 효과적인 위험 관리가 없으면 조직은 다른 위협이 발생할 가능성이 높은 경우 중요한 것으로 인식되는 영역에서 보안 리소스를 구현할 수 있습니다. 효과적인 위험 관리는 조직이 비즈니스에 가장 위협이 되는 위험에 집중하는 데 도움이 됩니다. 이는 보안 환경이 끊임없이 변화하고 있으므로 위협과 위험이 초과 근무를 변경할 수 있으므로 매년 수행되어야 합니다. 예를 들어 최근 COVID-19 잠금 중에 원격 작업으로 이동하면서 피싱 공격이 크게 증가했습니다.
컨트롤 번호 21
비준된 공식 정보 보안 위험 관리 정책/프로세스가 문서화되고 설정되었다는 증거를 제공합니다.
의도: 위험 관리
조직에서 위험을 효과적으로 관리할 수 있도록 강력한 정보 보안 위험 관리 프로세스가 중요합니다. 이렇게 하면 조직에서 환경에 대한 위협에 대한 효과적인 완화를 계획하는 데 도움이 됩니다. 이 컨트롤의 의도는 organization 포괄적으로 문서화된 공식적으로 비준된 정보 보안 위험 관리 정책 또는 프로세스가 있는지 확인하는 것입니다. 정책은 organization 정보 보안 위험을 식별, 평가 및 관리하는 방법을 간략하게 설명해야 합니다. 여기에는 역할 및 책임, 위험 평가 방법론, 위험 수용 기준 및 위험 완화 절차가 포함되어야 합니다.
참고: 위험 평가는 일반적인 비즈니스 위험뿐만 아니라 정보 보안 위험에 집중해야 합니다.
지침: 위험 관리
공식적으로 문서화된 위험 평가 관리 프로세스를 제공해야 합니다.
예시 증거: 위험 관리
다음 증거는 Contoso의 위험 평가 프로세스의 일부 스크린샷입니다.
참고: ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
참고: ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
컨트롤 번호 22
다음을 보여주는 증거를 제공하세요.
- 공식적인 회사 차원의 정보 보안 위험 평가는 적어도 매년 수행됩니다.
또는 대상 위험 분석의 경우:
대상 위험 분석은 문서화되고 수행됩니다.
기존의 제어 또는 업계 모범 사례가 없는 모든 instance 대해 최소 12개월마다.
디자인/기술 제한으로 인해 환경에 취약성이 발생할 위험이 발생하며 사용자와 데이터가 위험에 노출됩니다.
손상 의심 또는 확인 시.
의도: 연간 평가
보안 위협은 환경 변경, 제공된 서비스 변경, 외부 영향, 보안 위협 환경의 진화 등에 따라 지속적으로 변화하고 있습니다. 조직은 적어도 매년 위험 평가 프로세스를 거쳐야 합니다. 위협이 변경될 수 있으므로 중요한 변경 시에도 이 프로세스를 수행하는 것이 좋습니다.
이 제어의 목적은 organization 시스템 변경 중 또는 인시던트, 취약성 검색, 인프라 변경 시 적어도 일년에 한 번 이상 공식적인 회사 차원의 정보 보안 위험 평가 및/또는 대상 위험 분석을 수행하는지 확인하는 것입니다. 이 평가는 잠재적인 취약성과 위협을 식별하고 평가하는 것을 목표로 모든 조직 자산, 프로세스 및 데이터를 포괄해야 합니다.
대상 위험 분석의 경우 이 컨트롤은 특정 시나리오에서 위험 분석을 수행할 필요성을 강조합니다. 이는 자산, 위협, 시스템 또는 컨트롤과 같은 더 좁은 scope 초점을 맞춥니다. 이는 조직에서 보안 모범 사례 또는 시스템 설계 제한 사항의 편차로 인해 발생하는 위험을 지속적으로 평가하고 식별하도록 하기 위한 것입니다. 적어도 매년 제어가 부족한 경우, 기술 제약 조건으로 인해 취약성이 발생할 때, 의심되거나 확인된 보안 인시던트에 대한 대응으로 대상 위험 분석을 수행하면 organization 약점과 노출을 정확히 파악할 수 있습니다. 이를 통해 수정 작업의 우선 순위를 지정하고 보상 제어를 구현하여 악용 가능성과 영향을 최소화할 수 있는 정보에 입각한 위험 기반 결정을 내릴 수 있습니다. 목표는 알려진 격차가 무기한 무시되지 않고 위험 인식 방식으로 해결되고 있다는 지속적인 실사, 지침 및 증거를 제공하는 것입니다. 이러한 대상 위험 평가를 수행하면 시간이 지남에 따라 보안 태세를 사전에 개선하려는 조직의 노력을 보여 줍니다.
지침: 연간 평가
증거는 버전 추적 또는 날짜가 지정된 증거를 통해서일 수 있습니다. 정보 보안 위험 평가의 출력과 정보 보안 위험 평가 프로세스 자체에 대한 날짜가 아님을 보여주는 증거를 제공해야 합니다.
예시 증거: 연간 평가
다음 스크린샷은 6개월마다 예약되는 위험 평가 모임을 보여줍니다.
다음 두 스크린샷은 두 위험 평가에서 회의 시간(분)의 예를 보여 줍니다. 위험 평가에 대한 보고서/회의 시간(분) 또는 보고서가 제공될 것으로 예상합니다.
참고: 이 스크린샷은 정책/프로세스 문서를 보여줍니다. ISV가 실제 지원 정책/절차 설명서를 공유하고 스크린샷만 제공하는 것이 아닙니다.
참고: 이 스크린샷은 정책/프로세스 문서를 보여 하며, ISV가 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
컨트롤 번호 23
정보 보안 위험 평가에 다음이 포함되는지 확인합니다.
영향을 받는 시스템 구성 요소 또는 리소스입니다.
위협 및 취약성 또는 동등성.
영향 및 가능성 매트릭스 또는 이에 해당합니다.
위험 레지스터/위험 처리 계획의 생성입니다.
의도: 위험 평가
위험 평가에는 가장 중요한 IT 자산과 해당 가치를 식별하는 데 도움이 되는 시스템 구성 요소 및 리소스가 포함됩니다. organization 비즈니스에 대한 잠재적 위협을 식별하고 분석하여 가장 높은 잠재적 영향과 가장 높은 확률을 가진 위험에 먼저 집중할 수 있습니다. IT 인프라 및 관련 비용에 대한 잠재적 영향을 이해하면 경영진이 예산, 정책, 절차 등에 대해 정보에 입각한 결정을 내리는 데 도움이 될 수 있습니다. 보안 위험 평가에 포함될 수 있는 시스템 구성 요소 또는 리소스 목록은 다음과 같습니다.
서버
데이터베이스
응용 프로그램
네트워크
데이터 스토리지 디바이스
사용자
조직에서는 정보 보안 위험을 효과적으로 관리하기 위해 환경 및 데이터에 대한 위협과 발생할 수 있는 취약성에 대해 위험 평가를 수행해야 합니다. 이를 통해 조직은 상당한 위험을 초래할 수 있는 수많은 위협과 취약성을 식별할 수 있습니다. 위험 평가는 위험 값을 식별하는 데 사용할 수 있는 영향 및 가능성 등급을 문서화해야 합니다. 이는 위험 처리의 우선 순위를 지정하고 전반적인 위험 값을 줄이는 데 사용할 수 있습니다. 위험 평가는 적용되고 있는 4개의 위험 처리의 한의 기록을 제공하기 위하여 제대로 추적될 필요가 있습니다. 이러한 위험 치료는 다음과 같습니다.
방지/종료: 비즈니스는 위험을 처리하는 비용이 서비스에서 생성된 수익보다 더 많은 것을 결정할 수 있습니다. 따라서 비즈니스는 서비스 수행을 중지하도록 선택할 수 있습니다.
이전/공유: 비즈니스는 처리를 타사로 이동하여 위험을 타사로 이전하도록 선택할 수 있습니다.
수락/허용/유지: 비즈니스에서 위험을 허용할 수 있다고 결정할 수 있습니다. 이것은 기업의 위험 식욕에 매우 의존하고 organization 따라 달라질 수 있습니다.
처리/완화/수정: 비즈니스는 위험을 허용 가능한 수준으로 줄이기 위해 완화 제어를 구현하기로 결정합니다.
지침: 위험 평가
증거는 이미 제공 된 정보 보안 위험 평가 프로세스뿐만 아니라 위험 평가 프로세스가 제대로 수행되고 있음을 입증하기 위해 위험 평가의 출력 (위험 등록 / 위험 치료 계획을 통해)을 통해 제공되어야합니다. 위험 레지스터에는 위험, 취약성, 영향 및 가능성 등급이 포함되어야 합니다.
예시 증거: 위험 평가
다음 스크린샷은 위협 및 취약성이 포함되어 있음을 보여 주는 위험 레지스터를 보여 줍니다. 또한 영향과 가능성이 포함됨을 보여 줍니다.
참고: 전체 위험 평가 설명서는 스크린샷 대신 제공해야 합니다. 다음 스크린샷은 위험 처리 계획을 보여 줍니다.
컨트롤 번호 24
다음과 같은 증거를 제공하세요.
사용자(ISV)에는 공급업체 및 비즈니스 파트너와 관련된 위험을 평가하고 관리하는 위험 관리 프로세스가 있습니다.
사용자(ISV)는 내부 제어 시스템에 영향을 미칠 수 있는 변경 내용과 위험을 식별하고 평가할 수 있습니다.
의도: 공급업체 및 파트너
공급업체 위험 관리는 비즈니스 관계가 설정되기 전과 관계 기간 내내 비즈니스 파트너, 공급업체 또는 타사 공급업체의 위험 상태를 평가하는 방법입니다. 공급업체 위험을 관리함으로써 조직은 비즈니스 연속성 중단을 방지하고, 재정적 영향을 방지하고, 평판을 보호하고, 규정을 준수하며, 공급업체와의 협업과 관련된 위험을 식별하고 최소화할 수 있습니다. 공급업체 위험을 효과적으로 관리하려면 실사 평가, 보안과 관련된 계약 의무 및 공급업체 규정 준수에 대한 지속적인 모니터링을 포함하는 프로세스를 마련하는 것이 중요합니다.
지침: 공급업체 및 파트너
새로운 공급업체 및 계약자 온보딩을 위한 조달 및 심사 설명서, 검사 목록 및 설문지, 수행된 평가, 규정 준수 검사 등과 같은 공급업체 위험 평가 프로세스를 입증하기 위해 증거를 제공할 수 있습니다.
예시 증거: 공급업체 및 파트너
다음 스크린샷은 공급업체 온보딩 및 심사 프로세스가 Confluence에서 JIRA 작업으로 유지 관리됨을 보여 줍니다. 각 새 공급업체에 대해 규정 준수 상태를 검토하기 위해 초기 위험 평가가 발생합니다. 조달 프로세스 중에 위험 평가 설문지가 채워지고 전반적인 위험은 공급업체에 제공되는 시스템 및 데이터에 대한 액세스 수준에 따라 결정됩니다.
다음 스크린샷은 평가의 결과와 초기 검토를 기반으로 식별된 전반적인 위험을 보여 줍니다.
의도: 내부 컨트롤
이 하위 지점의 초점은 organization 내부 제어 시스템에 영향을 미칠 수 있는 변경 내용과 위험을 인식하고 평가하여 시간이 지남에 따라 내부 제어가 효과적으로 유지되도록 하는 것입니다. 비즈니스 운영이 변경되면 내부 제어가 더 이상 효과적이지 않을 수 있습니다. 위험은 시간이 지남에 따라 진화하고, 이전에 고려되지 않은 새로운 위험이 나타날 수 있습니다. 이러한 위험을 식별하고 평가하면 내부 제어가 해당 위험을 해결하도록 설계되었는지 확인할 수 있습니다. 이는 사기 및 오류를 방지하고, 비즈니스 연속성을 유지하며, 규정 준수를 보장하는 데 도움이 됩니다.
지침: 내부 컨트롤
잠재적인 공급업체 변경 내용이 고려되고 평가되도록 공급업체 위험 평가 프로세스가 정의된 기간에 새로 고쳐짐을 입증할 수 있는 회의록 및 보고서 검토와 같은 증거를 제공할 수 있습니다.
예시 증거: 내부 제어
다음 스크린샷은 승인된 공급업체 및 계약자 목록을 3개월 동안 검토하여 규정 준수 표준 및 규정 준수 수준이 온보딩 중에 초기 평가와 일치하도록 하는 것을 보여 줍니다.
첫 번째 스크린샷은 평가 및 위험 설문지를 수행하기 위한 설정된 지침을 보여줍니다.
다음 스크린샷은 실제 공급업체 승인 목록 및 규정 준수 수준, 수행된 평가, 평가자, 승인자 등을 보여 줍니다. 이는 제어 요구 사항을 이해하고 예상되는 증거의 형식을 표시하기 위한 기준 시나리오를 제공하도록 설계된 기본적인 공급업체 위험 평가의 예일 뿐입니다. ISV는 organization 적용되는 고유한 공급업체 위험 평가를 제공해야 합니다.
보안 인시던트 대응
보안 인시던트 대응은 보안 인시던트가 포함된 organization 소요되는 시간을 줄이고 organization 데이터 반출에 대한 노출 수준을 제한할 수 있으므로 모든 조직에서 중요합니다. 포괄적이고 상세한 보안 인시던트 대응 계획을 개발함으로써 이러한 노출을 식별 시간에서 봉쇄 시간으로 줄일 수 있습니다.
IBM의 "데이터 위반 보고서 2020 비용"이라는 제목의 보고서는 평균적으로 위반을 포함하는 데 걸린 시간이 73일임을 강조합니다. 또한 동일한 보고서는 위반을 겪은 organization 가장 큰 비용 절감을 식별하며, 인시던트 대응 준비로 평균을 제공합니다.
$2,000,000의 비용 절감. 조직은 ISO 27001, NIST, SOC 2, PCI DSS 등과 같은 업계 표준 프레임워크를 사용하여 보안 규정 준수에 대한 모범 사례를 따라야 합니다.
컨트롤 번호 25
organization 인시던트에 대응하는 방법, 유지 관리 방법 및 다음을 포함하는 방법을 보여 주는 비준된 IRP(보안 인시던트 대응 계획/절차)를 제공하세요.
연락처 정보를 포함하여 인시던트 대응 팀의 세부 정보
인시던트 중 내부 통신 계획 및 주요 이해 관계자, 결제 브랜드 및 인수자, 규제 기관(예: GDPR의 경우 72시간), 감독 기관, 이사, 고객 등 관련 당사자와 외부 통신
인시던트 분류, 포함, 완화, 복구 및 인시던트 유형에 따라 정상적인 비즈니스 작업으로 복귀와 같은 활동에 대한 단계입니다.
의도: IRP(Incedent Response Plan)
이 제어의 목적은 명확하게 문서화된 역할, 책임 및 연락처 정보를 포함하는 지정된 인시던트 대응 팀을 포함하는 공식적으로 문서화된 IRP(인시던트 대응 계획)가 있는지 확인하는 것입니다. IRP는 인시던트의 특성을 분류하고, 즉각적인 영향을 포함하고, 위험을 완화하고, 인시던트에서 복구하고, 정상적인 비즈니스 운영을 복원하는 등 탐지에서 해결까지 보안 인시던트를 관리하기 위한 구조화된 접근 방식을 제공해야 합니다. 수행된 작업이 organization 위험 관리 전략 및 규정 준수 의무에 부합하도록 각 단계를 명확한 프로토콜로 잘 정의해야 합니다.
IRP 내에서 인시던트 대응 팀의 자세한 사양은 각 팀 구성원이 인시던트 관리에 대한 자신의 역할을 이해하여 조정되고 효율적인 대응을 가능하게 합니다. IRP를 배치하면 organization 보안 인시던트 대응을 보다 효율적으로 관리할 수 있으므로 궁극적으로 organization 데이터 손실 노출을 제한하고 손상 비용을 줄일 수 있습니다.
조직은 운영 중인 국가/국가(예: 일반 데이터 보호 규정 GDPR)를 기반으로 하거나 제공되는 기능(예: 결제 데이터가 처리되는 경우 PCI DSS)에 따라 위반 알림 의무가 있을 수 있습니다. 시기 적절한 알림이 실패하면 심각한 파급효과를 가져올 수 있습니다. 따라서 알림 의무가 충족되도록 하려면 인시던트 대응 계획에는 모든 이해 관계자와의 통신, 미디어 통신 프로세스 및 미디어와 대화할 수 있는 사람과 말할 수 없는 사람을 포함한 통신 프로세스가 포함되어야 합니다.
지침: 내부 컨트롤
인시던트 대응 계획/프로시저의 전체 버전을 제공합니다. 인시던트 대응 계획에는 식별에서 해결까지 인시던트 처리 프로세스와 문서화된 통신 프로세스를 다루는 섹션이 포함되어야 합니다.
예시 증거: 내부 제어
다음 스크린샷은 Contoso의 인시던트 대응 계획의 시작을 보여줍니다.
참고: 증거 제출의 일부로 전체 인시던트 대응 계획을 제공해야 합니다.
예시 증거: 내부 제어
다음 스크린샷은 통신 프로세스를 보여 주는 인시던트 응답 계획의 추출을 보여줍니다.
컨트롤 번호 26
다음을 보여 주는 증거를 제공하세요.
인시던트 대응 팀의 모든 구성원은 인시던트에 대응할 수 있는 연간 교육을 받았습니다.
의도: 학습
organization 손상이 포함되는 데 걸리는 시간이 길어질수록 데이터 반출 위험이 커지고 잠재적으로 더 많은 양의 유출된 데이터가 생성되고 손상의 전체 비용이 커질 수 있습니다. organization 인시던트 대응 팀은 보안 인시던트에 적시에 대응할 준비가 되어 있는 것이 중요합니다. 팀은 정기적인 교육을 수행하고 탁상 연습을 수행함으로써 보안 인시던트 처리에 신속하고 효율적으로 대비할 준비가 되어 있습니다. 이 교육은 잠재적 위협 식별, 초기 대응 작업, 에스컬레이션 절차 및 장기 완화 전략과 같은 다양한 측면을 다루어야 합니다.
인시던트 대응 팀 AND에 대한 내부 인시던트 대응 교육을 모두 수행하여 정보 보안 위험에 연결되어야 하는 정기적인 탁상 연습을 수행하는 것이 좋습니다.
발생할 가능성이 가장 높은 보안 인시던트 식별을 위한 평가입니다. 탁상 연습은 실제 시나리오를 시뮬레이션하여 압력을 받고 대응하는 팀의 능력을 테스트하고 연마해야 합니다. 이렇게 하면 organization 직원이 보안 위반 또는 사이버 공격을 올바르게 처리하는 방법을 알 수 있도록 할 수 있습니다. 그리고 팀은 가장 가능성이 높은 보안 인시던트들을 신속하게 억제하고 조사하기 위해 어떤 조치를 취해야 하는지 알게 될 것입니다.
지침: 교육
학습 콘텐츠를 공유하여 학습이 수행되었음을 보여주는 증거와 참석한 사람(모든 인시던트 대응 팀을 포함해야함)을 보여주는 레코드가 제공되어야 합니다. 또는 뿐만 아니라 탁상 연습이 수행되었음을 보여 주는 레코드도 있습니다. 이 모든 것은 증거가 제출된 시점부터 12개월 이내에 완료되어야 합니다.
예시 증거: 학습
Contoso는 외부 보안 회사를 사용하여 인시던트 대응 탁상 연습을 수행했습니다. 다음은 컨설팅의 일부로 생성된 보고서의 샘플입니다.
참고: 전체 보고서를 공유해야 합니다. 이 연습은 타사 회사에서 수행해야 하는 Microsoft 365 요구 사항이 없으면 내부적으로 수행할 수도 있습니다.
참고: 전체 보고서를 공유해야 합니다. 이 연습은 타사 회사에서 수행해야 하는 Microsoft 365 요구 사항이 없으면 내부적으로도 수행할 수 있습니다.
컨트롤 번호 27
다음과 같은 증거를 제공하세요.
인시던트 대응 전략 및 지원 설명서는 다음 중 하나를 기반으로 검토 및 업데이트됩니다.
탁상 연습에서 배운 교훈
인시던트에 대응하여 배운 교훈
조직 변경 내용
의도: 계획 검토
시간이 지남에 따라 인시던트 대응 계획은 조직의 변화에 따라 또는 계획을 제정할 때 배운 교훈을 기반으로 발전해야 합니다. 운영 환경을 변경하려면 위협이 변경되거나 규정 요구 사항이 변경 될 수 있으므로 인시던트 대응 계획을 변경해야 할 수 있습니다. 또한 탁상 연습 및 실제 보안 인시던트 대응이 수행됨에 따라 개선될 수 있는 계획의 영역을 식별할 수 있습니다. 이 작업은 계획에 기본 제공되어야 하며 이 컨트롤의 의도는 이 프로세스가 포함되도록 하는 것입니다. 이 제어의 목적은 세 가지 고유 트리거를 기반으로 organization 인시던트 대응 전략 및 지원 설명서의 검토 및 업데이트를 의무화하는 것입니다.
인시던트 대응 전략의 효과를 테스트하기 위한 시뮬레이션된 연습이 수행된 후 식별된 간격 또는 개선 영역을 즉시 기존 인시던트 대응 계획에 통합해야 합니다.
실제 인시던트는 현재 대응 전략의 강점과 약점에 대한 귀중한 인사이트를 제공합니다. 인시던트가 발생하는 경우 인시던트 후 검토를 수행하여 이러한 단원을 캡처한 다음, 대응 전략 및 절차를 업데이트하는 데 사용해야 합니다.
합병, 인수 또는 핵심 인력의 변경과 같은 organization 내의 중요한 변경은 인시던트 대응 전략의 검토를 트리거해야 합니다. 이러한 조직 변경으로 인해 새로운 위험이 발생하거나 기존 위험을 전환할 수 있으며, 인시던트 대응 계획을 적절하게 업데이트하여 효과를 유지해야 합니다.
지침: 계획 검토
이는 종종 보안 인시던트 또는 탁상 연습의 결과를 검토하여 입증됩니다. 단원을 파악하여 인시던트 대응 계획을 업데이트했습니다. 계획은 변경 로그를 유지해야 하며, 학습된 단원 또는 조직 변경 내용에 따라 구현된 변경 내용도 참조해야 합니다.
예시 증거: 계획 검토
다음 스크린샷은 학습된 단원 및/또는 organization 변경 내용을 기반으로 업데이트에 대한 섹션을 포함하는 제공된 인시던트 대응 계획의 스크린샷입니다.
참고: 이러한 예제는 전체 화면 스크린샷이 아니며, 모든 URL이 포함된 전체 화면 스크린샷을 제출하고, 로그인한 사용자와 증거 검토를 위한 시간 및 날짜 스탬프를 제출해야 합니다. Linux 사용자인 경우 명령 프롬프트를 통해 이 작업을 수행할 수 있습니다.
비즈니스 연속성 계획 및 재해 복구 계획
비즈니스 연속성 계획 및 재해 복구 계획은 organization 위험 관리 전략의 두 가지 중요한 구성 요소입니다. 비즈니스 연속성 계획은 재해 발생 시와 이후에 필수 비즈니스 기능이 계속 작동할 수 있도록 하는 계획을 만드는 프로세스이며 재해 복구 계획은 재해로부터 복구하고 정상적인 비즈니스 운영을 가능한 한 빨리 복원하는 계획을 만드는 프로세스입니다. 두 계획 모두 서로를 보완합니다. 재해 또는 예기치 않은 중단으로 인해 발생한 운영 문제를 모두 견뎌야 합니다. 이러한 계획은 재해 발생 시 organization 계속 작동하고, 평판을 보호하고, 법적 요구 사항을 준수하고, 고객 신뢰를 유지하고, 위험을 효과적으로 관리하고, 직원을 안전하게 유지할 수 있도록 하기 때문에 중요합니다.
컨트롤 번호 28
다음을 보여주는 증거를 제공하세요.
설명서는 비즈니스 연속성 계획을 간략하게 설명하고 다음을 포함하는 유지 관리됩니다.
역할 및 책임을 포함하여 관련 담당자의 세부 정보
관련 대체 요구 사항 및 목표와 관련된 비즈니스 기능
시스템 및 데이터 백업 절차, 구성 및 예약/보존
복구 우선 순위 및 시간 범위 대상
예기치 않은 예약되지 않은 중단이 발생할 경우 중요한 정보 시스템, 비즈니스 기능 및 서비스를 작업에 반환하기 위해 따라야 할 작업, 단계 및 절차를 자세히 설명하는 비상 계획
최종 전체 시스템 복원을 포함하고 원래 상태로 돌아가는 설정된 프로세스
의도: 비즈니스 연속성 계획
이 제어의 목적은 할당된 역할 및 책임이 있는 명확하게 정의된 직원 목록이 비즈니스 연속성 계획에 포함되도록 하는 것입니다. 이러한 역할은 인시던트 중에 계획을 효과적으로 활성화하고 실행하는 데 중요합니다.
지침: 비즈니스 연속성 계획
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 비즈니스 연속성 계획
다음 스크린샷은 비즈니스 연속성 계획의 추출과 해당 계획이 존재하고 유지 관리됨을 보여 줍니다.
참고: 이 스크린샷은 정책/프로세스 문서의 스냅샷을 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
다음 스크린샷은 관련 팀, 연락처 세부 정보 및 수행할 단계를 포함하여 '핵심 직원' 섹션이 간략하게 설명된 정책의 추출을 보여줍니다.
의도: 우선 순위 지정
이 제어의 목적은 중요도에 따라 비즈니스 기능을 문서화하고 우선 순위를 지정하는 것입니다. 계획되지 않은 중단 중에 각 함수를 유지하거나 신속하게 복원하는 데 필요한 해당 비상 요구 사항의 개요가 함께 제공됩니다.
지침: 우선 순위 지정
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 우선 순위 지정
다음 스크린샷은 비즈니스 연속성 계획의 추출과 비즈니스 기능 및 중요도 수준에 대한 개요와 비상 계획이 존재하는 경우를 보여 줍니다.
참고: 이 스크린샷은 정책/프로세스 문서를 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
의도: 백업
이 하위 지점의 목적은 필수 시스템 및 데이터를 백업하기 위한 문서화된 절차를 유지하는 것입니다. 또한 이 설명서에서는 데이터가 현재 및 검색 가능한지 확인하기 위해 구성 설정과 백업 예약 및 보존 정책을 지정해야 합니다.
지침: 백업
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 백업
다음 스크린샷은 Contoso의 재해 복구 계획의 추출과 모든 시스템에 대해 문서화된 백업 구성이 있음을 보여 줍니다. 다음 스크린샷에서 백업 일정도 요약되어 있습니다. 이 예제에서는 비즈니스 연속성 및 재해 복구 계획이 함께 작동하므로 백업 구성이 재해 복구 계획의 일부로 설명되어 있습니다.
참고: 이 스크린샷은 정책/절차 문서의 스냅샷 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
의도: 타임라인
이 컨트롤은 복구 작업에 대한 우선 순위가 지정된 타임라인을 설정하는 것을 목표로 합니다. 이러한 RTO(복구 시간 목표)는 비즈니스 영향 분석과 일치해야 하며 직원이 먼저 복원해야 하는 시스템과 기능을 이해할 수 있도록 명확하게 정의해야 합니다.
지침: 타임라인
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 타임라인
다음 스크린샷은 설정된 RTO(복구 시간 목표)뿐만 아니라 비즈니스 기능의 연속성 및 중요도 분류를 보여 줍니다.
참고: 이 스크린샷은 정책/프로세스 문서를 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
의도: 복구
이 컨트롤은 중요한 정보 시스템, 비즈니스 기능 및 서비스를 운영 상태 반환하기 위해 수행해야 하는 단계별 절차를 제공합니다. 이는 신속하고 효과적인 조치가 필수적인 고압 상황에서 의사 결정을 안내할 만큼 충분히 자세해야 합니다.
지침: 복구
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 복구
다음 스크린샷은 재해 복구 계획의 추출과 모든 시스템 및 비즈니스 기능에 대해 문서화된 복구 계획이 있음을 보여 줍니다. 이 예제에서는 비즈니스 연속성 및 재해 복구 계획이 함께 작동하여 전체 복구/복원을 달성하기 위해 시스템 복구 절차가 재해 복구 계획의 일부입니다.
참고: 이 스크린샷은 정책/프로세스 문서를 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
의도: 유효성 검사
이 제어점은 비즈니스 연속성 계획에 위기가 관리되면 시스템을 원래 상태로 복원하는 organization 안내하는 구조화된 프로세스가 포함되도록 하는 것을 목표로 합니다. 여기에는 시스템이 완전히 작동하고 무결성을 유지하도록 하는 유효성 검사 단계가 포함됩니다.
지침: 유효성 검사
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 유효성 검사
다음 스크린샷은 비즈니스 연속성 계획 정책 및 수행할 단계/작업에 설명된 복구 프로세스를 보여 줍니다.
참고: 이 스크린샷은 정책/절차 문서의 스냅샷 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
컨트롤 번호 29
다음을 보여주는 증거를 제공하세요.
설명서가 존재하며 유지 관리되며 재해 복구 계획을 간략하게 설명하고 최소한 다음을 포함합니다.
역할 및 책임을 포함하여 관련 담당자의 세부 정보
관련 대체 요구 사항 및 목표와 관련된 비즈니스 기능
시스템 및 데이터 백업 절차, 구성 및 예약/보존
복구 우선 순위 및 시간 범위 대상
예기치 않은 예약되지 않은 중단이 발생할 경우 중요한 정보 시스템, 비즈니스 기능 및 서비스를 작업에 반환하기 위해 따라야 할 작업, 단계 및 절차를 자세히 설명하는 비상 계획
최종 전체 시스템 복원을 포함하고 원래 상태로 돌아가는 설정된 프로세스
의도: DRP
이 제어의 목적은 재해 복구 팀의 각 구성원에 대해 잘 문서화된 역할과 책임을 갖기 위한 것입니다. 또한 재해 시나리오 중에 적절한 담당자가 문제를 신속하게 상승시키고 해결할 수 있도록 에스컬레이션 프로세스를 설명해야 합니다.
지침: DRP
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: DRP
다음 스크린샷은 재해 복구 계획의 추출과 재해 복구 계획이 존재하고 유지 관리됨을 보여 줍니다.
참고: 이 스크린샷은 정책/프로세스 문서를 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
다음 스크린샷은 관련 팀, 연락처 세부 정보 및 에스컬레이션 단계를 포함하여 '대체 계획'이 요약된 정책의 추출을 보여줍니다.
의도: 인벤토리
이 제어의 목적은 비즈니스 운영을 지원하는 데 중요한 모든 정보 시스템의 최신 인벤토리 목록을 유지하는 것입니다. 이 목록은 재해 복구 작업 중에 우선 순위를 지정해야 하는 시스템을 이해하기 위한 기본 사항입니다.
지침: 인벤토리
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 인벤토리
다음 스크린샷은 DRP의 추출과 중요한 시스템의 인벤토리 및 중요도 수준 및 시스템 함수가 존재하는 것을 보여 줍니다.
참고: 이 스크린샷은 정책/프로세스 문서를 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
다음 스크린샷은 분류 및 서비스 중요도 정의를 보여줍니다.
참고: 이 스크린샷은 정책/프로세스 문서를 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
의도: 백업
이 컨트롤을 사용하려면 시스템 및 데이터 백업에 대해 잘 정의된 프로시저가 있어야 합니다. 이러한 절차는 실패 또는 재해 발생 시 모든 중요한 데이터를 복원할 수 있도록 백업의 빈도, 구성 및 위치를 간략하게 설명해야 합니다.
지침: 백업
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 백업
다음 스크린샷은 재해 복구 계획의 추출과 모든 시스템에 대해 문서화된 백업 구성이 있음을 보여 줍니다. 아래에서 백업 일정도 요약되어 있는지 확인합니다.
참고: 이 스크린샷은 정책/프로세스 문서의 스냅샷 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
의도: 복구
이 컨트롤은 중요한 시스템 및 데이터를 복원하는 단계별 절차를 간략하게 설명하는 포괄적인 복구 계획을 요구합니다. 이는 재해 복구 팀의 로드맵 역할을 하며 모든 복구 작업이 미리 계획되고 비즈니스 운영 복원에 효과적임을 보장합니다.
지침: 복구
컨트롤 설명에서 처리된 개요를 다루는 섹션을 포함해야 하는 재해 복구 계획/절차의 전체 버전을 제공하세요. 디지털 버전에 있는 경우 실제 PDF/WORD 문서를 제공하거나 온라인 플랫폼을 통해 프로세스가 유지 관리되는 경우 프로세스의 내보내기 또는 스크린샷을 제공합니다.
예시 증거: 복구
다음 스크린샷은 재해 복구 계획의 추출과 장비 교체 및 시스템 복구 단계 및 지침이 존재하고 문서화되어 있으며 복구 기간, 클라우드 인프라 복원을 위해 수행할 작업 등을 포함하는 복구 절차를 보여 줍니다.
참고: 이 스크린샷은 정책/프로세스 문서의 스냅샷 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
컨트롤 번호 30
다음을 보여주는 증거를 제공하세요.
비즈니스 연속성 계획 및 재해 복구 계획은 적어도 12개월마다 검토되어 불리한 상황에서 유효하고 효과적인 상태를 유지하고 다음을 기반으로 업데이트됩니다.
계획의 연간 검토.
모든 관련 담당자는 대체 계획에 할당된 역할 및 책임에 대한 교육을 받습니다.
계획/s는 비즈니스 연속성 또는 재해 복구 연습을 통해 테스트됩니다.
연습 또는 조직 변경에서 배운 단원을 포함하여 테스트 결과가 문서화됩니다.
의도: 연간 검토
이 제어의 목적은 비즈니스 연속성 및 재해 복구 계획을 매년 검토하는 것입니다. 검토는 계획이 여전히 효과적이고 정확하며 현재의 비즈니스 목표 및 기술 아키텍처에 부합하는지 확인해야 합니다.
의도: 연간 교육
이 제어는 비즈니스 연속성 및 재해 복구 계획에서 지정된 역할을 가진 모든 개인이 매년 적절한 교육을 받도록 규정합니다. 목표는 재해 또는 비즈니스 중단 시 책임을 인식하고 효과적으로 실행할 수 있도록 하는 것입니다.
의도: 연습
여기서 의도는 실제 연습을 통해 비즈니스 연속성 및 재해 복구 계획의 효과의 유효성을 검사하는 것입니다. 이러한 연습은 organization 비즈니스 운영을 얼마나 잘 유지하거나 복원할 수 있는지 테스트하기 위해 다양한 불리한 조건을 시뮬레이션하도록 설계되어야 합니다.
의도: 분석
최종 제어점은 무엇이 잘 작동했는지, 무엇이 작동하지 않았는지에 대한 분석을 포함하여 모든 테스트 결과에 대한 철저한 설명서를 목표로 합니다. 배운 교훈은 계획에 다시 통합되어야 하며, organization 복원력을 개선하기 위해 모든 단점을 즉시 해결해야 합니다.
지침: 리뷰
검토를 위해 보고서, 모임 메모 및 연간 비즈니스 연속성 및 재해 복구 계획 연습의 출력과 같은 증거를 제공해야 합니다.
예시 증거: 리뷰
다음 스크린샷은 팀이 비즈니스 연속성 및 재해 복구 계획을 제정하고 비즈니스 기능 및 시스템 운영의 성공적인 복원까지 상황을 연습할 수 있도록 시나리오가 설정된 비즈니스 연속성 및 재해 복구 계획 드릴(연습)의 보고서 출력을 보여줍니다.
참고: 이러한 스크린샷은 정책/프로세스 문서의 스냅샷 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.
참고: 이러한 스크린샷은 정책/프로세스 문서의 스냅샷 보여 줍니다. ISV는 실제 지원 정책/절차 설명서를 공유하고 단순히 스크린샷을 제공하는 것이 아닙니다.