컨테이너 취약성 대응
애플리케이션은 ServiceNow® 컨테이너 취약성 대응 컨테이너 취약한 항목 (CVIT) 을 임포트하고 규칙에 따라 컨테이너 취약성을 정정할 수 있습니다. 취약성 데이터는 NVD(국가 취약성 데이터베이스) 또는 타사 통합과 같은 내부 및 외부 소스에서 끌어옵니다.
스토어에서 앱 요청
ServiceNow Store 웹 사이트를 방문하면 사용 가능한 모든 앱을 확인하고 스토어에 요청을 제출하는 방법에 대한 정보를 참조할 수 있습니다. 출시된 모든 앱의 누적 릴리스 정보는 ServiceNow Store 버전 기록 릴리스 정보를 참조하십시오.
|
Vulnerability Response 작업 공간 사용
|
||
이점
- Palo Alto Networks의 Prisma Cloud Compute 같은 외부 공급업체 컨테이너 보안 제품과 통합됩니다.
- 런타임에 배포된 이미지의 취약성 데이터를 임포트하고 런타임 컨텍스트 정보(호스트, Kubernetes 클러스터, 서비스 및 네임스페이스)로 취약성 데이터를 보강합니다.
- Kubernetes 디스커버리 사용 ServiceNow 의 구성 관리 데이터베이스(CMDB) 관련 Kubernetes 엔터티에 취약성에서 생성된 참조 목록을 제공합니다.
- 취약성 및 정정 추세에 대한 인사이트를 제공하는 포괄적인 보고 대시보드를 제공합니다.
주요 기능
- 컨테이너를 실행하는 대신 CVIT에서 소스 Docker 이미지를 가리킵니다.
- 이미지, Kubernetes 클러스터, 네임스페이스 또는 서비스 수준에서 추적하도록 CVIT의 세분성을 구성합니다.
- 새 이미지 버전을 추적하여 수정된 취약성을 식별합니다. 이전 버전에서 보고된 취약성은 런타임에 새 이미지 버전이 배포될 때 자동으로 해결 ServiceNow 됩니다.
- 애플리케이션 이미지와 별도로 기본 이미지의 CVIT를 추적하여 독립적인 정정을 가능하게 합니다.
- 다단계 승인자 프로세스를 통해 검토할 수 있는 예외 요청 또는 긍정 오류 요청을 제기합니다.
- CVIT를 자동으로 연기하도록 예외 규칙을 정의합니다.
사용 케이스
- 런타임 컨텍스트
- 컨테이너 이미지의 취약성은 애플리케이션 수명주기의 다음 스테이지에서 이미지를 검사하여 검색할 수 있습니다.
- 스테이지 1: CI/CD 파이프라인에서 이미지를 빌드하는 경우.
- 스테이지 2: 이미지가 레지스트리에 게시될 때
- 스테이지 3: 이미지가 런타임에 배포될 때
1단계와 2단계에서 가능한 한 빨리 취약성을 식별하는 것이 중요하지만 런타임 환경에 배포된 이미지를 검사하는 것도 똑같이 중요합니다. 다음과 같은 이점을 제공합니다.- 게시된 새로운 CVE(Common Vulnerabilities and Exposures)를 식별합니다.
- 배포된 애플리케이션의 위험 태세에 대한 정확한 가시성을 제공합니다.
- 해결해야 하는 취약성의 우선순위 지정. 취약성으로 인해 영향을 받는 애플리케이션 서비스 또는 비즈니스 서비스와 관련된 런타임 컨텍스트는 우선순위 지정에 도움이 될 수 있습니다.
컨테이너 취약성 대응 에서 Prisma Cloud Compute Palo Alto Networks 와 같은 컨테이너 보안 제품과 통합하여 런타임에 배포된 이미지의 취약성 데이터를 끌어오고 이러한 컨테이너 이미지가 배포되는 호스트, Kubernetes 클러스터, 서비스 및 네임스페이스와 같은 런타임 컨텍스트 정보로 취약성 데이터를 보강합니다. Kubernetes 검색을 사용하는 ServiceNow 고객은 취약성에서 생성된 참조를 해당 구성 관리 데이터베이스(CMDB). 메타데이터를 ServiceNow 보강할 뿐만 아니라 취약성 및 정정 추세에 대한 인사이트를 제공하는 포괄적인 보고 대시보드를 제공합니다.
- 소유권 식별
- 필수 구성 요소
-
Kubernetes 메타데이터 및 참조: 컨테이너 취약성 대응 Kubernetes 메타데이터(네임스페이스, 클러스터 등) 및 항목 참조를 구성 관리 데이터베이스(CMDB) 채우려면 (ITOM)에서 Information Technology Operations Management Kubernetes 검색을 구현해야 합니다. Kubernetes 검색은 Docker 이미지, 실행 중인 Docker 컨테이너, 포드, Kubernetes 클러스터 등을 CMDB컨테이너 취약성 대응 . 이미지 ID를 기반으로 Docker CMDB 이미지를 식별한 다음, 관련 Kubernetes 엔터티를 식별하고 취약한 항목에서 해당 엔터티에 대한 참조를 채웁니다.
- 클라우드 메타데이터 및 Docker 이미지 레이블: 컨테이너 취약성 대응 Docker 이미지 레이블, 클라우드 계정 ID, 이미지가 배포되는 지역도 채웁니다. 이 데이터는 취약한 항목과 연결된 "탐색한 컨테이너 이미지" 기록에 유지됩니다. 이 데이터를 채우기 위한 필수 조건은 없습니다. 컨테이너 취약성 대응 는 컨테이너 보안 제품(예: Palo Alto Prisma Cloud Compute)에서 반환한 데이터를 사용하여 이러한 항목을 채웁니다.
-
-
컨테이너 이미지의 취약성을 패치하기 위한 소유권은 조직마다 다를 수 있습니다. 이 정보는 다른 위치에서 캡처될 수 있습니다. 일부 조직에서는 특정 컨테이너 이미지를 소유하는 애플리케이션 팀을 식별하는 방법으로 Docker 이미지 레이블을 사용하는 반면, 다른 조직에서는 Kubernetes 네임스페이스 또는 컨테이너 이미지가 배포된 클라우드 계정을 사용하여 올바른 소유자를 식별할 수 있습니다.
컨테이너 취약성 대응 은 '할당 규칙' 모듈에서 Docker 이미지 레이블, Kubernetes 클러스터/서비스/네임스페이스 메타데이터 또는 클라우드 계정 메타데이터(클라우드 계정 ID, 지역, 제공자 등)를 캡처 및 사용하고 이미지 또는 런타임 환경의 메타데이터를 기반으로 올바른 애플리케이션 팀에 취약성을 자동으로 할당하는 데 필요한 데이터 모델 요소를 제공합니다.
- 기본 이미지의 취약성 추적
- 필수 구성 요소
"기본 이미지" 속성을 채우 컨테이너 취약성 대응려면 기본 이미지를 콘솔에서 명시적으로 Vulnerability Response Integration with Palo Alto Networks Prisma Cloud Compute 구성해야 합니다. Prisma Cloud에서 기본 이미지를 구성하는 방법에 대한 자세한 내용은 https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin - compute/vulnerability_management/base_images를 참조하십시오.
컨테이너 취약성 대응 다른 팀에 할당할 수 있도록 기본 계층에 대한 별도의 취약성 기록을 생성할 수 있습니다.
컨테이너 이미지의 다른 계층에서 검색된 취약성에서 Alpine과 같은 기본 OS 이미지에서 식별된 취약성을 추적합니다. 많은 조직에는 기본 OS 이미지를 패치하고 모든 애플리케이션 팀에서 사용할 수 있도록 하는 전담 팀이 있습니다.
- 취약한 항목에 대한 세분성 정의
- 필수 구성 요소
다음으로 이동하여 CVIT의 세분성을 구성합니다. .
-
기본적으로 CVE 및 Docker 이미지 버전(참조 + 태그)의 모든 고유한 조합에 대해 취약한 항목이 생성됩니다. 그러나 몇 개의 Docker 이미지는 둘 이상의 Kubernetes 네임스페이스에 배포될 수 있으며 각 네임스페이스는 다른 비즈니스 단위 또는 팀이 소유할 수 있습니다. 각 팀은 취약성을 수정하기 위해 새 버전의 컨테이너 이미지를 롤아웃하기 위해 고유한 주기를 따를 수 있습니다. 이 시나리오를 수용하기 위해 다음을 컨테이너 취약성 대응 수행하여 취약한 항목에 대한 세분성을 정의할 수 있습니다. Docker 이미지 버전 및 취약성의 모든 고유한 조합에 대해 각 Kubernetes 네임스페이스/클러스터/서비스에 대해 하나의 취약한 항목을 생성해야 하는지 여부입니다.
이 예에서는 동일한 Docker 이미지 및 CVE 조합에 대해 생성된 두 개의 취약한 항목을 볼 수 있습니다. 하나는 Kubernetes 네임스페이스 'k8s-finservco-loans'에 대한 것이고 다른 하나는 'k8s-finservco-wealthandinsurance'에 대한 것입니다.
- 태그 기반 서비스 식별을 사용하여 영향을 받는 서비스 식별
- 필수 구성 요소
- 애플리케이션에서 다양한 서비스를 식별하고 해당 서비스를 나타내는 태그/키-값 쌍을 정의합니다.
- 해당 태그 또는 레이블을 사용하여 Docker 이미지 및 Kubernetes 포드를 배포합니다.
- ITOM Kubernetes 디스커버리 배포 올바른 태그로 '태그 기반 서비스'를 정의합니다.
- ITOM Kubernetes 디스커버리 배포
- 올바른 태그 또는 키-값 쌍을 사용하여 "태그 기반 서비스"를 정의합니다.
- 를 사용하여 취약성 데이터 ServiceNow 임포트 컨테이너 취약성 대응
-
취약한 항목에 대한 위험 계산은 CI(Docker 이미지) 및 에서 관련 서비스의 CMDB중요도를 확인하여 수행할 수 있습니다. 그러나 영향을 받는 서비스를 보다 쉽게 식별할 수 있도록 에서는 컨테이너 취약성 대응 태그 기반 서비스 식별을 제공합니다.
Kubernetes 포드 또는 엔티티가 의 ServiceNow"태그 기반 서비스"에 정의된 키 값과 일치하는 키 값 또는 레이블과 함께 게시되면 는 컨테이너 취약성 대응 Docker 이미지와 영향을 받는 애플리케이션 서비스 간의 관계를 자동으로 설정하고 위험 계산에 해당 애플리케이션 서비스의 중요도를 사용합니다.
플로우는 다음과 같습니다.- 컨테이너 취약성 대응 컨테이너 보안 제품에서 취약성 데이터를 임포트합니다.
- 각 컨테이너 취약한 항목에 컨테이너 취약성 대응 대해 취약성이 있는 Docker 이미지를 CMDB 채웁니다.
- 컨테이너 취약성 대응 그런 다음, Docker 이미지 레이블 또는 이 이미지가 배포된 Kubernetes 포드와 함께 게시된 레이블/키-값을 확인합니다. Kubernetes 디스커버리가 실행 중인 경우 이 CMDB 이미지를 사용할 수 있습니다.
- 컨테이너 취약성 대응 그런 다음 동일한 일치하는 키-값 쌍이 정의된 "태그 기반 서비스"를 CMDB 검색합니다.
- 컨테이너 취약성 대응 는 일치하는 "태그 기반 서비스"(있는 경우)의 "비즈니스 중요도"를 사용하여 컨테이너 취약한 항목의 위험을 계산합니다.
- 취약성 추적
- 정정 대상 설정
ServiceNow 를 사용하면 취약성 관리자가 컨테이너 이미지에서 발견된 취약성을 수정하기 위한 SLA(서비스 수준 계약)를 정의할 수 있도록 '정정 대상 규칙'을 정의할 수 있습니다. 정정 목표 날짜는 이미지 메타데이터 또는 취약성 정보에 대한 조건/기준을 기반으로 정의할 수 있습니다. 정정 소유자는 기한이 임박한 취약성에 대한 이메일 커뮤니케이션을 받습니다.
- 예외 관리
-
취약성에 대한 애플리케이션 팀 또는 정정 소유자는 다음과 같은 이유로 예외를 요청하는 기능이 필요할 수 있습니다.
- 완화 통제가 이미 시행 중입니다.
- 수용된 위험
- 수정 사항을 푸시하기 위해 유지관리 기간을 기다리는 중입니다.
ServiceNow 보안 관리자가 예외 요청에 대해 여러 수준의 승인자를 정의할 수 있습니다. 지정된 조건과 일치하는 취약성을 자동으로 지연시키는 데 사용할 수 있는 자동 예외 규칙을 정의할 수도 있습니다.
새로운 기능
의 새로운 기능과 변경된 Yokohama내용에 대한 자세한 내용은 릴리스 정보를 참조하십시오 Yokohama .
시작
- 인스턴스에 대한 보안 운영Now Platform 개요는 보안 운영 이해를 참조하십시오.
- 에서 다운로드할 수 있는 보안 운영 모든 애플리케이션에 대한 자세한 내용은 보안 운영 및 ServiceNow Store를 참조하십시오.ServiceNow Store