on
MS SDL이란? (2)
본 내용은 머리 속에 있는 내용을 정리하기 위한 포스팅으로, 잘못된 설명이나 오역이 있을 수 있습니다. 전반적으로 쭉 읽어보는 정도로 접근하시면 감사하겠습니다. :)
이번 과정에선 SDL의 모델을 확인하고 각 과정에서 어떠한 요소를 체크하는지 알아보겠다. 마이크로소프트는 이 SDL을 최적화하여 다음과 같은 모델을 제시하였다.
이 스텝은 Training과 Response를 제외하면 소프트웨어 개발 생명 주기와 유사한 구조를 가진다. 실제로 마이크로소프트는 이 SDL을 기존 SDLC에서 보안성과 개인정보보호 측면을 보강하기 위함이였기 때문에, 유사한 구조를 가지게 된것으로 보인다.
이제 각 단계별로 어떠한 역할을 수행하는지 알아보겠다.
Pre-SDL Requirements : Security Training
이 단계는 프로젝트 시작전 사전 단계로 모든 소프트웨어 개발팀이 보안과 개인정보보호의 최신 트렌드와 기본적인 보안 개념을 학습하는 단계이다. SDL에 따르면 소프트웨어 개발 인력에 대해 매년 최소 한번의 보안 트레이닝 클래스를 참석하도록 하고 있다고 한다. 여기서 말하는 보안 트레이닝은 단순히 어떠어떠한 해킹 기법이 있으며, 어떠한 취약점이이 있다 선에서 끝나는게 아닌, 몸으로 실제 위협을 느낄 수 있는 수준으로 진행한다고 한다. 마이크로소프트에선 이러한 사전 보안 교육으로 상당 수의 취약점을 감소시킬수 있었다고 설명하고 있다.
이 과정은 크게 보안성을 고려한 설계, 위협 모델링, 보안 코딩, 보안 테스팅, 개인정보보호로 이루어져 있다.
Phase 1: Requirements
이 단계는 SDL이 각각의 프로젝트에 관여하는 단계로 다양한 버그와 공격 기법을 분류하는 보안 버그 분류 프로세스를 재정의하고 신종 공격을 파악하여 이에대한 조치 방안을 강구한다. 이 단계에선 특히 자금에 대한 고려가 필요함을 강조하며, 자금을 고려하지 않고 보안성을 높이게 되면, 프로젝트 수행 자체가 어려워질 수 있기 때문에, 보안의 강도와 자금간의 조정이 필요하다고 설명하고 있다.
이 과정은 보안 요구사항 수립하고 버그 관리 방법 정의 및 보안 리스크 관리 방안을 짜는 것 등을 들 수 있으며, 전체적인 프로젝트 수립 시점에 해결할 수 있는 보안 이슈를 해결하고 설계 및 구현 단계에서 고려해야할 항목을 준비해야 한다.
Phase 2: Design
디자인은 보통 설계라고 명명하며, SDL에선 프로젝트의 전반적인 계획을 세우는 단계라고 명시하고 있다. 설계 단계에선 위협 모델링(Theat Modeling)을 수행해야 한다고 설명하고 있다. 위협 모델링은 어떠한 위협이 어떤 식으로 자산에 피해를 줄 수 있을지 판단하는 것으로, 세 가지 일반적인 모델링 접근 방법이 존재한다. 모의 해킹에서도 취약점 진단을 수행하기 전에 수집된 정보를 기반으로 진행하는 것으로, 시스템의 운용 및 사용 방법이 기술된 시스템 설계를 기반으로 공격자가 해당 시스템의 fail을 유발시키는 방법 등을 들 수 있다.
몇가지 예를 들어보면, 개발할 소프트웨어가 네트워크 통신을 하는 경우 윈도우의 방화벽 정책을 어떻게 할 것인가를 기준으로 다양한 설계가 이루어질 수 있다. 방화벽 자체를 Disable 시킬 수도 있을 것이며, 실행 시점에만 방화벽의 룰을 변경하고 종료 시점에 되돌릴 수도 있을 것이다. 만약 어떤 시그널을 받아서 행동하는 프로그램이라면, 인바운드 트래픽만 허용해두었다가, 시그널을 받고 응답 시에만 방화벽의 룰을 변경할 수 있을 것이다. 이런 세가지 사항에서도 위협 모델링을 고려하면, 보안을 고려한 효과적인 방법을 선정하여 설계에 반영할 수 있을 것이다.
참고로 마이크로소프트 내부에선 암호 사용에 대해 다음과 같은 사항을 최소 사항을 요구하고 있다.
- 대칭키 알고리즘을 사용하는 경우, AES로 암/복호화를 수행해야 하며, 128비트 이상의 키를 사용해야 한다.
- 공개키를 사용하는 경우엔 RSA를 사용해야 하며, 2048비트 이상의 키를 사용해야 한다.
- 해시는 SHA-256 이상을 사용해야 한다.
- (SDL 5.1부터) SSL을 지원해야 한다. 등
설계 시점에서 이러한 사항을 고려한다면, 소프트웨어의 전반적인 보안성을 높일 수 있게 된다. 참고로 마이크로소프트 오피스 2010의 경우엔 다음 사항을 설계 단계에서 고려했다고 한다.
- 네트워크에 저장한 파일에 대한 접근 차단 설정
- 오피스 파일 로드 시점에 파일 유효성 검사 및 제한된 보기 기능을 추가
- 500개가 넘는 위협 모델을 만들어 검토하여 1000개 이상의 잠재적 보안 문제를 해결
- 오피스 2010의 파일 암호화 지원
이러한 부분이 설계 단계에서 적절하게 고려된다면, 설계 단계에선 다른 포맷의 파일로 인해 취약점의 발생을 막을 수 있게 된다. 물론 개발 단계에서 이러한 설계 사항이 적절히 반영되지 않거나, 코딩 실수로 인해 문제가 발생하는 것은 설계 단계에서 고려할 수 없는 사항이므로 논외로 한다.
Phase 3: Implementation
이 단계에선 개발 단계에서 해결할 수 있는 다양한 보안 기법을 제시한다. 개발자에겐 가장 실질적인 개발 요구사항을 담고 있는 부분이라고 할 수 있다. 예를 들어 SDL에서 설명하는 코드 생성과 라이브러리 관리를 보면 다음과 같다.
- Unmanaged, Native C++은 Visual Studio 2010 컴파일러와 링커를 사용해야 하며, 빌드 옵션에 /GS, /DYNAMICBASE, /NX, /SAFESEH 를 적용해야 한다.
- Managed, C#은 Visual Studio 2008 SP1 이상의 환경에서 빌드해야한다. 이는 SP1부터 DEP를 지원하기 때문이다.
주기적으로 코드 분석 도구를 통해 문제점을 찾아 해결해야하며, C, C++, C#은 최신 코드분석 툴을 사용해야한다고 설명한다. 또한 커널 드라이버의 경우엔 마이크로소프트의 WDF(Windows Driver Foundation)의 드라이버 킷(WDK)에 있는 PREfast for Driver의 사용을 제안하고 있다.
추가적으로 취약점 발생 위험성이 상당히 높은 Banned API의 사용을 자제할 것도 작성되어 있다. 대표적인 것이 문자열 버퍼 핸들링 함수(ex. strcpy)가 있다. 마이크로소프트에선 banned.h 헤더를 제공하며, 프로젝트에 이를 추가하면, 이런 위험한 API가 존재할 경우 Warning을 출력할 수 있도록 하고 있다.
이 외에도 다양한 방법이 존재하며, 이 부분은 인터넷 검색을 통해 다양한 정보를 얻거나 다양한 보안 코딩 서적을 참조해야 한다.
마이크로소프트 오피스 2010의 경우엔 내부적으로 OACR(Office Automated Code Review)를 통해 자동화된 버그 산출을 수행한다고 말하고 있으며, 이전 제품(오피스 2007 등)에서 발생한 취약점의 경우 동일한 취약점이 다시 발생할 수 있기 때문에 취약점 리뷰를 통해 이를 해소한다고 말한다. 그리고 이전 버전에서 DEP, S
EHOP 방어 매커니즘 추가하였고, SharePoint 솔루션에 샌드박스