위협 모델링

위협 모델링은 시스템을 만들기 전에 무엇이 잘못될 수 있는지 미리 찾아 적는 작업입니다. 누가 무엇을 노리고 어디로 들어올지 설계도를 놓고 따져 봅니다. 찾은 위협마다 어떻게 막을지도 함께 정합니다. 다 만든 뒤에 고치는 것보다 설계에서 고치는 편이 훨씬 싸서 이 일을 앞당겨 합니다.

쉽고 빠른 이해

위협 모델링은 만들려는 시스템을 그림으로 그려 놓고 「여기서 무엇이 잘못될 수 있나」를 묻는 작업입니다. 사진 업로드 기능이라면 「남의 계정으로 올리면?」·「비공개 사진 주소를 누가 맞히면?」을 묻습니다.

이걸 건너뛰면 보안 문제를 출시 뒤에야 만납니다. 그때는 코드와 데이터와 사용자가 얽혀 있어서 고치기가 훨씬 어렵습니다.

하는 순서는 이렇습니다.

데이터가 어디서 어디로 흐르는지 그립니다
흐름마다 잘못될 수 있는 일을 찾습니다. 미리 나눠 둔 갈래를 하나씩 대 봅니다
찾은 일마다 막을지, 기능을 뺄지, 알고도 둘지 정합니다

처음 기능을 설계할 때 합니다. 바깥과 데이터를 주고받는 길이 새로 생기면 다시 합니다. 화면 문구만 고치는 변경이면 건너뜁니다.

대가는 시간입니다. 설계 회의가 길어집니다. 설계가 바뀔 때마다 그림과 목록도 같이 고쳐야 합니다.

상세

긴 여행을 떠나기 전에 짐을 싸다가 「비가 오면 어떡하지」·「지갑을 잃어버리면 어떡하지」 하고 묻는 사람이 있습니다. 그래서 가방에 우산을 넣고 카드사 전화번호를 수첩에 따로 적어 둡니다. 「소매치기가 노리면 어떡하지」도 묻습니다. 지갑은 겉주머니 대신 안주머니에 넣습니다.

위협 모델링은 소매치기를 떠올리던 그 물음을 시스템 설계에 대는 작업입니다. 공격자가 무엇을 노리고 어떻게 들어올지 따져서 대응을 정합니다.

로그인 기능을 설계하는 중이라고 해 봅시다. 「누가 비밀번호를 수만 번 넣어 보면 어떻게 되나」를 묻습니다. 그리고 로그인 시도 횟수를 제한한다는 대응을 설계에 적습니다.

이 작업이 다루는 단위는 위협입니다. 위협은 시스템에 일어나면 곤란한 일 하나를 말합니다. 「공격자가 남의 비밀번호를 맞혀 그 계정의 사진을 지운다」가 위협 하나입니다. 누가, 무엇을 해서, 무엇이 망가지는지가 한 문장에 들어 있어야 대응을 정할 수 있습니다.

위협과 자주 섞이는 말이 취약점입니다. 취약점은 코드나 설정에 이미 난 결함입니다. 위협은 결함이 있든 없든 일어나면 곤란한 일입니다. 그래서 코드가 한 줄도 없을 때도 위협은 물을 수 있습니다.

설계 단계에서 하는 까닭

보안 결함은 언제 찾느냐에 따라 고치는 품이 크게 달라집니다. 설계 문서에서 찾으면 문서 몇 줄과 회의 한 번으로 끝납니다. 출시 뒤에 찾으면 코드를 고쳐야 합니다. 이미 쌓인 데이터를 옮기거나 사용자에게 알리는 일까지 붙기도 합니다.

막을 곳을 모른 채 방어를 늘리면 힘이 엉뚱한 데 쓰입니다. 아무도 노리지 않는 데이터에 암호화를 겹겹이 두르는 사이, 로그인 없이 열린 관리용 기능이 남습니다. 위협 모델링은 어디가 노려지는지부터 적습니다. 그래야 방어를 거기에 모을 수 있습니다.

뼈대가 되는 네 물음

위협 모델링을 하는 방법은 여럿입니다. 그래도 뼈대는 물음 넷으로 모입니다. 물음마다 손에 남는 것이 하나씩 있습니다.

물음	하는 일	손에 남는 것
무엇을 만드나	데이터가 흐르는 길을 그린다	흐름을 그린 그림
무엇이 잘못될 수 있나	흐름마다 위협을 찾는다	위협 목록
어떻게 할까	위협마다 대응을 정한다	대응 목록
잘했나	대응이 설계와 코드에 들어갔는지 되짚는다	고친 설계

네 물음은 한 번 돌고 끝나지 않습니다. 설계가 바뀌면 첫 물음부터 다시 돕니다. 아래 소절들은 이 물음을 하나씩 따라갑니다.

데이터 흐름도와 신뢰 경계

첫 물음의 답은 대개 그림 한 장입니다. 이 그림을 데이터 흐름도라고 부릅니다. 데이터가 어디서 들어와 어디를 거쳐 어디에 쌓이는지를 화살표로 잇습니다. 말로 설명할 때 빠지던 연결이 그림에서는 드러납니다.

사진 업로드 서비스를 예로 들어 봅시다. 사용자는 브라우저에서 사진을 올립니다. API(Application Programming Interface, 응용 프로그램 인터페이스) 서버가 그 파일을 받아 파일 저장소에 넣습니다. 사진 제목과 올린 사람 같은 정보는 데이터베이스에 적습니다.

flowchart TD
    subgraph OUT["바깥 · 믿지 않는 구역"]
        U["사용자 브라우저"]
    end
    subgraph IN["우리가 관리하는 구역"]
        A["API 서버"]
        F["파일 저장소"]
        D["데이터베이스"]
    end
    U -->|"사진 파일"| A
    A -->|"파일"| F
    A -->|"사진 정보"| D

「우리가 관리하는 구역」 상자의 테두리를 신뢰 경계라고 합니다. 테두리 안은 우리가 관리하는 구역입니다. 테두리 밖, 곧 믿지 않는 구역에서 들어오는 것은 무엇이든 의심하고 받습니다.

위협은 이 테두리를 넘는 화살표에 몰립니다. 그림에서는 사용자 브라우저에서 API 서버로 가는 화살표가 그렇습니다. 사진 파일이라고 들어온 것이 사진이 아닐 수도 있기 때문입니다.

그림에 쓰는 요소는 넷입니다. 여기에 신뢰 경계가 하나 더해집니다. 위 그림의 이름과 맞춰 보면 이렇습니다.

요소	뜻	위 그림에서
외부 개체	우리가 통제하지 못하는 사람이나 시스템	사용자 브라우저
처리	데이터를 받아 무언가를 하는 프로그램	API 서버
저장소	데이터가 쌓이는 곳	파일 저장소 · 데이터베이스
데이터 흐름	요소 사이를 오가는 데이터	화살표 셋
신뢰 경계	믿는 정도가 바뀌는 선	「우리가 관리하는 구역」 상자의 테두리

요소를 이렇게 나누는 까닭은 요소마다 잘 나는 위협이 달라서입니다. 저장소에서는 몰래 읽히거나 바뀌는 일을 먼저 봅니다. 외부 개체에서는 남으로 위장하는 일을 먼저 봅니다.

위협을 빠짐없이 찾는 STRIDE

둘째 물음 「무엇이 잘못될 수 있나」를 맨손으로 물으면 떠오르는 것만 적게 됩니다. 사람마다 떠올리는 것이 달라서 빈칸이 생깁니다. 그래서 위협을 몇 갈래로 미리 나눈 목록을 옆에 두고 흐름마다 대 봅니다.

가장 널리 쓰이는 목록이 STRIDE(Spoofing · Tampering · Repudiation · Information disclosure · Denial of service · Elevation of privilege)입니다. 위협을 여섯 갈래로 나눈 목록입니다. 이름은 여섯 갈래 영어 이름의 머리글자를 이은 것입니다. 우리말 이름은 아래 표의 갈래 칸에 있습니다.

갈래마다 깨지는 성질이 하나씩 있습니다. 성질은 시스템이 지키기로 한 약속입니다. 위장이 통하면 「상대가 말한 그 사람이다」라는 약속이 깨집니다. 표의 마지막 칸은 사진 업로드 서비스에 대 본 예입니다.

글자	갈래	깨지면 잃는 성질	사진 업로드에서
S	위장	상대가 말한 그 사람이다 · 인증	남의 계정으로 로그인해 사진을 올린다
T	변조	데이터가 몰래 안 바뀐다 · 무결성	남이 올린 사진을 다른 파일로 덮어쓴다
R	부인	한 일을 나중에 잡아뗄 수 없다 · 부인 방지	문제 사진을 올린 사람이 안 올렸다고 우겨도 반박할 기록이 없다
I	정보 노출	허락된 사람만 본다 · 기밀성	비공개 사진의 주소를 맞혀 열어 본다
D	서비스 거부	필요할 때 쓸 수 있다 · 가용성	큰 파일을 끝없이 올려 저장소를 채운다
E	권한 상승	허락된 일만 한다 · 인가	일반 사용자가 관리자용 삭제 기능을 부른다

표는 한 줄이 물음 하나입니다. 「이 화살표에서 위장이 되나」·「이 저장소에서 변조가 되나」를 차례로 묻습니다. 여섯 줄을 다 물어도 걸리는 것이 없으면 다음 흐름으로 넘어갑니다.

찾은 위협을 다루는 네 길

위협 목록이 나오면 셋째 물음 「어떻게 할까」로 넘어갑니다. 위협 하나마다 고를 수 있는 길은 넷입니다.

길	하는 일	사진 업로드에서
줄인다	막는 장치를 단다	사진 주소를 맞힐 수 없는 긴 무작위 값으로 만든다
없앤다	위협이 생기는 기능을 뺀다	비공개 사진 기능을 이번에는 만들지 않는다
넘긴다	그 일을 더 잘 지키는 쪽에 맡긴다	로그인을 검증된 외부 로그인 서비스에 맡긴다
받아들인다	알고도 둔다. 누가 왜 그렇게 정했는지 적는다	사진 파일에 촬영 기기 이름이 남는 것을 알고도 둔다

대부분의 위협은 「줄인다」로 갑니다. 「받아들인다」도 정당한 선택입니다. 모든 위협을 막으려 들면 서비스를 못 내놓기 때문입니다.

받아들이기로 했다면 그 이유를 꼭 적어 둡니다. 적지 않은 위협은 받아들인 것이 아니라 잊은 것입니다.

위협이 수십 개 나오면 한꺼번에 막을 수 없습니다. 그래서 두 가지를 보고 순서를 정합니다. 얼마나 일어나기 쉬운가, 터지면 얼마나 아픈가입니다. 이렇게 순서를 매기는 일을 위험 평가라고 합니다.

대응을 되짚는 마지막 물음

네 물음의 마지막은 「잘했나」입니다. 대응이 종이에서 끝나지 않았는지 보는 물음입니다. 위협 목록의 줄마다 대응이 적혀 있는지 봅니다.

그 대응이 작업 목록이나 테스트로 옮겨졌는지도 봅니다. 목록에만 있고 코드에 없는 대응은 없는 대응입니다.

다시 돌리는 때와 건너뛰는 때

위협 모델링은 새 기능을 설계할 때 처음 합니다. 그 뒤로는 설계가 바뀔 때마다 모든 것을 다시 돌리지 않습니다. 가르는 기준은 신뢰 경계입니다. 경계를 넘는 흐름이 새로 생기거나 경계 안에 노릴 만한 것이 새로 들어오면 다시 합니다.

바뀐 것	다시 하나	까닭
외부 결제 서비스와 새로 연동한다	한다	경계를 넘는 흐름이 새로 생긴다
주민등록번호를 새로 저장한다	한다	노릴 이유가 큰 데이터가 들어온다
새 API 를 바깥에 연다	한다	바깥에서 닿는 지점이 는다
서버 안의 함수 구조를 정리한다	안 한다	흐름과 경계가 그대로다
화면 문구를 고친다	안 한다	데이터 흐름에 안 닿는다

대가도 분명합니다. 설계 회의에 사람과 시간이 듭니다. 그림과 목록은 설계를 따라 고치지 않으면 금방 낡습니다. 그리고 참여한 사람이 상상하지 못한 공격은 목록에 오르지 않습니다.

이웃 보안 활동과 가르기

보안을 챙기는 활동은 위협 모델링 말고도 여럿입니다. 이름이 나란히 나와서 섞이기 쉽습니다. 언제 하는지와 무엇을 보는지로 가르면 이렇습니다.

활동	언제	무엇을 보나
위협 모델링	설계할 때	우리 시스템의 흐름에서 벌어질 일
보안 코드 리뷰	코드를 쓴 뒤	코드에 난 결함
침투 테스트	만든 뒤	공격해 보면 뚫리는가
흔한 문제 목록 참고	언제나	여러 서비스에서 흔히 난 문제

흔한 문제 목록의 대표가 OWASP(Open Worldwide Application Security Project, 소프트웨어 보안 비영리 재단)가 내는 OWASP Top 10입니다. 이런 목록은 남들이 자주 당한 문제를 모은 것이라 우리 서비스만의 흐름은 모릅니다. 위협 모델링은 그 빈칸을 우리 설계도로 채웁니다.

반대로 위협 모델링은 상상한 공격만 다룹니다. 그래서 만든 뒤에 침투 테스트로 정말 막히는지 확인합니다. 네 활동은 서로를 대신하지 못합니다.

결과물로서의 위협 모델

위협 모델링이 끝나면 데이터 흐름도, 위협 목록, 대응 목록이 남습니다. 이 묶음을 통틀어 위협 모델이라고 부릅니다. 설계 문서 옆에 두고 설계가 바뀔 때 같이 고칩니다.

보안 논문이나 통신 규약 설명에서는 「위협 모델」을 더 좁은 뜻으로도 씁니다. 공격자가 무엇을 할 수 있다고 가정하는지 적은 전제입니다. TLS(Transport Layer Security, 전송 계층 보안)는 공격자가 네트워크를 오가는 데이터를 전부 엿보고 바꿀 수 있다고 가정합니다. 그 가정 아래에서도 대화 내용을 지키도록 설계됐습니다.

이 뜻의 위협 모델은 「안전하다」는 말의 범위를 정합니다. 「이 설계는 안전하다」에는 언제나 「이 가정 아래에서」가 붙습니다. 서버 컴퓨터 자체를 손에 넣은 공격자는 그 가정 밖에 있습니다. 그런 공격자 앞에서는 안전하다는 말이 성립하지 않습니다.

위협 모델링

상세

설계 단계에서 하는 까닭

뼈대가 되는 네 물음

데이터 흐름도와 신뢰 경계

위협을 빠짐없이 찾는 STRIDE

찾은 위협을 다루는 네 길

대응을 되짚는 마지막 물음

다시 돌리는 때와 건너뛰는 때

이웃 보안 활동과 가르기

결과물로서의 위협 모델

관련 항목

위협 모델링에서 쓰는 분석 기법

위협 모델링이 목록에 올리는 공격

위협 모델링이 지키려는 보안 성질

찾은 위협에 거는 대응 원칙

위협 모델링과 헷갈리는 이웃 용어

위협 모델링과 나란히 도는 보안 활동

위협 모델링이 참고하는 약점 목록과 분류 체계

위협 모델링이 붙는 설계 산출물