EAL -Evaluation Assurance Level- 보증등급
서론
이 블로그를 보면, 또 WhoAmI 페이지를 보면 알 수 있겠지만, 나의 테크 스택은 독특한 편이다.
컴퓨터 공부의 시작은 Security(정보보안)으로 시작하였으며, 학부때는 서버 시스템을 열심히 공부하였고, 지금은 모바일 환경에서 저전력을 보고 있었다. 그리고 최근 몇개월 사이엔 딥러닝을 공부하고 있었다.
안타깝게도, 모바일 환경에서 저전력을 연구하던 내용은 빛을 보지 못하고 접게 되었다. 결과가(대부분 모바일 앱에서(특정 타겟 -게임, 웹브라우징 등-이 아닌) 5%정도의 전력 이득) 나오기는 했다. 하지만, 접게 되었으니까 논문은 없고... 내 머릿속에만 있으면서 누구한테 말도 못하는 그런 상황이다. 나같은 떠버리에겐 너무 가혹한 상황이다.
사실 이게 중요한게 아니다. 기존 석사 과정 2년간 하던 모바일 저전력 연구를 접은 지금 새로운 연구 주제가 결국 돌고 돌아 Secure OS 가 되었다. 그래서 오랜만에 보안 내용을 보게 된것이다. 이 무슨 수미쌍관적인 운명인지. 어쩌면 내 테크 트리는 이 연구를 위함이 아녔을까? Security-System-Mobile 이 합쳐진 Secure OS를 보기 위한...?
그럼, 이제 잡설은 줄이고, EAL에 대해 서술해 보도록 하겠다.
본론
감히 예측해 보건데, 이 글을 읽으시는 여러분은 EAL에 대해 처음 들어본 상황에서 열심히 구글링하고 계시지 않은가? 물론, Google은 내 블로그를 별로 안좋아 하니, 네이버 에서 보셨을 수도 있겠다. (구글신님 저를 굽어 살피소서)
[네이버에서는 2번에 있지만, 구글에서는 첫 페이지에 보이지 않는다]
각설하고, EAL을 나도 얼마전 까지 처음 들어봤었다. 앞서 서론에서 적은바와 같이, 최근에 연구 주제를 바꾸게 되어서 보기 시작한 내용이기도 하다. 그럼 EAL (Evaluation Assurance Level) 은 무엇일까?
EAL?
EAL은 CC(Common Criteria, 캠퍼스 커플이 아니다.) 에서 만든 소프트웨어의 평가 보증 을 위한 등급이다. 1999년 발효되었으며, 총 1에서 7까지 7단계로 나누어져 있다. 이는 같은 기관에서 만든 여러 규칙에 따라 작성된 문서를 통해 검증되며, 이 규정을 위한 설명과 문서들을 정의해 놓았다.
각 문서는 총 6가지의 클래스로 나누어 정리 가능하며 아래와 같다.
Development : 개발
Guidance docrument : 설명서
Life-cycle support : 생명주기 지원
Security Target evaluation : 보안목표 명세서 평가
Tests : 시험
Vulunerability assessment : 취약성 평가
-Common Criteria for Information Technology Security Evaluation 및 KISA의 한글 번역본 참조-
각 클래스는 다시 여러개의 패밀리로 분류되며, 각 EAL레벨 별로 클래스 마다 지켜야 하는 패밀리의 종류와 레벨이 다르게 지정되어 있다.
EAL 레벨 별 차이는 여러가지가 있지만 레벨 별 대표적인 특징만 정리한다면 아래와 같다.
[나름 EAL 버전 별 특성을 정리해 보았다]
아래 정리는, Common Criteria for Information Technology Security Evaluation 과 KISA의 한글 번역본을 참조하여 작성하였으며, KISA의 정보보호제품 평가제출물 작성 가이드 도 일부 참고 하였으나, 자의적으로 정리하였으므로 문서와 다른 내용/표현이 있을 수 있다.
EAL1 - 기능적인 시험
기능과 인터페이스에 대한 명세를 필요로 한다. 또한 제한적인 보안 명세서가 필요하다. 제한적인 보안 명세서라 함은, 단순히 프로그램(이하 TOE: Target Of Evaluation)이 만족해야 하는 보안 요구사항을 명확히 제시하는 것 만으로 충분하다. TOE의 기능이 설명서에 서술된대로 동작한다는 증거를 제공해야 한다.
EAL2 - 구조적인 시험
EAL1에 추가적으로 보안 아키텍쳐에 대한 구조 명세와 설계 명세가 추가된다. 이외에도 형상관리 시스템과 배포 절차에 대한 증거가 포함되는 등 구조적으로 안전함으로 보증한다. 또한 TOE명세에 기반한 독립적인 시험을 요구한다.
EAL2는 기존 시스템을 안전하게 하거나, 개발자와의 접촉이 어려울 경우, 즉 독립적으로 보증된 보안성을 필요로 할 경우 적용 가능하다.
EAL3 - 체계적인 시험 및 검사
EAL2에 추가적으로, TOE의 보안 구조 설계 명세가 필요하다. 또한 TOE의 형상괸리와 배포 절차 이외에도 개발환경 통제의 보증을 제공하여야 한다. 보다 완전한 범위의 보안 기증성 시험과 개발과정에서 TOE가 변경되지 않도록 하는 매커니즘과 절차를 요구한다.
EAL3는 설계 단계에서 기존 개발방법론의 많은 변화 없이 보안공학을 적용할수 있다. 실질적으로 소프트웨어 공학적인 재접근 없이, TOE및 TOE개발에 대한 조사를 필요로 할 경우 적용 가능하다.
EAL4 - 체계적인 설계, 시험 및 검토
EAL3에 추가적으로 완전한 인터페이스 명세와 TOE 모듈 설계 명세 그리고 TSF(TOE Security Functional, TOE 보안 기능)에 대한 구현의 표현의 일부를 필요로 한다. 구현의 표현은 소스코드 또는 하드웨어 다이어그램 등 실제 구현에 근접한 내용을 의미한다. 공격자의 침투 공격에 대한 내성을 제공된 기능명세, TOE 설계, 구현의 표현, 아티켁쳐 설계, 설명서 증거 등에 근거한 취약성 분석에 의해 뒷받힘 해야 한다.
EAL4는 상업적 개발 방법론에 기반한 시용적인 보안공학(Security engineering)으로 최대한의 보증을 얻을 수 있도록 한다. 전통적인 상용 TOE에 비교적 높은 수준의 보증된 보안성을 요구하며, 추가적인 비용을 지불할 용의가 있는 경우에 적용 가능하다.
여기까지 EAL 1~4 까지의 내용을 정리한 표는 아래와 같다.
[EAL1~4 등급별 구분 항목 표1]
EAL5 - 준정형화된 설계 및 시험
EAL4에 추가적으로 준정형화된 설계 명세와 보다 구조화된(분석 가능한)구조를 필요로 한다. 또한 모듈화된 TSF설계가 요구된다.
EAL5는 엄격한 상업적 개발 방법론에 기반한 보안공학으로부터 최대한의 보증을 얻을 수 있도록 한다. 엄격한 상업적 개발 방법론이란 전문적인 보안공학 기법을 완화시켜 응용하는 것을 말한다.
[EAL4와 5의 차이2]
EAL6 - 준정형화된 설계 검증 및 시험
EAL5에 추가적으로 정형화된 보안 정책 모델과, 기능과 TOE의 준정형화된 명세를 통해 보증을 제공한다. 이를 통해 준정형 검증을 하도록 한다. 보다 포괄적인 분석, 구조화된 구현의 표현, 보다 체계적인 구조(예: 계층화), 보다 포괄적이고 독립적인 취약성 분석, 개선된 형상관리와 개발환경 통제 등을 요구한다.
EAL6은 개발자가 심각한 위험으로부터 높은 가치의 자산을 보호하기 위한 최상의 TOE를 생산하기 위하여 엄격한 개발환경에서 보안 공학 기법을 응용하여 얻을 수 있는 높은 보증을 제공한다.
[EAL 5와 6의 차이 비교]
EAL7 - 정형화된 설계 검증 및 시험
EAL1 ~ 4 까지는 보안성의 증가가 이뤄지고, 5~7까지는 준정형 명세에서 정형 검증까지 정형화된 검증이 강해지는 구조를 가지고 있는것을 확인 가능하다. 여기까지로 이 글을 마치며, 각 기준 항목들과, 항목별 설명에 대하여 정리한 표를 아래에 첨부하며 마무리 짓도록 하겠다.
[EAL 패밀리 별 문서 설명, 클릭하여 확대]
