쉽게 시작하는 위협 모델링

최근 들어 위협 모델링에 대한 이야기를 자주 하게 된다. AI처럼 새로운 기술이 등장할 때, 남들이 만들어놓은 체크리스트나 노하우가 없을 때 더 빛을 발휘하기 때문이다. 위협 모델링은 제품 혹은 조직의 위협을 식별하고, 각각에 맞는 대응 방안을 마련하는 과정이기 때문이다. 하지만 막상 위협 모델링을 접해보지 않은 사람들에게는 이 과정이 어렵고 복잡하게 느껴질 수 있다. 어떤 사람은 대학원에서나 다루는 학문이라고 생각하기도 한다. 이번 글에서는 위협 모델링이 무엇인지 간략히 살펴보고, 바로 실무에 적용할 수 있는 방법을 함께 알아보자.

위협 모델링은 무엇인가?

위협 모델링은 MBTI로 치면 N(직관)형 성향이다. 갑자기 MBTI라니… 유행에 뒤쳐지기 싫은 아저씨 티를 팍팍 내는 것 처럼 보이지만, MBTI에서 S(감각)형 성향은 현재의 사실이나 데이터를 바탕으로 판단하고, N 성향은 보이지 않는 가능성이나 미래의 시나리오를 상상하는 경향이 있다. 위협 모델링이 N형 성향과 비슷한 이유는, 실제로 일어나지 않은 보안 위협을 미리 상상하고 예방하는 과정이기 때문이다. 어떻게 보면 우리가 일상에서 하는 밸런스 게임을 보안쪽 세상에 옮긴 것이다. 가령, 개발 편의를 위해 22번 포트 오픈 VS 22번 포트를 닫고 별도의 접근 제어 제공과 같은 선택의 갈림길마다 위협을 식별하고 회사의 리소스에 맞는 통제를 만드는 것이 바로 위협 모델링이다.

민초 VS 반민초? 참고로 난 반민초

위협 모델링은 언제 시작해야 할까?

많은 조직이 보안 점검을 제품이 완성된 후에 시작한다. 하지만 위협 모델링은 개발이 시작되기 전, 즉 아이디어와 아키텍처가 만들어지는 순간부터 시작해야 한다. 우리가 가진 위협은 단순히 취약점만이 아니다. 보안 점검으로 취약점은 줄일 수 있어도 제품이 가진 전체 위협을 밝혀내기 쉽지 않다. 위협 모델링을 통해 공격 대상이 되는 자산이 무엇인지, 그 자산이 가지는 위협이 뭔지 식별해야 한다.
보안을 제품 개발의 마지막이 아닌, 처음 단계로 앞당길수록 수정 비용이 급격히 줄어든다. 이건 데이터를 제시하지 않아도 실무를 경험한 모두가 공감하는 부분일거라 생각한다. 따라서 위협 모델링은 제품 개발 단계에서 가능한 한 빨리 수행해야 한다. (말이 쉽지 이것 또한 하나의 챌린지다)
마지막으로, 위협 모델링은 한 번에 완벽하게 만들어야 하는 정적인 문서가 아니다. 제품은 성장하고, 인프라도 바뀐다. 제품이 살아있는 생명체기 때문에 위협 모델도 함께 진화해야 한다. 정기적으로 리뷰와 업데이트를 반복하면서 새로운 기능, 기술 스택, 위협 환경의 변화를 반영해야 한다.

실무에서 가볍게 적용하기

이제 위협 모델링의 중요성은 충분히 이해했다. 하지만 실제로 팀 내에서 위협 모델링 한 번 해보자라고 말하면, 대부분 막막해한다. 무엇을 준비해야 하는지, 누가 참여해야 하는지, 어떤 도구를 써야 하는지 감이 잘 오지 않기 때문이다. 사실 위협 모델링은 거창한 보안 프로젝트가 아니라, 팀이 함께 시스템을 바라보는 밸런스 게임을 하는 대화의 장으로 시작하면 된다.

사람: 위협 모델링에 누가 참여해야 하는가

위협 모델링을 어렵게 생각할 필요는 없다. 앞서 이야기했듯, 우리가 일상에서 하는 밸런스 게임의 확장판이라고 보면 된다. 이 기능을 추가하면 사용자 경험이 좋아지지만, 데이터 유출 위험이 커지지 않을까? 같은 질문을 던지는 사람이라면 이미 위협 모델링을 하고 있는 것이다.
이 과정에 특정 보안 지식은 필수적이지 않다. 소프트웨어 엔지니어, PO, PM 누구나 참여할 수 있다. 특히 제품의 비즈니스 모델을 깊이 이해한 사람일수록, 오히려 위협도가 높은 위협을 잘 식별할 가능성이 높다. 공격자는 취약점만 노리지 않는다. 사람, 프로세스와 알고리즘을 노리기도 한다.

도구: 시작은 단순하게

위협 모델링에는 특정한 도구나 플랫폼이 꼭 필요하지 않다. 화이트보드만 있어도 가능하다. 팀이 함께 제품의 아키텍처와 주요 데이터 플로우를 그려보면서, “이 구간에서 외부 입력이 들어오는데 검증은 충분할까?”, “사용자 데이터가 여기를 거쳐 나가는데 암호화는 되어 있나?” 이런 질문들을 자연스럽게 던지면 된다. 화이트보드 대신 포스트잇, draw,io, 등 같은 도구를 써도 전혀 상관없다. 핵심은, 우리 시스템과 데이터가 어떻게 흐르는지 시각화하는 것이다. 그 위에 위협을 하나씩 붙여 나가는 형태로 진행하면 된다.

식별: 위협 헌팅

이제 적절한 사람이 모였다면 위협을 찾는 단계다. 이 과정에서는 시스템이 어떤 방식으로 공격받을 수 있는지를 탐색한다. 즉, 공격자의 시선으로 시스템을 바라보는 것이다.

먼저, 이전 단계에서 만든 시각화된 정보를 기준으로 발생할 수 있는 문제를 떠올려보자. 어렵게 생각할 필요는 없다. 예를 들어, 집의 문이 있다고 치자 만약, 잠그지 않았다면 어떤 위협이 있을까? 인가되지 않은 사람이 문을 열고 들어올 수 있는 위험이 있다. 반대로, 문을 잠둬도 발생할 수 있는 위협이 있다. 설정된 비밀번호가 쉽다거나, 누가 뒤에서 비밀번호를 보기 쉬운 구조 등의 위협들이 있다. 이런 식으로 위협을 하나씩 찾아가면 된다. 다음은 위협을 탐색할 때 던질 수 있는 예시 질문들이다.

해당 컴포넌트에 외부 입력이 들어오는가? 만약 그렇다면 입력 값은 검증하고 있는가?
데이터가 저장되거나 전송되는 과정에서 암호화가 이루어지는가?
인증과 권한 부여는 어떤 방식으로 작동하는가?
로그를 저장하고 있는가? 로그에 민감한 데이터가 노출되지 않는가?

이런 질문들을 쌓아가면 잠재적인 위협들이 자연스럽게 드러난다. 하다 보면 생각보다 많은 위협을 인지하지 못했다는 사실을 발견할 것이다.

식별된 위협은 리스트 형태로 정리하자. 각 위협이 무엇인지, 어떤 항목에 어떤 영향을 줄 수 있는지를 간단히 기록해두면 다음 단계에서 진행이 수월해진다.

대응: 위협을 적절히 대응하기

위협 모델링의 목적은 위협을 모두 없애는 것이 아니다. 중요한 건 어떤 위협에 집중해야 하는지 우선순위를 정하고, 그에 맞는 통제(control)를 만드는 것이다.

1. 모든 위협을 대응할 필요는 없다

식별된 위협 중 일부는 이미 기존 보안 통제로 커버되고 있을 수 있다. 예를 들어, 비밀번호 장기 사용이라는 위협이 발견되었어도 강제 MFA 정책이 운영 중이라면 새로운 통제를 추가할 필요가 없다. 따라서, 우리가 실제로 대응해야 하는 위협과 이미 통제가 적용된 위협을 구분하는 단계가 필요하다.

2. 위협에 등급을 부여하라

모든 위협은 영향도와 발생 가능성이라는 두 축으로 평가할 수 있다. 이 지표를 기반으로 Critical / Major / Minor같은 등급을 부여한다. 이 과정은 어떤 위협에 자원을 우선 투자할 것인가를 결정하는 과정이기도 하다.

3. 위협별 통제를 설계하라

이제 각 위협에 대응하는 통제를 만들어야 한다. 예를 들면 다음과 같다.

위협	등급	통제
내부자의 DB 서버 접근을 통한 고객 개인정보 유출	Major	주요 데이터 컬럼별 암호화 액세스 로그 저장 및 감사 최소 권한 원칙 적용 데이터베이스 접근 통제
서버의 접근시 외부망 접근 가능	Critical	인가된 네트워크에서만 서버 접근 허용
계정 재생성을 이용한 포인트 적립(회원 가입시 포인트 지급)	Minor	회원가입시 기존 가입 여부 검증

예시와 같이 하나의 위협에는 하나 이상의 통제가 필요할 수 있다. 또한 위협 혹은 통제가 꼭 기술적이지 않을 수 있다. 중요한 건 이 각 통제가 실제로 해당 위협을 완화할 수 있어야 한다.

4. 통제 이행과 추적

통제 항목이 정해졌다면, 그것이 실제로 이행되고 검증될 수 있어야 한다. 이를 위해 내부 티케팅 시스템에 각 통제를 등록해 관리한다. 티켓에는 위협에 대한 설명, 위협의 대상, 위협 등급, 등급에 따른 SLA, 위협 모델링 문서, 대응 방안등이 포함되어야 한다.

짝짝짝! 위 과정을 다 수행했다면 당신 인생의 첫 번째 위협 모델링이 완료되었다. 생각보다 어렵지 않고, 사람들의 예상처럼 거창하지 않다는 걸 느꼈을 것이다. 화이트보드 하나와 몇 명의 구성원만으로도 충분히 의미 있는 결과를 만들 수 있다. 첫걸음은 언제나 작게, 그러나 최종적으로는 해당 프로세스를 꾸준히 할 수 있도록 회사의 문화와 프로세스에 넣는 것이 중요하다.

한 단계 더 나아가기

그렇다면 이제 우리는 무엇을 더 해야 할까? 많은 사람들이 위협 모델링이라는 말을 들으면 STRIDE, DREAD 같은 특정 방법론을 떠올린다. 이는 각기 다른 사람과 팀이 위협 모델링을 수행하더라도 일관된 결과를 도출하기 위한 공통 언어와 구조를 제공하기 때문이다. 즉, 방법론은 목적이 아니라 수단과 도구이다. 조직의 보안 성숙도, 협업 문화, 그리고 기술 스택에 따라 필요한 만큼 선택적으로 채택하면 된다. 물론 위협 모델링을 활용해 논문을 쓴다거나 한다면 더욱더 일관된 방법론이 필요할 것이다.

위협 모델링을 더 잘 이해하기 위해서는 몇가지 책과 도구이다. 가볍게 읽어보고 싶다면 Izar Tarandach의 개발자를 위한 위협 모델링을 추천한다. 조금 더 깊이 있는 내용을 원한다면, 위협 모델링의 고전이라 할 수 있는 Adam Shostack의 Threat Modeling: Designing for Security를 읽어보자. 이 책은 단순한 기법 소개를 넘어, 왜 위협 모델링을 해야 하는가에 대한 철학까지 제시한다. 위협 모델링을 도와주는 도구로는 OWASP의 Threat Dragon이나 Microsoft의 Threat Modeling Tool과 같은 무료 도구가 있으며 각종 상용도구들도 존재한다. 요즘은 아키텍쳐만 올리면 LLM이 직접 위협 모델을 만들어주기도 한다.

마지막으로, 위협 모델링은 방법론이나 도구의 문제가 아니다. 우리 제품과 조직이 가진 위협을 더 잘 이해하기 위한 도구, 공격자 관점에서 제품을 바라보는 습관, 그리고 제품이 변화 할 때마다 업데이트하여 새로운 위협을 식별하는 문화이다.

Seongjin Blog