포티파이, 웹보안솔루션 구축사례

Chapter 4 - Case Study

웹 보안 솔루션, 이렇게 활용하라

개발프로세스에서 보안 검토

금융기관의 웹 취약점 사전 분석·점검에 효과적

웹 기반의 업무들이 늘어나고 그에 따라 웹 취약점을 이용한 보안 위협에 대비하기 위해 웹 애플리케이션 보안 방안에 논의가 시작되었다. 이전에는 대부분의 웹 애플리케이션 보안이 모의 해킹, 웹 취약점 점검 등과 같은 사후적인 관점에 초점이 맞추어져 있었고 사후적인 관점으로 웹 취약점을 점검하다 보니 점검시 마다 거의 동일한 취약점들이 반복되어 발견 되는 악순환이 계속되었다.

또한 전자금융법의 시행에 따라 외부적인 요소에 대한 규제가 시작되기 전에 웹 애플리케이션 보안 체계 구축이 필요했고 바젤 II나 사베인 옥슬리법 등으로 인해 내부 통제의 필요성도 대두되는 상황이었다.

은행들은 상용화된 일반 소프트웨어 패키지를 그대로 쓰는 경우가 거의 없으며 은행 내의 거의 모든 소프트웨어 프로그램들은 개발하거나 일반 패키지를 커스터마이징한 것들이다. 개발의 경우 과거엔 대부분 자체적으로 개발했지만 최근엔 점차 외부 개발업체에 아웃소싱으로 맡기는 비율이 늘고 있으며 은행 내 전산담당 직원들은 개발보다는 관리와 운영을 위한 인원이라고 해도 과언은 아니다.

은행들이 이처럼 개발을 외부 개발업체에 의존하다 보니 커뮤니케이션의 부족으로 애초에 계획했던 만큼의 결과를 기대하기란 매우 어렵다. 그렇다고 은행의 업무가 인터넷 뱅킹 등의 활성화로 365일 24시간 계속되는 상황에 프로그램 개발을 다시 원점으로 돌릴 수도 없는 상황이다. 또 프로그램 코딩 작업이 사람이 하는 일이라 설사 여러 취약점등의 오류가 발견됐다 하더라도 시스템을 무작정 중단시켜놓고 수작업에 의해 모든 소스를 하나하나 체크한다는 것도 사실상 불가능하다.

사후적인 웹 취약점 점검 관점이 아닌 웹 취약점에 대한 근본적인 원인 파악 및 조치, 그리고 개발 프로세스에서의 보안 검토 및 조치를 위해 소스코드 취약점 분석/점검 솔루션에 대한 검토가 시작되었으며 두 달여의 BMT 기간을 거쳐 Fortify Source Code Analysis가 선정 되어 프로젝트가 진행됐고 프로젝트를 통해 다음의 세부 과제들에 대한 구축을 목표로 했다.

●웹 취약성을 이용한 불법적인 침해사고를 사전에 방지

●웹 애플리케이션의 근본적인 취약점의 조기 발견 및 제거

●웹 애플리케이션의 개발 및 운영 프로세스 개선

●웹 취약점 점검 지침 및 개발 보안기준 가이드 마련

●웹 애플리케이션에 대한 상시/정기적인 취약성 점검체계 구축

안정화까지 총 4개월 정도의 시간이 소요되었고 총 3단계의 구축 작업을 했다. 첫 단계로 ‘웹 애플리케이션 업무 지침 및 보안가이드 작성’을 하였으며 그 가이드를 기준으로 포티파이 보안 룰을 설계하였다. 즉, 개발보안 지침을 ‘툴’화 하여 개발자들에게 배포한 상황이고 개발자들은 툴 기반으로 일관된 보안정책에 의해 개발을 행하게 되었다. 이러한 환경을 바탕으로 개발단계부터 개발자에 의해 근본적인 취약점 발견 및 제거를 행하게 되었으며 이 업무 프로세스는 인터넷 뱅킹 업무에 적용, 운영됐다.

두 번째 단계는 ‘정기 점검 체계 구축’으로, 이는 모듈 별 취약점은 개발자에 의해 조치되지만 모듈들이 모여 전체 프로그램이 되었을 때 모듈간의 플로우 상에서 발생 가능한 취약점 발견 및 개발된 애플리케이션에 대한 검증을 위함이었다. 정기점검 체계에는 두 가지 점검 방식을 적용 했는데 첫째는 정기적인 소스 전수 검사이며 야간 배치를 통해 정기적 전수검사를 하도록 구성했고 그 결과를 자동으로 보안 관리자에게 통보하도록 했으며 발견된 취약점에 대해서는 해당 개발자에게 통보하여 즉시 조치하도록 했다. 그 다음은 정기적으로 소스 관점이 아닌 공격자 관점의 보안 테스트를 수행하도록 하여 관리자 관점이 아닌 공격 관점에서 발생될 수 있는 취약점에 대한 보안 검사를 하도록 구성했다.

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

최초 적용 시 운영중인 애플리케이션에 대한 보안 분석을 하였기 때문에 발견된 취약점들에 대한 조치를 위해 개발자들의 업무 로드가 있었으나 취약점 조치 후 일정 수준의 보안 레벨에 다다르자 그때부터 웹 취약점에 대한 관리가 가능해 졌으며 나아가 개발자 스스로가 보안을 고려한 개발을 행하는 개발자들의 레벨 업 효과도 있었다.

은행 관계자에 따르면 “소스코드 보안 취약성 분석 및 조치는 은행들의 공통적인 숙제였다. 개발자에 의한 사고의 개연성은 언제나 상존했다. 보통 개발서버와 운영서버를 분리해서 운영하는데 문제를 검증하고 그 다음에 운영으로 넘기는 프로세스를 밟는 게 정상이다. 개발할 때는 직원이나 외부 직원이나 동일하기 때문에 문제가 발생할 소지가 크다. 이제 이 프로세스의 적용으로 사전에 취약성을 한 번 더 검증/조치하고 나갈 수 있게 됐다”고 밝혔다.

또한 그는 “개발 완료 후 사후 관점에서 애플리케이션 취약점 조치는 조치를 위한 리소스 및 비용의 한계가 분명히 있으므로 개발 초기부터 보안을 고려한 코딩을 할 수 있도록 개발보안 프로세스를 정립하는 것이 중요한 요소이다. 그러므로 차세대 개발 등의 개발 초기 단계부터 이러한 프로세스를 적용할 계획” 이라고 설명했다.

① 웹 개발 담당자는 소스코드 취약점을 자체 점검

② 변경관리(오로라)시스템에 인터넷 뱅킹 소스코드 변경 요청

③ 변경관리시스템은 소스코드의 취약점 점검을 웹 취약성 점검시스템에 요청

④ 웹 취약성 점검시스템은 소스코드의 보안 취약점을 점검해 변경관리 시스템에 전달

⑤ 변경관리 시스템은 소스코드가 취약점 없이 안전하면 인터넷 뱅킹 운영시스템에 적용하고 취약점이 발견되면 소스코드는 반송 처리하여 인터넷 뱅킹 운영시스템에는 적용 불가

⑥ 인터넷 뱅킹 운영 소스코드에 대해 정기적인 웹 취약점 전수 진단

<글·문성준 인터비젠테크놀로지 이사(moon.sj@interbizen.com)>

3월 15일부터 시행되고 있는 개정 개인정보보호법과 관련해 가장 까다롭고 이행하기 어려운 조항은 무엇인가요?
	인공지능(AI) 등 자동화된 결정에 대한 정보주체 권리 구체화
	접근권한 관리 등 개인정보 안전성 확보조치 강화 및 고유식별정보 관리실태 정기조사
	영향평가 요약본 공개제도 도입 등 개인정보 영향평가제도
	영상정보처리기기 및 안전조치 기준
	개인정보 보호책임자의 전문성 강화 위한 전문CPO 지정
	국외 수집·이전 개인정보 처리방침 공개 등 개인정보 처리방침 평가제도
	손해배상책임 의무대상자 변경 및 확대
	공공기관 개인정보 보호수준 평가 확대
	기타(댓글로)