와 정책 예외 통합 취약성 대응

버전 10.1부터 애플리케이션의 버전 10.3 내에서 애플리케이션에 고유한 정책 및 준수 관리 정책 예외 관리 기능을 사용하여 GRC 정책 예외를 요청할 수 있습니다취약성 대응.

정책 예외 통합 사용의 이점

과 정책 정책 및 준수 관리 예외 통합을 사용하여 예외를 요청하면 다음과 같은 이점이 있습니다.

• 평가를 수행하여 요청에 대한 추가 정보를 수집합니다.
• 특정 정책 또는 통제 목표에 따라 예외를 요청합니다. 이 작업은 예외가 승인되면 준수에 미치는 영향을 보여줍니다.
• 정책 예외와 연관된 위험 등급, 정책 또는 통제 목표에 따라 자동으로 트리거되는 승인을 구성합니다.

정책 예외 통합의 작동 방식

여기에 설명된 시나리오에서는 시스템에서 취약성이 식별되고 정정 소유자가 소프트웨어 패치가 필요하다고 결정했다고 가정합니다. 패치가 완전히 테스트되지 않았으며 소유자가 테스트가 완료될 때까지 패치 배포를 연기하기 위해 정책 예외를 요청하고 있습니다.

다음 다이어그램에서는 각 애플리케이션에서 준수 관리자와 수정 소유자가 수행하는 단계를 보여 줍니다.

그림 1. 정책 예외 통합

주:

GRC 비즈니스 사용자(sn_grc.business_user) 또는 비즈니스 사용자 – lite(sn_grc.business_user_lite)는 업스트림 애플리케이션에서 정책 예외를 제기하는 데 필요한 최소 역할입니다.

1. 애플리케이션이 취약성 대응 설치되면 취약성 그룹과 취약한 항목에 대한 두 개의 정책 예외 통합 기록이 자동으로 생성되어 통합 레지스트리에 추가됩니다.

   그림 2. 정책 예외 통합 레지스터

   

   취약한 항목 기록을 구성하기 위해 준수 관리자는 다음 단계를 수행합니다.

   1. 두 애플리케이션을 통합하는 데 사용되는 테이블의 매핑을 식별합니다.
   2. 예외를 요청하는 이유를 정의합니다.
   3. (선택 사항) 정책을 필터링하기 위한 정책 범주 정의
   4. (선택 사항) 정책 예외 요청에 대한 추가 정보를 수집하기 위해 요청자에게 보낼 질문서를 하나 이상 생성합니다 .
2. 또한 규정 준수 관리자는 선택적 검증 규칙 및 승인 규칙 을 정의하여 정책 예외에 대한 승인을 받는 프로세스를 자동화합니다.
3. 취약성 대응에서 정정 소유자 GRC: 정책 및 준수 관리를 사용하여 예외 요청 .
4. 애플리케이션에 대한 검증 규칙이 정의된 경우 지정된 승인자에게 승인이 필요하다는 알림이 전송됩니다. 요청자가 정책 예외 요청의 필드(예: 정책 또는 통제 목표)를 채우지 않은 경우 이러한 필드는 승인자에게 필수가 됩니다. 승인자가 요청을 검토, 완료 및 승인하면 분석 상태로 전환되고 추가 분석 및 승인을 위해 준수 관리자에게 할당됩니다.
5. 에서 정책 및 준수 관리준수 관리자는 승인된 요청을 수신하고 위험 평가 탭에서 정책 예외 요청에 위험 등급을 할당합니다.

   그림 3. 위험 평가 탭의 정책 예외 요청

   

   정책 예외 기록이 저장되면 소스 애플리케이션 및 소스 기록을 포함한 소스 탭의 정보와 취약한 항목 관련 목록의 정보가 자동으로 채워집니다. 이제 규정 준수 관리자는 정책 예외를 검토하고 승인하는 데 필요한 모든 데이터에 액세스할 수 있습니다.

6. 에서 정책 및 준수 관리평가가 구성된 경우 준수 관리자는 예외 평가를 수행합니다. 평가가 완료되면 준수 관리자는 위험 평가 탭으로 돌아가 필요한 경우 평가 결과에 따라 위험 등급 을 업데이트합니다. 또한 규정 준수 관리자는 평가 중에 수집된 정보로 다음 필드를 채웁니다.

   표 1. 위험 평가 탭

   필드	설명
   위험 설명	이 정책 예외와 관련된 위험에 대한 상세 정보를 제공합니다.
   위험 및 영향 분석	정책 예외에 대한 위험 및 영향 분석에 대한 상세 정보를 제공합니다.
   위험 완화 계획	이 정책 예외와 관련된 완화 계획에 대한 상세 정보를 제공합니다.

7. 정책 예외에 누락된 정보가 있는 경우 준수 관리자는 추가 정보 요청을 클릭하고 필요한 데이터 유형을 식별하는 설명을 추가할 수 있습니다. 요청자에게 알림이 전송되고 요청된 정보를 제공합니다.
8. 필요에 따라 준수 관리자는 요청 검토를 클릭하여 승인하기 전에 추가 사내 검토를 위해 정책 예외를 보낼 수 있습니다.
   주:

   검토를 요청하기 전에 영향을 받는 통제 관련 목록에 정책 예외의 영향을 받는 통제가 포함되어 있는지 확인하십시오. 관련 목록을 열고 추가를 클릭한 다음 컨트롤을 선택하기만 하면 됩니다.
9. 정책 예외의 위험이 특히 높고 규정 준수 관리자가 조직의 상급 사용자(예: CIO)의 승인을 받아야 한다고 생각하는 경우 규정 준수 관리자는 승인 요청을 클릭할 수 있습니다.
   그렇지 않으면 승인은 다음 시나리오에서 수행됩니다.

   승인 규칙 정의됨	승인에 미치는 영향
   에 대해 승인 규칙이 정의되지 않은 경우 취약성 대응	승인됨을 선택하면 정책 예외가 승인됩니다.
   승인 규칙이 정의되었지만 자동 트리거 확인란을 선택하지 않은 경우	승인 요청을 클릭하여 규칙에 정의된 사용자 또는 그룹에 정책 예외를 보낼 수 있습니다. 예를 들어, 승인 규칙은 정책 예외가 특정 정책을 기반으로 하는 경우 특정 사용자 또는 그룹에 정책 예외에 대한 승인을 제공해야 한다는 알림을 받도록 나타낼 수 있습니다. 또는 위험 등급이 중요인 정책 예외가 특정 승인자 집합에 자동으로 전송되도록 승인 규칙을 정의할 수 있습니다. 정책 예외를 승인하는 데 필요한 승인자 수는 규칙의 필수 승인 필드 설정에 따라 달라집니다. 승인을 클릭하여 정책 예외를 직접 승인할 수도 있습니다.
   승인 규칙이 정의되고 자동 트리거 확인란이 선택된 경우	승인 버튼을 클릭하면 승인 규칙이 실행되고 승인 규칙에 따라 정의된 사용자 또는 그룹에 정책 예외가 자동으로 전송됩니다. 자동 트리거를 사용하면 이 단계가 필수가 됩니다. 승인을 받으면 정책 예외가 적용됩니다.

10. 에서 취약성 대응승인을 받으면 정책 예외가 활성화되고 취약한 항목에 대한 패치 적용 활동은 정책 예외가 만료될 때까지 연기됩니다. 유효 기간 날짜에 도달하면 정책 예외가 만료되고 취약한 항목의 상태가 연기됨에서 오픈으로 변경됩니다.