강은성의 보안 아키텍트 | 소프트웨어 보안과 보안 개발프로세스(1)

CIO KR

작년 9월에 휴대폰 장터로 잘 알려진 커뮤니티에서 195만여 명의 개인정보가 유출되는 사고가 발생했다. 미래부가 발표한 민ㆍ관합동조사단의 조사결과에 따르면 이 곳의 홈페이지에는 비정상적인 DB 질의에 대한 검증절차가 없어서 이를 통해 SQL 삽입 공격이 이뤄졌다고 한다. 방통위는 이 곳이 정보통신망법에서 규정한 개인정보 보호조치(제28조 제1항)를 위반했다는 이유로 과징금 1억 200만 원, 과태료 1,500만 원의 행정처분을 결정했다. SQL 삽입 취약점은 오래되었을 뿐 아니라 유명한 글로벌 프로젝트인 OWASP(Open Web Application Security Project) 10에서도 2010년과 2013년 연속 1위를 차지할 정도로 잘 알려졌음에도 불구하고 이로 인한 사고가 끊이지 않은 것이 우리의 보안 현실이다. (OWASP 10은 2004년, 2007년, 2010년, 2013년에 진행됐다.)

웹 애플리케이션은 불특정 다수의 이용자가 서비스를 이용하는 공간이기 때문에 공인 IP로 인터넷에 공개된 서버에서 작동한다. 이용자와의 접점(인터페이스)인 동시에 범행자들의 보안 공격의 통로이기도 하다는 말이다. 따라서 웹 애플리케이션은 이용자에게 필요한 기능, 사용 편의성, 적절한 성능을 제공할 뿐 아니라 경계선에 있는 제1차 방어 기제로서 보안 공격에 최소한의 방어를 할 수 있어야 한다. 그래야 서비스 제공자가 이용자에게 온전한 서비스를 제공할 수 있다. 따라서 개발조직의 개발 목표에 기능, 편의성, 성능뿐 아니라 보안이 들어가야 한다. SQL 삽입 공격에 대해서도 그에 대한 취약점이 없도록 웹 서비스를 개발하는 것이 가장 좋은 방어책이다.

웹 애플리케이션뿐 아니라 일반 소프트웨어에도 방어 기제로서의 성격이 있다. 많은 소프트웨어들이 이용자와 직접적인 접점을 갖거나 다른 소프트웨어 모듈을 통해 간접적으로 연결되어 있기 때문이다. 메신저 같이 PC나 스마트폰에서 작동하는 애플리케이션도 이용자에게 서비스를 제공하는 동시에 이용자 정보와 데이터를 보호하기 위한 방어선으로서의 역할이 있다.

특히 사물인터넷(IoT) 시대에는 소프트웨어 보안(Security)과 사람의 안전(Safety)이 상당한 연관을 갖게 된다. 사물인터넷의 스마트기기는 사람의 건강정보나 생활정보를 밀착 수집하는 경우가 있는데, 그것의 보안취약점이 사람의 생명이나 안전, 일상생활에 악영향을 미칠 수 있다. 그런데 사물인터넷 기기에 보안취약점이 있는 경우 PC나 스마트폰보다 대응하기가 더 어렵다. 보안취약점이 알려지면 보안 패치 개발, 소프트웨어 업데이트 인프라를 통한 배포, 스마트기기 화면 등을 통한 이용자 인지, 이용자의 보안패치 수행 승인, 보안패치 실행까지 되어야 취약점이 해결되는데, 스마트기기의 컴퓨팅 능력이나 소프트웨어 개발업체의 대응 역량이 장애물이 될 가능성이 있다. 따라서 사물인터넷 시대에 보안취약점에 대응하기 위해서는 소프트웨어 업데이트를 신속하게 수행하기 위한 대책을 마련하는 것과 함께 처음부터 보안취약점이 발생하지 않도록 개발하는 것이 더욱 중요하다.

대표적인 사물인터넷 기기로 자동차가 떠오르고 있다. 최근 구글 같은 IT 업체뿐 아니라 아우디, GM 등 전통적인 자동차 회사들이 자율주행 자동차를 구현하기 위해 연구하고 있는데, 여기에서 보안(Security)의 문제는 곧 안전(Safety)의 문제와 직결된다. 자동차에 내장된 소프트웨어의 지시를 받아 동작하던 자동차가 해킹이 되어 오작동하거나 범행자의 의도에 따라 작동하면 인명사고로 연결될 수 있기 때문이다. 2015년 7월에 크라이슬러의 '지프 체로키'(Jeep Cherokee)가 무선인터넷을 통해 원격조종이 가능한 보안 결함이 있음이 밝혀지자 크라이슬러가 해당 차종 140만 대를 리콜한 것도 이 때문이다. 사물인터넷 시대에 보안의 중요성을 드러낸 사례다.

소프트웨어 보안을 강화하기 위한 중심에는 보안 소프트웨어 개발 생명주기(SSDL: Secure Software Development Lifecycle)가 있다. 개발할 때 취약점 없이 개발하고 출시 이후에 생기는 문제 역시 신속하고 정확하게 대응해야 하기 위해 반드시 필요하기 때문이다. 소프트웨어 개발프로세스는 소프트웨어 기획 - 요구사항 - 설계 - 구현 - 검증 - 출시 - 사후 대응을 포괄하는데, 개발의 각 단계에서 발생할 수 있는 결함(버그)은 뒤쪽 단계에서 발견할 수록 그것을 해결(패치)할 때 드는 비용이 크게 늘어나는 것으로 알려져 있다.


<그림 1> 결함 발생 및 탐지 시기에 따른 상대적 해결 비용 추정


출처: 미국 표준기술연구소, The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002.5

<그림 1>에서 보듯 각 단계에서 발생한 결함을 그 단계에서 해결하지 못하고, 이후 단계에서 해결하려면 상대적 비용이 크게 늘어난다. 구현(coding) 단계에서 발생한 결함을 통합테스트 단계에서 해결하려면 비용이 구현 단계보다 10배, 출시한 이후에는 30배가 더 든다. 요구사항 또는 구조설계 단계에서 발생한 결함을 구현 단계에서 해결하려면 5배, 통합테스트에서는 10배, 출시 이후에는 30배 더 비용이 든다. 이 보고서가 발간된 2002년보다 요즘에는 온라인이나 모바일을 통한 업데이트가 크게 활성화되었기 때문에 과거보다 업데이트 비용이 줄어든 측면도 있지만 이용자가 크게 늘어나서 결함으로 인한 이용자의 피해는 한층 더 커질 수 있는 상황이 되었다. 몇 배가 더 드는지에 대해서는 이견이 있다 하더라도 비용이 크게 증가할 수밖에 없다는 것에는 공감할 것이다.

보안취약점 역시 해결해야 할 결함으로 본다면 소프트웨어 보안을 위한 활동이 개발프로세스의 각 단계에서 제대로 이뤄질 때 가장 효율적이고 효과적이라는 결론에 다다른다. 하지만 우리나라에서 소프트웨어 보안 문제는 구현 단계의 보안 활동인 보안코딩(Secure Coding)과 소스코드에 대한 정적 분석 문제로 다뤄지는 것 같다. 전자정부에서 보안코딩이 의무화되고, 이를 준수하게 위해서는 보안업체가 공급한 정적 보안분석 도구를 돌려 보고 거기에서 나오는 취약점을 해결하는 것으로 되면서 소프트웨어업체는 개발 프로세스 전반을 갖춰 역량을 강화하기보다는 정적 분석도구로 사용으로 대응하는 모양새다. 정부의 원래 의도는 그렇지 않았던 것 같은데, 이것이 소프트웨어의 보안 수준을 높이기 위한 활동이 아니라 컴플라이언스처럼 되어 버렸다.

물론 정적 분석도구를 사용하면 사용하지 않는 것보다 보안수준을 높일 수 있지만 한계가 명확히 있다. 예를 들어 인증 구조가 잘못된 경우, 설계한 프로토콜이 보안에 취약한 경우, 암호화해야 할 데이터를 평문으로 보내는 경우, 키 관리를 제대로 하지 못한 경우 등은 정적 분석도구로 탐지할 수 없다. 소프트웨어 개발업체가 전반적인 SSDL을 운영하면서 각 단계별로 해야 할 보안 활동을 하지 않으면 이런 문제는 계속 발생할 수 있다는 점에 유의할 필요가 있다.

---------------------------------------------------------------
강은성 칼럼 인기기사
->강은성의 보안 아키텍트 | APT 공격, 어떻게 막을까?(2)
-> 강은성의 Security Architect | 보안관제 100% 활용하기(1)
->강은성의 Security Architect | APT 공격, 어떻게 막을까?(1)
-> 강은성의 Security Architect | 보안관제 100% 활용하기(2)
-> 강은성의 Security Architect | Software Architect? Security Architect!
-> 신간 인터뷰 | "모든 C-레벨의 2015년 화두는 정보보안" 강은성 대표
---------------------------------------------------------------

SSDL을 잘 만들어 운영하면 다음 몇 가지 이점이 있다. 첫째, 프로세스에 참여하는 각 주체들(개발팀, 품질팀, 보안팀 등)이 자신의 역할을 이해하며 일정과 인력을 운영, 협업할 수 있어서 보안취약점을 최소화하면서도 효율적으로 소프트웨어를 개발할 수 있다. 둘째, 전체 프로세스를 알고 있으므로 개발 속도와 보안 수준 사이에 유연한 대응을 할 수 있다. 예를 들어 출시를 앞당기기 위해 일부 보안활동을 제외해야 할 상황이 발생한다면 이를 관리하면서 의사결정을 할 수 있다. 셋째, 출시 이후에 새로운 보안취약점이 발견되었을 때 신속하고 정확하게 대응할 수 있다. 넷째, 프로세스 참여자가 다른 조직의 업무를 배움으로써 역량이 좋아지고 전사적 시너지 효과를 낼 수 있다.

참고할 만한 SSDL로는 마이크로소프트의 SDL(Security Development Lifecycle)이 있다. 가장 오래 되어 온라인에 정보가 많고, 참고할 만한 다양한 출판물이 나와 있다. 마이크로소프트는 SDL을 적용한 뒤에 운영체제와 DBMS에서 보안취약점이 크게 줄어들었다고 발표하였다. (<그림 2> 참조)

<그림 2> SDL 적용 뒤 마이크로소프트 제품의 취약점 감소 현황


출처: 마이크로소프트 SDL 사이트

국내 자료로는 한국인터넷진흥원 자료실 > 관련 법령 > 안내서·해설서 페이지에 보면 소프트웨어 개발보안이나 보안코딩에 관련된 다양한 가이드라인 문서가 있다. 세계적으로 많이 알려진 보안코딩 가이드라인은 카네기멜론대학교 소프트웨어공학연구소(SEI)의 CERT에서 운영하는 보안코딩 가이드라인 사이트에 있다. 많은 프로그래밍 언어를 포괄하고 내용도 상세하다.

우리나라에 개발프로세스가 잘 되어 있지 않은 소프트웨어 회사도 많은데, SSDL을 강조하는 것이 무리라고 생각할 수 있다. 하지만 모바일, 사물인터넷 분야에서 세계적인 소프트웨어를 만들어 보자고 하면서 개발프로세스나 보안 개발프로세스에 별 관심이 없는 것은 더 큰 무리라는 점도 우리가 알아야 하지 않을까 싶다.

*강은성 대표는 소프트웨어 개발자로 시작하여 국내 최대 보안전문업체에서 연구소장과 시큐리티대응센터장을 거치고, 인터넷 포털회사에서 최고보안책임자(CSO)를 역임한 국내 최고의 보안전문가다. 그는 대기업 임원으로서 기업보안을 책임졌던 리더십과 보안 현업에서 얻은 풍부한 관리적ㆍ기술적 경험, 수사기관과 소송에 대응했던 위기관리 경험을 토대로 실효성 있는 기업보안 거버넌스와 보안위험 관리, 정보보호대책을 제안하고 있다. 지금은 CISO Lab을 설립하여 기업 차원의 보안위험 대응 전략을 탐구하여 기업 보안컨설팅과 보안교육을 진행하고 있으며, 저서로 IT시큐리티(한울, 2009)와 CxO가 알아야 할 정보보안(한빛미디어, 2015)가 있다. ciokr@idg.co.kr