학교 보안 소모임에서 2차 학술 세미나 주제로 Threat Modeling / Trust Boundary를 선정해 사전 학습한 내용을 적어보려고 한다.
세미나 전
Threat Modeling(위협 모델링)
위협 모델링은 애플리케이션이나 시스템을 분석하여 어떤 자산을 보호해야 하고, 어떤 위협이 발생할 수 있으며, 이를 어떻게 방어할 것인지를 체계적으로 식별하는 프로세스이다.
Trust Boundary(신뢰 경계)
검증된 데이터와 검증되지 않은 데이터가 만나는 지점이다.
세미나 복습
Threat Modeling이 왜 필요한가?
1. 조기에 위험 식별(Identify Risks Early On)
위협 모델링은 설계 단계에서 잠재적인 보안 문제를 미리 찾아내는 것을 목표로 한다. 시스템을 다 만들어 놓은 뒤에 방화벽 같은 보안 솔루션을 억지로 덧붙이는(Bolted-on) 것이 아니라, 처음부터 보안이 튼튼하게 내재된(Built-into) 시스템을 만들 수 있다.
운영 환경에 서비스가 배포된 후 뒤늦게 취약점을 발견하고 구조를 뜯어고치는 것보다 훨씬 효율적이고 비용을 크게 아낄 수 있다.
2. 보안 인식 향상(Increased Security Awareness)
제대로 된 위협 모델링을 수행하려면, 우리가 만드는 애플리케이션의 보안 환경에 대해 비판적이고 창의적으로 고민해야 한다.
단순히 방어자의 입장에 머무는 것이 아니라, 공격자의 관점(Think like an attacker)에서 시스템을 바라보게 한다. 또한, 위협 모델링은 팀 단위로 진행되므로, 팀원들이 자유롭게 아이디어를 나누고 피드백을 주고받는 과정 자체가 훌륭한 보안 교육의 장이 된다.
3. 평가 대상(TOE)에 대한 가시성 향상(Improved Visibility of Target of Evaluation)
위협 모델링을 제대로 수행하려면 평가 대상이 되는 시스템을 깊이 이해해야만 한다. 앞서 언급한 데이터 흐름(Data Flows)이나 신뢰 경계(Trust Boundaries) 같은 시스템의 핵심 특성을 파악하지 않고서는 위협을 도출할 수 없기 때문이다.
결과적으로 위협 모델링을 진행하는 과정 자체가, 우리가 만들고 있는 시스템의 전체적인 내부 아키텍처와 구성 요소 간의 상호작용을 한눈에 꿰뚫어 볼 수 있는 가시성(Visibility)을 획기적으로 높여준다.
Threat Modeling의 기본 흐름
위협 모델링은 일회성 이벤트가 아니라, 소프트웨어 개발 수명 주기(SDLC) 내에서 지속적으로 반복되는 체계적인 과정으로 다음의 네 가지 단계로 나누어 진행된다.
1. 시스템 모델링(System Modeling)
우리가 보호해야 할 대상이 무엇인지 명확히 정의하고 구조화하는 단계이다. 아키텍처를 분석하고 구성 요소를 분해(Decomposition)하여 시각적인 모델로 만듭니다. 여기서 데이터 흐름도(DFD, Data Flow Diagram)를 작성한다.
특히, 시스템을 제대로 그리지 못하면 어떤 경계가 존재하는지, 어떤 데이터가 어디를 지나가는지, 어떤 지점이 중요한 자산과 연결되는지 보이지 않기 때문에, threat modeling의 출발점은 항상 시스템을 모델링하는 데서 시작해야 한다.
2. 위협 식별(Threat Identification)
작성된 시스템 모델과 신뢰 경계를 바탕으로, "어떤 공격이 가능할까?"를 도출해 내는 단계이다. 경험에만 의존하지 않고, 체계적인 방법론을 적용하여 위협을 누락 없이 찾아낸다. 방법론으로는 STRIDE, DREAD, P.A.S.T.A. 등이 존재한다.
그 중에서 STRIDE는 마이크로소프트에서 개발한 모델이다.
| 위협 카테고리 (STRIDE) | 침해하는 보안 요소 | 설명 및 발생 예시 (Examples) |
|---|---|---|
| Spoofing (스푸핑/위장) | Authentication (인증) | 사용자나 시스템의 신분을 속이는 위협이다. • 예시: 관리자 세션 탈취 |
| Tampering (변조) | Integrity (무결성) | 데이터나 코드를 악의적으로 수정하는 위협이다. • 예시: 파일 메타데이터 조작 |
| Repudiation (부인) | Accounting (책임 추적성) | 자신이 한 행동을 "내가 하지 않았다"고 발뺌할 수 있게 만드는 위협이다. • 예시: 접근 로그를 조작하거나 삭제 |
| Information Disclosure (정보 유출) | Confidentiality (기밀성) | 권한이 없는 자에게 민감한 정보가 노출되는 위협이다. • 예시: 비공개 파일 노출 |
| Denial of Service (서비스 거부) | Availability (가용성) | 정당한 사용자가 시스템을 사용하지 못하도록 방해하는 위협이다. • 예시: 대용량 업로드 남용 |
| Etion of Privileges (권한 상승) | Authorization (인가/권한) | 권한이 없는 사용자가 관리자 등 더 높은 권한을 획득하는 위협이다. • 예시: 일반 사용자의 관리자 기능 접근 |
3. 대응 및 완화(Response and Mitigations)
식별된 위협들을 어떻게 처리할지 결정하고, 방어 대책을 설계에 반영하는 단계이다. 모든 위협을 완벽하게 막는 것은 불가능하므로, 위험도에 따라 우선순위를 정하는 것이 중요하다.
4. 검토 및 검증(Review and Validation)
지금까지 진행한 위협 모델링이 제대로 수행되었는지, 그리고 도출된 보안 대책이 실제 코드와 시스템에 잘 반영되었는지 확인하는 마무리 단계이다.
DFD(Data Flow Diagram)
DFD는 시스템 요소와 그 사이의 데이터 이동을 시각적으로 표현하는 도구이다.
위협 모델링을 위해 시스템의 구조를 그릴 때 사용하는 5가지 표준 기호로 이 요소들을 조합하여 데이터가 어디서 오고, 어디에 저장되며, 어떤 경계를 넘는지 시각화할 수 있다.
| 요소 명칭 (Element) | 기호 (Shape) | 보안적 의미 및 예시 |
|---|---|---|
| 외부 엔터티 (External Entity) | 사각형 | 우리 시스템 외부의 존재(공격의 기점) • 예시: 웹 브라우저 사용자, 외부 API(OAuth, 결제) |
| 프로세스 (Process) | 원 / 타원 | 데이터를 처리하는 코드나 서비스. 공격의 주요 표적이 된다. • 예시: API 서버, 데이터 파싱 로직, 암호화 모듈 |
| 데이터 저장소 (Data Store) | 평행선 | 데이터가 보관되는 장소(보호해야 할 자산) • 예시: MySQL DB, Redis 캐시, 서버 로그 파일, S3 버킷 |
| 데이터 흐름 (Data Flow) | 화살표 | 데이터의 이동 경로(공격의 통로) • 예시: 로그인 정보 전송(HTTP), DB 쿼리, JSON 응답 데이터 |
| 신뢰 경계 (Trust Boundary) | 점선 | 권한이나 신뢰 수준이 바뀌는 지점(보안 필터) • 예시: 인터넷과 서버 사이, 웹 서버와 DB 사이, 사용자/관리자 구분선 |
Practical Threat Modeling이 주는 5가지 교훈
이론적인 방법론을 모두 숙지했다고 해도, 막상 실무나 프로젝트에 위협 모델링을 적용하려고 하면 "너무 거창한 거 아닐까?" 하는 부담감이 들 수 있다.
OWASP에서는 실제 환경에서 위협 모델링을 성공적으로 정착시키기 위해 다음 5가지 교훈을 강조합니다.
1. 수정하기 쉬운 형태를 유지하라 (Revisable form)
위협 모델링 문서는 한 번 예쁘게 그리고 끝나는 '완성작'이 아니다. 소프트웨어의 아키텍처가 변하고 새로운 기능이 추가될 때마다 함께 진화해야 하는 '살아있는 문서'다. 따라서 언제든지 부담 없이 고치고 덧붙일 수 있는 유연한 형태를 유지하는 것이 좋다.
2. 점진적으로 접근하라 (Incremental)
처음부터 거대한 시스템 전체를 완벽하게 분석하려고 욕심내면 금방 지쳐버린다. 가장 핵심적인 기능이나 최근에 변경된 아키텍처 등 작은 단위부터 시작하고, 작게 모델링하고 점차 범위를 넓혀가는 점진적인 방식이 훨씬 효과적이다.
3. 빠를수록 좋지만, 늦은 때란 없다 (Sooner the better; but never too late)
위협 모델링은 설계 단계에서 수행할 때 가장 적은 비용으로 큰 효과를 낸다. 하지만 이미 개발이 끝났거나 운영 중인 서비스라고 해서 포기할 필요는 없다. 취약점을 모른 채 방치하는 것보다, 늦게라도 아키텍처를 점검하고 방어선을 구축하는 것이 안전하다.
4. 도구는 거들 뿐이다 (Tools are secondary)
비싸고 복잡한 위협 모델링 전용 자동화 솔루션이 있어야만 시작할 수 있는 것이 아니다. 정말 중요한 것은 도구가 아니라, 구성원들이 모여 보안 위협을 논의하는 '과정'과 '대화' 그 자체다.
5. 간결함이 최우선이다 (Brevity is paramount)
수십 장짜리 복잡한 보안 분석 보고서는 결국 아무도 읽지 않는 서랍 속 문서가 된다. 누구나 시스템의 흐름을 직관적으로 이해하고, 어떤 위협이 있으며 어떻게 막을 것인지만 명확하게 알 수 있도록 최대한 간결하게(Brevity) 작성한다.
세미나 후
이번 세미나는 Threat Modeling과 Trust Boundary를 중심으로, 시스템을 단순한 기능 집합이 아니라 자산, 데이터 흐름, 통제의 경계, 그리고 위협 가능성의 조합으로 바라보는 연습을 하는 시간이었다. 앞으로도 논문, 기술 문서, 최신 보안 이슈를 함께 읽고 정리하면서, 보안을 구현의 문제에만 머무르지 않고 설계와 구조의 문제로 읽는 시각을 계속 확장해 나갈 예정이다.
