취약점 평가란 무엇인가? 수행 방법, 모범 사례 및 예시

주요 내용

• 취약점 평가는 공격자가 이를 발견하기 전에 네트워크, 호스트, 애플리케이션 및 클라우드 워크로드 전반에 걸쳐 보안 취약점을 체계적으로 식별, 분류 및 우선순위를 지정합니다.
• 침투 테스트와 달리, 이 방법은 어떤 취약점도 악용하지 않습니다. 대신 위험 요소를 파악하여 어떤 부분을 어떤 순서로 수정해야 하는지 알 수 있게 해줍니다.
• 핵심 절차: 자산을 파악하고, 적절한 도구를 사용하여 스캔한 뒤, 단순한 CVSS 점수가 아닌 실제 악용 가능성을 기준으로 우선순위를 정하고, 지속적으로 패치를 적용합니다.
• 대부분의 프로그램이 실패하는 이유는 도구가 부족해서가 아니라, 평가를 지속적인 활동으로 여기기보다는 분기별 행사로 취급하기 때문이다.

일반적인 조직은 언제든 수천 건의 알려진 취약점을 안고 있으며, 취약점 발견과 해결 사이의 시차는 줄어들기는커녕 오히려 더 벌어지고 있습니다. ‘2026 버라이즌 데이터 침해 조사 보고서’에 따르면, 취약점 악용은 현재 가장 흔한 초기 침입 경로로, 침해 사고의 31%를 차지하며 이는 전년의 20%에서 증가한 수치입니다. 대부분의 팀은 감사관, 고객 보안 설문조사, 또는 실제 사고로 인해 어쩔 수 없이 확인하게 된 후에야 비로소 취약점을 알게 됩니다.

취약점 평가는 다른 사람이 발견하기 전에 미리 파악하는 작업입니다. 제대로 수행되면 무엇이 문제가 있는지, 그 심각도가 어느 정도인지, 그리고 무엇을 먼저 수정해야 하는지 알려줍니다. 하지만 제대로 수행되지 않을 경우(실제로는 종종 그렇습니다), 아무도 읽지 않는 400페이지 분량의 PDF 문서가 만들어질 뿐입니다.

취약점 평가란 무엇인가요?

취약점 평가는 IT 환경 및 정보 시스템 전반에 걸쳐 보안 취약점을 식별, 분류 및 우선순위를 매기는 체계적인 과정입니다. 그 결과물로는 CVE, 잘못된 구성, 취약한 인증 정보, 노출된 서비스 등 문제점들이 영향을 미치는 자산 및 수반되는 위험과 연계되어 우선순위가 매겨진 목록이 도출됩니다.

이는 대립적인 접근이 아닌 설명적인 접근 방식입니다. 보안 감사는 귀사의 통제 수단이 특정 프레임워크에 부합하는지 평가할 수 있습니다. 제로 트러스트 검토는 귀사의 접근 모델에 의문을 제기합니다. 반면 취약점 평가는 더 좁은 범위의 질문에 답합니다. 즉, 현재 어디에 취약점이 존재하는가 하는 점입니다. 이는 보안이 취약한 기본 설정, 추측하기 쉬운 관리자 비밀번호, 미적용된 패치, 혹은 아무도 강화하지 않은 취약한 인증 메커니즘 등일 수 있습니다.

취약점 평가의 작동 원리

이 메커니즘은 마케팅에서 묘사하는 것보다 더 간단합니다. 대부분의 평가는 다음과 같은 과정을 거칩니다:

• 자산 탐색: 문서화되지 않은 항목을 포함하여 네트워크에 실제로 존재하는 모든 자산을 파악합니다.
• 스캔: 해당 자산에 대해 인증된 스캔과 인증되지 않은 스캔을 실행하여 알려진 문제를 탐지합니다.
• 상관관계: 취약점 데이터베이스(NVD, 공급업체 권고 사항, KEV)와 결과를 대조하여 심각도와 맥락을 파악합니다.
• 보고: 단순히 12,000행짜리 CSV 파일만 제공하는 것이 아니라, 사람이 실제로 활용할 수 있는 결과를 만들어내야 합니다.
• 문제 해결 결과 전달: 실제 수정 작업을 수행할 팀에게 조사 결과를 전달할 때, 스캐너가 의도한 바를 팀이 직접 추론할 필요가 없도록 충분한 맥락을 함께 제공하십시오.

다양한 유형의 취약점 평가

스택의 각 계층마다 서로 다른 관점이 필요합니다. 네트워크 스캔을 한 번 실행했다고 해서 애플리케이션을 ‘안전하다’고 단정 짓는 것은 범주 오류입니다. 대부분의 성숙한 프로그램은 다음 요소들 중 여러 가지를 결합하고 있습니다:

• 네트워크 기반 평가: 노출된 서비스, 잘못 구성된 방화벽, 취약한 SSL/TLS, 인증되지 않은 서비스를 찾기 위해 IP 범위를 스캔합니다. 전형적인 외부 스캔입니다.
• 호스트 기반 평가: 서버 및 워크스테이션을 대상으로 인증을 거친 스캔을 수행하여 누락된 패치, 안전하지 않은 구성, 위험한 로컬 소프트웨어를 찾아냅니다. 네트워크 스캔에서 놓치는 문제점들을 포착합니다.
• 애플리케이션 평가: 코드베이스에 대한 SAST, DAST 및 SCA를 수행하여 SQL 인젝션(SQLi), XSS, 보안이 취약한 종속성 등의 문제를 프로덕션 환경에 반영되기 전에 탐지합니다. 현대적인 프로젝트는 수십 개에서 수백 개에 이르는 전이적 종속성 (즉, 종속성의 종속성)을 포함하고 있어, 공급망 취약점이 애플리케이션 공격 표면의 상당 부분을 차지하고 있습니다.
• 데이터베이스 평가: 기본 계정, 취약한 암호화, 과도한 권한, 패치되지 않은 데이터베이스 버전이 있는지 확인합니다.
• 클라우드 평가: AWS, GCP, Azure 전반에 걸쳐 IAM 정책, 노출된 스토리지 버킷, 컨테이너 이미지 및 런타임 구성을 평가합니다.
• 무선 네트워크 진단: 비인가 액세스 포인트, 취약한 프로토콜, 잘못 구성된 게스트 네트워크를 찾아냅니다.

전문가 팁: 인증된 스캔은 인증되지 않은 스캔보다 10배 더 많은 문제를 발견하지만, 설정하기가 더 어렵고 운영하기에도 조직 내 반발을 불러일으키기 쉽습니다. 호스트 스캔 유형 중 하나만 수행할 예산이 있다면, 반드시 인증된 스캔을 선택하십시오. 인증되지 않은 스캔은 외부인이 보는 것을 알려주는 반면, 인증된 스캔은 공격자가 첫 번째 침투 지점을 확보한 후 보는 것을 알려줍니다.

취약점 평가의 장단점

취약점 평가는 수행할 수 있는 보안 활동 중에서도 투자 대비 수익률(ROI)이 높은 편에 속하지만, 만능 해결책은 아닙니다. 이 평가가 무엇을 할 수 있고 무엇을 할 수 없는지 미리 파악해 두면 나중에 겪을 수 있는 실망을 크게 줄일 수 있습니다.

취약점 평가를 수행하는 방법: 실제로 중요한 4단계

공개된 대부분의 단계별 목록은 불필요하게 부풀려져 있습니다. 핵심만 추려보면 이 작업은 네 단계로 이루어집니다. 각 단계는 예상 가능한 방식으로 실패하기 마련이며, 이 중 어느 하나라도 생략하면 프로그램에서 생성된 보고서를 아무도 실행에 옮기지 않게 됩니다.

1단계: 범위 정의 및 자산 목록 작성

보이지 않는 것은 평가할 수 없습니다. 스캐너를 어떤 대상에 대기 전에, 호스트, 서비스, 애플리케이션, 클라우드 리소스에 대한 최신 현황 파악은 물론, 평가 대상에 포함되는 것과 제외되는 것에 대한 명확한 범위를 정해야 합니다. 지루하게 들릴지 모르겠지만, 이것이 나머지 평가 과정이 유용한지 여부를 가늠하는 가장 중요한 지표입니다.

AWS에서 운영되는 40명 규모의 SaaS 팀은 일반적으로 첫 번째 본격적인 자산 조사 과정에서 예상보다 20~30% 더 많은 자산을 발견하게 됩니다. 잊혀진 스테이징 환경, 디렉토리에 여전히 남아 있는 계약직 직원의 노트북, 2021년에 누군가가 생성한 후 폐기하지 않은 오래된 EC2 인스턴스 등이 그 예입니다. IT 부서의 관리 범위 밖에서 생성된 클라우드 계정, SaaS 도구, 개발 환경 등 ‘섀도우 IT’ 영역에서 이러한 격차가 가장 심각하게 나타납니다.

범위를 문서로 명확히 정의하십시오. IP 범위, 도메인, 계정 및 제외 대상을 구체적으로 명시하십시오. 인증 기반 스캔이 허용되지 않는 시스템이 있다면 그 이유와 함께 기록해 두십시오. 이 단계를 생략하면, 개발 클러스터가 다른 VPC에 있다는 사실을 보안 팀에 아무도 알리지 않아 몇 주 동안 스캔을 반복하게 될 것입니다.

2단계: 적절한 도구와 인증 정보를 사용하여 스캔하기

평가 대상 계층(네트워크, 호스트, 애플리케이션, 클라우드)에 적합한 스캐너를 선택하고, 적절한 인증 정보를 사용하여 실행하십시오. 호스트 기반 평가의 경우, 패키지 버전과 구성 파일을 읽을 수 있을 만큼 충분한 권한을 가진 SSH 또는 WinRM 액세스가 필요합니다.

도구 선택보다 일정이 더 중요합니다. 적절한 범위를 기준으로 매주 실행되는 스캐너는 분기마다 한 번씩 실행되는 “동종 최고” 스캐너보다 더 뛰어난 성능을 발휘합니다. 특히 리눅스 시스템의 경우, 원시 NVD 항목보다는 벤더 권고 사항과 취약점 데이터베이스를 기준으로 스캔해야 합니다. 레드햇(Red Hat), 캐노니컬(Canonical), 수세(SUSE)는 버전 번호를 변경하지 않고 수정 사항을 백포트하므로, 일반적인 CVE 검사를 수행하면 패치가 적용된 시스템에서 허위 양성이 대량으로 발생합니다.

주의: 프로덕션 데이터베이스나 금융 시스템을 대상으로 인증된 스캔을 수행하면 IDS 경보가 발생하거나, 서비스 계정이 잠기거나, 호스트당 수백 건의 감사 로그 이벤트가 생성될 수 있습니다. 해당 시스템을 관리하는 팀과 협력하여 작업 시간을 조정하고, 읽기 전용 권한이 부여된 전용 서비스 계정을 사용하십시오. 새벽 3시에 서비스 계정을 잠그는 스캐너는 더 이상 실행해서는 안 됩니다.

3단계: 분류 및 우선순위 지정 – CVSS에만 의존하지 않기

스캐너에서 출력되는 원시 데이터는 정렬되지 않은 잡음에 불과합니다. 선별 단계는 보안 분석가들이 취약점 평가 데이터를 실제로 유용한 정보로 전환하는 과정이며, 동시에 대부분의 프로그램이 방대한 데이터 양을 감당하지 못하고 무너지기도 하는 단계이기도 합니다. CISA의 ‘알려진 악용 취약점(KEV)’ 목록에는 공격자들이 현재 적극적으로 활용하고 있는 CVE들이 수록되어 있습니다. 이는 공개된 모든 CVE 중 극히 일부에 불과하며, CVSS 점수와 관계없이 가장 먼저 패치를 적용해야 할 목록입니다.

실용적인 트라이아지 스택:

1. 인터넷에 노출된 자산에 대해 KEV에 등재된 CVE부터 점검하십시오. 이 문제들은 긴급 대응이 필요한 사안입니다.
2. 민감한 데이터를 처리하거나 인증 경로에 속하는 자산에 대해 ‘심각(Critical)’ 등급의 CVE(CVSS 9.0+)를 추가하십시오.
3. EPSS 점수를 반영하여 실제 착취 가능성을 추정합니다.
4. 격리된 자산, 라우팅 불가능한 자산 또는 보상 제어 기능으로 보호되는 자산에서 발생하는 등급 하향 조정 문제.

이 부분에서 훌륭한 도구의 진가가 드러납니다. 예를 들어, TuxCare Radar는 악용 가능성 데이터, CVSS 점수, 확인된 패치 상태를 종합적으로 고려하므로, 팀원들이 단순히 원시 CVSS 수치만 보고 무엇이 시급한지 추측할 필요가 없습니다.

4단계: 문제 해결, 검증 및 재스캔 – 지속적으로

시정 조치가 따르지 않는 취약점 발견은 허울뿐인 쇼에 불과하며, 통계 수치도 이를 뒷받침합니다. TuxCare의 ‘2026 오픈소스 현황 보고서’에 따르면, 사이버 보안 사고의 61.4%는 이미 패치가 제공된 상태에서 발생했으며, 피해를 입은 조직의 92.6%는 사전에 취약점을 인지하고 있었습니다. 문제는 탐지가 아닙니다. 문제는 ‘인식’과 ‘시정’ 사이의 간극을 메우는 데 있습니다.

이 과정을 지속적으로 반복하십시오. 매일 또는 매주 점검을 실시하고, 새로운 문제점을 버그 수정 업무를 처리하는 동일한 티켓 관리 시스템에 반영하는 방식은 모든 실질적인 지표에서 분기별 평가보다 훨씬 더 효과적입니다.

가장 큰 장애물은 툴이나 예산이 아닙니다. 조직의 43%는 핵심 시스템을 오프라인으로 전환할 수 없다는 점을 패치 적용의 주된 걸림돌로 꼽았습니다. 이것이 바로 KernelCare와 같은 라이브 패치 도구가 존재하는 이유입니다. 재부팅 시간을 따로 잡지 않고도 커널 CVE를 해결할 수 있기 때문입니다. 업스트림 패치 제공이 완전히 중단된 지원 종료(EOL) 리눅스 배포판을 운영하는 팀의 경우, TuxCare의 Endless Lifecycle Support(ELS) 가 즉각적인 마이그레이션을 강요하지 않으면서도 그 공백을 메워줍니다.

취약점 평가 보고서에는 어떤 내용이 포함되나요?

아무도 열어보지 않는 CSV 파일로 내보내기만 하고 끝나는 스캔은 ‘완료된 평가’가 아니라 ‘완료된 스캔’일 뿐입니다. 발견된 결과를 의사결정으로 전환하는 것은 바로 보고서입니다. 훌륭한 취약점 평가 보고서에는 최소한 다음 내용이 포함되어야 합니다:

• 취약점 이름 및 CVE ID: 이를 읽는 누구나 직접 조회할 수 있도록
• 영향을 받는 자산: 호스트명, IP, 서비스 또는 애플리케이션
• CVSS 점수: NVD에서 제공하는 기본 심각도 등급
• 취약점 악용 가능성 관련 정보: CISA KEV 목록에 포함되어 있습니까? EPSS 점수는 얼마입니까? 공개된 익스플로잇 코드가 있습니까?
• 패치 상태: 패치됨, 패치되지 않음, 완화됨 또는 수용된 위험
• 권장 조치: 패치, 구성 변경, 보상 제어 또는 문서화된 예외
• 책임자 및 마감일: 대부분의 보고서에서 이 두 필드를 비워두는 경우가 많은데, 바로 그 때문에 조사 결과가 종결되지 않는 것입니다

실제로 이 보고서에는 두 가지 버전이 필요합니다. 하나는 작업을 수행하는 엔지니어를 위한 기술 보고서이고, 다른 하나는 CVSS 점수 대신 취약점을 비즈니스 위험과 연계하여 설명하는 경영진용 요약 보고서입니다. 외부로 노출되지 않은 내부 시스템에서 CVSS 9.8을 기록한 경우와, 공개 인증 서비스에서 CVSS 7.5를 기록한 경우에는 서로 다른 표현을 사용해야 합니다.

흔히 겪는 어려움과 대처 방법

스캐너 때문에 작업이 막히는 경우는 거의 없습니다. 실제 프로그램을 차질을 빚게 만드는 주된 원인은 대개 노이즈, 조정상의 문제, 그리고 아키텍처의 복잡성입니다.

오탐지(및 위음성)

스캐너는 실재하지 않는 문제를 지적하는 반면, 실제로 존재하는 문제는 놓치기도 합니다. 오탐은 시간이 지남에 따라 프로그램에 대한 신뢰를 갉아먹습니다. 지친 엔지니어가 스캐너의 경고를 무시하기 시작하면, 이 모든 작업은 그 가치를 잃게 됩니다. 위음성은 더 심각한 문제입니다. 실제 취약점을 발견하지 못한 채 방치하게 되기 때문입니다.

해결책은 더 좋은 스캐너가 아니라 보정입니다:

• 자산 클래스별로 스캔 프로필을 조정하십시오. 웹 서버와 데이터베이스 서버는 서로 다른 점검 항목이 필요합니다.
• 서비스 배너를 통해 추측하는 대신, 가능한 한 인증된 스캔을 활용하여 버전 정보를 확인하십시오.
• 원시 CVE 데이터보다는 공급업체의 보안 권고 사항과 결과를 대조해 확인하십시오. 특히 수정 사항을 역포트하는 엔터프라이즈 리눅스 배포판의 경우 더욱 그렇습니다. 이는 의외로 흔한 오탐의 원인이 되며, 엔지니어들의 귀중한 시간을 낭비하게 만듭니다.
• 알려진 오탐에 대한 차단 목록을 관리하고, 만료일을 설정하여 차단 조치가 실제 상황이 변경된 후에도 은연중에 지속되지 않도록 해야 합니다.

TuxCare Radar는 바로 이 문제를 해결하기 위해 특별히 개발되었습니다. 이 도구는 실제로 패치가 적용되지 않은 CVE와 라이브 커널 패치를 통해 메모리 내에서 수정된 CVE를 구분할 수 있습니다. 일반적인 스캐너는 이러한 차이를 종종 간과하여, 팀이 이미 해결한 취약점에 대해 경고를 발생시키곤 합니다.

새로운 취약점에 대한 최신 정보 파악하기

NIST는 매달 수천 건의 새로운 CVE를 공개하고 있으며, 그 속도는 점점 더 빨라지고 있습니다. 사람이 직접 권고문을 일일이 읽어보며 이를 따라잡을 수는 없습니다. 실질적인 해결책은 다음과 같습니다:

• 공급업체 메일링 리스트와 CISA KEV 업데이트를 구독하고, 이를 스캔 결과와 동일한 티켓팅 시스템으로 전달하십시오.
• 스캐너에 위협 인텔리전스 피드를 자동화하여, 새로운 시그니처가 몇 주가 아닌 며칠 내에 스캔에 반영되도록 하세요.
• 인증 관련 취약점은 별도로 추적하십시오. 인증 관련 버그는 공개된 직후 가장 빠르게 악용되는 경향이 있습니다.

또한 TuxCare의 CVE 트래커를 사용하여 지원 대상인 지원 종료된 리눅스 배포판 및 오픈소스 제품의 취약점 및 수정 현황을 모니터링할 수 있습니다.

복잡한 하이브리드 환경 스캔

온프레미스 평면 네트워크용으로 구축된 스캐너는 VPC 피어링, 쿠버네티스, 일시적 컨테이너, 파트너사의 SaaS 환경을 추가하는 순간 바로 작동이 중단됩니다. 하이브리드 스캐닝은 그 자체로 하나의 전문 분야입니다:

• 수명이 긴 호스트에는 스캐너 에이전트를 사용하고, 수명이 짧은 컨테이너에는 레지스트리/이미지 스캔을 수행하십시오.
• 단일 온프레미스 어플라이언스에서 클라우드 워크로드를 스캔하려고 시도하는 대신, 클라우드 네이티브 API(AWS Inspector, Azure Defender, GCP Security Command Center)와 연동하십시오.
• 모든 환경에서 자산에 일관되게 태그를 지정하여, 발견된 사항을 애플리케이션 및 소유자별로 상호 연관 지을 수 있도록 하십시오.
• 서버리스 함수나 관리형 서비스와 같은 일부 자산은 취약점 모델이 다르며, 완전히 다른 평가 전략이 필요하다는 점을 인정해야 합니다.

목표는 모든 CVE를 추적하는 것이 아니라, 현재 활발히 악용되고 있는 취약점들이 며칠 이상 방치되지 않도록 하는 것입니다.

취약점 평가 대 침투 테스트

이러한 사항들은 제안 요청서(RFP)에서 항상 혼동되곤 합니다. 이는 서로 다른 활동이며, 한 가지가 다른 하나를 대체할 수는 없습니다.

간단히 말해, 취약점 평가는 모든 항목을 겉핥기식으로 점검하는 반면, 침투 테스트는 몇 가지 대상을 집중적으로 공격합니다. 취약점 평가는 알려진 CVE를 찾아내고, 침투 테스트는 공격 체인, 논리적 결함, 그리고 때로는 제로데이 취약점을 발견합니다. 취약점 평가는 기준선으로 삼아 지속적으로 수행하십시오. 침투 테스트는 매년, 주요 서비스 출시 전, 또는 적용 범위가 실질적으로 변경될 때 실시하십시오.

취약점 평가를 위한 도구 및 소프트웨어

보안 도구 시장은 전용 취약점 스캐너, 공격 표면 관리 도구, 클라우드 네이티브 스캐닝 서비스 등에 이르기까지 매우 포화 상태입니다. 어떤 도구를 선택할지는 사용 중인 기술 스택에 따라 달라집니다. 리눅스 기반 시스템이 많은 환경, 클라우드 네이티브 환경, 그리고 윈도우가 주를 이루는 기업 환경마다 최적의 도구가 다릅니다.

TuxCare Radar

Radar는 TuxCare의 리눅스 전용 취약점 스캐너로, 대부분의 일반 스캐너가 제대로 처리하지 못하는 문제, 즉 엔터프라이즈 리눅스 배포판이 버전 번호를 올리지 않고 보안 수정 사항을 백포트한다는 점을 중심으로 설계되었습니다. 일반적인 CVE 검사 기능은 “구버전” 문자열을 감지하면 몇 주 전에 이미 패치된 취약점을 취약점으로 표시합니다.

Radar는 실제 벤더 권고 사항 데이터와 상호 참조합니다. 또한 실시간(재부팅 불필요) 패치도 인식하므로, KernelCare가 이미 메모리 내 커널 패치를 적용한 경우 Radar는 해당 CVE가 해결된 것으로 파악하여 미해결 상태로 보고하지 않습니다. 이는 사소한 세부 사항이 아닙니다. 이는 시스템의 실제 취약점을 정확히 알려주는 스캐너와, 팀이 결국 무시하게 되는 불필요한 경고를 생성하는 스캐너의 차이를 의미합니다.

Radar에 대해 알아두면 좋은 다른 점들: AI 기반 위험도 평가, 상주 에이전트 없음, 그리고 이미 스캐닝 플랫폼을 보유하고 있으며 정확한 리눅스 데이터만 추가로 통합하고자 하는 팀을 위한 Qualys, Nessus, OpenSCAP과의 기본 통합 기능 등이 있습니다.

Radar가 실제로 어떻게 작동하는지 확인해 보시겠습니까?

Tenable Nessus

오랜 기간 사용되어 온 범용 스캐너로, 다양한 운영 체제, 네트워크 장치 및 클라우드 자산을 폭넓게 지원하는 플러그인을 갖추고 있습니다. ‘하나의 도구로 대부분의 상황을 해결’하는 방식을 선호하며 라이선스 예산이 충분한 조직에 적합합니다. 다만, 패치된 엔터프라이즈 시스템에서 오탐을 유발하는 리눅스 백포팅의 미묘한 차이에 대해서는 전문성이 다소 부족합니다.

퀄리스 VMDR

광범위한 자산 범위를 지원하며, 에이전트 방식과 에이전트리스 방식을 모두 선택할 수 있고, Qualys의 광범위한 규정 준수 제품군과 긴밀하게 통합된 클라우드 기반 취약점 관리 솔루션 입니다. 취약점, 구성, 규정 준수 스캔을 모두 단일 공급업체에서 처리하고자 하는 기업에 적합합니다. 요금은 자산 수에 따라 책정되므로, 클라우드 네이티브 환경에서는 비용이 급격히 증가할 수 있습니다.

OpenSCAP

SCAP(Security Content Automation Protocol) 표준을 기반으로 구축된, 자동화된 규정 준수 점검 및 취약점 스캔을 위한 오픈소스 프레임워크입니다. NIST 및 CIS 벤치마크 규정 준수가 필수인 정부 기관, 규제 대상 산업, 리눅스 기반 환경에서 널리 사용됩니다. 유용한 결과를 얻기 위해서는 더 많은 구성 및 스크립팅 지식이 필요하지만, 무료로 사용할 수 있고 감사 가능하며, 기존 리눅스 자동화 파이프라인과 원활하게 통합됩니다.

취약성 평가 모범 사례

제대로 작동하는 프로그램과 방치되는 프로그램의 차이는 스캐너에 있는 경우가 거의 없습니다. 그 차이는 몇 가지 작업 습관에 달려 있습니다.

스캔 프로필 사용자 지정

기본 스캔 프로필은 출발점일 뿐, 최종 목표가 아닙니다. 웹 서버에는 안전한 프로필이 데이터베이스에는 과도한 부하를 줄 수 있으며, Windows 엔드포인트에 맞춰 조정된 프로필은 Linux 환경에서는 취약점을 놓칠 수 있습니다. 자산 유형별로 프로필을 구축하고, 이를 문서화한 뒤 분기별로 검토해야 합니다. 배포판(Distro)을 인식하는 도구, 즉 Red Hat이나 Ubuntu가 백포팅을 어떻게 처리하는지 이해하는 도구는 기본 설정으로 실행되는 일반적인 스캐너보다 훨씬 더 깔끔한 결과를 제공합니다.

다기능 팀과 협력하기

취약점 평가는 보안, 인프라, 애플리케이션 팀의 접점에서 이루어집니다. 책임자가 없는 평가 결과는 아무런 성과로 이어지지 않습니다. 보안 팀이 평가 범위를 정의하고 결과를 우선순위화하며, 인프라 팀이 OS 및 네트워크 문제 해결을 담당하고, 애플리케이션 팀이 코드 및 종속성 수정 작업을 책임지며, 규정 준수 팀은 보안 팀이 수작업으로 서식을 조정할 필요 없이 필요한 보고서를 바로 받을 수 있는 워크플로를 구축하십시오.

자산 목록을 최신 상태로 유지하세요

노후화된 인벤토리는 ‘침묵의 살인자’입니다. 실제로 530대의 호스트가 있음에도 400대만 있다고 인식하는 스캐너는 130대의 시스템에 대한 탐지 결과를 놓치게 되며, 이를 사용자에게 알리지 않습니다. 인벤토리 파악을 프로비저닝 과정에 연동하십시오. 새로운 VM, 컨테이너 이미지 또는 클라우드 계정이 생성될 때마다 인벤토리에 자동으로 반영되도록 해야 합니다. 이를 정기적인 구성 감사와 병행하여, 프로비저닝된 내용과 실제로 실행 중인 내용 간의 차이를 파악하십시오.

스캔 작업은 자동화하되, 선별 과정에는 사람이 참여하도록 하라

자동화는 대량의 작업을 처리하고, 사람은 판단을 담당합니다. 스캔 일정을 자동으로 설정하고, 검사 결과를 티켓팅 시스템에 자동으로 입력하되, 중요한 사항이나 KEV 목록에 포함된 항목은 반드시 사람이 검토하도록 해야 합니다. 감독 없이 순수하게 자동화만 진행하면 경보 피로도가 발생하고, 순수하게 수동으로만 검토할 경우 호스트 수가 수백 개를 넘어서면 확장성이 떨어집니다.

취약점 평가의 실제 사례

실제로 이것이 어떻게 나타나는지는 환경에 따라 크게 달라집니다. 몇 가지 현실적인 시나리오를 살펴보면:

예시 1: AWS 기반 SaaS 플랫폼

20명으로 구성된 SaaS 팀은 EC2 인스턴스 군에 대해 매주 인증 기반 스캔을 수행하고, ECR 레지스트리에 대해 매일 이미지 스캔을 실시하며, AWS Inspector를 통해 IAM 정책을 지속적으로 점검합니다. 발견된 문제는 Jira로 전송되며, 서비스 소유자에게 자동으로 할당됩니다. KEV에 등재된 중대한 CVE의 경우 7일 SLA가 적용되고, 그 외 모든 항목에는 30일 SLA가 적용됩니다. 이 팀의 문제 해결까지 소요되는 시간의 중앙값은 6개월 동안 45일에서 9일로 단축되었습니다.

예 2: 규제 대상 금융 서비스 업체

한 중견 은행은 약 8,000대의 호스트를 대상으로 분기별 내부 취약점 평가를 실시하고, 매월 외부 스캔을 수행하며, PCI 적용 범위에 대한 지속적인 스캔을 진행하고 있습니다. 규정 준수 보고 업무만으로도 전담 GRC 분석가 한 명이 필요합니다. 이 은행은 중요한 리눅스 서버의 경우, 패치 적용 시간을 예약하는 것이 운영에 지장을 주고 비용도 많이 들기 때문에 KernelCare의 재부팅 없이 적용되는 패치 기능을 활용하고 있습니다. KernelCare는 유지보수 일정을 변경할 필요 없이 스캔과 수정 사이의 공백을 메워줍니다.

예 3: 레거시 OT를 활용한 제조

공장 환경에서는 최신 리눅스 서버와 PLC를 구동하는 15년 된 윈도우 컴퓨터가 혼용되어 있습니다. OT 네트워크에 대한 능동적 스캔은 절대 허용되지 않습니다. 스캔이 잘못 수행될 경우 생산 라인이 중단될 수 있기 때문입니다. 따라서 평가 과정에서는 OT 자산에 대해서는 수동적 네트워크 모니터링을, IT 시스템에 대해서는 인증된 스캔을, 그리고 패치를 적용할 수 없지만 네트워크 분할을 통해 보호되는 시스템에 대해서는 문서화된 예외 목록을 활용합니다. 가장 흥미로운 발견은, 누군가가 잊고 있던 Windows 2008 서버가 기업 LAN에서 접근 가능하다는 사실이었습니다.

TuxCare를 통한 평가부터 실제 개선 조치까지

탐지만 하고 수정 조치를 취하지 않는다면 그저 비용만 드는 서류 작업에 불과합니다. 진정한 성과는 CVE 누적 건수를 앞서 나갈 수 있을 만큼 빠른 주기로 ‘스캔, 우선순위 지정, 패치, 검증’이라는 전체 과정을 완수하는 데 있습니다.

TuxCare Radar는 리눅스 환경에 특화된 정확도로 취약점 스캔 및 우선순위 지정을 처리합니다. KernelCare는 재부팅 시간 없이 커널 CVE 문제를 해결합니다. LibCare는 이를 OpenSSL 및 glibc와 같은 공유 라이브러리까지 확장합니다. 또한, 지원 종료일이 지난 시스템(CentOS 7, 구형 Ubuntu LTS 버전, 또는 지원이 종료된 언어 런타임 등)을 운영하는 팀을 위해, Endless Lifecycle Support는 벤더의 지원이 중단된 후에도 지속적으로 패치를 제공합니다.

현재 진행 중인 프로세스에서 수정 사항보다 보고서가 더 많이 생성된다면, 바로 그 격차를 해소해야 합니다. TuxCare가 지속적인 취약점 관리 워크플로우와 더 광범위한 IT 위험 관리 프로그램에 어떻게 통합되는지 확인해 보세요.

요약

기사 이름

취약점 평가란 무엇인가? 수행 방법, 모범 사례 및 예시

설명

IT 시스템을 안전하게 보호하고 싶으신가요? 취약점 평가와 그 작동 원리, 전문가들이 제안하는 모범 사례에 대한 가이드를 확인해 보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고