제로데이 공격이 증가하고 있습니다. 이제 방어 체계를 구축할 때입니다.

이 기사의 일부는 SC Magazine에 게재되었습니다. 본 내용은 수정 및 편집되어 이곳에 게시되었습니다.


집에 도둑이 든 경험이 있다면, 무언가 잘못되었다는 불길한 예감과 실제로 도둑을 맞았고 침해당했다는 사실을 깨달았을 때의 그 참담한 기분을 이해하실 겁니다. 이는 보통 지속적인 불안감을 남기며, 포트 녹스(Fort Knox)에 버금가는 보안 조치를 강구하게 만드는 계기가 됩니다.

이제 도둑이 직접 열쇠를 만들어 당신의 집에 침입했다고 상상해 보세요. 그들은 들키지 않도록 조심하며 마음대로 드나듭니다. 그러다 어느 날, 냉동실에 숨겨둔 보석이 사라지고 금고가 비었으며 개인 소지품이 엉망이 된 것을 뒤늦게 발견합니다. 이것이 바로 제로데이 사이버 공격을 당한 조직이 직면하는 현실입니다. 2020년 포네몬 연구소(Ponemon Institute)의 연구에 따르면 성공적인 데이터 침해 사고의 80%가 제로데이 취약점 공격으로 인한 것이었으며, 안타깝게도 대부분의 기업은 이러한 통계를 유의미하게 개선할 준비가 되어 있지 않습니다.

제로데이 공격은 정의상 공격자가 먼저 침투하기 때문에 개발자가 기존 취약점을 발견하고 패치할 시간을 전혀 주지 않습니다. 이미 피해가 발생한 후에는 소프트웨어 복구와 기업의 평판 회복을 위해 허둥지둥 대응할 수밖에 없습니다. 공격자는 항상 유리한 위치에 있으며, 이러한 격차를 최대한 줄이는 것이 무엇보다 중요합니다.

아무도 원치 않았던 연말 선물인 'Log4Shell'이 현재 인터넷을 강타하고 있으며, 10억 개 이상의 기기가 이 치명적인 자바(Java) 취약점의 영향을 받는 것으로 알려졌습니다. 이는 기록상 최악의 제로데이 공격으로 기록될 전망이며, 이제 막 시작 단계일 뿐입니다. 일부 보도에 따르면 공개 전부터 공격이 시작되었다고 하지만, 2016년 블랙햇 컨퍼런스(Black Hat Conference)에서 발표된 내용을 보면 이 문제는 이미 오래전부터 알려져 있었던 것으로 보입니다. 뼈아픈 일이죠. 더 심각한 것은 공격하기가 너무나 쉽다는 점이며, 전 세계의 모든 스크립트 키디와 공격자들이 이 취약점으로 한몫 챙기려 혈안이 되어 있습니다.

그렇다면 소프트웨어 개발 과정에서 놓친 취약점은 물론, 교묘하고 악랄한 위협을 방어하기 위한 최선의 방법은 무엇일까요? 함께 살펴보겠습니다.

대형 타겟을 노리는 제로데이 공격은 드물며 비용도 많이 듭니다

다크웹에는 취약점 거래 시장이 거대하게 형성되어 있으며, 제로데이는 매우 비싼 가격에 거래됩니다. 이 기사에 소개된 한 사례는 작성 시점 기준으로 250만 달러에 달했습니다. 애플 iOS의 취약점으로 알려진 이 사례에서 보안 연구원이 요구한 금액이 천문학적인 것은 놀라운 일이 아닙니다. 결국 이는 수백만 대의 기기를 감염시키고 수십억 개의 민감한 데이터 기록을 탈취할 수 있는 통로가 될 수 있으며, 발견되어 패치되기 전까지 최대한 오랫동안 그 기능을 수행할 수 있기 때문입니다.

그런데 도대체 누가 그런 거액을 지불할까요? 일반적으로 조직화된 사이버 범죄 조직은 가치가 있다고 판단되면, 특히 인기 있는 랜섬웨어 공격을 위해 자금을 마련합니다. 하지만 전 세계 정부와 국방 부처도 위협 인텔리전스를 위해 이러한 취약점을 구매하는 고객이며, 더 긍정적인 시나리오에서는 기업 스스로가 잠재적인 제로데이 취약점을 구매하여 재난을 예방하기도 합니다.

2021년은 실제 제로데이 취약점 발견 건수에서 기록을 경신했으며

만약 그것이 등골이 오싹해지는 제로데이 위협이라면, 아마존 기프트 카드 이상의 보상을 준비해야 할 것입니다(그만한 가치가 충분히 있을 것입니다).

보안 도구가 오히려 보안 담당자에게 짐이 될 수 있습니다

복잡한 보안 도구는 오랫동안 문제였으며, 평균적인 CISO는 보안 무기고에 55개에서 75개 사이의 도구를 관리하고 있습니다. 포네몬 연구소의 연구에 따르면, 세상에서 가장 혼란스러운(비유적인 의미의) 맥가이버 칼과 같을 뿐만 아니라, 기업의 53%는 자신들이 효과적으로 운영되고 있는지조차 확신하지 못하고 있습니다. 또 다른 연구에서는 CISO의 17%만이 자신의 보안 스택이 "완벽하게 효과적"이라고 생각하는 것으로 나타났습니다.

번아웃, 보안 전문 인력 부족, 민첩성 요구로 유명한 이 분야에서 보안 전문가들에게 방대한 도구 세트의 데이터, 보고, 모니터링이라는 정보 과부하를 강요하는 것은 큰 부담입니다. 이는 바로 그들이 중요한 경고를 놓치게 만드는 시나리오이며, Log4j의 취약점을 제대로 평가할 때도 그랬을 가능성이 큽니다.

예방적 보안에는 개발자 주도의 위협 모델링이 포함되어야 합니다

코드 수준의 취약점은 종종 개발자에 의해 도입되므로, 안전한 코딩 기술을 구축하기 위해서는 정밀한 가이드와 정기적인 학습 경로가 필요합니다. 하지만 한 단계 더 나아간 보안 개발자들은 소프트웨어 제작 과정의 일부로 위협 모델링을 배우고 실습할 기회를 얻었습니다.
‍
자신이 만든 소프트웨어를 가장 잘 아는 사람은 바로 그 소프트웨어를 직접 만든 개발자라는 사실은 놀라운 일이 아닙니다. 그들은 사용자가 소프트웨어와 어떻게 상호작용하는지, 기능이 어디에 사용되는지, 그리고 보안 인식이 충분하다면 소프트웨어가 어디서 고장 나거나 악용될 수 있는지에 대한 강력한 지식을 가지고 있습니다.

Log4Shell 취약점으로 다시 돌아가 보면, 안타깝게도 전문가와 복잡한 도구 세트가 감지하지 못한 치명적인 취약점이 발생한 시나리오를 보고 있습니다. 하지만 만약 해당 라이브러리가 사용자 입력을 정화하도록 구성되었다면 이런 일은 아예 일어나지 않았을지도 모릅니다. 그렇게 하지 않기로 한 결정은 편의성을 높이기 위한 모호한 기능이었던 것으로 보이지만, 결과적으로는 SQL 인젝션 수준으로 공격하기 매우 쉽게 만들었습니다(결코 천재적인 수준의 공격은 아니었습니다). 만약 보안 지식이 풍부한 개발자 그룹이 위협 모델링을 수행했다면, 이 시나리오는 충분히 예측되고 고려되었을 가능성이 높습니다.

훌륭한 보안 프로그램에는 인간이 만든 문제를 해결하는 핵심인 인간의 개입과 미묘한 차이를 다루는 감성적인 요소가 있습니다. 위협 모델링이 효과적이려면 공감 능력과 경험이 필요하며, 소프트웨어 및 애플리케이션의 아키텍처 수준에서의 보안 코딩과 구성도 마찬가지입니다. 이는 개발자들에게 갑자기 떠맡겨야 할 일이 아니라, 보안 팀의 부담을 덜어줄 수 있는 수준까지 역량을 강화할 수 있는 명확한 경로를 제공하는 것이 이상적입니다(이는 두 팀 간의 유대감을 쌓는 좋은 방법이기도 합니다).

제로데이는 n-데이로 이어집니다

제로데이 취약점에 대응하는 다음 단계는 가능한 한 빨리 패치를 배포하는 것입니다. 취약한 소프트웨어를 사용하는 모든 사용자가 공격자보다 한발 앞서 즉시 패치를 적용하기만을 바랄 뿐이죠. Log4Shell의 경우, Heartbleed 사태를 능가할 수도 있습니다. 수백만 대의 기기에 내장되어 있고 소프트웨어 빌드 전반에 걸쳐 복잡한 의존성을 형성하고 있기 때문에 그 영향력과 지속성은 매우 강력합니다.

현실적으로 이러한 교묘한 공격을 완전히 막을 방법은 없습니다. 하지만 양질의 안전한 소프트웨어를 만들기 위해 모든 수단을 동원하고, 핵심 인프라를 구축한다는 마음가짐으로 개발에 임한다면 우리 모두 충분히 대응할 수 있을 것입니다.