이 글의 한 버전이 SC 매거진에 게재된 바 있습니다. 본문에 수정이 가해졌으며 공동 게재됩니다.
도둑이 집에 침입한 경험이 있다면, 처음에는 뭔가 이상하다는 막연한 불안감이 들다가 결국 자신이 실제로 도둑맞고 침해당했다는 사실을 깨닫는 그 순간을 이해할 수 있을 것입니다. 이는 대개 지속적인 불편감으로 이어지며, 노크스버그에 버금가는 보안 조치로 전환하는 것은 말할 것도 없습니다.
이제 도둑이 스스로 열쇠를 만들어 집을 침입하는 상황을 상상해 보십시오. 그들은 곳곳을 기어 다니며 마음대로 드나들지만, 발각되지 않도록 조심스럽게 행동합니다. 그러다 어느 날, 냉장고에 숨겨둔 보석이 사라지고 금고가 비워졌으며 개인 소지품이 훔쳐진 것을 발견하게 됩니다.이미 때는 늦었습니다. 이는 조직이 제로데이 공격의 피해자가 되었을 때 마주하는 현실과 같습니다. 2020년 포네몬 연구소의 연구에 따르면 성공적인 데이터 유출 사건의 80%가 패치되지 않은 취약점 악용으로 인한 것이었으며, 안타깝게도 대부분의 기업은 여전히 이 통계 수치를 크게 개선할 역량이 부족합니다.
말 그대로 제로데이 공격은 위협 행위자가 먼저 침투하기 때문에 개발자가 악용될 수 있는 기존 취약점을 발견하고 패치할 시간을 주지 않습니다. 피해는 이미 발생한 뒤에야 소프트웨어와 기업 평판 손실을 복구하기 위한 발빠른 대응이 이어집니다. 공격자는 항상 우위를 점하고 있으며, 이 우위를 최대한 축소하는 것이 중요합니다.
아무도 원하지 않는 크리스마스 선물인 Log4Shell이 현재 인터넷을 뒤흔들고 있으며, 이 치명적인 자바 취약점으로 인해 10억 대 이상의 기기가 영향을 받은 것으로 알려졌습니다. 이는 기록상 가장 심각한 제로데이 공격이 될 것이며, 이제 막 시작에 불과합니다. 일부 보도에 따르면 공개 전 며칠 전부터 악용이 시작되었지만, 2016년 블랙햇 컨퍼런스 발표 자료에 따르면 이 문제는 이미 오래전부터 알려진 상태였습니다. 아이고. 더 나쁜 점은 이 취약점이 악용하기 매우 쉽다는 것이며, 지구상의 모든 스크립트 키드니와 위협 행위자들이 이 결함을 이용해 이익을 챙기고 있다는 사실입니다.
그렇다면, 우스꽝스럽고 위험한 위협은 물론이고 소프트웨어 개발 과정에서 간과된 취약점들까지 막기 위한 최선의 방법은 무엇일까요? 살펴보겠습니다.
대규모 대상을 겨냥한 제로데이 공격은 드물며(비용도 많이 든다)
다크웹의 취약점 악용 시장은 거대하며, 제로데이 취약점은 종종 엄청난 금액이 오간다. 예를 들어 이 글에서 언급된 취약점은 작성 당시 250만 달러에 거래되었다. 보도에 따르면 이는 애플 iOS의 취약점으로, 보안 연구원들의 요구 가격이 높은 것도 당연하다. 결국 이는 수백만 대의 기기를 침투하고 수십억 건의 민감한 데이터 기록을 수집하며, 발견 및 패치되기 전까지 최대한 오래 공격을 지속할 수 있는 진입점이 될 수 있기 때문이다.
그러나 어쨌든, 누가 그런 돈을 가지고 있겠는가? 일반적으로 현금 가치가 있다고 판단되면 조직화된 사이버 범죄 집단이 현금을 요구하며, 특히 인기 있는 랜섬웨어 공격의 경우 더욱 그렇다. 그러나 전 세계 정부 및 국방 부서는 위협 정보에 활용될 수 있는 취약점의 고객층이며, 더 적극적인 경우 해당 기업들 스스로 잠재적인 미수리 취약점을 구매하여 재앙을 줄일 수도 있다.
2021년은 실시간으로 패치되지 않은 취약점 발견 기록을 경신했으며, 대규모 조직, 정부 기관 및 인프라가 취약점 조사 대상이 될 가능성이 가장 높았습니다. 제로데이 공격 가능성으로부터 완전히 벗어날 방법은 없지만, 관대하고 체계적인 취약점 보상 프로그램을 제공함으로써 "게임을 할" 수 있습니다. 누군가가 다크 웹 시장에서 소프트웨어 성의 열쇠를 내놓기를 기다리기보다는, 합법적인 보안 애호가들을 여러분 편으로 끌어들이고, 그들에게 윤리적 공개와 잠재적 수정에 대한 풍성한 보상을 제공하세요.
게다가, 만약 그것이 우연히 소름 끼치는 새로운 취약점 위협이라면, 아마존 기프트 카드 이상의 것이 필요할 뿐만 아니라(그리고 그렇게 할 가치가 있다)라고 단언할 수 있습니다.
당신의 도구는 보안 담당자의 책임일 수 있습니다
복잡한 보안 도구는 오랫동안 문제점으로 지적되어 왔으며, 일반적인 최고정보보안책임자(CISO)는 보안 무기고에서 55개에서 75개에 이르는 다양한 도구를 관리해야 합니다. 이는 세계에서 가장 복잡한(비유적으로) 스위스 군용 칼일 뿐만 아니라, 포네몬 연구소(Ponemon Institute)의 연구에 따르면 53%의 기업은 심지어 자신의 효율성을 확신하지 못한다고 합니다. 또 다른 연구에 따르면, CISO 중 단 17%만이 자신들의 보안 스택이 "완전히 효과적"이라고 평가했습니다.
피로가 극에 달하고, 수요를 충족시킬 안전 기술 인력이 부족하며, 유연성에 대한 요구가 높은 분야에서는 안전 전문가들이 데이터, 보고서, 대규모 도구 집합 모니터링 형태로 정보 과부하를 처리하도록 강요받는 것이 큰 부담이 됩니다. 바로 이러한 상황이 핵심 경보를 놓치게 할 수 있으며, Log4j 취약점을 정확히 평가할 때도 그러한 상황이 발생할 가능성이 높습니다.
예방적 보안에는 개발자 주도 위협 모델링이 포함되어야 합니다.
코드 수준의 취약점은 일반적으로 개발자가 도입하며, 안전한 코딩 기술을 함양하기 위해서는 정확한 지침과 정기적인 학습 경로가 필요합니다. 그러나 소프트웨어 생성 과정의 일부로서, 차세대 보안 개발자는 위협 모델링을 학습하고 연습할 기회를 갖게 됩니다.
소프트웨어를 가장 잘 아는 사람이 바로 그 소프트웨어를 만드는 개발자라는 것은 당연한 일입니다. 그들은 사용자가 어떻게 상호작용하는지, 기능이 어디에서 사용되는지, 언제 충분한 보안 의식을 가지는지, 그리고 잠재적으로 어떻게 파괴되거나 악용될 수 있는지에 대한 풍부한 지식을 보유하고 있습니다.
이 문제를 Log4Shell 취약점으로 되돌려 보면, 안타깝게도 전문가와 복잡한 도구 세트의 탐지를 피해 간 치명적인 취약점이 존재한다는 사실을 목격하게 됩니다.그러나 라이브러리를 사용자 입력에 대해 디스오염 처리하도록 구성했다면 이런 사태는 아예 발생하지 않았을 것입니다 . 편의성을 높이기 위해이를 거부한 결정은 사소해 보일 수 있지만,이는 매우 쉽게 악용될 수 있는 취약점입니다(SQL 인젝션 수준의 공격을 생각해보세요. 물론 천재적인 기술은 아닙니다). 위협 모델링이 예리하고 보안에 정통한 개발자 집단에 의해 수행되었다면, 이러한 시나리오는 이론적으로 고려되었을 가능성이 높습니다.
좋은 보안 계획에는 감정적 요소가 포함되며, 인적 개입과 미묘한 차이는 인적 문제를 해결하는 핵심입니다. 위협 모델링은 공감 능력과 경험이 있어야 효과적이며, 소프트웨어 및 애플리케이션 아키텍처 수준의 보안 코딩과 구성도 마찬가지입니다. 이는 개발자가 하룻밤 사이에 빠져들어야 할 난제가 아니지만, 그들의 기술을 향상시켜 보안 팀이 이 중요한 임무를 수행하는 데 드는 부담을 줄일 수 있는 명확한 방법입니다. 이는 이상적인 방식이며(두 팀 간의 우호적인 관계를 구축하는 좋은 방법이기도 합니다).
제로데이 공격으로 인해 n일 동안
보안 취약점이 패치되지 않은 상태에서 다음 단계는 가능한 한 빨리 패치를 배포하는 것입니다. 그는 취약한 소프트웨어의 모든 사용자가 공격자가 먼저 도달하기 전에 가능한 한 빨리 패치를 적용하기를 간절히 바랍니다. Log4Shell 의 경우, 수백만 대의 장치에 내장되어 있고 소프트웨어 버전 전반에 걸쳐 복잡한 종속성을 생성한다는 점에서 그 지속성과 영향력은 매우 강력하여 심지어 Heartbleed를 능가할 수도 있습니다.
사실, 이러한 교활한 공격을 완전히 막을 방법은 없습니다. 그러나 고품질의 안전한 소프트웨어를 만들기 위해 모든 수단을 동원하겠다는 약속을 하고, 핵심 인프라를 다루는 것과 동일한 마음가짐으로 개발에 임한다면 우리 모두는 이에 맞설 기회를 가질 수 있습니다.
