하계 보안 세미나 6일차 - 보안적합성 검사

이번 6강에서는 국가 보안적합성 검증 체계를 배웠다.

앞선 강의에서는 암호가 어떻게 깨지는지, 양자내성암호는 어떤 원리인지, 자동차와 임베디드 코드에는 어떤 취약점이 생기는지를 살펴봤다. 이번 강의는 기술 자체보다는, 그렇게 만든 보안 제품을 국가·공공기관에서 사용하려면 어떤 검증 절차를 거쳐야 하는지를 다뤘다.

처음에는 보안적합성 검증, 보안기능 확인서, KCMVP, CC 인증처럼 이름이 비슷한 제도가 계속 등장해서 헷갈렸다. 하지만 강의 전체를 관통하는 질문은 비교적 단순했다.

“이 제품은 안전합니다”라고 개발자가 말하는 것과
국가가 실제 시험을 거쳐 검증한 것은 무엇이 다른가?

 

CTF에서는 주로 “내가 이 시스템을 깰 수 있는가?”를 생각한다. 하지만 제품 개발과 납품 단계에서는 질문이 달라진다.

이 기능을 구현했는가?
요구사항을 정확히 지켰는가?
그 사실을 누가 검증했는가?
검증 결과를 증명할 문서가 있는가?

 

즉 제품을 잘 만들었다고 주장하는 것만으로는 부족하고, 그 주장을 객관적인 시험과 문서로 증명해야 한다.

이름이 비슷한 세 가지 제도

강의에서 먼저 구분한 것은 보안기능 확인서, KCMVP, CC 인증이었다.

셋 다 보안과 관련된 검증 제도라서 비슷해 보이지만, 실제로 확인하는 대상이 다르다.

구분확인 대상쉽게 말하면

보안기능 확인서	제품에 구현된 보안기능	제품 기능을 실제로 시험한 결과
KCMVP	제품 안의 암호모듈	암호 구현이 규격대로 만들어졌는지 검증
CC 인증	제품 전체의 보안성	제품 전체를 일정한 평가기준으로 평가

보안기능 확인서는 영상기기와 같은 IT 제품의 보안기능 시험 결과를 나타내는 증서다. 이번 강의에서 중심적으로 다룬 제도이기도 하다.

KCMVP는 제품 전체가 아니라, 제품에 탑재된 암호모듈을 검증하는 제도다. 암호 알고리즘만 사용한다고 끝나는 것이 아니라, 그 알고리즘을 구현한 모듈이 규격과 보안요구사항을 제대로 지켰는지를 확인한다.

CC 인증은 ISO/IEC 15408을 기반으로 제품 전체의 보안성을 평가하는 제도다.

한 문장으로 구분하면 다음과 같다.

보안기능 확인서 = 제품의 보안기능 시험
KCMVP = 제품 안의 암호모듈 검증
CC 인증 = 제품 전체의 보안성 평가

 

예를 들어 IP카메라가 국가·공공기관에 들어가려면 제품 보안기능 시험을 거쳐 보안기능 확인서를 받아야 한다. 그리고 카메라 안에서 영상을 암호화한다면, 그 암호화 기능에는 KCMVP 검증필 암호모듈이 요구될 수 있다.

즉 하나가 다른 하나를 완전히 대신하는 관계는 아니다.

한 제품에도 여러 층의 검증이 붙는다

강의 자료에서는 하나의 제품에도 세 가지 층위의 검증이 붙을 수 있다고 설명했다.

운용 환경
→ 보안적합성 검증

제품 보안기능
→ 보안기능 시험제도(VSFT)

암호 구현
→ KCMVP 암호모듈 검증

 

제품의 암호화 코드가 정상적으로 동작한다고 해서, 제품 전체가 국가·공공기관에 바로 도입될 수 있는 것은 아니다.

반대로 제품의 로그인 기능과 감사기록이 잘 구현되어 있어도, 저장 암호화에 사용한 암호모듈이 KCMVP 검증필 목록에 없다면 관련 요구사항을 충족하지 못할 수 있다.

이번 강의에서 가장 중요하게 느껴진 부분도 이것이었다.

“구현이 맞다”와
“검증을 통과했다”는
서로 다른 문장이다.

 

보안적합성 검증이란

보안적합성 검증은 국가·공공기관이 IT 제품을 도입하기 전에 해당 제품의 안전성을 검증하는 제도다.

제품을 먼저 도입한 뒤 문제가 발생하면 수정하는 것이 아니라, 도입 전에 시험하고 취약점을 보완한 뒤 사용하는 구조다. 따라서 공공기관에 제품을 납품하려는 업체에는 일종의 관문 역할을 한다.

제품 개발
→ 보안기능 시험
→ 취약점 발견
→ 보완
→ 결과 검토
→ 확인서 발급
→ 공공기관 도입

 

강의에서는 국가정보원법, 사이버안보업무규정, 전자정부법 등이 제도의 근거로 연결된다고 설명했다.

개인 프로젝트에서는 “기능이 실행되는가?”가 중심이 되지만, 공공기관 납품에서는 “도입 요건을 통과했는가?”가 더 중요한 질문이 된다.

어떤 제품이 검증 대상인가

보안적합성 검증 대상에는 방화벽, VPN, 스위치와 라우터, 안티바이러스, DB 접근통제, 양자키분배 장비, 영상정보처리기기 등 여러 종류가 포함된다.

강의 자료에서는 국가용 보안요구사항이 공통 요구사항과 제품별 요구사항으로 구성되며, 제품별 요구사항은 10개 제품군, 총 34종으로 나뉜다고 설명했다.

대표적인 제품군은 다음과 같다.

침입차단
침입방지
구간보안
전송자료보안
보안관리
가상화
엔드포인트 보안
네트워크 장비
양자암호통신
영상정보처리기기

 

제품 종류가 달라도 인증, 데이터 보호, 업데이트 보호, 감사기록 같은 기본 뼈대는 반복된다.

IP카메라도 검증 대상이 된다

강의에서는 영상정보처리기기가 검증 대상에 편입된 사례를 집중적으로 다뤘다.

2024년 4월 1일부터 TCP/IP 네트워크로 연결되어 데이터를 전송하는 영상정보처리기기는 보안적합성 검증 대상에 포함됐다.

여기서 중요한 구분은 네트워크 연결 방식이다.

TCP/IP로 연결되는 IP카메라
→ 검증 대상

아날로그 또는 SDI 방식으로 영상을 전송하는 카메라
→ 해당 기준에서는 대상 제외

 

IP카메라는 인터넷이나 내부 네트워크와 연결되기 때문에 계정 탈취, 영상 유출, 펌웨어 변조, 네트워크 침입과 같은 위험이 생긴다. 그래서 단순한 촬영 장비가 아니라 하나의 네트워크 보안 제품처럼 관리할 필요가 있다.

어느 제품이든 반복되는 공통 보안요구사항

제품마다 기능은 다르지만, 공통적으로 확인하는 보안 항목이 있다.

강의에서는 서버 공통 보안요구사항을 다음과 같은 영역으로 정리했다.

식별 및 인증
보안관리
데이터 보호
자체보호
업데이트 보호
안전한 세션 관리
감사기록
암호지원
취약성 대응

 

영상정보처리기기에는 여기에 영상 보안이라는 제품 고유 항목이 추가된다.

예를 들어 방화벽과 VPN, IP카메라는 서로 전혀 다른 제품처럼 보이지만 다음과 같은 기준을 공통으로 적용받을 수 있다.

패스워드는 일정 길이 이상이어야 한다.
인증에 반복 실패하면 계정을 잠근다.
사용하지 않는 세션은 일정 시간이 지나면 종료한다.
중요한 행위는 감사기록으로 남긴다.
업데이트 파일의 무결성과 출처를 검증한다.
암호 기능은 정해진 기준에 맞게 구현한다.

 

강의 예시에서는 패스워드 9자리 이상, 인증 실패 5회, 유휴시간 10분 같은 구체적인 수치도 등장했다.

보안요구사항은 “로그인을 안전하게 구현한다”처럼 모호한 문장이 아니라, 실제 시험할 수 있는 형태로 작성된다는 점이 중요했다.

보안기능 시험제도에 참여하는 기관

보안기능 시험제도에는 여러 기관이 서로 다른 역할로 참여한다.

강의에서는 이를 네 주체로 정리했다.

NIS: 정책기관

국가정보원은 검증 정책을 수립하고 시험기관 지정과 확인서 효력 등을 관리한다.

NSR: 검증기관

국가보안기술연구소는 시험 가이드를 제공하고, 시험 결과를 검토하며 확인서 발급을 승인한다.

TTA: 시험기관

영상기기 분야에서는 한국정보통신기술협회가 실제 보안기능 시험을 수행하고 확인서를 발급한다.

신청기관: 제조업체

제품을 개발한 업체는 시험을 신청하고, 필요한 문서를 제출하며, 시험 중 발견된 취약점을 보완한다.

정리하면 다음과 같다.

정책은 NIS
검증은 NSR
시험은 TTA
신청은 제조업체

 

제품을 개발한 업체가 직접 접촉하는 곳은 시험기관이지만, 그 뒤에는 결과를 검토하는 검증기관과 제도를 관리하는 정책기관이 있다.

시험 신청부터 도입까지

제품은 신청 즉시 확인서를 받는 것이 아니다.

강의에서 설명한 전체 흐름은 다음과 같다.

1. 시험 신청
2. 접수 및 계약
3. 시험수행 계획 수립
4. 보안기능 시험
5. 시험 결과 검토
6. 보안기능 확인서 발급
7. 공공기관 도입

 

시험 과정에서 부적합 판정을 받으면 신청기관이 취약점을 수정하고 다시 시험을 받아야 한다.

여기서 시험은 서류만 읽고 통과 여부를 정하는 방식이 아니다. 실제 제품을 실행해 로그인, 계정 잠금, 세션 종료, 암호화, 업데이트, 감사기록 등의 동작을 확인한다.

문서에는 안전하다고 적혀 있지만
실제 제품은 다르게 동작할 수도 있다.

따라서 시험기관은 문서와 실제 동작을 함께 확인한다.

 

보안기능 확인서가 의미하는 것

보안기능 확인서는 제품이 시험기준을 만족했다는 사실을 확인하여, 검증기관의 승인 아래 시험기관이 발급하는 증서다.

도입기관은 이 확인서를 통해 해당 제품이 검증 절차를 거쳤는지 확인한다.

강의 자료에서는 확인서가 발급일까지 알려진 취약점이 제거됐는지 확인하는 결과물이라고 설명했다. 하지만 확인서가 발급된 이후에 새로 발견되는 모든 취약점까지 없다고 보증하는 것은 아니다.

즉 확인서는 다음을 의미한다.

발급 시점의 기준과 알려진 취약점을 바탕으로
시험을 통과했다.

 

다음 의미는 아니다.

앞으로 절대 취약점이 발견되지 않는다.

 

국가용 보안요구사항을 기준으로 시험한 제품은 5년, 신기술 등 구현명세서를 기반으로 시험한 경우는 2년의 유효기간이 적용될 수 있다고 강의에서 설명했다.

시험을 위해 제출해야 하는 문서

신청기관은 제품만 보내는 것이 아니라, 제품의 구조와 보안기능을 설명하는 문서도 제출해야 한다.

강의에서 소개한 문서는 다음 다섯 종류였다.

문서주요 내용

제품설명서	제품 개요와 구성
보안기능 구현명세서	보안기능, 인터페이스, 계정
운용설명서	설치와 운용 방법
시험결과서	시험 결과
취약점 개선내역서	발견된 취약점과 조치 내용

이 문서들은 모두 한국어로 작성해야 한다.

특히 구현명세서에는 제품의 모든 인터페이스와 계정을 적어야 한다.

시험 과정에서 명세서에 없는 인터페이스나 숨겨진 계정이 발견되면 백도어로 간주될 수 있고, 확인서 발급이 거부될 수 있다.

숨겨진 관리자 계정
문서에 없는 디버그 포트
알려지지 않은 원격 접속 기능
개발용으로 남겨 둔 서비스

→ 검증 관점에서는 모두 심각한 문제

 

개발자는 편의를 위해 테스트 계정이나 디버그 기능을 남겨 둘 수 있지만, 검증 제품에서는 그런 숨겨진 기능 자체가 취약점이 된다.

제품 요구사항이 KCMVP를 요구하는 경우

제품 보안요구사항에는 KCMVP 검증필 암호모듈을 사용해야 한다는 조건이 들어갈 수 있다.

강의에서는 IP카메라가 영상을 기기 내부에 저장하는 상황을 예로 들었다.

기기 내부에 영상을 저장할 때
KCMVP 검증필 암호모듈로 암호화해야 한다.

 

즉 “AES로 암호화했습니다”라는 설명만으로는 부족할 수 있다.

어떤 AES 구현인가?
어떤 모듈에 포함되어 있는가?
그 모듈의 버전은 무엇인가?
어떤 운영환경에서 검증됐는가?
KCMVP 검증필 목록에 등재되어 있는가?

 

이런 부분까지 확인해야 한다.

KCMVP란

KCMVP는 Korea Cryptographic Module Validation Program의 약자로, 우리나라의 암호모듈 검증 제도다.

암호 알고리즘 이름만 확인하는 것이 아니라, 해당 알고리즘과 키 관리, 난수 생성, 자가시험 등을 포함한 암호모듈이 규격에 맞게 구현되었는지를 검증한다.

검증을 통과한 모듈은 검증필 암호모듈 목록에 등재된다.

암호모듈 개발
→ 시험기관 시험
→ NSR 검토
→ 검증필 목록 등재

 

실무에서 첫 번째로 확인할 질문은 다음과 같다.

제품에 탑재한 암호모듈이
검증필 목록에 있는가?

 

암호모듈의 경계

KCMVP에서는 암호모듈의 경계가 중요하다.

암호모듈의 경계 안에는 다음과 같은 기능이 포함될 수 있다.

암호 알고리즘 구현
키 생성·저장·폐기 등의 키 관리
난수 생성
알고리즘 자가시험
코드 무결성 검사

 

검증은 이 경계 안을 대상으로 한다.

예를 들어 암호 라이브러리는 KCMVP 검증을 받았지만, 그 라이브러리를 호출하는 애플리케이션 코드에서 키를 로그로 출력한다면 제품 전체는 안전하지 않다.

검증필 암호모듈
≠
그 모듈을 사용하는 모든 애플리케이션까지 자동으로 안전함

 

모듈 경계 밖의 앱 코드와 운영 설정은 별도로 안전하게 만들어야 한다.

KCMVP 보안수준 1~4

KCMVP 암호모듈에는 보안수준이 있다.

강의에서는 수준이 높아질수록 소프트웨어 구현뿐만 아니라 물리적인 침해까지 고려한다고 설명했다.

수준주요 특징

Level 1	소프트웨어 중심의 기본 구현 검증
Level 2	변조 흔적과 역할 기반 접근통제
Level 3	물리적 침해 대응과 키 접근 보호
Level 4	전압과 온도 같은 환경 이상 대응

무조건 가장 높은 수준이 좋은 것은 아니다. 제품이 놓이는 환경과 예상되는 공격을 고려해 적절한 수준을 선택해야 한다.

서버에서 실행되는 소프트웨어 암호모듈과, 공격자가 직접 만질 수 있는 하드웨어 보안장비는 위협 모델이 다르기 때문이다.

KCMVP 목록에서 확인해야 하는 정보

검증필 목록에 비슷한 이름의 모듈이 있다고 해서 바로 사용할 수 있는 것은 아니다.

강의에서는 목록에서 다음 다섯 가지를 확인해야 한다고 설명했다.

모듈명과 버전
지원 알고리즘
보안수준
유효기간
운영환경

 

같은 코드라도 버전이나 운영체제, 암호모듈 경계가 다르면 다른 검증 대상으로 볼 수 있다.

예를 들어 Linux용으로 검증된 특정 버전의 암호모듈을 다른 운영체제나 다른 버전에서 사용하면, 기존 검증의 적용 범위에 포함되지 않을 수 있다.

그래서 실무 질문은 단순히 다음과 같지 않다.

AES를 사용했는가?

 

조금 더 정확한 질문은 다음과 같다.

우리가 실제로 사용하는 그 모듈과 그 버전,
그 운영환경이 검증필 목록에 있는가?

 

구현이 올바른 것과 검증필인 것은 다르다

강의에서는 IP카메라의 영상 저장 암호화를 예시로 들었다.

AES-256-CBC를 사용하고, 프레임마다 IV를 새로 생성하며, 데이터 암호화 키인 DEK와 키 암호화 키인 KEK를 분리했다면 기술적으로는 비교적 올바른 구조일 수 있다.

AES-256-CBC
프레임 단위 암호화
DEK와 KEK 분리
IV 매번 무작위 생성

 

하지만 그 구현이 KCMVP 검증필 목록에 없는 자체 구현이라면, “검증필 암호모듈 사용”을 요구하는 조건은 충족하지 못한다.

암호 사용 방법이 맞음
≠
KCMVP 검증필 모듈임

 

수업이나 공개 예제에서는 환경 제약 때문에 일반 라이브러리를 사용할 수 있지만, 실제 제품에서는 검증필 모듈로 교체해야 한다는 점을 분명하게 적어야 한다.

KCMVP 검증 대상 암호 알고리즘

강의에서는 KCMVP 검증 대상이 되는 암호 알고리즘도 소개했다.

블록암호

SEED
ARIA
HIGHT
LEA

 

SEED와 ARIA는 범용적인 블록암호이고, HIGHT와 LEA는 자원이 제한된 환경에서도 사용할 수 있도록 고려된 경량 블록암호다.

해시

SHA-2
LSH

 

해시는 데이터의 무결성을 확인하거나 전자서명, 키 유도 등의 과정에 사용된다.

메시지 인증

HMAC

 

HMAC은 비밀키와 해시를 함께 사용해 메시지의 변조 여부와 인증을 확인한다.

공개키·전자서명

RSA
KCDSA
ECDSA

 

공개키 암호와 전자서명에 사용된다.

키 설정과 난수

키 교환
키 유도
DRBG

 

DRBG는 결정론적 난수비트생성기로, 암호키와 nonce 등에 필요한 안전한 난수를 만든다.

여기서 중요한 것은 알고리즘을 하나만 골라 넣는 것이 아니다.

암호화
해시
메시지 인증
키 생성과 유도
난수 생성
키 저장과 폐기
자가시험

 

이 과정이 하나의 암호모듈 안에서 안전하게 이어져야 한다.

암호모듈은 스스로 상태를 점검해야 한다

KCMVP 보안요구사항에는 자가시험도 포함된다.

대표적으로 KAT와 무결성 검사가 있다.

KAT(Known Answer Test)는 미리 정해진 입력과 정답을 가지고 암호 알고리즘이 올바른 결과를 내는지 확인하는 시험이다.

정해진 입력을 암호화
→ 미리 알고 있는 정답과 비교
→ 같으면 정상
→ 다르면 모듈 사용 중단

 

무결성 검사는 모듈 코드나 중요 파일이 변조되지 않았는지 확인한다.

자가시험에 실패했는데도 계속 작동하면 잘못된 암호 결과나 손상된 키가 사용될 수 있다. 그래서 실패 시 기능을 중단하는 fail-closed 방식이 중요하다.

요구사항은 실제 코드로 구현되어야 한다

강의 후반부에서는 IP카메라 예제 프로젝트를 통해 국가용 보안요구사항이 코드로 어떻게 연결되는지 살펴봤다.

가장 인상적이었던 점은 문서의 각 조항이 실제 조건문과 함수로 연결된다는 것이었다.

패스워드 정책

예를 들어 패스워드는 9자리 이상이어야 하고, 사용자 계정과 같은 값이나 qwer, asdf, 1234처럼 단순한 키보드 연속 문자열을 제한할 수 있다.

 

if len(password) < 9:
    return False

if username and password.lower() == username.lower():
    return False

 

강의 예제에서는 정방향 문자열뿐 아니라 rewq처럼 역방향 배열까지 검사했다.

결국 문서에 적힌 “취약한 패스워드를 제한한다”는 문장은 코드 안에서는 여러 개의 구체적인 조건문이 된다.

인증 실패 5회 계정 잠금

로그인에 연속으로 실패하면 계정을 잠그고, 그 사실을 감사기록에 남겨야 한다.

틀린 비밀번호 5회
→ 계정 잠금
→ 잠금 사건 감사기록
→ 일정 시간 후 해제

 

검사기는 서버 내부 코드를 직접 보지 않고 실제 로그인을 반복해 기능이 동작하는지 확인한다.

특히 5번 실패한 뒤 6번째 시도에서는 정상 비밀번호를 입력해도 인증이 거부되어야 진짜 계정 잠금이라고 판정할 수 있다.

인증 실패 원인을 자세히 알려주지 않기

로그인 실패 시 다음과 같이 구체적으로 알려주면 공격자가 계정 존재 여부를 확인할 수 있다.

존재하지 않는 사용자입니다.
비밀번호가 틀렸습니다.

 

따라서 외부에는 다음처럼 같은 메시지를 보여주는 편이 안전하다.

인증 실패

 

존재하는 계정과 존재하지 않는 계정의 응답을 같게 만들어 계정 열거 공격을 막는 것이다.

클라이언트가 보내는 헤더를 그대로 믿지 않기

X-Forwarded-For와 같은 HTTP 헤더는 프록시 환경에서 실제 클라이언트 IP를 전달할 때 사용한다.

하지만 신뢰할 수 있는 프록시를 거치지 않은 상황에서는 공격자가 헤더 값을 임의로 작성할 수 있다. 따라서 IP 기반 접근통제를 구현하면서 해당 헤더를 무조건 신뢰하면 우회될 수 있다.

클라이언트가 주장하는 IP
≠
실제로 연결한 네트워크 상대의 IP

 

강의 예제에서는 소켓에서 확인한 실제 peer 정보를 사용하도록 구현했다.

구동 시 자체시험과 주기적 무결성 검사

IP카메라가 켜질 때 다음 항목을 스스로 검사하도록 구현할 수 있다.

카메라 하드웨어 접근 가능 여부
서버 연결 가능 여부
TLS 인증서 유효성
암호모듈 동작 여부

 

작동 중에는 중요 파일의 현재 해시값을 기준값과 비교해 변조 여부를 확인한다.

강의 예제에서는 실행 시점과 24시간 주기로 무결성을 검사하고, 문제가 발생하면 안전하게 종료하는 방식을 사용했다. 이것은 KCMVP의 자가시험과 같은 방향의 설계라고 볼 수 있다.

감사기록도 보호해야 한다

보안제품은 중요한 사건을 로그로 남겨야 한다.

대표적인 감사 대상은 다음과 같다.

로그인 성공과 실패
계정 잠금
관리자 설정 변경
사용자 추가와 삭제
업데이트 수행
무결성 검사 실패
시스템 시작과 종료

 

하지만 로그를 남기는 것만으로는 충분하지 않다.

공격자가 로그를 수정하거나 삭제할 수 있다면 자신의 흔적을 없앨 수 있기 때문이다. 그래서 감사기록은 일반 사용자가 변경할 수 없도록 보호하고, 로그가 가득 찼을 때 어떻게 처리할지도 정해야 한다.

로그 생성
→ 권한 분리
→ 변경·삭제 방지
→ 저장공간 관리
→ 관리자 검토

 

추적매트릭스란

요구사항 문서에는 수많은 조항이 있다. 각 조항이 코드의 어느 파일과 함수에서 구현되었는지 정리한 표를 추적매트릭스라고 한다.

예를 들어 다음과 같이 연결할 수 있다.

요구사항구현 위치

패스워드 정책	password_policy.py
인증 실패 5회 잠금	auth.py
유휴 10분 세션 종료	verify_token()
감사기록 변경 방지	audit.py

시험관은 이 표를 따라가며 요구사항과 실제 구현이 연결되는지 확인할 수 있다.

추적매트릭스가 없다면 기능은 구현되어 있어도 어디에 있는지 찾기 어렵다. 반대로 표에 조항은 있지만 실제 코드가 없다면 미구현 상태가 드러난다.

조항 번호를 코드 주석에 남기기

강의에서는 코드에 요구사항 번호를 직접 주석으로 적는 방법도 소개했다.

 

# [NIS 2.2.1] 연속 인증 실패 시 계정 잠금
# [NIS 8.1.1] 계정 잠금 사건 감사기록

 

이런 주석을 일정한 형식으로 남기면 자동화 도구가 코드 전체를 검색해 다음 자료를 만들 수 있다.

조항별 구현 파일 목록
조항별 구현 함수 목록
미구현 조항 목록
검증 결과와 코드의 연결
구현명세서 초안

 

거창한 시스템을 처음부터 만드는 것보다, 일관된 조항 주석 한 줄이 자동화의 출발점이 될 수 있다는 설명이 인상적이었다.

검증 자동화의 흐름

강의에서는 요구사항을 코드와 시험으로 연결하는 과정을 여섯 단계로 정리했다.

1. 요구사항을 체크리스트로 변환
2. 조항 주석 작성 규칙 결정
3. 조항별 기능 구현
4. 추적매트릭스 자동 생성
5. 외부 검증기 작성
6. 구현명세서와 시험결과 초안 생성

 

검증기는 내부 구현을 믿지 않고 외부에서 제품을 실제로 두드린다.

예를 들어 다음을 자동으로 시험할 수 있다.

TLS 1.0과 1.1 연결이 거부되는가?
틀린 비밀번호를 5번 입력하면 계정이 잠기는가?
정상 비밀번호를 입력해도 잠금 상태가 유지되는가?
유휴시간이 지나면 세션이 종료되는가?
잘못된 업데이트 파일이 거부되는가?

 

모든 검증 결과를 PASS 또는 FAIL로 출력하고, 각 결과에 해당 조항 번호를 붙이면 시험 근거로 활용하기 쉬워진다.

강의에서 설명한 자동화의 종료 조건은 비교적 명확했다.

검증기 전 항목 PASS
+
추적매트릭스 미구현 조항 0개

 

FAIL이 나오면 해당 조항의 구현으로 돌아가 수정하고 다시 시험한다.

AI를 사용할 때도 원문 검수가 필요하다

강의에서는 AI를 활용해 요구사항 구현과 검증 자동화를 보조하는 방법도 소개했다.

예를 들어 다음처럼 구체적으로 요청할 수 있다.

IP카메라 요구사항 2.2.1을 구현한다.
연속 인증 실패 5회에서 계정을 잠근다.
5분 후 잠금을 해제한다.
잠금 발생 시 감사기록을 남긴다.
구현부마다 [NIS 2.2.1] 주석을 작성한다.

 

단순히 “보안을 강화해줘”라고 요청하는 것보다, 조항 번호와 수치, 필요한 산출물을 함께 알려주는 편이 훨씬 정확하다.

하지만 AI가 만든 코드와 문서는 어디까지나 초안이다.

조항 번호가 맞는가?
수치를 정확히 적용했는가?
조건부 요구사항을 잘못 필수로 해석하지 않았는가?
숨겨진 인터페이스나 계정을 만들지 않았는가?

 

이 부분은 반드시 원문 요구사항과 대조해 사람이 검수해야 한다. 검수되지 않은 자동화는 오히려 새로운 취약점이나 문서 불일치를 만들 수 있다.

이번 강의에서 기억할 핵심

이번 강의는 기술적으로 안전한 제품과, 공식적으로 검증된 제품 사이의 차이를 보여주는 내용이었다.

전체 흐름을 정리하면 다음과 같다.

보안적합성 검증
= 국가·공공기관 도입 전 제품 안전성 확인

보안기능 확인서
= 제품 보안기능 시험의 최종 결과물

KCMVP
= 제품 안의 암호모듈이 규격대로 구현됐는지 검증

CC 인증
= 제품 전체의 보안성 평가

 

그리고 제품 개발자의 관점에서는 다음 흐름으로 볼 수 있다.

보안요구사항 확인
→ 기능 구현
→ 조항과 코드 연결
→ 자체시험과 자동 검증
→ 취약점 수정
→ 제출문서 작성
→ 시험기관 시험
→ 확인서 발급

 

마무리

이번 강의를 듣기 전에는 제품에 AES나 TLS 같은 안전한 기술을 사용하면 보안제품이라고 부를 수 있다고 생각했다.

하지만 어떤 알고리즘을 사용했는지만으로는 부족했다. 암호모듈의 버전과 운영환경, 키 관리, 난수 생성, 자가시험까지 확인해야 하고, 제품 차원에서는 인증과 세션, 업데이트, 감사기록, 자체보호 기능도 함께 검증해야 한다.

무엇보다 중요한 점은 구현과 증명은 별개의 작업이라는 것이다.

코드를 잘 작성하는 것
요구사항을 정확히 구현하는 것
실제 동작을 시험하는 것
시험 결과를 문서로 남기는 것
공식 검증기관의 확인을 받는 것

 

이 모든 과정이 연결되어야 비로소 “검증된 제품”이 된다.

이번 6강의 핵심은 다음 문장으로 정리할 수 있을 것 같다.

보안은 “안전하게 만들었다”는 주장으로 끝나지 않는다.

무엇을 구현했고,
어떻게 시험했으며,
누가 그 결과를 확인했는지를
증명할 수 있어야 한다.