차량 보안 테스트는 왜 이렇게 끝이 없을까?— ISO 21434 Clause 11이 말하는 “검증”의 진짜 의미

현업에서 보는 차량 보안 기술

자동차 사이버보안을 처음 접하면 이런 생각을 하기 쉽습니다.

"보안 기능 구현했는데, 테스트만 하면 끝 아닌가?"

그런데 실제 현장은 전혀 다릅니다.

Secure Boot 넣었는데 부팅 경로 검증은 했는가?
SecOC 적용했는데 Replay Attack은 막히는가?
Security Access 구현했는데 Brute Force는 가능한가?
차량 전체 네트워크에서 우회 경로는 없는가?

그리고 테스트를 시작하면 또 다른 질문이 생깁니다.
"어디까지 테스트해야 충분한 걸까?"

보안은 "기능이 동작하는지"를 검증하는 게 아니라,
"깨지지 않는지"를 증명해야 하기 때문입니다.

Verification과 Validation — 왜 구분해야 하는가

많은 사람들이 Verification과 Validation을 같은 개념으로 씁니다. 하지만 ISO/SAE 21434에서 이 둘은 명확히 다릅니다. Clause 11은 Cybersecurity Validation을 다루는데, 이것이 단순 기능 테스트와 어떻게 다른지 이해하는 것이 출발점입니다.

Verification

구현 검증

"요구사항대로 만들었는가?"

SecOC MAC 생성 코드가 요구사항대로 동작하는가

Secure Boot 서명 검증 로직이 명세대로 구현됐는가

Security Access Seed-Key 알고리즘이 정의대로인가

Requirement → 구현 → 테스트 Traceability 확인

Validation

보안 효과 검증

"실제 공격을 막을 수 있는가?"

실제 CAN Injection 공격이 SecOC로 차단되는가

변조된 펌웨어를 Secure Boot가 실제로 막는가

공격자 관점에서 우회 경로가 없는가

공격 시나리오 전체 체인이 성립하지 않음을 확인

Verification에서 통과했다고 Validation이 통과되는 건 아닙니다. "요구사항대로 구현됐지만 실제 공격에는 뚫리는" 상황이 현장에서 실제로 발생합니다. 요구사항 자체가 공격 시나리오를 충분히 커버하지 못한 경우가 많기 때문입니다.

왜 차량 보안 테스트는 어려운가

자동차 보안 테스트가 일반 소프트웨어 테스트와 다른 이유는 대상 자체가 다르기 때문입니다.

차량 — 연결된 시스템 전체가 테스트 대상

Mobile App

→

Cloud Backend

→

TCU

→

Gateway

→

Safety ECU

OBD Port

→

Diagnostic Access

→

Gateway 우회

→

CAN 전체 접근

웹 서비스는 서버 하나를 테스트하면 되는 경우가 많습니다. 하지만 차량은 Gateway, TCU, ADAS ECU, Powertrain ECU, CAN/Ethernet, OTA 서버, Mobile App, Cloud까지 모두 연결됩니다. 가장 위험한 문제는 개별 ECU 취약점이 아니라 "어디를 통해 어디까지 침투 가능한가"의 Attack Chain입니다.

개별 ECU가 아무리 강해도, 연결된 경로 중 하나가 약하면 차량 전체가 위험합니다. TCU → Gateway → CAN → Brake ECU 체인이 성립하면 개별 ECU 보안은 의미를 잃습니다.

차량 보안 테스트는 무엇을 하는가 — 4가지 활동

많은 사람들이 차량 보안 테스트 = Pentest라고 생각합니다. 하지만 21434 Clause 11에서 요구하는 검증 활동은 훨씬 넓습니다.

1

Requirement-based Security Test — 요구사항이 실제로 구현됐는가

Security Requirement가 ECU에서 실제로 동작하는지 확인합니다. TARA에서 도출된 보안 목표가 구현으로 이어졌는지 Traceability를 따라 검증하는 단계입니다.

2

Vulnerability Analysis — 구현 실수와 알려진 취약점 탐색

Hard-coded Key, Debug Port 열림, Default Password, Buffer Overflow, 인증 우회 가능성 등을 분석합니다. Legacy Code, 외부 공급사 코드, 오픈소스, AUTOSAR Stack이 섞인 차량에서는 예상보다 취약점이 많이 발견됩니다.

3

Fuzzing — 비정상 입력으로 예외 상황 탐색

정상 패킷 대신 비정상 입력을 계속 넣어서 ECU가 예상치 못한 상황에서 어떻게 동작하는지 확인합니다. 잘못된 UDS Length, 비정상 CAN Frame, Oversized SOME/IP Message 등이 대상입니다.

4

Penetration Test — 실제 공격 시나리오가 성립하는가

공격자 관점에서 차량 전체를 공격합니다. 개별 ECU 취약점 발견이 아니라 "실제 공격 체인이 성립하는가"를 확인하는 것이 핵심입니다.

테스트 유형	핵심 질문	주요 대상
Requirement-based Test	요구사항대로 구현됐는가?	Secure Boot, SecOC, Security Access, Anti-Rollback
Vulnerability Analysis	알려진 취약점·구현 실수가 있는가?	Debug Port, Hard-coded Key, CVE, OSS 취약점
Fuzzing	비정상 입력에서 ECU가 안전하게 동작하는가?	UDS, CAN, DoIP, SOME/IP, BLE
Penetration Test	실제 공격 시나리오가 성립하는가?	Attack Chain 전체, Gateway 우회, 원격 침투

실제 차량 Pentest — 어떤 시나리오를 수행하는가

🔧 Diagnostic 공격

UDS Session 전환·권한 우회

Security Access Seed-Key Brute Force

권한 없는 Flashing 시도

Hidden UDS Service 탐색

Diagnostic Fuzzing

📡 CAN / 네트워크 공격

위조 CAN 메시지 주입

SecOC Freshness 우회 시도

Replay Attack

Gateway 필터링 우회

CAN ID 충돌(Arbitration Abuse)

📦 OTA 공격

OTA 패키지 위변조

서명 검증 우회 시도

Rollback 공격

Download Channel 중간자 공격

불완전 업데이트 상태 악용

🔩 Firmware / HW 분석

JTAG/SWD Debug 접근 시도

Firmware Dump·역공학

Hard-coded Key·Secret 탐색

암호화 구현 취약점 분석

Side Channel 가능성 평가

📶 무선 인터페이스 공격

BLE/Wi-Fi 인증 우회

Key Fob Relay Attack

TCU 원격 침투

중간자(MITM) 공격

인증서 검증 우회

🌐 DoIP / Ethernet 공격

DoIP 인증 우회

비인가 Flash 시도

서비스 거부(DoS) 공격

비인가 ECU 접근

네트워크 Fuzzing

Pentest의 핵심은 "취약점 개수 찾기"가 아닙니다. 실제 공격 시나리오가 성립하는지 확인하는 것입니다. 개별 ECU 취약점 하나보다, TCU → Gateway → CAN → Safety ECU로 이어지는 Attack Chain이 완성되는지가 훨씬 더 중요합니다.

Clause 11의 Work Product — 테스트팀이 만들어야 하는 것들

WP Clause 11 — 주요 Work Product

Cybersecurity Validation Specification 필수

무엇을 어떻게 검증할지 사전 정의하는 문서. 공격 시나리오, 테스트 환경, 테스트 범위, Pass/Fail 기준, 사용 도구가 포함됩니다. 이 문서 없이 테스트를 시작하면 "어디까지 했는가"를 증명할 수 없습니다.

Cybersecurity Validation Report 필수

실제 테스트 수행 결과. 발견된 취약점, Risk 평가, 재현 조건, 영향 분석, 수정 여부, Residual Risk가 포함됩니다. 취약점이 없는 것보다 "어디까지 테스트했고 무엇이 남았는가"를 명확히 하는 것이 더 중요합니다.

Vulnerability Analysis Report 필수

알려진 취약점과 구현 취약점 분석 결과. CVE 영향 분석, Hard-coded Key, Debug 상태, OSS 취약점이 포함됩니다. Pentest 전 단계로, 어떤 공격 시나리오를 집중 수행할지 방향을 정합니다.

Penetration Test Report 필수

공격 시뮬레이션 수행 결과. 수행한 공격 시나리오, 발견된 취약점, 재현 절차, Attack Chain 성립 여부, 위험도 평가, 권고 조치가 포함됩니다. OEM마다 요구하는 범위와 깊이가 다르므로 사전 합의가 필요합니다.

Residual Risk Evaluation 필수

검증 이후에도 남아있는 Risk를 평가하고 허용 가능성을 판단하는 문서. 모든 Risk 제거는 불가능하므로 허용 근거와 완화 조치를 명시합니다. Cybersecurity Case의 핵심 구성 요소입니다.

Residual Risk — "수용 가능한 위험"을 어떻게 판단하는가

모든 취약점을 제거하는 것은 현실적으로 불가능합니다. 그래서 Clause 11의 핵심 판단 중 하나가 "남은 위험이 수용 가능한 수준인가"입니다.

Residual Risk 수용 판단 기준

즉시 수정

Attack Chain이 완성되고 Safety 영향이 있는 취약점. 원격 공격 가능, 전문성 낮음. 반드시 수정 후 재검증이 필요합니다.

수정 계획

Attack Feasibility가 중간 수준. 특수 장비나 물리 접근이 필요한 공격. 다음 버전 또는 OTA로 수정 계획을 수립합니다.

완화 조치

공격 가능성은 있으나 피해 규모가 제한적. 직접 수정보다 Gateway 필터링, 접근 제한 같은 Compensating Control로 완화합니다.

수용

물리 접근 필수, 전문 장비 필요, 실제 영향 매우 제한적인 취약점. 근거와 완화 조치를 문서화하고 OEM 승인을 받아 Residual Risk로 수용합니다.

"취약점 0개"가 아니라 "취약점을 이해하고 관리하고 있는가"가 VTA 심사의 핵심입니다. 취약점이 발견됐을 때 수정·재검증·배포 프로세스가 있는가를 OEM은 더 중요하게 봅니다.

왜 "보안 완료"라는 상태가 없는가

기능 테스트는 Pass/Fail이 가능합니다. 하지만 보안 테스트는 다릅니다. 새로운 공격 기법, 새로운 CVE, 새로운 연결 기능이 계속 등장하기 때문입니다.

잘못된 기대

"Pentest 한 번 통과하면 보안 완료" — 개발 단계에서 한 번 하면 출시 후에도 안전하다는 생각

실제로는

새로운 공격 기법, CVE, 기능 추가, 아키텍처 변경이 발생하면 재검증 필요. 보안 테스트는 "완료"가 아니라 "지속 관리" 개념

잘못된 기대

"취약점 0개 = 안전하다" — 취약점이 발견되지 않으면 보안이 완성됐다는 생각

실제로는

발견되지 않은 것과 없는 것은 다름. 테스트 범위와 깊이가 충분했는지가 더 중요. "어디까지 테스트했는가"를 증명해야 함

잘못된 기대

"보안 기능 구현 = Validation 통과" — 요구사항대로 구현했으면 검증도 됐다는 생각

실제로는

요구사항이 실제 공격 시나리오를 충분히 커버하지 못할 수 있음. Validation은 공격자 관점에서 별도로 수행해야 함

잘못된 기대

"OEM에 제출할 Pentest Report만 있으면 된다" — 보고서 형식만 맞추면 된다는 생각

실제로는

VTA 심사는 Traceability를 봄. Requirement → Test Spec → Test Result → Residual Risk까지 연결이 있어야 인정받음

차량 보안 테스트는 "완료"보다 "지속 관리" 개념에 가깝습니다. 그래서 ISO 21434도 Clause 12~14에서 양산 이후 보안 활동을 계속 요구합니다. 새로운 CVE가 발표됐을 때 영향 분석하고 패치를 배포하는 것까지가 보안 검증의 범위입니다.

현업에서는 실제로 이렇게 경험한다

Pentest 범위 정의가 가장 먼저 어렵다 — 어디까지 공격 시나리오로 볼지 OEM마다 다릅니다. 어떤 OEM은 OBD 중심이고, 어떤 OEM은 클라우드·Mobile App까지 포함합니다. 프로젝트 초기에 OEM과 범위를 합의하지 않으면 나중에 재수행 요청이 생깁니다.

테스트보다 증적 정리가 더 오래 걸린다 — Pentest 수행 자체보다 Traceability, Report 작성, Evidence 정리가 더 많은 시간을 차지하는 경우가 많습니다. Requirement와 Test Case를 연결하고 Cybersecurity Case로 취합하는 작업이 상당한 공수입니다.

보안 수정 후 기능 Regression이 반드시 발생한다 — SecOC 적용 후 CAN Latency 증가, HSM 적용 후 Boot Time 증가, IDS 활성화 후 CPU Load 증가. 보안 수정이 Safety 또는 기능 요구사항과 충돌하는 경우가 반드시 생깁니다.

Legacy ECU는 테스트 자체가 어렵다 — Debug Interface가 없거나 로깅 체계가 부족한 ECU는 취약점 분석 난이도가 매우 높습니다. Black-box 테스트 접근이 필요하고, 결과의 신뢰성을 증명하기도 어렵습니다.

OEM은 "취약점 0개"보다 대응 체계를 본다 — 실제로 중요한 건 취약점이 발견됐을 때 수정·재검증·OTA 배포 프로세스가 있는가입니다. 취약점 개수보다 이 체계의 존재 여부가 VTA 심사에서 더 중요하게 평가됩니다.

마무리

차량 보안 테스트의 목적은
"안전하다고 선언하는 것"이 아닙니다.

어디까지 위험을 줄였고,
남은 위험을 이해하고 관리하고 있는지를 증명하는 것입니다.

자동차는 이제 단순 기계가 아니라 계속 연결되고 업데이트되는 시스템입니다. 그래서 보안 테스트도 출시 전 이벤트가 아니라 차량 생애주기 전체의 활동으로 바뀌고 있습니다. 그리고 이것이 ISO 21434 Clause 11이 말하는 Validation의 진짜 의미입니다.

핵심 요약

• Clause 11은 Cybersecurity Validation — Verification(구현 검증)과 다른 개념이다
• Validation의 핵심 질문: "실제 공격을 막을 수 있는가?"
• 차량 보안 테스트는 개별 ECU가 아니라 차량 전체 Attack Chain을 본다
• 4가지 활동: Requirement-based Test → Vulnerability Analysis → Fuzzing → Penetration Test
• Pentest의 핵심은 취약점 개수가 아니라 Attack Chain 완성 여부다
• 주요 Work Product: Validation Specification, Validation Report, Vulnerability Analysis Report, PenTest Report, Residual Risk Evaluation
• Residual Risk는 "방치"가 아니라 근거와 함께 문서화하고 OEM 승인을 받아야 한다
• 취약점 0개보다 "어디까지 테스트했고 무엇이 남았는가"를 증명하는 것이 중요하다
• 보안 테스트는 "완료"가 아니라 차량 생애주기 전체의 "지속 관리" 활동이다
• OEM은 취약점 개수보다 발견 후 수정·재검증·배포 프로세스의 존재를 더 중요하게 본다

ISO21434 Clause11 CybersecurityValidation PenetrationTest Fuzzing VulnerabilityAnalysis 차량사이버보안 자동차보안테스트 ResidualRisk AttackChain WorkProduct R155