자동차 사이버보안 테스트는 실제로 무엇을 할까?— ISO/SAE 21434 Clause 11의 현실

차량 사이버보안 테스트·검증 시리즈

시리즈 전체 구성

1

1편 · 지금 읽는 글

자동차 보안 테스트는 실제로 무엇을 할까?

ISO/SAE 21434 Clause 11 · 4가지 검증 유형 · 테스트 전체 구조

NOW

2

2편 · 다음 글

차량 Penetration Test는 왜 일반 IT 해킹과 다를까?

CAN·UDS·Fuzzing · 물리 공격 · 차량 특화 PenTest 방법론

NEXT

3

3편 · 예정

차량 보안 테스트는 왜 완벽할 수 없을까?

Residual Risk · 현실적인 보안의 한계 · PSIRT와 지속 운영

SOON

차량 사이버보안 이야기를 하다 보면 이런 말을 자주 듣습니다.

현업에서 자주 나오는 말들

"보안 테스트면 해킹 한 번 해보는 거 아닌가요?"

"웹 모의해킹처럼 하면 되는 거 아닌가요?"

"PenTest만 하면 보안 검증 끝 아닌가요?"

"자동차 보안 테스트는 왜 이렇게 오래 걸리죠?"

이 오해들이 생기는 이유가 있습니다. IT 보안 테스트와 차량 보안 테스트가 겉으로는 비슷해 보이기 때문입니다. 하지만 실제로는 목적도, 구조도, 난이도도 완전히 다릅니다.

차량 보안 테스트는 단순히 "뚫리나 안 뚫리나"를 보는 작업이 아닙니다.

보안 요구사항이 제대로 구현됐는지,
실제 공격을 막을 수 있는지,
양산 이후에도 보안이 유지되는지까지 확인하는 전체 과정입니다.

---

차량 보안 테스트가 IT와 구조적으로 다른 이유

일반 IT 보안 테스트	차량 보안 테스트
서버·웹앱 중심	수십~수백 개 ECU + 네트워크
TCP/IP 기반 통신	CAN·LIN·FlexRay·Ethernet 혼재
소프트웨어 중심	물리 ECU + 펌웨어 + 하드웨어
취약점 발견 후 빠른 패치	양산 이후 수정 비용·공수 매우 큼
서비스 장애 중심 영향	조향·제동·파워트레인 제어 영향 가능
테스트 환경 구성 상대적으로 쉬움	실차 환경 없이 재현 안 되는 경우 많음

⚠️ 차량에서는 보안 문제가 Safety 문제로 이어질 수 있습니다.
CAN 메시지 조작으로 브레이크나 조향에 영향을 줄 수 있는 구조입니다. 그래서 테스트 자체도 통제된 환경에서, 절차에 따라 수행해야 합니다.

---

ISO/SAE 21434 Clause 11이 말하는 것

ISO/SAE 21434는 V-모델 개발 프로세스를 기반으로 합니다. 보안 테스트는 그 오른쪽 — 검증과 타당성 확인 단계에 위치합니다.

ISO/SAE 21434 V-모델 내 보안 테스트 위치

Concept
(Clause 9)

TARA · 보안 목표

→

System Design
(Clause 10)

요구사항 · 설계

→

SW 개발
(Clause 10)

구현

→

통합·검증
(Clause 10.4.2)

Integration & Verification

→

타당성 확인
(Clause 11)

Cybersecurity Validation

Clause 11 Cybersecurity Validation의 핵심:

차량 수준에서 아이템 전체를 대상으로 "사이버보안 목표가 실제로 달성됐는가"를 확인합니다. 단품 ECU 검증이 아닌 통합 시스템 관점에서의 검증입니다.

---

자동차 보안 테스트는 크게 4가지로 나뉜다

ISO/SAE 21434와 KISA 매뉴얼이 정의하는 검증 방법은 네 가지입니다. PenTest는 그 중 하나일 뿐입니다.

요구사항 검증

Requirement Verification

보안 요구사항이 ECU에 제대로 구현됐는지 확인합니다. "해야 한다"고 정의한 것들이 실제로 됐는지를 봅니다.

• Secure Boot 활성화 여부
• Debug Lock 설정 확인
• 인증 실패 시 제한 동작
• Traceability 연결 확인

취약점 분석

Vulnerability Analysis

알려진 취약점과 구조적 약점을 분석합니다. 코드·OSS·BSP 전반을 대상으로 합니다.

• CVE·CWE 기반 분석
• 오래된 라이브러리 점검
• Attack Surface 분석
• SBOM 기반 취약점 추적

보안 기능 시험

Security Testing

보안 기능이 정상 동작하는지 시험합니다. 기능이 있다고 제대로 동작하는 건 아닙니다.

• SecOC MAC 생성·검증
• OTA 무결성 검증 실패 처리
• 인증 실패 시 잠금 동작
• Secure Storage 접근 통제

침투 테스트

Penetration Testing

실제 공격자 관점에서 침투를 시도합니다. TARA에서 도출된 위협 시나리오 기반입니다.

• CAN Injection · Replay Attack
• UDS 권한 우회 시도
• Secure Debug 우회
• Firmware 변조 후 검증 우회

사이버보안 등급(CAL)에 따라 테스트 수준이 달라집니다.
Level 1 ECU는 퍼징·침투 테스트, Level 3 ECU(게이트웨이·ADAS)는 취약점 스캔까지 포함한 전체 검증이 필요합니다.

---

현실에서는 ECU 하나 테스트하는 것도 어렵다

이론은 깔끔하지만 현실은 다릅니다. 테스트 환경 구성부터 난관이 시작됩니다.

현업에서 자주 겪는 문제들

실차 환경이 아니면 재현 안 되는 문제가 있다 — Gateway Routing, Timing, Wake-up 조건 때문에 벤치에서는 안 보이는 동작이 있습니다. 실차 없이 완전한 검증이 불가능한 경우가 생깁니다.

ECU 하나만으로 테스트 불가능한 경우가 많다 — 다른 ECU와 인증·메시지 흐름이 연결되어 있어 전체 네트워크가 필요한 경우가 있습니다. 특히 SecOC 검증은 네트워크 전체가 필요합니다.

양산 Firmware와 개발 Firmware가 다르다 — Debug 옵션, Secure Boot 활성화 상태, 인증 설정이 다를 수 있습니다. 반드시 양산 버전 Firmware로 최종 검증해야 합니다.

OTA 이후 상태까지 고려해야 한다 — 업데이트 이후에도 Security Configuration이 유지되는지, Secure Boot가 정상 동작하는지 별도 검증이 필요합니다.

---

그래서 "PenTest만 하면 끝"이 아니다

❌ "모의해킹 한 번 했으니까 보안 검증 끝"

✅ Requirement 확인 → 기능 검증 → 취약점 분석 → PenTest가 모두 필요하다

PenTest는 검증 체계의 마지막 단계에 가깝습니다.

Secure Boot가 요구사항대로 구현됐는지, HSM이 제대로 동작하는지, OTA 검증이 실패했을 때 안전하게 차단되는지 같은 것들이 먼저 확인되어야 합니다. PenTest는 그 위에서 "실제 공격자가 이 구조를 뚫을 수 있는가"를 마지막으로 확인하는 작업입니다.

---

SDV 시대 — 테스트 범위가 계속 커지고 있다

차량 보안 테스트 범위 변화

📦 과거 ECU 중심

CAN 버스 중심
ECU 단위 검증
UDS 진단 중심
물리 접근 테스트

→

🔗 현재 SDV 시대

OTA + Cloud + PKI
Linux·Container 환경
SBOM 기반 취약점
Fuzzing 자동화
Backend API 포함
실시간 모니터링

차량이 "움직이는 분산 시스템"에 가까워지면서 테스트 범위와 복잡도가 계속 증가하고 있습니다. 이제는 ECU 하나만 보는 게 아니라 차량 전체 + Backend + OTA 플랫폼까지 포함한 통합 검증이 필요합니다.

---

마무리

차량 보안 테스트는
"취약점 찾기"보다,
"차량 전체 시스템이 안전하게 동작하는가"를 검증하는 과정에 가깝습니다.

그리고 그 검증은 PenTest 하나로 끝나지 않습니다.

NEXT — 2편 예고

차량 Penetration Test는 왜 일반 IT 해킹과 다를까?

CAN Injection, UDS Abuse, 물리 PCB 공격, Fuzzing. 차량 PenTest가 일반 웹 모의해킹과 어떻게 다른지, 실제로 어떤 방식으로 수행되는지 이야기합니다.

CAN·UDS 공격 Fuzzing PCB 물리 공격 Secure Boot 우회 시도 차량 특화 도구

핵심 요약

1

차량 보안 테스트는 단순 모의해킹이 아니다 — Requirement 검증부터 PenTest까지 4단계 전체가 필요합니다

2

ISO/SAE 21434 Clause 11은 차량 수준 통합 검증을 요구한다 — 단품 ECU가 아닌 시스템 전체를 봅니다

3

차량 특유의 테스트 환경 문제가 크다 — 실차·양산 Firmware·전체 네트워크가 필요한 경우가 많습니다

4

PenTest는 마지막 단계 — 그 전에 요구사항 검증·기능 시험·취약점 분석이 먼저 돼야 합니다

5

SDV 시대에는 테스트 범위가 OTA·Cloud·Backend까지 확장된다 — ECU 단위 검증만으로는 부족합니다

차량보안테스트 ISO21434 Clause11 PenetrationTest 취약점분석 차량사이버보안 Fuzzing SecureBoot SDV KISA