개념
이 레슨의 경계
두 가지를 먼저 가른다.
보안 시험 기법은 이 레슨이 다루지 않는다. 위협 모델링, 인증·인가 우회, 침투 시험 절차는 모듈 50 이 맡는다. 이 레슨은 인증 제도가 요구하는 구조와 증거 만 본다.
국내 보안 인증 제도들의 관계 정리도 이 레슨이 아니다. CC 인증, 보안기능확인서, 신속확인제의 중복과 선택은 모듈 33 쪽의 주제다. 이 레슨은 CC 의 구조 자체 와, 그 구조가 QA 작업에 만드는 요구를 다룬다.
그리고 공격 기법·취약점 세부는 쓰지 않는다. 레슨 1 에서 그은 경계가 그대로다.
CC 가 증명하는 것과 증명하지 않는 것
공통평가기준(Common Criteria, CC) 은 IT 제품의 보안 기능을 평가하는 국제적 틀이고, ISO/IEC 15408 로도 발행되어 있다. 공개 자료는 그 목적을 보안 기능과 역량을 일관되고 반복 가능한 방식으로 명세·구현·평가하는 데 있다고 설명한다.
QA 가 가장 먼저 교정해야 하는 오해는 이것이다. CC 인증은 "이 제품이 안전하다" 는 증명이 아니다. 증명하는 것은 좁다 — 제품이 스스로 주장한 보안 기능이, 선언한 깊이로 검증되었다. 주장하지 않은 것은 평가되지 않고, 선언한 깊이를 넘는 확신은 주어지지 않는다.
공개 자료가 보증수준에 대해 설명하는 문장이 이 점을 분명히 한다 — 높은 보증수준이 반드시 "더 나은 보안" 을 뜻하지 않고, 주장된 보안 확신이 더 광범위하게 검증되었음 을 뜻한다.
이 구분이 실무에서 왜 중요한가. 사업에서 "CC 인증 받았으니 보안 시험은 안 해도 되지 않나요" 라는 말이 반드시 나온다. 답은 아니오 이고, 근거는 두 가지다. 평가 범위(무엇을 주장했는가) 가 우리 사용 방식을 덮지 않을 수 있고, 평가는 특정 구성과 버전에 대한 것이다.
구조 — 평가 대상, 보안 목표, 보호 프로파일
CC 의 구조에서 QA 가 알아야 할 축은 셋이다.
평가 대상(TOE, Target of Evaluation) — 평가되는 것의 범위. 제품 전체가 아니라 제품의 일부일 수 있고, 특정 구성·특정 버전으로 한정된다. TOE 경계가 CC 문서에서 가장 중요한 한 줄 이다. 경계 밖은 평가되지 않았다.
보안 목표(ST, Security Target) — 그 TOE 가 주장하는 보안 기능과 가정, 위협, 그리고 적용할 보증 요구를 적은 문서. "무엇을 주장하는가" 가 여기 있다.
보호 프로파일(PP, Protection Profile) — 제품 범주 에 대한 보안 요구사항 묶음. 개별 제품이 아니라 "이 종류의 제품은 이런 요구를 충족해야 한다" 를 정한 것이다. 여러 기관이 공동으로 만드는 형태(협업 보호 프로파일) 도 쓰인다.
여기서 인증으로 가는 길이 두 갈래 라는 점이 실무적으로 중요하다. 공개 자료는 보증수준(EAL) 중심의 길과 보호 프로파일 중심의 길을 구분해 설명한다. 어느 길을 가는지에 따라 산출물과 시험 요구가 달라진다. 우리 사업이 어느 길인지, 어느 PP 를 적용하는지는 사업 문서와 해당 제도 운영 기관의 안내에서 확인한다(원문 확인).
보증수준(EAL) — 깊이의 등급
평가보증수준(EAL) 은 평가의 깊이와 엄격성을 나타내는 등급이다. 공개 자료는 EAL1(기능 시험됨) 부터 EAL7(정형적으로 설계 검증되고 시험됨) 까지 일곱 단계 로 설명하고, 숫자가 올라갈수록 평가의 깊이와 범위가 커진다고 안내한다.
각 수준의 구체적 보증 요구 항목과 요구 산출물 목록은 CC 원문의 해당 부분에서 확인한다(원문 확인). 외운 목록으로 일정을 세우지 않는다 — 레슨 1 의 원칙이 그대로 적용된다.
상호인정 에 대해서도 정확히 알아 둘 필요가 있다. 공통평가기준 상호인정 협정(CCRA) 에 따라 참여국 간에 평가 결과가 인정되는데, 공개 자료는 그 인정 범위가 낮은 보증수준(EAL1·EAL2 수준) 에 한정 되는 형태로 합의되어 있다고 설명한다. 협업 보호 프로파일 기반 평가가 상호인정의 다른 경로로 쓰인다는 설명도 함께 나온다. 인정 범위의 정확한 조건과 현행 합의 내용은 CCRA 와 제도 운영 기관의 공개 문서에서 확인한다(원문 확인). 이것이 실무에서 중요한 이유는 해외 수출·납품 시 "우리 인증이 그쪽에서 인정되는가" 가 사업 조건이 되기 때문 이다.
QA 가 실제로 만드는 것
CC 평가에서 QA 의 자리는 레슨 2 의 DO-178C 와 구조적으로 닮아 있다. 주장 → 요구 → 증거 의 사슬을 만드는 일이다.
실무에서 QA 가 기여하는 작업은 넷이다.
1) 보안 기능 주장을 시험 가능한 문장으로 번역한다. ST 에 적힌 보안 기능 요구는 추상적으로 쓰이기 쉽다. "식별되지 않은 사용자의 접근을 차단한다" 를 판정 가능한 조건과 절차 로 바꾸는 것이 QA 의 일이다. 모듈 58 레슨 1 의 오라클 논의가 여기서 쓰인다.
2) 기능과 시험의 추적표를 만든다. 주장된 보안 기능 하나하나가 어느 시험으로 덮이는지, 거꾸로 각 시험이 어느 주장을 덮는지. 양방향이다. 레슨 1·2 에서 만든 추적 식별자 체계를 그대로 쓴다.
3) TOE 경계를 시험 설계에 반영한다. 경계 밖은 평가 대상이 아니지만, 경계 위에서 벌어지는 일은 중요하다. 경계를 넘는 인터페이스, 경계 밖에 대한 가정 (ST 에 적힌 운용 환경 가정) 이 실제로 성립하는지가 시험 대상이 된다. 가정이 깨지는 조건을 만드는 시험 이 QA 가 제공할 수 있는 가장 값진 것이다.
4) 형상과 증거를 관리한다. 평가는 특정 버전·특정 구성에 대한 것이다. 시험 증거가 그 버전·구성과 맞물려 있지 않으면 쓰이지 못한다. 이것이 아래 절의 주제다.
통제된 환경의 증거 관리
이 분야의 시험 환경에는 제약이 걸린다. 보안 구역, 망분리, 매체 통제, 반출 승인, 기록 가능 범위의 제한. 이 조건에서 증거를 남기는 일은 일반 환경과 다르다.
먼저 원칙. 통제 절차를 우회해 증거를 만들지 않는다. 스크린샷을 개인 기기로 찍거나, 로그를 승인 없이 외부로 옮기거나, 통제 구역 밖으로 자료를 들고 나오는 행위는 어떤 업무적 이유로도 하지 않는다. 증거가 부족한 상황은 절차 안에서 해결한다 — 승인을 받거나, 기록 범위를 합의하거나, 증거 형태를 바꾼다.
그 전제 아래, 통제 환경에서 증거를 설계하는 방법은 이렇다.
1) 증거 형태를 미리 합의한다. 무엇을 어떤 형태로 남길 수 있는지를 시험 전에 확인한다. 화면 캡처가 가능한지, 로그 추출이 가능한지, 어떤 수준까지 외부 보고서에 쓸 수 있는지. 시험을 다 한 뒤에 "이건 반출 안 됩니다" 를 듣는 것이 최악이다.
2) 민감 정보를 증거에서 분리한다. 시험 결과를 증명하는 데 필요한 것은 판정의 근거 이고, 민감한 값 자체가 아닌 경우가 많다. 식별자를 치환하고, 실제 값 대신 "범위 안/밖" 판정을 남기고, 구성 정보는 참조 번호로 대체한다. 이 설계를 잘하면 증거의 반출 등급이 내려가 일이 쉬워진다.
3) 통제 구역 안의 기록과 밖의 보고서를 분리한다. 상세 증거는 구역 안에 보관하고, 밖으로 나가는 보고서에는 그 증거를 가리키는 참조 와 판정만 적는다. 심사·검토 때 상세가 필요하면 구역 안에서 열어 보인다. 이 두 층 구조가 통제 환경의 표준적 운영 방식이다.
4) 참관과 서명을 증거로 쓴다. 기록을 남길 수 없는 활동에서는 누가 참관했고 무엇을 확인했는지 가 증거가 된다. 서명된 확인서가 스크린샷을 대신한다. 이것이 형식적으로 보일 수 있지만, 통제 환경에서는 가장 실질적인 수단이다.
5) 재현 가능성을 절차로 보장한다. 증거를 자유롭게 남길 수 없으니, 같은 시험을 다시 할 수 있는 절차서 의 품질이 더 중요해진다. 레슨 4 의 환경 구성서와 결합해, 절차서만 보고 재현 가능한 수준으로 쓴다.
증거가 형상과 묶여야 한다
통제 환경이든 아니든, CC 평가에서 증거가 쓰이려면 어느 형상에 대한 것인지 가 확정되어야 한다. 관리할 축은 넷이다.
| 축 | 확인할 것 |
|---|---|
| 제품 형상 | 평가 대상 버전·빌드 식별, 포함된 구성요소 목록 |
| 환경 형상 | 운용 환경 구성, 의존 소프트웨어 버전, 설정값 |
| 시험 형상 | 시험 절차서 판본, 시험 데이터, 도구 버전 |
| 증거 형상 | 결과 파일의 회차와 이력(덮어쓰지 않는다) |
가장 흔한 실패는 설정값 이다. 평가는 특정 설정을 전제로 하는데, 시험할 때 편의를 위해 설정을 바꿔 두고 그 사실이 기록되지 않는다. 그러면 증거가 전제와 어긋난다. 설정은 파일로 관리하고 시험 증거에 함께 첨부 한다.
그리고 증거 파일을 덮어쓰지 않는다 는 원칙이 여기서도 적용된다(모듈 62 레슨 6 과 같다). 재시험 회차가 구분되지 않으면 이력이 사라지고, 심사에서 "이 결과는 몇 번째 시도입니까" 에 답할 수 없다.
변경이 인증을 흔든다
평가는 특정 버전에 대한 것이므로, 제품이 바뀌면 인증의 유효 범위가 문제가 된다. 보안 패치 하나를 적용해도 "이것이 인증된 제품인가" 라는 질문이 생긴다.
제도마다 변경 처리 방식(유지·재평가 등) 이 정해져 있고, 그 조건과 절차는 제도 운영 기관의 공개 안내에서 확인한다(원문 확인). QA 관점에서 미리 준비할 것은 변경 영향 분석의 양식 이다.
- 변경 내용과 영향받는 보안 기능
- 영향받는 ST 의 주장 항목
- 재시험 범위와 근거
- 환경·설정에 미치는 영향
- 증거 중 무효가 되는 것
이 양식을 미리 만들어 두면, 패치가 필요할 때마다 "인증 때문에 패치를 못 한다" 와 "일단 패치하고 나중에 생각한다" 사이에서 헤매지 않는다. 보안 패치를 미루는 것 자체가 위험이므로, 판단을 빠르게 하는 양식 이 실질적 가치를 갖는다.
실무에서 왜 필요한가
국내에서 CC 관련 QA 수요는 보안 제품 개발사, 공공 납품 솔루션 기업, 국방·공공 사업의 구성품 공급사 에서 나온다. 공고에는 "CC 인증 대응", "보안 요구사항 검증", "보증수준", "형상관리", "인증 산출물 작성" 같은 말이 적힌다.
이 일에서 QA 가 실제로 겪는 어려움은 보안 기술이 아니라 문서와 추적 이다. 평가 기관이 요구하는 것은 "시험을 많이 했다" 가 아니라 "주장한 기능 전부가 덮였음을 보여라" 이고, 그것을 보이는 수단은 추적표다. 추적표가 없으면 시험을 아무리 해도 평가가 진행되지 않는다.
그리고 통제 환경의 증거 설계 는 경험으로만 쌓이는 역량이다. 처음 들어간 사람은 반드시 한 번 막힌다 — 시험을 다 해 놓고 증거를 반출할 수 없거나, 증거에 민감 정보가 섞여 전부 다시 만들어야 한다. 그 경험을 미리 아는 것과 모르는 것의 차이가 크다. 증거 형태를 시험 전에 합의한다 는 한 가지 습관이 그 실패를 대부분 막는다.
마지막으로 이 레슨의 내용은 CC 밖에서도 쓰인다. 통제 환경의 증거 관리, 형상과 증거의 결합, 변경 영향 분석 양식은 규격 환경 전반의 공통 역량 이다. 레슨 1~5 와 합치면 "증거로 신뢰를 만드는 일" 의 전체 그림이 된다.