개념
레슨 2의 두 층이 세 층이 된다
레슨 2에서 TS 103 701이 평가를 개념 평가(문서가 요구를 충족하는가) 와 기능 평가(기기가 문서대로 동작하는가) 로 나눈다고 했다. EN 18031은 이 구조를 물려받되 기능 평가를 둘로 쪼갠다.
TS 103 701 EN 18031
──────────── ─────────────────────────────────────────
개념 평가 → 개념 평가 문서와 근거가 요구를 충족하는가
기능 평가 → 기능 완전성 평가 문서가 빠짐없는가 — 실제로 확인
기능 충분성 평가 구현이 충분히 강한가 — 실제로 공격완전성과 충분성의 차이가 이 레슨의 절반이다. 완전성은 "목록이 다 있는가", 충분성은 "있는 것이 버티는가" 다. 인터페이스 목록에 SSH·HTTPS만 적혀 있는데 포트 스캔에서 Telnet이 열려 있으면 완전성 실패다. 목록은 정확한데 HTTPS가 낡은 암호 스위트를 받아들이면 충분성 실패다.
첫 작업 — 자산 식별
EN 18031은 "무엇을 보호하는가" 로 시작한다. 파트 1이 다루는 자산은 두 종류다.
| 자산 | 뜻 | 예 |
|---|---|---|
| 보안 자산(security asset) | 보안 기능 자체와 그것을 지탱하는 민감한 보안 파라미터 | 인증 자격증명, 암호 키, 인증서, 업데이트 서명 검증 키, 접근 통제 설정 |
| 네트워크 자산(network asset) | 네트워크 기능과 그 설정, 네트워크 자원 | 라우팅·방화벽 설정, 무선 연결 설정, 대역폭 같은 네트워크 자원 |
파트 2는 여기에 개인정보 자산, 파트 3은 금융 자산 을 더한다(레슨 4).
자산 식별이 첫 작업인 이유는 모든 요구사항의 적용 여부가 자산에서 갈리기 때문 이다. 보호할 자산이 접근 경로를 갖지 않으면 접근 통제 요구가 비적용이 되고, 기기가 자격증명을 전혀 저장하지 않으면 보안 저장 요구의 범위가 줄어든다. 자산 목록이 부실하면 뒤따르는 모든 비적용 판정이 근거를 잃는다.
메커니즘 11개, 요구사항 31개
EN 18031은 "AES-256을 쓰라" 같은 해법을 지정하지 않는다. 대신 메커니즘 을 묻는다 — 접근 통제 메커니즘이 있는가, 그것이 적절한가. 이렇게 하면 스마트 플러그부터 공유기까지 같은 규격으로 평가할 수 있다. 공개된 EN 18031-1 성적서의 요구사항 목록을 정리하면 이렇다.
| 코드 | 메커니즘 | 요구사항 | 요지 |
|---|---|---|---|
| ACM | 접근 통제 | ACM-1, ACM-2 | 자산 접근을 권한 있는 주체로 제한 |
| AUM | 인증 | AUM-1 ~ AUM-6 | 적용성·적절성, 인증자 검증, 인증자 변경, 패스워드 강도(AUM-5), 무차별 대입 방어 |
| SUM | 보안 업데이트 | SUM-1 ~ SUM-3 | 적용성, 무결성·진정성 있는 업데이트, 자동 업데이트 |
| SSM | 보안 저장 | SSM-1 ~ SSM-3 | 적용성, 저장 자산의 무결성 보호, 기밀성 보호 |
| SCM | 보안 통신 | SCM-1 ~ SCM-4 | 적용성, 무결성·진정성, 기밀성, 재전송 방지 |
| RLM | 복원력 | RLM-1 | 서비스 거부 등의 영향 완화 |
| NMM | 네트워크 모니터링 | NMM-1 | 공격 징후 탐지 |
| TCM | 트래픽 통제 | TCM-1 | 악성 트래픽 통제 |
| CCK | 기밀 암호 키 | CCK-1 ~ CCK-3 | 키의 적절성, 생성 방식, 출고 시 고정값 금지 |
| GEC | 일반 기기 역량 | GEC-1 ~ GEC-6 | 알려진 취약점 없음, 서비스 노출 제한, 선택 서비스 설정, 노출 인터페이스 문서화, 불필요한 외부 인터페이스 없음, 입력 검증 |
| CRY | 암호 | CRY-1 | 모범 사례 암호 사용 |
요구사항 이름에 두 패턴 이 반복된다는 점을 보자. -1 은 대부분 "적용성
(Applicability)", 그다음 번호는 "적절한(Appropriate) ~" 이다. 먼저 이
메커니즘이 필요한지 정하고, 필요하다면 충분한지 본다. 이 순서가 규격 전체의
사고방식이다.
NMM과 TCM은 성격상 네트워크 장비 에 걸리는 요구다. 공개 성적서에서도 공유기가 아닌 데이터 수집 모듈은 이 두 요구를 "네트워크 장비 아님"을 사유로 N/A 처리했다. 레슨 1에서 본 N/A(제품 성질로 빠짐)의 전형이다.
결정 트리 — 적용하지 않을 자유와 그 대가
각 메커니즘의 적용성 판단에는 규격이 결정 트리 를 준다. 트리의 노드는 예·아니오 질문이고, 끝은 "적용"과 "비적용" 판정이다.
(개념 예시 — 실제 노드 문구는 규격 원문을 따른다)
자산 A 에 대한 접근 경로가 있는가?
├─ 아니오 ──────────────────────────────▶ 비적용 (근거: 경로 부재 입증)
└─ 예
그 접근이 의도적으로 공개된 것인가?
├─ 예 (정당한 이유 문서화) ─────────▶ 비적용 (근거: 공개 의도와 위험 평가)
└─ 아니오
다른 통제로 이미 막혀 있는가?
├─ 예 (대체 통제 문서화) ──────▶ 대체 통제 평가로 이동
└─ 아니오 ────────────────────▶ 적용 → 적절성 요구로 이동여기서 중요한 것은 비적용도 결과물 이라는 점이다. 트리에서 "비적용"에 도달하려면 그 경로의 모든 질문에 대한 증거가 있어야 한다. 개념 평가의 절반은 제조사가 선택한 트리 경로를 따라가며 각 분기의 근거가 타당한지 보는 일이다.
결정은 기기 전체가 아니라 항목 단위 로 내린다. 같은 기기라도 인터페이스마다 결정이 다를 수 있다. 관리용 웹 인터페이스에는 접근 통제가 적용되고, 로컬 네트워크 기기 탐색용 광고 패킷에는 공개 의도로 비적용이 될 수 있다. 그래서 결정 기록은 "자산 × 인터페이스" 표 형태가 된다.
세 가지 평가를 요구사항 하나에 붙이기
적용으로 판정된 요구사항마다 세 평가가 붙는다.
| 평가 | 방법 | 대표 도구·기법 | 실패의 모양 |
|---|---|---|---|
| 개념 평가 | 문서 검토 — 선택한 메커니즘, 구현 설명, 트리 경로의 근거 | 문서 대조표 | 근거가 없거나 모순된다 |
| 기능 완전성 평가 | 문서가 빠짐없는지 직접 확인 | 포트·서비스 스캔, 트래픽 캡처, 설정 화면 전수 확인 | 문서에 없는 인터페이스·서비스가 존재한다 |
| 기능 충분성 평가 | 구현이 공격에 버티는지 직접 시험 | 퍼징, 침투 테스트, 코드 리뷰, 부하·스트레스 시험 | 기형 입력에 죽는다, 우회된다, 약한 설정이 받아들여진다 |
공개 성적서를 보면 기능 완전성 평가가 "수행 불요(N/E)" 로 적힌 줄이 많다. 규격 구조상 충분성 평가가 완전성 확인을 포함하는 요구사항이 있기 때문이다. 이런 줄을 "완전성 확인을 안 했다"로 읽으면 안 된다. 반대로 시험소가 N/E를 쓸 때는 규격의 어느 부분이 그 생략을 허용하는지 가 방법 기술에 들어가야 한다.
제조사가 낼 문서에는 번호가 붙어 있다
EN 18031은 평가에 필요한 정보를 정보 요소(E.Info) 로 번호를 붙여 지정한다.
예를 들어 E.Info.ACM-1.ACM 처럼 요구사항 번호와 대상이 이름에 들어간다.
일반 정보로는 대체로 다음이 요구된다.
- 기기의 의도된 기능
- 기술 정보(구성, 인터페이스)
- 채택했다고 선언한 모범 사례
- 메커니즘별 구체 사항
- 보안 위험 평가
이 번호 체계는 레슨 2의 IXIT와 같은 역할을 한다. 차이는 요구사항 번호와 1:1로 묶여 있다 는 점이다. 제조사 QA가 기술 문서를 이 번호 순서로 목차화하면 시험소의 개념 평가 시간이 크게 줄어든다.
규격은 흔히 쓰이는 기술적 해법을 구현 범주(implementation category) 로 묶고, 그 범주를 택했을 때 추가로 확인할 구현 특화 평가 단위 를 준다. 예컨대 업데이트 보호를 전자서명으로 구현했다면, 서명 방식에 특화된 평가 단위가 더 붙는다. 레슨 4에서 볼 파트 3의 제한 조항(6.3.2.4)이 바로 이 구현 범주를 겨냥한다.
요구사항 하나를 끝까지 — AUM-5 패스워드 강도
공개 성적서에서 AUM-5는 6.2.5 절 에 있다. 그리고 레슨 1에서 본 관보 제한 조항이 6.2.5.1과 6.2.5.2 다. 즉 EN 18031 세 파트에 공통으로 걸린 제한이 정확히 이 요구사항 안에 있다. 시험 설계를 끝까지 따라가 보자.
1단계 — 적용성. 기기에 패스워드 기반 인증이 있는가? 없다면(예: 인증서 기반 기기 인증만 사용) AUM-5는 비적용이고, 대신 AUM-2 이하에서 다른 인증의 적절성을 본다. 있다면 적용.
2단계 — 제한 조항 확인(시험 전). 사용자가 패스워드를 설정하지 않거나 쓰지 않는 선택지가 있는가? 있다면 시험 결과와 무관하게 이 요구에 대한 적합성 추정이 성립하지 않는다 는 의견을 따로 준비한다. 이것을 시험이 끝난 뒤 발견하면 제조사의 출시 일정이 무너진다.
3단계 — 세 평가 설계.
| 평가 | 시험 항목 | 증거 |
|---|---|---|
| 개념 | 패스워드 정책 문서 — 최소 길이·복잡도·흔한 패스워드 목록 차단 여부, 출고 시 초기 패스워드 생성 방식 | 정책 문서, E.Info 대응 |
| 완전성 | 패스워드 인증을 쓰는 모든 인터페이스가 문서에 있는가 — 웹 UI, 앱, SSH, Telnet, 시리얼 콘솔, 로컬 API | 포트 스캔 결과 ↔ 문서 목록 대조표 |
| 충분성 | 정책 경계 바로 아래 패스워드(길이 N−1), 흔한 패스워드, 사용자 ID와 같은 패스워드가 거부되는가. 정책이 모든 인터페이스에서 동일하게 강제되는가 | 시도별 요청·응답 기록 |
충분성 평가 세 번째 줄에서 모듈 3의 경계값 분석 이 그대로 쓰인다. 최소 길이가 8이면 7자·8자를 시험한다. 그리고 "모든 인터페이스에서 동일하게"가 가장 자주 실패한다. 웹 UI는 정책을 강제하는데 앱의 설정 API는 서버 측 검증 없이 클라이언트 측에서만 검사하는 경우다. 이것은 GEC-6(입력 검증)과도 겹친다.
무차별 대입 억제는 AUM-6이다. AUM-5를 통과해도 무제한 시도를 허용하면 AUM-6에서 걸린다. 두 요구를 한 시험 세션에서 함께 설계하되, 판정은 요구사항별로 따로 적는다.
GEC — 가장 넓고 가장 자주 걸리는 묶음
GEC(일반 기기 역량)는 특정 보안 기능이 아니라 기기 전반의 위생 을 본다.
- GEC-1 알려진 악용 가능 취약점 없음 — 사용 소프트웨어·하드웨어 구성품 목록을 공개 취약점 데이터베이스와 대조한다. 구성품 목록(SBOM)이 없으면 시작할 수 없다
- GEC-2·3 서비스 노출 제한과 선택 서비스 설정 — 기본값으로 켜진 서비스가 필요한 것뿐인가
- GEC-4 노출 인터페이스·서비스 문서화 — 완전성 평가의 기준 문서
- GEC-5 불필요한 외부 인터페이스 없음 — 양산품에 디버그 포트가 살아 있지 않은가
- GEC-6 입력 검증 — 네트워크·API 입력의 검증
공개된 한 성적서는 파생 모델을 원 성적서에 기대어 발행하면서 GEC-1과 GEC-5만 파생 모델에서 다시 수행 했다. 이유가 교훈적이다. 보안 메커니즘은 모델 간에 같다고 선언할 수 있어도, 탑재 부품 버전(GEC-1)과 물리 인터페이스 구성(GEC-5)은 모델마다 달라지기 때문 이다. 파생 모델 성적서를 설계할 때 어떤 요구를 재시험할지 정하는 기준이 여기서 나온다.
성적서 한 장의 모양
공개된 EN 18031-1 성적서들은 대체로 다음 순서를 따른다.
1. 표지 규격 판, 모델·파생 모델, 펌웨어 버전
2. 판정 기호 P · F · N/A · N/E 정의
3. 시험 개요 원 성적서 번호(파생 발행 시), 모델 간 차이, 재시험 항목
4. 시험 정보 시료 수령일, 시험 기간, 시험 장소
5. 제품 정보 구성품(무선 칩·물리 인터페이스), 제품 설명
6. 시험 환경 단독 동작 불가 기기는 호스트 장비와 결합한 구성
7. 시험 도구 도구명과 버전 (스캐너·패킷 분석기·취약점 스캐너 등)
8. 요구사항 표 메커니즘 → 요구사항 → 개념/완전성/충분성 세 줄 → 판정6번이 소프트웨어 시험 경험자에게 낯선 부분이다. 인버터에 붙어야만 동작하는 통신 모듈은 호스트 장비와 결합한 상태로 시험 하고, 그 구성을 명시한다. 모듈 31 레슨 2의 시험 환경 기재 가 여기서는 "무엇과 결합했는가"를 포함한다. 7번의 도구 버전은 모듈 32 레슨 4의 원자료 재현성 요구와 이어진다. 취약점 스캐너의 결과는 플러그인 데이터베이스 버전 에 따라 달라지므로 버전 없이는 재현할 수 없다.
실무에서 왜 필요한가
EN 18031 시험이 지연되는 원인은 대체로 세 곳에 몰린다.
자산 목록과 인터페이스 목록이 없다. 제조사가 위험 평가 없이 시료만 보내면 시험소는 자산 식별부터 대신 해야 하고, 그 결과를 제조사가 다시 확인하는 왕복이 생긴다. 제조사 QA가 시험 의뢰 전에 자산 × 인터페이스 표 를 만들어 두면 이 왕복이 사라진다.
비적용 근거가 한 줄이다. "해당 없음"은 결정 트리의 경로를 보여주지 않는다. 개념 평가에서 반려되고 문서 보완 라운드가 추가된다. 모듈 33 레슨 5에서 결함 라운드 수가 준비 수준의 함수라고 했던 것이 여기서도 똑같다.
SBOM이 없다. GEC-1은 구성품 목록 없이 판정할 수 없다. 펌웨어를 받아 구성품을 역추출하는 작업은 시간이 들고 정확도도 낮다. 레슨 1에서 본 CRA 역시 SBOM을 요구하므로, 이 문서 하나가 두 제도에 동시에 쓰인다.
시험소 쪽에서는 N/E·N/A 판정의 근거 기술 이 품질의 척도가 된다. 생략의 근거가 방법서에 적혀 있지 않으면 평가자 입장에서 누락과 구분되지 않는다.