제로데이 공격이 증가하고 있습니다. 방어적 우위를 확보할 계획을 세울 때입니다.

이 기사의 한 버전이 Revista SC에 게재된 바 있습니다. 수정 후 본지에 배포되었습니다.


도둑이 집에 침입한 경험이 있다면, 무언가 잘못되었다는 초기의 침울한 느낌과 이어서 실제로 강도 피해를 입었다는 사실을 깨닫는 그 감정을 이해할 것입니다. 일반적으로 이는 지속적인 불쾌감으로 이어지며, 포트 녹스 수준의 보안 조치를 취하는 것은 말할 것도 없습니다.

이제 도둑들이 열쇠를 만들어 집을 침입했다고 상상해 보세요. 그들은 마음대로 드나들며 이리저리 돌아다니지만, 발각되지 않도록 조심합니다. 그러다 어느 날, 냉동실에 숨겨둔 보석이 사라지고 금고가 비었으며 개인 소지품이 털렸다는 사실을 너무 늦게 깨닫게 됩니다. 이것이 바로 제로데이 사이버 공격을 당한 조직이 마주하는 현실입니다. 2020년 포네몬 연구소 조사에 따르면 성공적인 데이터 유출 사건의 80%가 제로데이 공격으로 인한 것이었으며, 안타깝게도 대부분의 기업은 이 통계를 크게 개선할 준비가 여전히 부족합니다.

제로데이 공격은 정의상 개발자가 악용될 수 있는 기존 취약점을 찾아 수정할 시간을 주지 않습니다. 위협 행위자가 가장 먼저 침투했기 때문입니다. 피해는 이미 발생했으며, 이후 소프트웨어와 기업 평판에 가해진 손상을 복구하기 위한 작업이 시작됩니다. 공격자는 항상 우위를 점하고 있으며, 이 우위를 최대한 좁히는 것이 핵심입니다.

아무도 원하지 않았던 크리스마스 선물, Log4Shell이 현재 인터넷을 뒤흔들고 있으며, 이 치명적인 자바 취약점으로 인해 10억 대 이상의 기기가 영향을 받은 것으로 알려졌습니다. 이는 단 하루 만에 기록된 최악의 공격으로 부상하고 있으며, 이제 막 시작에 불과합니다. 일부 보고서에 따르면 이 취약점이 공개되기 며칠 전부터 악용이 시작됐다고 하지만, 2016년 블랙햇 컨퍼런스에서 발표된 내용에 따르면 이 문제는 이미 오래전부터 알려진 문제였습니다. 아이고. 더 나쁜 점은 이 취약점이 악용하기가 엄청나게 쉽다는 점이며, 전 세계의 모든 악성코드 작성자와 위협 행위자들이 이 취약점을 이용해 돈을 벌려고 하고 있습니다.

그렇다면, 소프트웨어 개발 과정에서 간과된 취약점은 물론이고, 교묘하고 미묘한 위협으로부터 자신을 방어하기 위한 최선의 방법은 무엇일까요? 함께 살펴보겠습니다.

중요 목표물에 대한 제로데이 공격은 드물고(비용이 많이 든다)

다크 웹에는 방대한 익스플로잇 시장이 존재하며, 제로데이 취약점은 보통 엄청난 금액에 거래됩니다. 예를 들어 이 기사 작성 시점 기준으로 해당 취약점은 250만 달러에 거래되고 있었습니다. 이 취약점은 애플 iOS 시스템의 문제로 알려져 있어, 보안 연구원이 엄청난 금액을 요구하는 것도 놀랍지 않습니다. 결국 이 취약점은 수백만 대의 기기를 해킹하고, 수십억 건의 기밀 데이터를 수집하며, 발견 및 수정되기 전까지 최대한 오랫동안 악용할 수 있는 진입점이 될 수 있기 때문입니다.

하지만 대체 누가 그런 거금을 가지고 있겠는가? 일반적으로 조직화된 사이버 범죄 집단들은 가치 있다고 판단되면 돈을 챙겨간다. 특히 점점 더 보편화되고 있는 랜섬웨어 공격의 경우 더욱 그렇다. 그러나 전 세계 정부와 국방부도 위협 정보를 얻기 위해 악용할 수 있는 익스플로잇의 고객층에 속하며, 더 긍정적인 시나리오에서는 기업들 스스로 잠재적인 제로데이 취약점을 사들여 재앙을 완화할 수 있습니다.

2021년에는 제로데이 취약점을 실시간으로 발견하는 기록이 경신되었으며, 대규모 조직, 정부 부처 및 인프라가 취약점을 탐지하기 위한 조사의 가장 큰 위험에 노출되어 있습니다. 제로데이 공격 가능성으로부터 완전히 안전할 방법은 없지만, 관대하고 체계적인 버그 보상 프로그램을 제공함으로써 어느 정도 '대응'할 수 있습니다. 다크 웹 시장에서 누군가가 소프트웨어 성의 열쇠를 건네주길 기다리기보다는, 합법적인 보안 개선점을 찾아내고 윤리적 공개 및 잠재적 해결책에 대해 적절한 보상을 제공하세요.

만약 그것이 소름 끼치는 제로데이 위협이라면, 아마존 기프트 카드 한 장 이상의 비용을 지출해야 할 것이 분명합니다(그리고 그럴 가치가 있을 것입니다).

귀사의 도구는 보안 담당자에게 부담이 될 수 있습니다

복잡한 보안 도구는 오랫동안 문제였으며, 평균적인 CISO는 보안 무기고에서 55~75개의 도구를 관리합니다. 세계에서 가장 혼란스러운 스위스 군용 칼(비유적으로)일 뿐만 아니라, 포네몬 연구소 조사에 따르면 53%의 기업은 이 도구들이 효과적으로 작동하는지조차 확신하지 못합니다. 또 다른 연구에 따르면 CISO 중 단 17%만이 자사 보안 시스템이 '완전히 효과적'이라고 생각했습니다.

보안 인력 부족과 민첩성 요구가 만연한 환경에서, 보안 전문가들이 방대한 데이터, 보고서, 도구 세트 모니터링으로 인한 정보 과부하 속에서 일하도록 강요하는 것은 부담이 됩니다. 바로 이러한 유형의 시나리오가 중요한 경고를 놓치게 할 수 있으며, Log4j 취약점을 적절히 평가하는 과정에서 그런 일이 발생했을 가능성이 높습니다.

예방적 보안은 개발자 주도 위협 모델을 포함해야 한다

개발자들은 코드 수준에서 취약점을 도입하는 경우가 많으며, 안전한 코딩 기술을 개발하기 위해서는 정확한 지침과 정기적인 학습 경로가 필요합니다. 그러나 고급 보안 시스템 개발자들은 소프트웨어 제작 과정의 일환으로 위협 모델링을 배우고 연습할 기회를 가져왔습니다.
‍
소프트웨어를 가장 잘 아는 사람들이 바로 그 소프트웨어를 직접 만들고 구현한 개발자들인 것은 당연한 일입니다. 그들은 사용자가 소프트웨어와 상호작용하는 방식, 기능이 사용되는 위치, 그리고 보안에 대한 인식이 충분히 높을 경우 실패하거나 악용될 수 있는 가능한 시나리오에 대해 깊이 이해하고 있습니다.

Log4Shell 취약점을 다시 언급하자면, 안타깝게도 전문가와 복잡한 도구 세트조차도 이 치명적인 취약점을 탐지하지 못한 상황에 직면해 있습니다. 그러나 해당 라이브러리가 사용자 입력을 소독하도록 설정되었다면 이 취약점은 아예 발생하지 않았을 수도 있습니다. 이를 하지 않기로 한 결정은 편의성을 위한 잘 알려지지 않은 기능으로 보이지만, 악용하기 매우 쉽게 만들었습니다(SQL 인젝션 수준을 생각해보세요, 확실히 좋은 것은 아닙니다). 위협 모델링이 열정적인 개발자 및 보안 전문가 그룹에 의해 수행되었다면, 이러한 시나리오가 이론화되고 고려되었을 가능성이 매우 높습니다.

좋은 보안 프로그램에는 감정적 요소가 포함되어 있으며, 인간이 만든 문제를 해결하기 위해서는 인간의 개입과 미묘한 차이가 핵심적입니다. 위협 모델링은 효과적이기 위해 공감과 경험이 필요하며, 소프트웨어와 애플리케이션의 아키텍처 수준에서 안전한 코딩 및 구성이 마찬가지로 중요합니다. 개발자들이 하룻밤 사이에 뛰어들어야 할 일은 아니지만, 이상적으로는 보안 팀이 이 중요한 업무를 수행하는 부담을 덜어줄 수 있을 만큼 역량을 향상시키는 명확한 경로를 찾는 것이 좋습니다(이는 두 팀 간의 좋은 관계를 구축하는 훌륭한 방법이기도 합니다).

제로일은 n일로 이어진다

제로데이 공격에 대응하기 위한 다음 단계는 패치를 최대한 신속하게 배포하는 것입니다. 취약한 소프트웨어를 사용하는 모든 사용자가 가능한 한 빨리, 그리고 무엇보다도 공격자가 먼저 도달하기 전에 패치를 적용하기를 바라는 마음에서입니다. Log4Shell의 경우, 수백만 대의 장치에 내장되어 있으며 소프트웨어 빌드에 복잡한 종속성을 생성한다는 점에서 그 지속성과 영향력 측면에서 Heartbleed를 능가할 수 있습니다.

현실적으로, 이런 교묘한 공격을 완전히 막을 방법은 없습니다. 그러나 안전한 고품질 소프트웨어를 만들기 위해 가능한 모든 방법을 동원하고, 핵심 인프라를 다룰 때와 동일한 마음가짐으로 개발에 임한다면 우리 모두는 맞서 싸울 기회를 가질 수 있습니다.