.jpg)
사후 취약점 점검이 아닌 개발 프로세스 개선으로 웹 보안 강화
웹 해킹으로 인해 애플리케이션 보안의 중요성을 인식한 대기업을 중심으로 최근 애플리케이션 보안 방안에 대한 인식과 관심이 커지고 있다. 이전에는 대부분의 애플리케이션 보안이 모의 해킹, 웹 취약점 점검 등과 같은 사후적인 관점에 초점이 맞추어져 있었고 사후적인 관점으로 웹 취약점을 점검하다 보니 발견된 취약점을 제거하는 데에 막대한 비용과 시간이 소요되었다. 연간 1~2회 보안점검을 실시하는 탓에 점검시 마다 거의 동일한 취약점들이 매번 반복되어 발견되는 악순환이 계속되는 문제가 발생했다. 이러한 문제를 해결하기 위해 사후적인 취약점 점검 관점이 아닌 개발 프로세스 개선을 통한 애플리케이션 사고의 사전 예방과 취약점에 대한 근본적인 원인 파악 및 조치를 포함한 상시 보안체계를 갖추기 위해 포티파이의 솔루션을 구축하게 됐다.
웹 기반의 업무가 늘어남에 따라 과거 몇 년간 국내에는 애플리케이션 해킹으로 인한 수많은 사고들이 발생했으며 그 피해 또한 과거의 것과는 비교할 수 없을 정도로 커지게 되었다. 이에 애플리케이션 보안의 중요성을 인식한 대기업을 중심으로 애플리케이션 보안 방안에 논의가 시작되었다. 이전에는 대부분의 애플리케이션 보안이 모의 해킹, 웹 취약점 점검 등과 같은 사후적인 관점에 초점이 맞추어져 있었고 사후적인 관점으로 웹 취약점을 점검하다 보니 발견된 취약점을 제거하는 데에 막대한 비용과 시간이 소요 되었고 연간 1~2회 보안점검을 실시하는 탓에 점검시 마다 거의 동일한 취약점들이 매번 반복되어 발견되는 악순환이 계속되는 문제가 발생했다.
금융사의 인터넷뱅킹 시스템을 비롯한 대부분의 기업 애플리케이션은 상용화된 일반 소프트웨어 패키지를 그대로 쓰는 경우가 거의 없으며 신규 개발하거나 일반 패키지를 커스터마이징한 것들이다. 신규 개발의 경우 대부분 외부 개발업체 아웃소싱에 의존 하고 있으며 기업 전산담당 직원들은 개발보다는 관리와 운영을 위한 인원이라고 해도 과언은 아니다.
기업들이 이처럼 외부 개발업체의 개발에 의존하다 보니 보안을 고려하여 개발할 수 있는 여건이 충분하지 못해 애초에 계획했던 만큼의 결과를 기대하기란 매우 어렵다. 또한 개발 완료 후 보안점검 결과 여러 취약점 등의 오류가 발견됐다 하더라도 시스템을 무작정 중단시켜놓고 수작업에 의해 모든 소스를 하나하나 체크한다는 것도 사실상 불가능하다.
이러한 문제를 해결하기 위해 애플리케이션 보안 점검을 단순히 툴의 도입 차원에서 접근 하게 되면 이벤트성 취약점 점검에 그치게 되고 근본적인 문제를 해결하지 못하게 될 확률이 높아지게 된다.
이에 대부분의 1금융사와 통신사, 대기업군을 중심으로 사후적인 취약점 점검 관점이 아닌 개발 프로세스 개선을 통한 애플리케이션 사고의 사전 예방과 취약점에 대한 근본적인 원인 파악 및 조치를 포함한 상시 보안체계를 갖추기 위해 포티파이 도입을 추진하게 되었다.
개발 프로세스 개선 프로젝트 추진 과정
개발 프로세스 개선 프로젝트는 다음 사항을 세부 항목으로 추진하게 된다.
-
애플리케이션 취약점 점검 지침 및 개발 보안기준 가이드 개발
-
애플리케이션 취약점 개발자 자체 점검 체계 구축
-
애플리케이션에 대한 정기적인 취약성 점검체계 구축
-
애플리케이션 상시 취약점 점검 시스템 구축
-
개발자 개발 보안 교육 및 인식 확산
일반적으로 개발 보안 프로세스가 확립·안정화 되려면 약 3~4개월 정도의 시간이 소요되며 다음과 같은 내용으로 프로세스 구축이 진행된다.
● 개발 보안기준 가이드 작성
첫 단계로 ‘웹 취약점 점검 지침 및 개발 보안기준 가이드 작성’을 하게 되며 그 가이드를 기준으로 포티파이 보안 점검 룰을 설계한다. 이를 위해 기업이 내부적으로 적용하고 있는 보안 지침을 분석하고 포티파이 개발 보안 정책에 기반하여 개발 보안 정책을 수립하게 된다. 이를 통하여 개발 정책을 가지고 있지 않거나 가지고 있더라도 형식적인 수준에 머물렀던 내용들을 현실화 하여 ‘개발 보안 기준’을 수립할 수 있게 된다.
● 애플리케이션 취약점 자체 점검 체계 구축
두 번째 단계는 ‘애플리케이션 취약점 개발자 자체 점검 체계 구축’으로 전 단계에서 개발된 개발 보안 정책을 점검 룰 셋으로 설정하고 개발자들에게 배포하여 개발자들은 툴 기반으로 일관된 보안정책에 의해 개발을 진행하게 된다. 기존에 문서 형태로 제공되던 개발 보안 정책을 ‘툴’의 형태로 제공하여 개발자는 툴 사용법 및 간단한 보안 개발 교육만으로 자체 보안점검 능력을 보유하게 되며 이러한 환경을 바탕으로 개발단계부터 개발자에 의한 자체 보안 분석과 개선을 통해 근본적인 취약점 발견 및 제거를 수행하게 된다.
● 정기 점검 체계 구축
세 번째 단계는 ‘정기 점검 체계 구축’으로, 이는 각 모듈 별 취약점은 개발자에 의해 조치되지만 모듈들이 모여 전체 프로그램이 되었을 때 모듈간의 플로우 상에서 발생 가능한 취약점 발견 및 개발된 애플리케이션에 대한 검증을 위함이다. 별도의 분석 시스템을 구축하여 일간 또는 주간단위로 정기적으로 소스에 대한 전수 검사를 수행 하며 배치 작업을 통해 자동으로 소스코드를 취합하여 전수검사를 하도록 구성하고 그 결과는 360 Server에 취합되어 자동으로 보안 관리자에게 통보하도록 구성한다. 또한 발견된 취약점에 대해서는 해당 개발자에게 통보하여 즉시 조치하도록 한다.
● 변경관리 프로세스와의 통합
네 번째 단계는 기업에서 사용중인 변경관리 프로세스와의 통합 작업이며 변경관리와의 통합을 통해 애플리케이션에 대한 변경 관리시 보안 검증까지 동시에 행하도록 하여 기존 변경관리 기능에 보안 검토 프로세스를 동시에 행하도록 구축한다. 또한 이러한 시스템을 구축하기 위해서는 운영중인 변경관리 프로세스의 일부 변경 및 커스터마이징이 필요하게 된다.
K은행의 경우에는 내부 통합 품질 관리시스템과 연계하여 신규 개발·운영시 애플리케이션의 품질 및 보안관점에서 통합하여 관리되도록 구성하여 운영하고 있다. 일반적으로 최초 적용 시 운영중인 애플리케이션에 대한 보안 분석을 하기 때문에 발견된 취약점들에 대한 조치를 위해 개발자들의 업무 로드가 발생 되나 취약점 조치 후 일정 수준의 보안 레벨에 이르게 되면 취약점에 대한 관리가 가능해 지게 되며 나아가 개발자 스스로가 보안을 고려한 개발을 행하는 개발자들의 레벨 업 효과도 발생하게 된다.
● 개발 보안 교육 및 인식 확산
다섯 번째 단계는 ‘개발자 개발 보안 교육 및 인식 확산’으로 보안은 보안 관리자의 몫이라고 생각하게 되지만 애플리케이션 영역에서는 코드를 생산하는 개발자가 실제적인 보안 주체가 되어야 한다. 그러므로 개발자의 스킬업이 반드시 필요하게 되며 이를 위해 구축된 보안 개발 프로세스에 대한 인식 확산과 애플리케이션 보안에 대한 일반 지식이 함께 교육 되고 몸에 배어야 한다. 지속적인 보안 개발 교육과 구축된 시스템 운용을 통해 빠른 기간에 보안 개발 프로세스에 적응 하게 된다.
개발 초기 단계부터 개발보안 프로세스 적용
개발 완료 후 사후 관점에서 애플리케이션 취약점 조치는 조치를 위한 리소스 및 비용의 한계가 분명히 있으므로 개발 초기부터 보안을 고려한 코딩을 할 수 있도록 개발보안 프로세스를 정립하는 것이 중요한 요소이다. 그러므로 개발 초기 단계부터 개발보안 프로세스를 적용하는 것이 매우 중요하다 할 수 있겠다.
이러한 구축 단계를 통해 최종적으로 기업은 ‘보안이 고려된 상시 개발 프로세스’를 통해 개발팀, 보안팀, QA팀 등 각 업무 부서별 개발 단계별 업무 분장을 효과적으로 확립 하여 애플리케이션 보안 문제를 근본적으로 해결 할 수 있는 시스템을 갖추게 된다.
-
개발팀 : 개발시 자체 보안 점검 수행
-
QA팀 : 소스코드 개발분 취합 및 정기 전수 분석 수행 및 결과 검토, 문제 발견시 개발팀에 수정 요청
-
보안팀 : 개발 보안 정책 설정, 개발자 교육, 보안 점검 현황 모니터링
<글 : 김태형 기자(is21@boannews.com)>
[월간 정보보호21c 통권 제107호 (info@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
[2024-05-16] 
.jpg)
