보안에 취약한 애플리케이션에 투자하라

100% 공감하는 내용이다. 이제 해킹을 위한 공격 방법의 트렌드가 확실히 변화했다. 네트웍이 목표가 아니라, 사용자들이 사용하는 실질적인 어플리케이션 자체가 목적이 되었다. 그만큼 직접적인 타격을 많이 주기도 하지만, 대응을 하지 못하는 기업의 입장에서는 대외 공신력 및 브랜드 가치가 하락할 수밖에 없기 때문이다. 천번을 반복해서 얘기한다해도 문제될 것이 없다고 생각한다. 보안은 사후약방문 [死後藥方文] 되어서는 안된다. 끊임없이 예방해야 하며, 이를 위한 방법으로 개발 기획상에 보안에 대한 적용 부분이 명시되어야 한다. 코딩단계부터 적용할 지침과 가이드가 마련되어야 하며, 당장이 아닌, 먼 미래까지도 바라볼수 있는 안목을 가져야하지 않을까 생각한다. 우선 나부터 그러한 노력을 시작해야 하겠다.

=================================================================================

전문가들은 보안에 취약한 것은 네트워크나 시스템 계층이 아니라 애플리케이션 영역으로 보고 있다. 대부분의 보안사고가 애플리케이션의 취약점을 이용한 것임에도 기업들은 신경을 쓰지 않는다. 그러나 애플리케이션 인프라도 고객의 중요한 자산임을 인식하고 보안에 투자해야 한다.

전문가들은 보안에 취약한 것은 네트워크나 시스템 계층이 아니라 애플리케이션 영역으로 보고 있다. 대부분의 보안사고가 애플리케이션의 취약점을 이용한 것임에도 기업들은 신경을 쓰지 않는다. 그러나 애플리케이션 인프라도 고객의 중요한 자산임을 인식하고 보안에 투자해야 한다.

각 기업들은 보안사고 예방 및 방지를 위해 해마다 많은 투자를 행하고 있으며 이에 따라 보안사고가 줄어들어야 하는 것이 당연한 일이지만 실제 보안 사고에 의한 악영향은 역으로 점점 증가되고 있는 추세이다.

이에 대한 전문가들의 의견은 70% 이상의 보안 취약점이 네트워크나 시스템 계층이 아닌 애플리케이션 영역으로 보고되고 있으며 조사 대상의 92%의 애플리케이션이 취약한 것으로 보고되었다(NIST)는 것은 이미 잘 알려진 사실이다.

이렇듯 대부분의 보안사고가 애플리케이션의 취약점을 이용함 것임에도 불구하고 대부분의 기업들은 네트워크 및 시스템 인프라의 보안 투자에 중점을 두고 있고 실제 취약한 애플리케이션 관련 투자에는 인색한 현실이다.

더욱이 애플리케이션 인프라의 특성상 대부분의 개발은 아웃 소싱을 통해 이루어지고 있고 고객 입장에서는 애플리케이션 보안까지도 개발업체의 책임으로 생각하는 경우가 많이 있다. 그러나 시스템, 네트워크 인프라와 마찬가지로 애플리케이션 인프라 자체도 고객의 중요한 자산으로 인식하여야 하며 이에 대한 보안 투자 역시 여타 인프라에 대한 보안 투자와 마찬가지로 고객이 신경 써야 할 중요한 몫이다.

또한 국내뿐 아닌 전 세계적으로도 보안 관점에서 코딩을 할 수 있는 개발자가 많지 않은 것이 현실이고 특히 개발자에게는 애플리케이션의 기능성, 가용성, 안정성 및 프로젝트 기간 내에 개발을 완료하는 것이 가장 중요한 업무 목표이다. 즉, 애플리케이션 보안이라는 부분이 중요한 화두이며 개발자의 참여가 필수적인 요소이지만 현실적으로 개발자가 보안까지 고려하여 코딩을 하는 것에 한계가 있는 것이 현실이다.

애플리케이션 보안은 당연한 트렌드

2000년대 초반 이후 애플리케이션 보안의 중요성이 인식되어가며 애플리케이션 보안과 관련된 여러 가지 방안들이 등장하기 시작하였으나 그 당시의 방안들은 대부분 개발 이후 사후 관점에서의 보안 방안들이었고 최근 1~2년 사이의 트렌드는 애플리케이션 계획단계에서 운영단계까지 전체 개발프로세스(SDL)에 대한 단계별 보안 적용 방안이 전반적인 추세이다.

“개발 완료 후 전체 애플리케이션에 대한 보안 취약점들을 검사하고 조치하기 위해서는 개발한 시간만큼의 시간 및 비용이 요구된다”는 가트너 보고서도 말해주듯이 개발프로세스에서의 보안은 애플리케이션 보안의 당연한 트렌드라 할 수 있을 것이다.

개발 프로세스의 보안 요소들을 살펴보면, 계획단계에서는 애플리케이션 보안 정책, 즉 개발 보안 가이드가 요구되며 이에 대한 검증 계획이 마련되어야 한다. 최근 2`~3년간 대부분의 대기업과 금융권은 보안 컨설팅 및 자체 정책에 의해 개발 보안 가이드를 마련했지만 개발자가 가이드를 준수 했는지 여부를 확인 할 수 있는 검증장치 마련은 현실적으로 어려움이 있었다. 그러나 최근 들어 기술의 발전에 따라 코드관점에서 보안에 대한 검증을 수행 할 수 있는 도구들이 마련되어 보안 가이드라인에 대한 준수 여부를 확인할 수 있는 방법들이 소개되어 있다.

코딩단계에서는 개발자들이 보안 가이드를 준수하여 코딩 할 수 있도록 하는 유도하는 방안이 요구된다. 이미 만들어진 보안 가이드를 준수 할 수 있는 시스템 혹은 프로세스가 마련되어야 하며 예를 들어 개개의 개발자들이 도구화 된 보안가이드를 가지고 본인이 개발하고 있는 소스에 대한 취약점을 스스로 관리한다든지 혹은 대부분의 기업들이 사용하고 있는 형상관리 혹은 변경관리 도구와 연동하여 보안 취약점에 대한 관리를 하는 방안이 있다.

대부분 개발자들의 코딩 특성이 “무”에서 코딩 하는 경우 보다 보유하고 있는 기존의 코드를 변경함에 의해 프로젝트 특성에 맞는 코드를 생산해 낸다. 즉, 보유중인 코드는 copy & paste의 과정을 거쳐 새로운 코드로 거듭나는 경우가 대부분이며 이 경우, 기 보유중인 코드에 취약점이 있다면 재 생산 과정을 거치면서 취약점이 2배, 4배, 8배 등과 같이 기하급수적으로 늘어나게 되고 결국에는 취약점에 대한 관리 불능 상태로 테스팅 혹은 운영으로 넘어가게 되곤 한다.

코딩단계에서 보안을 적용하라

혹자의 경우 “프로젝트 기간 안에 코딩을 끝내야 되는데 언제 보안까지 신경 쓰느냐?”라고 불평 하는 개발자들을 종종 접하곤 하는데 위의 현실을 얘기하면 서로간의 공감대가 형성 되는 경우가 많다. 또한 실제로 코딩 단계에서 보안을 적용 했을 경우 최초 적응 기간이 지나면 대부분의 개발자들이 프로젝트 기간 안에 자연스럽게 보안을 고려한 코딩을 하게 되는 경우를 많이 보아 왔다. 이는 결국 개발자 스스로의 코딩 수준이 높아지는 결과로 이어진다.

또한 형상관리 혹은 변경관리 도구와의 연동을 통해 코드의 변경관리 단계에서 보안 검토 프로세스까지 추가함으로써 코딩단계의 보안 검토 프로세스를 운영 할 수 있다. 최근 몇몇 금융권 및 대기업에서 변경관리 혹은 형상관리와 연동된 보안 검토 프로세스에 대한 운영 사례는 참조할 만한 좋은 예라 할 수 있다.

테스트 단계에서는 개발된 애플리케이션 소스에 대한 전수검사 혹은 QA 관점의 보안 테스트가 요구된다. 우선 코딩단계에서 보안이 고려되었다 하더라도 각 모듈들이 모여 전체 애플리케이션이 되었을 때 모듈간의 플로우 상에서 발생될 수 있는 취약점의 파악 및 조치를 위해 또는 보안 가이드 라인에 대한 준수 여부 확인을 위해 코드에 대한 전수 검사는 꼭 필요한 테스트 방안이다.

이 외에 외부에서 내부로의 애플리케이션 보안 테스트 즉, 모의 해킹이나 웹 스캐너를 이용한 전체 페이지 테스트도 필요한 테스트 방안이다. 현재 개발 프로세스상에 테스트 항목들은 대부분 코드 표준 준수, 영향평가, 가용성 위주의 테스트가 대부분을 차지하고 있었으나 앞으로는 보안 테스트 항목도 애플리케이션 품질 테스트의 중요한 항목-애플리케이션 보안도 광의의 의미로 품질에 속하는 항목이므로-이 될 것이라 보여지고 나아가 ITIL이나 CMMI 같은 모델에서도 QA 관점에서 애플리케이션 보안 부문이 주요 항목으로 자리 잡을 것이라 생각된다.

개발 프로세스 단계별 보안 적용은 필수

운영단계에서의 가장 중요한 부분은 공격에 대한 모니터링 및 방어일 것이다. 내·외부로부터 애플리케이션 공격이 행해질 경우 공격에 대한 모니터링, 더 나아가 적극적인 방어를 할 수 있는 장치 마련이 필요한 항목이다.

관제 시스템 등과의 연동을 통한 애플리케이션 공격에 모니터링이 필요하고 방어 방안으로는 애플리케이션 방화벽이 대표적이다. 그러나 애플리케이션 방화벽이 가장 현실적인 방법이기는 하지만 현재 금융권이나 대기업 등 네트워크 트래픽이 많은 경우 웹 서버의 성능 저하요소 및 룰 세팅의 어려움들로 인해 아직까지 대기업 군의 적극 도입이 더딘 실정이다. 하지만 향후 하드웨어 및 소프트웨어 기술 발달에 의해 현재의 어려움들은 자연스럽게 해결되리라 보여진다.

최근에는 애플리케이션에 대한 하드닝 기술을 이용한 새로운 방어 방안이 새로운 트렌드로 나타나고 있으나 아직 시장에서의 검증은 시간을 두고 지켜보아야 할 장치이다. 운영단계에서 또 한 가지 고려해야 할 부분은 애플리케이션 변경에 대한 보안 검토 방안이다.

수시로 변경되는 애플리케이션의 특성상 변경되는 애플리케이션 모듈에 대한 보안 검토가 필요하다. 즉 코드 변경시 취약점 검사를 수행할 수 있도록 형상관리 또는 변경관리 프로세스가 구축되어야 한다. 

최근 들어 금융권의 차세대 시스템 구축 시 개발단계부터의 보안적용, 최근 행자부에서 발표한 “전자정부 10대 보안대책”에 포함된 개발단계의 취약점 제거 등과 같이 공공, 민수 분야에서 애플리케이션 보안과 관련된 항목들이 포함되고 있는 것은 그만큼 애플리케이션 보안이 기업의 중요한 보안요소로 자리잡아 가고 있는 추세라고 말 할 수 있을 것이다.

마지막으로 방화벽과 같은 네트워크 보안 혹은 접근통제와 같은 시스템 보안의 경우 일정한 경계를 만들고 보안 위협에 대한 대처를 행하는 ‘경계’의 보안이다.

그러나 애플리케이션의 경우 내·외부의 연결 고리를 가질 수 밖에 없는 특징이 있으므로 네트워크, 시스템등의 IT 인프라와 같은 “경계”의 보안이 적용되기 어려운 것이 현실이다. 그러므로 애플리케이션 보안의 가장 근본적인 해결 방안은 앞서 언급한 계획, 코딩, 테스트, 운영 등 전체 개발 프로세스 단계별 보안 적용을 통해 애플리케이션 보안 위협에 대처할 수 있는 “내성”을 가진 “강한” 애플리케이션을 만드는 것이라 생각한다.

<글: 문성준 인터비젠테크놀로지 서비스 사업부 이사>

출처 : 보안뉴스

관련 글 : 2007/11/05 - [Security_Space] - SW 보안은「개발단계에서 출발」