TARA 결과는 실제로 어떻게 Security Requirement로 연결될까?

자동차 사이버보안 규제 이야기 06

이전 편 | TARA는 실제로 어떻게 수행할까?

지난 글에서 TARA가 어떻게 수행되는지 살펴봤습니다.
위협 시나리오를 도출하고, 영향도와 공격 가능성을 평가하고,
위험도를 결정하는 것까지는 이해가 됐을 겁니다.

그런데 실제 현장에서 더 많이 받는 질문이 있습니다.
"TARA 결과가 나왔어요. 그다음에 뭘 하면 되죠?"

TARA는 분석으로 끝나는 게 아닙니다.
그 결과가 보안 목표가 되고, 보안 요구사항이 되고,
결국 Secure Boot·SecOC·게이트웨이 같은 실제 기술 구현으로 이어집니다.

이 연결 고리를 모르면 TARA를 해도 의미가 절반입니다.

TARA에서 구현까지 — 전체 연결 구조

먼저 큰 그림을 봐야 합니다. TARA 결과는 한 번에 구현으로 가지 않습니다. 중간에 두 단계를 거칩니다.

TARA → 구현 전체 연결 흐름

🔍

TARA — 위협 시나리오 + 위험도 "OTA 패키지 변조 공격 — 위험도 심각 — 경감 필요"

↓

🎯

사이버보안 목표 (Cybersecurity Goal) "OTA 업데이트 패키지의 무결성과 진본성을 보장해야 한다"

↓

📋

사이버보안 요구사항 (Cybersecurity Requirement) "TCU는 OTA 패키지 설치 전 OEM 공개키로 디지털 서명을 검증해야 한다"

↓

⚙️

보안 설계 및 구현 코드 서명 검증 로직, HSM 키 저장, 안티 롤백 카운터 구현

↓

✅

검증 (V&V) 변조된 패키지 설치 시도 → 거부 확인, Penetration Test 수행

이 흐름에서 핵심은 각 단계가 이전 단계의 근거로 연결된다는 점입니다. "왜 코드 서명을 구현했나" → 요구사항 때문. "왜 그 요구사항이 나왔나" → 목표 때문. "왜 그 목표가 생겼나" → TARA의 위협 시나리오 때문. 이 연결이 끊기면 추적성이 없는 것입니다.

사이버보안 목표 vs 사이버보안 요구사항 — 뭐가 다른가

처음 접하면 "목표"와 "요구사항"이 같은 말처럼 느껴집니다. 하지만 이 둘은 명확히 다른 역할을 합니다.

사이버보안 목표(Goal)는 "무엇을 달성해야 하는가"를 선언하는 것입니다. 기술에 독립적입니다. 어떤 방법을 쓸지는 아직 결정하지 않습니다.

사이버보안 요구사항(Requirement)은 "어떻게 달성할 것인가"를 구체적으로 정의하는 것입니다. 시스템·컴포넌트 수준으로 내려가고, 검증 가능한 형태여야 합니다.

자동차 요구사항 문서에서 자주 보이는 "shall"이라는 표현이 있습니다. "The ECU shall verify the digital signature before execution." 이 표현은 단순한 문체가 아닙니다. ISO/IEC 표준에서 "shall"은 반드시 충족해야 하는 의무 요구사항을 의미합니다. "should"는 권고, "may"는 선택입니다. 요구사항 문서에서 이 세 단어의 차이는 개발 우선순위와 심사 기준에 직결됩니다.

예시 1 OTA 공격 대응

🎯 사이버보안 목표

OTA 업데이트 패키지의 무결성과 진본성이 보장되어야 한다

→

📋 사이버보안 요구사항

TCU는 패키지 설치 전 OEM 공개키로 디지털 서명을 검증해야 한다

검증 실패 시 설치를 중단하고 오류를 기록해야 한다

서명 검증용 키는 HSM에 저장되어야 한다

현재 버전보다 낮은 버전의 설치를 거부해야 한다

예시 2 CAN 버스 메시지 주입 대응

🎯 사이버보안 목표

인포테인먼트 도메인에서 파워트레인 도메인으로의 비인가 메시지 전달이 차단되어야 한다

→

📋 사이버보안 요구사항

게이트웨이는 허용된 CAN ID 목록(화이트리스트)만 도메인 간 전달해야 한다

안전 관련 ECU로 향하는 메시지는 SecOC MAC 검증을 통과해야 한다

비정상 메시지 탐지 시 로그를 기록하고 게이트웨이 관리자에게 통보해야 한다

예시 3 Secure Boot — 부팅 무결성

🎯 사이버보안 목표

ECU는 신뢰할 수 있는 소프트웨어만 실행해야 한다

→

📋 사이버보안 요구사항

ECU는 부팅 시 Boot ROM → BL1 → BL2 → Application 순서로 각 단계의 서명을 검증해야 한다

서명 검증 실패 시 부팅을 중단하거나 Fallback 파티션으로 복구해야 한다

양산 단계에서 디버그 포트(JTAG/SWD)는 비활성화되어야 한다

좋은 요구사항의 조건은 세 가지입니다. 첫째, 검증 가능해야 합니다. "보안이 강해야 한다"는 요구사항이 아닙니다. 둘째, 모호하지 않아야 합니다. 읽는 사람마다 다르게 해석하면 안 됩니다. 셋째, 어느 위협 시나리오에서 나왔는지 추적 가능해야 합니다.

요구사항은 계층 구조를 가진다

사이버보안 요구사항은 하나의 레벨로 끝나지 않습니다. 차량 시스템 수준의 요구사항이 ECU 수준으로, ECU 수준이 소프트웨어 모듈 수준으로 점점 구체화됩니다.

사이버보안 목표 (Goal) OTA 패키지의 무결성과 진본성이 보장되어야 한다

시스템 수준 요구사항 차량 OTA 시스템은 서명 검증 없이 펌웨어를 설치해서는 안 된다

ECU 수준 요구사항 (TCU) TCU는 수신된 패키지의 SHA-256 해시와 ECDSA 서명을 검증해야 한다

소프트웨어 수준 요구사항 서명 검증 모듈은 검증 실패 시 에러 코드를 반환하고 설치 프로세스를 종료해야 한다

하드웨어 수준 요구사항 OEM 공개키는 HSM의 보호 영역에 저장되어야 하며 외부에서 읽기가 불가능해야 한다

이 계층 구조 덕분에 OEM은 상위 목표를 정의하고, Tier-1은 ECU 수준 요구사항을 맡고, Tier-1 내 소프트웨어 팀은 모듈 수준 요구사항을 구현합니다. 각자의 책임 범위가 명확해집니다.

추적성(Traceability) — 연결이 끊기면 모든 게 무너진다

TARA에서 구현까지의 연결을 추적할 수 있어야 합니다. 이것이 추적성(Traceability)입니다. 단순히 문서를 많이 만드는 게 아닙니다. 각 항목이 무엇에서 나왔고, 어디로 이어지는지를 연결하는 것입니다.

위협 시나리오	사이버보안 목표	요구사항 ID	구현	검증 결과
TS-01: OTA 패키지 변조	OTA 무결성·진본성 보장	CSR-001	코드 서명 검증 모듈	통과
TS-01: OTA 패키지 변조	OTA 무결성·진본성 보장	CSR-002	HSM 키 저장	통과
TS-01: OTA 패키지 변조	OTA 무결성·진본성 보장	CSR-003	안티 롤백 카운터	미완
TS-03: CAN 메시지 주입	도메인 간 비인가 메시지 차단	CSR-011	게이트웨이 화이트리스트 필터	통과
TS-03: CAN 메시지 주입	도메인 간 비인가 메시지 차단	CSR-012	SecOC MAC 검증	통과

이 추적성 테이블 하나로 "TS-01 위협에 대해 CSR-003이 아직 미완이다"라는 것이 즉시 보입니다. 양산 전 어떤 보안 활동이 남아 있는지, 어떤 요구사항이 검증됐는지를 한눈에 파악할 수 있습니다.

추적성이 없으면 이런 일이 생깁니다. 개발 중 시스템이 변경됐는데 관련 요구사항이 업데이트되지 않습니다. 검증이 완료됐다고 표시됐지만 실제로는 어느 요구사항을 검증한 건지 불분명합니다. OEM 심사에서 "이 요구사항은 어느 위협에서 나왔습니까?"라는 질문에 답하지 못합니다.

목표·요구사항 작성에서 자주 하는 실수들

• ⚠️
  요구사항을 목표처럼 쓴다 "시스템은 안전해야 한다"는 요구사항이 아닙니다. 검증할 수 없습니다. "시스템은 서명 검증 실패 시 부팅을 중단해야 한다"처럼 구체적이고 측정 가능해야 합니다.
• ⚠️
  TARA와 연결되지 않은 요구사항을 추가한다 "업계 모범 사례니까" 또는 "다른 프로젝트에서 썼으니까"라는 이유로 요구사항을 추가하면 추적성이 깨집니다. 모든 요구사항은 위협 시나리오나 규제 요건에 연결되어야 합니다.
• ⚠️
  요구사항이 구현 방법을 과도하게 제약한다 "SHA-256을 사용해야 한다"처럼 구현 방법을 요구사항에 고정하면 기술이 바뀔 때 요구사항 전체를 바꿔야 합니다. "NIST가 승인한 해시 알고리즘을 사용해야 한다"처럼 원칙을 명시하는 편이 낫습니다.
• ⚠️
  시스템 변경 시 요구사항을 업데이트하지 않는다 새로운 인터페이스가 추가됐는데 관련 TARA와 요구사항이 업데이트되지 않으면, 그 인터페이스는 분석되지 않은 채로 양산됩니다. 요구사항 관리는 개발이 끝날 때까지 계속됩니다.

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

목표와 요구사항 작성이 처음엔 가장 어렵다 — TARA까지는 어떻게든 하는데, 목표와 요구사항으로 전환하는 단계에서 막히는 경우가 많습니다. "무엇을 어느 수준으로 명시해야 하는가"의 기준이 처음에는 불분명하기 때문입니다. OEM의 기존 요구사항 예시를 참고하거나, 21434 Annex의 예시를 활용하는 것이 실질적으로 도움이 됩니다.

추적성 관리 도구가 없으면 엑셀이 한계에 부딪힌다 — 초반에는 엑셀로 추적성을 관리합니다. 하지만 요구사항이 수십~수백 개로 늘어나고, 시스템이 변경되면 엑셀 관리는 금방 한계에 부딪힙니다. DOORS, Polarion, Jama 같은 요구사항 관리 도구를 도입하는 이유입니다. 툴 도입 시점을 너무 늦추면 나중에 마이그레이션 비용이 큽니다.

OEM마다 요구사항 형식이 다르다 — "shall", "should", "may" 같은 표현의 강도 구분, ID 체계, 계층 구조 형식이 OEM마다 다릅니다. 한 Tier-1이 여러 OEM을 동시에 대응하는 경우 형식 변환 작업이 상당한 공수를 차지합니다. 초기에 OEM의 템플릿을 받아서 그에 맞게 작성하는 게 재작업을 줄이는 방법입니다.

요구사항이 검증 계획으로 이어지는지 확인해야 한다 — 요구사항을 작성할 때부터 "이것을 어떻게 검증할 것인가"를 함께 생각해야 합니다. 검증 방법이 없는 요구사항은 결국 V&V 단계에서 문제가 됩니다. "HSM에 키가 저장되어야 한다"는 요구사항이라면, "HSM 외부에서 키 읽기 시도 시 실패를 확인하는 테스트"가 검증 방법으로 정의돼야 합니다.

마무리

TARA 결과가 나왔다고 보안이 완성되는 게 아닙니다. 그 결과가 목표로, 목표가 요구사항으로, 요구사항이 설계로, 설계가 구현으로, 구현이 검증으로 이어지는 전 과정이 추적 가능하게 연결돼야 합니다.

좋은 보안 요구사항은 두 방향으로 답할 수 있어야 합니다.
"왜 이 요구사항이 있는가" — TARA 위협 시나리오로 거슬러 올라갈 수 있어야 합니다.
"이 요구사항이 충족됐는가" — 검증 결과로 확인할 수 있어야 합니다.

이 두 방향의 연결이 살아있는 요구사항이 진짜 보안의 기반입니다.

핵심 요약

• TARA → 사이버보안 목표 → 요구사항 → 설계·구현 → 검증, 이 흐름이 끊기지 않아야 한다
• 목표는 "무엇을 달성해야 하는가" (기술 독립적), 요구사항은 "어떻게 달성할 것인가" (구체적·검증 가능)
• 요구사항은 시스템 → ECU → SW/HW 수준으로 계층화된다
• 추적성 테이블로 위협→목표→요구사항→구현→검증이 한눈에 보여야 한다
• 자주 하는 실수: 목표처럼 쓰는 요구사항, TARA와 연결 안 된 요구사항, 시스템 변경 시 미업데이트
• 요구사항 작성 시부터 검증 방법을 함께 정의해야 V&V 단계에서 문제가 없다

이 시리즈

1

자동차는 언제부터 '보안'을 고민하게 됐을까?

2

UNECE R155 쉽게 이해하기

3

CSMS는 실제로 무엇을 관리할까

4

ISO/SAE 21434는 왜 자동차 개발 프로세스를 바꿨을까?

5

TARA는 실제로 어떻게 수행할까?

6

TARA 결과는 실제로 어떻게 Security Requirement로 연결될까?  ← 현재 글

SecurityRequirement TARA ISO21434 차량사이버보안 추적성 보안요구사항 CybersecurityGoal 자동차보안개발 UNECE_R155 Traceability