패치도 잘 해야 한다. 패치 또한 새로운 위협 요소가 될 수 있기 때문이다. 그렇다고 현재의 패치 시스템을 다 뜯어 고칠 필요는 없다. 조금씩만 개선하면 된다. 현실적인 선에서 패치 관리 시스템을 향상시킬 수 있는 패치 관리 노하우를 정리해 본다.

[보안뉴스 문가용 기자] “패치라는 행위가 안전하기만 하다고 믿고 있었다면, 이제 아니라는 걸 누구나 이해하게 됐군요.” 보안 업체 제로데이컨설팅(Zero Day Consulting)의 CEO인 브래드 코지(Brad Causey)의 설명이다. 당연히 최근 발생한 솔라윈즈(SolarWinds) 사태를 두고 한 말이다. “패치는 리스크를 줄이고자 하는 행위지만, 그 자체로 새로운 리스크에 문을 열어주는 것 또한 사실입니다.”


코지는 “내가 새로운 진리를 말하는 것이 전혀 아니”라고 강조한다. “이미 보안 업계에서는 누구나 알고 있는 사실입니다. 그러므로 패치는 나오자마자 무조건 적용하지 말고 먼저 실험을 해 보는 게 중요합니다. 사실 패치 적용했다가 컴퓨터가 멈춰버린 경험이 있는 조직들은 대부분 이렇게 합니다.” 그 외에 안전한 패치를 위해 할 수 있는 일에는 어떤 것이 있을까?

코지는 “현실적으로 움직여야 한다”고 말한다. “솔라윈즈 사태가 대단히 큰 충격을 주는 사건임에는 분명합니다. 하지만 그렇다고 해서 모든 조직들이 당장 오늘부터 패치 관리 시스템을 솔라윈즈 공격 시나리오에 맞춰 처음부터 개편해야 하는 건 아닙니다. 그저 이미 알려져 있었던 안전한 패치 관리 실천사항들을 다시 검토하여 적용하는 게 낫습니다. 즉, 해야 하는 걸 알면서도 하지 않았던 것을 실천하기 시작하면 충분하다는 겁니다.” 그러면서 코지는 NIST의 SP 800-40 문건이 좋은 가이드라인이 될 수 있다고 제안했다.

사이버 보안 업체 IP아키텍츠(IP Architects LLC)의 회장인 존 피론티(John Pironti)는 다른 의미에서 현실적이 되라고 조언한다. “자동 패치 시스템을 켜두고, 패치에 대해서는 완전히 잊어버리는 조직이 많습니다. 그렇게 패치라는 것을 망각의 영역에 가져다 두고, 거기에 쏟을 에너지를 앱 개발과 출시에 씁니다. 앱들이 빛의 속도로 등장해요. 그러면서 오로지 해킹만으로 평생을 보낸 국가 지원 해커들을 막겠다? 도둑놈 심보죠. 해야 할 건 하면서 공격을 막을 수 있을 거라 희망하는 게 옳습니다.”

그렇다고 자동화 기술로 패치를 감당하는 것이 잘못된 것은 아니다. 보안 업체 옴디아(Omdia)의 커티스 프랭클린(Curtis Franklin)은 “자동화 기술을 활용하는 것이 오히려 중요하다”고 말한다. “지금 발견되고 익스플로잇 되는 취약점의 수는 일일이 수작업으로 관리하기가 불가능한 수준에 이르렀습니다. 그렇게 하다가는 오히려 놓치는 것이 늘어납니다. 시스템을 더 취약하게 만드는 것입니다.” 이것 또한 현실이다.

피론티는 “이번에 대규모 사건이 터지긴 했지만, 그렇다고 업데이트를 불신하기 시작한다면 오히려 더 큰 문제가 일어날 것”이라고 경고하기도 했다. “만약 ‘솔라윈즈 사태로 패치라는 것을 믿을 수 없어서 패치 안 해’라고 생각하기 시작하는 사람들이 생겨난다면, 그것이야말로 솔라윈즈 사태로 인한 가장 큰 피해가 될 것입니다. 패치를 믿을 수 없어서 한 번 실험해 보고 전사적인 적용을 할 거야, 라는 쪽으로 가야 맞죠.”

피론티는 “근본적으로 소프트웨어가 오류를 포함한 상태, 즉, 취약점을 가진 불량품 상태로 출시되어도 사회적으로 용인되고 있다는 것이 문제”라고 말한다. “일부 산업에서는 표준이 엄격하게 적용되어 문제가 적은 편인데, 대기업들이 자체적으로 개발해 내부용으로 사용하는 앱들은 취약점이 득실득실 댑니다. 내부용이니까 괜찮다고들 생각하고 넘어갑니다만, 이것도 곧 바뀌어야 할 겁니다. 취약점 있는 소프트웨어가 출시되어도 괜찮다는 생각부터 바뀌어야 할 겁니다.”

하지만 이는 장기적인 해결 과제다. 지금 당장에는 어떻게 해야 할까? 피론티는 소프트웨어 개발사에게 소비자로서 한 가지 질문을 늘 묻기를 권고한다. “‘서드파티 코드의 무결성을 확인하고 유지하기 위해 어떻게 하고 계시나요?’ 이걸 물으면 됩니다. 소비자 한 사람 한 사람이 이걸 벤더들에게 묻기 시작하면 변화가 있을 거라고 기대합니다.”

다시 이야기를 ‘패치 실험’으로 돌리면, 테스트 환경을 어떻게 구성해야 할까? 조직 내 존재하는 모든 장비들과 모든 버전의 OS를 현실과 똑같이 설치하면 최고일 것이다. 하지만 단순히 패치 실험만을 위해 대부분의 시간 동안 아무도 사용하지 않을 장비와 솔루션에 지나치게 많은 돈을 투자하기는 힘들다.

코지는 “사업 운영에 있어 가장 중요한 환경을 구현하는 정도 선에서 그치는 게 알맞다”고 권장한다. “가장 많은 고객들이 사용하는 서비스나, 매일 운영되는 서비스의 핵심 인프라 같은 것들 말이죠. 혹은 가장 민감한 데이터가 유통되는 환경을 구현하는 것도 좋습니다.” 이에는 프랭클린도 동의하지만 “올바른 도구를 사용해 실험하는 것도 중요하다”고 지적한다. “시장에 좋은 솔루션들이 세분화 되어 출시되어 있습니다. 실험 목적에 맞게 알맞은 것을 활용하면 패치 실험으로 인한 효과를 극대화시킬 수 있을 겁니다.”

패치 관리를 대행해 주는 서비스도 존재하고, 대행 솔루션도 사용해봄직 하다고 프랭클린은 권장한다. 다만 이 때 다음과 같은 질문을 해가며 조심스럽게 선택하는 것이 좋다고 한다.
1) 클라우드 기반인가? 에이전트 기반인가? 에이전트리스(agentless)인가?
2) 어떤 애플리케이션 및 시스템과 호환되는가?
3) 서드파티 애플리케이션들도 관찰하는가?
4) 호환되지 않는 장비들에 대한 가시성도 확보되는가?
5) 패치를 적용하기 전에 실험을 하는가?
6) 감사 및 보고서도 생성해 주는가?
7) 통합해 사용할 수 있는 다른 제품이나 오픈소스 제품이 존재하는가?

코지는 실험 환경을 망으로부터 분리시키는 것의 중요성도 강조한다. “물리적으로까지 분리해 두는 것이 가장 안전하고 이상적일 겁니다. 하지만 현실에서 이렇게 실험 환경을 운영하는 것이 쉬운 일은 아닐 겁니다. 가상화와 마이크로세그멘테이션 이 보다 현실적인 선택지가 될 것입니다.”

패치 관리 대행 서비스 업체인 매니지엔진(ManageEngine)의 로마누스 레이몬드(Romanus Raymond)는 “실험을 했더라도 실제 패치 전에는 항상 백업을 하라고 고객들에게 권고한다”고 말한다. 또한 “조금씩 그룹을 나눠서 패치를 진행하는 것이 안전하다”고도 덧붙인다. “조금씩 나눠서 진행할 때 문제에 대한 진단과 해결이 더 쉬워집니다.”

3줄 요약
1. 패치, 그냥 막 적용한다고 되는 게 아님. 그 자체로 위험 요소가 될 수 있음.
2. 패치를 받았으면 실험하고 적용하는 것이 제일 중요함.
3. 이 때 조금씩 나눠서 하고, 중요한 데이터는 백업해두는 것이 안전.
[국제부 문가용 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>