단순한 스캔이 아닌 9단계로 취약점 관리 프로세스를 구축하는 방법

우리는 4월 XNUMX일을 크게 보냈어요 취약점 관리 워크숍. 오늘 우리는 Qualys의 Andrey Novikov의 연설 사본을 출판하고 있습니다. 그는 취약점 관리 워크플로우를 구축하기 위해 거쳐야 할 단계를 알려줄 것입니다. 스포일러: 우리는 스캔하기 전에 중간 지점에만 도달할 것입니다.

1단계: 취약성 관리 프로세스의 성숙도 수준 결정

처음에는 취약성 관리 프로세스의 성숙도 측면에서 조직이 어느 단계에 있는지 이해해야 합니다. 그런 후에야 어디로 이동해야 하는지, 어떤 조치를 취해야 하는지 이해할 수 있습니다. 검사 및 기타 활동을 시작하기 전에 조직은 내부 작업을 수행하여 IT 및 정보 보안 관점에서 현재 프로세스가 어떻게 구성되어 있는지 이해해야 합니다.

기본적인 질문에 답해 보세요.

• 재고 및 자산 분류를 위한 프로세스가 있습니까? 
• IT 인프라를 얼마나 정기적으로 검사하고 전체 인프라를 대상으로 하는지, 전체 그림을 볼 수 있습니까?
• 귀하의 IT 리소스가 모니터링됩니까?
• 귀하의 프로세스에 KPI가 구현되어 있습니까? 그리고 KPI가 충족되고 있음을 어떻게 이해합니까?
• 이러한 모든 프로세스가 문서화되어 있습니까?

2단계: 전체 인프라 범위 보장

당신이 모르는 것을 보호할 수는 없습니다. IT 인프라가 무엇으로 구성되어 있는지에 대한 완전한 그림이 없으면 이를 보호할 수 없습니다. 현대 인프라는 복잡하며 양적, 질적으로 끊임없이 변화하고 있습니다.
이제 IT 인프라는 기존 기술(워크스테이션, 서버, 가상 머신) 스택뿐만 아니라 비교적 새로운 기술인 컨테이너, 마이크로서비스에도 기반을 두고 있습니다. 정보 보안 서비스는 주로 스캐너로 구성된 기존 도구 세트를 사용하여 작업하기가 매우 어렵 기 때문에 가능한 모든 방법으로 후자에서 벗어나고 있습니다. 문제는 어떤 스캐너도 전체 인프라를 다룰 수 없다는 것입니다. 스캐너가 인프라의 모든 노드에 도달하려면 여러 요소가 일치해야 합니다. 스캔 시 자산은 조직의 경계 내에 있어야 합니다. 완전한 정보를 수집하려면 스캐너에 자산과 해당 계정에 대한 네트워크 액세스 권한이 있어야 합니다.

우리의 통계에 따르면 중규모 또는 대규모 조직의 경우 인프라의 약 15~20%가 어떤 이유로든 스캐너에 캡처되지 않습니다. 즉, 자산이 경계를 넘어 이동했거나 사무실에 전혀 나타나지 않습니다. 예를 들어 원격으로 근무하지만 여전히 회사 네트워크에 액세스할 수 있는 직원의 노트북이나 자산이 Amazon과 같은 외부 클라우드 서비스에 있는 경우가 있습니다. 그리고 스캐너는 가시성 영역 밖에 있기 때문에 이러한 자산에 대해 아무것도 알지 못할 가능성이 높습니다.

전체 인프라를 포괄하려면 스캐너뿐만 아니라 인프라에서 새로운 장치를 감지하는 수동 트래픽 청취 기술, 정보를 수신하는 에이전트 데이터 수집 방법을 포함한 전체 센서 세트를 사용해야 합니다. 이를 통해 온라인으로 데이터를 수신할 수 있습니다. 자격 증명을 강조 표시하지 않고 스캔해야 합니다.

3단계: 자산 분류

모든 자산이 동일하게 생성되는 것은 아닙니다. 어떤 자산이 중요하고 어떤 자산이 중요하지 않은지 결정하는 것이 귀하의 임무입니다. 스캐너와 같은 어떤 도구도 이 작업을 수행하지 않습니다. 이상적으로는 정보 보안, IT 및 비즈니스가 함께 협력하여 인프라를 분석하여 비즈니스에 중요한 시스템을 식별합니다. 이를 위해 가용성, 무결성, 기밀성, RTO/RPO 등에 대해 허용 가능한 지표를 결정합니다.

이는 취약점 관리 프로세스의 우선순위를 정하는 데 도움이 됩니다. 전문가가 취약점에 대한 데이터를 받으면 이는 전체 인프라에 걸쳐 수천 개의 취약점이 포함된 시트가 아니라 시스템의 중요성을 고려한 세부적인 정보가 됩니다.

4단계: 인프라 평가 수행

그리고 네 번째 단계에서만 취약성의 관점에서 인프라를 평가하게 됩니다. 이 단계에서는 소프트웨어 취약점뿐만 아니라 취약점이 될 수도 있는 구성 오류에도 주의를 기울이는 것이 좋습니다. 여기서는 에이전트의 정보 수집 방법을 권장합니다. 스캐너는 경계 보안을 평가하는 데 사용될 수 있고 사용해야 합니다. 클라우드 공급자의 리소스를 사용하는 경우 거기에서 자산 및 구성에 대한 정보도 수집해야 합니다. Docker 컨테이너를 사용하여 인프라의 취약점을 분석하는 데 특별한 주의를 기울이세요.

5단계: 보고 설정

이는 취약점 관리 프로세스의 중요한 요소 중 하나입니다.
첫 번째 요점: 임의의 취약점 목록과 이를 제거하는 방법에 대한 설명이 포함된 여러 페이지로 구성된 보고서를 작업하는 사람은 아무도 없습니다. 우선, 동료들과 소통하고 보고서에 어떤 내용이 포함되어야 하는지, 동료들이 데이터를 받는 것이 어떻게 더 편리한지 알아내야 합니다. 예를 들어, 일부 관리자는 취약점에 대한 자세한 설명이 필요하지 않고 패치에 대한 정보와 이에 대한 링크만 필요합니다. 또 다른 전문가는 네트워크 인프라에서 발견된 취약점에만 관심을 갖고 있습니다.

두 번째 요점: 보고란 종이 보고서만을 의미하는 것이 아닙니다. 이는 정보와 정적인 이야기를 얻기 위한 오래된 형식입니다. 개인은 보고서를 받고 이 보고서에 데이터가 표시되는 방식에 어떤 방식으로도 영향을 미칠 수 없습니다. 원하는 형식의 보고서를 얻으려면 IT 전문가가 정보 보안 전문가에게 연락하여 보고서를 다시 작성하도록 요청해야 합니다. 시간이 지남에 따라 새로운 취약점이 나타납니다. 부서에서 부서로 보고서를 전달하는 대신 두 분야의 전문가가 온라인으로 데이터를 모니터링하고 동일한 그림을 볼 수 있어야 합니다. 따라서 우리 플랫폼에서는 사용자 정의 가능한 대시보드 형태의 동적 보고서를 사용합니다.

6단계: 우선순위 지정

여기에서 다음을 수행할 수 있습니다.

1. 시스템의 골든 이미지로 저장소를 생성합니다. 골든 이미지로 작업하고, 취약점을 확인하고, 지속적으로 구성을 수정하세요. 이는 새로운 자산의 출현을 자동으로 보고하고 해당 자산의 취약성에 대한 정보를 제공하는 에이전트의 도움으로 수행될 수 있습니다.

2. 비즈니스에 중요한 자산에 집중하십시오. 한번에 취약점을 제거할 수 있는 조직은 세상에 없습니다. 취약점을 제거하는 과정은 길고 지루하기까지 합니다.

3. 공격 표면을 좁힙니다. 불필요한 소프트웨어 및 서비스의 인프라를 정리하고 불필요한 포트를 닫으십시오. 최근 한 회사에서 40만 대의 기기에서 이전 버전의 Mozilla 브라우저와 관련된 약 100만 개의 취약점이 발견된 사례가 있었습니다. 나중에 밝혀진 바와 같이 Mozilla는 수년 전에 골든 이미지에 도입되었으며 아무도 이를 사용하지 않지만 수많은 취약점의 원인입니다. 브라우저가 컴퓨터에서 제거되었을 때(일부 서버에서도 마찬가지였습니다) 이러한 수만 개의 취약점이 사라졌습니다.

4. 위협 인텔리전스를 기반으로 취약점 순위를 지정합니다. 취약점의 심각성뿐만 아니라 취약점이 있는 시스템에 대한 공개 악용, 맬웨어, 패치 또는 외부 액세스의 존재도 고려하십시오. 이 취약점이 중요한 비즈니스 시스템에 미치는 영향을 평가합니다. 데이터 손실, 서비스 거부 등으로 이어질 수 있습니까?

7단계: KPI에 동의

스캔을 위해 스캔하지 마십시오. 발견된 취약점에 아무 일도 일어나지 않으면 이 스캔은 쓸모없는 작업으로 변합니다. 취약점에 대한 작업이 형식적인 일이 되는 것을 방지하려면 결과를 어떻게 평가할 것인지 생각해 보십시오. 정보 보안과 IT는 취약점 제거 작업의 구성 방식, 검사 수행 빈도, 패치 설치 등에 대해 합의해야 합니다.
슬라이드에는 가능한 KPI의 예가 나와 있습니다. 우리가 고객에게 추천하는 확장 목록도 있습니다. 관심이 있으신 분은 저에게 연락해 주시면 이 정보를 공유해 드리겠습니다.

8단계: 자동화

다시 스캔으로 돌아갑니다. Qualys에서는 스캐닝이 오늘날 취약점 관리 프로세스에서 발생할 수 있는 가장 중요하지 않은 일이며, 무엇보다도 정보 보안 전문가의 참여 없이 수행되도록 최대한 자동화해야 한다고 믿습니다. 오늘날에는 이를 수행할 수 있는 많은 도구가 있습니다. 개방형 API와 필요한 커넥터 수만 있으면 충분합니다.

제가 소개하고 싶은 예는 DevOps입니다. 거기에 취약점 스캐너를 구현하면 DevOps를 잊어버릴 수 있습니다. 고전적인 스캐너인 오래된 기술을 사용하면 이러한 프로세스가 허용되지 않습니다. 개발자는 귀하가 스캔하여 여러 페이지로 구성된 불편한 보고서를 제공할 때까지 기다리지 않습니다. 개발자는 취약점에 대한 정보가 버그 정보 형태로 코드 어셈블리 시스템에 입력될 것으로 기대합니다. 보안은 이러한 프로세스에 원활하게 구축되어야 하며 개발자가 사용하는 시스템에서 자동으로 호출되는 기능이어야 합니다.

9단계: 필수 사항에 집중

회사에 진정한 가치를 가져다주는 것이 무엇인지에 집중하세요. 스캔은 자동으로 수행될 수 있으며 보고서도 자동으로 전송될 수 있습니다.
관련된 모든 사람이 더욱 유연하고 편리하게 프로세스를 개선할 수 있도록 집중하세요. 예를 들어 웹 애플리케이션을 개발하는 상대방과의 모든 계약에 보안이 내장되어 있는지 확인하는 데 중점을 둡니다.

회사에서 취약점 관리 프로세스를 구축하는 방법에 대한 자세한 정보가 필요한 경우 저와 제 동료에게 문의하세요. 기꺼이 도와드리겠습니다.

출처 : habr.com