CISO(최고정보보안책임자)들이 보안 문제의 주범으로 한결같이 지적하는 것은 바로 엉성하게 만들어진 소프트웨어다. 업계에서는 이미 다 알고 있는 사실이니 그리 놀랄 만한 것은 아니다.
개발자들은 보통 보안시스템 교육을 거의 받지 않는다. 설사 교육을 받았다 하더라도 소프트웨어 엔지니어들은 소프트웨어에 기능을 추가했다거나 개발 일정을 맞추는 경우에나 보상을 받을 뿐, 소프트웨어의 취약점을 제거했을 때는 아니다.
버
그 투성이의 코드가 작성되면 결국 소프트웨어가 개발된 후에 보안 전략을 다시 수립해야 하는 상황에 처하게 된다. 방화벽,
애플리케이션 게이트웨이, 패킷 필터링, 행동 차단(behavior blocking), 패칭 등 현재 우리가 사용하는 각종 보안
수단들은 소프트웨어 취약점, 개방형 인터페이스, 불안정한 기능 등에 맞서 소프트웨어를 보호하기 위한 조치들이다.
의료 행위와 비교한다면「병 자체가 아닌 증상을 치료하는 것(대증요법)」이라고나 할까.
사
후약방문식의 보안 처방은 비효율적일뿐만 아니라 비용도 많이 든다. 진정으로 자신의 가치 자산을 보호하고 싶다면 IT 관리자들이
해커들보다 한 템포 빠르게 대처할 수 있도록 소프트웨어 취약성 데이터베이스를 끊임없이 추적해야 한다.
소프트웨어
업체들이 발표하는 패치만 활용해도 모든 취약한 시스템에 대해 IT 보안 훈련과 응급처치를 할 수 있다. 이미 개발이 완료된
소프트웨어의 보안 취약점을 수정하는 것은 개발 과정에서 수정하는 것보다 100배나 더 많은 비용이 소요될 수도 있다.
하
지만 언제나 모자란 것보다는 넘치는 게 좋다. 소프트웨어 보안 문제가 이슈화되면서 이제는 학계와 정부에서도 관심을 기울이기
시작했다. 일례로 카네기 멜론 대학의 SEI(Software Engineering Institute)는 품질과 보안에 중점을
두는 소프트웨어 개발 프로세스 모델을 개발했다.
그리고 이 표준은 미국 국토안보부(Department of Homeland Security)의 BSI(Build Security-In) 계획에도 포함됐다.
출
발은 좋다. 하지만 매년 소프트웨어에 수십억 달러를 쏟아 붓고 있는 기업으로 눈을 돌려보자. 슬프지만 대부분의 기업들은
ISV(독립소프트웨어업체)들로부터 립서비스로만 보안 소프트웨어 개발을 제공받고 있을 뿐이다. 그렇다면 그 결과는? 불안정한
소프트웨어가 이미 상당수 설치돼 있거나 매일 추가되고 있다. 무언가 획기적인 조치가 필요한 시점이다.
|
|||||||||||||||||
흥미로운 사실은 대부분의 기업들이 보안 소프트웨어 개발에 대해 자유방임주의적 태도로 일관하는 데 비해 수많은 보안 문제를 유발하는 주범으로 종종 지목되는 MS는 철저한 보안 전략을 수립하고 있다는 점이다.
MS는 지난 2002년 빌 게이츠가 TC(Trustworthy Computing) 이메일 선언을 하기 오래 전부터 이미 소프트웨어 설계와 테스팅 프로세스에 보안 이슈를 포함시켜 왔다.
1998
년의「내부 보안 태스크포스」는 2000년 SWI(Secure Windows Initiative)로 발전했으며, 2004년「보안
푸시(security push)」를 거쳐 최종적으로 완전한 모습을 갖춘 SDL(Security Development
Lifecycle)로 탄생했다. SDL은 개발자 교육과 보안 응답 실행 처리로 시작되는 철저한 12단계 시리즈 보안 전략이다.
지난 2004년 MS 임원진의 지시로 시작된 이후 비즈니스 활동에 사용되고 있으며, 인터넷에 노출되거나 사적인 데이터를 포함하는 모든 MS의 소프트웨어는 SDL을 준수하도록 하고 있다.
그
러나 MS가 인정하듯 SDL은 무료가 아니다. 중요한 레거시 코드를 사용하는 기업의 경우, SDL로 인해 개발비와 프로젝트
비용이 15~20% 정도 상승할 수 있다. 하지만 MS는 SDL이 그 이상의 가치를 갖고 있다고 주장한다. SDL 프로세스를
거친 제품의 경우 취약점이 50% 정도 감소했으며, 지난 3년 동안 SQL 서버에서 단 한 번도 데이터베이스 취약점이 발견되지
않았다는 것이다.
그렇다면 빌 게이츠와 MS를 통해 기업들이 배울 수 있는 것은? MS의 SDL 성과는 보안
소프트웨어 개발이 얼마나 중요하며 또 효과적일 수 있는지를 잘 보여주는 사례다. MS가 SDL을 구현함으로써 상당한 비용을
절감한 것은 분명한 사실이다.
그러나 이보다 더 중요한 것은 MS가 고객들에게 보안 운영비용이 더 낮은 양질의 소프트웨어를 제공할 수 있게 됐다는 점이다.
다
른 기업들은 이를 모델로 삼아야 한다. 이제부터는 사내 개발자, ISV, 아웃소싱 업체들에 안전한 소프트웨어 개발을 요구해야
한다. 보안 소프트웨어 개발 프로세스의 전체 개요가 담긴 문서를 제공받고 ISV에는 보안 개발 프로세스 결과 보고서를 요구해야
한다.
즉 기업이 ISV들로부터 재무보고서처럼 소프트웨어 개발에 대해서도 투명성 있는 자료를 제출받아야 한다는 말이다.
자,
그러면 다음 단계는 무엇이 될 것인가? 보안 소프트웨어 개발이 오랜 시간을 거쳐 ISO 와 같은 국제 표준 기구를 통해 결실을
맺게 될 것이다. PCI(Payment Card Industry)는 오는 2007년 내에 PCI SSS(Security
Standard Specification) 2.0에서 이를 구현하기 위해 은행과 유통업체들을 준비시키고 있다.
앞을
내다볼 줄 아는 기업이라면 ISV들을 상대로 빠른 시일 내에 이러한 프로세스를 시작하라고 요구해야 한다. 2008년까지 보안
소프트웨어 개발 프로세스를 구현하지 않으면 사업상 문제가 생길 것이라며 정확한 데드라인을 제시하라. 너무 엄격한 것 아니냐는
불만이 나올 수도 있겠지만, 조금이라도 멀리 보는 기업이라면 지금 당장 이 작업을 시작해야 한다.
현재 보안 소프트웨어 개발에 대해 아무것도 하지 않고 있는 ISV들과 아웃소싱 업체들이 보안 문제에 눈을 뜰 때까지는 꽤 많은 시간이 걸릴 테니까 말이다. @
– Jon Oltsik ( CNET News.com ) 2006/12/05
