브루스 슈나이어(Bruce Schneier)
누군가의 컴퓨터를 컨트롤하기 위한 일반적인 방법은 그 컴퓨터의 소프트웨어 프로그램의 취약성을 익스플로이트 하는 것이다. 취약성은 소프트웨어의 실수, 즉 명세와 설계에서의 실수이며, 특히 프로그래밍에서의 실수다. 그 어떠한 대형 패키지라도 수천 개의 실수를 갖기 마련이다.
이러한 취약성들은 우리의 소프트웨어 시스템 내에 잠복한 채 발견되기를 기다리고 있다. 발견되면 그들은 시스템을 공격하는데 사용된다. 그러나 많은 시스템들은 패치되지 않았으며 따라서 인터넷은 알려진, 익스플로이트 가능한 취약성으로 가득 차 있다.
새로운 취약성들은 아주 매력적인 상품이다. 그 중 하나를 발견한 어떤 해커가 그것을 암시장에서 팔수도 있고 폭로하겠다며 업체를 협박할 수도 있으며, 혹은 결과를 생각하지 않고 그것을 단순히 공개해버릴 수도 있다. 설사 그 해커가 이 중 어떤 일도 하지 않는다 할지라도 취약성이 누군가에게 알려졌다는 사실만으로도 그 소프트웨어의 사용자들 모두에 대한 위험이 증가한다. 그렇다면 새로운 취약성을 연구하는 것은 도덕적일까?
분명하게 말하자면 그렇다. 여러 위험에도 불구하고 취약성 연구는 굉장히 가치 있는 일이다. 보안은 마음가짐이며 취약성을 찾는 것은 그 마음가짐을 자라나게 하는 것이다. 실무자들이 이러한 필수적인 학습 도구를 부인하면 보안은 자연히 고통을 겪기 마련이다.
보안 엔지니어들은 다른 엔지니어와는 다르게 세상을 바라본다. 시스템이 작동하는 방식에 초점을 맞추는 대신 어떻게 시스템이 실패하고 어떻게 실패하도록 만들어질 수 있으며, 또 어떻게 이러한 결점을 방지 또는 보호할 수 있는지에 초점을 맞춘다. 대부분의 소프트웨어 취약성은 정상적인 운영에서는 결코 나타나지 않으며 오직 공격자가 그것을 고의적으로 익스플로이트 할 때 나타난다. 그러므로 보안 엔지니어들은 공격자처럼 생각할 필요가 있다.
이러한 마음가짐은 가르치기 어렵다. 타고나는 것인지도 모른다. 그러나 이러한 마음가짐을 갖도록 훈련하기 위해 사람들은 보안 취약성을 지속적으로 반복해서 검색하고 발견할 필요가 있다. 분야에 상관없이 이것은 사실이다.
훌륭한 암호사용자는 다른 이들의 알고리즘과 프로토콜에서 취약성을 찾아낸다. 훌륭한 소프트웨어 보안 전문가는 다른 이들의 코드에서 취약성을 찾아낸다. 훌륭한 공항 보안 설계자는 공항 보안을 전복시키기 위한 새로운 방법들을 찾아낸다.
누군가 나에게 내가 모르는 사람의 보안 설계를 보여줄 때 제일 먼저 “이 설계자가 어떤 것을 공격해봤지?”라고 묻는 것이 매우 중요하다. 누구나 자신이 깰 수 없는 시스템을 설계할 수 있다. 그러므로 누군가 “여기 내 보안 시스템이 있다. 난 이것을 깰 수 없다”라고 말한다면 우리의 첫 번째 반응은 “당신은 누구인가?”가 되어야만 한다. 만일 그 사람이 수십 개의 비슷한 시스템을 공격해 본 경험이 있는 사람이라면 그의 시스템은 살펴볼 가치가 있다. 그러나 그가 아무것도 공격해보지 않았다면 그의 시스템이 좋은 것일 가능성은 제로다.
취약성 연구는 필수적이다. 그것이 다음 세대의 컴퓨터 보안 전문가들을 훈련시키기 때문이다. 그렇다. 소프트웨어와 공항 등에서 새롭게 발견된 취약성들은 우리를 위험에 몰아넣지만, 그러나 그것은 동시에 우리에게 보안이 실제로 얼마나 훌륭한지에 관해 좀 더 현실적인 정보를 준다.
또한 새로운 취약성을 처리하기 위한 크고 작은 책임이 있는-좀 더, 혹은 덜 합법적인- 방법들이 있는 것도 사실이다. 그러나 나쁜 사람들은 지속적으로 새로운 취약성을 찾고 있고 만일 우리의 시스템을 보호하는데 어떠한 희망도 존재하지 않는다면 우리는 적어도 대응할 수 있는 좋은 사람들이 필요하다.
내 의문은 취약성을 연구하는 것의 도덕성 여부에 관한 것이 아니다. 만일 누군가 문제를 분석하고 더 나은 통찰력을 제공할 수 있는 기술을 갖고 있다면, 그에게 취약성 연구를 하지 않도록 하는 것이 도덕적인가 하는 것이 의문일 뿐이다.
마커스 랜엄(Marcus Ranum)
브루스 슈나이어는 취약성을 조사하고 드러내는 것이 소프트웨어의 질을 향상시키는데 도움이 될 것이라고 주장했지만 그런 일은 결코 없었다. 지난 20년간의 소프트웨어 개발(제발 “엔지니어링”이라고 부르지 말라!)이 그러한 견해를 완전히 반박하고 있다.
여전히 버퍼 오버플로우가 존재할 뿐만 아니라 결과적으로 근절된 취약성이란 존재하지 않는다. 그것이 바로 취약성 “연구”를 제안한 사람이 기본적으로 실수하고 있는 부분이다. 만일 당신이 무언가를 향상시키고 싶다면 개별적인 사건이 아니라 문제의 카테고리에 대한 해결책을 찾을 필요가 있다.
일반적으로 취약성 “연구”는 “업체들에서 강탈하다시피 한 ‘감사 편지’와 취약성 시장으로부터의 현금 포상금으로 15초간 명예를 누리기 위해 소프트웨어의 중요한 부분에서 버그를 하나 더 찾는” 상황으로 고착되어있다. 이것은 “연구”가 아니다. 그저 평범한 “조사”일 뿐이다.
취약성 게임의 경제학은 “더 나은 소프트웨어 만들기”라는 옵션을 포함하고 있지 않다. 하지만 “더 비싼 소프트웨어 만들기”는 포함하고 있다. 내가 소프트웨어 비즈니스에서 출발했을 때만해도 10%의 연간 유지비도 엄청난 것으로 여겨졌다. 그러나 현재 기업들은 20%, 혹은 25%를 써야하는 상황이다.
왜? 취약성 게임이 업체들에게 고객들을 묶어놓는 새로운 환상적인 방법을 주었기 때문이다. 만일 당신이 유지 구매를 중단하고 업그레이드라는 다람쥐 쳇바퀴에서 내려온다면 구식이 되어가고 있는 당신의 소프트웨어는 6개월 내에 어떤 해킹 로봇에 의해 구멍이 뚫릴 것이라고 장담할 수 있다.
브루스 슈나이어와 내가 동의하는 부분은 어떤 것을 실패 내성이 있는 것으로 설계하기 위해서는 실패 모드의 관점에서 생각할 필요가 있다는 이론이다. 즉, 브루스의 말처럼 “공격자처럼 생각하라”는 것이다. 그러나 사실 이것은 실패 모드를 이해하는 것에 관한 문제다. 그것이 해킹 공격에 의한 에러든, 또는 단순히 서툰 사용자에 의한 것이든 소프트웨어는 수정할 수 있어야만 한다. 입력을 체크하고 안전하게 실패하며 사용자들이 설명서를 읽어볼 것이라고 기대하지 않는 것, 그것이 바로 프로그래밍의 1단계다.
에러의 새로운 카테고리들은 거의 함께 나타나지 않는다. 내가 기억하는 최근의 것은 공용 키 옹호자들에 대한 CPU/타이밍 공격에 관한 폴 코처(Paul Kocher)의 논문이다. 그가 1996년에 그것을 발표했을 때 암호 작성 커뮤니티는 걱정꺼리 리스트에 문제의 카테고리를 추가하고 움직이기 시작했다.
왜 소프트웨어 개발은 그와 유사하게 반응하지 않는 것인가? 예를 들어 마이크로소프트사와 같은 소프트웨어 대기업은 버퍼 오버플로우를 하나의 카테고리로 해결하려고 노력하기보다 코드의 개별적인 버퍼 오버플로우를 근절하기 위해 그것을 추적하려고 노력하며 수백만 달러를 쓰고 있다.
취약성 게임에 관해 사람들이 저지르는 가장 큰 실수는 ‘문제를 드러내는 것이 도움이 될 것’이라는 이데올로기에 현혹되는 것이다. 나는 그저 웹 2.0을 예로 드는 것만으로도 그것이 왜 틀린 생각인지를 입증할 수 있다.
웹 2.0 설계시 우리가 지난 20년간 소프트웨어를 작성하면서 배워왔던 것이 표출되었던가? 전혀 그렇지 않았다! 이것은 ‘설계’라고 부를 수도 없다. 만일 취약성 때문에 발생할 수 있는 일을 공개하는 것이 어떤 식으로든 소프트웨어 개발자들로 하여금 프로그래밍에 좀 더 주의하도록 압박했다면 웹 2.0은 나타나지 않았을 것이다.
만일 우리가 정말로 소프트웨어를 좀 더 안전하게 만드는데 관심이 있었다면 우리는 더욱 안전한 코드의 개발을 촉진하는 소프트웨어 개발 환경을 확보하기 위해 노력했을 것이다.
만일 브루스의 주장이 취약성 ‘연구’가 우리에게 더 나은 소프트웨어를 만드는 법을 가르칠 수 있다는 것이라면 소프트웨어가 더욱 비싸고 복잡해지는 대신 훨씬 더 좋아지도록 기여했을 것이다. 그러나 실제로는 ‘더욱 비싸고 복잡’해지고 있다. 그리고 그 점이 나를 두렵게 한다.
[정보보호21c (info@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
[2024-05-30] 
.jpg)
.jpg)
