2016.03.17

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

강은성 | CIO KR
이번 칼럼에서는 지난 칼럼에 이어 보안 소프트웨어 개발생명주기(SSDL, Secure Software Development Lifecycle)를 좀더 세부적으로 살펴보려고 한다. 상용 소프트웨어를 개발하는 회사들은 소프트웨어 기획 - 요구사항 정의 - 설계 - 구현 - 시험(검증) - 출시 - 유지보수(운영)를 뼈대로 하는 개발 프로세스를 갖고 있기 마련이다.

SSDL에서는 각 개발단계에서 해야 할 보안활동을 정의한다. 개발단계별 대표적인 보안활동으로는 보안요구사항 작성(요구사항 정의단계), 위협모델링(설계단계), 보안 코딩, 정적 분석, 보안 코드리뷰(구현단계), 보안 테스트, Fuzz 테스트, 동적 분석, 침투 테스트(시험단계), 최종 보안점검(출시단계), 제품보안 이슈 대응(유지보수단계) 등이 있다.

[그림 1] 마이크로소프트의 Security Development Lifecycle(SDL)


요구사항 정의단계에서는 소프트웨어를 개발할 때 구현할 기능요구사항을 주로 작성하지만, 비기능적인 요구사항도 작성하는 것이 보통이다. 여기에는 품질, 성능, 운영, 인터페이스, 보안 요구사항이 포함된다.

보안요구사항의 예로는 다음과 같은 것들이 있다.

① 익명 사용자를 허용하지 않는다.
② 일반 사용자 계정으로는 관리 기능을 수행할 수 없다.
③ 원격에서 관리자 계정으로 시스템 접속 시 2단계 인증을 적용한다.
④ 전화번호와 거주지 상세 주소는 저장 및 전송 시 암호화한다.
⑤ 데이터 암호화 키는 별도의 하드웨어 보안모듈(HSM)에 저장한다.
⑥ 전사 서비스 개인정보 및 정보보호 정책에 따라 암호화 여부, 방법, 수준을 결정한다.
⑦ SSDL의 모든 보안활동을 적용한다.

보안요구사항은 기능요구사항과 마찬가지로 특정 기능이나 데이터에 대한 것(①~⑤)일 수도 있고, 여러 사항에 적용되는 정책적인 것(⑥~⑦)일 수도 있다. 어떤 것이든 요구사항 정의서(SRS, Software Requirement Specification)에 작성하는 것이 필요하다. 전사 개인정보 또는 보안정책 문서가 별도로 있다 하더라도 개발자가 구현하는 데 직접 영향을 미치는 사항이면 프로젝트에 해당하는 사항을 골라 SRS에 표시(기술)하거나 SRS에 보안정책을 준수할 것을 기록하는 것이 좋다. 그래야 이후 설계, 구현, 시험 단계의 개발자가 해당 보안활동을 빠뜨리지 않고 수행할 수 있다. (개발에서 가장 많은 역할을 하는 사람은 개발자이므로, 보안요구사항은 개발자가 이해하기 쉽게 작성해야 한다)

설계단계의 대표적인 보안활동으로 위협모델링이 있다. 위협은 시스템에 해를 미칠 가능성이다. 마이크로소프트의 SDL(Security Development Lifecycle)에서는 DFD(Data Flow Diagram)를 이용해 대상 시스템의 세부 구성을 기술한 뒤 여기서 나타날 수 있는 위협을 STRIDE, 즉 신분 위장(Spoofing identity), 데이터 변조(Tampering with data), 행위 부인(Repudiation), 정보 유출(Information disclosure), 서비스 중단(Denial of service), 권한 상승(Elevation of privilege)으로 분류하여 표시한다. 이러한 위협들은 정보보호가 달성하려는 목표인 인증(Authentication), 무결성(Integrity), 부인방지(Non-repudiation), 기밀성(Confidentiality), 가용성(Availability), 인가(Authorization)에 대응한다. 위협모델링을 해 보면 몇 단계만 내려가도 매우 복잡해 지고 시간과 노력이 많이 든다. 어느 수준에서 위협모델링을 마칠지 검토해 놓을 필요가 있다.

위협모델링에서는 예상되는 위협에 대한 보안대책을 수립하는데, 위협모델링을 몇 번 시행하면 보안대책의 풀이 생겨서 특정 위협에 대한 전사 표준대책을 마련할 수 있다. 참고로 실력이 충분하지 못한 조직에서는 국제표준이나 전사표준같이 검증된 대책을 이용하는 것이 좋다. 위협모델링에서 작성한 위협과 보안대책은 구현, 시험, 출시, 각 단계 보안활동의 입력으로 사용된다. 유지보수단계에서도 소스가 변경되면 기존 위협모델에 어떤 변화를 주는지 검토해야 한다.

구현단계에서 하는 대표적인 보안활동으로는 보통 보안 코딩(Secure coding)과 이를 점검하기 위한 정적 분석, 보안 코드리뷰가 있다. 보안 코딩은 취약점이 있는 함수나 로직을 쓰지 않도록 하는 것인데, 이를 점검하기 위해 정적 분석을 하거나 보안 코드리뷰를 수행한다. 정적 분석도구를 이용하면 소스를 분석하여 보안에 취약한 함수나 (일부) 로직을 탐지할 수 있는데, 주로 개발팀이나 품질관리팀에서 수행한다. 보안 코드리뷰는 보안요구사항, 위협모델링에서 수립된 보안대책이 제대로 구현되었는지 소스 코드를 점검하는 활동으로서 정적 분석에서 탐지하지 못한 보안취약점을 찾아내는 데 유용하다. 기존 코드리뷰 시간을 활용해도 좋다.

SSDL에서 특히 강조되는 활동이 유지보수단계에서 이뤄지는 보안이슈 대응 활동이다. 개발 프로세스에서는 별로 강조되지 않는 단계이고, 개발자들도 (남들이 작성해 놓은 소스를 다뤄야 하는) 유지보수 업무를 별로 좋아하지 않는다. 하지만 개발단계에서 미처 처리하지 못한 보안취약점이 있을 수도 있고, 보안취약점을 모두 없앴다 하더라도 출시 뒤 새로운 보안취약점이 발견될 수도 있다. '적'이 있는 보안의 특성상 이용자나 회사가 피해를 볼 수 있으므로 보안취약점이 발견되면 신속하고 정확하게 패치해야 한다. 따라서 제품 출시 이전에 보안이슈 대응을 위한 조직체계와 세부 프로세스, IT인프라를 갖춰야 한다.

이러한 SSDL의 보안활동은 세 차원의 연계가 이뤄질 때 효과적이다. 첫째, 보안활동이 개발 프로세스와 잘 연계되어야 한다. 사실 '연계'라는 말보다 잘 녹아 들어야 한다는 말이 더 어울린다. 보안활동에서 가장 많은 역할을 해야 하는 주체는 개발자이기 때문이다. 개발자가 개발을 잘하면 상당히 많은 보안문제를 해결할 수 있다. 개발의 전 과정에서 이슈추적시스템(ITS)을 이용해 보안문제를 다루는 것도 좋은 방법이다.

둘째, 보안활동 사이의 연계가 잘 이뤄져야 한다. 예를 들어 분석단계에서 작성된 보안요구사항은 이후 위협모델링이나 보안 테스트케이스에 반영되어 보안 테스트에서 검증되어야 하고, 위협모델링의 결과물은 보안 코드리뷰, 동적 분석, 침투 테스트의 입력이 된다. 입출력 관계가 있는 보안활동 사이의 연계가 잘 이뤄져야 효율적이고 효과적으로 보안취약점을 제거할 수 있다.

셋째, 처리주체 사이의 연계(협업)가 잘 되어야 한다. 보안활동에는 개발자, 아키텍트, 품질관리자, 테스터, 보안담당자 등 여러 주체가 참여한다. 개발 프로세스와 마찬가지로 각 처리주체가 자신의 업무에 능숙할 뿐 아니라 다른 주체의 관련 업무도 이해하고 있어야 협업이 잘 될 수 있다. 특히 공통자원인 품질이나 보안업무 담당자는 잘못하면 개발일정에 큰 영향을 미친다.


소프트웨어 개발회사들이 SSDL을 잘 운영함으로써 보안품질이 뛰어난 제품을 출시할 뿐 아니라 관련 조직 및 전사의 보안 역량이 성장하고, 전사적 시너지를 낼 수 있기를 바란다.

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



2016.03.17

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

강은성 | CIO KR
이번 칼럼에서는 지난 칼럼에 이어 보안 소프트웨어 개발생명주기(SSDL, Secure Software Development Lifecycle)를 좀더 세부적으로 살펴보려고 한다. 상용 소프트웨어를 개발하는 회사들은 소프트웨어 기획 - 요구사항 정의 - 설계 - 구현 - 시험(검증) - 출시 - 유지보수(운영)를 뼈대로 하는 개발 프로세스를 갖고 있기 마련이다.

SSDL에서는 각 개발단계에서 해야 할 보안활동을 정의한다. 개발단계별 대표적인 보안활동으로는 보안요구사항 작성(요구사항 정의단계), 위협모델링(설계단계), 보안 코딩, 정적 분석, 보안 코드리뷰(구현단계), 보안 테스트, Fuzz 테스트, 동적 분석, 침투 테스트(시험단계), 최종 보안점검(출시단계), 제품보안 이슈 대응(유지보수단계) 등이 있다.

[그림 1] 마이크로소프트의 Security Development Lifecycle(SDL)


요구사항 정의단계에서는 소프트웨어를 개발할 때 구현할 기능요구사항을 주로 작성하지만, 비기능적인 요구사항도 작성하는 것이 보통이다. 여기에는 품질, 성능, 운영, 인터페이스, 보안 요구사항이 포함된다.

보안요구사항의 예로는 다음과 같은 것들이 있다.

① 익명 사용자를 허용하지 않는다.
② 일반 사용자 계정으로는 관리 기능을 수행할 수 없다.
③ 원격에서 관리자 계정으로 시스템 접속 시 2단계 인증을 적용한다.
④ 전화번호와 거주지 상세 주소는 저장 및 전송 시 암호화한다.
⑤ 데이터 암호화 키는 별도의 하드웨어 보안모듈(HSM)에 저장한다.
⑥ 전사 서비스 개인정보 및 정보보호 정책에 따라 암호화 여부, 방법, 수준을 결정한다.
⑦ SSDL의 모든 보안활동을 적용한다.

보안요구사항은 기능요구사항과 마찬가지로 특정 기능이나 데이터에 대한 것(①~⑤)일 수도 있고, 여러 사항에 적용되는 정책적인 것(⑥~⑦)일 수도 있다. 어떤 것이든 요구사항 정의서(SRS, Software Requirement Specification)에 작성하는 것이 필요하다. 전사 개인정보 또는 보안정책 문서가 별도로 있다 하더라도 개발자가 구현하는 데 직접 영향을 미치는 사항이면 프로젝트에 해당하는 사항을 골라 SRS에 표시(기술)하거나 SRS에 보안정책을 준수할 것을 기록하는 것이 좋다. 그래야 이후 설계, 구현, 시험 단계의 개발자가 해당 보안활동을 빠뜨리지 않고 수행할 수 있다. (개발에서 가장 많은 역할을 하는 사람은 개발자이므로, 보안요구사항은 개발자가 이해하기 쉽게 작성해야 한다)

설계단계의 대표적인 보안활동으로 위협모델링이 있다. 위협은 시스템에 해를 미칠 가능성이다. 마이크로소프트의 SDL(Security Development Lifecycle)에서는 DFD(Data Flow Diagram)를 이용해 대상 시스템의 세부 구성을 기술한 뒤 여기서 나타날 수 있는 위협을 STRIDE, 즉 신분 위장(Spoofing identity), 데이터 변조(Tampering with data), 행위 부인(Repudiation), 정보 유출(Information disclosure), 서비스 중단(Denial of service), 권한 상승(Elevation of privilege)으로 분류하여 표시한다. 이러한 위협들은 정보보호가 달성하려는 목표인 인증(Authentication), 무결성(Integrity), 부인방지(Non-repudiation), 기밀성(Confidentiality), 가용성(Availability), 인가(Authorization)에 대응한다. 위협모델링을 해 보면 몇 단계만 내려가도 매우 복잡해 지고 시간과 노력이 많이 든다. 어느 수준에서 위협모델링을 마칠지 검토해 놓을 필요가 있다.

위협모델링에서는 예상되는 위협에 대한 보안대책을 수립하는데, 위협모델링을 몇 번 시행하면 보안대책의 풀이 생겨서 특정 위협에 대한 전사 표준대책을 마련할 수 있다. 참고로 실력이 충분하지 못한 조직에서는 국제표준이나 전사표준같이 검증된 대책을 이용하는 것이 좋다. 위협모델링에서 작성한 위협과 보안대책은 구현, 시험, 출시, 각 단계 보안활동의 입력으로 사용된다. 유지보수단계에서도 소스가 변경되면 기존 위협모델에 어떤 변화를 주는지 검토해야 한다.

구현단계에서 하는 대표적인 보안활동으로는 보통 보안 코딩(Secure coding)과 이를 점검하기 위한 정적 분석, 보안 코드리뷰가 있다. 보안 코딩은 취약점이 있는 함수나 로직을 쓰지 않도록 하는 것인데, 이를 점검하기 위해 정적 분석을 하거나 보안 코드리뷰를 수행한다. 정적 분석도구를 이용하면 소스를 분석하여 보안에 취약한 함수나 (일부) 로직을 탐지할 수 있는데, 주로 개발팀이나 품질관리팀에서 수행한다. 보안 코드리뷰는 보안요구사항, 위협모델링에서 수립된 보안대책이 제대로 구현되었는지 소스 코드를 점검하는 활동으로서 정적 분석에서 탐지하지 못한 보안취약점을 찾아내는 데 유용하다. 기존 코드리뷰 시간을 활용해도 좋다.

SSDL에서 특히 강조되는 활동이 유지보수단계에서 이뤄지는 보안이슈 대응 활동이다. 개발 프로세스에서는 별로 강조되지 않는 단계이고, 개발자들도 (남들이 작성해 놓은 소스를 다뤄야 하는) 유지보수 업무를 별로 좋아하지 않는다. 하지만 개발단계에서 미처 처리하지 못한 보안취약점이 있을 수도 있고, 보안취약점을 모두 없앴다 하더라도 출시 뒤 새로운 보안취약점이 발견될 수도 있다. '적'이 있는 보안의 특성상 이용자나 회사가 피해를 볼 수 있으므로 보안취약점이 발견되면 신속하고 정확하게 패치해야 한다. 따라서 제품 출시 이전에 보안이슈 대응을 위한 조직체계와 세부 프로세스, IT인프라를 갖춰야 한다.

이러한 SSDL의 보안활동은 세 차원의 연계가 이뤄질 때 효과적이다. 첫째, 보안활동이 개발 프로세스와 잘 연계되어야 한다. 사실 '연계'라는 말보다 잘 녹아 들어야 한다는 말이 더 어울린다. 보안활동에서 가장 많은 역할을 해야 하는 주체는 개발자이기 때문이다. 개발자가 개발을 잘하면 상당히 많은 보안문제를 해결할 수 있다. 개발의 전 과정에서 이슈추적시스템(ITS)을 이용해 보안문제를 다루는 것도 좋은 방법이다.

둘째, 보안활동 사이의 연계가 잘 이뤄져야 한다. 예를 들어 분석단계에서 작성된 보안요구사항은 이후 위협모델링이나 보안 테스트케이스에 반영되어 보안 테스트에서 검증되어야 하고, 위협모델링의 결과물은 보안 코드리뷰, 동적 분석, 침투 테스트의 입력이 된다. 입출력 관계가 있는 보안활동 사이의 연계가 잘 이뤄져야 효율적이고 효과적으로 보안취약점을 제거할 수 있다.

셋째, 처리주체 사이의 연계(협업)가 잘 되어야 한다. 보안활동에는 개발자, 아키텍트, 품질관리자, 테스터, 보안담당자 등 여러 주체가 참여한다. 개발 프로세스와 마찬가지로 각 처리주체가 자신의 업무에 능숙할 뿐 아니라 다른 주체의 관련 업무도 이해하고 있어야 협업이 잘 될 수 있다. 특히 공통자원인 품질이나 보안업무 담당자는 잘못하면 개발일정에 큰 영향을 미친다.


소프트웨어 개발회사들이 SSDL을 잘 운영함으로써 보안품질이 뛰어난 제품을 출시할 뿐 아니라 관련 조직 및 전사의 보안 역량이 성장하고, 전사적 시너지를 낼 수 있기를 바란다.

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

X