특장차·트레일러도 사이버보안 관리가 필요할까?

현업에서 보는 차량 사이버보안 제도

특장업체에서 자주 듣는 말

"완성차 OEM이 보안 다 하는 거 아닌가요? 우리가 왜 해야 해요?"

"CAN에 ECU 하나 붙이는 건데 그게 무슨 보안 문제야?"

"우리는 특장 기능만 추가하는 거라 R155 해당 없는 거 아닌가요?"

"원격 모니터링 앱 붙이는 건 예전부터 했는데 뭐가 달라진 거죠?"

맞습니다. 특장업체 입장에서는 억울한 면이 있습니다. OEM이 인증받은 차량에 기능만 추가하는 건데, 왜 보안까지 신경써야 하냐는 거죠.

그런데 최근 국토교통부가 발간한 자동차 사이버보안 인증제도 가이드라인에는 이걸 직접 겨냥한 항목이 따로 있습니다.

가이드라인 2.14 — 특장차·피견인차 관련 사이버보안 인터페이스

제작사(특장을 허용하는 제작사거나 트랙터 제작사인 경우)가 특장(2차 제작) 또는 피견인차(트레일러)와의 연동을 위해 자동차 사이버보안에 영향을 미칠 수 있는 통신 기능을 허용하는 경우, 해당 기능은 원제작사가 관리하는 사이버보안 통제가 적용된 전용 인터페이스를 통해 제공되어야 한다.

한 줄로 요약하면 이겁니다.

특장업체가 차량과 연결할 때는
OEM이 통제 가능한 "공식 인터페이스" 안에서만 움직여야 한다.

---

왜 특장차가 보안 문제가 될까

완성차 OEM은 차량 출고 시점에 보안 설계를 완료합니다. TARA도 했고, CSMS도 갖췄습니다. 그런데 특장 작업은 그 이후에 일어납니다. OEM이 보안을 설계한 이후에 새로운 것들이 붙기 시작합니다.

ℹ️ 특장 과정에서 추가되는 것들

별도 ECU 추가  ·  CAN 직접 연결  ·  PTO 연동  ·  원격 제어 기능
작업 모드 ECU  ·  LTE/Wi-Fi 모듈  ·  Cloud 연결  ·  앱 연동

이게 왜 문제냐면 — OEM이 설계한 보안 경계선 밖에서 새로운 연결이 생기기 때문입니다. OEM 입장에서는 누가 CAN에 붙는지, 어떤 메시지를 보내는지, 어떤 ECU를 건드리는지 모릅니다. 그 모르는 부분이 공격 경로가 됩니다.

❌ OEM이 인증받았으니까 특장 이후에도 차량 보안은 OEM 책임이다

✅ 특장 이후 추가된 공격면은 특장업체가 함께 책임져야 한다

차량 보안 인증은 출고 시점의 구성을 기준으로 합니다. 특장 작업으로 새로운 ECU, 새로운 통신 경로, 새로운 원격 기능이 붙으면 — 그 부분은 OEM이 설계한 보안 범위 밖입니다. 가이드라인은 이 책임 공백을 메우라는 요구입니다.

---

실제로 위험한 상황 3가지

01

특장 ECU가 CAN에 직접 붙는 경우

크레인 제어, 유압 제어, 냉동기 제어, 작업 모드 제어를 위해 특장 ECU가 차량 CAN에 직접 연결되는 구조입니다. 현장에서 흔한 방식이지만 보안 관점에서는 문제가 됩니다.

왜 위험한가

인증 없는 CAN 송신, 보안 없는 Debug Port, 평문 통신, 기본 패스워드 — 특장 ECU의 보안 수준이 OEM 양산 ECU보다 낮으면 차량 전체 공격 진입점이 됩니다. 테슬라 CAN Spoofing 사례와 구조적으로 같습니다.

02

진단 기능 우회

특장 기능 구현 과정에서 UDS 서비스, Routine Control, 특수 DID 접근, Gateway 우회가 발생하는 경우가 있습니다. 기능은 동작하지만 보안 체계 밖에서 움직이는 겁니다.

왜 위험한가

OEM이 허용하지 않은 방식으로 진단 기능에 접근하면 보안 감사에서 즉각 문제가 됩니다. "기능이 작동하면 된다"는 논리가 보안 심사에서는 통하지 않습니다.

03

원격 기능 추가

원격 제어, 원격 모니터링, Fleet 관리, 앱 연동이 특장 영역에서도 빠르게 늘고 있습니다. 특장차도 SDV 흐름 안으로 들어오고 있는 겁니다.

왜 위험한가

LTE, Wi-Fi, Bluetooth, Cloud 연결이 추가되면 "인터넷에서 차량 CAN까지 닿는 경로"가 생깁니다. 공격자 입장에서는 원격에서 차량 내부 네트워크까지 접근할 수 있는 문이 열리는 겁니다.

---

가이드라인 체크리스트 — 특장업체가 직접 확인해야 할 것들

가이드라인 2.14의 주요 확인사항입니다. 특장업체 입장에서 하나씩 짚어보겠습니다.

가이드라인 2.14 주요 확인사항

📋

특장 및 피견인차를 위한 전용 인터페이스를 식별 및 정의한 문서가 존재하는가?
→ "어디에 연결하고 어떤 신호를 주고받는지" 문서가 있어야 합니다. 구두 협의나 도면만으로는 부족합니다.

📋

식별된 전용 환경을 TARA에 반영하여 위험 평가를 수행하고 있는가?
→ 특장이 붙으면 기존 TARA가 바뀌어야 합니다. 특장 이후 새로운 공격 경로가 생겼는지 평가해야 합니다.

📋

사이버보안 컨셉에 해당 내용이 반영되어 수립되어 있는가?
→ 특장 인터페이스 관련 보안 요구사항이 설계 문서에 들어가 있어야 합니다.

📋

전용 인터페이스에 대한 테스트가 진행되었는가?
→ 기능 테스트가 아닌 보안 테스트입니다. 인증 우회 시도, Spoofing 테스트, 퍼징 등이 포함됩니다.

📋

공식적으로 특장업체 및 피견인차 업체에 사이버보안 요구사항을 전달하는 절차가 있는가?
→ OEM이 특장업체에게 "이렇게 해야 한다"를 공식 문서로 전달하는 체계가 있어야 합니다.

* 특장 및 피견인차를 위한 전용 인터페이스를 제공하지 않는 경우, 해당없음을 명시

---

OEM vs 특장업체 — 각자의 역할

가이드라인이 요구하는 건 특장업체만의 의무가 아닙니다. OEM과 특장업체 사이의 역할 분리가 핵심입니다.

OEM 역할

전용 인터페이스 제공

· 보안 통제된 공식 접점 정의
· 허용 메시지 범위 명시
· 보안 요구사항 문서 전달
· Gateway 필터링 적용
· TARA에 특장 환경 반영

특장업체 역할

공식 인터페이스 준수

· OEM 전용 인터페이스 내에서 개발
· 추가 ECU 보안 수준 확보
· 원격 기능 보안 설계
· 보안 테스트 수행
· 변경 발생 시 OEM 통보

피견인차(트레일러) 역할

연동 인터페이스 보안

· 트레일러 ECU 보안 확보
· 외부 연결 접점 관리
· 인증된 통신 방식 사용
· 보안 문서화 유지
· 이상 신호 차단 구조 적용

---

TARA가 특장 이후에 다시 필요한 이유

이 부분이 특장업체 입장에서 가장 낯선 개념일 수 있습니다.

TARA(Threat Analysis and Risk Assessment)는 차량의 공격 경로와 위험도를 분석하는 것입니다. 그런데 특장 작업으로 차량 구성이 바뀌면 — 공격 경로 자체가 달라집니다.

특장 변경 요소	새로 생기는 공격 경로	위험 수준
추가 ECU CAN 연결	CAN Injection 진입점 증가	높음
LTE/Wi-Fi 모듈 추가	원격 공격면 신규 생성	높음
PTO 연동	안전 기능 제어 영향 가능	중간~높음
진단 포트 활용	권한 없는 기능 접근 가능	중간~높음
트레일러 ECU 연동	외부 장치 신뢰 문제	중간
Cloud·앱 연결	인터넷→CAN 경로 생성	높음

즉, 특장 이후에는 기존 OEM TARA가 더 이상 유효하지 않을 수 있습니다. 새로운 공격 경로에 대한 위험 평가가 추가로 필요합니다.

---

특장업체 입장에서 현실적으로 어려운 점

현장에서 자주 나오는 고민

OEM이 전용 인터페이스 정보를 충분히 안 준다 — 보안상 이유로 공개 범위가 제한되는 경우가 많습니다. "이렇게 해야 한다"는 요구사항은 받았는데, 정작 어떻게 해야 하는지 정보가 부족한 경우가 생깁니다.

CSMS, TARA 개념 자체가 생소하다 — CAN 개발 경험은 있어도 보안 요구사항 문서화, TARA, 보안 테스트는 전혀 다른 영역입니다. 사람도 없고 경험도 없는 경우가 많습니다.

현장 개조·사양 변경이 잦다 — 특장업의 특성상 고객 요청으로 현장에서 사양이 바뀌는 경우가 많습니다. 변경될 때마다 보안 문서를 업데이트하는 체계를 갖추기가 쉽지 않습니다.

보안 검증 비용이 부담스럽다 — 중소 특장업체 입장에서 보안 전문 인력 채용, 보안 테스트 장비, 외부 보안 검증 용역은 현실적으로 큰 부담입니다.

---

앞으로 어떻게 준비해야 할까

특장업체 사이버보안 대응 단계

1

OEM 전용 인터페이스 확인 — 해당 OEM 차량에 공식 특장 인터페이스가 있는지, 없다면 "해당없음" 명시가 필요한지 확인합니다.

2

연결 접점 문서화 — 어떤 CAN 메시지를 주고받는지, 어떤 ECU에 접근하는지, 원격 기능이 있는지를 명확히 문서화합니다.

3

위험 평가(간이 TARA) — 추가된 공격 경로에 대해 위험도를 평가합니다. 전문 TARA가 어렵다면 간이 체크리스트 방식으로 시작할 수 있습니다.

4

추가 ECU 보안 최소 요구사항 적용 — CAN 메시지 인증, Debug Port 비활성화, 기본 패스워드 변경 같은 기본 보안 사항을 적용합니다.

5

변경 관리 절차 수립 — 사양 변경이 생길 때 보안 담당자에게 통보하고 문서를 업데이트하는 최소한의 절차를 만들어둡니다.

✅ 지금 당장 완벽한 체계가 필요한 게 아닙니다.
"어디에 연결하는지 알고, 문서로 남기고, 위험을 인식하는 것"에서 시작하면 됩니다.

---

마무리

예전 특장 시스템은 "기능을 추가하면 끝"이었습니다.

이제는 "OEM 보안 체계 안에서 어떻게 안전하게 연결할 것인가"가
특장업체에도 요구되기 시작했습니다.

가이드라인 2.14는 특장업체를 괴롭히려는 게 아닙니다. OEM이 인증받은 차량에 구멍이 생기지 않도록, 특장·피견인차 연결 접점도 체계 안에서 관리하자는 겁니다.

현실적으로 중소 특장업체가 당장 CSMS를 구축하기는 어렵습니다. 하지만 연결 접점을 문서화하고, OEM 인터페이스 안에서 개발하고, 위험을 인식하는 것부터 시작할 수 있습니다.

앞으로 SDV 흐름에서 "차량에 연결되는 모든 장치"는 보안 관리 대상이 됩니다. 특장차도 예외가 아닙니다.

핵심 요약

1

특장 이후 생기는 공격면은 OEM 인증 범위 밖이다 — 특장업체가 추가한 ECU, 원격 기능, 연결 접점은 OEM이 설계한 보안 경계 밖에 있다

2

핵심은 "OEM 전용 인터페이스" 안에서 움직이는 것 — 임의로 CAN에 붙거나 진단 기능을 우회하면 보안 심사에서 문제가 된다

3

특장 이후 TARA가 다시 필요하다 — 새로운 공격 경로가 생겼기 때문에 기존 OEM TARA만으로는 부족하다

4

가이드라인 체크리스트 5개 항목이 기준이다 — 문서화, TARA 반영, 보안 컨셉, 테스트, 요구사항 전달 절차

5

지금 당장 완벽한 체계보다 시작이 중요하다 — 연결 접점 문서화, 기본 보안 적용, 변경 관리 절차부터 시작할 수 있다

특장차 피견인차 트레일러 자동차사이버보안 CSMS TARA R155 CAN보안 SecureGateway 상용차보안 사이버보안인증 KATRI