'IEC 62443-4-2 인증 취득'이 아무 뜻도 없는 이유

결론부터

"IEC 62443-4-2 SL2 인증 취득"이라는 문장만으로는 아무것도 알 수 없다. 62443-4-2 인증은 합격/불합격의 이분법이 아니다. 7개 기반 요구사항(FR)마다 세 개의 숫자가 찍히고, 그 숫자로 산수를 해야 무엇이 실제로 검증됐는지 나온다. 그리고 "SL2"라는 표기조차 네 종류의 서로 다른 보안 수준 중 어느 것인지 밝히지 않으면 의미가 흐려진다.

이 글은 62443-4-2 인증서를 읽는 법을 세 가지 각도에서 다룬다. 첫째, (RA, NAR, TR) 세 숫자의 산수. 둘째, "해당 없음(N/A)"과 "범위 밖"의 결정적 차이. 셋째, SL-T/SL-C/SL-D/SL-A 네 가지 보안 수준의 혼동을 바로잡는 것. 이 글은 62443 자체의 입문이 아니다 — 표준의 구조를 처음 보는 독자는 IEC 62443-4-2 입문을 먼저 읽는 편이 낫다.

1. 인증서에는 세 숫자가 찍힌다

가장 널리 쓰이는 62443 인증 경로인 IECEE CB Scheme(산업 사이버보안 프로그램, OD-2061)의 인증서는 7개 FR 각각에 (RA, NAR, TR) 형식의 세 숫자를 찍는다.

여기서 결정적인 사실 하나. TR은 제조사와 무관하게 표준 자체가 정하는 상수다. 62443-4-2 표준이 각 FR에 몇 개의 요구를 규정하는지는 고정되어 있다. 그래서 TR은 인증서 비교의 기준선이 된다.

(위 값은 공개 백서 정리 기준이며, 표준의 판(edition)·정오표 반영 여부에 따라 ±1 오차가 있을 수 있다. 실무에서는 4-2 원문으로 재검산해야 한다.)

인증서에 찍힌 TR이 이 표와 다르면, 판이 다르거나 서식이 다른 것이다. 이 대조표 하나만 손에 쥐고 있어도 인증서의 상당 부분을 검증할 수 있다.

2. 핵심 산수 — TR − (RA + NAR)

이제 본론이다. 세 숫자의 관계는 두 경우로 나뉜다.

RA + NAR = TR   →  모든 요구가 평가되거나 해당없음으로 처리됨
RA + NAR < TR   →  일부 요구가 범위에서 제외됨

차액 TR − (RA + NAR)이 "평가되지 않은(N/E, Not Evaluated)" 요구 수다. 그리고 이 숫자는 인증서에 직접 찍히지 않는다. 스스로 계산해야만 드러난다.

예를 들어 어떤 컴포넌트의 인증서에 EDR이 (9, 2, 13)으로 찍혀 있다고 하자. EDR의 TR은 13이다.

• RA = 9 (9개 통과)
• NAR = 2 (2개 해당 없음)
• 9 + 2 = 11 ≠ 13

차액 2개가 범위 밖(N/E)이다. 인증서 어디에도 "2개를 빼고 시험했습니다"라고 쓰여 있지 않다. 오직 산수로만 드러난다. 그 2개가 무엇이고 왜 빠졌는지는 인증서만으로는 알 수 없다.

이것이 "인증 취득" 문구가 정보량이 낮은 이유다. 마케팅 자료는 RA만 강조하고, NAR과 TR — 특히 산수로 계산되는 N/E — 은 언급하지 않는 경우가 많다.

3. N/A와 "범위 밖"은 완전히 다르다

여기서 가장 흔한 오해를 바로잡아야 한다. "해당 없음(N/A)"과 "범위 밖(N/E)"은 겉보기엔 둘 다 "이 요구는 평가 결과에 없다"이지만, 보안 함의가 정반대다.

N/A는 안전 신호다. 예를 들어 어떤 소프트웨어가 모바일 코드(JavaScript, Java 애플릿 등)를 전혀 사용하지 않는다면, 모바일 코드 관련 요구(CR 2.4)는 해당 없음이다. 제조사가 "우리는 모바일 코드를 안 씁니다"라고 선언하고 인증기관이 이를 사실로 확인한다. 없는 기능은 공격당할 수 없으므로, N/A는 오히려 공격면이 작다는 뜻이다. 그래서 N/A 판정을 받으려면 그 요구를 범위에 포함시켜야 한다 — 인증서에 NAR로 표기되어 "해당 없음이 확인됐다"를 보여주므로 신청자에게 이득이다.

N/E는 물음표다. 신청자가 그 요구를 아예 범위에서 뺐다는 뜻이고, 왜 뺐는지는 두 가지 가능성이 있다.

1. 추구하는 SL보다 상위 요구라서 (정상) — SL2를 목표로 하는데 SL3에서만 요구되는 항목은 자연히 범위 밖이다.
2. 해당 SL에서 요구되지만 제조사가 충족하지 못할 것으로 판단해 뺐음 (문제) — 이것이 위험한 경우다.

인증서만으로는 이 둘을 구분할 수 없다. 구분하려면 전체 시험보고서를 봐야 한다. 백서의 표현을 빌리면: "어떤 요구가 상위 보안수준의 것이라 빠진 것인지, 아니면 제조사가 해당되는 요구를 범위에서 뺀 것인지 확인하려면 일반적으로 전체 시험보고서를 봐야 한다."

즉 N/E가 크게 나온 인증서는 그 자체로 위험 신호는 아니지만, "시험보고서를 요청해야 한다"는 신호다. 정상적인 상위-SL 제외인지, 미충족 회피인지가 거기서 갈린다.

4. 왜 신청자가 범위를 고르는가

이 구조의 근원은 IECEE 스킴이 신청자에게 범위 선택권을 준다는 데 있다.

• 어느 표준을 쓸지, 그 표준의 어느 보안 요구를 평가받을지 신청자가 고른다.
• 표준의 모든 요구를 선택할 필요가 없다.
• N/A 판정을 원하면 그 요구를 범위에 넣어야 한다.

이 유연성은 양날의 검이다. 제조사 입장에서는 단계적 출시에 맞춰 인증을 받을 수 있다는 장점이다. 하지만 구매자 입장에서는 인증서만으로 "무엇이 빠졌는지" 알 수 없다는 단점이 된다. N/E 건수가 세 숫자에 직접 표기되지 않고 추론해야 하기 때문이다.

참고로 62443 인증에는 크게 두 스킴이 있다. IECEE CB Scheme(위에서 다룬 3-tuple 서식)과 ISASecure(ISA Security Compliance Institute의 스킴)다. 두 스킴은 서식이 다르다 — ISASecure는 3-tuple이 아니라 레벨 단위 표기를 쓴다. 하지만 한 가지 공통점이 결정적이다.

두 스킴 모두 "개발 프로세스 인증 없이는 컴포넌트 인증을 못 받는다"는 구조를 갖는다.

• IECEE: 4-2 제품 인증서는 4-1(개발 프로세스) 인증서를 참조하지 않으면 발급 불가.
• ISASecure: 컴포넌트 인증(CSA)을 받으려면 공급자가 먼저 SDLA(개발 생애주기) 인증을 보유해야 한다.

두 스킴이 독립적으로 같은 결론에 도달했다는 사실이 시사적이다. 컴포넌트 보안 인증의 전제는 개발 프로세스 인증이다. 그래서 4-2 인증서를 읽을 때는 항상 "참조된 4-1 인증서가 있는가"를 함께 확인해야 한다. 없으면 그 4-2 인증서는 애초에 성립할 수 없다.

5. SL2라는 표기의 함정 — 보안 수준은 네 종류다

이제 두 번째 큰 오해로 넘어간다. "SL2 제품"이라고 할 때, 그 SL2가 정확히 무엇인가?

62443에서 보안 수준(SL)은 한 종류가 아니라 네 종류다. 각각 생애주기의 다른 단계에 속하고, 다른 주체가 결정한다.

4-2 인증서가 말하는 것은 오직 SL-C다. 인증서에는 보통 "Product Capability Assessment"라고 명시된다 — 여기서 Capability(역량)이지 Achieved(달성)가 아니다. 즉 "이 컴포넌트는 SL2 수준의 위협을 자체적으로 막을 역량이 있다"이지, "이 컴포넌트가 설치된 환경에서 실제로 SL2가 달성되었다"가 아니다.

순서가 뒤집히면 안 된다

이 네 유형은 순서가 있다. SL-T가 먼저다.

① 시스템을 존·도관으로 분할
② 결과 분석 → 각 존·도관에 SL-T 할당 (위험평가)
③ SL-T를 채울 SL-C를 가진 컴포넌트 선정
④ SL-C < SL-T인 곳 → 보상 대응 수단 추가
⑤ 설계의 SL-A를 측정해 SL-T와 대조
⑥ 운영 중 SL-A 재측정 → 열화 감지

핵심은 **"목표(SL-T)를 먼저 정하고, 그것을 채울 역량(SL-C)을 가진 제품을 고른다"**는 순서다. SL-C만 보고 제품을 고르는 것은 순서가 뒤집힌 것이다. 위험평가로 SL-T를 정하지 않으면, SL-C가 얼마여야 충분한지 알 수 없다. 실제로 표준(3-3 Annex A.2.3)은 "제어 시스템 보안 역량은 사용 맥락과 독립적으로 결정되지만, 그 맥락 안에서 SL-T를 달성하기 위해 사용된다"고 명시한다.

그리고 중요한 사실 — 모든 컴포넌트가 SL-T를 스스로 만족할 필요는 없다. SL-C가 SL-T에 못 미치는 컴포넌트는 방화벽 같은 보상 대응 수단으로 메운다. "SL3 환경이니 모든 부품이 SL-C 3여야 한다"는 것은 오해다.

SL 0의 세 얼굴

같은 "SL 0"조차 유형에 따라 뜻이 다르다.

SL-C 0은 결함 신호이고, SL-T 0은 정상 판단이다. 같은 표기를 같은 뜻으로 읽으면 안 된다. "SL-T가 0이다"는 "이 FR은 이 존에서 그렇게 중요하지 않다"는 합리적 결정일 수 있다. "SL-C가 0이다"는 "이 제품은 이 FR에서 최소 요구조차 못 채운다"는 흠결이다.

(SL-D는 비교적 최근에 초안 단계에서 추가된 유형이다. 현재 발행된 3-3:2013과 4-2:2019는 SL-T/SL-C/SL-A 3종 체계이므로, 실무 문서에서 SL-D를 쓰면 심사원과 용어가 어긋날 수 있다. 발행판 확인 전에는 3종 체계를 기준으로 삼는 편이 안전하다.)

6. 인증서 읽기 — 실전 절차

지금까지의 내용을 하나의 체크리스트로 묶는다. 62443-4-2 인증서를 손에 쥐었을 때 밟을 순서다.

1. 인증서 종류 확인 — "Product Capability Assessment"인가? 역량(SL-C)이지 설치 환경의 달성(SL-A)이 아니다.
2. 제품 버전 확인 — "Certificate Coverage" 필드를 본다. v3.1의 인증서는 v4.2에 유효하지 않다.
3. 표준 판 확인 — 예: IEC 62443-4-2:2019. 판이 다르면 TR 대조표가 어긋난다.
4. 참조 4-1 인증서 확인 — 4-2 인증서는 4-1 인증서를 반드시 참조한다. 없으면 성립 불가.
5. FR별 3-tuple을 TR 표와 대조 — TR − (RA + NAR) 차액을 계산한다. 차액이 크면 시험보고서를 요구한다.
6. 디바이스 타입 판별 — SAR/EDR/HDR/NDR 네 종 중 RA ≠ 0인 것이 실제 컴포넌트 타입이다. 나머지가 (0, 0, ...)이면 그 타입은 해당 없음이다.

왜 단일 숫자로 압축되지 않는가

마지막으로, 이 모든 복잡성의 근원. 62443-4-2 인증은 7개 FR 벡터의 길이 측정이다. FR3은 최고 수준에서 19개의 "눈금"을 갖고, FR5는 4개뿐이다. 각 FR은 독립된 축이다.

그래서 "SL2 제품"과 "SL3 제품"의 비교는 FR별로 해야 한다. SL 상승의 기울기가 FR마다 다르기 때문이다.

• FR5(제한된 데이터 흐름)는 SL1~SL4가 전부 동일하다(4개 요구, RE 없음). 망 분할 요구는 SL이 올라가도 늘지 않는다.
• 반대로 FR1(식별·인증)은 SL2→SL3에서 강화요구(RE)가 1개에서 7개로 급증한다.

즉 "SL3 제품"이 "SL2 제품"보다 모든 FR에서 강하다는 뜻이 아니다. FR5에서는 둘이 똑같고, FR1에서는 격차가 크다. 이것이 SL을 단일 숫자로 압축할 수 없는 이유이고, 인증서가 FR별로 세 숫자를 찍는 이유다.

정리

"IEC 62443-4-2 SL2 인증 취득"이라는 문장은 세 층위에서 정보를 감춘다.

• 어떤 FR이 얼마나 평가됐는지 — 인증서의 (RA, NAR, TR)을 FR별로 보고 TR − (RA + NAR) 차액을 계산해야 드러난다.
• 무엇이 빠졌는지 — N/A(안전)와 N/E(모름)는 다르며, N/E는 시험보고서를 봐야 이유를 안다.
• 어떤 SL인지 — SL-C(역량)이지 SL-A(설치 환경의 달성)가 아니며, SL-T(목표)와는 결정 순서가 반대다.

인증서는 합격 도장이 아니라 벡터의 좌표다. 그 좌표를 읽는 산수를 모르면, "인증 취득"이라는 문구는 정말로 아무것도 말해 주지 않는다. 62443의 요구사항 구조 자체 — FR1~7과 컴포넌트 타입, SL 벡터 — 를 더 알고 싶다면 IEC 62443-4-2 입문에서 지도를 그려 두었다.