컨테이너 취약성 대응

  • 릴리스 버전: Xanadu
  • 업데이트 날짜 2024년 08월 01일
  • 소요 시간: 10분
  • 애플리케이션은 ServiceNow® 컨테이너 취약성 대응 컨테이너 취약한 항목 (CVIT) 을 가져오고 규칙에 따라 컨테이너 취약성을 정정할 수 있습니다. NVD(국가 취약성 데이터베이스) 또는 외부 공급업체 통합과 같은 내부 및 외부 소스에서 취약성 데이터를 끌어옵니다.

    버전 18.0 취약성 대응부터 Vulnerability Manager Workspace 및 IT Remediation Workspace에서 각각 CVIT를 모니터링하고 정정할 수 있습니다. 자세한 내용은 취약성 관리자 작업 공간IT 정정 작업 공간 살펴보기 문서를 참조하십시오.

    스토어에서 앱 요청

    ServiceNow Store 웹 사이트를 방문하면 사용 가능한 모든 앱을 확인하고 스토어에 요청을 제출하는 방법에 대한 정보를 참조할 수 있습니다. 출시된 모든 앱의 누적 릴리스 정보는 ServiceNow Store 버전 기록 릴리스 정보를 참조하십시오.

    이점

    컨테이너 취약성 대응 애플리케이션은 다음과 같은 주요 이점을 제공합니다.
    • 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)를 식별합니다.
    • 배포된 애플리케이션의 위험 태세에 대한 정확한 가시성 제공
    • 해결해야 하는 취약성의 우선순위 지정 취약성으로 인해 영향을 받는 애플리케이션 서비스 또는 비즈니스 서비스 측면의 런타임 컨텍스트는 우선순위 지정에 도움이 될 수 있습니다.

    컨테이너 취약성 대응 는 프리즈마 클라우드 컴퓨팅 Palo Alto Networks 과 같은 컨테이너 보안 제품과 통합하여 런타임에 배포된 이미지에 대한 취약성 데이터를 끌어오고, 이러한 컨테이너 이미지가 배포되는 호스트, Kubernetes 클러스터, 서비스 및 네임스페이스와 같은 런타임 컨텍스트 정보로 취약성 데이터를 보강합니다. Kubernetes 검색을 사용하는 ServiceNow 고객은 의 에서 관련 Kubernetes 엔터티에 대한 취약성에서 생성된 참조를 볼 수 있습니다 구성 관리 데이터베이스(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의 세분성 구성 모두 > 컨테이너 취약성 대응 > 관리 > VI 세분성 구성.

    VI 세분성

    기본적으로 CVE와 Docker 이미지 버전(참조 + 태그)의 고유한 조합마다 취약한 항목이 생성됩니다. 그러나 몇 개의 Docker 이미지는 둘 이상의 Kubernetes 네임스페이스에 배포될 수 있으며 각 네임스페이스는 서로 다른 사업부 또는 팀에서 소유할 수 있습니다. 각 팀은 취약성을 수정하기 위해 새 버전의 컨테이너 이미지를 롤아웃하기 위한 자체 주기를 따를 수 있습니다. 이 시나리오를 컨테이너 취약성 대응 수용하기 위해 취약한 항목에 대한 세분성을 정의할 수 있습니다. Docker 이미지 버전 및 취약성의 모든 고유한 조합에 대해서도 각 Kubernetes 네임스페이스/클러스터/서비스에 대해 하나의 취약한 항목을 생성해야 하는지 여부입니다.

    VI 세분성

    이 예에서는 동일한 Docker 이미지 및 CVE 조합에 대해 생성된 두 개의 취약한 항목을 볼 수 있습니다. 하나는 Kubernetes 네임스페이스 'k8s-finservco-loans'용이고 다른 하나는 'k8s-finservco-wealthandinsurance'용입니다.

    태그 기반 서비스 식별을 사용하여 영향을 받는 서비스 식별
    전제 조건
    • 애플리케이션에서 다양한 서비스를 식별하고 해당 서비스를 나타내는 태그/키-값 쌍을 정의합니다.
    • 해당 태그 또는 레이블을 사용하여 Docker 이미지 및 Kubernetes Pod를 배포합니다.
    • ITOM Kubernetes 배포 검색 올바른 태그 또는 레이블을 사용하여 "태그 기반 서비스"를 정의합니다.
    • ITOM Kubernetes 검색 배포
    • 올바른 태그 또는 키-값 쌍을 사용하여 "태그 기반 서비스"를 정의합니다.
    • 취약성 데이터를 ServiceNow 사용하여 임포트 컨테이너 취약성 대응

    취약한 항목에 대한 위험 계산은 CI(Docker 이미지) 및 에서 CMDB관련 서비스의 중요도를 확인하여 수행할 수 있습니다. 그러나 영향을 받는 서비스를 보다 쉽게 식별할 수 있도록 에서는 컨테이너 취약성 대응 태그 기반 서비스 ID를 제공합니다.

    의 '태그 기반 서비스'ServiceNow컨테이너 취약성 대응에 정의된 키-값과 일치하는 키-값 또는 레이블과 함께 Kubernetes 포드 또는 엔터티를 게시하면 에서 Docker 이미지와 영향을 받는 애플리케이션 서비스 간의 관계를 자동으로 설정하고 위험 계산에 해당 애플리케이션 서비스의 중요도를 사용합니다.

    흐름은 다음과 같습니다.
    1. 컨테이너 취약성 대응 컨테이너 보안 제품에서 취약성 데이터를 임포트합니다.
    2. 각 컨테이너 취약한 항목에 컨테이너 취약성 대응 대해 취약성이 있는 Docker 이미지를 CMDB 채웁니다.
    3. 컨테이너 취약성 대응 그런 다음 Docker 이미지 레이블 또는 이 이미지가 배포된 Kubernetes Pod와 함께 게시된 레이블/키-값을 확인합니다. Kubernetes 검색이 실행 중인 경우 이 이미지를 사용할 수 CMDB 있습니다.
    4. 컨테이너 취약성 대응 그런 다음 동일한 일치 키-값 쌍이 정의된 '태그 기반 서비스' CMDB 를 검색합니다.위험 계산

      위험 계산

    5. 컨테이너 취약성 대응 는 일치하는 "태그 기반 서비스"(있는 경우)의 "비즈니스 중요도"를 사용하여 컨테이너 취약한 항목의 위험을 계산합니다.

      위험 계산

      위험 계산
    취약성 추적
    정정 대상 설정

    ServiceNow 를 사용하면 취약성 관리자가 '정정 대상 규칙'을 정의하여 컨테이너 이미지에서 발견된 취약성을 수정하기 위한 SLA(서비스 수준 계약)를 정의할 수 있습니다. 정정 목표 날짜는 이미지 메타데이터 또는 취약성 정보에 대한 조건/기준에 따라 정의할 수 있습니다. 정정 소유자는 기한이 임박한 취약성에 대한 이메일 커뮤니케이션을 받습니다.정정 대상 설정

    해결된 취약점 식별

    호스트에 패치를 적용하여 수정할 수 있는 호스트 취약점과 달리 컨테이너 취약점은 패치할 수 없습니다. 이전 버전을 대체하려면 새 버전의 컨테이너 이미지를 만들고 배포해야 합니다. 새 버전은 이전 버전과 다른 식별자(이미지 ID)를 가지고 있어 이미 수정된 취약성을 추적하기가 어렵습니다.

    ServiceNow 이전 버전의 컨테이너 이미지에서 보고되었지만 최신 버전의 이미지에서 해결된 취약성을 식별하고 해당 취약성을 자동으로 '종결/수정됨' 상태로 전환하여 보안 팀이 항상 최신 위험 태세를 정확하게 파악할 수 있도록 합니다.

    예외 관리

    취약성에 대한 애플리케이션 팀 또는 정정 소유자는 다음과 같은 이유로 예외를 요청할 수 있어야 할 수 있습니다.

    • 완화 통제가 이미 시행되고 있습니다.
    • 수용된 위험
    • 수정 사항을 푸시하기 위해 유지관리 기간을 기다리는 중입니다.

    ServiceNow 보안 관리자가 예외 요청에 대한 여러 수준의 승인자를 정의할 수 있도록 합니다. 지정된 조건과 일치하는 취약성을 자동으로 연기하는 데 사용할 수 있는 자동 예외 규칙을 정의할 수도 있습니다.예외

    예외

    새로운 기능

    새로운 기능과 변경된 Xanadu내용에 대한 자세한 내용은 릴리스 노트를 Xanadu 참조하십시오.

    시작하기

    • 인스턴스에 대한 보안 운영Now Platform 개요는 보안 작업 이해를 참조하십시오.
    • 에서 다운로드할 수 있는 모든 보안 운영 애플리케이션에 대한 자세한 내용은 보안 운영 및 ServiceNow Store를 참조하십시오.ServiceNow Store