<목록>
1. TCSEC
2. 요구 분석을 통한 국제 표준 시스템 평가 지표(CC)
3. 사용자 요구 분석 명세화
4. 접근통제 방법
1) 임의적 접근통제(DAC : Discretionary Access Control)
2) 강제적 접근통제 ( MAC : Mandatory Access Control)
3) 비임의적 접근통제(Non - Discretionary Access Control)
1. TCSEC
TCSEC는 미국에서 처음 개발된 요구분석을 통한 시스템 평가 방식으로서, 요구분석 대신 먼저 분류하여 쉽게 사용 그룹을 확인하기 위해 사용한다.
미국에서는 평가기준 문서들을 Rainbow book 이라고 한다. 그렇게 불리는 이유는 평가 기준에 대한 문서를 요구할때 직감적으로 분류가 가능하도록 색으로 분류하는 것이다. TCSEC를 오렌지 북이라고도 부른다.
Bell-Lapadula 모델 기반의 기밀성을 다루며 가용성과 무결성은 다루지 않기 때문에 국가간 기준에는 적합하지만, 일반 기업에는 적합하지 않다. Bell-Lapadula 모델은 등급을 나누고 등급의 규정을 정하는 것이다. 접근가능 인원을 분류하여 자신보다 높은 등급에는 접근이 불가능하며, 자신보다 낮은 등급의 문서 또한 생성이 불가능하게 하는 것이다. 만약 생성이 가능하다면 정보유출로 간주가 가능하며 이를 방지하기위해 직접 Typeing을 하지 않고 대필후 검토만 수행한다.
통제는 자산과 위험을 식별하고 위험을 식별 가능한 수준까지 낮추기 위한 작업을 의미한다. 통제 목적은 보안정책, 보증, 책임추적성이 있다. 보안정책은 보안 계획을 의미하며 보증은 어느 정도까지 보호가 가능한지, 책임 추적성은 이슈 발생시 그 책임은 누구에게 있는가 에 대한 내용이다.
보안 클래스
클래스 등급 |
목적 |
허용범위 |
D |
최소보호 |
보안이 필요없는 소프트웨어 |
C |
재량적(임의적)보호 : 알아야할 필요성 : 임의적 접근제어) |
OS, 오라클등의 계정을 사용해 접근이 가능한 SW |
B |
강제적 보호 : 보안레이블(강제적 접근제어) |
외국 수출이 원할 경우 정부의 승인이 필요하다. |
A |
검증된 정형화된 보호 |
외국 수출이 불가능하며, 장비와 SW분리가 불가능한 일체형 장비이고, 네트워크에 연결되지 않은 모듈로서 작동하는 SW이다. |
강제적 접근정책 : 접근 가능한 등급이 되어야 하며 반드시 임의적 임의적 접근정책과 같이 사용해야 한다.
2. 요구 분석을 통한 국제 표준 시스템 평가 지표(CC)
CC(Common Criteria)는 국제 표준 평가 지표로서 PP와 ST를 이용해서 등급을 평가한다. ISO평가와 동일한 방식으로 진행이된다. 특징은 기존에 평가정보가 없더라도 수용이 가능하다. 하지만 기존과 다른 보안제품임을 검증하는 검증내용이 반드시 필요하다. 예를 들어 IPS, UTM, NAC등은 평가기준이 없어 단독 제품으로 사용이 불가능하다.
보호프로파일(PP) |
보안목표명세서(ST) |
구현에 독립적임 |
구현에 종속적임 |
제품군 |
특정 제품 |
여러 제품/시스템이 동일한 유형의 PP를 수용할 수 있다. |
하나의 제품/시스템은 하나의 ST를 수용해야 한다. |
PP는 ST를 수용할 수 없다. |
ST는 PP를 수용할 수 있다. |
PP는 보호프로파일(Protection Profile)로서 CC의 기능과 보증 요구사항을 이용하여 특정제품(Target of Evaluation:TOE)의 구현과 상관없이 보안요구사항을 정의한 문서이다. 사용자인 정보보안 담당자, 정보보호 시스템 개발자, 이외 여러 단체나 집단에 의해 개발이 가능하여 민간기관에서 개발한다. 보안 요구사항에 대한 이론적 근거, 보안목적등이 기술된다.
ST는 보안목표명세서(Security Target)로서 PP를 기초로 보안기능을 서술하여 명세화된 PP라고 할 수 있다. 시스템 사용환경, 보안환경, 보안기능 명세서등을 포함해 기업에서 작성한다.
PP가 없다면 PP를 생성하게 되는데 기존에 존재하는 PP와 비교하여 유사한 PP가 존재한다면 해당 PP를 확장하고, 별개의 PP라면 PP를 새로 등록한다. 이후에 PP Evaluation -> ST Evaluation -> TOE Evaluation 순서로 평가가 진행된다.
PP Evaluation - PP의 완전성, 일치성, 기술성 평가
ST Evaluation - PP의 요구사항 충족 여부를 통한 등급화
TOE Evaluation - ST의 요구사항 충족여부
한국은 CC와 보안 요구 등급이 일치하기 때문에 인증서 수행, 발행국이다. 하지만 EAL4/K4 이상의 레벨만 등급을 받고 그 이하로는 등급을 왠만하면 받지 않는데, 등급을 평가받기 위해서는 소스코드를 제출하기 때문이다.
3. 사용자 요구 분석 명세화
사용자의 요구 분석 명세화는 접근 권한은 유형에 따라 need to know(알필요, 할필요)에 근거해서 문서화 되어야 한다. 그 근거자료는 BPR과 ISP를 사용한다. BPR(Business Processing Reprograming)은 사용자가 어떤 장비, 어떤 파일이나 디렉토리에 사용할것인가에 대한 문서화된 자료로서 주기적으로 수행한다. ISP는 정보전략기획으로서 PC업무에 사용한 SW등의 리소스에 대한 사용계획을 문서화한 자료이다.
접근 권한 통제 목록은 ACL(Access Control List)라고 하며 접근 통제 테이블이라고도 한다.
정책 입안자인 결정권자나 개별사용자인 자산의 실 소유자(부서장)에 의해 결정 되지만 반드시 보안관리자에 의해 구현되어야 한다. 이렇듯 결정과 구현이 명확히 분리되어 무결성이 확보되어야 책임추적성이 가능하며, 책임추적성을 위해 작업명세서가 필요한 것이다.
IS는 정보 시스템을 의미하며 주로 자원에 관련된 구체적인 대상을 지칭한다. 참고로 IT는 구체적인 대상이 지칭되지 않은 정보 시스템을 의미한다. (* 자원이란 정량적 측정이 가능한 것으로 돈으로 환산이 가능한 재원을 의미한다.)
ACL을 작성하기 위한 작업순서
① IS자원목록을 작성한다. IS자원목록은 HW/SW, 업무시간, 업무프로세스등의 자산을 평가하는 작업이다.
② IS자원을 접근 권한 기준에 따라 분류하며, 그룹화 하는 작업이다.
③ IS자원을 Labeling작업을 통해 정보자산목록의 명명화를 정보자산소유자를 통해 수행한다. 하지만 해당 정보자산이 다른 그룹과 공유되어 사용하는 명칭이 다를 수 있기 때문에 통합이 어렵다.
④ ACL을 작성하고 검증하여 업무분석 자료로서 사용한다.
4. 접근통제 방법
1) 임의적 접근통제(DAC : Discretionary Access Control)
- 계정기반 접근통제로서 사용자의 신원을 이용한 접근통제 방식이다.
- 신원, 사용자 중심의 접근통제 방식이다.
- 강제 접근 통제에 추가적인 검정 도구로 사용하며, 강제 접근 통제보다 우선 할 수 없다.
2) 강제적 접근통제 ( MAC : Mandatory Access Control)
- 보안 혹은 시스템 관리자가 이미 만들어진 보안정책에 근거하여 접근 내용을 ACL로 작성한다.
- 규칙 기반의 접근통제로서 Rule-base access control방식이라고 이다.
- 임의적 접근통제를 포함해 최소권한의 원칙을 구현한다.
- 기밀성 등급과 무결성 등급에 따라 접근 방식과 권한에 차이가 있다.
보안등급 |
기밀성 등급 |
무결성 등급 |
||
중점 |
데이터의 투명성 |
데이터의 정확성 |
||
접근(Read) 권한 |
상위 등급 참조 |
불가능 |
상위 등급 참조 |
가능 |
하위 등급 참조 |
가능 |
하위 등급 참조 |
불가능 |
|
사용(Write) 권한 |
하위 등급 작성 불가 |
상위 등급 작성 불가 |
3) 비임의적 접근통제(Non - Discretionary Access Control)
- 역할(Role)이나 역할(Task)기반의 접근 통제인 동시에 격자기반 접근 통제로서 Role-base access control 또는 Lattice-base access control이라고 한다.
- 대표적인 예로 오라클과 같이 Take-grant model이 있다.
- 임의적 접근통제와 마찬가지로 신원기반 접근통제이지만 권한을 가진 사용자가 다른 사용자에게 권한 위임이 가능한 모델이다.
'교육 > Security Governance' 카테고리의 다른 글
Day 56 (FTP서버의 보안 명세 구현) (0) | 2020.02.07 |
---|---|
Day 56 (Governance) (0) | 2020.02.07 |
Day 55 (Governance) (0) | 2020.02.06 |
Day 54 (Governance) (0) | 2020.02.05 |
Day 25 (Physical Security) (0) | 2019.12.20 |