타늄(Tanium)의 최고 보안 설계자(Chief Security Architect)인 라이언 카잔시얀은 ‘완나크라이(WannaCry)’ 랜섬웨어 공격 발생 후 전 세계 수십 개 기업의 내부 대응 절차를 직접 목격해 왔다. 그가 얻은 가장 큰 교훈은 무엇일까요? 단순한 방치가 아니라 변화에 대한 제도화된 저항이, 수많은 기업이 취약한 상태에 놓이게 된 가장 큰 원인 중 하나다. 이에 대해 다음과 같이 대처할 수 있습니다.
(Image: Arek Socha / Pixabay)
WannaCry 랜섬웨어 공격의 여파로 책임 공방이 확산되는 모습을 지켜보면서, 피해자들이 왜 쉽게 구할 수 있는 보안 조치를 그렇게 늦게까지 시행하지 않았는지 의문을 품게 되는 것은 당연한 일입니다. 이번 감염 확산을 막을 수 있었던 패치는 이미 두 달 전부터 제공되고 있었다. 이 악성코드는 4년 전부터 더 이상 사용되지 않게 된 Windows 기능을 악용했다. 종종 간과되는 점은, 단순한 방치가 아니라 변화에 대한 제도화된 저항이 수많은 기업이 취약한 상태에 놓이게 된 가장 큰 원인 중 하나라는 사실입니다.
지난 일주일 동안, 저는 ‘완나크라이(WannaCry)’ 랜섬웨어 공격이 발생한 후 전 세계 수십 개 기업의 내부 대응 절차를 엿볼 기회를 가졌습니다. 나는 인식과 현실 사이에 너무나도 빈번하게 발생하는 괴리를 목격했다.
가장 눈에 띄는 괴리부터 살펴보겠습니다. 많은 조직이 자사 시스템의 대부분에 패치가 적용되었다는 전제 하에 운영되고 있었습니다. 오히려 그들은 자사 컴퓨터 시스템 중 취약한 컴퓨터의 비율이 두 자릿수에 달한다는 사실을 발견했다. 다른 사람들은 시스템이 재부팅되었는지, 또는 다른 완화 조치를 위한 구성 변경이 적용되었거나 효력을 발휘했는지 확인할 방법이 없었다. 또 다른 이들은 수정 조치를 “단행”하는 데 주저했는데, 이는 의도하지 않은 결과가 발생할 경우 이를 신속하게 파악할 수 있을지, 또는 필요할 때 변경 사항을 되돌릴 수 있을지 확신하지 못했기 때문이다.
이러한 상황은 ‘완나크라이’ 공격에만 국한된 것이 아닙니다. Even as annual worldwide IT security approaches $100 billion in 2017, businesses continue to struggle with basic systems management tasks, like patching, which are critical to so-called security hygiene. 왜 그런지 이해하려면, 먼저 대부분의 IT 조직이 어떻게 운영되는지 살펴봐야 합니다.
지난 10년 동안 소프트웨어 개발자들은 데브옵스(DevOps) 운동과 이른바 애자일 방법론을 적극적으로 받아들여 왔다. 이러한 접근 방식은 기업 환경에서 솔루션의 반복적이고 신속한 개발, 테스트 및 제공을 중시합니다. 그러나 IT 및 보안 운영의 여러 분야에서 엔지니어링 및 변경 관리 프로세스는 비교적 구식인 채로 남아 있으며, 변화하는 추세에 완강히 저항하고 있다. 이는 두 가지 철학의 대립입니다. 즉, 신속하고 점진적이며 자동화된 변화와, 체계적이고 계획적이며 면밀히 검토된 대대적인 변화 간의 대립입니다.
‘완나크라이’는 조직 차원에서 심각한 문제를 야기한다
IT 및 보안 운영 부서가 변화에 소극적인 데에는 매우 현실적이고 실질적인 이유가 있습니다. 대부분의 IT 인프라는 기존 기술과 최신 기술이 뒤섞여 있으며, 시간이 지남에 따라 어찌어찌 함께 작동하도록 임시방편으로 짜맞춰진 상태입니다. Frost & Sullivan에 따르면, 평균적인 기업은 엔드포인트에서 4~6개의 운영 체제를, 서버에서는 4~7개의 서로 다른 운영 체제를 운영하고 있습니다. 수백 개의 비즈니스 핵심 애플리케이션(일부는 다른 애플리케이션보다 OS 계층의 변화에 더 민감할 수 있음)이 이러한 플랫폼 위에서 실행될 수 있습니다. 그리고 이러한 모든 인프라를 관리하는 운영상의 책임은 종종 극도로 분절되어 있는데, 최종 사용자 컴퓨팅, 서버 관리, 애플리케이션 감독 등의 업무가 여러 팀에 분산되어 있으며, 이들 팀은 항상 같은 속도로 움직이는 것은 아닙니다. 계약업체와 외주업체를 포함시키면 상황이 더욱 복잡해집니다. 그리고 어떤 개인이나 팀도 자신의 패치 작업으로 인해 중요한 시스템이 다운되는 사태를 초래하고 싶어 하지 않습니다.
비즈니스 요구 사항상 시스템 가용성이 중단 없이 유지되어야 할 경우, 기업들이 특정 유형의 IT 변경 사항에 대해 보수적인 입장을 취하는 이유를 쉽게 이해할 수 있다. 그리고 공정하게 말하자면, 현대의 변경 관리 프로세스들은 모두 비상 상황을 처리하기 위한 조항을 마련하고 있습니다. 그러나 워나크라이(WannaCry) 사건의 긴급성으로 인해 신속한 대응이 필요했음에도 불구하고, 많은 조직은 보안 운영 및 시스템 관리 기술의 한계로 인해 제약을 받았습니다. 이는 악순환을 보여줍니다. 대규모로 변화를 안정적이고 신속하게 실행하고 그 결과를 모니터링할 기술적 역량이 부족할 경우, 사람들은 더 많은 심의, 절차, 합의라는 형태로 ‘저항’을 가하게 됩니다. 이로 인해 기업의 민첩성이 더욱 저하되고, 투자한 솔루션의 효과도 제한받게 됩니다.
안타깝게도, WannaCry의 확산을 막을 수 있었던 이 패치는 오히려 확산 속도를 늦추는 데 “완벽한” 조합의 특성을 지니고 있었습니다:
- 이는 거의 모든 Windows 버전에 영향을 미쳤으며, 이는 테스트가 필요한 시스템 역할과 유형이 더 많아졌음을 의미합니다.
- 재부팅이 필요했기 때문에(모든 패치가 그런 것은 아닙니다), 업무에 미치는 영향을 최소화하기 위해 일정을 조율해야 했습니다.
- 이 제품은 원래 Windows XP 및 Server 2003 용으로 출시되지 않았으며, WannaCry 사태가 발생한 후에야 출시되었습니다. 두 운영 체제 모두 지원이 종료되었지만, 여전히 많은 환경에서 사용되고 있습니다. 그 수가 점점 줄어들고 있습니다. 예를 들어, NHS의 보고에 따르면 재고 목록에 등재된 호스트 중 XP를 실행 중인 시스템은 약 5%에 불과했지만, 이러한 시스템들은 종종 중요한 레거시 장치를 지원하는 데 사용되고 있습니다.
이러한 기술적·절차적 장애물들을 고려할 때, WannaCry가 특히 의료 분야와 같은 특정 산업 분야에서 그토록 엄청난 피해를 입혔다는 것은 놀라운 일이 아닙니다.
무서운 사실은 ‘완나크라이’가 훨씬, 훨씬 더 심각한 사태로 번질 수도 있었다는 점입니다. 이 글을 쓰는 시점에서, 해당 악성코드는 “고작” 수십만 대의 시스템만 감염시켰습니다. 반면, Conficker( 2008년 당시 마찬가지로 널리 퍼져 있던 Windows 취약점을 악용했던)는 10 백만 대 이상의 컴퓨터로 확산되었다. 많은 조직들이 단순히 운이 좋아 초기 공격 캠페인의 표적에서 벗어날 수 있었다. 그럼에도 불구하고 2017 에서 IT 시스템에 대한 의존도가 높기 때문에, 이번 공격의 영향은 그 이전의 다른 공격들보다 훨씬 더 심각하게 느껴졌다.
IT 리더들은 단순히 공격 탐지 및 대응 능력 향상에만 집중하는 것이 아니라, 이 기회를 활용하여 시스템 관리 및 보안 운영을 뒷받침하는 프로세스와 기술의 현대화를 주도해야 합니다. 향후 공격이 필연적으로 우리의 1차 방어선을 뚫고 들어올 때, 보안 위생 관리에 민첩한 접근 방식을 취한다면 소규모의 산발적인 감염이 다음 번 전 세계적 대유행으로 번지는 것을 막을 수 있습니다.
저자 라이언 카잔시얀() 소개: 타늄(Tanium)의 최고 보안 아키텍트(Chief Security Architect)인 라이언 카잔시얀은 사고 대응, 포렌식 분석 및 침투 테스트 분야에서 14 년 이상의 경력을 보유하고 있습니다. 라이언은 타늄(Tanium)의 위협 대응(Threat Response) 제품군의 설계 및 로드맵을 총괄하며, 타늄 엔드포인트 탐지 및 대응(EDR) 팀을 이끌고 있습니다. Tanium에 합류하기 전, 라이언은 Mandiant에서 표적 공격의 피해를 입은 수십 개의 포춘 500 대 기업과 협력하며 조사 및 대응 업무를 총괄했습니다. 라이언은 블랙햇(Black Hat)과 FBI 사이버 수사대의 강사로 활동하며 수백 명의 사고 대응 요원을 양성해 왔습니다. 그는 『Incident Response and Computer Forensics 제3판』(McGraw-Hill, 2014)의 공동 저자이다. 라이언은 또한 TV 시리즈 《미스터 로봇》의 기술 자문으로 활동하며, 작가진 및 제작팀과 협력해 드라마에 등장하는 해킹 장면을 기획하고 있습니다.
