• 아티클

Security Briefs

SDL 위협 모델링 도구 시작

Adam Shostack

목차

위협 모델링 프로세스 시작
위협 분석
환경 화면
보고서로 추적하기
Actions(작업) 메뉴
위협 모델링 회의
자산에 대한 고찰

fig01.gif

그림 1 위협 모델링 프로세스

2008년 11월 Microsoft는 SDL(Security Development Lifecycle) 위협 모델링 도구를 MSDN에서 무료 다운로드로 일반 사용자에게 제공한다고 발표했습니다. 이 칼럼에서는 SDL 위협 모델링 접근 방식을 도입하려는 팀의 프로세스를 살펴보면서 새 도구를 사용하여 보안 프로세스의 핵심이 될만한 뛰어난 위협 모델을 개발하는 방법을 알아봅니다.

이 칼럼은 SDL 위협 모델링에 대한 입문서가 아닙니다. SDL 위협 모델링과 관련하여 기본 지식이 필요한 독자는 2006년 11월호 MSDN Magazine에서 STRIDE 방식 사용에 대해 필자가 공동 집필한 "Threat Modeling: STRIDE 방식을 사용한 보안 설계 결함 탐색" 칼럼을 참조하십시오. 그림 1에는 이 프로세스의 간단한 개요가 나와 있습니다.

위협 모델링 프로세스 시작

SDL 위협 모델링 도구를 시작해보면 왼쪽 아래에 다이어그램, 분석, 환경 및 보고서라는 4개의 화면이 Microsoft Office Outlook과 매우 유사하게 구성되어 있습니다(그림 2 참조). 단, 실제 화면은 서로 밀접하게 관련된 위협과 완화를 모두 고려하여 구성되어 있으므로 그림 1의 개요와 다소 차이가 있습니다.

이 섹션에서는 Deb(개발자), Paul(프로그램 관리자), Tim(테스터)이 위협 모델을 처음으로 개발하는 과정을 따라가면서 도구의 각 화면에 대해 설명하겠습니다.

fig02.gif

"안녕, Deb. 이 위협 모델 다이어그램을 가지고 씨름하고 있는데 말이야, 세부적인 구현을 좀 도와주겠어?"

"물론이지, Paul. 어서 들어와."

Paul이 위협 모델 도구의 "Diagrams only(다이어그램만)" 보고서를 사용하여 이미 작성한 다이어그램의 인쇄본을 건넵니다. 이 다이어그램은 그림 3에 나와 있습니다.

"Paul, 이런 다이어그램은 처음 봐. 간단해 보이기는 하는데, 여러 가지 도형이 무엇을 의미하는지 설명해 주겠어?"

"여기 보이는 사각형은 Carl이라는 가상의 일반 고객을 외부 엔터티로 표현한 거야. Carl은 웹 서버에 명령을 보내고 있지. 여기 보이는 원은 실행 중인 코드이고 화살표는 통신 방향을 나타내지. 웹 서버가 조회하는 데이터베이스는 평행한 두 개의 직선으로 나타냈어. 데이터가 저장된 위치를 망라해서 데이터베이스로 나타낸 거야. 이 시스템을 DFD(데이터 흐름도)라고 하지. DFD에 대해 자세히 설명한 Wikipedia 기사를 참조하면 도움이 될 거야. 단, 여기에 점선으로 표시된 제어 권한이 있는 여러 사람 사이의 신뢰 경계에 대해서는 그 기사에서 다루지 않고 있지. 예를 들어서 IT 전문가가 로그인 정보를 Active Directory 시스템에서 관리하도록 하고 있기 때문에 Active Directory가 우리의 제어 권한 밖에 있는 것으로 표시되어 있어."

fig03.gif

그림 3 Paul의 DFD 다이어그램

도구를 시작하면 다이어그램 화면이 표시됩니다. Paul은 이 화면에서 Visio 도구와 제공된 스텐실을 사용하여 DFD를 작성했습니다(그림 4 참조). DFD 작성은 처음이지만 왼쪽의 유효성 검사기에 피드백이 나타나기 때문에 SDL의 일부로 위협 모델링을 사용한 경험을 살려 무리 없이 작성할 수 있었습니다. 오른쪽 위에 있는 Context(컨텍스트) 폴더를 마우스 오른쪽 단추로 클릭하여 세부 항목을 추가해 나가면서 복잡한 다이어그램을 그렸습니다.

그림 4 다이어그램 화면

위협 분석

분석 화면을 열었을 때 Paul은 잠시 당황했습니다(그림 5 참조). 대체 어디서 발생한 것인지도 모를 위협이 긴 목록으로 나열되었기 때문입니다. 이러한 위협 목록은 "요소당 STRIDE"라는 SDL 방식을 사용하여 구성됩니다. 이는 대부분의 소프트웨어가 그림 5와 같은 예측 가능한 일련의 위협 요소를 내재한 채 개발된다는 가정을 전제로 합니다. 보안 전문가들 중에는 해커를 쫓는 것 자체에 재미를 느껴 가장 우선시하는 사람이 많습니다. 하지만 집을 지키려면 상식적으로 출입문과 창문에 잠금 장치가 있는지를 먼저 살핀 후에 경보 시스템이 필요한지를 고려하는 것이 순서일 것입니다. 따라서 분석 화면의 행 중 하나를 클릭하여 요소당 STRIDE부터 시작합니다.

그림 5 분석 화면

Paul은 먼저 요소 목록에서 데이터베이스를 선택했습니다. 화면 맨 위에 표시된 대로 "database"가 데이터 저장소이기 때문에 변조, 정보 노출, 서비스 거부 공격 등의 대상이 된다는 사실을 확인했습니다. 그리고 아래에 있는 질문을 통해 사람들이 데이터를 어떻게 변조하는 지를 파악하고 데이터베이스에 연결하도록 허용할 사용자를 지정할 수 있었습니다. 드디어 화이트보드 다이어그램과 몇 가지 간단한 규칙을 통해 첫 번째 위협 요소가 파악되었습니다. 위협 모델링을 위한 첫 단계를 완료한 것입니다.

몇 분 동안 상의한 결과 액세스 제어와 역할에 대한 계획이 필요하다는 사실을 깨닫게 되었습니다. Paul이 두 가지 위협에 간단한 메모를 기록했습니다. 첫 번째는 "No access control plan(액세스 제어 계획 없음)"이라는 문구였고 TFS(Team Foundation Server) 데이터베이스에 작업 항목도 입력했습니다. 두 번째로 "Access control plan requires a role list(액세스 제어 계획에 역할 목록 필요)"라는 문구를 기록한 Paul은 TFS에서 첫 번째 버그에 종속된 두 번째 버그를 만들었습니다.

정보 노출 항목으로 이동한 Paul은 감사 및 보고서 생성용으로 사용할 읽기 전용 계정이 액세스 제어 계획에 필요하다는 것을 알게 되었습니다. 이것이 새로운 위협이 되는지 궁금했고 완화 방법이 동일하므로 위협이 되지 않는다고 판단하여 TFS에서 버그를 편집했습니다. 그런 다음 다른 곳에서 위협이 완화되었음을 확실히 하기 위해 "covered in TFS bug #235"라고 기록했습니다. 이렇게 하더라도 문제가 없다는 확신은 없었지만 그렇기 때문에 검증 기능이 필요한 것입니다(그림 6 참조).

그림 6 적용 안 되는 위협으로 검증

정보 노출에 대해 추가로 검토하는 과정에서 Paul은 백업 테이프를 암호화할 필요성을 인지하게 되었지만 백업 테이프 암호화는 운영상의 작업입니다. (이 문제를 추적한 과정은 관련 기능을 하나만 더 소개한 후에 설명하도록 하겠습니다. 그러면 먼저 화면 위쪽에 있는 "auto-generate threats for this element" 확인란을 살펴보겠습니다.)

자동 생성 기능은 위협 모델 수가 많고 테스터와 프로그램 관리자가 위협 모델의 내용에 대해 적극적으로 의견을 교환할 수 있는 체제가 완비된 대규모 팀을 위한 기능입니다. 예제 상황의 경우 자신이 작성한 기능과 어떻게 상호 작용하는지와 컨텍스트를 보여 주는 몇 가지 요소를 제시하는 역할은 Phil이 담당해야 한다고 여긴 Paul은 기본적으로 선택되어 있는 자동 생성 확인란을 선택 취소하고 Phil의 역할이라는 의견을 기록했습니다.

환경 화면

백업 테이프를 암호화하는 작업이 신경 쓰였던 Paul은 환경 화면을 열고 외부 보안 정보에 대한 섹션을 표시했습니다(그림 7 참조). 그리고 운영 팀에서 테이프 백업 작업을 처리해야 한다는 메모를 남겼습니다. 이 경우 운영 팀에 도구의 복사본이 제대로 전달되었는지 확인해야 합니다.

그림 7 외부 보안 정보

외부 보안 정보 섹션에 메시지를 작성하던 중에 문서 헤더 섹션에 대해 궁금해진 Paul은 안내 텍스트를 통해 위협 모델의 소유자와 대상 항목 등을 입력하는 섹션이라는 것을 알 수 있었습니다. Paul은 이 섹션을 작성하면서 Contoso 프로젝트 추적 번호를 입력할 수 있으면 좋겠다고 생각했습니다.

트리의 요소를 차례로 이동하면서 Paul은 SQL Server와 Fabrikam Foxy Web Widgets 2.3 위젯 라이브러리 간에 종속성이 있음을 기록했습니다. 또한 Tim이 SQL Server와 Fabrikam Foxy Web Widgets 2.3 위젯 라이브러리가 최신인지, Fabrikam에서 보안 알림을 받는지를 확인하기 위한 조사를 해야 한다는 내용을 추가했습니다.

보고서로 추적하기

다음 다섯 가지 위협 모델링 보고서를 사용할 수 있습니다.

Analysis Report(분석 보고서) 누구든 게시된 다이어그램 유효성 검사 항목, 작성된 위협, 완화 조치가 없는 위협, 위협으로 검증되거나 위협을 발생시키지 않는 것으로 표시된 항목 등을 확인하는 데 사용할 수 있지만 주로 보안 관리자나 컨설턴트가 위협 모델을 검토할 수 있도록 디자인된 보고서입니다.

Threat Model Report(위협 모델 보고서) 위협 모델에 입력된 정보를 단일 페이지 보기로 보여 주는 보고서입니다.

Diagrams Only(다이어그램만) 다이어그램 인쇄용 보고서입니다. 인쇄된 출력물을 작업에 사용하려는 경우 전체 페이지가 아니라 보고서만 쉽게 인쇄할 수 있습니다.

Bug Report(버그 보고서) 이 위협 모델에서 입력된 버그와 해당 버그의 상태를 보여 주는 보고서입니다.

Fuzzing Report(퍼지 테스트 보고서) 다이어그램 작성 단계에서 제공된 아키텍처 정보를 사용하여 우선 순위에 따라 나열된 퍼지 테스트 대상 목록을 보여 주는 보고서입니다. 퍼지 테스트는 프로그램에 대한 입력을 임의로 생성하는 방식의 테스트 기법입니다. 퍼지 테스트를 통해 프로그램의 작동이 얼마나 쉽게 중단되는지 확인하면 놀라실 겁니다. 게다가 이러한 작동 중단은 악용될 수도 있습니다. 퍼지 테스트에 대한 자세한 내용은 Team System용 사용자 지정 테스트 인터페이스 공급자 만들기 또는 Microsoft의 퍼지 테스트와 심사 프로세스를 참조하십시오.

Actions(작업) 메뉴

Actions(작업) 메뉴에는 Thumbnail(미리 보기), Bug Tracking Settings(버그 추적 설정), Team Lead Mode(팀장 모드) 등 몇 가지 유용한 기능이 포함되어 있습니다. Thumbnail(미리 보기)는 다른 화면에서 다이어그램에 쉽게 액세스할 수 있는 기능으로, 모델을 분석하는 동안 복잡한 다이어그램을 화면에 표시해 두고자 할 때 유용합니다. 창 크기에 맞추어 자동으로 크기가 조정되므로 창 크기를 변경하더라도 전체 다이어그램이 보기에 표시됩니다.

버그 정보를 입력하지 않은 채로 버그를 작성하려 하면 나타나는 버그 추적 대화 상자도 Actions(작업) 메뉴를 통해 언제든지 표시할 수 있습니다. 또한 매우 작은 XML 파일을 통해 입력할 필드를 정의할 수도 있고 기존 필드를 편집할 수도 있습니다("use template(템플릿 사용)" 확인란을 선택하지 않은 경우). 버그에는 "TM: [threat] affects [element]"라는 제목이 자동으로 지정되고 위협 및 완화 정보를 사용하여 내용이 자동으로 입력됩니다. 필드는 선택한 후에 Delete 키를 눌러 삭제할 수 있습니다.

Team Lead Mode(팀장 모드)를 선택하면 Describe Environment(환경 설명) 화면에 Template Settings(템플릿 설정)이라는 새로운 섹션이 표시됩니다. 이 섹션에서는 팀장이 위협 식별 과정을 안내하는 질문을 변경하고 위협 모델의 기본 저장 위치를 설정할 수 있습니다. 또한 팀장은 문서 헤더 정보의 필드를 편집하고 환경에 맞게 항목을 추가하거나 제거할 수도 있습니다.

앞서 원했던 대로 Paul은 Contoso 프로젝트 추적 번호를 새 필드로 추가했습니다. 팀장 모드에서 저장한 모든 위협 모델은 템플릿으로 사용할 수 있습니다. (사실 모든 위협 모델은 추가 작업을 위한 템플릿으로 사용할 수 있습니다.)

안내 질문을 변경하려면 SDL 위협 모델링 도구의 \Data 폴더에 생성된 XML 파일을 편집해야 합니다. 알아보기 쉬운 서식으로 되어 있으므로 쉽게 편집할 수 있습니다.

위협 모델링 회의

Paul이 동료 직원들에게 위협 모델을 보냈을 때 테스터인 Tim은 상당히 실망한 눈치였습니다. 그는 갖가지 불평을 쏟아내며 Paul에게 "프로그램 관리자는 항상 모든 기능이 잘 작동할 것이라고만 생각하죠?"라고 물었습니다.

이러한 테스터의 태도와 회의적인 반응은 위협 모델을 보완하는 데 중요한 역할을 하기도 합니다. 때문에 테스터에게 위협 모델링 프로세스의 팀장 역할을 맡기는 팀도 많습니다. 이 시나리오에서는 Tim이 위협 모델을 맡은 후 곧 위협 모델링 회의를 소집했습니다. 한 차례 회의를 통해 프로세스를 조율하고 다이어그램을 전반적으로 검토한 다음 두 번째 회의에서 위협을 검토하고 승인했습니다.

첫 번째 회의에서 Tim은 10분 동안 모든 참석자에게 SDL 위협 모델링 프로세스를 전반적으로 설명했습니다. 그리고 위협 모델 다이어그램을 보면서 자세히 검토하기 시작했습니다. 검토를 시작한지 5분도 채 안 되서 중요한 구성 요소가 빠져 있다는 사실을 발견했습니다.

몇 분 후 Tim과 Paul은 주제를 약간 벗어나 웹 서버를 실제로 어떻게 구축할지에 대해 논의하기 시작했습니다. 회의 진행 방식으로 바람직하다고 할 수는 없지만 결국 초기에 모순된 점을 발견함으로써 나중에 시간을 크게 절약할 수 있기 때문에 유익한 논의였다는 데 모두 동의했습니다.

두 번째 회의에서 팀원들은 위협을 전반적으로 검토하고 해결 방안을 논의하고 위협 모델을 승인했습니다. 그리고 문서를 소스 제어 단계로 체크 인하고 개발을 계속 진행했습니다.

자산에 대한 고찰

위협 모델링 경험이 있는 독자라면 자산에 대해 전혀 언급하지 않았다는 사실을 의아하게 생각할 수도 있을 겁니다. 소프트웨어 엔지니어는 소프트웨어에 대해서는 잘 알지만 자산이라는 개념과 공격자가 공격 대상으로 선호하는 자산에 대한 이해가 부족한 경우가 많습니다.

집에 대해서 위협 모델링을 수행한다면 먼저 가족이나 소중한 사진 또는 값비싼 미술품에 대해 생각해야 합니다. 또는 침입 가능성이 있는 사람이나 현재 보안 시스템에 대해 먼저 생각할 수도 있습니다. 아니면 수영장이나 현관과 같은 물리적 구조에 대해서 먼저 생각할 수도 있을 겁니다. 이러한 것들이 각각 자산, 공격자 또는 소프트웨어 설계에 해당한다고 할 수 있으며 세 가지 접근 방식 모두 유효합니다.

이 칼럼에서 제시한 위협 모델링 방식은 과거에 Microsoft에서 사용한 방식보다 훨씬 간단합니다. Microsoft SDL 팀에서는 이러한 소프트웨어 설계 방식이 다른 팀에도 유용하다는 사실을 알게 되었습니다. 여러분에게도 유용한 정보가 되기를 바랍니다.

질문이나 의견이 있으면 briefs@microsoft.com으로 보내시기 바랍니다.

Adam Shostack은 Microsoft SDL(Security Development Lifecycle) 팀의 프로그램 관리자로, SDL의 위협 모델링 부분을 담당하고 있습니다.