"ECU 하나 분석하는 작업"
"취약점 찾아서 문서로 정리하는 것"
"보안팀이 만드는 보고서"
하지만 최근 자동차 업계 흐름은 다르게 움직이고 있습니다.
OEM들은 ECU 하나가 아니라 차량 전체 시스템(Vehicle Level)을 보기 시작했습니다.
그리고 범위는 차량 내부를 넘어 Cloud, Backend, Mobile App까지 확장되고 있습니다.
왜 이런 변화가 생겼을까요?
TARA는 결과물이 아니라 방법론이다
실무에서 종종 이런 표현을 듣습니다. "TARA 결과 주세요", "TARA 문서 완료됐나요?", "TARA 몇 개 나왔나요?" 물론 틀린 말은 아닙니다. 하지만 TARA의 본질을 놓치는 표현이기도 합니다.
TARA(Threat Analysis and Risk Assessment)는 특정 문서 하나가 아니라, 위협과 위험을 체계적으로 분석하는 방법론(Methodology)입니다. 무엇을 보호해야 하는지(Asset), 어떤 공격 경로가 존재하는지(Attack Path), 공격 성공 시 어떤 영향이 있는지(Impact)를 분석하는 과정 자체가 핵심입니다.
ISO/SAE 21434에서도 TARA는 단순 체크리스트가 아닙니다. 같은 차량이라도 OEM마다 TARA 결과가 달라질 수 있습니다. 사용하는 방법론, 가정(Assumption), Attack Feasibility 평가 기준이 다르기 때문입니다.
TARA는 "완성된 문서"가 목표가 아닙니다. 차량 시스템의 위험을 이해하고, 그 이해를 바탕으로 보안 목표와 요구사항을 정의하는 것이 목표입니다. 문서는 그 과정의 증거입니다.
과거에는 왜 ECU 단위 TARA가 많았나
초기 차량 보안에서 ECU 단위 분석이 일반적이었던 데는 이유가 있습니다. 당시 차량은 외부와 연결되는 인터페이스 자체가 적었기 때문입니다.
항목
과거 차량 구조
외부 연결
OBD 포트 정도 — OTA·Cloud·Mobile 연계 거의 없음
ECU 간 통신
CAN 버스 중심 — 단순 메시지 교환
공격 표면
물리 접근 중심 — 원격 공격 가능성 낮음
보안 관점
특정 ECU 보호 = 보안 완성으로 인식
이 구조에서는 "어떤 ECU를 보호하는가"가 보안의 핵심처럼 보였습니다. 그래서 Engine ECU, Gateway ECU처럼 ECU 단위로 분석하는 방식이 자연스럽게 자리잡았습니다.
공격은 ECU 하나에서 끝나지 않는다
문제는 실제 공격이 ECU 하나에서 멈추지 않는다는 것입니다. 공격자는 ECU 자체가 아니라 최종적으로 차량 기능을 목표로 합니다.
실제 공격 경로 예시 — ECU 하나가 아닌 시스템 전체 이동
원격 공격 경로
Cellular / Wi-Fi 진입점
→
TCU 침해 거점 확보
→
Gateway 우회 내부 이동
→
차량 기능 제어 최종 목표
Cloud 경유 공격 경로
Mobile App 취약점 진입점
→
Cloud Backend 침해 서버 장악
→
OTA 악용 차량 전달
→
Fleet 전체 공격 대규모 피해
두 번째 시나리오가 더 위험한 이유가 있습니다. Cloud Backend 하나가 침해되면 그 OEM의 모든 차량이 동시에 공격 대상이 됩니다. 개별 ECU 보안이 아무리 강해도, Cloud 인증이 무너지면 Fleet 전체가 노출됩니다.
즉, 개별 ECU만 보면 실제 공격 흐름을 놓칩니다. 그래서 최근 OEM들은 Attack Path 기반 TARA를 점점 더 중요하게 보기 시작했습니다.
ECU 단위 TARA vs Vehicle Level TARA — 무엇이 달라지는가
ECU 단위 TARA
개별 ECU를 분석 단위로 설정
ECU 내부 자산 중심
단일 ECU 영향 분석
차량 내부 인터페이스 한정
Tier-1이 개별 수행
Vehicle Level TARA
차량 기능(Function)을 분석 단위로
Cross-domain 공격 경로 추적
Fleet 전체 영향 분석
Cloud·Backend·App 포함
OEM 주도, Tier-1 협업
관점
ECU 단위 TARA
Vehicle Level TARA
분석 대상
특정 ECU
차량 기능 전체
위협 범위
ECU 내부 위협
End-to-End 공격 경로
피해 분석
ECU 단위 영향
Fleet 전체·사회적 영향
경계
차량 내부
Cloud·Mobile·Backend 포함
책임 주체
Tier-1
OEM 주도 + Tier-1·Cloud 협업
실제로 어떻게 달라지는가 — Remote Parking 예시
Vehicle Level TARA가 실제로 어떻게 다른지, Remote Parking 기능을 예시로 보겠습니다.
REMOTE PARKING — Vehicle Level TARA 관점의 분석 범위
Mobile App 인증·세션
→
Cloud Backend API·인증서
→
TCU 명령 수신
→
Gateway 필터링
→
Brake·Steering 최종 제어
ECU 단위 TARA라면 Brake ECU, Steering ECU만 분석했을 것입니다. 하지만 Vehicle Level TARA에서는 전혀 다른 질문들이 추가됩니다.
Mobile
App
Mobile App 인증이 취약하면?
앱 인증 우회로 타인의 차량에 Remote Parking 명령 가능. 세션 탈취, 재전송 공격 포함. App 자체는 차량 팀 범위가 아니었지만 이제 TARA 대상이 됩니다.
Cloud
Backend
Cloud API가 침해되면?
서버 하나 침해 = Fleet 전체 공격 가능. 인증서 관리 오류, API 권한 과다 부여, Backend 접근 통제 실패가 모두 TARA 대상입니다.
OTA
설정
OTA로 Parking 설정이 변경되면?
악성 OTA로 Remote Parking 동작 범위가 변경될 수 있습니다. OTA 서명 검증 실패, Anti-Rollback 부재가 이 공격의 출발점입니다.
Fleet
영향
공격 성공 시 피해는 얼마나 되는가?
단일 차량 → Fleet 전체로 확산 가능성. 대규모 Safety 사고, 리콜, 규제 제재까지 이어질 수 있습니다. Damage Scenario가 완전히 달라집니다.
이제 자동차 보안의 경계는 차량 내부에서 끝나지 않습니다. Remote 기능 하나가 Mobile App → Cloud → OTA → ECU 전체 체인을 연결합니다. 이 체인 중 하나라도 약하면 차량 제어까지 영향이 갑니다.
Vehicle Level TARA가 어려운 이유 — 범위 정의 자체가 어렵다
Vehicle Level TARA가 확산되면서 새로운 고민도 생기고 있습니다. 무엇보다 "어디까지를 분석 범위로 볼 것인가"가 어렵습니다.
Vehicle Level TARA — 조직 간 역할 경계 문제
OEM 차량팀
ECU 보안, Gateway, 차량 내부 네트워크까지는 명확. 하지만 Cloud·App까지 어디까지 책임지는가?
OEM Cloud팀
Backend API, 인증서, 서버 보안은 담당. 그런데 차량 TARA에 어떻게 참여해야 하는가?
Tier-1
ECU 단위 TARA는 수행. 하지만 OEM Cloud 보안까지 분석 범위에 포함해야 하는가?
공통 과제
Mobile App, Fleet 운영 서버, Backend PKI — 차량 TARA에 포함되는가, 별도인가? OEM 내부에서도 기준이 다른 경우가 많습니다.
Vehicle Level TARA가 어려운 이유는 단순히 분석 대상이 많아서가 아닙니다. 시스템 경계(System Boundary) 자체가 계속 커지고 있고, 그 경계를 누가 어떻게 정의하는가에 대한 기준이 아직 명확하지 않기 때문입니다.
현장에서 자주 마주치는 오해들
흔한 오해
"TARA는 ECU별로 각각 수행하면 된다" — ECU 단위 분석을 모두 합치면 Vehicle Level이 된다는 생각
실제로는
Cross-domain 공격 경로는 ECU별 분석을 합쳐도 보이지 않음. Vehicle Level에서 기능 중심으로 봐야 전체 공격 흐름이 식별됨
흔한 오해
"Cloud는 IT팀 담당이니 차량 TARA와 별개다" — 차량과 Cloud를 분리해서 관리
실제로는
Cloud Backend 침해 = 차량 Fleet 전체 영향. OTA·Remote 기능이 있으면 Cloud는 차량 TARA 범위에 포함되어야 함
흔한 오해
"TARA는 한 번 하면 끝이다" — 개발 단계에서 수행한 TARA가 운영 내내 유효하다는 생각
실제로는
새로운 기능 추가, 인터페이스 변경, 새 공격 기법 등장 시 TARA 업데이트 필요. Clause 8에서 지속 활동으로 요구됨
흔한 오해
"TARA = 취약점 분석" — 현재 있는 취약점을 찾는 작업이라는 생각
실제로는
TARA는 미래 위협을 예측하고 보안 목표를 정의하는 작업. 취약점 분석(Vulnerability Analysis)은 Clause 11 검증 단계에서 수행
TARA는 어디로 가고 있는가
자동차 산업은 지금 "ECU 보안"에서 "시스템 보안"으로 이동하고 있습니다. 그리고 TARA의 범위도 함께 확장되고 있습니다.
TARA 범위 확장 흐름
ECU 단위 개별 분석
→
Domain 단위 Powertrain·Body
→
Vehicle 단위 기능 중심
→
End-to-End Cloud 포함
단계
분석 범위
현재 업계 수준
ECU 단위
개별 ECU 내부
Tier-1 일반화
Domain 단위
Powertrain·Body·Chassis 도메인
대형 OEM 적용 중
Vehicle 단위
차량 기능 + 내부 네트워크 전체
선도 OEM 요구 시작
End-to-End
Cloud·Mobile·Backend 포함
SDV 전환 OEM 도입 중
앞으로의 TARA는 "어떤 ECU가 위험한가"보다 "차량 시스템 전체에서 어떤 공격 경로가 존재하는가"를 더 중요하게 보게 될 것입니다. 그리고 그 경로는 이미 차량 밖 Cloud와 Mobile까지 연결되어 있습니다.
현업에서는 실제로 이렇게 경험한다
OEM마다 TARA 방법론이 달라서 Tier-1이 가장 힘들다 — 같은 ECU를 납품하는데 OEM A는 Risk Matrix 방식, OEM B는 Attack Feasibility 중심, OEM C는 STRIDE 기반을 요구합니다. Tier-1 입장에서 프로젝트마다 TARA 방식을 맞춰야 하는 현실적 어려움이 있습니다.
Vehicle Level TARA를 수행하려면 Cloud팀과의 협업이 필수인데 그게 어렵다 — 차량팀과 Cloud팀은 조직 문화, 개발 주기, 보안 기준이 다릅니다. Vehicle Level TARA를 제대로 하려면 두 조직이 함께 앉아 공격 경로를 추적해야 하는데, 이 협업 자체가 현실적으로 가장 어려운 과제 중 하나입니다.
Attack Path를 끝까지 추적하다 보면 범위가 계속 늘어난다 — "이 ECU에서 저 ECU로 이동 가능하다"를 따라가다 보면 어느 순간 Cloud Backend까지 도달합니다. 그리고 "Backend는 우리 범위가 아니다"는 경계 논쟁이 시작됩니다. 범위 합의가 TARA 시작 전에 반드시 이루어져야 합니다.
Fleet 영향 분석이 새로운 숙제가 됐다 — 과거에는 "이 ECU가 공격받으면 차량 1대에 영향"이었습니다. 이제는 "이 Cloud API가 침해되면 Fleet 수십만 대에 동시 영향"이 가능합니다. Damage Scenario를 Fleet 단위로 산정하는 방식이 점점 중요해지고 있습니다.
마무리
TARA는 문서가 아닙니다.
ECU 하나만 분석하는 작업도 아닙니다.
차량 시스템 전체의 위험을 이해하기 위한 방법론입니다.
그리고 그 시스템은 이미 도로 위 차량을 넘어
Cloud, Mobile, Fleet 전체로 확장됐습니다.
자동차 보안은 이제 "특정 ECU를 얼마나 잘 보호하는가"를 넘어, "차량과 연결된 시스템 전체를 어떻게 신뢰할 수 있는 구조로 만드는가"의 문제로 이동하고 있습니다.
Vehicle Level TARA는 그 변화의 출발점입니다.
핵심 요약
TARA는 결과물이 아니라 위협과 위험을 분석하는 방법론(Methodology)이다
과거 ECU 단위 TARA는 외부 연결이 적던 시대에 맞는 방식이었다
실제 공격은 ECU 하나가 아니라 시스템 전체 경로를 따라 이동한다
Cloud Backend 침해 = Fleet 전체 동시 영향 — ECU 단위 분석으로는 이 위험을 볼 수 없다
Vehicle Level TARA는 차량 기능 중심으로 Cloud·Mobile·Backend까지 범위를 확장한다
Remote Parking 하나만 봐도 App·Cloud·OTA·Gateway·ECU 전체 체인이 분석 대상이 된다
Vehicle Level TARA의 가장 큰 어려움은 시스템 경계(Boundary) 정의와 조직 간 협업이다
OEM마다 TARA 방법론이 달라 Tier-1은 프로젝트마다 다른 방식에 대응해야 한다
TARA 범위는 ECU → Domain → Vehicle → End-to-End로 확장되고 있다