티스토리 뷰

정보보안/Infra

IEC 62443이란? OT 보안 국제표준 구조·보안 수준(SL)·7대 요구사항 쉽게 정리

실더 2026. 10. 1. 09:00

📌 3줄 요약
1. IEC 62443은 공장·전력·교통·선박 등 OT(운영기술) 환경의 보안 국제표준 시리즈입니다.
2. 4개 그룹으로 "누가 무엇을 지키는지"를 나누고, 7대 기본 요구사항(FR)과 보안 수준(SL)으로 "얼마나 지킬지"를 정합니다.
3. 2024년부터 신조선에 적용되는 선박 사이버 보안 규격 IACS UR E27도 이 표준을 기반으로 만들어졌습니다.

신규 장비 도입 보안성 검토를 하다 보면 공급사 제안서에서 이런 문장을 자주 봅니다.

"본 제품은 IEC 62443-4-2 인증을 획득했습니다."

 

그런데 이 한 줄만 보고 "그럼 보안은 됐네"라고 판단하면 안 됩니다. 4-2는 부품(장비) 하나에 대한 요구사항이고, 그 장비가 들어가는 시스템 설계와 운영 조직의 관리는 다른 파트가 다룹니다. 인증 등급이 우리 환경에 필요한 수준과 맞는지도 따로 봐야 합니다.

이 글은 선박 사이버 보안 시리즈의 1편입니다. 선박 규격을 이해하려면 그 뿌리인 IEC 62443을 먼저 알아야 하기 때문에, 이번 편에서는 IEC 62443의 구조, 역할, 7대 요구사항, 보안 수준, 구역과 경로, 위험평가 흐름, 보안 개발 생명주기를 정리했습니다. 각 섹션에는 IT 보안·DevSecOps 담당자가 참고할 포인트를 함께 넣었습니다.

시리즈 주제
1편 (이번 글) IEC 62443 — OT 보안 국제표준의 구조와 핵심 개념
2편 선박 사이버 보안 규제 지도 — IMO · IACS · IEC · 미국 · EU
3편 IACS UR E26 · E27 — 원문 기준 요구사항과 인증 절차
4편 선박 사이버 보안 실무 체크리스트 — E27 41개 대응표, IT 보안·DevSecOps 적용
목차 내용
1 IEC 62443이란?
2 IT 보안과 OT 보안의 차이
3 4개 그룹 구조
4 역할별 관계
5 7대 기본 요구사항 (FR)
6 보안 수준 (SL)
7 구역과 경로
8 위험평가와 설계 흐름
9 보안 개발 생명주기와 DevSecOps
10 인증 제도
11 최신 동향: EU CRA

🎯 1. IEC 62443이란?

구분 내용
한 줄 정의 산업자동화제어시스템(Industrial Automation and Control Systems)을 안전하게 만들기 위한 OT 보안 국제표준 시리즈
만든 곳 국제전기기술위원회(IEC)와 국제자동화협회(ISA)가 함께 개발
발행 형태 국제적으로는 IEC 62443, 미국에서는 ANSI/ISA 62443으로 발행
적용 분야 전력, 수도, 의료, 교통 등 산업·기반시설 OT 전반 (선박·철도 등은 이를 바탕으로 분야별 규격을 만듦)
구성 정책, 시스템 요구사항, 부품 요구사항, 적합성 평가로 이어지는 계층 구조
⚠️ 약어 주의: IACS가 두 가지 뜻으로 쓰입니다.
IEC 62443의 IACS = Industrial Automation and Control Systems (산업자동화제어시스템)
선박 규격의 IACS = International Association of Classification Societies (국제선급연합회)
혼동을 막기 위해 이 시리즈에서는 IACS를 국제선급연합회의 뜻으로만 쓰고, IEC 62443의 대상은 산업제어시스템으로 적습니다.

🧩 2. IT 보안과 OT 보안, 무엇이 다를까?

IEC 62443을 이해하려면 먼저 OT 환경이 IT와 어떻게 다른지 알아야 합니다.

구분 IT (업무 시스템) OT (산업·제어 시스템)
최우선 가치 기밀성 (정보 유출 방지) 가용성과 안전 (멈추거나 오작동하면 사고)
장애의 결과 데이터 유출, 업무 중단 설비 파손, 인명 사고, 환경 오염
패치 정기 패치가 기본 운전 중단이 어려워 검증 후 계획된 시점에 적용
백신·차단 솔루션 대부분 설치 실시간 제어 성능에 영향을 주면 설치가 제한됨
장비 수명 3~5년 교체 10~20년 이상 운영
대표 표준 ISO/IEC 27001 IEC 62443
🛠 IT 보안 · DevSecOps 포인트
IT 보안 정책을 OT에 그대로 옮기면 오히려 사고가 날 수 있습니다. 예를 들어 IPS의 자동 차단 기능이 정상 제어 신호를 막으면 설비가 멈춥니다. OT에서는 "보안 조치가 가용성을 해치지 않는가"를 항상 먼저 검토해야 합니다.

🏗 3. IEC 62443 시리즈 구조 (4개 그룹)

그룹 주요 파트 내용 주 대상
1. 일반 1-1 개념과 모델 (2009) · 1-5 보안 프로파일 체계 (2023) 시리즈 전체에 쓰이는 용어, 개념, 모델 전체
2. 정책·절차 2-1 보안 프로그램 요구사항 (2024) · 2-3 패치 관리 (2015) · 2-4 서비스 제공자 요구사항 (2023) 운영 조직의 보안 관리 체계, 패치 관리, 유지보수 업체 요건 자산 소유자, 서비스 제공자
3. 시스템 3-2 위험평가와 시스템 설계 (2020) · 3-3 시스템 보안 요구사항과 보안 수준 (2013) 구역·경로 설계, 시스템 단위 보안 기능 시스템 통합사
4. 부품 4-1 보안 개발 생명주기 (2018) · 4-2 부품 기술 보안 요구사항 (2019) 제품 개발 프로세스, 장비 단위 보안 기능 제품 공급사

괄호 안은 현재 기준 판(edition)의 발행 연도입니다. IEC 표준은 주기적으로 검토되어 유지, 개정, 폐지가 결정되므로, 인증이나 계약에 인용할 때는 어느 판을 기준으로 하는지 반드시 함께 적어야 합니다.

🛠 IT 보안 · DevSecOps 포인트
IT 보안 표준과 비교하면 이해가 쉽습니다. 2-1은 ISMS처럼 운영 조직의 관리체계, 3-3은 시스템 설계 보안 요구사항, 4-1은 시큐어 SDLC(DevSecOps), 4-2는 제품 보안 기능 인증에 해당합니다. 담당 업무에 따라 먼저 읽어야 할 파트가 다릅니다.

👥 4. 역할별 관계 — 누가 무엇을 지키나?

역할 하는 일 따르는 파트 IT 보안에 비유하면
제품 공급사 보안 기능을 갖춘 장비·소프트웨어 개발 4-1, 4-2 솔루션 벤더
시스템 통합사 장비를 조합해 시스템 설계·구축, 구역 설계 3-2, 3-3, 2-4 SI 구축사
서비스 제공자 통합·유지보수 서비스 제공 2-4 유지보수 업체
자산 소유자 실제 운영, 보안 프로그램 관리, 패치 2-1, 2-3 우리 회사 (운영·보안팀)
🛠 IT 보안 · DevSecOps 포인트
신규 장비 도입 보안성 검토는 자산 소유자 입장에서 공급사가 4-1(개발 프로세스), 4-2(제품 기능) 요구사항을 지켰다는 증적을 확인하는 일입니다. 인증서 사본만 받지 말고 인증 범위, 기준 판, 보안 수준(SL-C)까지 확인하세요.

🔑 5. 7대 기본 요구사항 (FR)

 

IEC 62443의 기술 요구사항은 모두 아래 7개 기본 요구사항(Foundational Requirements) 아래에 분류됩니다. 3-3이 시스템 요구사항(SR)을 정의하고, 4-2는 이를 부품 요구사항(CR)으로 확장합니다.

FR 이름 목적 IT 보안 통제로 치면
FR1 식별·인증 통제 사람·소프트웨어·장비를 모두 식별하고 인증 계정 관리, MFA, 기본 비밀번호 변경
FR2 사용 통제 인증된 주체가 허용된 일만 하도록 제한 권한 관리, 최소 권한, 세션 잠금
FR3 시스템 무결성 무단 변경과 악성코드로부터 보호 무결성 검증, 악성코드 방지, 입력값 검증
FR4 데이터 기밀성 저장·전송 정보의 노출 방지 암호화, 안전한 암호 알고리즘
FR5 데이터 흐름 제한 구역과 경로로 통신을 분리·통제 망분리, 방화벽 정책
FR6 적시 대응 보안 이벤트를 기록하고 대응 감사 로그, 모니터링
FR7 자원 가용성 공격 중에도 필수 기능 유지 DoS 대응, 백업·복구, 최소 기능 원칙
🛠 IT 보안 · DevSecOps 포인트
7개 FR은 웹·앱 취약점 점검 항목과도 거의 그대로 대응합니다. 예를 들어 FR1·FR2는 인증·권한 우회 점검, FR3는 입력값 검증(인젝션) 점검, FR4는 평문 전송·취약한 암호화 점검에 해당합니다. SAST 룰셋을 FR 기준으로 분류해 두면 OT 제품 점검에도 재사용할 수 있습니다.
💡 3편 미리보기: 선박 규격 IACS UR E27의 보안 기능 41개를 FR별로 나누면 FR5(데이터 흐름 제한)만 하나도 없습니다. 망분리는 장비 규격(E27)이 아니라 선박 전체 규격(E26)이 맡기 때문입니다. 자세한 내용은 3편에서 다룹니다.

📶 6. 보안 수준 (Security Level, SL)

수준 보호 대상 위협 예시 (이해를 돕기 위한 비유)
SL 0 특별한 보호 요구 없음 —
SL 1 우발적이거나 우연한 침해 실수로 잘못된 설정을 바꾼 직원
SL 2 단순한 수단을 쓰는 의도적 침해 공개된 도구를 쓰는 일반 공격자
SL 3 정교한 수단 + 중간 수준의 자원 산업제어 지식을 갖춘 공격 조직
SL 4 정교한 수단 + 대규모 자원을 가진 숙련된 공격자 국가 지원 수준의 공격 그룹

 

SL은 3가지 종류가 있습니다

종류 의미 누가 정하나
SL-T (Target) 위험평가로 정한 필요한 보안 수준 자산 소유자 + 통합사
SL-C (Capability) 시스템(3-3)이나 부품(4-2)이 추가 대책 없이 낼 수 있는 수준 공급사 (인증으로 입증)
SL-A (Achieved) 실제 구축·운영 환경에서 측정된 수준 검증·운영 단계에서 확인
💡 핵심은 "SL-A ≥ SL-T"입니다. SL-C가 높은 장비를 샀더라도 설정을 잘못하면 SL-A는 낮아집니다. 반대로 SL-C가 부족한 부분은 방화벽 같은 보완 대책(compensating countermeasure)으로 메울 수 있습니다.
🛠 IT 보안 · DevSecOps 포인트
SL은 위협 모델링에서 말하는 "공격자 프로파일"과 같은 개념입니다. 모든 구역을 SL 4로 설계하면 비용과 운영 부담이 커지고 가용성까지 해칠 수 있습니다. 위험평가로 구역마다 필요한 만큼만 정하는 것이 원칙입니다.

🧱 7. 구역(Zone)과 경로(Conduit)

개념 정의 IT 보안에 비유하면
구역 (Zone) 보안 요구사항이 같은 시스템과 부품을 기능적·논리적·물리적 관계에 따라 묶은 단위 망분리된 네트워크 영역 (업무망, 서버팜, DMZ 등)
경로 (Conduit) 두 개 이상의 구역을 연결하는 통신 채널의 묶음 방화벽, 단방향 게이트웨이 등 구간 통제
구역별 SL-T 구역마다 위험에 따라 목표 보안 수준을 따로 부여 망 등급별 보안 정책
🛠 IT 보안 · DevSecOps 포인트
구역·경로는 IT의 망분리·방화벽 정책과 같은 개념이지만 원칙이 더 엄격합니다. 방화벽 정책 점검 시 "Any 허용 규칙", "사용하지 않는 허용 규칙", "제어 구역에서 기업망으로 바로 나가는 통신"은 OT 환경에서 우선 제거 대상입니다.

🔄 8. 위험평가와 설계 흐름 (3-2)

 

IEC 62443-3-2는 위험평가 방법 자체를 정해 두지 않고, 조직의 기존 위험관리 방식과 맞추도록 권고합니다. 대신 초기 위험평가로 우선순위를 정하고 구역·경로를 나눈 뒤, 상세 위험평가로 목표 보안 수준과 대책을 정하는 순서를 제시합니다.

단계 하는 일 산출물
1. 대상 정의 평가할 시스템(SuC, System under Consideration)의 범위 확정 시스템 범위, 자산 목록
2. 초기 위험평가 최악의 상황을 가정해 우선순위 파악 위험 우선순위
3. 구역·경로 분할 보안 요구사항이 같은 자산끼리 묶고 통신 경로 정의 구역·경로 다이어그램
4. 상세 위험평가 구역별 위협, 취약점, 영향 분석 구역별 위험 분석서
5. SL-T 결정 구역·경로별 목표 보안 수준 설정 SL-T 정의서
6. 대책 선정 3-3(시스템), 4-2(부품) 요구사항과 보완 대책 선택 보안 요구사항 명세
7. 검증·운영 SL-A가 SL-T를 충족하는지 확인하고 변경 시 재평가 시험 결과, 운영 기록
🛠 IT 보안 · DevSecOps 포인트
2~5단계는 DevSecOps의 위협 모델링, 6~7단계는 보안 요구사항 구현과 검증에 해당합니다. 설계 문서에 "어느 구역, 어떤 SL-T"가 명시되어 있으면 이후 취약점 점검과 인수 시험의 합격 기준이 분명해집니다.

🛠 9. 보안 개발 생명주기 (4-1)와 DevSecOps

 

IEC 62443-4-1은 제품 공급사의 개발 프로세스에 대한 요구사항입니다. 8개 실천 영역(practice)과 47개 요구사항으로 구성됩니다.

실천 영역 내용 요구사항 수 DevSecOps 대응 (참고)
SM 보안 관리 개발 프로세스 전반의 관리, 역할, 교육, 코드 서명키 보호 등 13 보안 거버넌스, 서명키 관리(HSM·KMS)
SR 보안 요구사항 목표 보안 수준과 위협 모델을 바탕으로 요구사항 정의 5 위협 모델링, 보안 요구사항 정의
SD 보안 설계 보안 설계 원칙 적용 4 보안 아키텍처 리뷰
SI 보안 구현 시큐어 코딩 표준 적용 2 시큐어 코딩, SAST
SVV 보안 검증 보안 요구사항 시험, 위협 완화 시험, 취약점 시험 등 5 DAST, 퍼징, 모의해킹
DM 보안 이슈 관리 발견된 취약점의 접수, 분석, 처리 6 PSIRT, 취약점 트래킹
SUM 보안 업데이트 관리 패치 검증, 배포, 문서화 5 서명된 패치 배포, 릴리스 노트
SG 보안 가이드 하드닝, 설치, 운영 가이드 제공 7 하드닝 가이드, 보안 설정 문서
합계   47  

 

성숙도 수준 (Maturity Level)

수준 의미
ML1 초기 단계. 절차가 정형화되지 않고 그때그때 수행
ML2 절차가 문서화되고 반복 가능 (처음 인증을 받는 기업의 일반적인 목표)
ML3 조직 전체에 정의되어 일관되게 적용
ML4 측정과 지속적 개선까지 이루어짐

 

실제 기업 설문에서는 8개 영역 중 보안 관리(SM), 보안 설계(SD), 보안 업데이트 관리(SUM)를 가장 어려운 영역으로 꼽았습니다. 코드 서명키 보호 같은 기술 통제보다 조직·절차 측면이 더 어렵다는 뜻입니다.

🛠 IT 보안 · DevSecOps 포인트
이미 DevSecOps 파이프라인(SAST, SCA, DAST)을 운영하고 있다면 도구는 대부분 갖춘 상태입니다. 부족한 것은 보통 증적입니다. 각 단계의 결과(스캔 리포트, 조치 이력, 예외 승인)를 4-1 요구사항 번호에 맞춰 남기는 것부터 시작하면 됩니다. 특히 SM-8(코드 서명용 개인키 보호)은 선박 규격 E27에도 그대로 인용되는 항목입니다.

🏅 10. 인증 제도

구분 내용
4-1 프로세스 인증 ISASecure SDLA(보안 개발 생명주기 보증) 인증이 대표적이며, 달성한 성숙도 수준으로 인증
IECEE 체계 IECEE 인증 시험소(CBTL)에서도 IEC 62443 프로세스·제품 평가를 제공
인증기관 exida, TÜV SÜD, TÜV Rheinland, UL Solutions 등 여러 국제 인증기관이 평가 서비스 제공
🛠 IT 보안 · DevSecOps 포인트
인증서를 확인할 때는 ① 대상 파트(4-1인지 4-2인지) ② 기준 판(연도) ③ 성숙도(ML) 또는 보안 수준(SL-C) ④ 평가에서 제외된 항목 4가지를 꼭 보세요. 47개 요구사항 중 일부를 범위에서 제외하고 인증을 받은 사례도 있습니다.

🌐 11. 최신 동향: EU 사이버 복원력법(CRA)

항목 내용
CRA 일정 2024년 12월 10일 발효, 2027년 12월 11일 전면 적용. 취약점·사고 보고 의무는 2026년 9월부터
표준화 EU 집행위원회가 2025년 2월 표준화 요청(M/606)을 채택하고, CEN·CENELEC·ETSI가 2025년 4월 수락
IEC 62443과의 관계 OT 제품용 EN 50770 시리즈가 IEC 62443-3-3, 4-1, 4-2를 기반으로 개발 중이며 아직 초안 단계
현재 의미 EU에 제품을 파는 OT 제조사에게 IEC 62443은 CRA 대응의 핵심 실무 기준
⚠️ IEC 62443이 CRA의 "조화 표준(harmonised standard)"으로 확정되었는지는 자료마다 설명이 다릅니다. 이 글 작성 시점(2026년 9월) 기준으로 조화 표준화 작업이 진행 중인 상태로 이해하는 것이 정확합니다.

🚫 이런 판단은 하지 마세요

① "4-2 인증 장비니까 우리 시스템도 안전하다"

4-2는 장비가 낼 수 있는 수준(SL-C)입니다. 우리 시스템의 실제 수준(SL-A)은 구역 설계, 설정, 운영에 따라 달라집니다.

② "IT 보안 정책을 OT에도 똑같이 적용하면 된다"

일괄 백신 설치, IPS 자동 차단, 즉시 패치는 OT에서 가용성을 해칠 수 있습니다. 가용성 영향 검토가 먼저입니다.

③ "보안 수준은 높을수록 좋다"

SL은 위험평가로 구역마다 필요한 만큼 정하는 것입니다. 과도한 SL-T는 비용과 운영 부담만 키웁니다.

④ "IEC 62443은 공장 이야기라 우리와 상관없다"

선박(IACS UR E27), 철도 등 여러 분야의 사이버 보안 규격이 IEC 62443을 기반으로 만들어지고 있습니다. OT 장비를 도입하는 조직이라면 모두 해당됩니다.

💬 자주 나오는 질문

Q. ISO/IEC 27001과 IEC 62443은 무엇이 다른가요?

ISO/IEC 27001은 조직의 정보보호 관리체계 표준이고, IEC 62443은 산업제어시스템에 특화되어 운영 조직, 시스템 설계, 제품 개발까지 역할별로 요구사항을 나눈 표준입니다. 둘은 경쟁 관계가 아니라 함께 쓰는 관계입니다.

Q. 3-3과 4-2는 어떻게 다른가요?

3-3은 시스템 전체가 갖춰야 할 보안 요구사항(SR)이고, 4-2는 이를 개별 부품 단위의 요구사항(CR)으로 확장한 것입니다. 둘 다 7대 FR 아래에 분류됩니다.

Q. 어떤 파트부터 공부하면 좋을까요?

역할에 따라 다릅니다. 운영·보안팀은 1-1 → 2-1 → 3-2, 개발 조직은 4-1 → 4-2, 구축 담당은 3-2 → 3-3 순서를 추천합니다.

Q. 선박 규격과는 어떻게 연결되나요?

IACS UR E27은 IEC 62443-3-3의 요구사항 일부와 4-1의 개발 생명주기 요구사항을 골라 선박용으로 구성한 규격입니다. 3편에서 자세히 다룹니다.

🎉 정리

  1. IEC 62443은 OT 환경의 보안 국제표준 시리즈다. IT와 달리 가용성과 안전이 최우선이다.
  2. 4개 그룹(일반·정책·시스템·부품)으로 공급사, 통합사, 자산 소유자의 역할을 나눈다.
  3. 7대 기본 요구사항(FR)이 모든 기술 요구사항의 뼈대다.
  4. 보안 수준(SL)은 SL-T(목표), SL-C(능력), SL-A(달성)로 나뉘며, 목표는 SL-A ≥ SL-T다.
  5. 구역과 경로는 망분리·방화벽 정책의 OT 버전이다.
  6. 4-1은 DevSecOps와 대응되며, 8개 영역 47개 요구사항에 대한 증적이 핵심이다.
  7. 인증서는 파트, 판, 수준, 제외 항목까지 확인해야 한다.

다음 2편에서는 선박 사이버 보안에 관련된 규격 전체를 한 장의 지도로 정리합니다. IMO 지침, IACS 선급 규칙, IEC 기술 표준, 미국·EU 법규가 각각 어떤 성격이고 서로 어떻게 연결되는지 먼저 보고 나면, 3편의 IACS UR E26·E27 세부 내용이 훨씬 쉽게 이해됩니다. 이번 편의 FR, SL, 구역·경로 개념은 3편과 4편에서 그대로 다시 등장합니다.

🔗 참고 자료

저작자표시 비영리 변경금지 (새창열림)

'정보보안 > Infra' 카테고리의 다른 글

Rocky Linux 8 SSH CBC 취약점, 설정 파일엔 없는데 Nessus는 왜 탐지할까? (crypto-policies·opt-out 정리)  (0) 2026.10.07
선박 사이버 보안 규제 총정리 — IMO·IACS·IEC·미국·EU 한눈에 보기  (0) 2026.10.05
보안장비는 실시간 원격 로그, 서버는 왜 요구하지 않을까?  (0) 2026.09.21
RHEL 7.8에 ELS가 적용될까?  (1) 2026.09.18
OpenSearch 데모 인증서(Example Com Inc. Root CA), 내부망이면 괜찮을까?  (0) 2026.09.17