“개발 초기부터 개발보안 프로세스 적용해야”

‘포티파이 360’ 활용 방법론 중심으로

애플리케이션 기반의 업무가 늘어남에 따라 과거 몇 년간 국내에선 애플리케이션 해킹으로 인한 수많은 사고들이 발생했다. 그 피해 또한 종래의 것과는 비교할 수 없을 정도로 커졌다.

“모의해킹, 보안 취약점 완전히 제거 불가능”

이에 애플리케이션 보안의 중요성을 인식한 선도 기업을 중심으로 애플리케이션 보안 방안을 논의하기 시작했다.

기존의 애플리케이션에 대한 보안 검사는 개발 완료 후에 모의해킹 등의 사후 관점의 방법을 사용한다.

이 방법론은 보안 검사 결과 여러 취약점등의 오류가 발견됐다 하더라도 남은 개발기간과 비용의 문제, 더 나아가 이미 개발된 애플리케이션의 기술적인 문제로 인해 취약점을 제거하지 못할 가능성이 높다. 

 

[글: 한국포티파이소프트웨어 손장군 부장]

또한 개발과정 중에 보안을 고려하지 않기 때문에 일반적으로 조치해야 할 중요한 보안 문제들이 상당수 발견된다.

“개발 보안 프로세스, 취약점 찾아내기 한계”

이런 문제를 해결하기 위한 방법으로, 국내 기업들은 마이크로소프트, 오라클 등의 해외 기업에서 사용하고 있는 개발 보안 프로세스의 도입을 검토하게 됐다.

이런 방법은 설계 시에 보안에 대한 고려사항을 반영 하고 개발자가 애플리케이션 개발 시에 코드상에 보안 문제점이 없는지 분석해 보안 문제를 사전에 제거하고, 확산되지 않게 한다.

이를 통해 개발 완료 후에 조치해야 할 보안 취약점의 수를 급격히 줄일 수 있는 프로세스로서의 보안 개발 방법이다.

프로세스를 구축 하더라도, 개발자가 어떻게 보안 취약점을 찾아낼 수 있는지가 여전히 남은 이슈이다.

“일반 개발자, 보안 고려한 코딩 지식 못 갖춰”

개발자는 주어진 개발 기간에 목표된 기능을 구현하는 것이 주된 업무이며 보안전문가가 아니기 때문에, 보안이 고려된 코딩에 대한 전문 지식이 없는 것이 현실이다.

개발자에게 보안 코딩 능력을 손쉽게 부여할 수 있는 방법은 소스코드 보안 분석 툴을 개발자에게 배포하여 사용하도록 하는 것이며, 소스코드 보안 분석 툴의 전문 보안 지식을 통해 개발자는 손쉽게 보안코딩 여부를 검사하고, 문제점을 어떻게 개선할 것인가를 가이드 받게 된다.

“소스코드 보안 전문 분석 툴 적용만이 해법”

이러한 소스코드 보안 분석 도구로는 포티파이사와 온스랩사등이 제품을 출시 하고 있으며 국내의 경우 포티파이사의 ‘Fortify 360 ‘ 제품이 유일하게 국내 금융 및 대기업 군에 보급되어 ‘상시 개발보안 프로세스’ 구축 솔루션으로 사용되고 있다.

포티파이 360을 통한 개발 프로세스 구축은 다음과 같은 세부 항목으로 추진하게 된다.

- 애플리케이션 취약점 점검 지침 및 개발 보안기준 가이드 개발

- 애플리케이션 취약점 개발자 자체 점검 체계 구축

- 애플리케이션에 대한 정기적인 취약성 점검체계 구축

- 애플리케이션 상시 취약점 점검 시스템 구축

- 개발자 개발 보안 교육 및 인식 확산

단계로 ‘애플리케이션 취약점 점검지침 개발 보안기준 가이드 작성’하게 되며 그 가이드를 기준으로 포티파이 보안 점검 룰을 설계한다.

이를 위해 기업이 내부적으로 적용하고 있는 보안 지침을 분석하고 포티파이 개발 보안 정책을 바탕으로 개발 보안 정책을 수립하게 된다.

이를 통해 개발 정책을 가지고 있지 않거나 가지고 있더라도 형식적인 수준에 머물렀던 내용들을 현실화한 ‘개발 보안 기준’을 수립할 수 있게 된다.

번째 단계는 ‘애플리케이션 취약점 개발자 자체 점검 체계 구축’으로 전 단계에서 개발된 개발 보안 정책을 점검 룰 셋으로 설정하고 개발자들에게 배포해, 개발자들이 툴 기반으로 일관된 보안정책에 의해 개발을 진행할 수 있게 한다.

기존에 문서 형태로 제공되던 개발 보안 정책을 ‘툴’의 형태로 제공해, 개발자는 툴 사용법 및 간단한 보안 개발 교육만으로 자체 보안점검 능력을 보유하게 된다.

이러한 환경을 바탕으로 개발단계부터 개발자에 의한 자체 보안 분석과 개선을 통해 근본적인 취약점을 발견하고 제거할 수 있다.

번째 단계는 ‘정기 점검 체계 구축’. 이 단계는 각 모듈 별 취약점은 개발자에 의해 조치되지만 모듈들이 모여 전체 프로그램이 되었을 때 모듈 간의 플로우 상에서 발생 가능한 취약점 발견 및 개발된 애플리케이션에 대한 검증을 수행한다.

특히 별도의 분석 시스템을 구축해 일간 또는 주간 단위로 정기적으로 소스에 대한 전수 검사를 수행하며 배치 작업을 통해 자동으로 소스코드를 취합해 전수검사를 하도록 구성한다.

그리고 그 결과는 ‘360서버’에 취합되어 자동으로 보안 관리자에게 통보하도록 구성한다. 또한 발견된 취약점을 해당 개발자에게 통보해 즉시 조치하도록 한다.

번째 단계는 기업에서 사용중인 변경관리 프로세스와의 통합 작업이며, 변경관리와의 통합을 통해 애플리케이션에 대한 변경 관리 시 보안 검증까지 동시에 수행한다. 이를 통해 기존 변경관리 기능에 보안 검토 프로세스를 동시에 행하도록 구축한다.

또한 이러한 시스템을 구축하기 위해선 운영중인 변경관리 프로세스를 일부 변경하고, 커스터마이징까지 진행한다.

다섯 번째 단계는 ‘개발자 개발 보안 교육 인식 확산’. 보안은 보안 관리자의 몫이라고 생각하지만, 애플리케이션 영역에서는 코드를 생산하는 개발자가 실제적인 보안 주체가 돼야 한다.

이에 따라 개발자의 스킬업이 반드시 필요하며, 이를 위해 구축된 보안 개발 프로세스에 대한 인식 확산과, 애플리케이션 보안에 대한 일반 지식을 함께 교육하고, 나아가 이를 몸에 익혀야 한다.

또한 지속적인 보안 개발 교육과 구축된 시스템 운용을 통해 빠른 기간 내에 보안 개발 프로세스에 적응하게 된다.

개발 완료 후 사후 관점에서 애플리케이션 취약점 조치는, 조치를 위한 리소스 및 비용의 한계가 분명히 존재하기 때문에, 개발 초기부터 보안을 고려한 코딩을 할 수 있도록 개발보안 프로세스를 정립하는 것이 매우 중요하다.

그러므로 개발 초기 단계부터 개발보안 프로세스를 적용하는 것이 매우 중요함을 깨달아야 할 것이다.

<자료: 한국포티파이소프트웨어>  <데일리그리드>



저작권자 © 데일리그리드 무단전재 및 재배포 금지