개발자 여러분, 지금 하고 계신가요?

도대체 무엇을 물어보고 싶은 걸까.
잠시 후에 필자가 하고자 하는 질문을 다시 한번 던지도록 하겠다.

소프트웨어의 보안 결함으로 인한 피해

1:10:100 법칙을 들어 본 적이 있는가? 이것은 세계적인 항공 배송 업체인 FedEx 사에서 만든 법칙으로 그 내용은 다음과 같다. “불량이 생길 경우 즉각적으로 고치는 데에는 1의 원가가 들지만, 책임 소재나 문책 등을 회피하기 위해 이를 숨기고 그대로 기업의 문을 나서면 10의 원가가 들며, 이것이 고객 손에 들어가 클레임으로 되면 100의 원가가 든다.” 소프트웨어 업계에서는 이 법칙에 특히나 관심을 기울일 필요가 있다.

대부분의 소프트웨어 보안 결함을 수정하는데 드는 비용은 매우 저렴하다. 예를 들어, 2003년 여름 전 세계 PC에 엄청난 피해를 불러일으킨 블래스터(Blaster) 웜의 발생을 유발한 것은 ‘단 두 줄의 소스 코드’이다. 이 두 줄을 제대로 수정하는데 드는 비용은 얼마일까? 하지만 이 소스 코드의 오류가 사전에 발견되지 않고 고객에게 전달되어 발생한 비용은 천문학적이다(약 20~100억 달러 추산).

이 결과를 보면, 1:10:100이 아니라, 1:10:10×10ⁿ이라고 해도 전혀 어색하지 않다. 소프트웨어의 보안 결함으로 인한 피해는 소프트웨어를 만든 업체뿐만 아니라, 소프트웨어의 최종 사용자에게도 큰 피해를 준다. 특히, 자기 복제를 통해 다른 사용자에게 급속도로 확산을 시킬 수 있기 때문에 위와 같이 피해가 커지게 된다.

이런 피해를 방지하기 위한 가장 효율적인 방법은 보안상 안전한 소프트웨어를 만드는 것이다.
이 글의 목적은 바로 여기에 있다. 필자는 몇 회에 걸쳐 ‘Secure software를 만드는 방법’에 대한 가이드라인을 제시하고자 한다.

무엇이 그들을 곤경에서 벗어나게 했는가

먼저, 저 멀리 태평양 건너의 어떤 회사의 얘기를 해 볼까 한다.
이 회사는 소프트웨어를 팔아서 어마어마한 돈을 벌어들이고 있는 회사이다. 이 회사의 창업자 겸 회장인 사람은 세계 제 1의 부자이자 자선사업가로도 유명하다. 모두 예상한 대로, 이 회사는 바로 Microsoft이다.

Microsoft는 2000년대 초반까지만 해도 사용자와 컴퓨터 전문가, 언론으로부터의 엄청난 비난을 감수해야 했다. 이 비난의 원인은 Microsoft에서 개발한 소프트웨어의 보안상 취약점이 너무나 많았기 때문이다. 2003년 1월 25일에는 Microsoft SQL Server의 취약점 때문에 발생한 ‘슬래머 웜[http://kr.ahnlab.com/info/smart2u/virus_detail_1098.html]’이 대한민국 인터넷을 전부 마비시키기도 했다. 또, 위에서 언급한 Microsoft Windows의 RPC 취약점을 이용한 ‘블래스터 웜[http://kr.ahnlab.com/info/smart2u/virus_detail_1371.html]’ 덕분에, 새로 설치한 윈도우가 10초 만에 공격 당해서 재 시작되는 화면을 몇 번씩이나 바라봐야만 했다.

당시 Microsoft가 직면한 시장 상황은 다음과 같다.

• 고객들은 잦은 보안 패치로 인한 비용과 번거로움에 대해 불평
• 웜(Worm)과 바이러스(virus)로 인한 공격이 IT 관리자와 최종 사용자의 컴퓨팅 자원 사용을 방해하여, 최종 사용자들의 불만을 야기
• 언론이 보안 취약점에 초점을 맞추어, 제품의 새로운 기능과 개선된 점이 고객에게 제대로 전달되지 않음
• Microsoft의 개발자들이 기존 제품의 보안 취약점에 대한 패치를 제공하느라 새로운 제품의 출시 일정이 연기되어야 하는 상황

하지만, 이런 현상이 현재도 지속되고 있을까. 그렇지 않다. 지금도 Microsoft의 윈도우는 취약점을 가지고 있고, 앞으로도 계속 발견될 것으로 보인다. 하지만 취약점의 수는 엄청난 비난을 받던 시절과는 비교할 수 없을 정도로 줄어들었다.

[표] Microsoft 제품의 연도별 보안 취약점 수와 전체 취약점에서 차지하는 비율
자료 출처: http://nvd.nist.gov (NIST ? National Vulnerability Database)

[표]의 첫 번째 차트는 매년 보고된 Microsoft 제품의 취약점 수이다.
두 번째 차트는 매년 보고된 모든 소프트웨어의 취약점 수 중에서 Microsoft 제품의 취약점이 차지하는 비율을 표시한다. 이 표를 분석해 보면, Microsoft 제품의 취약점은 1999년을 기점으로 하여 점점 줄어들고 있다는 사실을 확인할 수 있다.

이런 변화는 1998년부터 시작된 노력의 결과이다.
Microsoft의 경영진은 강력한 의지를 가지고 모든 직원들에게 안전한 소프트웨어를 만들도록 강제하고 독려했다.
Microsoft는 Windows 2000을 개발하는 시점에 자사에서 개발되고 출시되는 모든 소프트웨어에 대해 보안 검사를 실시하고, 보안상 취약점이 있거나 있다고 의심되는 제품에 대해 ‘출시 중지(Stop shipment)’라는 강력한 제재를 취했다.
그리고 개발자뿐만 아니라 테스터, 프로그램 관리자(PM), 설명서 직원들에 대한 지속적인 교육과 보안에 중점을 둔 소프트웨어 설계, SDL(Secure Development Lifecycle)이라고 불리는 안전한 소프트웨어 개발 프로세스의 도입과 적용 등의 노력을 끊임없이 기울여 왔다.
Microsoft의 SDL(http://msdn.microsoft.com/security/)에 관해서는 다음 회에서 자세히 다루도록 하겠다.

개발자가 보안에 대해서 알아야 하는 이유

필자가 개발자의 길로 뛰어든 지 이제 만 8년이 되어간다. 2000년 당시에는 막 1.5 세대 보안 업체들이 설립되기 시작한 시점이다.
비즈니스 모델로서의 보안은 시장에 뿌리를 내리고 있었지만, 실천하는 행동으로서의 보안은 대중에게 많이 알려지지 않았던 시기이다. 물론 그 대중에는 우리 개발자들도 포함되어 있다.
필자 역시 소프트웨어를 개발하고 있지만(더구나 보안 소프트웨어를 말이다), 솔직히 정말 보안에 취약하지 않은 소프트웨어를 개발했는가에 대해서는 회의적이다. 극소수의 뛰어난 개발자를 제외하면 대부분 비슷할 것이라고 스스로 위안을 삼으면서 말이다.

사실, 개발자들은 보안에 대해 잘 알아야 한다. 그래야 개발자들이 만들어내는 소프트웨어가 취약하지 않을 수 있다. 대한민국에서 과중한 업무와 박봉, 말도 안 되는 일정, 그리고 수시로 바뀌는 발주처의 요구사항에 시달리는 개발자들이, 보안에 대해 이해하고 제품 개발에 적용하기에는 현실이 너무 가혹하다는 것은 필자도 경험으로 잘 알고 있다. 그래도 우리가 만드는 소프트웨어가 세계적인 품질을 가지기 위해서는 반드시 필요한 요소이다.

안전한 소프트웨어를 만드는 방법을 제시하기에 앞서, 필자는 먼저 안전한 소프트웨어를 만드는 ‘환경’에 대해 언급하고자 한다. 아무리 많은 방법을 알아도, 방법을 적용할 수 있는 환경이 먼저 만들어지지 않으면 아무 쓸모가 없기 때문이다.

Secure Programming을 위한 선결 조건

보안이 소프트웨어의 중요한 화두로 떠오름에 따라 시중에는 많은 ‘Secure Programming’에 관련한 참고 서적과 자동화 도구가 출시되고 있다. 이로 인해 개발자들이 안전한 소프트웨어를 만드는 과정이 조금 더 쉬워진 것도 사실이다. 하지만, 무엇보다 중요한 것은 소프트웨어를 안전하게 만들고자 하는 ‘개발자 자신의 끊임없는 노력’이 뒷받침되어야 한다. 서적과 자동화 도구는 우리가 해야 할 일을 대신 해주지는 않는다.

앞서 언급했듯이 Microsoft가 취약점의 수를 줄일 수 있었던 원동력은 경영진의 의지이다. Microsoft의 경영진은 많은 비용을 감수하고 소프트웨어의 보안을 확보하기 위해 강력한 드라이브를 걸었고, 소프트웨어 개발 프로세스에 보안을 고려하도록 회사의 정책으로 강제하였기 때문에 소프트웨어가 견고해질 수 있었다. 이처럼, 위에서 언급한 ‘개발자의 노력과 의지’가 가장 중요한 요소이지만, 그런 노력을 뒷받침해줄 수 있는 정책과 환경을 만들어 주는 것은 경영진의 의지이다.

안전한 소프트웨어를 만드는 가장 효율적이고 저렴한 방법은 개발 프로세스 적용 시 설계, 구현, 테스트 절차에 보안을 고려하여 설계하는 것이다. 그리고 경영진은 개발팀에 대한 지원과 강제를 통해 해당 프로세스가 자사의 제품에 적용될 수 있도록 해야 한다.

이제 처음에 제기했던 질문을 다시 한번 하고자 한다.
모두 안전한 소프트웨어를 만들고 있는가? 만약 그렇지 않다면, 이 칼럼에 관심을 가지고 지금 하고 있는 일에 적용해 보기를 바란다. 다음 회에서는 실제로 Secure software를 만들기 위한 가이드라인을 제시하도록 하겠다.@

[저자] 안철수연구소 보안관리Unit 조인중 선임연구원

[안철수연구소 2007-06-14]