취약점 관리란 무엇인가요?

취약성 관리 설명

네트워크 장치, 서버, 스토리지 시스템, 워크스테이션, 레거시 애플리케이션, 가상 머신, 컨테이너, 클라우드 애플리케이션, 마이크로서비스, 데이터베이스, API, 클라우드 인프라 서비스, 클라우드 플랫폼 서비스, 보안 구성 등 그 목록은 끝이 없을 것 같습니다. 애자일 방법론의 보급이 증가하고 클라우드 서비스가 IT 환경을 확장함에 따라 취약성 관리가 점점 더 복잡해지고 있습니다. 기존 IT 환경과 마찬가지로 클라우드 워크로드의 취약성 관리는 보안 취약성을 식별, 평가, 우선순위 지정, 완화하여 민감한 데이터를보호하고 클라우드 규정 준수를유지하며 사이버 공격의 위험을 줄이는 지속적이고 다각적인 프로세스입니다.

이 프로세스는 최신 자산 인벤토리를 유지하고 취약성 스캔을 사용하여 클라우드 리소스에서 잠재적인 위협을 발견하는 것으로 시작됩니다. 그런 다음 취약성의 심각성과 영향을 기준으로 취약성을 평가하여 해결 노력의 우선순위를 정할 수 있습니다. 패치 및 구성 관리는 소프트웨어 취약성과 잘못된 구성을 해결하고, 지속적인 모니터링과 사고 대응을 통해 새로운 위협을 신속하게 탐지하고 차단합니다. 마지막으로 보고 및 감사 활동은 가시성과 책임성을 제공하여 취약점 관리 프로그램의 효과와 규정 준수를 보장합니다.

취약성, 위협 및 위험 이해하기

취약점이 중요한 이유와 취약점이 비즈니스에 미치는 영향을 이해하려면 취약점, 위협 및 위험 간의 관계를 이해해야 합니다.

취약점이란 공격자가 시스템을 제어하거나 데이터를 유출하거나 운영을 방해하거나 비즈니스에 해를 끼치기 위해 악용할 수 있는 IT 시스템의 결함, 약점, 잘못된 구성 또는 감독 소홀을 말합니다.

즉, 취약점이 사이버 위협을 수행할 수 있는 기회를 제공한다는 뜻입니다. 위협이란 어떤 종류의 사이버 공격을 시도하거나 잠재적으로 실행할 수 있는 모든 주체를 말합니다. 그러나 사이버 공격을 수행하기 위해서는 위협이 이용할 수 있는 취약점을 찾아야 합니다.

취약점이 존재하고 위협이 이를 적극적으로 악용하려고 하면 조직은 위험에 처하게 됩니다.

따라서 취약점은 위협이 실제 위험으로 이어질 수 있는 가능성을 열어줍니다. 취약점이 없으면 금전적 이득을 위해 조직의 중요 데이터를 훔치려는 해커나 지정학적 목적으로 중요 시스템을 방해하려는 국가 지원 위협 행위자와 같은 위협이 여전히 존재할 수 있습니다. 그러나 취약점이 존재하는 경우에만 실제로 위협이 악용될 위험이 존재합니다.

클라우드 취약성 관리가 어려운 이유

모든 유형의 워크로드에서 취약점 관리는 간단하지 않지만 클라우드 워크로드를 처리하는 경우 취약점을 탐지하고 완화하는 것은 특히 어렵습니다.

복잡하고 다양한 클라우드 서비스

클라우드 워크로드는 매우 다양할 수 있습니다. 여기에는 VM, 컨테이너, 서버리스 기능, 오케스트레이션 서비스또는 위의 모든 것이 포함될 수 있습니다. 클라우드 워크로드 유형에 따라 각기 다른 유형의 취약점이 발생할 수 있으므로 워크로드 상황에 따라 다양한 위협을 인식할 수 있는 취약점 관리 전략이 필요합니다.

끊임없이 변화하는 클라우드

대부분의 온프레미스 환경보다 클라우드 환경은 일반적으로 동적입니다. 워크로드의 대규모 확장 및 축소, 사용자 추가 또는 제거, 애플리케이션 업데이트 등에 따라 구성이 지속적으로 변경됩니다. 따라서 취약점을 지속적으로 모니터링하는 기능이 가장 중요합니다.

다양한 클라우드 위험 범위

모든 취약점이 똑같이 생성되는 것은 아닙니다. 원격 코드 실행 익스플로잇을 가능하게 하는 익스플로잇과 같은 일부 익스플로잇은 드문 구성에서만 익스플로잇이 가능한 익스플로잇보다 더 위험합니다. 어떤 문제가 심각한지 알아야 먼저 해결할 수 있습니다.

취약성 관리 대 패치 관리

어떤 측면에서 취약성 관리 프로세스는 패치 관리와 같이 IT 조직이 수십 년 동안 실행해 온 다른 보안 프로세스와 유사합니다. 취약점 관리와 마찬가지로 패치 관리는 잠재적인 보안 위험(공격자가 악용할 수 있는 패치되지 않은 소프트웨어)이 실제 문제가 되기 전에 체계적으로 찾아 대응하는 것을 포함합니다.

그러나 취약점 관리 프로세스는 패치 관리 그 이상입니다.

• 패치되지 않은 소프트웨어는 IT 환경에 취약점이 유입되는 한 가지 방법이지만, 이것이 유일한 방법은 아닙니다. 취약점 관리는 안전하지 않은 구성과 같은 취약점의 다른 진입 지점도 해결합니다.
• 패치 관리는 일반적으로 소프트웨어 패치를 주기적으로 설치하는 것이지만, 취약성 관리는 지속적인 프로세스입니다. 일주일에 한 번 또는 하루에 한 번만 취약점을 검사할 필요도 없고, 검사해서도 안 됩니다. 대신 지속적으로 스캔하여 언제 어디서나 실시간으로 취약점을 발견하고 대응할 수 있도록 해야 합니다.
• 취약성 관리 프로세스는 패치할 수 있는 자산(애플리케이션 등)뿐만 아니라 클라우드 서비스, 인프라 및 IT 팀이 일반적으로 패치할 수 없는 기타 유형의 리소스에도 적용됩니다.

일반적인 취약점 및 노출(CVE) 개요

보안 연구원이 공개적으로 사용되는 소프트웨어에서 취약점을 발견하면 일반적으로 CVE(공통 취약점 및 노출) 데이터베이스에 보고합니다. CVE 데이터베이스는 알려진 취약점의 목록입니다. 여기에는 취약점의 원인, 취약점이 악용될 수 있는 방법, 취약점의 심각성, 취약점을 완화하기 위한 시스템 패치 또는 업데이트 방법에 대한 세부 정보가 포함되어 있습니다.

대부분의 CVE 데이터베이스는 취약점 및 취약점이 초래하는 심각성에 대한 세부 정보를 공유하기 위한 개방형 프레임워크인 CVSS(공통 취약점 점수 시스템)를 사용하여 이 정보를 정의합니다. 취약성 데이터에 액세스할 수 있도록 함으로써 CVE와 CVSS는 조직이 사용하는 시스템이나 소프트웨어에 영향을 미치는 취약성을 파악하는 데 사용할 수 있는 중요한 리소스를 제공합니다. 또한 비즈니스에서 사용하는 특정 구성에 따라 취약점이 얼마나 심각한지, 취약점이 악용될 수 있는지 여부를 팀에 알려줄 수 있습니다.

국가 취약점 데이터베이스와 MITRE CVE 데이터베이스는 가장 널리 사용되는 공개 CVE 데이터베이스 중 하나입니다. 그러나 조직은 비공개 또는 향상된 CVE 데이터를 유지하여 위협 인텔리전스 서비스의 일부로 다른 조직에 제공할 수도 있습니다.

CVE의 중요한 한계는 일반적으로 오픈 소스 애플리케이션과 같이 공개적으로 사용 가능한 소프트웨어에 영향을 미치는 위협만 나열한다는 점입니다. 그 주된 이유는 누구나 공개 소프트웨어를 검사하고 그 안에서 잠재적으로 취약점을 찾을 수 있기 때문입니다. 조직이 내부용으로 예약한 소프트웨어는 외부 연구자가 연구하기가 더 어렵습니다. 그 결과, 소프트웨어 내의 취약점이 반드시 CVE 데이터베이스에서 발견되거나 공개되지는 않았습니다.

즉, CVE 데이터베이스에 알려진 취약점 기록이 없다고 해서 애플리케이션에 취약점이 없는 것으로 간주해서는 안 됩니다. 취약점이 존재하고 위협 행위자에게 알려졌지만 아직 보고되지 않았을 가능성은 항상 존재합니다.

하지만 위에서 언급한 바와 같이 보안 취약점은 다양한 형태로 존재합니다.

깨진 인증

소프트웨어 내의 비효율적인 액세스 제어 프로세스 또는 구성으로 인해 악의적인 공격자가 소프트웨어에 액세스하거나 사용자 권한 이상으로 권한을 확대할 수 있습니다.

SQL 인젝션

SQL 인젝션 취약점을 통해 공격자는 데이터베이스에 악성 쿼리를 삽입하여 데이터를 조작하거나 정보를 유출할 수 있습니다. SQL 인젝션 취약점은 일반적으로 데이터베이스와 인터페이스하는 애플리케이션 내에서 적절한 입력 유효성 검사가 이루어지지 않아서 발생합니다.

크로스 사이트 스크립팅

크로스 사이트 스크립팅 취약점을 통해 공격자는 악성 스크립트를 실행할 수 있습니다. 이러한 유형의 취약점은 잘못 작성된 자바스크립트 코드가 포함된 웹사이트에 가장 자주 영향을 미칩니다. 공격자가 취약한 코드를 발견하면 사이트를 속여 원하는 스크립트를 실행하도록 하여 웹사이트에 연결되는 엔드포인트의 리소스에 액세스할 수 있습니다.

사이트 간 요청 위조

공격자는 사이트 간 요청 위조 취약점을 악용하여 사용자가 현재 인증된 웹사이트나 애플리케이션에 악성 코드를 삽입하도록 유도할 수 있습니다. 크로스 사이트 스크립팅 취약점과 유사하지만, 크로스 사이트 요청 위조 취약점은 안전하지 않은 자바스크립트를 통해 악성 코드를 실행하는 것이 아니라 인증된 사용자를 사칭하여 악의적인 작업을 수행한다는 점이 가장 큰 차이점입니다.

잘못된 보안 구성

모든 유형의 보안 구성 실수 또는 감독 소홀은 취약점을 유발할 수 있습니다. 예를 들어, 관리자가 방화벽 구성 실수로 인해 실수로 인터넷을 통해 민감한 데이터에 액세스할 수 있게 하거나 새 애플리케이션 구축을 구성할 때 다중 인증을 요구하는 것을 잊어버릴 수 있습니다.

취약점 관리 대 취약점 평가

취약점 관리는 IT 조직이 취약점을 식별하고 이에 대응하기 위해 사용하는 전략입니다. 그러나 개별 취약점이 발견되면 취약점 평가라는 프로세스를 사용하여 취약점이 어느 정도의 위험을 초래하는지 파악하고 취약점을 해결하는 방법을 결정합니다.

취약점 평가가 중요한 이유는 모든 취약점이 동일한 수준의 위험을 초래하는 것은 아니기 때문입니다. 예를 들어, 취약한 시스템에 직접 물리적으로 접근할 수 있는 공격자만 익스플로잇할 수 있는 취약점은 일반적으로 네트워크를 통해 익스플로잇할 수 있는 취약점보다 위험이 적습니다. 네트워크를 통해 활동하는 위협 행위자의 수가 일반적으로 IT 자산에 물리적으로 접근할 수 있는 사람보다 훨씬 더 많기 때문입니다.

또한 특정 구성이나 환경에서만 취약점이 악용될 수 있는 경우도 있습니다. 예를 들어 애플리케이션이 Windows 서버에서는 호스팅되지만 Linux 서버에서는 호스팅되지 않는 경우 또는 그 반대의 경우 애플리케이션의 취약점을 악용할 수 있습니다.

이러한 요소를 기반으로 취약성 평가를 통해 조직은 각 취약성이 조직에 미치는 구체적인 위험 수준을 결정할 수 있습니다. 그런 다음 가장 심각한 취약점에 우선적으로 대응하여 전반적인 위험 수준을 최소화할 수 있습니다.

취약성 관리 프레임워크 설정하기

취약성 관리 프로그램은 해당 조직의 고유한 요구 사항에 맞게 조정해야 하지만, Gartner는 취약성 관리를 시작하는 데 유용한 출발점을 제공하는 취약성 관리 지침 프레임워크를 제공합니다.

Gartner 프레임워크의 주요 구성 요소는 다음과 같습니다:

• 프로그램의 범위를 정의합니다: 기업은 취약성 관리 전략의 시작은 해결해야 할 IT 자산과 취약성 유형을 결정하는 것부터 시작합니다.
• 역할과 책임을 정의합니다: 누가 언제 무엇을 하는지 결정하는 것은 취약성 관리의 중요한 요소입니다. IT 엔지니어와 같은 일선 직원부터 CISO, CTO에 이르기까지 모두가 취약점을 찾고, 보고하고, 관리하는 데 있어 각자의 역할이 있습니다.
• 취약성 평가 도구를 선택합니다: 기업은 취약점을 찾고 평가하는 데 사용할 도구와 취약점 해결을 워크플로와 도구에 어떻게 반영할지 결정해야 합니다.
• 정책 SLA를 만들고 구체화하세요: SLA는 조직이 취약점에 얼마나 빨리 대응할지, 어느 수준의 활성 취약점을 허용할 수 있는지를 결정합니다. 조직마다 감내할 수 있는 위험 수준이 다를 수 있으므로 SLA는 비즈니스에 맞게 조정하는 데 특히 중요한 리소스입니다.
• 자산 컨텍스트 소스를 식별합니다: 자산 컨텍스트 소스는 시스템이나 애플리케이션이 비즈니스에서 수행하는 역할에 대한 데이터와 같은 보완적인 정보를 제공하며, 이는 취약성과 그 심각성을 평가하는 데 중요할 수 있습니다.

이러한 각 요구 사항을 해결함으로써 조직은 우려되는 모든 시스템에서 취약점을 찾아 대응할 수 있는 취약점 관리 프로그램을 구축할 수 있습니다.

취약점 관리의 4가지 핵심 단계

효과적인 취약점 관리 프로그램이 완전히 구현되면 비즈니스에서 취약점 관리 프로세스에서 다음 각 단계를 수행할 수 있어야 합니다.

취약점 식별

보이지 않는 것을 고칠 수는 없습니다. 취약점을 찾으려면 조직의 모든 IT 자산을 스캔하고 해당 자산(또는 자산의 구성 요소)이 취약점에 노출되어 있는지 확인해야 합니다. CVE 데이터베이스는 이러한 목적을 위해 중요한 리소스이지만, 모든 취약점이 공개 CVE 목록에 자세히 설명되어 있는 것은 아닙니다.

취약점 평가

발견 후에는 각 취약점을 평가하여 비즈니스에 미치는 위험 수준을 결정해야 합니다. 경우에 따라 수동 취약성 평가가 필요할 수도 있지만, 취약성 관리 도구는 각 취약성의 심각성을 자동으로 결정하고 비즈니스 환경에서 취약성이 악용될 가능성을 평가하여 프로세스를 가속화할 수 있습니다.

취약점 처리

취약점은 크게 세 가지 방법으로 처리할 수 있습니다:

• 수정: 수정에는 일반적으로 영향을 받는 자산을 업데이트하거나 패치를 적용하여 취약점을 완전히 제거하여 취약점이 더 이상 존재하지 않도록 하는 작업이 포함됩니다.
• 완화: 조직은 완화를 통해 취약점이 악용될 수 있는 위험을 최소화하거나 취약점으로 인해 발생할 수 있는 잠재적 피해를 줄일 수 있습니다. 완화는 수정이 불가능하거나 실현 불가능한 경우에 좋은 전략입니다. 예를 들어 취약한 레거시 애플리케이션에 대한 패치가 제공되지 않아 업데이트할 수 없는 경우에도 애플리케이션의 구성을 변경하여 취약성을 완화할 수 있습니다.
• 수락: 경우에 따라 IT 조직은 취약점이 개선이나 완화의 가치가 있을 만큼 심각하지 않다고 판단할 수 있습니다. 이 경우 취약점을 받아들이기만 하면 됩니다.

취약점 보고

취약점 보고는 외부 이해관계자에게 취약점을 공개하는 프로세스입니다. 여기에는 공개 CVE 데이터베이스에 취약점 보고서를 제출하는 것이 포함되는 경우가 많지만, 규정 준수 의무 또는 계약에 따라 조직은 규제 기관, 고객 또는 파트너에게 직접 취약점을 보고해야 할 수도 있습니다. 어느 쪽이든 보고의 목표는 어떤 취약점이 존재하는지, 취약점의 원인은 무엇인지, 취약점을 어떻게 수정할 수 있는지에 대한 정보를 공유하여 다른 사람들이 취약점이 익스플로잇으로 이어지기 전에 대응할 수 있도록 하는 것입니다.

취약점 관리 프로그램 개선하기

취약점 관리 프로그램이 마련되어 있다고 해서 취약점에 대한 걱정을 멈추고 다른 걱정거리로 넘어갈 수 있는 것은 아닙니다. 대신 취약성 관리는 지속적인 개선 전략의 혜택을 받아야 하며, 이는 IT 조직이 취약성 관리 전략을 개선할 수 있는 방법을 지속적으로 모색해야 한다는 것을 의미합니다.

취약점 관리 프로그램 개선의 일반적인 예는 다음과 같습니다:

• 자동화를 더욱 광범위하게 활용하여 취약점 관리에 효율성과 일관성을 더하세요.
• 취약점 관리 범위 내에 추가 시스템 또는 애플리케이션을 도입하여 포괄적인 적용 범위를 늘립니다.
• 추가 취약성 데이터베이스 및/또는 자산 컨텍스트 소스를 활용하여 취약성을 평가할 때 사용할 수 있는 데이터를 늘립니다.
• 새롭거나 향상된 취약성 관리 도구를 구축하여 이전 시스템에서 지원하지 못했던 취약성 유형을 탐지합니다.

이러한 단계를 통해 조직은 취약성 관리를 더욱 효과적이고 효율적으로 수행할 수 있으며, 취약성의 종류와 위치에 관계없이 모든 취약성을 실시간으로 탐지하고 수정한다는 목표에 더 가까워질 수 있습니다.

클라우드 워크로드 취약성 관리를 위한 모범 사례

클라우드 취약점이 심각한 위협으로 발전하기 전에 모든 클라우드 취약점을 발견하고 해결할 수 있는 간단한 비결은 없습니다. 하지만 다음과 같은 전략을 사용하면 심각한 클라우드 관련 사이버 공격의 위험을 완화할 수 있습니다.

CI 프로세스에 취약점 스캔 통합

개발 수명 주기 초기에 취약점을 발견할수록 프로덕션 환경의 침해로 이어질 위험이 낮아집니다.

따라서 취약점 스캔은 CI 프로세스에 통합되어야 합니다. 워크로드가 프로덕션 환경에서 스캔할 때까지 기다리지 말고 개발 및 스테이징 환경의 호스트, 컨테이너, 서버리스 기능 및 기타 리소스를 스캔하세요. 개발/스테이징과 프로덕션 간에 구성이 변경되더라도 취약성 사전 배포를 모니터링하면 취약성이 프로덕션에 침투하는 것을 방지할 수 있는 가능성을 극대화할 수 있습니다.

프로덕션에서 스캔 유지

물론 워크로드가 프로덕션 환경에 구축된 이후에도 지속적으로 취약성 모니터링을 수행해야 합니다. 아무리 많은 사전 배포 스캔을 수행해도 프로덕션 워크로드의 위험을 확인하는 것을 대신할 수는 없습니다.

클라우드 환경의 모든 레이어 스캔

일반적인 클라우드 워크로드에는 여러 계층의 구성이 포함됩니다. 각각에 취약점이 존재할 수 있습니다.

예를 들어 컨테이너를 구축하는 경우 컨테이너 이미지에 취약점이 있을 수 있습니다. 컨테이너 오케스트레이터에서 구성한 RBAC 정책에도 취약점이 남아있을 수 있습니다. 또한 클라우드 제공업체의 IAM 프레임워크를 사용하여 구성한 정책은 컨테이너화된 워크로드에 위험을 초래할 수 있습니다.

그렇기 때문에 클라우드 워크로드의 모든 계층을 검사하는 것이 중요합니다. 데이터가 존재하는 모든 곳에는 취약점도 존재할 수 있습니다.

CVE를 사용하여 취약성 컨텍스트 확보하기

위에서 언급했듯이 일부 취약점은 다른 취약점보다 심각성이 더 높습니다. 하지만 어떤 것이 즉각적인 주의가 필요한지 항상 명확하게 알 수 있는 것은 아닙니다.

그럼에도 불구하고 취약성 경고를 최대한 실행 가능한 것으로 만들려면 각 취약성의 심각성 수준을 알아야 합니다. 알려진 취약점을 나열하고 위험 정도에 따라 '점수'를 매기는 CVE(공통 취약점 및 노출) 데이터베이스를 사용하여 이 작업을 수행할 수 있습니다.

취약성 탐지와 CVE 데이터를 결합하면 클라우드 워크로드 위험에 대한 상황에 맞는 실행 가능한 인사이트를 얻을 수 있습니다.

취약점 관리 FAQ