신뢰할 수 있는 컴퓨팅 보안 개발 주기

Steve Lipner
Michael Howard
보안 엔지니어링 및 통신
보안 비즈니스 및 기술 부서
Microsoft Corporation

2005년 3월

요약: 이 문서에서는 악의적인 공격에 대응하는 데 필요한 소프트웨어 개발을 위해 Microsoft가 채택한 프로세스인 신뢰할 수 있는 컴퓨팅 보안 개발 주기(SDL)에 대해 설명합니다. 프로세스는 Microsoft 개발 프로세스의 각 단계에서 보안에 중점을 둔 활동과 결과물을 포괄합니다. 이러한 활동과 결과물에는 소프트웨어 설계 과정의 위협 모델 개발, 구현 과정의 정적 분석 코드 검색 도구 사용, 중점적인 "보안 적용" 과정의 코드 검토와 보안 테스트 수행이 포함됩니다. SDL을 적용한 소프트웨어를 릴리스하기 전에 개발 그룹에서 독립된 팀의 최종 보안 검토를 거쳐야 합니다. SDL을 적용하지 않은 소프트웨어와 비교했을 때 SDL을 거친 소프트웨어는 보안 취약점의 외부 검색 비율이 상당히 줄어든 것으로 나타났습니다. 이 백서에서는 SDL에 대해 설명하고 Microsoft 소프트웨어에서 구현한 경험을 다룹니다. (인쇄 시 19 페이지)

참고 이 문서는 IEEE의 후원으로 2004년 12월 아리조나 주 투산에서 개최된 2004년 Annual Computer Security Applications Conference(연례 컴퓨터 보안 응용 회의)에서 발표한 "신뢰할 수 있는 컴퓨팅 보안 개발 주기"의 업데이트된 버전입니다.

내용

1. 소개
   1.1 기준선 프로세스
   1.2 보안 개발 주기 개요
2. 보안 개발 주기 프로세스
   2.1 요구 사항 단계
   2.2 설계 단계
   2.3 구현 단계
   2.4 검증 단계
   2.5 릴리스 단계
   2.6 지원 및 서비스 단계
3. Microsoft에서 보안 개발 주기의 구현
   3.1 SDL의 의무 적용
   3.2 의무 교육
   3.3 제품 팀을 위한 메트릭
   3.4 중앙 보안 팀
4. Microsoft에서 보안 개발 주기의 구현 결과
5. 보안 개발 주기 적용의 관찰
   5.1 SDL 요소의 효과
   5.2 도구, 테스트 및 코드 검토
   5.3 투자
   5.4 결과
6. 결론
7. 감사의 글
8. 참고 문헌
9. 고지 사항

1. 소개

모든 소프트웨어 공급업체는 보안 위협을 반드시 해결해야 합니다. 보안은 시장, 중요한 인프라를 보호할 필요성 및 컴퓨팅에서 폭 넓은 신뢰를 구축하고 유지할 필요성에 따라 소프트웨어 공급업체에 대한 핵심 요구 사항입니다. 모든 소프트웨어 공급업체의 주요 당면 과제는 패치를 통한 업데이트가 덜 필요하고 보안 관리의 부담을 줄여주는 보다 안전한 보안 소프트웨어를 만드는 것입니다.

소프트웨어 업계에서 현재의 개선된 보안에 대한 요구를 충족시킬 수 있는 열쇠는 적절히 개선된 보안을 안정적으로 제공하는 반복 가능한 프로세스를 구현하는 것입니다. 따라서 소프트웨어 공급업체는 보안에 더 많은 중점을 두는 보다 엄격한 소프트웨어 개발 프로세스로 전환해야 합니다. 이러한 프로세스는 설계, 코딩 및 설명서에 존재하는 보안 취약점 숫자를 최소화하고 가능한 개발 주기 초기 단계에서 이러한 취약점을 발견하여 제거하기 위한 것입니다. 인터넷으로부터 받는 입력을 처리하거나, 공격 받을 가능성이 있는 중요한 시스템을 제어하거나, 개인 식별 정보를 처리하는 데 사용되는 기업용 및 일반 소프트웨어에서 이 프로세스의 필요성이 가장 큽니다.

더욱 안전한 소프트웨어를 작성하려면 반복 가능한 프로세스, 엔지니어 교육 그리고 메트릭과 책임 등 세 가지 영역이 필요합니다. 이 문서에서는 SDL의 반복 가능한 프로세스에 중점을 두겠지만 엔지니어 교육을 설명하고 SDL 하위 집합의 적용 날짜에 대한 영향을 보여주는 몇 가지 전반적인 메트릭도 제공합니다.

Microsoft의 경험을 가이드로 하여 다른 조직에서 SDL을 채택하는 경우 소프트웨어 개발에 적절하지 않은 비용을 추가해서는 안 됩니다. Microsoft가 얻은 경험은 비용보다 더욱 안전한 소프트웨어의 이점(즉, 적은 패치와 향상된 고객 만족)이 훨씬 두드러진다는 점입니다.

SDL은 소프트웨어 보안을 개선할 수 있는 조치를 통합함으로써 소프트웨어 개발 조직의 프로세스를 수정하는 것을 포함합니다. 이 문서는 이러한 조치를 요약하고 일반적인 소프트웨어 개발 주기에 통합되는 방식을 설명합니다. 이렇게 수정하는 이유는 프로세스를 완전히 변경하는 것이 아니라 잘 정의된 보안 검사점과 보안 결과물을 추가하려는 것입니다.

이 문서에서는 최적의 보안 방법과 프로세스 개선을 개발 및 발전시키고, 조직 전체에 전문 지식을 제공하고, 소프트웨어를 릴리스하기 전에 검토(최종 보안 검토 또는 FSR)를 수행하는 중앙 그룹이 회사(또는 소프트웨어 개발 조직) 내에 있다고 가정합니다. Microsoft의 경험으로 볼 때 이런 조직은 SDL의 성공적인 구현과 소프트웨어 보안 개선에 중요합니다. 반면에 일부 조직에서는 "중앙 보안 팀" 역할을 계약자 또는 컨설턴트에게 맡기는 것을 고려할 수도 있습니다. 이 문서는 소프트웨어 보안을 개선하기 위한 일련의 단계를 대규모 소프트웨어 개발 조직에서 일반적으로 사용하는 소프트웨어 개발 프로세스에 통합하는 것을 설명합니다. 이러한 단계는 Microsoft가 신뢰할 수 있는 컴퓨팅 프로젝트(Trustworthy Computing Initiative)의 일환으로 설계하고 구현한 것입니다. 이 프로세스 개선의 목표는 고객이 사용하는 소프트웨어에서 보안 취약점의 수와 위험 등급을 줄이는 것입니다. 이 문서에서 Microsoft가 현재 구현 중인 수정된 소프트웨어 개발 프로세스는 신뢰할 수 있는 컴퓨팅 소프트웨어 개발 주기(또는 간단히 SDL)라고 합니다.

Microsoft는 소프트웨어 설계와 개발 동안 자주 상호 작용할 수 있는 보안 팀이 있어야 하고 민감한 기술 및 비즈니스 정보가 신뢰할 수 있어야 한다는 것을 경험을 통해 알게 되었습니다. 이런 이유로 팀 구성원을 조직하고 교육시킬 컨설턴트를 고용할 수도 있지만 소프트웨어 개발 조직 내에 보안 팀을 구성하는 것이 더 좋습니다.

1.1 기준선 프로세스

Microsoft에서 일반적으로 허용되는 소프트웨어 개발 프로세스는 대개 그림 1과 같은 흐름을 따릅니다. 높은 수준에서 보면 이 프로세스는 일반적인 업계 관행입니다.

그림 1. 표준 Microsoft 개발 프로세스(확대하려면 이미지를 클릭)

그림 1은 5가지 일정을 보여주고 "워터폴(waterfall)" 개발 프로세스를 제안하는 것처럼 보이지만 실제로는 프로세스가 나선형 구조로 되어 있습니다. 요구 사항 및 설계는 변화하는 시장 요구 및 소프트웨어 구현 동안 발생하는 현실에 맞추어 종종 구현 단계 동안 다시 방문하게 됩니다. 또한 개발 프로세스는 거의 모든 지점에서 코드를 실행할 것을 요구합니다. 따라서 개발팀이 지속적으로 테스트하고 사용할 수 있는 일련의 빌드를 전달하도록 각 주요 일정을 나눕니다.

1.2 보안 개발 주기 개요

실제 환경에서 소프트웨어의 보안에 대한 경험을 토대로 보다 안전한 소프트웨어 구축을 위한 높은 수준의 원칙을 수립했습니다. Microsoft는 이러한 원칙을 SD³+C 설계 보안(Secure by Design), 기본 보안(Secure by Default), 배포 및 통신 보안(Secure in Deployment and Communications)이라고 부릅니다. 이러한 원칙을 간단히 정의하면 다음과 같습니다.

설계 보안: 소프트웨어는 자기 자신과 처리하는 정보를 보호하고 공격에 대응하도록 구조화되고 설계되고 구현되어야 합니다.
기본 보안: 실제 환경에서 소프트웨어는 완벽한 보안을 달성하지 못하므로 설계자는 보안 결함이 있을 수 있다고 가정해야 합니다. 공격자가 이러한 남아 있는 결함을 공격할 때 발생하는 피해를 최소화하려면 소프트웨어는 기본 상태에서 보안 수준을 강화해야 합니다. 예를 들어, 소프트웨어는 최소한의 필요한 권한을 사용하여 실행해야 하며, 폭 넓게 필요하지 않는 서비스 및 기능은 기본적으로 해제하거나 소수의 사용자만 액세스할 수 있도록 해야 합니다.
배포 보안: 소프트웨어와 함께 도구 및 지침을 제공하여 일반 사용자 및/또는 관리자가 안전하게 사용할 수 있도록 해야 합니다. 또한 업데이트를 배포하기 쉬워야 합니다.
통신: 소프트웨어 개발자는 제품 취약점의 발견에 대비해야 하고 일반 사용자 및/또는 관리자가 보호 조치(패치 적용 또는 해결 방법 배포)를 취할 수 있도록 공개적으로 책임감을 갖고 정보를 제공해야 합니다.

SD³+C의 각 요소는 개발 프로세스에 요구 사항을 부과하지만 첫 번째 두 가지 요소(설계 보안 및 기본 보안)는 대개 보안 이점을 제공합니다. 설계 보안은 처음에 취약점이 발생하지 않도록 예방하는 프로세스를 요구하지만 기본 보안은 소프트웨어의 기본 노출 즉, "공격 허점"을 최소화할 것을 요구합니다.

SD³+C 패러다임을 기존 개발 프로세스에 통합하는 보안 조치를 도입하면 그림 2의 전체 프로세스 조직이 발생합니다.

그림 2. Microsoft 개발 프로세스에 대한 SDL 개선(확대하려면 이미지를 클릭)

이 문서의 2장에서는 SDL의 구성 요소를 높은 수준에서 설명합니다. 3장에서는 Microsoft에서의 SDL 구현에 대한 상세 내용을 간단히 요약합니다. 4장에서는 이전 소프트웨어 버전과 비교하여 Microsoft Windows Server 2003 및 기타 소프트웨어의 개발 과정에서 SDL의 초기 적용으로 보안 취약점 수가 줄어들고 보안 취약점 위험 등급이 낮아지는 것을 보여주는 몇 가지 그림 데이터를 제공합니다. 5장에서는 SDL을 적용한 Microsoft의 경험을 토대로 프로세스의 요소에 대해 몇 가지 질적인 관찰을 제공합니다. 마지막으로 6장에서는 전체적인 결론을 제공합니다.

2. 보안 개발 주기 프로세스

앞에서 설명한 것처럼 엔지니어 교육은 이 문서의 범위를 벗어납니다. 그러나 교육 프로그램이 SDL의 성공에 중요하다는 것을 인식해야 합니다. 대학과 대학교의 전산, 컴퓨터 공학 및 관련 학과 졸업생들은 일반적으로 현업에 바로 투입하거나 안전한 소프트웨어를 설계, 개발 또는 테스트하는 데 필요한 교육이 부족한 상태로 배출됩니다. 보안 교육 과정을 이수한 사람들조차 버퍼 오버런이나 정규화 결함보다는 암호화 알고리즘이나 액세스 제어 모델에서 문제에 봉착할 가능성이 더 많습니다. 일반적으로 업계의 소프트웨어 설계자, 엔지니어 및 테스터도 적절한 보안 기술을 제대로 갖추지 못한 것이 현실입니다.

이러한 상황에서 보안 소프트웨어를 개발하려는 조직은 엔지니어링 직원이 적절한 교육을 받을 수 있도록 배려해야 합니다. 이 당면 과제를 해결하는 방법은 조직의 규모와 리소스 가용성에 따라 다릅니다. 엔지니어링 직원 수가 많은 조직은 사내 프로그램을 구축하여 엔지니어들에게 지속적인 보안 교육을 제공할 수 있으며, 소규모 조직은 외부 교육에 의존해야 할 수 있습니다. Microsoft에서는 소프트웨어 개발에 관여하는 모든 직원이 매년 "보안 보충" 교육을 이수하도록 하고 있습니다.

2.1 요구 사항 단계

보안 시스템 개발의 기본 사항은 "기초부터 다시" 보안을 고려할 것을 요구합니다. 많은 개발 프로젝트가 이전 릴리스를 토대로 "다음 버전"을 생산하지만, 새 릴리스나 버전의 요구 사항 단계 및 초기 계획은 보안 소프트웨어를 구축할 가장 좋은 기회입니다.

요구 사항 단계 동안 제품 팀은 중앙 보안 팀과 접촉하여 계획을 진행하면서 연락 지점, 리소스 및 가이드의 역할을 하는 보안 전문가(Microsoft에서 SDL의 구현에서는 "보안 친구"라고 함)를 배정해 줄 것을 요청합니다. 보안 전문가는 계획을 검토하고 필요한 사항을 권고하고 보안 팀이 제품 팀의 일정을 지원하는 적절한 리소스를 계획할 수 있도록 함으로써 제품 팀을 지원합니다. 보안 전문가는 프로젝트 규모, 복잡성 및 위험 요소를 기반으로 요구되는 보안 일정 및 종료 기준에 대해 제품 팀에 조언합니다. 보안 전문가는 제품 팀이 프로젝트 시작부터 최종 보안 검토와 소프트웨어 릴리스를 완료하는 단계까지 보안 팀과 연락을 취합니다. 보안 전문가는 보안 팀과 제품 팀 관리자 사이의 연락 창구 역할을 하며 프로세스 마무리 단계에서 보안 관련 문제가 발생하지 않도록 프로젝트의 보안 요소를 추적할지 여부를 팀 관리자에게 조언합니다.

요구 사항 단계는 제품 팀이 개발 프로세스에 어떻게 보안을 통합하고, 주요 보안 목표를 식별하고, 계획과 일정 중단을 최소화하면서 소프트웨어 보안을 극대화할 것인지 고려할 기회입니다. 이 프로세스의 일환으로 팀은 소프트웨어의 보안 기능과 보장 조치를 해당 소프트웨어와 함께 사용할 다른 소프트웨어와 어떻게 통합할지 고려해야 합니다. 다른 소프트웨어와의 인터페이스는 개별 제품을 보안 시스템에 통합하는 사용자 요구를 충족시키기 위한 중요한 고려 사항입니다. 보안 목표, 당면 과제 및 계획에 대한 제품 팀의 전반적인 관점은 요구 사항 단계 동안 생성된 계획 문서에 반영되어야 합니다. 프로젝트가 진행되면서 계획은 변경될 수 있지만 이렇게 초기에 계획을 조율하면 요구 사항이 누락되거나 나중에 갑자기 발생하는 것을 예방할 수 있습니다.

각 제품 팀은 보안 기능 요구 사항을 이 단계의 일부로 간주해야 합니다. 일부 보안 기능 요구 사항은 위협 모델링에 대응하여 식별되지만 사용자 요구 사항은 고객 요구에 따라 보안 기능을 포함할 것을 요구합니다. 보안 기능 요구 사항은 업계 표준 준수 필요성과 공통 기준 같은 인증 프로세스에 의해서도 발생합니다. 제품 팀은 이러한 요구 사항을 통상적인 계획 프로세스의 일부로 인식하고 반영해야 합니다.

2.2 설계 단계

설계 단계에서는 소프트웨어의 전체적인 요구 사항 및 구조를 식별합니다. 보안의 관점에서 설계 단계의 주요 요소는 다음과 같습니다.

보안 아키텍처와 설계 지침 정의: 보안의 관점에서 소프트웨어의 전체적인 구조를 정의하고 어떤 구성 요소가 올바르게 작동하는 것이 보안에 필수적인지 식별합니다("신뢰할 수 있는 컴퓨팅 기초"). 계층화, 강력하게 형식화된 언어 사용, 최소 권한의 응용 프로그램 및 공격 허점의 최소화와 같이 소프트웨어에 전역적으로 적용되는 설계 기술을 파악합니다. (계층화 는 구성 요소 간에 순환적 종속성을 피하도록 구조화된 잘 정의된 구성 요소로 소프트웨어를 구성하는 것을 말합니다. 구성 요소는 계층으로 구성되며 더 높은 계층은 낮은 계층의 서비스를 사용할 수 있는 반면, 낮은 계층은 높은 계층에 종속되는 것이 금지됩니다.) 아키텍처의 특정 개별 요소는 개별 설계 사양으로 세부화되지만 보안 아키텍처는 보안 설계의 전체적인 관점을 식별합니다.
소프트웨어 공격 허점의 요소를 문서화합니다. 소프트웨어가 완벽한 보안을 달성하지 못하는 경우 기본적으로 많은 사용자가 사용할 기능만 모든 사용자에게 제공하고 이러한 기능은 가능한 최소 수준의 권한을 갖도록 설치하는 것이 중요합니다. 공격 허점의 요소를 측정하면 기본 보안에 대한 지속적인 메트릭을 제품 팀에 제공하고 소프트웨어가 공격에 더 취약한 인스턴스를 검색할 수 있습니다. 증가된 공격 허점의 몇 가지 인스턴스는 향상된 제품 기능이나 사용 가능성으로 정당화될 수 있지만 가능한 기본 구성을 보호하여 소프트웨어를 출시하도록 설계와 구현 단계 동안 이러한 각 인스턴스를 찾아 문제를 짚고 넘어가는 것이 중요합니다.
위협 모델링을 수행합니다. 제품 팀은 구성 요소 수준에서 위협 모델링을 수행합니다. 구조적 방법을 사용하여 구성 요소 팀은 소프트웨어가 관리해야 하는 자산과 이러한 자산을 평가할 수 있는 인터페이스를 식별합니다. 위협 모델링 프로세스는 각 자산에 손해를 입힐 수 있는 위협과 손해 가능성(위험 예측)을 식별합니다. 구성 요소 팀은 암호화 같은 보안 기능의 형태 또는 손해로부터 자산을 보호하는 소프트웨어의 적절한 기능적 형태로 위험을 완화하기 위한 대책을 식별합니다. 따라서 위협 모델링은 제품 팀이 보안 기능의 요구 뿐만 아니라 특히 신중한 코드 검토와 보안 테스트가 필요한 영역을 식별합니다. 위협 모델링 프로세스는 저장과 업데이트를 위해 시스템이 읽을 수 있는 형태로 위협 모델을 캡처하는 도구에서 지원해야 합니다.
보충 출시 기준을 정의합니다. 기본 보안 출시 기준은 조직 수준에서 정의해야 하지만 개별 제품 팀 또는 소프트웨어 릴리스는 소프트웨어를 릴리스하기 전에 충족해야 하는 특정 기준을 가질 수 있습니다. 예를 들어, 고객에게 출시 중인 소프트웨어의 업데이트된 버전을 개발하는 제품 팀은 릴리스할 준비가 되었다고 간주하기 전에 일정 기간 동안 새로운 버전에 외부적으로 보고된 취약점이 없도록 확장된 공격을 받을 수 있도록 해야 할 수 있습니다. (즉, 개발 프로세스는 취약점이 보고된 후에 제품 팀이 "해결"하도록 하기 보다는 보고되기 전에 취약점을 발견하여 제거해야 합니다.)

2.3 구현 단계

구현 단계 도중에 제품 팀은 소프트웨어를 코딩하고 테스트하고 통합합니다. 이 단계 동안 보안 결함을 제거하거나 초기 삽입을 방지하기 위해 취한 단계는 상당히 유용합니다. 보안 취약점이 고객에게 릴리스되는 소프트웨어의 최종 버전에 포함될 가능성을 크게 줄입니다.

위협 모델링의 결과는 구현 단계 동안 특히 중요한 지침을 제공합니다. 개발자는 우선 순위가 높은 위협을 완화하는 코드의 정확성을 확보하는 데 주의를 기울이고 테스터는 이러한 위협이 실제로 차단되었거나 완화되었는지 확인하는 테스트에 집중합니다.

구현 단계에서 적용되는 SDL 요소는 다음과 같습니다.

코딩 및 테스트 표준을 적용합니다. 코딩 표준은 개발자가 보안 취약점을 일으킬 수 있는 결함이 발생하지 않도록 도움을 줍니다. 예를 들어, 보다 안전하고 일관성 있는 문자열 처리와 버퍼 조작 구조를 사용하면 버퍼 오버런 취약점이 발생할 가능성을 피할 수 있습니다. 테스트 표준과 최적의 방법은 테스트가 소프트웨어 기능의 정확한 동작에만 집중하기 보다는 가능한 보안 취약점을 검색하는 데 중점을 둘 수 있도록 합니다.
퍼징(fuzzing) 도구를 포함하여 보안 테스트 도구를 적용합니다. "퍼징"은 소프트웨어 취약점을 발생시킬 수 있는 오류를 최대한 검색할 수 있도록, 구조적이지만 잘못된 입력을 API(소프트웨어 응용 프로그래밍 인터페이스)와 네트워크 인터페이스에 제공합니다.
정적 분석 코드 검색 도구를 적용합니다. 도구는 버퍼 오버런, 정수 오버런 및 초기화되지 않은 변수를 포함하여 취약점을 발생시키는 몇 가지 종류의 코딩 결함을 검색할 수 있습니다. Microsoft는 이러한 도구 개발에 많은 투자를 했으며 새로운 종류의 코딩 결함과 소프트웨어 취약점이 발견되면서 이러한 도구(오랫동안 사용해 온 두 가지는 PREfix 및 PREfast로 알려져 있음)를 지속적으로 개선했습니다.
코드 검토를 수행합니다. 코드 검토는 숙련된 개발자가 소스 코드를 검사하고 잠재적인 보안 취약점을 검색하고 제거하도록 하여 자동화 도구를 보완합니다. 이것은 개발 프로세스 동안 소프트웨어에서 보안 취약점을 제거하는 프로세스에 중요한 단계입니다.

2.4 검증 단계

검증 단계는 소프트웨어가 기능적으로 완벽한지 확인하고 사용자 베타 테스트를 시작하는 지점입니다. 이 단계 동안 소프트웨어는 베타 테스트를 거치지만 제품 팀은 구현 단계 및 집중 보안 테스트에서 완료한 것 이외의 보안 코드 검토를 포함하는 "보안 푸시(security push)"를 수행합니다.

Microsoft는 Windows Server 2003 및 2002년 초반에 여러 가지 다른 소프트웨어 버전의 검사 단계 동안 보안 푸시를 도입했습니다. 보안 푸시를 프로세스에 도입한 데는 두 가지 이유가 있습니다.

해당 버전의 소프트웨어 주기가 검증 단계에 도달했고 이 단계는 필요한 코드 검토와 테스트를 수행하기 적절한 지점이었습니다.
검증 단계 동안 보안 푸시를 수행하면 소프트웨어의 완성된 버전을 대상으로 코드 검토와 테스트를 할 수 있으며 구현 단계 동안 개발되었거나 업데이트된 코드 및 수정되지 않은 "기존 코드"를 모두 검토할 기회를 제공합니다.

첫 번째 이유는 기록 사건, 즉 검증 단계 동안 처음 발생한 보안 푸시를 시작하기로 한 결정을 반영합니다. 그러나 Microsoft는 검증 단계 동안 보안 푸시를 수행하는 것이 실제로 최종 소프트웨어가 요구 사항을 만족시키고 이전 소프트웨어 버전에서 가져온 기존 코드를 심도 있게 검토할 수 있는 좋은 방법이라는 결론을 내렸습니다.

중요한 사실은 우선 순위가 높은 코드(소프트웨어의 "공격 허점"의 일부인 코드)의 코드 검토 및 테스트가 SDL의 여러 부분에 중요하다는 것입니다. 예를 들어, 모든 문제를 조기에 해결하고 이러한 문제의 원인을 식별하고 수정할 수 있어 이러한 검토와 테스트가 구현 단계에서 필요합니다. 또한 제품이 완성 단계에 이르렀을 때 검증 단계에서도 중요합니다.

2.5 릴리스 단계

릴리스 단계 동안 소프트웨어는 최종 보안 검토("FSR")를 받아야 합니다. FSR의 목적은 단 한가지 질문에 답하는 것입니다. "보안의 관점에서, 소프트웨어가 고객에게 인도될 모든 준비가 끝났는가?" FSR은 소프트웨어의 범위에 따라 소프트웨어를 완성하기 2-6개월 전에 수행됩니다. FSR을 수행하기 전에 소프트웨어는 릴리스에 앞서 최소한의 비보안 변경만 예상되는 안정된 상태에 있어야 합니다.

FSR은 조직의 중앙 보안 팀이 수행하는 소프트웨어 검토와는 별개입니다. 보안 팀의 보안 전문가는 소프트웨어가 필요로 하는 FSR의 범위를 제품 팀에 조언하고 FSR 이전에 리소스 요구 사항 목록을 제품 팀에게 제공합니다. 제품 팀은 FSR을 완수하는 데 필요한 리소스와 정보를 보안 팀에게 제공합니다. FSR은 제품 팀의 질문서 작성을 시작하고 FSR에 할당된 보안 팀 구성원과 면담합니다. FSR은 분석이 제대로 수행되었는지 확인하기 위해 초기에는 보안 버그로 식별되었지만 추가 분석에서는 보안에 영향을 주지 않는 것으로 확인된 버그 검토를 요구합니다. 또한 FSR은 유사한 소프트웨어에 영향을 주는 새로 보고된 취약점에 소프트웨어가 대응할 수 있는지도 검토합니다. 주요 소프트웨어 버전에 대한 FSR은 침투 테스트 및 보안 팀을 보조할 외부 보안 검토 계약자 사용도 요구합니다.

FSR은 단순한 통과/실패 연습이 아니며, 소프트웨어에 남아 있는 모든 보안 취약점을 찾는 것도 FSR의 목표가 아닙니다. 이것은 명백히 실천 불가능한 것입니다. 오히려 FSR은 제품 팀과 조직의 임원진에게 소프트웨어의 보안 상태 및 고객에게 릴리스된 후에 공격에 대응할 수 있는 가능성에 대한 전반적인 상황을 보여주는 것입니다. FSR에서 남아 있는 취약점의 패턴을 발견한 경우 적절한 대응은 발견된 취약점을 해결하는 것이 아니라 초기 단계로 돌아가 근본 원인을 해결하는 다른 조치(예: 교육 개선, 도구 개선)를 취하는 것입니다.

2.6 지원 및 서비스 단계

개발 도중 SDL을 적용했음에도 불구하고 최신 개발 방법은 아직 취약점이 없는 출시 소프트웨어를 지원하지 않습니다. 이렇게 하는 데는 그럴만한 이유가 있습니다. 개발 프로세스가 출시되는 소프트웨어에서 모든 취약점을 제거할 수는 있지만 새로운 공격이 발견되고 "안전한" 소프트웨어가 취약해질 수 있다는 것을 알게 됩니다. 따라서 제품 팀은 고객에게 출시되는 소프트웨어에서 새로 발견된 취약점에 대응할 준비를 갖추어야 합니다.

취약점 보고서를 평가하고 보안 전문가를 할당하고 적절할 때 업데이트를 준비하는 것이 대응 프로세스의 일부입니다. 대응 프로세스의 다른 구성 요소는 보고된 취약점에 대해 사후 검토를 수행하고 필요한 조치를 취하는 것입니다. 오류를 해결하는 업데이트를 제공하고, 코드 검색 도구를 업데이트하고, 주요 하위 시스템에 대한 코드 검토를 시작하는 등 취약점에 대한 대응 조치를 수행합니다. 대응 단계 동안의 목표는 오류에서 배우고 취약점 보고서에 제공된 정보를 사용하여 추가 취약점이 현장에서 발견된 경우 고객이 위험에 처하기 전에 제거하는 것입니다. 대응 프로세스는 제품 팀과 보안 팀이 유사한 오류가 향후에 다시 발생하지 않도록 프로세스를 개선하는 데도 도움을 줍니다.

3. Microsoft에서 보안 개발 주기의 구현

Microsoft 에서 SDL의 구현은 2002년 초 "보안 푸시" 이후로 발전되어 왔습니다. 프로세스를 시작하고 제품 개발 단계에서 많은 영향을 주기 위해 SDL의 여러 단계에 걸쳐 배포된 보안 푸시는 상대적으로 짧은 시간에 압축되었습니다. 보안 푸시는 제품 팀의 계획, 리소스 및 일정에 상당한 영향을 주었으며 Microsoft 임원진의 전폭적인 지원이 없었다면 시작하기가 훨씬 어려웠을 것입니다. 보안 푸시는 위협 모델링, 코드 검토 및 보안(침투 포함) 테스트에 집중되었습니다. 최종 보안 검토("FSR")는 Windows Server 2003을 릴리스하기 전인 2002년 말에 도입되었으며 FSR은 Windows Server 2003을 출시할 때의 기본 구성에 상당한 영향을 주었습니다.

초기 보안 푸시 및 FSR 이후에 Microsoft는 SDL 프로세스를 공식화하는 프로젝트에 착수했습니다. 이 프로젝트의 4가지 특정 결과는 언급할 필요가 있습니다.

SDL의 의무 적용을 구현하는 정책
엔지니어링 직원의 의무 교육
제품 팀의 메트릭
중앙 보안 팀의 역할

다음 장에서는 각 영역에 대해 설명합니다.

3.1 SDL의 의무 적용

SDL의 이점(5장 참조)을 보여주었지만 Microsoft는 광범위한 소프트웨어에서 SDL의 적용을 위한 요구 사항을 공식화하기로 결정했습니다. 이 문서 작성 현재 SDL은 다음과 같은 모든 소프트웨어의 의무적으로 적용되고 있습니다.

개인 또는 민감한 정보를 처리하는 데 사용될 예정인 소프트웨어
기업 또는 기타 조직(학계, 정부 또는 비영리 단체)에 사용될 예정인 소프트웨어
인터넷 또는 네트워크로 연결된 환경에 연결될 예정인 소프트웨어

의무 사항이 적용되지 않는 소프트웨어(예: "The Magic School Bus" 같은 유아용 게임)는 위의 기준에 맞지 않는 독립 실행형 응용 프로그램을 포함합니다. 특히, SDL은 이런 소프트웨어가 작동하는 플랫폼(운영 체제 또는 다른 소프트웨어)의 보안을 방해하는 것을 금지합니다.

3.2 의무 교육

초기 2002년의 보안 푸시의 한 가지 중요한 측면은 모든 개발자, 테스터, 프로그램 관리자 및 설명서 직원에 대한 제품 그룹 범위의 교육이었습니다. Microsoft는 소프트웨어에 SDL을 적용하는 조직에서 엔지니어의 연례 보안 교육을 위해 요구 사항을 공식화했습니다. 연간 업데이트 요구는 보안이 정적 도메인이 아니라는 사실에 따라 반영되었습니다. 위협, 공격 및 방어는 발전합니다. 결과적으로 소프트웨어에 영향을 미치는 보안 문제에 완벽한 역량과 자질을 갖춘 엔지니어도 위협 상황이 변함에 따라 추가 교육을 받아야 합니다. 예를 들어, 정수 오버플로 취약점의 중요성은 지난 4년 동안 극적으로 증가했으며 최근에는 일부 암호화 알고리즘이 이전에는 인식되지 않은 취약점을 갖고 있다는 것이 밝혀졌습니다.

Microsoft는 "라이브 교육"과 디지털 미디어 형태로 엔지니어에게 제공하는 보안에 대한 일반적인 소개와 업데이트를 개발했습니다. Microsoft는 이 강좌를 소프트웨어 기술과 엔지니어 역할에 따라 전문화된 교육의 기초로 사용했습니다. Microsoft는 수강생의 기술, 역할 및 경력 수준에 따라 세분화된 보안 교육 과정을 구축하는 과정에 있습니다.

많은 Microsoft 파트너와 고객이 Microsoft의 보안 교육과 프로세스를 이용할 수 있는지 문의했습니다. Microsoft Press는 보안 설계, 코딩 및 위협 모델링에 대한 Microsoft의 내부 경험을 책으로 출판했으며 Microsoft Learning은 Microsoft의 내부 방식을 토대로 한 강좌를 제공합니다.

3.3 제품 팀을 위한 메트릭

한 기업으로서 Microsoft는 "측정할 수 없는 것을 관리할 수 없다"는 속담으로 추친되고 있습니다. 소프트웨어의 보안을 신뢰성 있게 측정하는 메트릭을 고안하는 것은 매우 어려운 일이지만 소프트웨어 보안의 대용으로 이용하는 메트릭이 있는 것이 사실입니다. 이러한 메트릭은 엔지니어링 직원 교육(개발 주기 시작 단계)부터 고객에게 릴리스한 소프트웨어에서 발견된 취약점 해결까지 그 범위는 다양합니다.

Microsoft는 제품 팀이 SDL에서 구현 성공을 모니터링할 수 있는 여러 가지 보안 메트릭을 고안했습니다. 이러한 메트릭은 코드 검토와 보안 테스트를 통한 위협 모델링부터 FSR에 제시되는 소프트웨어 보안까지 SDL의 팀 구현을 해결합니다. 이러한 메트릭이 시간에 따라 구현되면서 팀이 자체 성능(개선, 변동 없음 또는 저하)은 물론 다른 팀과 비교한 성능을 추적할 수 있어야 합니다. 전체 메트릭은 선임 제품 팀 관리자와 Microsoft 임원에 정기적으로 보고됩니다.

3.4 중앙 보안 팀

2002년 보안 푸시 전에 Microsoft는 소프트웨어 보안을 개선하고 Windows의 취약점을 줄이고 Windows를 개발하는 사람 이외의 제품 팀에 보안 지원을 제공하는 역할을 하는 Secure Windows Initiative("SWI") 팀을 만들었습니다. SWI 팀은 Windows Server 2003 보안 푸시를 조직하고 관리하는 데 중심적인 역할을 수행했고 2002년에 시작한 모든 보안 푸시 노력에 대한 교육과 컨설팅 지원을 제공했습니다. 또한 SWI 팀은 Windows Server 2003에 대해 FSR을 실행하여 FSR 프로세스를 개척하기도 했습니다.

SDL의 공식적인 롤아웃과 함께 SWI 팀은 Microsoft에서 중앙 보안 팀 역할을 수행했습니다. SWI 팀의 책임은 다음과 같습니다

프로세스에 대한 의무 측면의 정의를 포함한 SDL의 개발, 유지 관리 및 개선.
엔지니어 교육의 개발, 향상 및 제공.
프로세스 전반에 걸쳐 제품 팀을 이끌고, 제품 팀을 위한 검토를 수행하고, 제품 팀 질문을 시기 적절하게 받고 정확하고 믿을만한 응답을 하는 "보안 전문가"의 제공.
광범위한 보안 사항에 대한 전문 지식을 제공하여 직접 또는 보안 전문가를 통해 받는 질문을 시기 적절하게 정확한 응답을 하는 서비스.
소프트웨어가 릴리스되기 전에 최종 보안 검토 실행.
고객에게 릴리스된 소프트웨어의 보고된 취약점을 기술적으로 조사하여 근본 원인을 이해하고 적절한 수준의 대응을 시작할 수 있도록 조치.

SWI 팀의 가용성과 효율성은 Microsoft에서 SDL을 구현할 때 주요한 요소로 입증되었습니다. Microsoft는 보다 안전한 소프트웨어 개발을 위한 확장 가능한 프로세스를 갖는 것을 목표로 하고 있으며 이 목표는 모든 제품 팀에 널리 배포된 보안 역량을 갖출 필요성을 암시합니다. 그러나 중앙의 매우 숙련된 보안 팀은 회사 전체의 제품 팀이 속도를 내고 보다 안전한 소프트웨어를 작성할 수 있도록 지원하는 중요한 역할을 수행합니다. 또한 제품 팀 외부의 직원이 FSR을 수행할 수 있도록 합니다.

4. Microsoft에서 보안 개발 주기의 구현 결과

Microsoft는 SDL이 Microsoft 소프트웨어의 보안을 개선한다고 결론을 내리는 것은 시기 상조이지만 지금까지의 결과는 고무적이라고 판단하고 있습니다.

Windows Server 2003은 SDL의 많은 부분을 구현한 Microsoft에서 첫 번째 운영 체제 릴리스입니다. 그림 3은 두 개의 최신 운영 체제인 Windows 2000과 Windows Server 2003을 릴리스한 후 게시된 보안 게시판 수를 보여줍니다. Windows 2000이 릴리스되었을 때 Microsoft는 공식적인 보안 게시판 위험 등급 시스템을 갖추고 있지 않았습니다. Microsoft는 현재 위험 등급 시스템으로 Windows 2000에 적용되는 각 보안 게시판을 평가했습니다. 이 백서 앞부분에서 설명한 것처럼 Windows Server 2003은 SDL 프로세스 대부분(모두는 아님)을 사용하여 개발되었고 Windows 2000은 이러한 프로세스를 사용하여 개발되지 않았습니다.

그림 3. SDL 이전과 이후 Windows의 긴급 및 중요 보안 게시판

위험 등급은 http://www.microsoft.com/technet/security/bulletin/rating.mspx (영문)에 정의되어 있습니다

다른 Microsoft 소프트웨어 릴리스도 SDL의 요소를 적용했습니다. SQL Server 및 Exchange Server 제품 팀은 보안 취약점과 기타 문제를 위한 수정 프로그램을 모은 소프트웨어 릴리스인 서비스 팩을 릴리스하기 전에 위협 모델링, 코드 검토 및 보안 테스트를 포함한 보안 푸시를 수행했습니다. SQL Server 보안 푸시의 결과는 SQL Server 2000 서비스 팩 3에 통합되었고 Exchange Server 보안 푸시의 결과는 Exchange 2000 Server 서비스 팩 3에 통합되었습니다. 그림 4와 5는 해당 서비스 팩의 릴리스 전과 후 같은 기간(SQL Server 2000의 경우 24개월, Exchange 2000 Server의 경우 18개월)에 릴리스된 보안 게시판 수를 보여줍니다.

그림 4. SDL 이전과 이후의 SQL Server 2000 보안 게시판

그림 5. SDL 이전과 이후의 Exchange Server 2000 보안 게시판

또 다른 고무적인 예는 Windows Server 2003의 Internet Information Server 구성 요소(IIS 6)입니다. 릴리스된지 2년 동안 Microsoft는 웹 서버에 영향을 주는 보안 게시판 하나가 게시되었으며 이것은 기본적으로 설치되지 않는 구성 요소(WebDAV)에 대한 것이었습니다.

보안 취약점의 예제가 아직 적고 기간이 제한되어 있지만 이러한 결과는 SDL이 효과적이라는 증거를 제공합니다. Microsoft는 초기의 추세가 지속되는지 확인하기 위해 Windows Server 2003 및 Exchange Server와 SQL Server 서비스 팩의 비율을 계속 모니터링할 것입니다. Microsoft는 SDL의 완벽한 구현 이후에 새 버전이 출시되면 다른 Microsoft 소프트웨어도 분석하여 보안 취약점의 수와 취약점의 위험 등급이 계속 떨어지는지 확인할 것입니다.

5. 보안 개발 주기 적용의 관찰

앞 장에서 제시된 데이터는 SDL로 "무엇"을 달성할 것인지에 대한 개요를 제공했습니다. 이 장에서는 프로세스가 "어떻게" 작동하는지에 대한 몇 가지 질문을 해 보겠습니다. Microsoft는 취약점 보고서와 보안 게시판을 엄격하게 추적하므로 앞 장은 딱딱한 숫자를 기준으로 했지만 이 장은 SWI 팀 구성원의 관찰과 의견의 형태로 이야기 식으로 전개됩니다.

5.1 SDL 요소의 효과

SDL은 소프트웨어 개발 주기 전체에 배포된 많은 수의 구성 요소 하위 프로세스로 이루어져 있습니다. SDL 팀은 효율성의 측면에서 어느 것이 가장 높은 이익이 있으며 무엇을 시도했고 효과가 떨어지는지 이러한 하위 프로세스의 우선 순위를 정해 달라는 요청을 받았습니다.

SWI 팀의 의견은 위협 모델링이 SDL의 구성 요소 중 가장 우선 순위가 높다는데 모아졌습니다. 명백히 위협 모델링은 격리에는 적용되지 않았습니다. 위협 모델링은 설계, 코드 검토 및 테스트를 수행하며 위협 모델링만 구현한 다음 모델에 대응하여 조치를 취하지 않은 프로세스(예를 들어, 예제에 대해 완화 효율성을 테스트하지 않음)는 전혀 효과가 없습니다. 버그 개수의 형태로 된 통계는 위협 모델링에 대한 많은 투자가 보안 취약점을 초래하는 버그가 절대 만들어지지 않도록 하기 때문에 위협 모델링의 역할을 과소 평가하는 경향이 있습니다. 그러나 안전한 소프트웨어를 개발하는 프로세스에 집중하는 위협 모델링의 역할은 목록 맨 위에 올라갈만큼 아주 중요합니다.

SDL은 Microsoft에서 상대적으로 새로운 프로세스이므로 프로세스의 한 구성 요소가 제거된 인스턴스는 아직 없었습니다. 그러나 장기간의 보안 연구를 통해 침투 테스트가 보안을 달성하는 방법이 아니라는 한 가지 사실은 밝혀졌습니다. 침투 테스트는 주요 소프트웨어 릴리스에 대한 최종 보안 검토(FSR)의 한 구성 요소지만 전체 주기에서 제품 팀 활동은 침투 테스트 대신 위협 모델링, 코드 검토, 자동화 도구의 사용 및 퍼징 테스트에 집중합니다. 후자는 고전적인 임시 침투 테스트보다는 보안 버그 예방 또는 제거를 훨씬 철저하게 측정합니다. FSR의 침투 테스트 요소는 보안 버그를 찾고 수정하는 방법이라기 보다는 소프트웨어를 릴리스할 준비가 되었는지 여부를 확인하는 데 도움을 줍니다. FSR의 침투 테스트 결과 보안 버그가 매우 많은 경우 이전 단계가 충분히 효과적이지 못하기 때문이며 올바른 대응은 침투 테스트 버그만 해결하기 보다는 이러한 단계에서 완료했어야 하는 작업을 다시 방문하고 소프트웨어를 릴리스하는 것입니다.

5.2 도구, 테스트 및 코드 검토

정적 분석 도구, 퍼징 테스트 및 코드 검토는 보완적입니다. Microsoft는 정적 코드 분석 도구에 집중 투자했으며 이러한 도구의 사용은 SDL의 중요한 부분입니다. 도구는 특히 버퍼 오버런 같은 보안 취약점을 초래할 수 있는 많은 코딩 오류를 찾는데 효과적입니다. 그러나 현재의 최신 도구도 모든 오류를 발견하지 못합니다. 도구가 해결하지 못하는 오류를 검색하고 도구의 개선 기회를 식별하기 위해 수동 코드 검토도 SDL에 필요합니다. 참조에 인용한 Michael Howard의 Microsoft Developer Network(MSDN) 문서는 Microsoft가 엔지니어에게 교육하는 코드 보안 검토를 수행하는 일반적인 접근 방식의 개요를 제공합니다.

퍼징 테스트를 크게 강조하는 것은 상대적으로 최근에 SDL에 추가되었지만 현재까지의 결과는 매우 고무적이라는 것입니다. 정적 코드 검색 도구와 달리 퍼징 테스트 도구는 테스트할 각 파일 형식 및/또는 네트워크 프로토콜에 대해 구축(또는 최소한 구성)해야 합니다. 이 때문에 정적 분석 도구에서 잡아 내지 못한 오류를 종종 발견할 수 있습니다. 위협 모델은 제품 팀이 테스트를 위한 인터페이스와 형식을 우선 순위화하는 데 도움을 줍니다. 퍼징 테스트 결과는 전적으로 결정적이지 않지만(도구는 유한 횟수의 주기 동안 실행되며 모든 버그를 찾는다는 보장이 없음) 경험에 의하면 적절한 수준의 퍼징 테스트를 수행하면 보안 취약점으로 악용될 수도 있는 "흥미로운" 버그를 찾을 가능성이 있습니다.

5.3 투자

의무 보안 교육은 Microsoft 엔지니어링 직원 규모를 가진 회사에게는 상당한 투자가 될 수 있습니다. 교육은 라이브(강사 주도형) 클래스와 온라인 자료의 조합으로 제공됩니다. 온라인 자료는 Microsoft 본사의 원격 사이트에서 소규모 엔지니어링 팀에 교육을 제공하는 도구로 특히 유용합니다. 라이브 교육은 보안 푸시 또는 다른 주요 작업을 준비하고 있는 팀을 위해 팀 수준에서 제공했을 때 특히 효과적인 것으로 입증되었습니다. 이 경우 Microsoft의 경험은 팀 교육이 강의실 교육 뿐만 아니라 보안 푸시 수행을 통해 진행할 것을 제안합니다. 보안 교육(일반적으로 반나절 과정)은 작업 그룹의 모든 사람이 보안에 집중한다는 사실로 의미가 확대됩니다.

중앙 보안 팀(SWI 팀)은 Microsoft가 보안을 강조한 지난 2년 동안 크게 성장했습니다. 팀은 Microsoft의 전체 엔지니어링 직원 수에 비하면 상대적으로 작으며 제품 팀과 함께 더욱 안전한 소프트웨어를 생산하기 위한 책임과 리소스를 보장하기 위해 "확장"하는 접근 방식을 강조합니다. 확장에 중점을 두는 몇 가지 전략은 교육과 도구에 대한 강조, 제품 팀이 팀의 문제를 해결하기 보다는 자신의 문제를 해결하도록 돕는 보안 전문가 제공 및 릴리스하기 위해 소프트웨어 준비에 대한 의견을 제품 팀에 제공하기 위한 검토(FSR 포함)의 사용을 포함합니다.

5.4 결과

SDL의 궁극적인 테스트는 Microsoft 소프트웨어의 취약점을 제거하고 완화하는 것입니다. 4장에서 요약한 경험은 SDL이 이 테스트를 충족시킨다는 것을 보여줍니다. Microsoft는 개발 중인 소프트웨어 버전에서 외부에서 보고된 취약점의 효과도 평가합니다. 최근의 경험은 새 버전에서 계획했거나 구현한 보안 조치가 기존 버전에 대해 효과적인 것으로 발견된 공격을 차단하며 그 수가 점차 늘어나는 것을 보여주었습니다. 최근에 릴리스한 Windows XP 서비스 팩 2는 이런 식으로 검토되었으며 계획했지만 아직 구현하지 않았거나 공개적으로 논의한 보안 변경 사항이 Microsoft 외부의 보안 연구자들에 의해 이전 버전의 Windows에 대해 보고된 상당 수의 취약점을 제거한 것으로 밝혀졌습니다.

6. 결론

Microsoft의 경험은 SDL이 보안 취약점의 사례를 줄이는 데 효과적이라는 것을 보여주고 있습니다. SDL의 초기 구현(Windows Server 2003, SQL Server 2000 서비스 팩 3 및 Exchange 2000 Server 서비스 팩 3)은 결과적으로 소프트웨어 보안을 크게 향상시켰으며 SDL의 향상을 반영하는 후속 소프트웨어 버전에서 소프트웨어 보안이 더욱 개선된 것으로 나타나고 있습니다.

SDL을 구성하는 요소의 점진적인 구현은 점진적인 개선을 낳았으며, 우리는 이것을 프로세스 유효성의 한 조짐으로 보고 있습니다. 프로세스는 완벽하지 않고 계속 발전하고 있으며 완벽에 도달하거나 예측 가능한 미래에 발전을 멈출 가능성도 없습니다.

Microsoft는 보안 개발 주기의 개발과 구현에 투자를 아끼지 않고 있으며 소프트웨어를 설계, 개발 및 테스트하는 방식도 크게 변하고 있습니다. 사회에 대해 소프트웨어의 증가하는 중요성은 Microsoft 및 업계가 소프트웨어 보안을 지속적으로 개선하라는 요구를 강조하므로 SDL에 대한 이 백서와 특정 기술에 대한 서적(참고 문헌 참조) 모두 소프트웨어 업계와 Microsoft의 경험을 공유하려는 노력으로 출판된 것입니다.

7. 감사의 글

이 문서의 초기 개발은 현 저자의 공동 노력으로 2002년말 시작되었습니다. 초안은 SDL이 발전하면서 업데이트되었고 현재 버전은 2004년 여름과 가을에 준비되었습니다. 저자는 SDL을 정의하고 다듬는 데 도움을 주신 Matt Thomlinson, Matt Lyons, Jamil Villani 및 Eric Bidstrup(모두 Microsoft Secure Windows Initiative 팀)에게 감사드립니다. 그 외에 Microsoft의 Scott Charney와 Phil Reitinger, Carnegie Mellon University의 Jeannette Wing도 초안에 대해 특히 도움이 되는 조언을 제공했습니다. 저자는 이 문서에 대해 조언과 자문을 해주신 Martin Abadi, Virgil Gligor, Dick Kemmerer, Chris Mitchell, Fred Schneider, Neeraj Suri 및 James Whittaker에게도 감사를 드립니다.

8. 참고 문헌

Mundie, Craig, Trustworthy Computing White Paper (영문)

Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users (영문), MSDN Magazine, 2004년 11월

Howard, Michael, Expert Tips for Finding Security Defects in Your Code (영문), MSDN Magazine, 2003년 11월

Howard, Michael and David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003

Swiderski, Frank and Window Snyder, Threat Modeling, Microsoft Press, Redmond Washington, 2004

9. 고지 사항

이 문서에 포함된 정보는 문서를 발행할 때 논의된 문제들에 대한 Microsoft Corporation의 당시 관점을 나타냅니다. Microsoft는 변화하는 시장 환경에 대처해야 하므로 이를 Microsoft측의 책임으로 해석해서는 안되며 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft는 그 정확성을 보증하지 않습니다.

이 문서는 오직 정보를 제공하기 위한 것입니다. Microsoft는 이 문서의 내용에 대해 명시적, 묵시적 또는 법률적으로 어떠한 보증도 하지 않습니다.

Microsoft, MSDN, Windows 및 Windows Server미국, 대한민국, 및/또는 그 외의 국가에서 Microsoft Corporation의 상표이거나 등록 상표입니다.

페이지 맨 위로