델타항공의 CEO 에드 바스티안은 마이크로소프트와 크라우드스트라이크를 상대로 제기한 5억 달러 규모의 소송에 대해 언급했습니다. 델타 측은 이번 사태에 대해 "델타 생태계에 우선적으로 접근할 권리를 침해한 행위"라고 언급하며 기술 분야에서 "가장 취약한 플랫폼"에 대한 의존도를 재고하겠다고 밝혔습니다. 

MS와 크라우드스트라이크를 겨냥한 델타항공의 대규모 소송 

바스티안은 사고가 발생한 5일 동안 5,000편 이상의 항공편을 취소했고, 40,000대 이상의 서버를 수동으로 재설정했으며 취소 승객에 대한 매출 손실 뿐만 아니라 하루에 수천만 달러의 보상금과 호텔 비용을 포함, 5억 달러의 손실을 입었다고 주장했습니다. 

이번 소송에 대해 델타측은 마이크로소프트와 크라우드스트라이크는 "무료 자문 등 아무것도 제공하지 않았다"고 말했습니다. 또, 델타항공의 IT 시스템 구축 과정에서 마이크로소프트와 크라우드스트라이크는 분명히 핵심적인 요소로 함께 사용됨에도 불구하고, 양사 각각이 사이버 분야에서 경쟁을 하고 있다는 이유로 상호 협조나 파트너십 제공을 비롯한 충분한 기술 지원을 해주지 않았다고 했습니다. 

또한 크라우드스트라이크의 잘못된 검증 프로세스를 정면으로 비난했는데요. "연중무휴 24시간 운영되는 중요한 작업 시스템에 (충분한 검토 없이) 설치한 뒤 버그가 있다고 말해선 안 된다"고 말했습니다.

​MS 기반 보안 시스템의 전면 교체가 해결 방법?

인터뷰 과정에서 바스티안은 이후 마이크로소프트, 크라우드스트라이크를 벗어나기 위한 시스템 구매 포트폴리오를 확보했다는 암시를 남기기도 했습니다. "우리는 마이크로소프트를 다시 생각해야 한다. 내 생각에 윈도우는 아마도 그 분야에서 가장 취약한 플랫폼일 것이다. 애플에서 대규모 장애가 발생했다는 소식을 마지막으로 들은 게 언제인가?"라고 말했는데요.

이 부분에 대해서 우리는 생각을 해 볼 필요가 있습니다. 이번 사태와 관련해 마이크로소프트는 소프트웨어 애플리케이션에 대한 커널 수준 액세스를 재검토하고 있다고 발표했는데요. 에드 바스티안이 언급한대로 MacOS를 기반으로 작동하는 서버, 현재는 단종된 XServe는 아무런 문제가 없는걸까요? 

그렇지는 않습니다. 키체인에 저장된 비밀번호에 아예 접근이 완전히 가능한 'Mojave 취약점' 등 다양한 제로데이 취약점에 노출되어 있습니다. 하지만 타 OS에 비해 크게 문제가 되지 않는 것은 마이크로소프트 윈도우즈나 유닉스 시스템을 기반으로 한 RHEL(Red Hat Enterprise Linux), CentOS와 달리 시장에서 많이 사용되지 않기 때문입니다.

​독이 되어버린 서버 시스템의 막대한 시장 점유율

실제 이번 사고의 영향이 이 정도로 컸던 데에는 서버 시스템에 대한 마이크로소프트의 막대한 시장 점유율이 영향을 줬기 때문입니. 거기다 최근들어 다양한 컴플라이언스 제약이 생기면서 기업들이 자체적인 서버를 구축하지 않고 Azure나 AWS 등 클라우드 시스템에 아웃소싱을 하면서 더욱 윈도우즈 제품군으로 집중되는 현상은 강해졌습니다. 

바스티안이 언급한 애플 제품군이 과거에는 그나마 경쟁이 될 수 있었으나, 클라우드 환경 변화와 더불어 제품 자체가 관공서나 기업에 납품하기 좋은 상태가 아니었기 때문에 사실상 도태된 지 오래라 의미가 없는 상황이 된 것도 독점이 심해지는 이유 중 하나인데요. 

애플의 GPL(General Public License) 라이선스에 대한 병적일 정도의 기피, 레거시 시스템을 인정하지 않는다고 불릴 정도로 하위 호환에 대한 불친절한 대처 등 사실상 서버 시장에선 사용할 수 없는 제품군으로 전락한지 오래가 되어버린거죠.

​중앙화 된 보안 시스템, 검증되지 않은 배포, 뒤늦은 대응의 복합적 문제

물론 현대 보안의 복잡한 인증을 이수하기 위한 컴플라이언스를 모두 달성하기 위해서는 복잡다단한 시스템 관리와 로그 수집, 중앙화 된 보안 제어와 통제, 관리 시스템이 필요합니다. 이를 달성하기 위해서는 어느 정도 커널에 보안 프로그램이 접근해야 할 필요가 있는 것 또한 사실이죠.

이런 상황에서 마이크로소프트가 하위호환을 유지하기 위해 적당한 수준에서 과도한 커널 접근을 정리하지 않은 것도 문제겠지만, 근본적으로는 크라우드스트라이크의 안이한 배포가 이번 사고를 낳은 1차적 책임이 있으며, 빠르게 대응을 하지 않고 시스템 관리를 아웃소싱에 맡긴것이 문제가 되지 않나 생각됩니다.

실제 크라우드스트라이크측에서 밝힌 바에 따르면 이번 사고의 원인은 매개변수가 원래 21개가 정의되어 있어야 하는데 입력되는 값이 20개였고, 테스트 과정에서는 와일드카드를 사용한 정책 검증을 했으나 이후 패치 과정에서 정책 검증 기준이 완전 일치로 바뀌면서 Array OOB(Out-Of-Bound)가 발생하면서 문제가 일어난 것이라고 하는데요. 

크라우드스트라이크는 팔콘 센서 컴파일 과정에서 매개변수를 검증하는 루틴을 넣고, 런타임 과정에서도 다시 한번 체크를 하는 루틴을 넣는 한편 정책 템플릿 개발에서 문제가 발생하지 않도록 하겠다는 등의 수정책을 발표했습니다.

​고도화된 시스템 이전에 보안 담당자의 관리의식 제고 필요

이런 문제가 발생하는 것을 막기 위해 많은 기업에서는 TDD(Test-Driven Development, 테스트 주도 개발)를 개발 방법론으로 도입하고 있습니다만, 시스템이 커지면서 테스트 과정이 점점 많아지면 어느 순간 기계적으로 주어진 테스트 시나리오만 충족하게 되면 배포하는 경우도 많습니다. 

실제로 메타나 오라클같은 경우 조그만 기능 하나 배포하기 위한 테스트 통과 과정만 자동화를 도입했음에도 며칠 이상 걸린다는 이야기도 있을 정도입니다. 이번 사고 역시 템플릿을 활용한 개발, 그리고 기계적으로 와일드 카드를 적용한 테스트, 그리고 테스트 과정에 대한 제대로 된 평가나 변화에 맞춘 테스트 시나리오의 변경/추적 없이 단순히 개발 테스트에 통과했다는 것 만을 근거로 배표를 했기에 이런 사건이 발생하게 된 거였죠.

전적으로 이번 사고는 크라우드스트라이크가 가장 큰 잘못을 저지른 것이 맞습니다. 마이크로소프트 역시 온전히 책임에서 피해갈 수는 없습니다. 하지만 델타에서 언급한 것처럼 델타는 순수한 피해자라고만 보기는 힘듭니다. 

오히려 이번 사고를 통해 기업 IT 시스템 관리에 대한 전체적인 관리 의식의 제고가 필요하다고 생각합니다. 시스템에 사고가 발생할때는 가장 취약한 부분에서, 사람이 지켜보고 있지 않을 때 발생합니다. 델타는 어떻게 보면 관리와 운영을 아웃소싱했던 것에 대한 뼈아픈 댓가를 치르고 있는 셈이겠죠.

​사람이 하는 일은 항상 문제가 생길 수 있습니다. 그것이 자동화된 일이고 정형화된 체계를 따른다 해도 문제는 어디선가 발생합니다. 이번 사고를 보면서 언제건 어디서건 문제와 사고가 일어날 수 있다는 것을 상정하고 충분한 조치가 가능하도록 인력과 자원을 대비해 두는 것 역시 시스템의 안정적 운영과 보안 관리를 위해 CEO와 CISO가 가질 가장 중요한 덕목이 아닐까 생각됩니다.

인텔렉추얼데이터는 기업의 중요 데이터를 취급하는 모든 과정에 걸쳐 보안 담당자의 정밀한 모니터링 및 관리 체계를 구축하고 있으며, 여러 단계에 걸친 보안 시스템을 기반으로 보다 안전한 eDiscovery를 진행하고 있습니다. 데이터 보안이 중요한 eDiscovery를 진행하신다면, 대한민국 eDiscovery의 절대적 기준, 인텔렉추얼데이터와 함께 하세요.