IEC 62443-4-2 입문 — FR1~7과 컴포넌트 요구사항 지도

들어가며

IEC 62443-4-2는 산업 자동화 제어 시스템(IACS)을 구성하는 컴포넌트 하나하나 — PLC, 산업 스위치, HMI PC, SCADA 소프트웨어 — 가 어떤 사이버보안 요구를 충족해야 하는지를 정의하는 표준이다. 이 글은 그 표준을 처음 마주하는 사람을 위한 지도다.

62443 문서를 처음 열면 압도되기 쉽다. 부(Part)가 여러 개이고, FR·CR·SR·SL·SL-C 같은 약어가 쏟아진다. 하지만 이 표준은 몇 개의 골격 발상만 잡으면 나머지가 제자리를 찾는다. 그 발상들은 이렇다 — 표준은 주제가 아니라 독자로 나뉜다. SL에는 네 얼굴이 있다. 보안은 7개의 독립된 축(FR)으로 분해된다. 그리고 산업 보안의 목표는 "공격을 막아라"가 아니라 "공격받아도 제어를 놓지 마라"다.

이 글은 IEC 62443-4-2를 다룬다. 인증서를 실제로 읽는 법은 별도 글에서, CRA와의 관계는 또 다른 글에서 이어 다룬다. 여기서는 표준 자체의 뼈대를 세운다.

1부 — 좌표를 잡는다

1.1 왜 IACS 보안은 IT 보안과 다른가

시작점은 이 질문이다. IT 보안 솔루션을 산업 제어 시스템에 그대로 가져다 붙이면 왜 안 되는가?

우선순위가 다르기 때문이다.

• IT 보안 — 정보 보호가 우선이다. 기밀성(Confidentiality)이 최상위 가치다. 서버가 잠깐 느려지거나 재부팅되는 것은 감수할 수 있다.
• IACS 보안 — 제어 시스템의 가용성, 플랜트 보호, 운영 연속성, 실시간 응답이 최상위다. 컨트롤러가 잠깐 멈추면 그것이 곧 물리적 사고다.

IT 보안 대책을 IACS에 그대로 적용하면 부작용이 난다. 강한 인증을 걸었더니 비상 상황에서 조작이 지연되고, 무결성 검사를 돌렸더니 실시간 제어 주기를 놓친다. 필수 서비스 손실·비상 절차 방해가 발생한다. 그래서 IACS는 IT와 다른 보안 프레임워크가 필요하고, 62443이 그 프레임워크다.

이 우선순위 전도는 이 글 전체를 관통한다. 뒤에서 볼 "인증이 비상 운영을 방해하면 안 된다", "DoS를 막는 게 아니라 저하 모드를 유지한다" 같은 요구들이 전부 여기서 나온다.

1.2 62443은 주제가 아니라 독자로 분할된다

가장 흔한 오해가 "1-1이 개론이고 4-2가 심화"라고 읽는 것이다. 틀렸다. 62443 시리즈의 분할축은 난이도가 아니라 누가 무엇에 책임지는가다.

즉 각 부는 다른 역할의 사람이 읽으라고 쓰였다. 그리고 역할마다 적합성을 주장해야 할 표준 목록이 다르다.

4-2는 제품 공급자의 표준이다. PLC를 만드는 회사가 "우리 PLC가 이런 보안 역량을 갖췄다"를 증명하기 위한 것이다. 자산 소유자가 자기 공장 전체의 보안을 4-2로 주장할 수는 없다 — 그건 3-2·3-3·2-1의 영역이다. 자기 역할 밖 표준으로 적합성을 주장할 수 없다는 것이 이 구조의 핵심이다.

표준 계층으로 다시 보면 이렇다.

IEC 62443-1-1 (용어/개념/모델)
    └── IEC 62443-3-3 (시스템 SR + SL 정의)
            └── IEC 62443-4-2 (컴포넌트 CR + SL-C 정의)
IEC 62443-4-1 (보안 제품 개발 프로세스)

4-2의 컴포넌트 요구(CR)는 3-3의 시스템 요구(SR)를 컴포넌트 수준으로 구체화한 것이다. 그래서 CR 번호는 SR 번호와 일치하도록 설계되어 추적성을 확보한다. 이 때문에 CR 번호가 불연속적으로 나타날 수 있다(예: CR 1.6이 없고 CR 1.7로 건너뛰기도 한다).

1.3 SL의 네 얼굴

62443에서 "보안 수준(SL)"은 한 종류가 아니다. 네 종류이고, 각각 생애주기의 다른 단계에 속한다. 이걸 혼동하는 것이 SL 개념 오용의 가장 흔한 원인이다.

4-2는 SL-C만 다룬다. 표기는 SL-C(FR, component)이고 값은 0~4다. SL-C는 "이 컴포넌트가 보상 대응 수단 없이 자체적으로 이 수준의 위협을 막을 수 있는 역량"을 뜻한다. 설치 환경에서 실제로 달성되는 수준(SL-A)이나 목표(SL-T)와는 별개다.

순서가 중요하다. SL-T가 먼저 정해지고, 그것을 채울 SL-C를 가진 컴포넌트를 고른다. 위험평가(3-2)로 각 존·도관에 SL-T를 할당하고, SL-C가 SL-T에 못 미치면 방화벽 같은 보상 수단으로 메운다. 모든 컴포넌트가 SL-T를 스스로 만족할 필요는 없다 — 이것이 3-3의 명시적 원칙이다.

1.4 SL 0의 세 얼굴

SL이 네 종류라는 것의 실전적 귀결 하나. 같은 "SL 0"조차 유형에 따라 뜻이 정반대다.

SL-C 0은 흠결이고, SL-T 0은 합리적 결정이다. "이 FR은 이 존에서 그렇게 중요하지 않아 SL-T를 0으로 뒀다"는 정상적인 위험 결정일 수 있다. 하지만 "이 제품의 SL-C가 0이다"는 최소 요구조차 못 채운다는 흠결이다. 같은 표기를 같은 뜻으로 읽으면 판단을 망친다.

한 가지 더 — SL은 위협 행위자의 프로파일이지 품질 등급이 아니다.

SL이 오르는 것은 "더 좋은 제품"이 아니라 "더 강한 적을 상정한 제품"이다. SL1은 실수를 막고, SL4는 국가 지원 공격을 막는다.

1.5 CR과 RE — 요구가 누적되는 방식

각 FR은 여러 개의 CR(Component Requirement)로 구체화된다. 그리고 각 CR은 기본요구(baseline)를 정의하고, **RE(Requirement Enhancement, 강화요구)**로 상위 SL을 달성한다. RE는 누적된다.

CR 1.1(인간 사용자 식별·인증)을 예로 들면:

각 CR 문서는 네 부분으로 읽는다 — Requirement(최소 충족 기능), Rationale(왜 필요한지, 운영 맥락), RE(상위 SL 강화 조건), Security levels(SL별 CR/RE 조합). 이 패턴이 모든 CR에 일관되게 적용된다.

1.6 FR별 독립 평가 — SL은 벡터다

결정적으로, SL-C는 FR마다 독립적으로 평가된다. 한 컴포넌트가 FR1에서 SL3, FR4에서 SL2를 달성할 수 있다. 그래서 컴포넌트의 SL-C는 단일 숫자가 아니라 벡터다.

SL-C = [IAC:3, UC:2, SI:3, DC:2, RDF:2, TRE:2, RA:2]

"이 PLC는 SL2다"라는 말은 부정확하다. 정확히는 "7개 축에서 각각 이런 값을 가진다"이다. 이 벡터 개념이 인증서를 읽는 법의 출발점이 된다.

2부 — FR1~7 지도

이제 7개 기반 요구사항을 하나씩 본다. FR은 IACS 보안을 신원 / 권한 / 무결성 / 기밀성 / 망분리 / 탐지대응 / 가용성으로 분해한 것이다. 모든 CR은 항상 "결정된 SL-T에 근거하여, 컴포넌트는 …할 역량을 제공해야 한다"는 형태를 취한다 — SL-T가 선행 입력임이 문장 구조에 박혀 있다.

FR1 — 식별 및 인증 제어 (IAC)

한 줄 요약: 접근을 허용하기 전에 모든 사용자를 식별하고 인증한다.

여기서 "사용자"는 인간만이 아니다. 소프트웨어 프로세스, 디바이스 간 상호 인증(machine-to-machine)까지 포함한다. Clause 5에 CR 1.1~1.14가 정의된다.

주요 CR 몇 가지:

• CR 1.1 인간 사용자 식별·인증 — 모든 인간 접근 가능 인터페이스에서 강제. RE(1)은 고유 식별, RE(2)는 MFA.
• CR 1.2 소프트웨어/디바이스 식별·인증 — SL1에서는 불필요, SL2부터 요구된다.
• CR 1.5 인증자 관리 — 초기 인증자 지원, 기본 인증자 변경 인식. RE(1)은 하드웨어 보안 메커니즘으로 인증자 보호(SL3~4).
• CR 1.7 패스워드 강도 — 국제 지침 기반 설정 가능한 강도. RE로 재사용 방지·수명 제한.
• CR 1.10 인증자 피드백 — 패스워드 입력 시 asterisk 표시처럼 인증자 정보를 가린다. 인증 실패 사유를 구체적으로 노출하지 않는다.
• CR 1.11 로그인 실패 제한 — 설정 횟수 초과 시 접근 거부.

여기서 산업 보안 특유의 반전. **CR 1.11은 "비상 운영 시스템에서는 DoS 방지를 위해 자동 잠금을 제한적으로 적용해야 한다"**고 단서를 단다. IT라면 "실패하면 무조건 잠근다"가 정답이지만, 비상 상황에서 조작자가 계정 잠김으로 컨트롤러를 못 만지면 그것이 곧 사고다. 인증이 필수 기능을 방해해서는 안 된다 — 이 원칙(CCSC 1)이 FR1 전체를 관통한다.

FR2 — 사용 제어 (UC)

한 줄 요약: 인증 다음 단계 — 확인된 사용자에게 할당된 권한 범위 안에서만 동작을 허용한다.

FR1이 "당신이 누구인가"라면 FR2는 "당신이 무엇을 할 수 있는가"다. Clause 6, CR 2.1~2.13.

• CR 2.1 권한 부여 집행 — 역할 기반 권한. RE(1) 최소 권한, RE(3) 슈퍼바이저 수동 오버라이드(SL3), RE(4) 심각한 동작에 이중 승인(dual approval)(SL4).
• CR 2.8 감사 이벤트 — SL1~4 전부 필수. 여섯 카테고리(접근 제어, 요청 오류, 제어 시스템 이벤트, 백업·복구, 설정 변경, 감사 로그 이벤트)를 로깅한다. 각 레코드에는 타임스탬프·출처·카테고리·유형·이벤트 ID·결과가 들어간다.
• CR 2.11 타임스탬프 — RE(1)은 시스템 전체 시간 소스와 동기화(SL2~4). 여러 컴포넌트의 로그를 상관 분석하려면 시간이 맞아야 한다.
• CR 2.12 부인 방지 — 특정 사용자가 특정 행동을 했음을 증명.

또 하나의 산업 보안 반전. CR 2.10은 감사 처리가 실패해도(하드웨어 오류, 저장 초과 등) 필수 서비스가 중단되어서는 안 된다고 요구한다. IT에서는 "로그를 못 남기면 멈춘다(fail-secure)"가 흔하지만, 제어 시스템에서는 로그 때문에 제어가 멈추면 안 된다. 로그 손실과 제어 손실 중 후자가 더 위험하기 때문이다.

FR3 — 시스템 무결성 (SI)

한 줄 요약: 컴포넌트가 무단으로 조작·수정되지 않도록 보호한다 — 통신, 소프트웨어, 설정, 물리 하드웨어까지.

Clause 7, CR 3.1~3.14. 여기에 산업 보안의 가장 특징적인 요구들이 모여 있다.

• CR 3.1 통신 무결성 — 전송 정보의 무결성 보호. RE(1)은 수신 정보의 출처 인증. IACS 특유의 고려: 진동·EMI·이물질 같은 물리적 요인도 통신 무결성에 영향을 준다.
• CR 3.4 소프트웨어·정보 무결성 — 무결성 검사. RE(1) 암호화 해시 기반 진본성 검사, RE(2) 무단 변경 시 자동 알림.
• CR 3.5 입력 유효성 검사 — 외부 인터페이스 입력의 구문·길이·내용 검사. SQL 인젝션, XSS, 버퍼 오버플로우, 프로토콜 퍼징을 막는다. (이 요구가 왜 중요한지는 Achilles 인증 글에서 실제 퍼징 시험으로 확인할 수 있다.)
• CR 3.7 오류 처리 — 오류 메시지가 공격에 악용되지 않도록. "잘못된 사용자명"과 "잘못된 패스워드"를 구분해 표시하지 않는다.

가장 IACS다운 것은 **CR 3.6 결정론적 출력(deterministic output)**이다. 자동화 공정에 연결된 컴포넌트는 정상 운영을 유지할 수 없을 때 출력을 미리 정의된 안전 상태로 전환해야 한다. 상태 옵션은 비전원(Unpowered)·유지(Hold)·고정값(Fixed)·동적(Dynamic) 중 설정 가능하다. IT 소프트웨어는 "실패하면 예외를 던지고 죽으면 된다". 물리 액추에이터를 제어하는 컨트롤러는 죽어서는 안 되고, 알려진 안전 상태로 떨어져야 한다. 밸브를 열린 채로 둘 것인가, 닫을 것인가, 현 상태를 유지할 것인가 — 이것은 설계자가 미리 정해야 하는 물리적 안전 결정이다.

FR4 — 데이터 기밀성 (DC)

한 줄 요약: 전송 중·저장 중 정보의 무단 노출을 방지한다.

Clause 8, CR 4.1~4.3. FR 중 가장 작다(요구 3개). IACS에서 기밀성이 최우선이 아니라는 점이 여기 반영된다.

• CR 4.1 정보 기밀성 — 저장 중(at rest)과 전송 중(in transit) 모두. 설계 원칙: 컴포넌트가 어떤 정보에 읽기 권한 설정을 지원한다는 것 자체가 그 정보가 민감하다는 신호이므로, 그 기밀성 보호 능력도 함께 제공해야 한다.
• CR 4.2 정보 지속성 — 폐기·서비스 해제 시 인증 정보·네트워크 설정·암호화 키를 삭제. SL2부터 요구. RE(1) 휘발성 공유 메모리 잔류 방지, RE(2) 삭제 검증.
• CR 4.3 암호화 사용 — SL1~4 전부 필수. 국제적으로 인정된 알고리즘만 사용(AES, SHA 시리즈, 키 관리는 NIST SP 800-57, 구현은 FIPS 140-2 또는 ISO/IEC 19790). 자체 암호를 만들지 말라는 뜻이다.

FR5 — 제한된 데이터 흐름 (RDF)

한 줄 요약: 존과 도관으로 시스템을 세분화해 불필요한 데이터 흐름을 막는다.

Clause에 CR 5.15.4. 앞서 인증서 글에서 언급했듯, **FR5는 SL1SL4가 전부 동일**하다. 망 분할 요구는 SL이 올라도 늘지 않는다.

• CR 5.1 네트워크 세분화 — 모든 SL 동일. 논리적 세분화(저비용, 단일 장애점 위험)와 물리적 세분화(추가 보호, 고비용)를 상황에 맞게 쓴다. 사고 대응 시 네트워크를 분리해도 핵심 서비스(DHCP, DNS, CA)가 이중화로 유지되도록 설계해야 한다.
• CR 5.2 존 경계 보호 / CR 5.3 개인 간 통신 제한 — 네트워크 디바이스(NDR) 전용 요구.

FR5가 SL에 무관하게 일정한 이유는, 망 분할이 "얼마나 정교하게" 하느냐의 문제가 아니라 "하느냐 마느냐"의 문제이기 때문이다. 경계는 있거나 없거나다.

FR6 — 이벤트에 대한 적시 대응 (TRE)

한 줄 요약: 보안 침해 시 적시에 통보하고, 증거를 수집하고, 교정 조치를 취한다.

CR 6.1~6.2. 탐지와 대응의 축이다.

• CR 6.1 감사 로그 접근성 — SL12는 수동 접근(화면 조회, 출력). SL34는 RE(1)로 프로그래밍 방식 접근 — API 또는 SIEM으로 로그 전송. 수동 접근으로는 대규모 사고 조사가 안 되기 때문이다.
• CR 6.2 연속 모니터링 — SL2 이상부터 요구(SL1은 해당 없음). IDS/IPS, 악성코드 방지, 네트워크 모니터링으로 침해를 적시에 탐지한다.

여기도 IACS 단서가 붙는다. 모니터링 도구(IDS/IPS/SIEM)는 제어 시스템 성능에 부정적 영향을 주지 않도록 전략적으로 배치해야 한다. 보안 감시가 제어 주기를 방해하면 본말이 전도된다.

FR7 — 자원 가용성 (RA)

한 줄 요약: DoS·장애 상황에서도 필수 기능을 유지한다.

CR 7.1~7.8. 여기가 IACS 보안의 정점이자, IT 보안과 가장 크게 갈리는 지점이다.

• CR 7.1 서비스 거부 보호 — 핵심. 아래에서 따로 본다.
• CR 7.2 리소스 관리 — 보안 기능(스캔·패치·안티바이러스)이 제어 프로세스를 방해하지 않도록 트래픽 속도 제한.
• CR 7.3 백업 — RE(1)로 복원 전 백업 무결성 검증(SL2~4). 백업 프로세스가 정상 운영을 방해하면 안 된다.
• CR 7.4 복구·재구성 — 장애 후 알려진 보안 상태로 복구(보안 파라미터 복원, 패치 재설치, 안전 백업 로드).
• CR 7.6 네트워크·보안 구성 — SL3~4는 RE(1)로 기계 가독 형식의 현재 설정 보고서 생성.
• CR 7.7 최소 기능 — 불필요한 기능·포트·프로토콜·서비스를 제한. 기본값으로 비활성화.
• CR 7.8 컴포넌트 인벤토리 — SL2 이상 요구.

CR 7.1이 산업 보안의 철학을 가장 선명하게 드러낸다. 그 요구는 "DoS를 막아라"가 아니다. **"DoS 이벤트 결과로 저하 모드(degraded mode)에 들어가도 필수 기능을 유지하라"**이다.

SL 1 : 필수 기능을 저하 모드에서 유지
SL 2~4 : + RE(1) 메시지 플러딩 완화 (통신 부하 관리)

차이를 음미할 만하다. IT 보안은 "공격을 차단하고 정상 상태를 지킨다"를 목표로 한다. IACS 보안은 공격을 완전히 막지 못하더라도 제어를 놓지 않는 것을 목표로 한다. 발전소가 DoS 공격을 받았을 때 중요한 것은 "공격을 막았느냐"가 아니라 "터빈 제어가 살아 있느냐"다. 저하 모드로 떨어지더라도 필수 기능 — 안전 유지에 필요한 최소 기능 — 은 계속 돌아야 한다. "막아라"가 아니라 "저하되더라도 유지하라" 가 산업 보안의 문법이다.

이 발상은 표준의 용어 정의에 새겨져 있다. degraded mode는 "결함이 발생해도 필수 기능을 유지하는 운영 모드"로, essential function은 "HSE(보건·안전·환경) 및 가용성 유지에 필요한 기능(손실 시 보호 상실·제어 상실·가시성 상실)"으로 정의된다.

3부 — 컴포넌트 타입 지도

FR1~7의 CR은 대부분 4가지 컴포넌트 타입에 공통 적용된다. 하지만 각 타입에는 고유 제약이 있어 전용 요구사항이 추가된다.

각 타입의 성격:

• SAR (소프트웨어 애플리케이션) — 호스트·임베디드 디바이스 위에서 실행되며 의존성(DB, 서드파티 라이브러리)을 가진다. 전용 요구: 모바일 코드 제어(CR 2.4), 악성코드 방호(CR 3.2).
• EDR (임베디드 디바이스) — 산업 공정을 직접 감시·제어하는 특수 목적 디바이스. 제한된 저장공간, 임베디드 OS/펌웨어, 실시간 스케줄러가 특징이다. 제한된 자원 때문에 일부 CR은 보상 대응 수단으로 충족하고, 비상 운영 시 인증이 조작을 방해하지 않아야 한다. 전용 요구: 물리적 변조 저항·탐지(CR 3.11), 부팅 무결성(CR 3.14), 신뢰 루트 프로비저닝(CR 3.12~3.13).
• HDR (호스트 디바이스) — Windows·Linux 기반 범용 디바이스. 파일시스템과 완전한 HMI를 갖지만 실시간 스케줄러는 없다. 전용 요구: 악성코드 방호(CR 3.2), 하드웨어 기반 보안 기능.
• NDR (네트워크 디바이스) — 데이터 흐름을 촉진·제한하되 공정에 직접 관여하지 않는다. HMI 없음, 실시간 스케줄러 없음. 전용 요구: 무선 접근 관리(CR 1.6), 네트워크 세분화 지원(FR5의 CR 5.2/5.3).

한 컴포넌트가 여러 타입을 겸할 수 있다. 예를 들어 HMI를 내장한 PLC는 EDR + SAR 요구를 모두 충족해야 한다. 이것이 인증서 글에서 "RA ≠ 0인 타입이 실제 컴포넌트 타입"이라고 한 이유다 — 인증서의 SAR/EDR/HDR/NDR 점수 중 0이 아닌 것이 그 제품의 실제 정체성이다.

EDR의 "제한된 자원 → 보상 대응 수단 활용"이라는 특성은 실무에서 특히 중요하다. PLC는 IT 서버처럼 넉넉한 메모리와 범용 OS를 갖지 못한다. 그래서 모든 CR을 자체적으로 충족하기 어렵고, 일부는 "이 요구는 상위 방화벽이 담당한다" 식으로 시스템 통합으로 메운다. 이 "보상 수단으로 메운 부분"을 CR별로 명시하는 것이 평가의 핵심이 된다.

정리 — 지도를 손에 쥐고

IEC 62443-4-2를 처음 마주할 때 잡아야 할 골격을 다시 모은다.

• 표준은 독자로 나뉜다 — 4-2는 제품 공급자(컴포넌트를 만드는 사람)의 표준이다. 난이도가 아니라 역할이 분할축이다.
• SL에는 네 얼굴이 있다 — 4-2가 다루는 것은 SL-C(역량)뿐이다. SL-T(목표)가 먼저 정해지고, SL 0조차 유형에 따라 뜻이 반대다.
• 보안은 7개 축(FR)의 벡터다 — 신원(FR1)·권한(FR2)·무결성(FR3)·기밀성(FR4)·망분리(FR5)·탐지대응(FR6)·가용성(FR7). 각 축은 독립 평가되고, SL 상승의 기울기가 다르다.
• 문법은 "막아라"가 아니라 "유지하라" — CR 3.6 결정론적 출력, CR 7.1 저하 모드 유지, "인증이 비상 운영을 방해하면 안 된다" — 전부 제어 연속성을 기밀성·차단보다 앞세우는 IACS 특유의 우선순위에서 나온다.
• 컴포넌트 타입은 정체성이다 — SAR/EDR/HDR/NDR. 공통 CR 위에 타입 전용 요구가 얹히고, 한 제품이 여러 타입을 겸할 수 있다.

이 지도를 손에 쥐면 나머지가 제자리를 찾는다. 이 요구들이 실제 인증서에서 어떤 숫자로 표현되는지는 'IEC 62443-4-2 인증 취득'이 아무 뜻도 없는 이유에서, 이 표준이 EU CRA를 통해 어떻게 법적 강제력을 얻는지는 CRA가 2027년에 바꾸는 것에서, 그리고 이 요구들이 실제 패킷 단위 퍼징 시험으로 어떻게 검증되는지는 Achilles 인증 해부에서 이어 볼 수 있다.