위협 모델링이 중요한 이유

위협 모델링은 공격자가 알아내기 전에 시스템에서 발생할 수 있는 문제를 체계적으로 식별하는 활동입니다. 설계를 분석하고 가능한 위협을 열거한 다음 이를 완화할 방법을 결정합니다.

위협 모델링은 다음 네 가지 핵심 질문에 답합니다.

• 무엇을 만들고 있습니까?
• 무엇이 잘못될 수 있습니까?
• 그 문제에 어떻게 대응할 것입니까?
• 제대로 수행했습니까?

위협 모델링은 배포 후가 아니라 개발 생명 주기의 초기에 보안 문제를 해결하는 보안을 앞단으로 옮기기 원칙을 구현합니다.

결함을 발견하는 시점이 늦어질수록 수정 비용은 크게 증가합니다.

• 설계 단계 — 다이어그램을 변경하면 되므로 비용이 거의 들지 않습니다
• 개발 단계 — 일부 코드를 다시 작성해야 합니다
• 운영 단계 — 긴급 패치, 사고, 잠재적인 침해가 발생할 수 있습니다

코드 한 줄을 작성하기 전에 설계 결함을 발견하는 것이 가능한 가장 저렴한 수정 방법입니다.

위협 모델링은 의도적인 사고방식의 전환을 요구합니다. 시스템이 어떻게 작동해야 하는지에 대한 생각을 멈추고 어떻게 악용될 수 있는지 생각하기 시작해야 합니다.

방어자는 자연스럽게 기능과 정상 경로에 집중합니다. 공격자는 다음을 찾습니다.

• 검증되지 않은 입력값
• 깨뜨릴 수 있는 신뢰 가정
• 건너뛰거나 재실행할 수 있는 단계
• 보호해야 하지만 보호되지 않은 데이터

모델링을 사용하면 이러한 적대적 사고를 우연이 아니라 체계적인 방식으로 수행할 수 있습니다.

세 가지 용어가 모든 위협 모델의 토대가 됩니다. 서로 구분하여 사용하십시오.

• 자산 — 보호할 가치가 있는 중요한 것(고객 데이터, 인증 정보, 가용성)
• 위협 — 발생할 수 있는 나쁜 사건이나 행위자(데이터를 훔치는 공격자)
• 취약점 — 위협이 성공하도록 만드는 약점(누락된 접근 확인)

위협이 취약점을 악용하여 가치 있는 자산을 공격할 수 있을 때 위험이 발생합니다.

식별하지 않은 것은 보호할 수 없습니다. 모든 위협 모델은 중요한 항목을 나열하는 것부터 시작하십시오.

일반적인 자산 범주는 다음과 같습니다.

위협 모델링은 일회성 활동이 아니라 특정 시점에 수행할 때 가장 큰 가치를 발휘합니다.

• 새 시스템이나 기능을 설계할 때
• 중대한 아키텍처 변경을 수행할 때
• 새로운 신뢰 경계를 추가할 때(새로운 통합 또는 외부 애플리케이션 프로그래밍 인터페이스)
• 보안 사고 후 관련 공백을 찾을 때

성숙한 팀은 위협 모델을 시스템의 변화에 따라 다시 검토하는 지속적인 활동으로 취급합니다.

위협 모델링은 팀 전체가 참여해야 하는 활동입니다. 한 사람이 만든 모델에는 중요한 맥락이 너무 많이 빠집니다.

효과적인 논의에는 다음과 같은 사람들이 참여합니다.

• 시스템이 실제로 어떻게 작동하는지 아는 개발자
• 설계 의도를 이해하는 시스템 설계자
• 공격 유형을 아는 보안 기술자
• 사업에 미치는 영향을 이해하는 제품 책임자

이처럼 다양한 관점이 모여야 어느 한 역할만으로는 발견할 수 없는 위협이 드러납니다.

여러 구조화된 방법론이 있으며 필요에 따라 혼합해 사용할 수 있습니다:

• STRIDE — 위협을 유형별로 분류하며 기술 설계에 적합합니다(다음 레슨에서 다룹니다)
• PASTA — 위험을 중심으로 하며 위협을 비즈니스 영향과 연결합니다
• 공격 트리 — 공격자의 목표와 경로를 모델링합니다
• DREAD — 위험의 우선순위를 정하기 위한 점수화 모델입니다

STRIDE는 체계적이고 접근하기 쉬워 가장 널리 가르치는 출발점입니다.

위협 모델은 실행 가능한 결과를 만들어 낼 때만 유용합니다. 일반적으로 다음과 같은 결과물이 포함됩니다:

• 시스템과 신뢰 경계를 보여 주는 다이어그램
• 분류된 식별된 위협 목록
• 각 위협에 대한 위험 등급
• 완화 조치 또는 위험 수용 결정
• 담당자에게 할당된 실행 항목

아무도 실행하지 않는 문서로 끝나는 위협 모델은 실패한 것입니다.

위협 모델링은 예측 가능한 방식으로 실패하는 경우가 많습니다. 다음과 같은 함정을 피하십시오:

• 전체를 한꺼번에 다루기 — 시스템 전체를 한 번에 모델링하려는 것; 대신 범위를 좁게 정하십시오
• 분석 마비 — 결정 없이 끝없이 논의하는 것
• 체크박스로 여기기 — 감사 담당자를 만족시키기 위한 문서만 만들고 실제로는 아무 조치도 취하지 않는 것
• 후속 조치 부재 — 위협을 식별하고도 완화 조치를 추적하지 않는 것

범위를 명확히 정하고, 시간 제한을 두며, 실제 실행 항목과 연결하십시오.

위협 모델링을 한 번도 해 보지 않았다면 다음의 가벼운 절차로 작게 시작하십시오:

• 시스템과 데이터 흐름을 간단한 다이어그램으로 그립니다
• 데이터가 신뢰 경계를 넘는 지점을 표시합니다
• 각 경계에서 공격자가 무엇을 할 수 있는지 질문합니다
• 가장 중요한 위협과 각각의 완화 조치를 기록합니다
• 담당자를 지정하고 나중에 다시 검토합니다

30분 동안 화이트보드에서 진행하는 세션만으로도 그렇지 않으면 운영 환경에 도달했을 문제를 찾아낼 수 있습니다.

위협 모델링이 중요한 이유를 배웠습니다:

• 위협 모델링은 공격자가 문제를 찾아내기 전에 무엇이 잘못될 수 있는지 구조적으로 답합니다
• 보안을 개발 초기 단계로 앞당겨 수정 비용을 크게 줄입니다
• 자산, 위협, 취약점을 구분하십시오. 위험은 이들이 교차하는 지점에서 발생합니다
• 설계 시점과 주요 변경 시점에 여러 분야의 팀과 함께 모델링하십시오
• 전체를 한꺼번에 다루거나 후속 조치를 하지 않는 등의 함정을 피하고, 항상 실행 가능한 결과물을 만드십시오

다음에는 위협을 분류하기 위한 STRIDE 프레임워크를 배웁니다.