마이크로소프트가 소프트웨어 업데이트를 배포하는 ‘패치 화요일()’은 매달 정해진 날에 어김없이 찾아옵니다. (적어도 사이버 보안 분야에서는) 거의 모든 사람이 이 사실을 알고 있으므로, IT 팀은 경고를 받자마자 시스템을 업데이트할 것이라고 생각할 수 있습니다.
하지만 실제로는 그렇지 않다. 시노프시스(Synopsys)가 실시한 최근 ‘ ’ 조사( )에 따르면, IT 전문가의 28%가 중대한 취약점에 대한 패치를 적용하는 데 최소 3주가 걸리는 것으로 나타났으며, 또 다른 20%는 최대 한 달이 걸린다고 인정했다.
위협 행위자들이 취약점을 노린 새로운 공격 수법을 개발하고 있는 상황에서, 의 패치 관리 에 대한 이러한 소극적인 접근 방식은 수많은 네트워크와 데이터를 더 큰 위험에 빠뜨리고 있습니다. 마치 정비 경고등이 켜진 채로 차를 운전하는 것과 같습니다. 문제가 있다는 건 알지만, 차가 여전히 잘 달리고 있기 때문에 수리를 미루기 쉽습니다.
정비 경고등이 켜진 후 차량에 고장이 발생하기까지 몇 주에서 몇 달이 걸릴 수도 있습니다. 보안 분야에서 패치 공지가 도착하면, 이미 너무 늦지 않았다면 단 몇 초 안에 문제를 해결해야 합니다. 악의적인 공격자들은 지속적으로 알려진 취약점을 탐색하고 있기 때문입니다..
“기업 네트워크 뒤에 있고 방화벽으로 보호받고 있다 하더라도, 누군가가 경계선을 뚫고 들어와 그 취약점을 찾아내는 것은 시간문제일 뿐입니다.”라고 소프트웨어 보안 정보 기관 자문위원이자 카네기멜론대학교 사이버보안 교수, 그리고 ForAllSecure의 CEO인 데이비드 브럼리가 말했다. “보안 측면에서 볼 때, 가능한 한 빨리 패치를 적용해야 합니다.”
패치 적용이 더딘 이유
지난 1년 동안 IT 및 보안 팀은 다음과 같은 취약점들에 직면했습니다. MOVEit의 경우, 공격자가 시스템을 장악할 수 있게 하는 파일 전송 제로데이 결함; curl의 경우, URL 구문을 사용하여 데이터를 전송하는 오픈소스 도구를 겨냥한 제로데이 공격; 그리고 Apache Superset 익스플로잇의 경우, 구성 정보와 데이터베이스를 노출시키는 제로데이 취약점 등이 있었습니다. 에 따르면 매년 100건 미만의 새로운 제로데이 공격이 발생하고 있지만, 이러한 공격은 특정 조직 하나만을 표적으로 삼는 것이 아니라 해당 소프트웨어를 사용하는 모든 사용자를 대상으로 하기 때문에 막대한 피해를 입히는 경향이 있습니다. 최소한의 노력으로 수많은 표적을 공격할 수 있다는 점 때문에, 이는 국가 차원의 공격 주체와 사이버 범죄 조직들이 즐겨 사용하는 공격 수단이 되고 있다.
“기업 네트워크 뒤에 있고 방화벽으로 보호받고 있다 하더라도, 누군가가 경계선을 뚫고 들어와 그 취약점을 찾아내는 것은 시간문제일 뿐입니다.”데이비드 브럼리, 카네기멜론대학교 소프트웨어 보안 고문 겸 교수
그렇다면 패치가 출시되었음에도 불구하고 IT 및 보안 팀이 이를 적용하는 데 왜 이렇게 오랜 시간이 걸리는 것일까?
첫 번째 과제는 엔드포인트 가시성( )과 관련이 있습니다.: 보안 팀은 네트워크에서 실제로 사용 중인 자산 의 수와 유형 , 그리고 엔드포인트에 대한 정보를 파악해야 합니다. 여기에는 기업이 공식적으로 승인한 장비뿐만 아니라 직원들이 개인적으로 가져와 사용하는 수많은 다른 기기와 앱도 포함됩니다. 예를 들어, 이 취약점은 직원들이 사용하고 있지만 IT 담당자에게는 알려지지 않은 ‘ ’의 섀도우 IT( )에 존재할 수 있습니다. 아니면 DevOps 팀이 지원되지 않는 도구에 의존하는 환경을 사용하고 있을 수도 있습니다.
패치 적용을 지연시키는 두 번째 요인은 소프트웨어의 가시성, 특히 소프트웨어 내에서 취약점이 존재하는 구성 요소와 관련이 있습니다. 제로데이 취약점이 공개될 때마다 보안 팀은 자사의 소프트웨어 공급망 에 대해 충분히 파악하지 못하고 있다는 사실을 깨닫고, 감염된 구성 요소가 네트워크에서 사용 중인 애플리케이션 중 어느 곳에나 포함되어 있는지 확인하기 위해 허둥지둥해야 하는 경우가 너무나도 많습니다.
[함께 읽어보세요: 소프트웨어 공급망을 보호하는 7 가지 방법]
수만 개의 애플리케이션에서 사용되는 인기 있는 오픈소스 자바 로깅 라이브러리인 Apache Log4j에서 제로데이 취약점이 발견되었을 때, 2021년 12월 에서 발생한 일이 바로 이것입니다. 그 후 곧바로 패치가 배포되었음에도 불구하고, 2년이 넘게 지난 지금도 놀라울 정도로 많은 기업이 이 취약점을 아직까지 해결하지 못하고 있다. (최근 에서 실시한 설문조사( )에 따르면, Log4j 개를 사용하는 앱 중 38%가 보안이 취약한 버전을 사용하고 있는 것으로 나타났습니다.)
이러한 문제의 원인이 되는 구성 요소를 파악하기 위해 기업들은 점점 더 소프트웨어 원자재 명세서(SBOM, )를 활용하고 있는데, 이는 조직에서 사용하는 모든 소프트웨어 애플리케이션과 프로그램에 포함된 구성 요소나 구성 성분을 상세히 명시해 주는 것입니다. “식료품 저장실에 있는 다양한 물건들을 떠올려 보세요,”라고 타늄(이 잡지의 모회사)의 엔드포인트 보안 연구 책임자인 멜리사 비쇼핑이 설명했다. 식품 제조업체들은 모든 제품의 모든 원재료를 철저히 추적하고 있으며, 이를 통해 – 예를 들어 리스테리아나 대장균이 유행할 경우 – 오염된 원재료가 제품에 언제, 어디서 혼합되었는지 정확히 파악할 수 있습니다. 마찬가지로, SBOM을 활용하면 소프트웨어 빌드 구성 요소를 더 쉽게 추적할 수 있으며, 취약점이 발견되었을 때 해당 정보를 보다 신속하게 확인할 수 있습니다.
패치 적용이 더딘 세 번째 잠재적 원인은 결국 비즈니스적인 문제에서 비롯됩니다.
비쇼핑은 “사업은 계속되어야 하며, 많은 시스템에서는 정전이나 가동 중단, 재부팅이 불가피하다”고 말했다. “그로 인해 패치 적용을 미뤄야 한다고 주장하는 사업주나 운영팀의 반발이 일어날 수 있습니다.”
또한 취약점이 확인되어 기업 경영진에게 보고되었고, 경영진도 패치를 적용하겠다고 약속했지만, 공급업체가 해당 패치를 출시하기 전까지는 아무런 조치도 취할 수 없는 경우도 있습니다. 이는 특히 오픈소스 소프트웨어나 오픈소스 구성 요소를 사용하는 시스템에서 문제가 됩니다.
“공급업체들이 소프트웨어를 업데이트할 때까지 기다려야 합니다,”라고 비쇼핑은 덧붙였습니다. “즉, 전체 생태계에서 해당 업데이트를 제공할 수 있게 될 때까지 기다린 다음, 우리 환경에서 업데이트를 원활하게 진행할 수 있도록 관련 프로세스, 기술 및 정책을 마련해야 한다는 뜻입니다.”
왜 느린 패치가 때로는 그토록 유혹적인가
패치 적용을 미루는 일부 사람들은 자신들에게 그럴 만한 이유가 있다고 주장한다. 바로 패치를 즉시 적용하면 오히려 더 큰 피해를 입힐까 봐 두려워하기 때문이다.
“서비스 중단이나 가동 중단, 재부팅 등이 발생하면, 사업주나 운영 팀 측에서 ‘패치 적용은 미뤄야 한다’며 반발할 수 있습니다.”타늄(Tanium)의 엔드포인트 보안 연구 책임자 멜리사 비쇼핑
브럼리는 “패치를 적용하면 예측할 수 없는 문제가 발생할 수 있다”고 말했다. 사용자 입장에서는 업그레이드에 얼마나 시간이 걸릴지, 수정 프로그램을 적용하면 시스템에 오류가 발생할지, 또 어떤 문제를 해결하거나 예방하는 것인지 알 수 없습니다.
개발자의 관점에서 볼 때, 기존 코드의 안정성을 유지하는 것은 쉽지 않은 일일 수 있습니다. “코드를 작성했을 때는 제대로 작동했었는데요. “하지만 이제 업데이트가 필요할 때, 개발자는 해당 종속성에서 어떤 부분이 새로 불안정해졌는지 알 수 없다”고 그는 지적했다.
개발자들은 패치를 적용하라는 지시를 받을 때 상반된 메시지를 접하게 됩니다. 하나는 취약한 부분을 가능한 한 빨리 개선하는 것이고, 다른 하나는 아무런 문제가 발생하지 않도록 하는 것입니다. 브럼리는 두 번째 항목에 대해, 이것이 바로 개발자들이 자신의 작업을 평가하는 방식이라고 덧붙였습니다. 개발자들은 코드를 수정해야 하는 상황보다는 탄탄한 코드를 작성하기를 원하기 때문입니다.
개발자들의 부담을 다소 덜어주고, 알려지지 않은 취약점에 대한 패치가 검증될 때까지 기다리고 싶은 유혹을 줄이기 위해, IT 및 보안 팀은 ‘ ’ 방식의 ‘보안 설계(security-by-design)’ 접근 방식을 도입할 수 있으며(그리고 도입해야 합니다). 이 접근 방식은 지속적인 테스트를 통해 취약점을 최대한 제거하고, 개발 프로세스에 인증 보호 장치를 구축하는 것을 목표로 합니다. The National Cybersecurity Strategy, released by the White House in 2023, strongly recommends organizations adopt security-by-design protocols. 사이버보안 및 인프라 보안국(CISA)에 따르면, ‘설계 단계부터 보안을 고려한(secure by design)’ 접근 방식을 채택하면 패치 출시와 적용 사이의 시간 차를 포함해 사이버 보안의 취약점을 더 효과적으로 해소할 수 있을 것이라고 한다.
[함께 읽어보세요: NFL의 전설 빌 벨리칙이 알려주는 신속한 패치 관리의 비결 – 그리고 성공적인 사이버 보안 전략의 네 가지 핵심 요소]
조직 전반에 걸쳐 ‘설계 단계부터 고려된 보안(security-by-design)’이 표준이 되는 시점이 오기 전까지는, IT, 보안, 개발 팀이 협력하여 패치 적용 속도를 높일 수 있도록 지원하는 일종의 프로세스가 필요할 것입니다.
패치 작업은 정책 수립부터 시작됩니다
덴턴스(Dentons)의 글로벌 데이터 개인정보 보호 및 사이버 보안 그룹 파트너인 카일 밀러에 따르면, 가정용 컴퓨터 앞에서 크롬과 윈도우 업데이트를 적용하는 개인 사용자와는 달리, 기업 환경에서 패치를 처리하는 과정은 정책 수립부터 시작된다.
“어떤 도구가 애플리케이션의 80%를 모니터링하고 있다면, 나머지 20%의 애플리케이션은 패치 관리 도구에 포함되지 않았기 때문에 보안상 심각한 위험에 노출될 가능성이 매우 높습니다.”카일 밀러, 덴턴스 파트너
“우선 패치 관리에 관한 정책과 절차를 문서화하는 것부터 시작해야 합니다,”라고 밀러는 말했다. 이를 통해 패치를 적용하는 담당자가 회사의 기대 사항을 정확히 파악할 수 있도록 조직 차원의 통제 체계를 마련합니다.
“제가 협력하는 대부분의 기업들은 업무 시간 외에 별도의 시간을 할애해 정기적인 패치를 적용합니다.”라고 밀러는 말했다. “하지만 필요한 경우 중대한 취약점에 대한 패치 적용을 승인하는 절차도 마련해야 하며, 때로는 가능한 한 신속하게 처리해야 할 때도 있습니다.” 이를 위해서는 시스템 현황을 파악하여 잠재적인 위험 요소와 패치의 출처를 확인할 수 있어야 합니다.
패치 작업을 업무 시간 외에 수행하는 이유 중 하나는 이에 따른 가동 중단 시간을 줄이기 위해서입니다. 또한 패치 작업을 수동으로 수행해야 하는 경우 – 이는 시간이 많이 소요되는 과정입니다 – 보안 팀이 이 작업을 처리할 수 있는 기회는 대개 이때뿐입니다.
이는 의 자동화 솔루션과 AI의 필요성을 뒷받침합니다. 패치 적용 과정을 자동화하면 반복적인 작업에 대한 수동 개입의 필요성을 줄일 뿐만 아니라, 업데이트에 더 신속하게 대응할 수 있게 되어 결과적으로 취약점이 노출되는 기간을 단축할 수 있습니다. 패치 적용 프로세스를 자동화하면, 악용으로 인한 데이터 유출 위험을 줄임으로써 기업의 규정 준수 목표 달성에도 기여할 수 있습니다. 또한 조직은 AI를 활용하여 중대한 위험도를 기준으로 취약점의 우선순위를 정하고, 그 우선순위에 따라 패치를 적용하여 위험을 완화할 수 있습니다.
시중에는 다양한 패치 관리 도구가 있지만, 밀러는 어떤 도구가 효과를 발휘하려면 사용자의 구체적인 요구 사항에 맞춰져야 한다고 경고합니다.
밀러는 “어떤 도구가 애플리케이션의 80%를 모니터링하고 있다면, 나머지 20%의 애플리케이션은 패치 관리 도구에 포함되지 않았기 때문에 보안상 심각한 위험에 노출될 가능성이 매우 높다”고 말했다. 마찬가지로, 내부 시스템의 구버전을 파악하는 데 도움이 되는 패치 관리 도구는 보안 담당자가 해당 알림을 검토하고 해당 시스템을 최신 상태로 업데이트할 때만 유용합니다.
그렇긴 하지만, ‘ ’ 도구들의 무분별한 확산()에도 주의해야 합니다. 도구가 너무 많으면 오히려 효과적인 패치 적용과 전반적인 사이버 보안을 저해할 수 있습니다. 가장 효과적인 패치 적용 절차를 마련하기 위해 IT 및 보안 팀은 현재 보유하고 있는 도구를 평가하고, 중복된 부분과 미처 다루지 못한 영역을 파악하며, 각 도구의 효과성(해당 도구가 현재 직면한 보안 문제를 실제로 해결하고 있는지, 또는 현재 구축된 시스템과 호환되는지 여부)을 확인한 뒤, 의 자동화된 패치 적용 프로세스를 통해 수작업 부담을 어떻게 가장 효과적으로 줄일 수 있을지 결정해야 합니다.
밀러는 “도구를 도입하는 것과, 해당 도구가 자사 시스템에 맞게 조정되고 적절하게 구현되도록 보장하는 것, 그리고 내부 IT 팀이 이를 모니터링하는 과정을 종합적으로 고려해야 한다”고 말했다.
패치 문화 개선하기
개발 단계에서 어떤 도구를 사용하든, 어떤 정책을 마련하든, 코드가 아무리 견고하더라도 취약점은 항상 발생하기 마련입니다. 이러한 현실을 인식하고, 기업들은 패치 관리에 대한 문화를 바꿔나가야 합니다. 이를 위한 한 가지 방법은 의 취약점 관리 프로그램을 구축하는 것입니다.
타늄(Tanium)의 비쇼핑은 “실질적인 취약점 관리 프로그램을 구축하는 것은 효과적인 패치 관리 프로그램을 구축하는 과정의 일부”라고 말했다.
겉보기에는 똑같은 것처럼 들릴지 모르지만, 사실은 다릅니다. 취약점 관리는 위협을 평가하고, 각 위협이 환경에 미칠 수 있는 영향을 분석합니다. 일부는 조직의 보안에 극도로 위험할 수 있는 반면, 다른 고위험 취약점은 해당 시스템에서는 악용될 수 없을 수도 있습니다.
조직은 취약점 관리 프로그램을 수립하는 것 외에도 전반적인 보안 및 보안 인식 교육을 강화해야 합니다. 사용자들에게 보안이 취약한 시스템이 초래하는 결과를 보여주고, 패치가 적용되지 않은 취약점의 위험성을 강조하며, 시스템을 효율적으로 운영할 수 있는 정책과 절차를 마련하는 것은 IT 및 보안 팀이 적시에 패치를 적용하는 데 방해가 되는 문제들을 더 잘 해결하는 데 도움이 될 것입니다.
