유용한 위협 모델은 무엇을 보호하는지, 누가 또는 무엇이 그것에 영향을 미칠 수 있는지, 신뢰가 어디서 바뀌는지, 가장 중요한 위험을 어떻게 줄이고 테스트할 것인지 설명합니다. 일반적인 도구 목록이 아니라 실제 프로젝트부터 시작하십시오.
추론할 수 있을 만큼 작은 범위를 정의하십시오
하나의 작동하는 서비스부터 시작하십시오. 고객 포털, 게시 사이트 또는 내부 애플리케이션입니다. 운영하는 구성 요소와 의존하는 외부 시스템을 기록하십시오. 위협 모델은 가정을 가시화해야 하며, 가능한 모든 공격이 해결되었다고 암시해서는 안 됩니다. 애플리케이션을 배포하는 사람들이 별도의 컨설턴트가 다이어그램을 해석하지 않고도 설명할 수 있을 만큼 첫 버전을 작게 유지하십시오.
가치 있는 결과와 자산을 나열하십시오. 여기에는 고객 데이터, 관리 접근, 결제 상태, 게시된 콘텐츠 및 서비스 복원 능력이 포함될 수 있습니다. 정보가 공개되어 있더라도 가용성이 자산이 될 수 있습니다. 어떤 실패가 불편한지, 어떤 실패가 사람이나 조직에 피해를 줄지 결정하십시오. 이러한 구분은 모든 경고를 동등하게 취급하지 않고 통제의 우선순위를 정하는 데 도움이 됩니다.
신뢰가 바뀌는 지점을 그리십시오
OWASP의 위협 모델링 지침은 데이터 흐름과 신뢰 경계를 사용하여 설계를 이해하기 쉽게 만듭니다. 소규모 호스팅 애플리케이션의 경우 브라우저, 웹 프로세스, 데이터베이스, 관리자, 백업 목적지 및 외부 통합을 그리십시오. 이들 사이를 이동하는 정보를 표시하십시오. 신뢰할 수 없는 클라이언트에서 권한 있는 서버 작업으로 넘어가는 요청은 명시적인 검증과 권한 부여가 필요합니다.
같은 머신 안에 있다고 해서 모든 구성 요소가 동등하게 신뢰된다고 가정하지 마십시오. 공개 업로드 프로세스는 데이터베이스 관리와 동일한 권한을 가져서는 안 됩니다. 백업 작업은 라이브 애플리케이션 기록을 수정하는 능력 없이 읽기 접근이 필요할 수 있습니다. 이러한 역할을 분리하면 손상된 구성 요소의 영향을 더 쉽게 억제하고 필요한 권한을 더 쉽게 검토할 수 있습니다.
구체적인 실패 시나리오를 선택하십시오
몇 가지 그럴듯한 이벤트를 사용하여 설계에 도전하십시오. 공격자가 관리자 비밀번호를 훔칩니다. 사용자가 다른 사용자의 기록을 요청합니다. 업로드가 디스크를 채웁니다. 배포가 구성 파일을 노출합니다. 복구 사본을 복원할 수 없습니다. 시작 조건, 영향을 받는 구성 요소 및 결과를 설명하십시오. 구체적인 시나리오는 보안을 개선하라는 광범위한 지시보다 테스트하기 쉽습니다.
외부 침입뿐만 아니라 실수와 정당한 워크플로 남용도 포함하십시오. 재시도가 두 개의 가치 있는 작업을 생성하거나 두 요청이 동일한 객체를 변경하기 위해 경쟁할 수 있습니다. OWASP의 비즈니스 로직 지침은 이러한 프로세스 가정을 강조합니다. 누가 워크플로를 다음 상태로 이동할 수 있는지, 요청을 반복하거나 재정렬하면 결과가 예기치 않게 변경되는지 확인하십시오.
| 시나리오 | 조사할 통제 | 수집할 증거 |
|---|---|---|
| 도난당한 관리 자격 증명 | 지원되는 경우 제한된 접근 및 2차 인증 | 무단 로그인이 완료될 수 없음 |
| 다른 사용자의 객체 요청됨 | 서버 측 객체 권한 부여 | 격리된 테스트가 거부 결과를 반환함 |
| 업로드로 디스크 소진됨 | 크기, 할당량 및 보존 통제 | 서비스 실패 전에 한도가 적용됨 |
| 중복 워크플로 요청 | 멱등성 및 트랜잭션 경계 | 반복된 요청이 하나의 결과를 생성함 |
영향과 신뢰할 수 있는 경로로 우선순위를 정하십시오
각 시나리오에 대해 잠재적 영향과 발생에 필요한 조건을 기록하십시오. 추측한 수치 점수가 정확한 확률이라고 가장하지 마십시오. 인터넷에 노출된 약한 비밀번호와 조건이 까다로운 로컬 이벤트를 여전히 구분할 수 있습니다. 중요한 위험에 소유자와 실용적인 다음 단계를 지정하여 모델이 누군가 실제로 완료할 수 있는 작업을 생성하도록 하십시오.
애플리케이션 손상뿐만 아니라 정보 수명 주기도 고려하십시오. 진단 내보내기는 정상 운영 중에 불필요한 데이터를 공개할 수 있습니다. 보존된 계정 필드는 목적이 끝난 후 오랫동안 노출을 생성할 수 있습니다. 따라서 개인정보 검토는 정보를 제거하거나 보존을 단축할 수 있으며, 보안 검토는 남아 있는 것에 대한 접근을 제한합니다. 두 변경 모두 프로젝트를 보호할 때 모델에 포함됩니다.
승인된 환경에서 통제를 테스트하십시오
대표적인 권한과 가상 기록이 있는 스테이징 환경을 만드십시오. 거부된 접근, 요청 한도, 워크플로 재시도 및 복구를 테스트하십시오. 합성 데이터로 동작을 입증할 수 있을 때 실제 고객 데이터를 사용하지 마십시오. 목표는 통제를 검증하는 것이지 인상적인 공격 트래픽을 생성하는 것이 아닙니다. 소유하거나 명시적으로 평가 권한이 있는 시스템 내에서 머무르십시오.
통과한 것, 실패한 것 및 알 수 없는 것을 기록하십시오. 스캐너 결과는 증거를 제공할 수 있지만 애플리케이션의 비즈니스 규칙 테스트를 대체하지는 않습니다. 마찬가지로 네트워크 보호 옵션은 객체 권한 부여나 비밀 파일 처리를 검증하지 않습니다. 유용한 결과를 시나리오에 첨부하여 향후 유지 관리자가 특정 통제가 존재하는 이유를 이해할 수 있도록 하십시오.
모델을 변경과 연결된 상태로 유지하십시오
통합을 추가하거나, 새 엔드포인트를 노출하거나, 권한을 변경하거나, 데이터를 다른 목적지로 이동할 때 관련 부분을 검토하십시오. 사소한 텍스트 편집을 위해 전체 아키텍처를 다시 그릴 필요는 없습니다. 트리거는 접근, 정보 또는 시스템 동작에 대한 가정의 변경입니다. 모델을 일회성 워크숍 결과물로 남겨두지 말고 배포 및 복구 문서 옆에 보관하십시오.
SwissOctet은 완성된 애플리케이션 위협 모델이 아니라 인프라 선택의 카탈로그를 제공합니다. 귀하의 통제를 지원하는 구성과 옵션을 선택한 다음 구축한 배포를 검증하십시오. 테스트된 조치가 있는 작고 유지 관리되는 모델은 해결하는 위험에 대한 명확한 설명이 없는 대규모 보안 제품 모음보다 더 유용합니다.
실용 체크리스트.
- 자산과 실패의 결과를 나열하십시오.
- 데이터 흐름과 신뢰 경계를 그리십시오.
- 특정 침입, 실수 및 워크플로 시나리오를 선택하십시오.
- 중요한 위험에 통제와 소유자를 지정하십시오.
- 승인된 환경에서 합성 데이터로 테스트하십시오.
- 관련 가정이 변경될 때 모델을 검토하십시오.
중요한 세부 사항.
시작하기 위해 공식 프레임워크가 필요합니까?+
아니요. 작은 다이어그램과 문서화된 시나리오 세트가 유용할 수 있습니다. 프레임워크는 위험을 일관되게 검토하도록 도와줍니다.
취약점 스캐너가 위협 모델링을 대체합니까?+
아니요. 스캐너는 기술적 약점을 찾을 수 있지만, 위협 모델은 설계 가정, 권한 및 비즈니스 워크플로도 검토합니다.
모델을 얼마나 자주 업데이트해야 합니까?+
데이터 흐름, 통합, 권한 또는 노출된 기능이 변경될 때 영향을 받는 부분을 업데이트하고, 해결되지 않은 위험을 정기적으로 검토하십시오.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- OWASP: 위협 모델링 치트 시트 cheatsheetseries.owasp.org
- OWASP: 실무에서의 위협 모델링 devguide.owasp.org
- OWASP: 비즈니스 로직 보안 cheatsheetseries.owasp.org
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.