취약점 하나에 수천 개 기기, 앱, 라이브러리가 얽혀있어
사용 중인 모든 소프트웨어 인벤토리 작성하고 추적해야

[보안뉴스 오다인 기자] 세상 모든 사람들처럼 필자도 에퀴팩스(Equifax)가 소프트웨어 취약점을 패치해서 초대형 유출 사고를 막았더라면 좋았을 것이라고 바란다. 그러나 나는 왜 패치하는 게 어려운지도 잘 알고 있다. 나는 45,000명이 넘는 직원을 거느린 미국의 대형 은행에서 일한 적 있다. 처음 몇 년 동안 나는 수십 억 달러 치 투자 자산 거래를 처리하는 애플리케이션을 만들고 업데이트하는 부서의 개발 팀장으로 일했다. 그 후 나는 공공 클라우드, 네트워크, 보안 엔지니어링 등의 부문에서 일하면서 회사 전역의 각 부서가 애플리케이션을 생산하는 것을 도왔다.

서버 몇 개에 소프트웨어 취약점 하나를 패치한다는 건 말처럼 쉽지 않다. 취약점 하나를 패치한다는 건 각기 다른 장소와 사업 공정에 위치한 수천 개의 기기, 소프트웨어 애플리케이션, 소프트웨어 라이브러리라는 전체 맥락을 고려해야 하는 일이기 때문이다.

기기, 애플리케이션, 소프트웨어 라이브러리를 추적하기
기업은 소프트웨어를 사용하는 모든 기기에 대해 목록을 작성해야 할 필요가 있다. 에퀴팩스는 전 세계에 약 10,000명의 직원을 갖고 있다. 이 직원 개인마다 사용하는 컴퓨터, 전화기, 태플릿 등 기기가 있을 것이다. 기업은 자사 네트워크와 공공 클라우드 환경 내 가상 기기에 연결된 모든 하드웨어를 추적해야만 한다. 추가적으로, 운영체제, 애플리케이션, 소프트웨어 라이브러리 등 각기 다른 기기에서 기업이 사용하고 있는 모든 소프트웨어를 알고 있어야 한다. 이런 소프트웨어 중 일부는 자동화된 업데이트가 진행되지 않을 수도 있고 업데이트를 공지하는 프로세스가 없을지도 모른다. 기업은 소프트웨어를 철저하게 검사해서 업데이트 프로세스가 낫페트야(NotPetya), 씨클리너(CCleaner), 공공 파이썬 저장소 내의 악성 라이브러리 등 최근 일련의 사건들에서 나타난 것과 같은 악성 코드를 실어 나르고 있진 않은지 확인해야 한다.

비즈니스 인텔리전스 업체 크런치베이스(Crunchbase)에 따르면, 에퀴팩스는 1995년부터 2017년 사이에 16개 회사를 인수했다. 어느 회사가 다른 회사를 인수할 때마다 무수히 많은 신기술과 소프트웨어 라이브러리가 인수의 일부분으로 이뤄진다. 어느 회사를 인수할 때는 그 회사 시스템상의 모든 소프트웨어가 가장 최신 버전으로 업데이트돼 있는지 반드시 확인해야 한다. 인수합병에는 많은 복잡한 문제가 따라오는데, 그 중에서 패치가 최우선순위가 되는 일은 잘 없다. 각기 다른 네트워크와 IT 시스템을 합치는 건 복잡한 일이고, 최소 1년에서 그 이상의 시간이 걸릴 수 있는 일이다. 인수와 조직개편이 이뤄진다는 건, 서로 다른 사업 공정을 가진 서로 다른 기업이 존재한다는 걸 의미한다. 서로 다른 사람들이 기업의 다양한 부문에서 소프트웨어를 관리하고 있다는 뜻이다.

핵심적이고, 복잡하고, 오래된 애플리케이션을 업데이트한다는 것
많은 애플리케이션이 하나의 소프트웨어 라이브러리를 공유하고 있다. 그 라이브러리를 업데이트한다는 건 수백만 또는 수십억 달러 치 거래를 취급하는 프로세스를 망가뜨릴 수도 있는 일이다. 기업은 각각의 애플리케이션에 대해 업그레이드된 라이브러리가 제대로 작동하는지 테스트해야만 한다. 그런 다음, 새로운 버전의 애플리케이션을 세상에 내놓아야 하는 것이다. 예전의 어느 사례를 들어 설명하자면, 개발 부서가 손수 제작한 라이브러리를 업데이트해서 새로운 버전의 자바로 구축하는 데 수개월이 걸렸다. 당시 개발 부서는 50개가 넘는 각기 다른 금융 처리 애플리케이션에서 테스트를 진행해야만 했다. 이 애플리케이션들이 라이브러리 하나에 딸려 있었기 때문이다. 개발 부서는 애플리케이션을 실제 현장에 배치하고 구식 버전의 라이브러리를 제거하기 전에 50회 이상 테스트를 진행했다.

복잡한 레거시 애플리케이션을 테스트하는 것은 어려운 일이다. 투자 거래를 다루는 회사가 준수해야 할 그 모든 미국 세법과 규칙을 상상해보라. 거래 한 건에 대한 세법 적용이 달라지거나 세금 신고서에 명시돼야 할 항목에 변화가 있을 경우, 이에 따라 수백 가지의 변형이 발생할 수 있다. 시스템에 가해지는 변화는 이처럼 수많은 변형에 대해 개발 부서가 얼마나 많이 테스트를 해봐야 하는지를 말해준다. 시스템상의 세금 및 금융 처리가 모두 정확하게 작동하는지 확인하기 위해서 반복적으로 테스트를 진행해야만 하는 것이다. 바라건대, 각 애플리케이션에 대해서도 문서화 작업이 이뤄져야 한다. 그렇지 않다면, 업데이트된 레거시 애플리케이션을 어쩌다 한 번씩 테스트할 줄 아는 어느 누군가라도 아직 존재하길 바란다.

일부 경우, 패치를 설치하고 테스트하는 것은 고도로 위험할 수 있다. 소프트웨어 패치는 SCADA 시스템, 의료 기기, 연구실 시스템 같은 수백만 달러짜리 기기를 망가뜨릴 수도 있다. 시스템 관리자가 소프트웨어 업데이트를 사전에 테스트할 수 있는 여분의 기기 같은 건 존재하지 않는다. 소프트웨어를 패치하는 건 기업의 운영을 중단시키는 일이 될지도 모른다. 의료시설의 경우, 말 그대로 살고 죽는 문제가 될 수도 있는 것이다.

솔루션과 대안을 적용하는 것
패치가 어렵다는 건 기업들이 이 문제를 무시해도 된다는 뜻은 아니다. 기업들은 시간과 돈을 들여 소프트웨어 배치를 자동화하면서 사용하는 소프트웨어 목록을 추적하는 솔루션을 도입할 필요가 있다. 기업이 자사에 어떤 소프트웨어가 존재하는지 모른다면, 소프트웨어가 모두 최신 버전으로 업데이트돼 있는지 파악할 수 없을 것이다. 패치하는 게 매우 위험한 상황일 경우, 기업은 취약점이 있는 포트에 네트워크 접근을 제한하거나 소프트웨어 내 취약한 기능을 꺼버리는 방법도 고려해볼 수 있다.

또한, 기업들은 레거시 소프트웨어를 새로운 소프트웨어 아키텍처로 바꿔야 한다. 그래서 애초에 설계될 때부터 보안이 고려된 소프트웨어를 사용해야 한다. 이런 소프트웨어에 대해 투자수익률을 측정할 때는 대규모 정보 침해 때문에 다른 여러 기업들이 직면한 비용에 기초해야 한다. 그런데도 유사한 일이 반복된다면, 정보 유출을 막기 위해 제정된 높은 수준의 법률과 이로 인한 비용을 고려해야 한다. 이 같은 비용의 일부는 문제를 직접적으로 해결하지 않는 간접비로 추가될 수도 있다. PCI-DSS 컴플라이언스와 관련된 규제 같은 것들 말이다.

글 : 테리 라디헬(Teri Radichel)
[국제부 오다인 기자(boan2@boannews.com)]

Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>