자동차 사이버보안을 시작하면 이 용어들이 계속 등장합니다.
Cybersecurity Goal, Cybersecurity Requirement, Security Claim.
문제는, 이름이 전부 비슷하게 생겼다는 겁니다.
그래서 실제 프로젝트에서도 이런 대화가 반복됩니다.
ISO/SAE 21434 문서를 읽다 보면 계층 구조가 머릿속에서 꼬이기 시작합니다. 비슷한 이름, 비슷한 위치, 비슷해 보이는 내용.
하지만 이 구조를 한 번 제대로 이해하면, TARA부터 형식승인까지 전체 흐름이 한 번에 연결됩니다.
Goal / Requirement / Claim의 차이를
실제 ECU 개발 흐름 기준으로 정리해봅니다.
왜 이 구조가 중요한가
자동차 보안은 단순히 "보안 기능을 넣는 작업"으로 끝나지 않습니다.
규제와 개발은 항상 이렇게 움직입니다.
식별
정의
분해
구현
검증
입증
세 개념은 이 흐름에서 각자 다른 역할을 담당합니다.
Cybersecurity Goal — 방향을 정의하는 단계
Goal은 가장 상위 개념입니다. TARA에서 위험 시나리오를 분석한 뒤, "무엇을 반드시 보호해야 하는가"를 정의합니다.
핵심은 기술 구현이 들어가지 않는다는 점입니다. Goal은 "목적"만 담습니다.
예시 — OTA 공격 시나리오
TARA 분석 결과, 공격자가 악성 OTA 패키지를 주입해 차량 기능을 변조할 수 있다는 Risk가 도출됐다고 가정합니다.
그럼 Cybersecurity Goal은 이렇게 나옵니다.
"인가되지 않은 소프트웨어가 ECU에 설치되지 않도록 해야 한다"
중요한 건, 이 문장에 Secure Boot, RSA, HSM 같은 구현 기술이 전혀 등장하지 않는다는 점입니다. Goal은 무엇을 달성해야 하는가만 정의합니다.
"RSA-2048 기반 Secure Boot를 적용해야 한다" — 이건 Goal이 아닙니다. 이미 구현 방법이 들어갔습니다.
Cybersecurity Requirement — 구현을 지시하는 단계
여기서부터 구현 레벨로 내려옵니다. Requirement는 "Goal을 달성하기 위해 ECU가 무엇을 해야 하는가"입니다. Goal을 기술 요구사항으로 분해한 결과물입니다.
같은 OTA 예시로 보면
이 Goal에서 다음과 같은 Requirement들이 도출됩니다.
| 번호 | Cybersecurity Requirement | 테스트 가능 여부 |
|---|---|---|
| REQ-01 | ECU는 부팅 시 소프트웨어 디지털 서명을 검증해야 한다 | ✅ 검증 가능 |
| REQ-02 | ECU는 OEM 공개키를 HSM 내부에 저장해야 한다 | ✅ 검증 가능 |
| REQ-03 | 서명 검증 실패 시 부팅을 중단하고 오류 로그를 기록해야 한다 | ✅ 검증 가능 |
| REQ-04 | Anti-Rollback 카운터 검증을 수행해야 한다 | ✅ 검증 가능 |
이제 개발팀이 구현하고 테스트팀이 검증할 수 있는 수준이 됩니다.
Security Claim — 충족을 입증하는 단계
여기서 가장 많이 혼동됩니다. Claim은 Requirement가 아닙니다.
Claim은 "우리가 보안 목표를 실제로 달성했다고 주장하는 내용"입니다. 그리고 Claim에는 반드시 Evidence(근거)가 필요합니다.
왜 Claim이 필요한가
자동차 보안은 규제 산업입니다. 단순히 "Secure Boot 구현했어요"로 끝나지 않습니다. OEM, VTA, Auditor는 반드시 묻습니다.
그래서 등장하는 게 Claim + Evidence 구조입니다.
Claim과 Evidence의 실제 형태
"이 ECU는 인증되지 않은 소프트웨어의 실행을 방지한다"
이 Claim을 뒷받침하는 Evidence는 다음과 같이 구성됩니다.
"우리는 안전하다"가 아니라,
"이 Evidence들이 있기 때문에 우리는 안전하다고 말할 수 있다"입니다.
세 개념 비교 — 한눈에 정리
| 구분 | 핵심 질문 | 포함 내용 | 작성 시점 |
|---|---|---|---|
| Cybersecurity Goal | 무엇을 보호할 것인가? | 보호 대상, 보호 목적 (구현 기술 ❌) |
TARA 완료 후 |
| Cybersecurity Requirement | ECU가 무엇을 해야 하는가? | 기술 요구사항 (테스트 가능해야 함) |
Concept Phase |
| Security Claim | 충족됐다고 어떻게 증명하는가? | 주장 + Evidence (근거 없으면 무효) |
Validation 완료 후 |
자주 나오는 실수 4가지
"RSA-2048 기반 Secure Boot를 적용해야 한다"
이건 Goal이 아니라 Requirement입니다.
"인가되지 않은 소프트웨어 실행을 방지해야 한다"
구현 기술 없이 보호 목적만 명시했습니다.
"ECU는 충분히 안전해야 한다"
이건 테스트 기준이 없습니다.
"서명 검증 실패 시 부팅을 중단하고 오류 로그를 기록해야 한다"
조건과 결과가 명확합니다.
ISO 21434가 이 구조를 요구하는 이유 — Traceability
ISO 21434는 단순 기술 표준이 아닙니다. 핵심은 하나입니다.
그래서 Goal, Requirement, Test, Claim이 서로 연결되어야 합니다.
시나리오
목표
요구사항
케이스
입증
이를 Bidirectional Traceability(양방향 추적성)라고 합니다. Requirement가 바뀌면 연결된 Test Case와 Claim도 영향을 받습니다. 이 연결이 끊어지면 형식승인에서 문제가 됩니다.
현업에서는 이렇게 경험한다
현업 경험 4가지
마무리
자동차 보안 개발은 보안 기능을 추가하는 작업이 아닙니다.
왜 필요한지 설명하고,
무엇을 해야 하는지 정의하고,
그 결과를 증명하는 과정입니다.
Goal은 방향을 만들고, Requirement는 ECU를 움직이며, Claim은 그 결과를 입증합니다.
그리고 ISO 21434는 이 전체 연결 구조—TARA → Goal → Requirement → Test → Claim—가 끊어지지 않고 이어져 있을 것을 요구하는 표준입니다.
'차량 사이버보안 > ISO21434 실무' 카테고리의 다른 글
| 왜 차량 사이버보안은 결국 “문서 싸움”이 될까?— Secure Boot보다 더 중요한 건 “설명할 수 있는가”다 (0) | 2026.05.20 |
|---|---|
| “HW는 같은데 SW만 조금 달라요” — TARA랑 보안 시험 다시 해야 하나? (0) | 2026.05.20 |
| 차량 보안 테스트는 왜 이렇게 끝이 없을까?— ISO 21434 Clause 11이 말하는 “검증”의 진짜 의미 (0) | 2026.05.19 |
| TARA의 대상은 ECU만일까? — 자동차 보안이 시스템 전체를 보기 시작한 이유 (0) | 2026.05.15 |
| 양산 이후 차량 보안은 어떻게 유지될까? — Clause 12~15 (0) | 2026.05.15 |