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

현업에서 보는 ISO/SAE 21434 03

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

자동차 사이버보안을 처음 접하면 보통 이런 생각을 합니다.

"일단 Secure Boot 넣고, 암호화 넣고, HSM 넣으면 되는 거 아닌가?"

하지만 차량마다 위협이 다르고, 공격 경로가 다르고, 보호해야 하는 자산이 다릅니다.
인포테인먼트 ECU와 브레이크 ECU는 같은 보안 수준이 필요하지 않습니다.

그래서 자동차 업계는 "무조건 보안 기능을 넣는 방식"에서
"무엇이 얼마나 위험한지 먼저 분석하는 방식"으로 바뀌었습니다.

그 중심에 있는 것이 바로 TARA(Threat Analysis and Risk Assessment)입니다.
ISO/SAE 21434 Clause 9는 이 TARA를 자동차 보안 개발의 출발점으로 정의합니다.

왜 자동차 업계는 TARA 중심으로 바뀌었을까

과거 자동차 개발에서 보안은 늘 뒤늦게 들어왔습니다. OTA 구조를 다 만든 뒤에야 "서명 검증 필요하네?", "HSM 없어?", "Gateway 분리해야겠는데?" 같은 상황이 발생했습니다.

이미 아키텍처가 확정되고 MCU 선정이 완료된 상태에서 보안 요구사항이 들어오면 수정 비용이 폭발합니다. 21434가 Concept Phase에서 TARA를 먼저 요구하는 이유가 여기 있습니다.

과거 개발 순서

기능 설계 → 구현 → 테스트

출시 직전 보안 검토

보안 = 기능 추가 개념

HW 확정 후 보안 반영 시도

수정 비용 폭발, 일정 지연

21434 이후 개발 순서

위협 분석 → 보안 목표 정의

Concept 단계에서 Risk 파악

보안 = 설계 출발점

TARA 결과로 HW·SW 결정

앞단에서 발견 = 수정 비용 최소화

21434 Clause 9의 핵심 철학은 이것입니다. 위협을 먼저 이해하고, 그 결과로 설계하라. 보안 기술은 목적이 아니라 수단입니다. 무엇을 막아야 하는지 모르면 무엇을 넣어야 하는지도 알 수 없습니다.

TARA — 8단계로 이해하는 전체 흐름

자동차 업계마다 세부 방법론은 다르지만, TARA는 대체로 다음 순서로 진행됩니다.

1

Item Definition — 분석 대상 정의

무엇을 분석할지 먼저 정의합니다. Gateway ECU, BMS, OTA 시스템, ADAS ECU, 차량 클라우드 플랫폼 등 범위를 명확히 합니다. 범위가 불명확하면 이후 모든 분석이 흔들립니다.

2

Asset Identification — 보호 대상 식별

무엇을 보호해야 하는지 정의합니다. 기능 중심이 아니라 공격자 관점으로 "무엇이 가장 중요한 자산인가"를 먼저 봅니다.

3

Threat Scenario — 위협 시나리오 정의

어떤 공격이 가능한지 정의합니다. OBD 진단 악용, OTA 패키지 위변조, BLE 인증 우회, CAN Injection, Gateway 우회, Debug Port 악용 등.

4

Damage Scenario — 피해 시나리오 분석

공격 성공 시 어떤 피해가 발생하는지 분석합니다. Safety·Financial·Privacy·Operational·Regulatory 관점으로 구분합니다.

5

Attack Path Analysis — 공격 경로 분석

공격자가 실제로 어떻게 시스템에 침투하는지 경로를 분석합니다. ECU 단위가 아니라 여러 시스템을 연결하는 전체 경로를 봐야 합니다.

6

Attack Feasibility — 공격 가능성 평가

공격이 얼마나 현실적으로 가능한지 평가합니다. 난이도, 필요 장비, 소요 시간, 전문성, 물리 접근 필요 여부 등을 기준으로 판단합니다.

7

Risk Assessment — 위험도 평가

공격 가능성과 피해 규모를 종합해 Risk Level(High/Medium/Low)을 산출합니다. 이 결과가 보안 대응 우선순위를 결정합니다.

8

Security Goal 도출 — 보안 목표 정의

위험 평가 결과를 바탕으로 "무엇을 막아야 하는가"를 명확히 정의합니다. 이후 Security Requirement와 Secure Architecture의 출발점이 됩니다.

Asset Identification — 공격자 관점으로 보기 시작하다

TARA에서 가장 중요한 관점 전환이 일어나는 단계가 Asset Identification입니다. 기존 자동차 개발이 "기능이 동작하는가"를 물었다면, TARA는 "무엇이 가장 중요한 자산인가"를 먼저 묻습니다.

Asset	보호 이유	피해 유형
브레이크 제어 신호	오동작 시 인명 피해 직결	Safety
OTA 인증 키	탈취 시 악성 펌웨어 설치 가능	Safety Operational
차량 위치·주행 정보	개인정보 침해, 도난 활용	Privacy
CAN 통신 무결성	메시지 위변조로 제어 오동작	Safety
진단 인증 정보	불법 접근으로 주행 거리 조작 등	Financial
Debug Interface	양산 후 노출 시 시스템 전체 침해	Safety Regulatory

자동차는 단순 정보 시스템이 아닙니다. 공격 성공 시 사람의 안전, 물리 제어, 실제 주행까지 연결됩니다. 그래서 자동차 TARA는 IT 보안의 CIA(Confidentiality·Integrity·Availability) 외에 Safety 영향을 별도로 고려합니다.

Attack Path Analysis — 경로 전체를 봐야 한다

과거 자동차 보안은 ECU 단위, 개별 기능 단위로 보안을 검토하는 경우가 많았습니다. 하지만 실제 공격은 ECU 하나를 직접 노리지 않습니다. 여러 시스템을 연결해서 진입점부터 최종 목표까지 이동합니다.

Attack Path 예시 — 원격 브레이크 공격 시나리오

LTE Modem
진입점

→

Telematics ECU
거점 확보

→

Gateway 우회
내부 이동

→

CAN Injection
메시지 위변조

→

브레이크 ECU
최종 목표

이 시나리오에서 브레이크 ECU만 보호해서는 의미가 없습니다. LTE Modem의 취약점, Telematics ECU의 격리, Gateway의 필터링 규칙, CAN 메시지 인증(SecOC)이 모두 연결되어야 합니다. Attack Path Analysis가 중요한 이유입니다.

Attack Feasibility — 같은 취약점도 위험도가 다르다

21434에서는 취약점 존재 여부만이 아니라 공격이 얼마나 현실적으로 가능한지도 평가합니다. 같은 취약점이라도 공격 난이도에 따라 Risk Level이 달라집니다.

Attack Feasibility 평가 기준

평가 항목

OBD 진단 공격

OTA 원격 공격

접근 방식

물리 접근 필요

원격 가능

공격 규모

차량 1대씩

대량 동시 공격 가능

필요 전문성

진단 장비 필요

네트워크 지식

소요 시간

현장 체류 필요

자동화 가능

Feasibility

낮음 (제한적)

높음 (광범위)

OBD 포트 취약점과 OTA 취약점은 기술적 심각도가 같더라도 Attack Feasibility가 다르면 Risk Level이 달라집니다. 원격 대량 공격이 가능한 취약점은 물리 접근이 필요한 취약점보다 훨씬 높은 우선순위로 다뤄져야 합니다.

Security Goal — TARA의 최종 결과물

Risk Assessment를 마치면 가장 중요한 결과물이 나옵니다. Security Goal입니다. "무엇을 막아야 하는가"를 명확하고 검증 가능한 문장으로 정의한 것입니다.

OTA

"비인가 OTA 패키지는 차량에 설치되어서는 안 된다."
→ OTA 서명 검증, 인증서 관리, 롤백 방지가 요구사항으로 이어집니다.

CAN

"브레이크 ECU는 인증되지 않은 CAN 메시지를 수용해서는 안 된다."
→ SecOC 적용, 메시지 인증 코드 요구사항으로 이어집니다.

Debug

"Debug Interface는 양산 이후 비활성화되어야 한다."
→ Secure Boot 단계에서 Debug 잠금, HSM 기반 접근 제어로 이어집니다.

BLE

"차량 스마트키 BLE 통신은 재전송 공격에 대응할 수 있어야 한다."
→ Nonce 기반 인증, 타임스탬프 검증 요구사항으로 이어집니다.

Security Goal이 잘 정의되어야 그 아래 Requirement, Architecture, Implementation이 올바르게 내려갑니다. TARA가 잘못되면 Requirement도 틀리고, Architecture도 틀리고, 검증 방향도 틀어집니다.

Clause 9 결과가 이후 모든 단계의 출발점이 된다

TARA 결과의 흐름 — Clause 9 → Clause 14

Clause 9
TARA

→

Security Goal
보안 목표

→

Clause 10
요구사항·설계

→

Clause 11
검증·PenTest

→

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

TARA 결과는 단순히 문서로 끝나지 않습니다. Security Goal은 Security Requirement가 되고, Requirement는 Secure Architecture로 내려가고, Architecture는 구현과 검증의 기준이 됩니다. 그리고 그 결과가 Cybersecurity Case로 취합되어 VTA 형식승인의 근거가 됩니다.

TARA 없이 개발할 때

개발 막바지에 보안 검토 → "HSM 없어", "SecOC 못 넣어" → MCU 재선정, 일정 지연, 비용 폭발

TARA 먼저 수행할 때

Concept 단계에서 Risk 파악 → HSM·SecOC 필요 여부 결정 → MCU·아키텍처·BOM에 반영

위협 누락이 생길 때

OBD 공격만 분석 → OTA 경로 누락 → 원격 대량 공격 가능한 취약점 방치

공격 표면 전체를 볼 때

인터페이스 전체 분석 → Attack Path 전체 추적 → 위협 누락 최소화

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

TARA 결과가 HW까지 바꾼다 — TARA 결과에 따라 HSM 필요 여부, Secure Boot 적용 범위, SecOC 대상 메시지, IDS 필요 여부, Gateway 분리 구조까지 결정됩니다. 즉 MCU 선정, 메모리 크기, HW BOM까지 영향을 줍니다. 이것이 Concept 단계에서 TARA를 먼저 해야 하는 진짜 이유입니다.

가장 위험한 건 "위협 누락"이다 — 발견한 위협보다 놓친 위협이 더 위험합니다. 공격 표면 식별, Attack Path 분석, 인터페이스 분석이 중요한 이유입니다. TARA를 수행했어도 공격 경로를 단편적으로 봤다면 실제 위협에 대응하지 못합니다.

OEM마다 TARA 방법론이 다르다 — 21434는 방향만 제시합니다. 실제 Risk Matrix, Attack Feasibility 기준, Rating 방식은 OEM마다 다릅니다. 그래서 Tier-1은 OEM별 TARA 대응 경험이 매우 중요하고, 같은 ECU라도 OEM에 따라 분석 결과가 달라질 수 있습니다.

TARA 문서는 살아있어야 한다 — 처음 작성한 TARA가 개발 내내 그대로 유지되는 경우가 많습니다. 하지만 아키텍처 변경, 인터페이스 추가, 새로운 공격 기법 등장에 따라 TARA도 업데이트되어야 합니다. 정적인 문서가 아니라 개발과 함께 살아가는 분석 결과여야 합니다.

마무리

TARA는 "무엇이 위험한가"를 먼저 이해하는 과정입니다.
자동차 보안이 어디서 시작되는지 알고 싶다면,
TARA가 그 출발점입니다.

자동차 업계가 Secure Boot, HSM, SecOC, IDS, OTA 보안 같은 기술을 넣기 시작한 이유도 결국은 TARA 결과에서 시작됩니다. 기술이 먼저가 아니라, 위협을 이해한 다음에 기술이 선택됩니다.

다음 편에서는 Clause 10을 다룹니다. TARA에서 도출된 Security Goal이 어떻게 Security Requirement가 되고, Secure Architecture와 ECU 구현으로 내려가는지를 살펴봅니다.

핵심 요약

• Clause 9는 Concept Phase를 정의한다 — 개발 초기에 위협을 먼저 이해하는 단계
• 핵심 활동은 TARA — "무엇이 얼마나 위험한가"를 체계적으로 분석하는 과정
• 주요 단계: Item Definition → Asset → Threat → Damage → Attack Path → Feasibility → Risk → Security Goal
• 자동차 보안은 기능 중심 개발에서 Risk 기반 개발로 이동했다
• Attack Path Analysis는 ECU 단위가 아니라 공격 경로 전체를 봐야 한다
• 같은 취약점이라도 Attack Feasibility에 따라 Risk Level이 달라진다
• Security Goal이 TARA의 최종 결과물 — 이후 Requirement·Architecture의 출발점
• TARA 결과에 따라 HSM·SecOC·IDS·Secure Boot 적용 여부까지 결정된다
• 위협 누락이 가장 위험한 실패 중 하나 — 공격 표면 전체를 봐야 한다
• OEM마다 방법론이 다르며, Tier-1은 OEM별 대응 경험이 중요하다

📚 현업에서 보는 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~14

ISO21434 Clause9 TARA ThreatAnalysis RiskAssessment SecurityGoal AttackPath 차량사이버보안 ConceptPhase SecureDesign 자동차규제