제로데이 공격이 증가하고 있습니다. 방어 전략을 세워야 할 때입니다.

이 기사의 한 버전이 에 게재되었습니다. SC 매거진.여기에서 수정 및 신디케이트되었습니다.


도둑이 집에 침입한 적이 있다면 처음에는 무언가 잘못되었다는 느낌을 이해하게 될 것입니다. 그리고 나서 실제로 도난당하고 침해를 당했다는 사실을 깨닫게 될 것입니다.이로 인해 대개 불편함이 오래 지속되며, 포트 녹스에 필적하는 보안 조치로 전환되는 것은 말할 것도 없습니다.

도둑들이 스스로를 열쇠로 삼았기 때문에 집이 뚫렸다고 상상해 보세요. 그들은 마음대로 이리저리 기어다니며 오고 가지만 들키지 않도록 조심합니다. 그러던 어느 날, 냉동실에 숨겨둔 장신구가 사라지고, 금고가 비워지고, 개인 소지품이 샅샅이 뒤졌음을 너무 늦게 알게 됩니다. 이는 제로데이 사이버 공격의 피해자가 될 경우 조직이 직면하는 현실과 동일합니다. 2020년 포네몬 연구소의 연구에 따르면 성공적인 데이터 침해의 80%가 제로데이 익스플로잇의 결과였으며, 안타깝게도 대부분의 기업은 이 통계를 크게 개선할 준비가 되어 있지 않습니다.

정의에 따르면 제로데이 공격은 위협 행위자가 먼저 침입하기 때문에 개발자가 악용될 수 있는 기존 취약점을 찾아 패치할 시간을 전혀 주지 않습니다. 피해를 입은 다음에는 소프트웨어와 비즈니스에 미치는 평판 훼손 모두를 해결하기 위한 광란의 난타전이 벌어집니다. 공격자는 항상 우위를 점하기 때문에 최대한 우위를 점하는 것이 중요합니다.

아무도 원하지 않았던 명절 선물인 Log4Shell은 현재 인터넷을 뜨겁게 달구고 있습니다. 10억 개 이상의 장치가 이 치명적인 Java 취약점의 영향을 받았다고 합니다. 이는 기록상 최악의 0일 공격이 될 것으로 예상되며, 이제 시작에 불과합니다. 그럼에도 불구하고 일부 보고서는 익스플로잇이 공개되기 며칠 전에 시작되었다고 진술하고 있으며, 2016년 블랙햇 컨퍼런스에서 열린 프레젠테이션은 이 문제가 한동안 알려져 있었음을 시사합니다. 설상가상으로, 악용하기 매우 쉬워 지구상의 모든 스크립트 키디와 위협 행위자들이 이 취약점을 이용해 페이더트를 추적하고 있습니다.

그렇다면 소프트웨어 개발 프로세스에서 놓친 취약점은 말할 것도 없고, 미끄럽고 사악한 위협으로부터 방어하기 위한 최선의 방법은 무엇일까요? 한 번 살펴보겠습니다.

대형 표적에 대한 제로데이 공격은 드물고 비용도 많이 듭니다.

다크 웹에는 거대한 익스플로잇 시장이 존재합니다. 한 가지 예를 들자면 제로데이는 상당히 많은 돈을 벌어들이는 경향이 있습니다. 이 글 작성 시점에 250만 달러에 거래되고 있습니다. 애플 iOS를 악용한 것으로 알려졌는데, 보안 연구원의 요구 가격이 천정부지로 오른 것은 놀라운 일이 아닙니다. 결국 이는 수백만 대의 기기를 손상시키고 수십억 개의 민감한 데이터 기록을 수집하며 발견 및 패치가 적용되기 전까지 가능한 한 오랫동안 그렇게 할 수 있는 관문이 될 수 있습니다.

어쨌든 누가 그런 돈을 가지고 있겠는가? 일반적으로 조직화된 사이버 범죄 조직은 가치가 있다고 판단되면 현금을 마련한다. 특히 항상 인기 있는 랜섬웨어 공격의 경우에는 더욱 그렇다. 하지만 글로벌 정부와 국방부는 위협 인텔리전스에 사용할 수 있는 익스플로잇의 고객으로 꼽히고 있으며, 좀 더 긍정적인 시나리오에서는 기업 자체가 잠재적인 제로데이 익스플로잇을 구매하여 재해를 완화할 수도 있다.

2021년에는 기록이 깨졌습니다. 실시간 제로데이 익스플로잇 발견의 경우 취약점이 발견될 위험이 가장 큰 것은 대규모 조직, 정부 부처 및 인프라입니다. 제로데이 공격의 가능성으로부터 완전히 안전할 수 있는 방법은 없지만, 넉넉하고 체계적인 버그 바운티 프로그램을 제공하면 어느 정도 "게임"을 할 수 있습니다.다크 웹 마켓플레이스에서 누군가가 소프트웨어 성의 열쇠를 제공할 때까지 기다리지 말고, 합법적인 보안 전문가를 확보하고 윤리적 정보 공개와 잠재적 수정 사항에 대해 적절한 보상을 제공하십시오.

제로데이 위협이 너무 심할 경우 아마존 기프트 카드보다 더 많은 돈을 써야 한다고 가정하는 것이 안전합니다 (그리고 그렇게 하는 데 그만한 가치가 있을 것입니다).

툴링은 보안 담당자의 책임일 수 있습니다.

일반적인 CISO가 관리하는 번거로운 보안 툴링은 오랫동안 문제가 되어 왔습니다. 55개에서 75개에 이르는 다양한 도구를 그들의 보안 무기고에 보유한 기업 중 53%는 자신들이 효과적으로 일하고 있다는 확신조차 하지 못합니다. 포네몬 연구소(Ponemon Institute) 의 연구에 따르면, 또 다른 연구에서는 CISO의 17%만이 자신의 보안 스택이 "완전히 효과적"이라고 생각하는 것으로 나타났습니다.

번아웃, 수요를 충족할 보안 전문 인력의 부족, 민첩성에 대한 요구로 잘 알려진 이 분야에서 보안 전문가가 방대한 도구 집합에 대한 데이터, 보고 및 모니터링의 형태로 정보 과부하를 처리하도록 강요하는 것은 부담스러운 일입니다. Log4j의 약점을 제대로 평가했을 때 중요한 경고를 놓칠 수 있는 시나리오가 바로 이런 시나리오입니다.

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

코드 수준의 취약점은 개발자가 도입하는 경우가 많으며, 보안 코딩 기술을 구축하려면 정확한 지침과 정기적인 학습 경로가 필요합니다. 하지만 보안 수준이 한 단계 높은 개발자에게는 소프트웨어 개발 프로세스의 일부로 위협 모델링을 배우고 실습할 수 있는 기회가 주어졌습니다.

자신의 소프트웨어를 가장 잘 아는 사람들이 그곳에 앉아 있는 것은 놀라운 일이 아닙니다. 바로 소프트웨어를 만든 개발자들입니다. 이들은 사용자가 소프트웨어와 상호작용하는 방식, 기능이 사용되는 위치, 보안에 충분히 주의를 기울이지 않을 경우 소프트웨어가 손상되거나 악용될 수 있는 잠재적 시나리오에 대한 강력한 지식을 보유하고 있습니다.

이 문제를 Log4Shell 익스플로잇으로 되돌리면 안타깝게도 치명적인 취약점이 전문가와 복잡한 도구 집합에 의한 탐지를 피할 수 있는 시나리오가 나타납니다. 하지만 라이브러리가 사용자 입력을 삭제하도록 구성된 경우에는 전혀 발생하지 않았을 수 있습니다. 그렇게 하지 않기로 한 결정은 추가 편의를 위한 애매한 기능이었던 것 같습니다. 하지만 악용하기가 매우 쉬워졌습니다 (SQL 인젝션 수준을 생각해 보세요. 천재적인 것은 아닙니다). 예리하고 보안에 정통한 개발자 그룹이 위협 모델링을 수행했다면 이 시나리오를 이론화하고 고려했을 가능성이 큽니다.

우수한 보안 프로그램에는 인간이 야기한 문제를 해결하는 데 있어 인간의 개입과 미묘한 차이가 핵심인 감정적 요소가 있습니다. 위협 모델링이 효과적이려면 공감과 경험이 필요하며, 소프트웨어 및 애플리케이션의 아키텍처 수준에서의 보안 코딩 및 구성도 마찬가지입니다. 개발자들이 하룻밤 사이에 이런 일에 몰두할 필요는 없지만, 이 중요한 작업에 대한 보안 팀의 압박을 덜 수 있는 수준까지 기술을 업그레이드할 수 있는 명확한 경로가 있으면 이상적입니다 (그리고 양 팀 간의 관계를 구축할 수 있는 좋은 방법이기도 합니다).

0일이 n일로 이어집니다

제로데이 대응의 다음 단계는 가능한 한 빨리 패치를 배포하는 것입니다. 취약한 소프트웨어의 모든 사용자가 가능한 한 빨리, 그리고 확실히 공격자가 먼저 도착하기 전에 패치를 적용하기를 바랍니다. Log4Shell은 수백만 개의 장치에 내장되어 있고 소프트웨어 빌드 전반에 걸쳐 복잡한 종속성을 생성한다는 점에서 내구성과 효능이 뛰어나, 하트블리드를 능가할지도 모릅니다.

현실적으로 이러한 유형의 교활한 공격을 완전히 막을 방법은 없습니다. 하지만 모든 수단을 동원해 품질이 우수하고 안전한 소프트웨어를 만들고, 중요 인프라와 같은 사고방식으로 개발에 접근하겠다는 약속이 있다면 우리 모두가 싸울 기회를 잡을 수 있습니다.