AI가 차량에 들어가면 TARA는 어떻게 바뀔까? — 위협 분석·리스크 평가 방법론의 진화

트렌드 — SDV·AI 시대의 자동차 보안

시리즈 전체 구성

1

이전 글

차량 보안과 AI는 어떻게 만날까?

AI Vehicle 시대, 사이버보안 패러다임의 변화

DONE

2

지금 읽는 글

AI가 차량에 들어가면 TARA는 어떻게 바뀔까?

위협 분석·리스크 평가 방법론의 진화

NOW

3

다음 글

ISO/PAS 8800 — AI 차량 시대의 새로운 안전 표준

21434로 부족한 이유, 그 다음은 무엇인가

NEXT

4

예정

Adversarial Attack이 자율주행차를 속이는 방법

스티커 한 장으로 AI를 속일 수 있다면

SOON

TARA 실무자들이 자주 하는 말

"AI 기능도 결국 ECU에 올라가니까 기존 TARA 그대로 쓰면 되는 거 아닌가요?"

"AI 모델은 소프트웨어니까 Secure Boot로 무결성 검증하면 끝 아닌가요?"

"Adversarial Attack은 학술 연구 수준이고 실차 TARA에서 다룰 필요는 없지 않나요?"

"21434 TARA를 잘 수행하면 AI 리스크도 커버된다고 봐도 되지 않나요?"

자동차 사이버보안 프로젝트에서 모든 논의의 출발점은 TARA다.

그런데 지금의 TARA는 사실 하나의 전제 위에 서 있다 — "시스템은 정상 동작한다. 위험은 공격자가 만든다."

AI가 차량에 들어오면 이 전제 자체가 흔들린다.

---

지금의 TARA는 무엇을 전제로 만들어졌는가

ISO/SAE 21434의 TARA는 명확한 구조를 가진다.

ISO/SAE 21434 TARA 기본 구조

Asset
식별

→

Damage
Scenario

→

Threat
Scenario

→

Attack
Path

→

Risk
Evaluation

공격자가 시스템을 변조 또는 접근 → 피해 발생 구조를 전제로 설계된 프레임워크

예를 들어 브레이크 제어 기능을 Asset으로 잡으면, CAN 메시지 위조라는 Threat Scenario가 나오고, 의도치 않은 제동이라는 Damage로 이어지는 식이다.

여기서 TARA 전체를 관통하는 핵심 가정이 하나 있다.

💡 기존 TARA의 암묵적 전제 — "시스템 자체는 정상 동작한다. 위험은 공격자가 시스템을 변조하거나 침투했기 때문에 발생한다."

그래서 TARA의 핵심 질문은 항상 "누가, 어떻게 시스템에 접근했는가"였다. 이 전제 안에서는 현재의 Asset 목록, Threat 카탈로그, Attack Path 방법론이 모두 합리적으로 작동한다.

---

AI 시스템은 정상 동작하면서도 위험할 수 있다

AI Vehicle에서는 상황이 달라진다.

❌ 위험은 반드시 공격자의 개입으로 발생한다

✅ AI는 아무도 공격하지 않아도 잘못된 판단을 내릴 수 있다

ECU는 정상 동작했다. 네트워크도 정상이다. 공격자가 시스템에 접근하지도 않았다. 그런데 AI가 STOP 표지판을 속도 제한 표지판으로 오인식해 위험이 발생했다. 기존 TARA의 전제가 성립하지 않는 상황이다.

이 경우 기존 TARA 프레임워크로는 설명이 어렵다. Threat Scenario가 없는데 Damage가 발생하는 구조이기 때문이다. AI Vehicle에서는 시스템의 정상 동작 자체가 위험의 원인이 될 수 있다.

---

Asset의 정의가 달라진다

기존 TARA에서 Asset은 ECU, 통신 데이터, 진단 기능, 암호키 같은 것들이 중심이었다. AI Vehicle에서는 새로운 자산군이 등장한다.

구분	기존 TARA Asset	AI Vehicle 추가 Asset
소프트웨어	ECU 펌웨어, 애플리케이션 코드	AI 모델 파일 (.bin, .onnx 등)
데이터	CAN 메시지, 진단 데이터	학습 데이터셋, 추론 결과, 센서 입력
파라미터	보안 설정값, 암호키	모델 가중치(weights), 임베딩, 토큰
프로세스	진단 세션, 업데이트 절차	추론 파이프라인, 의사결정 과정
공급망	ECU 공급사, OSS	AI 모델 공급사, 데이터 공급사, 클라우드 학습 환경

특히 AI 모델의 공급망은 기존 OSS 관리와는 성격이 다르다. OEM → AI 모델 공급사 → 데이터 공급사 → 클라우드 학습 환경으로 이어지는 모든 단계가 잠재적 공격 표면이 된다. 학습 데이터가 오염된다면 AI는 출시 전부터 잘못된 판단을 학습한 상태로 차량에 탑재될 수 있다.

---

Threat Scenario 밖에 있는 위협들

기존 TARA의 Threat Scenario는 공격자의 행동을 중심으로 구성된다. 진단 접근 → 보안 우회 → 악성 코드 설치 같은 흐름이다.

AI Vehicle에서는 공격자가 없는 위협 시나리오가 추가된다.

AI Vehicle에서 추가되는 위협 시나리오 유형

1

Model Failure Scenario — 공격 없음. AI 모델이 특정 환경 조건(야간, 악천후, 비정형 도로)에서 정상 입력에 대해 잘못된 판단을 내린다.

2

Adversarial Input Scenario — 물리적 조작(표지판 스티커 부착 등)으로 AI의 센서 입력을 교란. ECU 접근 없이 차량 판단을 바꾼다.

3

Data Poisoning Scenario — 학습 단계에서 훈련 데이터를 오염. 모델이 특정 트리거 조건에서만 오동작하도록 설계된 백도어를 포함한 채 배포된다.

4

Decision Drift Scenario — OTA로 업데이트된 모델이 이전 버전과 다른 판단 패턴을 보인다. 공격이 아닌 업데이트 자체가 리스크 요인이 된다.

⚠️ Adversarial Attack은 학술 연구가 아니다

스티커 몇 장으로 STOP 표지판을 속도 제한 표지판으로 오인식시키는 공격은 이미 여러 연구기관에서 실증됐다. 공격자는 ECU도, CAN도, OTA도 건드리지 않는다. 기존 TARA의 Attack Path 개념으로는 이 공격을 포착하기 어렵다.

---

TARA는 어떻게 확장되어야 할까

아직 업계에 정해진 답은 없다. 하지만 현재 논의되고 있는 방향은 있다.

❌ 기존 TARA 구조에 AI 관련 항목을 추가하면 충분하다

✅ AI 시스템의 특성을 반영한 새로운 분석 레이어가 필요하다

AI는 Rule-Based 시스템이 아니기 때문에 동일한 입력에도 확률적으로 다른 출력이 나올 수 있다. 이 불확실성을 기존의 결정론적 Threat Scenario 구조로 포착하는 데는 구조적 한계가 있다. 위협 분석의 대상이 "시스템의 상태"에서 "AI의 판단 신뢰성"으로 확장되어야 한다.

분석 영역	기존 TARA	AI Vehicle TARA (방향)
핵심 질문	누가 시스템에 접근했는가?	AI가 왜 그런 판단을 했는가?
Asset	ECU, 통신, 암호키	+ AI 모델, 학습 데이터, 추론 결과
Threat 유형	외부 공격자 기반	+ AI 오판단, Data Poisoning, Adversarial Input
Attack Path	ECU/네트워크 침투 경로	+ 센서 입력 교란, 공급망 오염 경로
Risk 기준	CVSS 기반 취약점 심각도	+ AI 판단 오류 빈도, 안전 영향도

---

ISO/SAE 21434 이후 — 새로운 프레임워크들

21434는 AI 모델 자체의 신뢰성 문제를 직접 다루지 않는다. 표준이 설계될 당시의 전제가 Rule-Based 시스템이었기 때문이다. 이 공백을 메우기 위해 여러 프레임워크가 등장하고 있다.

ℹ️ 주목해야 할 AI 관련 프레임워크

• ISO/PAS 8800 — AI 기반 차량의 안전 요구사항. ISO 26262(기능안전)와 21434(사이버보안)의 교차점에서 AI를 다룬다. TARA와의 관계 정립이 앞으로 핵심 논의가 될 것이다.

• NIST AI RMF — AI 시스템의 리스크 관리 프레임워크. Govern / Map / Measure / Manage 4단계 구조로 AI 리스크를 체계화한다.

• EU AI Act — 자율주행을 고위험 AI 시스템으로 분류. 투명성, 설명 가능성, 지속적 모니터링을 요구한다.

---

🔧 현업에서 마주치는 변화들

AI 기능 포함 제어기의 TARA, 기존 위협 카탈로그가 맞지 않는다 — AI 기능이 포함된 제어기에 대한 TARA를 수행하다 보면 기존 위협 카탈로그로는 커버되지 않는 항목들이 생긴다. Adversarial Input이나 Model Poisoning을 어떻게 Threat Scenario로 정의하고 리스크를 수치화할지 아직 업계에 확립된 방법론이 없다.

AI 모델 OTA가 보안 검토 범위에 들어오기 시작했다 — 이전에는 SW 패키지 서명 검증이 OTA 보안의 핵심이었다. 최근에는 AI 모델 파일 자체의 무결성 외에 배포된 모델의 행동 변화까지 보안 검토 범위에 포함해야 하는지 논의가 생기고 있다.

기능안전과 사이버보안의 경계가 흐려지고 있다 — 기존에는 HARA(기능안전)와 TARA(사이버보안)가 비교적 명확하게 구분됐다. AI 차량에서는 AI 오판단이 기능 결함인지 보안 위협인지 경계가 모호해진다. ISO/PAS 8800이 이 교차 영역을 다루려는 이유가 여기 있다.

결국 TARA는 "시스템을 분석하는 방법론"에서 "판단을 분석하는 방법론"으로 진화해야 할 수 있다.

그렇다면 다음 질문이 자연스럽게 나온다 — ISO/PAS 8800은 이 공백을 채울 수 있을까? 아니면 21434를 보완하는 수준에 그칠까?

핵심 요약

1

기존 TARA의 전제가 흔들린다 — "시스템은 정상 동작하고 위험은 공격자가 만든다"는 가정이 AI 시스템에서는 성립하지 않는다.

2

Asset 목록이 확장된다 — AI 모델 파일, 학습 데이터, 추론 결과, 모델 가중치가 새로운 보호 대상이 된다.

3

Threat Scenario 밖의 위협이 존재한다 — Model Failure, Adversarial Input, Data Poisoning은 공격자 없이도 발생하는 위험이다.

4

AI 공급망이 새로운 공격 표면이다 — 데이터 공급사, 클라우드 학습 환경까지 TARA 범위에 포함될 필요가 생긴다.

5

ISO/PAS 8800이 열쇠가 될 수 있다 — 21434가 다루지 못하는 AI 판단 신뢰성 문제를 어떻게 규격화할지가 향후 2~3년 업계의 핵심 논의가 될 것이다.

TARA ISO/SAE 21434 AIVehicle 자동차사이버보안 AdversarialAttack DataPoisoning ISO/PAS8800 Model Security SDV 위협분석 리스크평가