강은성의 보안 아키텍트ㅣ크라우드스트라이크, 보안SW, SW공급망 품질 관리

지난 7월 19일은 세계 IT 역사에 오명으로 기록될 만한 날이다. AWS에 이어 시장 점유율 세계 2위를 자랑하는 마이크로소프트(MS)의 클라우드 서비스 애저(Azure)의 일부가 중단되어, 애저를 기반으로 서비스를 제공하는 전 세계의 주요 항공, 여행, 통신, 병원 등의 서비스가 중단되는 등 상당한 피해가 발생했다.
 

세계적인 보안업체 크라우드스트라이크(CrowdStrike)의 EDR(Endpoint Detection and Response) 제품인 팔콘(Falcon)에서 발생한 오류로 전 세계 약 850만 대의 윈도 PC와 서버가 ‘공포의 블루스크린’(BSOD: Blue Screen of Death)이 발생한 것이 원인이었다.

팔콘 → 윈도 시스템(PC, 서버) → MS 애저 → 항공여행사 등 서비스 → 서비스 이용자로 이어지는 공급망을 타고 팔콘의 오류가 확산한 것이다. (애저나 팔콘의 국내 점유율이 높지 않아 국내 피해는 많지 않았다.)

블루스크린!
얼마 만에 들어본 단어인가!
아직도 블루스크린이 뜨게 만드는 소프트웨어가 있다니!! 그것도 세계적인 보안제품의 온라인 업데이트에서 말이다. 소프트웨어 패치가 대부분이 CD로 이뤄지던 20여 년 전에도 끊임없이 나타나는 악성코드에 대응하기 위해 안티바이러스제품에서는 하루에도 몇 번씩 온라인 업데이트를 통해 시그니처 파일(악성코드 DB)을 배포하였는데 말이다.

수백만 대의 기기에 블루스크린이 뜨는 끔찍한 상황이 발생하지 않도록 윈도OS의 온갖 버전에서 테스트하고, OS 파일과 주요 회사의 보안 소프트웨어 등을 대상으로 오진 테스트도 하였다. 보안 제품은 커널 레벨의 모듈이 있어서 블루스크린이 뜨지 않도록 하는 것은 보안 소프트웨어가 갖춰야 할 기본 요건이었다.

사고가 발생한 뒤 2주가 조금 지난 8월 6일, 크라우드스트라이크는 12쪽짜리 사고에 관한 근본 원인 분석 자료를 내놓았다. 회사의 설명을 종합하여 한 문장으로 요약하면 이렇다.
 

팔콘의 윈도용 소프트웨어인 ‘센서’의 구성 요소인 C-00000291*.sys라는 채널 파일(설정 파일)에는 악성코드에 대응하기 위한 코드(템플릿)가 포함되어 있는데, 업데이트된 템플릿에서는 20개의 항목이 있었으나, ‘센서’의 인터프리터에서는 템플릿으로부터 21번째 포인터 배열 입력을 읽으려다가 ‘Out of bounds memory access’가 발생하여 센서가 죽었고, PC도 함께 죽었다.

한 마디로 제품 스펙에 대해 팀 사이에 공유(협업)가 제대로 안 됐다는 얘기다. 일반적으로 품질관리팀에서 하는 경곗값이나 이상 데이터에 대한 테스트도 잘되지 않은 것 같다.

보안제품에서 이런 사고가 발생하면, ‘자동 업데이트’ 설정을 해 놓은 기업에서는 속수무책으로 당하게 된다. 공장 라인의 IT 기기에 악성코드 대응 소프트웨어를 설치한 일부 제조업체를 제외한 대다수 기업에서는 하루에도 수만 개씩 악성코드가 발생하고, 제로데이 공격도 나타나는 상황에 대응하기 위해 보안 업데이트가 나오면 즉시 적용하도록 ‘자동 업데이트’ 설정을 해 놓았다.

더욱이 관련 법규나 보안 관련 인증에서 이를 권고하거나 의무로 하기도 한다.
 

개인정보의 안전성 확보조치 기준 제9조(악성프로그램 등 방지) ① 개인정보처리자는 악성프로그램 등을 방지ㆍ치료할 수 있는 보안 프로그램을 설치ㆍ운영하여야 하며, 다음 각 호의 사항을 준수하여야 한다. 1. 프로그램의 자동 업데이트 기능을 사용하거나, 정당한 사유가 없는 한 일 1회 이상 업데이트를 실시하는 등 최신의 상태로 유지 (중략) ② 개인정보처리자는 악성프로그램 관련 경보가 발령된 경우 또는 사용 중인 응용 프로그램이나 운영체제 소프트웨어의 제작업체에서 보안 업데이트 공지가 있는 경우 정당한 사유가 없는 한 즉시 이에 따른 업데이트 등을 실시하여야 한다.

근본적으로 문제를 해결할 책임은 MS에 있지 않나 싶다. 윈도 운영체제의 BSOD는 윈도의 독특한 시스템 중단 방식이다. 윈도가 시스템을 지속하면 시스템이나 데이터에 심각한 손실이 발생한다고 판단했을 때 BSOD를 발생시킨다. 오류 코드를 보여주고, 메모리 덤프 파일을 생성하여 오류 수정에 도움을 주는 면도 있다.

특히 이번 사고처럼 소프트웨어에서 메모리 문제가 발생하면 해당 프로세스만 종료시키면 되는데, 시스템 전체가 종료되는 심각한 사고가, 윈도가 나름 안정된 운영체제로 인정받았던 윈도98이 나온 지 26년이 지난 지금까지 발생한다는 것은 운영체제에 문제가 있다고 볼 수밖에 없다. 지난해 MS가 윈도 운영체제를 메모리 안전성(Memory-safe)이 높은 러스트(Rust) 언어로 변환하고 있다는 발표가 있어서 좀 나아질 수 있을지도 모르겠다.

개발사 또한 관심을 기울여야 한다. 특히 안티바이러스나 EDR과 같은 엔드포인트 보안 제품의 업데이트는 자동 업데이트 설정을 타고 세계 수백만 대의 기기에 그대로 적용된다. 기술적인 난이도와 기술력 있는 인력 확보 등 여러 어려움이 있긴 하지만, SaaS(Software as a Service) 이전에도 연간 라이선스라는 다른 기업이 부러워하는 비즈니스 모델을 가진 만큼 개발 프로세스와 온라인 업데이트 체계의 보안성과 안정성을 빈틈없이 준비할 필요가 있다.

보안 소프트웨어 개발사에서는 가능하면 커널 모드를 적게 쓰는 방법을 연구하고, 시그니처 업데이트, 바이너리 업데이트, 커널 모드를 사용하는 소스 변경에 따른 업데이트 등 ‘업데이트 위험’을 평가하여 그에 대한 테스트와 업데이트에 신중을 기하는 방식을 고려해 볼 필요가 있을 것 같다. 역량 있는 보안팀이 활용할 수 있도록 이에 대한 옵션을 제공하는 것도 방법이 되지 않을까 싶다.

2021년 5월, 미국 바이든 행정부에서 행정명령(EO) 14028을 발표한 이후 소프트웨어 공급망 보안 강화는 전 세계적인 흐름이 되었다. 이번 사고는 보안 소프트웨어가 원인이지만, ‘공급망 보안’의 영역이라기보다는 ‘공급망 품질 관리’의 영역이라 볼 수 있다.

1980년대 초반에 ‘공급망 관리’라는 용어가 등장한 이후 40여 년이 지나 제조업에서 공급망 품질 관리는 경영에서 핵심적인 요소의 하나로 자리 잡은 지 오래다. 제품-부품 또는 원청-하청으로 (수직적으로) 엮여 있는 제조업의 공급망과는 다른 점도 있지만, 전 세계가 인터넷을 통해 실시간으로 엮여 있는 소프트웨어 공급망을 좀 더 심각하게 다루지 못한 게 아닐까 하는 우려도 하게 된다.

이번 사고를 계기로 소프트웨어 공급망 보안 못지않게 소프트웨어 공급망 품질 관리에 관심을 둬야 하지 않을까 한다.
 
* 강은성 교수는 국내 최대 보안기업의 연구소장과 인터넷 포털회사의 최고보안책임자(CSO)를 역임한 정보보호 및 개인정보보호 전문가다. 현재는 서울여자대학교 정보보호학과 조교수로 있다. 저서로 「IT시큐리티」(한울, 2009)와 「팀장부터 CEO까지 알아야 할 기업 정보보안 가이드」(한빛미디어, 2022) 등이 있다.
ciokr@idg.co.kr