Transcript 3. Architecture overview의 생성

3장
Threat
Modeling
2009.3
신수정
1. 개요
Threat modeling
-
시스템에 영향을 미치는 위협들을 구조적으로 정의하고 평가하게 함
이 Chapter
Threat modeling을 위한 프로세스 서정
가장 common한 Threat에 대한 이해
Threat model의 Evolve
2
1. 개요
One time only process가 아님 : 시스템 설계부터 지속적으로 이루어져야 할 iterative porcess
첫번째 pass에서 모든 가능한 위협을 정의하기 어려움
Application이 static하지 않고 계속 변화하기 때문에 같이 반복되어야 함
3
2. 자산의 정의
-
보호하고자 하는 자산의 정의
-
기밀 데이터(고객DB 등)로 부터 웹 페이지, 웹 사
이트 가용성까지 걸쳐 있음
4
3. Architecture overview의 생성
1) 어플리케이션이 무엇을 하는지 정의
-
어플리케이션이 무엇을 하는지, 어떻게 자산을 사용하고
접근하는지 정의
-
Use cases를 문서화(사용자관점, 시스템과 사용자간의
상호교류) – Actor-Use->use-case
예) 인사 Application
-
직원이 financial data를 view함
-
직원이 personal data를 update함
-
Manager가 직원 details를 view함
•
Actor: 개발되는 시스템과 상호작용을 해야 하는 사람, 사
물, 시스템의 외부, 누가 시스템을?
•
Use-case: 시스템으로 부터 제공되는 기능, Actor에 의해
수햏되는 서로 밀접한 관계가 있는 트랜잭션들의 순서, 사
용자 입장에서의 기능적 요구사항, 시스템 내/외부 상호작
용 행위의 집합, 시작과 종료까지 완전한 하나의 주요 단위
기능 포함
5
3. Architecture overview의 생성
2)
아키텍쳐 다이어그램 생성
- 시스템의 구조와 구성
6
3. Architecture overview의 생성
3) 기술 정의
- 솔루션 이행에 사용되는 기술 정의
7
4. Decompose the application
- Security profile을 생성하기 위해 Application을 break down함
8
4. Decompose the application
1)
Trust boundary 정의
-
자산을 둘러쌓고 있는 신뢰 경계 정의
-
Upstream data 흐름, 사용자 입력이 신뢰되는가? 그렇지 않다면 데이터 플로우와 입력이 어떻게
인증되고 허가되는가?
-
Calling code가 신뢰되는가?
 특별한 trust boundary안으로의 모든 입력 포인트를 지키는 적절한 gatekeeper서리, 입력 gate
keeper는 trust boundary로 전달되는 모든 데이터를 충분히 validate해야 함
2)
Data flow 정의
-
개별 서브시스템사이의 데이터 흐름
-
신뢰 바운더리를 흐르는 데이터 흐름이 중요: 신뢰 바운더리 외부로 부터오는 데이터를 전달하는
코드는 이 데이터가 문제가 있다고 가정하여 철저한 검증 수행
3)
Entry point 정의
-
entry point는 공격의 entry point일 수 있음
-
각 entry point에 대해 허가와 검증을 수행하는 gatekeeper의 형태 결정
-
Logical: user, service interface
-
Physical: ports, sockets
9
4. Decompose the application
4)
권한 코드 정의
-
권한 코드는 안전한 자원을 접근하고, 권한 operation을 수행함.
-
Secure Resource: DNS서버, 디렉토리 서비스, 환경변수, 이벤트 로그, 파일시스템, …
-
권한코드는 적절한 코드 접근 보안 퍼미션이 주어져야 함
-
자원과 operation이 trust되지 않거나 잠재된 문제 코드에 노출되어서는 안됨
5)
보안 프로파일 문서화
- 입력 확인, 인증, 허가 등에 사용되는 설계 및 구현 방법 정의 필요
10
4. Decompose the application
11
5. Identify the threats
두 가지 방법
-
위협을 정의하기 위해 STRIDE사용 : goal-based
approach(공격자의 목적을 고려)
-
카테고리된 위협 리스트의 사용: 네트워크, 호스트,
Application 카테고리로 그룹화된 위협의 리스트를 사용
함
12
5. Identify the threats
1) 네트워크 위협 정의
-
전송자 IP 주소에 의존한 보안 메커니즘- IP 스푸핑의 위협
-
암호화되지 않은 네트워크 채널을 사용해서 session identifier나 쿠키의 전송: IP세션 하이재킹의 위협
-
암호화되지 않은 네트워크 채널을 사용하여 인증 credential이나 민감한 데이터의 전송
-
안전하지 않은 장비나 서버 configuration으로 인한 위협
2) 호스트 위협 정의
-
패치되지 않은 서버
-
불필요한 포트, 프로토콜, 서비스
-
인증되지 않은 접근의 허가
-
약한 패스워드 및 계정 정책
3) 어플리케이션 위협 정의
-
약한 입력 validation
-
암호화되지 않은 네트워크로의 인증 credential전달
-
약한 패스워드와 계정 정책
-
안전한 configuration관리의 실패
-
Over-privileged secret
-
약한 암호화
-
약한 로깅 및 감사
13
5. Identify the threats
•
Attack Tree: 시스템에 대한 잠재적 공격을 체계적으로 수집하고 문서화 하는 방법
14
5. Identify the threats
•
Attack pattern: 기업의 공격정보를 캡처하는 공식적인 접근, 여러 형태로 발생할 수 있는 공격의 일반적인
표현, 공격 기술에 초점
15
6. Document the threats
(5) 위협의 문서화
16
7. Rate the threats
(6)
위협의 Rating
-
Risk= Probability* damage potential
예) 1-10 scale사용
17
7. Rate the threats
(6)
위협의 Rating
-
상, 중, 하 스케일 사용
-
DREAD model
D: 취약성이 exploit되면 손상이 얼마나 큰가?
R: 공격을 재생하는 것이 얼마나 쉬운가?
E: 공격을 시행하기가 얼마나 쉬운가?
A: 대략 얼마나 많은 사용자가 영향받는가?
D: 취약성을 발견하기가 얼마나 쉬운가?
18
7. Rate the threats
12-15: High
8-11: Medium
5-7: Low
19
8. 위협 모델링의 산출물
산출물
응용시스템 아키텍쳐의 보안 측면의 문서화
Rate된 위협의 리스트
20