제로데이 공격을 차단하십시오. 방어선을 구축할 때가 왔습니다.

이 기사의 한 버전이 SC 매거진에 게재되었습니다.에 게재되었습니다. 본지는 이를 수정하여 재게재합니다.


집에 도둑이 들었던 경험이 있다면, 무언가 이상하다는 초기 느낌과 이어서 실제로 물건이 도난당하고 피해가 발생했다는 사실을 깨닫는 과정을 이해하실 겁니다. 이는 지속적인 불만으로 이어지지만, 결국 포트 녹스 수준의 보안 조치 변경으로만 해결될 수 있습니다.

지금 상상해 보세요. 도둑들이 열쇠를 만들어 집안에 침입한 상황입니다. 그들은 마음대로 드나들며 숨어 다니지만, 발각되지 않도록 조심합니다. 그러다 어느 날, 냉동고에 숨겨둔 보석이 사라지고 금고가 털리며 개인 소지품이 약탈당한 것을 너무 늦게 깨닫게 됩니다. 이것이 바로 제로데이 사이버 공격을 제공하는 기업이 연루된 현실과 동등한 상황이다. 2020년 포네몬 연구소의 조사에 따르면, 성공한 개인정보 침해 사건의 80%가 제로데이 익스플로잇의 결과였으며, 안타깝게도 대부분의 기업은 이 통계를 크게 개선할 준비가 되어 있지 않다.

제로데이 공격은 정의상 개발자에게 기존 보안 취약점을 찾아 수정할 시간을 주지 않습니다. 위협 행위자가 먼저 침투했기 때문입니다. 피해는 가해진 후 엄청난 악영향을 미치며, 이는 소프트웨어 자체뿐만 아니라 기업의 평판 손상까지 포함합니다. 공격자는 항상 유리한 입장에 있으며, 이 우위를 최대한 좁히는 것이 결정적입니다.

아무도 원하지 않았던 크리스마스 선물 — Log4Shell — 이 현재 인터넷을 뒤흔들고 있습니다. 이 치명적인 자바 보안 취약점으로 약 10억 대의 기기가 영향을 받을 것으로 추정됩니다. 사상 최악의 제로데이 공격이 될 조짐을 보이고 있으며, 이제 막 시작 단계입니다. 공개 수일 전부터 악용이 시작됐다는 일부 보고가 있지만, 2016년 블랙햇 컨퍼런스 발표를 보면 이 문제가 오래전부터 알려져 있었을 가능성이 높습니다. 아이고. 더 심각한 건 악용이 놀라울 정도로 쉽다는 점으로, 지구상의 모든 스크립트 키디와 위협 행위자들이 이 취약점을 노리고 달려들고 있습니다.

그렇다면 미끄럽고 어두운 위협으로부터, 더 나아가 소프트웨어 개발 과정에서 간과된 보안 취약점으로부터 자신을 보호하는 최선의 방법은 무엇일까요? 함께 살펴보겠습니다.

대규모 표적을 겨냥한 제로데이 공격은 드물며(비용도 많이 듭니다)

다크 웹에는 악용 코드에 대한 거대한 시장이 존재하며, 제로데이 취약점은 일반적으로 상당한 금액에 거래됩니다. 예를 들어 , 이 기사가 작성된 시점 기준으로 한 제로데이 취약점이 250만 달러에 거래되고 있었습니다. 이것은 애플 iOS용 익스플로잇으로, 보안 연구원의 요구 가격이 천정부지로 치솟은 것은 놀랄 일이 아닙니다. 결국 이 취약점은 수백만 대의 기기를 해킹하고, 수십억 건의 민감한 데이터를 수집하며, 발견되고 패치되기 전까지 가능한 한 오랫동안 이를 지속할 수 있는 통로가 될 수 있기 때문입니다.

하지만 대체 누가 그렇게 많은 돈을 가지고 있겠는가? 일반적으로 조직화된 사이버 범죄 조직들은 특히 널리 퍼진 랜섬웨어 공격의 경우, 가치 있다고 판단되면 돈을 내놓고 넘어간다. 그러나 전 세계 정부와 국방 당국은 위협 정보 수집을 위해 악용 코드를 구매하는 고객에 속하며, 긍정적인 경우 기업들은 잠재적인 제로데이 취약점을 직접 확보해 재앙을 막을 수도 있습니다.

2021년에는 제로데이 취약점의 실시간 발견 기록이 경신되었으며, 가장 큰 위험에 노출된 대규모 조직, 정부 기관 및 인프라가 취약점 테스트를 받았습니다. 제로데이 공격을 완전히 차단할 방법은 없지만, 관대하고 체계적인 버그 바운티 프로그램을 제공함으로써 어느 정도 대응할 수 있습니다. 다크 웹 시장에서 소프트웨어 성의 열쇠를 아무에게나 제공하는 대신, 합법적인 보안 애호가들을 여러분의 페이지로 초대하고 윤리적인 공개 및 가능한 수정 사항에 대해 적절한 보상을 제공하십시오.

만약 제로데이 위협이 발생한다면, 아마존 기프트 카드를 한 장 이상 발행해야 할 것임을 예상할 수 있습니다(그리고 그렇게 하는 것이 가치 있을 것입니다).

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

기존 보안 도구는 오랫동안 문제였으며, 평균적인 CISO는 보안 무기고에서 55개에서 75개 사이의 도구를 관리합니다. 이것이 세상에서 가장 복잡한(비유적으로) 스위스 군용 칼이라는 점을 제쳐두더라도, 포네몬 연구소(Ponemon Institute)의 연구에 따르면 53%의 기업은 이 도구들이 효과적으로 작동한다고 확신하지 못합니다. 또 다른 연구에서는 CISO의 단 17%만이 자신들의 보안 스택이 "완전히 효과적"이라고 생각한다고 밝혔습니다.

보안 전문가들이 소진되는 현상, 수요를 충족시킬 보안 인력 부족, 민첩성 요구로 유명한 분야에서, 방대한 데이터, 보고서, 거대한 도구를 모니터링하는 도구들로 인한 정보 홍수 속에서 보안 전문가들에게 업무를 강요하는 것은 부담이 됩니다. 바로 이러한 시나리오가 치명적인 경고를 간과하게 만들 수 있으며, Log4j의 취약점을 제대로 분석하는 과정에서 실제로 그런 일이 발생했습니다.

예방적 보안은 개발자 중심의 위협 모델링을 포함해야 한다

개발자들은 코드 수준의 안전 취약점을 자주 활용하며, 안전한 프로그래밍 지식을 제공하기 위해 정확한 지침과 정기적인 학습 경로가 필요합니다. 차세대 안전 개발자들은 소프트웨어 개발 과정에서 학습하고 연습할 기회를 제공받아야 합니다.
‍
소프트웨어를 가장 잘 아는 사람들이 바로 그 소프트웨어를 설계하고 개발한 개발자들인 것은 당연한 일입니다. 그들은 사용자가 소프트웨어를 어떻게 다루는지, 기능이 어디에서 사용되는지, 그리고 충분히 보안 의식이 있다면 소프트웨어가 고장 나거나 악용될 수 있는 잠재적 시나리오에 대한 깊은 지식을 보유하고 있습니다.

Log4Shell 취약점으로 돌아가 보면, 전문가와 복잡한 도구 세트가 발견하지 못한 치명적인 보안 구멍이 존재하는 시나리오를 목격하게 됩니다. 그러나 해당 라이브러리가 사용자 입력을 요약하도록 구성되었다면 이러한 취약점은 아예 발생하지 않았을 수도 있습니다. 이 결정은 실용적인 이유로 인해 다소 생소한 기능으로 보였지만, 악용하기는 매우 쉬웠습니다(SQL 인젝션 수준을 생각해보세요, 결코 뛰어난 기술은 아닙니다). 열정적이고 보안 의식이 높은 개발자 그룹이 위협 모델링을 수행했다면, 이 시나리오는 이론적으로 고안되고 실제로 구현되었을 가능성이 매우 높습니다.

우수한 보안 프로그램은 인간이 초래한 문제 해결의 핵심에 인간의 개입과 미묘한 차이를 두는 감정적 요소를 지닙니다. 위협 모델링은 효과적이기 위해 공감과 경험이 필요하며, 소프트웨어 및 애플리케이션의 안전한 코딩과 구성 역시 아키텍처 수준에서 동일합니다. 개발자는 밤샘 작업을 강요받아서는 안 되며, 이 중요한 임무를 보안 팀에 맡길 수 있다는 점을 명확히 하는 것이 이상적입니다(이는 두 팀 간 협력 관계를 구축할 수 있는 훌륭한 기회이기도 합니다).

Nulltage는 N-Tagen으로 이어진다

제로데이 취약점이 발견된 후의 대응 과정은 패치를 최대한 신속하게 배포하는 것을 포함하며, 취약한 소프트웨어의 모든 사용자가 공급업체보다 먼저, 그리고 가능한 한 빨리 패치를 적용하기를 간절히 바라는 마음에서 이루어집니다. Log4Shell은 수백만 대의 장치에 내장되어 있으며 소프트웨어 빌드 내에서 복잡한 종속성을 생성한다는 점에서 그 지속성과 성능 면에서 Heartbleed를 능가할 수 있습니다.

현실적으로 볼 때, 이러한 종류의 은밀한 공격을 완전히 막을 방법은 없습니다. 그러나 우리가 고품질의 안전한 소프트웨어를 개발하기 위해 모든 가능성을 활용하고, 중요 인프라를 다룰 때와 동일한 사고방식으로 개발에 임한다면, 우리 모두 진정한 기회를 가질 수 있습니다.