차량 보안 검증은 무엇을 증명해야 할까? — Clause 11

현업에서 보는 ISO/SAE 21434 05

이전 편 | 보안 요구사항은 어떻게 ECU 설계가 될까? — Clause 10

자동차 보안 프로젝트에서 이런 말이 자주 나옵니다.

"Secure Boot 들어갔습니다."
"SecOC 적용 완료했습니다."
"PenTest도 진행했습니다."

그런데 ISO/SAE 21434 관점에서는 여기서 더 중요한 질문이 있습니다.

"그래서 정말 안전하다는 게 증명됐는가?"

구현했다는 것과 검증됐다는 것은 다릅니다.
Clause 11은 보안 Requirement가 실제로 만족되었는지를 증명하는 단계입니다.
그리고 테스트를 주로 수행하는 팀이 가장 깊이 관여하는 절이기도 합니다.

Clause 11은 어디에 위치하는가

시리즈 전체 흐름에서의 Clause 11 위치

Clause 5·6
조직·프로젝트

→

Clause 9
TARA

→

Clause 10
설계·구현

→

Clause 11
검증·PenTest

→

Clause 12~15
양산·운영·폐기

Clause 10에서 설계하고 구현한 보안 기능이 실제로 의도한 대로 동작하는지, 공격자의 시도를 막아낼 수 있는지를 확인하는 단계가 Clause 11입니다. Clause 11의 결과물은 최종 Cybersecurity Case를 완성하는 핵심 근거가 됩니다.

과거 자동차 테스트

기능 정상 동작 확인 중심

보안 테스트 = 옵션

PenTest 없이 출시

취약점 = 출시 후 발견

검증 증적 관리 없음

21434·R155 이후

공격 저항성 검증 필수

Requirement 기반 검증

PenTest 의무화 추세

Residual Risk 평가 요구

Work Product 증적 필수

Clause 11 검증의 두 축

Clause 11은 크게 두 방향으로 움직입니다. 많은 사람들이 PenTest만 생각하지만, 21434는 훨씬 넓게 봅니다.

① Requirement 기반 검증

정의한 보안 Requirement가 구현됐는가?

Requirement ↔ Test Case ↔ Result 연결

기능 검증, 인터페이스 검증 포함

각 Requirement에 대한 Pass/Fail 판정

Traceability Matrix로 증적 관리

② 공격 기반 검증

실제 공격 시도에 견디는가?

Vulnerability Analysis 포함

Penetration Test 수행

알려진 취약점 + 새로운 공격 시나리오

Residual Risk 평가로 연결

PenTest에서 취약점이 발견되지 않았다는 것이 "안전하다"는 의미가 아닙니다. Requirement 기반 검증 없이 PenTest만 수행하면, 보안 기능 자체가 없거나 잘못 구현됐어도 "현재 공격 방법으로는 안 뚫렸다"는 결론만 나올 수 있습니다.

자동차 보안 검증 대상 — 무엇을 확인하는가

자동차 ECU의 공격 표면은 IT 시스템보다 훨씬 넓습니다. 실시간 제어, CAN 네트워크, 물리 인터페이스, OTA, 진단 프로토콜이 모두 검증 대상이 됩니다.

검증 영역	주요 확인 항목	대표 공격 시나리오
Secure Boot	변조 펌웨어 실행 차단, 서명 검증 동작	서명 제거 후 플래시 → Boot 시도
UDS / Diagnostics	Security Access 우회 방지, 세션 제어	Seed-Key 무차별 대입, 권한 없는 서비스 접근
SecOC / CAN	위조 메시지 차단, Replay 방지	CAN Injection, Replay Attack, SecOC 우회
OTA	악성 패키지 설치 차단, Anti-Rollback	패키지 위변조, 서명 우회, Rollback 공격
Gateway	비인가 Routing 차단, 도메인 분리	Gateway 우회, 비인가 ECU 접근
HSM / 키 관리	키 추출 방지, Side Channel 저항성	Firmware Dump, Hardcoded Key 탐색
Debug Interface	양산 잠금 여부, JTAG/SWD 비활성화	Debug Port 접근, JTAG 강제 활성화
DoIP / Ethernet	인증 우회 방지, 비인가 접근 차단	DoIP 인증 우회, 비인가 Flash 시도
무선 인터페이스	BT/BLE/Wi-Fi 인증·암호화 검증	중간자 공격, 재전송 공격, TCU 침투

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

테스트팀이 가장 궁금해하는 부분입니다. 실제 차량 PenTest에서 수행되는 주요 시나리오를 영역별로 정리했습니다.

🔧 Diagnostic 공격

UDS Session 전환 시도

Security Access Seed-Key 무차별 대입

권한 없는 Flashing 시도

Hidden UDS Service 탐색

Fuzzing 기반 진단 프로토콜 테스트

📡 CAN / 네트워크 공격

위조 CAN 메시지 주입

SecOC Freshness 우회 시도

Replay Attack

CAN ID 충돌(Arbitration Abuse)

Gateway 필터링 규칙 우회

📦 OTA 공격

OTA 패키지 위변조

서명 검증 우회 시도

Rollback 공격 (구 버전 강제 설치)

Download Channel 중간자 공격

불완전 업데이트 상태 악용

🔩 Firmware / 하드웨어 분석

JTAG/SWD Debug 접근 시도

Firmware Dump 및 역공학

Hardcoded Key / Secret 탐색

암호화 구현 취약점 분석

Side Channel 공격 가능성 평가

📶 무선 인터페이스 공격

BLE/Wi-Fi 인증 우회

Relay Attack (스마트키)

TCU / Telematics 침투

중간자(MITM) 공격

인증서 검증 우회

🌐 DoIP / Ethernet 공격

DoIP 인증 우회

비인가 Flash 시도

서비스 거부(DoS) 공격

비인가 ECU 접근

네트워크 Fuzzing

PenTest는 검증의 마지막 단계에 가깝습니다. PenTest에서 "공격 성공 없음"이 나왔어도, Secure Boot가 비활성화되어 있거나 Debug가 열려 있거나 HSM을 사용하지 않는다면 구조적 문제가 남아있는 것입니다. "지금 당장 안 뚫렸다"와 "안전하다"는 다릅니다.

Requirement → Test → Result — 연결이 끊어지면 안 된다

Clause 11에서 가장 중요하게 요구하는 것 중 하나가 Requirement와 Test, 그리고 Result의 연결입니다. "테스트 했다"가 아니라 "어떤 Requirement를 어떤 방법으로 검증해서 어떤 결과가 나왔는지"가 추적 가능해야 합니다.

Requirement → Test → Result Traceability 예시 — Secure Boot

Requirement

ECU는 ECDSA-P256 서명이 검증된 소프트웨어만 실행해야 한다 — Clause 10에서 정의, TARA OTA 위변조 위협에서 도출

Test Spec

TC-SB-001: 서명 없는 펌웨어 플래시 후 부팅 시도
TC-SB-002: 서명 있으나 변조된 펌웨어 플래시 후 부팅 시도
TC-SB-003: 유효한 서명·정상 펌웨어 플래시 후 부팅 시도

Test 수행

TC-SB-001: 부팅 차단 확인 → PASS  |  TC-SB-002: 부팅 차단 확인 → PASS  |  TC-SB-003: 정상 부팅 확인 → PASS

결과

Requirement 만족 — Verification Evidence로 Cybersecurity Case에 포함

Residual Risk

서명 검증 로직 구현 버그 가능성 → Risk Level: Low / 후속 Code Review로 완화

실제 프로젝트에서는 Requirement 변경이 생기면 Test Spec과 Result도 함께 업데이트해야 합니다. 이 연결이 끊어지면 VTA 심사에서 "이 Requirement는 검증됐습니까?"라는 질문에 답할 수 없게 됩니다. Traceability 관리가 구현보다 더 많은 공수를 차지하는 이유입니다.

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

Work Products Clause 11 — 산출물 목록 테스트팀 필수 확인

Verification Specification 필수

무엇을 어떻게 검증할지 사전 정의하는 문서. 각 Requirement에 대응하는 Test Case, 테스트 환경, 합격 기준(Pass/Fail 판정 조건)이 포함됩니다. Requirement가 정의되면 이 문서가 먼저 작성되어야 합니다.

Verification Result 필수

실제 테스트 수행 결과 기록. 각 Test Case의 Pass/Fail 판정, 실행 환경, 날짜, 담당자가 포함됩니다. Requirement와 결과 사이의 Traceability가 유지되어야 합니다.

Vulnerability Analysis Report 필수

알려진 취약점(CVE) 분석, 공격 표면 식별, 잠재적 취약점 탐색 결과를 정리한 문서. PenTest 전 단계로, 어떤 공격 시나리오를 집중적으로 테스트할지 방향을 정합니다.

Penetration Test Report 필수

실제 공격 시뮬레이션 수행 결과. 수행한 공격 시나리오, 발견된 취약점, 재현 절차, 위험도 평가, 권고 조치가 포함됩니다. OEM이 요구하는 범위와 깊이가 다를 수 있어 사전 합의가 필요합니다.

Residual Risk Evaluation 필수

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

Cybersecurity Case 필수

"이 차량이 충분히 안전하다"는 주장을 뒷받침하는 전체 논리 체계. TARA → Requirement → 구현 → 검증 → Residual Risk까지의 증거를 하나로 묶습니다. VTA/R155 형식승인의 핵심 제출 문서입니다.

Traceability Matrix

TARA 위협 → Security Goal → Requirement → Test Case → Test Result까지 전 단계 연결 추적 문서. 심사에서 "이 보안 기능이 왜 여기 있고 어떻게 검증됐는가"에 즉시 답할 수 있어야 합니다.

Cybersecurity Case — "우리는 충분히 안전하다"를 증명하는 논리

Clause 11의 최종 결과물이자 VTA 심사의 핵심 문서가 Cybersecurity Case입니다. 단순한 테스트 결과 모음이 아니라, "이 차량이 사이버보안 관점에서 충분히 안전하다"는 주장을 논리적으로 뒷받침하는 문서 체계입니다.

Cybersecurity Case 구성 요소

1

위협 근거 — TARA에서 식별된 위협 시나리오와 Risk Level. "어떤 위협이 존재하는가"를 정의합니다.

2

보안 목표 및 요구사항 — Security Goal과 Cybersecurity Requirement. "무엇을 막아야 하는가"와 "어떻게 막을 것인가"를 정의합니다.

3

구현 근거 — Cybersecurity Architecture와 Specification. "실제로 어떻게 구현했는가"를 증명합니다.

4

검증 증거 — Verification Result, PenTest Report. "구현이 요구사항을 만족하는가, 공격을 막는가"를 증명합니다.

5

Residual Risk 판단 — 남아있는 Risk와 허용 근거. "완벽하지 않더라도 허용 가능한 수준인가"를 정의합니다.

R155/VTA 심사에서 OEM이 "우리는 차량 사이버보안을 관리하고 있습니다"를 증명하는 핵심 수단이 Cybersecurity Case입니다. Tier-1이 제출하는 모든 검증 증거가 이 문서로 취합됩니다. 문서의 질이 심사 결과를 직접적으로 좌우합니다.

테스트팀이 자주 마주치는 오해들

흔한 오해

"PenTest에서 취약점 안 나왔으니 안전하다" — 공격 방법이 없었던 것이지 보안이 완성된 것이 아님

21434 관점

Requirement 기반 검증이 먼저. Secure Boot 비활성화·HSM 미사용·Debug 열림 같은 구조적 문제는 PenTest로 발견되지 않을 수 있음

흔한 오해

"SecOC 적용 완료 = CAN 보안 완성" — 기능 존재와 실제 보안 효과는 다름

21434 관점

Freshness 관리 실패, Key 공유 구조 문제, 일부 메시지 제외가 있으면 공격 가능성 남음. 실제 공격 저항성 검증 필수

흔한 오해

"PenTest 한 번이면 끝" — 아키텍처 변경, 새 인터페이스 추가, 공급망 변경 시 재검증 필요

21434 관점

변경 사항 발생 시 영향받는 Requirement와 Test를 재수행. Cybersecurity Monitoring으로 출시 후에도 지속

흔한 오해

"테스트 결과 보고서만 있으면 된다" — VTA 심사는 Traceability를 요구함

21434 관점

어떤 Requirement를, 어떤 Test로, 어떤 결과로 검증했는지 연결이 필수. 보고서보다 추적성이 더 중요

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

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

Requirement-Test 연결이 자주 끊어진다 — 개발 중 Requirement가 변경됐는데 Test Spec이 미수정되어 Traceability가 붕괴되는 경우가 매우 흔합니다. Requirement 변경 시 영향받는 Test Case를 함께 관리하는 프로세스가 초기부터 필요합니다.

OEM마다 PenTest 기대 수준이 다르다 — 어떤 OEM은 CVSS 기반 Risk 평가만 요구하고, 어떤 OEM은 실제 Exploit 가능성, Attack Path, 사용 Tool Chain까지 요구합니다. 프로젝트 초기에 OEM과 PenTest 범위·깊이·형식을 합의하는 것이 중요합니다.

보안 기능 존재와 보안 효과는 다르다 — SecOC가 적용됐어도 Freshness 관리가 부실하면 Replay Attack이 가능합니다. Secure Boot가 있어도 Debug가 열려 있으면 우회가 가능합니다. 기능 구현 체크리스트가 아니라 실제 공격 저항성을 검증해야 합니다.

Residual Risk 평가가 의외로 어렵다 — 어디까지 Risk를 줄였고 어느 수준의 잔여 Risk가 허용 가능한지 판단하는 것이 어렵습니다. 특히 Safety와 연결되는 Risk는 HARA(ISO 26262)와 함께 검토해야 하는 경우가 있어 협업 범위가 넓어집니다.

마무리

Secure Boot가 존재하는 것과 실제 공격을 막는 것은 다릅니다.
SecOC를 넣은 것과 CAN Injection을 막는 것도 다릅니다.
Clause 11은 바로 그 차이를 증명하는 단계입니다.

자동차 산업은 이제 기능이 정상 동작하는지 확인하는 것을 넘어, 공격 상황에서도 안전한지를 증명하는 방향으로 이동하고 있습니다. 그리고 그 증명의 핵심은 테스트 결과 자체가 아니라, Requirement에서 검증까지 이어지는 추적 가능한 증거 체계입니다.

다음 편에서는 Clause 12~15를 다룹니다. 차량이 출시된 이후 양산·운영·폐기 단계에서 보안이 어떻게 지속 관리되는지, PSIRT와 OTA가 어떻게 연결되는지를 살펴봅니다.

핵심 요약

• Clause 11은 Cybersecurity Validation 단계 — "보안 Requirement가 실제 만족됐는가"를 증명한다
• 검증은 Requirement 기반 검증 + 공격 기반 검증 두 축으로 구성된다
• PenTest는 검증의 마지막 단계이지 전체가 아니다
• 자동차 보안 검증 대상: Secure Boot·UDS·SecOC·OTA·Gateway·HSM·Debug·DoIP·무선
• Requirement ↔ Test Case ↔ Test Result Traceability가 VTA 심사의 핵심
• 주요 Work Product: Verification Specification, Verification Result, Vulnerability Analysis Report, PenTest Report, Residual Risk Evaluation, Cybersecurity Case
• Cybersecurity Case는 위협→요구사항→구현→검증→잔여Risk를 하나의 논리로 묶는 문서
• 보안 기능 존재보다 실제 공격 저항성 검증이 더 중요하다
• 테스트보다 증적 관리와 Traceability 유지에 더 많은 공수가 필요하다
• 자동차 산업은 기능 테스트 중심에서 공격 저항성 검증 중심으로 이동 중이다

📚 현업에서 보는 ISO/SAE 21434 — 시리즈

0

ISO/SAE 21434는 도대체 무엇을 바꿨을까? — 오버뷰

1

ISO 21434는 왜 개발보다 조직 관리부터 시작할까? — Clause 5·6

2

차량 보안은 왜 공급망 전체를 관리해야 할까? — Clause 7·8

3

TARA는 왜 자동차 보안의 출발점이 되었을까? — Clause 9

4

보안 요구사항은 어떻게 ECU 설계가 될까? — Clause 10

5

차량 보안 검증은 무엇을 증명해야 할까? — Clause 11  ← 현재 글

6

양산 이후 차량 보안은 어떻게 유지될까? — Clause 12~15

ISO21434 Clause11 CybersecurityValidation PenTest VulnerabilityAnalysis CybersecurityCase Traceability ResidualRisk 차량사이버보안 WorkProduct 자동차보안테스트 R155