자동차 사이버보안 산출물 총정리 — TARA부터 Cybersecurity Case까지 한눈에 보기

ISO/SAE 21434 실무 시리즈

ISO/SAE 21434 실무 시리즈 맵

DONE TARA 수행법

DONE Cybersecurity Goal vs Requirement

DONE Clause 9 — TARA

DONE Clause 10 — 보안 설계

DONE Clause 11 — V&V

NOW 산출물 세트 총정리

NEXT Traceability 관리

SOON PKI 전체 구조

프로젝트에 처음 들어온 엔지니어들이 받는 충격

"Secure Boot 구현했으면 이제 끝난 거 아닌가요?"

"왜 이렇게 문서가 많아요?"

"TARA 말고도 또 뭔가 있어요?"

"Cybersecurity Case가 뭔지 모르겠어요."

ISO/SAE 21434가 요구하는 것은 단순히 보안 기능의 구현이 아닙니다.

위험을 식별하고 → 요구사항으로 만들고 → 검증하고 → 증명하는
전체 흐름이 하나의 추적 가능한 체인으로 연결되어야 합니다.

오늘은 그 흐름을 산출물 단위로 통째로 정리합니다.

---

전체 그림부터 — 산출물은 하나의 흐름이다

개별 산출물을 하나씩 이해하기 전에 전체 흐름을 먼저 잡아야 합니다. 문서가 많아 보여도, 사실은 하나의 논리적 흐름 위에 놓여 있습니다.

CYBERSECURITY DOCUMENT FLOW

1

Item Definition — 무엇을 개발하는가

↓

2

Asset Identification — 무엇을 보호할 것인가

↓

3

TARA — 어떤 위험이 있는가

↓

4

Cybersecurity Goal — 무엇을 달성해야 하는가

↓

5

Cybersecurity Requirement — 어떻게 구현할 것인가

↓

6

System / HW / SW Requirement — 누가 무엇을 개발하는가

↓

7

Implementation — 실제 구현

↓

8

Verification & Validation — 올바르게 만들었는가 / 효과가 있는가

↓

9

Cybersecurity Case — 충분한 보안을 달성했다는 최종 증거

이 흐름 전체가 하나의 추적 가능한 체인(Traceability Chain)을 이룹니다. 위 흐름을 머릿속에 넣고 각 산출물을 읽으면 훨씬 쉽게 이해됩니다.

---

산출물별 상세 정리

단계	산출물	핵심 질문	주요 내용
①	Item Definition	무엇을 개발하는가?	시스템 기능, 외부 인터페이스, 네트워크 연결, 데이터 흐름, 시스템 경계
②	Asset Identification	무엇을 보호할 것인가?	보안키, 소프트웨어 이미지, 차량 제어 기능, 진단 서비스, CAN 메시지 등
③	TARA	어떤 위험이 있는가?	Threat Scenario, Attack Path, Impact Rating, Attack Feasibility, Risk 산출
④	Cybersecurity Goal	무엇을 달성해야 하는가?	Risk가 높은 항목을 보안 목표로 정의. 구현 방법은 포함하지 않음
⑤	Cybersecurity Requirement	어떻게 구현할 것인가?	Goal을 실제 구현 가능한 수준의 요구사항으로 변환
⑥	System/HW/SW Requirement	누가 무엇을 개발하는가?	보안 요구사항을 개발 영역(시스템/하드웨어/소프트웨어)별로 분해
⑦	Implementation	실제 구현이 되었는가?	코드, 설정, 하드웨어 설계 등 실제 결과물
⑧	V&V	올바르게 만들었고, 효과가 있는가?	코드 리뷰, 정적 분석, 요구사항 시험(Verification) / PenTest, 공격 시뮬레이션(Validation)
⑨	Cybersecurity Case	충분한 보안을 달성했다는 증거는?	위 모든 산출물의 결과를 연결한 최종 증거 문서

---

각 산출물, 현업에서는 이렇게 쓰인다

① Item Definition — 보안 분석의 범위를 정의한다

모든 것은 "무엇을 분석할 것인가"를 정하는 것에서 시작됩니다. Item Definition이 불분명하면 TARA 범위가 흔들리고, 뒤에 나오는 모든 산출물의 품질이 흔들립니다.

⚠️ Item의 경계(Boundary)를 어디서 자르느냐에 따라 분석해야 할 인터페이스 수가 크게 달라집니다. OEM이 Item을 어떻게 정의했느냐를 먼저 확인하는 게 프로젝트 시작의 첫 번째 일입니다.

② Asset Identification — 보호 대상을 구체적으로 찾는다

자산(Asset)은 물리적인 것만이 아닙니다. 데이터와 기능도 자산입니다. Gateway ECU라면 진단 서비스, CAN 메시지 라우팅 기능, 보안키, 소프트웨어 이미지 모두가 보호 대상이 될 수 있습니다.

ISO/SAE 21434에서 Asset은 Cybersecurity Property(기밀성·무결성·가용성)와 연결됩니다. 자산을 정의할 때는 "이 자산이 침해되면 어떤 보안 속성이 손상되는가"까지 함께 생각해야 합니다.

③ TARA — 사이버보안의 핵심 분석 문서

Threat Analysis and Risk Assessment. 여기서 나온 Risk 등급이 이후 모든 요구사항의 근거가 됩니다.

TARA 핵심 구조

Asset — 보호 대상 확정

↓

Threat Scenario — 위협 시나리오 도출

↓

Attack Path — 공격 경로 분석

↓

Impact Assessment — S / F / O / P 4개 영역 평가

↓

Attack Feasibility — 공격 난이도 평가

↓

Risk — Impact × Feasibility → Risk 등급 결정

현업 경험

실제 프로젝트에서 TARA는 초안을 한 번 만든 다음 OEM 리뷰, 협력사 리뷰를 거치며 3~5회 이상 버전업되는 경우가 많습니다. 특히 Attack Feasibility 평가 항목에서 OEM과 협력사 간 의견 차이가 자주 발생합니다. 같은 공격 경로를 두고 한쪽은 "현실적으로 어렵다", 다른 쪽은 "충분히 가능하다"고 보는 경우입니다. 이 차이가 결국 요구사항 수준을 결정하기 때문에, 협의 이력을 남겨두는 것이 중요합니다.

④ Cybersecurity Goal — "무엇을"을 정의한다

TARA에서 Risk가 높은 항목은 Cybersecurity Goal로 승격됩니다. Goal은 구현 방법을 포함하지 않습니다. "무엇을 달성해야 하는가"만을 정의합니다.

❌ Goal이 아닌 것 — "ECU는 Security Access를 구현해야 한다"

✅ 올바른 Goal — "승인되지 않은 사용자의 ECU 재프로그램을 방지해야 한다"

Goal은 방법이 아닌 목표를 서술합니다. 어떻게 구현할지는 다음 단계인 Requirement에서 정의합니다.

⑤ Cybersecurity Requirement — "어떻게"를 정의한다

Goal을 실제 엔지니어가 구현할 수 있는 수준으로 변환하는 단계입니다. 이 문서부터 개발 조직이 읽을 수 있는 내용이 됩니다.

✅ 변환 예시

Goal: "승인되지 않은 사용자의 ECU 재프로그램 방지"
→ Requirement: "ECU는 Flash Download 수행 전 UDS Security Access(0x27) 인증을 완료해야 한다"

⑥ System / HW / SW Requirement — 요구사항이 개발 조직으로 내려간다

Cybersecurity Requirement는 하나지만, 이를 구현하기 위해 시스템 / 하드웨어 / 소프트웨어 레벨로 분해됩니다.

분해 예시 — Security Access 구현

System Req: ECU는 인증된 사용자만 재프로그램 가능해야 한다
SW Req: UDS Service 0x27 구현, Seed/Key 알고리즘 적용
HW Req: 암호키 저장을 위한 HSM 사용

현업 경험

협력사 입장에서 가장 혼란스러운 지점이 바로 여기입니다. OEM이 Cybersecurity Requirement만 전달하고 "System/HW/SW 레벨로 분해해서 추적성 관리해줘"라고 요청하면 막막한 경우가 많습니다. 이 분해 작업이 사실상 사이버보안 엔지니어의 핵심 역량 중 하나입니다.

⑦ Verification & Validation — 두 개의 V는 완전히 다른 질문이다

VERIFICATION

요구사항대로 올바르게 만들었는가?

• 코드 리뷰
• 정적 분석 (MISRA·CERT)
• 요구사항 기반 기능 시험
• Integration Test

VALIDATION

실제 위험이 해결되었는가?

• Penetration Test
• 공격 시뮬레이션
• Fuzz Testing
• Residual Risk 판단

⚠️ Verification만 하고 Validation을 빠뜨리는 경우가 실무에서 많습니다.
요구사항 시험을 다 통과했다고 해서 실제 보안이 충분하다는 의미는 아닙니다. Validation은 "공격자 관점"에서 다시 한번 검증하는 과정입니다.

⑧ Cybersecurity Case — 모든 증거를 묶는 최종 문서

많은 사람들이 마지막에야 이해하는 문서입니다. Cybersecurity Case는 새로 작성하는 문서가 아닙니다. 앞서 만든 모든 산출물의 결과를 연결하여 "우리는 충분한 보안을 달성했다"는 논거를 구성하는 문서입니다.

Cybersecurity Case는 보안을 '주장'하는 것이 아니라, 주장을 '증명'하는 것입니다.

Cybersecurity Case가 포함하는 것:

TARA 결과 / Cybersecurity Goal / Requirement / 시험 결과 / 잔여 위험(Residual Risk) 분석 / 미결 사항 처리 이력

---

결국 자동차 사이버보안은 추적성(Traceability)의 싸움이다

실무 프로젝트에서 가장 자주 받는 질문이 있습니다.

"Secure Boot 구현했는데 이제 끝난 거 아닌가요?"

ISO/SAE 21434가 진짜로 묻는 것은 기술 그 자체가 아닙니다. 그 기술이 어떤 위험(TARA) 때문에 필요했고, 어떤 목표(Goal)를 달성하기 위한 것이며, 어떤 요구사항(Requirement)으로 정의되었고, 어떻게 검증(V&V)되었는지를 하나의 끊기지 않는 체인으로 증명하는 것입니다.

현업 경험

인증 심사나 OEM 기술 검토에서 가장 많이 지적받는 부분이 바로 이 체인의 단절입니다. 구현은 잘 되어 있는데 TARA에서 해당 항목이 없거나, Requirement는 있는데 시험 케이스와 연결이 안 되어 있거나. 기술이 아니라 문서의 연결이 문제가 되는 경우가 훨씬 많습니다.

---

핵심 요약

1

산출물은 Item Definition → TARA → Goal → Requirement → V&V → Cybersecurity Case로 이어지는 하나의 흐름

2

Goal은 "무엇을 달성할 것인가", Requirement는 "어떻게 구현할 것인가" — 역할이 분명히 다릅니다

3

Verification은 요구사항 준수, Validation은 실제 위험 해소 확인 — 둘은 대체 관계가 아닙니다

4

Cybersecurity Case는 새 문서가 아니라 모든 산출물의 연결 고리이자 최종 증거

5

인증에서 떨어지는 이유는 대부분 기술 부족이 아니라 추적성 단절

ISO21434 TARA CybersecurityCase 산출물정리 Traceability 보안요구사항 V&V 자동차사이버보안 차량보안