제8부 자율주행

8.12 자율주행 사이버보안 — ISO/SAE 21434

8.12.1 이 장에서 배우는 것 / 선수 지식

8.8~8.11에서 자율주행 안전을 기능안전(8.8·8.9)·SOTIF(8.10)·AI 안전(8.11) 세 기둥으로 봤다. 그런데 이 셋은 모두 공격자가 없음을 암묵적으로 가정한다 — 부품은 고장날 수 있고(기능안전), 인지는 한계가 있고(SOTIF·AI), 그러나 누군가 의도적으로 시스템을 조작하지는 않는다는 가정이다. 현실의 차량은 네트워크에 연결되고(OTA·텔레매틱스), 물리 인터페이스가 노출되며, 센서가 외부 신호에 노출된다 — 악의적 공격자가 있다. 사이버보안은 그 가정을 깨는 위협을 다루는 네 번째 기둥이고, 자율주행에서 사이버보안은 곧 안전의 전제 조건이다. 이 장이 그 기둥이다.

핵심 통찰: 사이버보안은 "안전과 별개의 IT 문제"가 아니라 "안전의 전제" 다. 공격이 성공해 제동·조향·인지가 조작되면, 아무리 잘 설계한 기능안전 메커니즘(8.9)도 무력화된다 — 즉 보안 침해는 안전 목표 위반으로 이어진다(security for safety). 그래서 자동차 사이버보안은 IT 보안 관행을 빌리되 위험을 안전 영향(SFOP)으로 평가하고, 제품 수명주기 전체(개념→개발→생산→운영→폐기)에 걸친 공학 규율로 다룬다. 그 표준이 ISO/SAE 21434, 규제 축이 UNECE R155·R156이다.

배우는 것:

• 왜 네 번째 기둥인가 — 보안은 안전의 전제(security for safety), 다른 세 기둥과의 관계.
• ISO/SAE 21434 — 도로차량 사이버보안 공학 수명주기(개념·용어·프로세스 표준, 시점 의존).
• UNECE R155·R156 — CSMS(사이버보안 관리 체계)·SUMS(소프트웨어 업데이트, OTA)의 규제·형식승인(규제·시점 의존).
• TARA — 위협 분석·위험 평가: 자산·위협 시나리오·공격 경로·영향(SFOP)·실현가능성·위험·CAL.
• 공격면 — CAN·Automotive Ethernet·OTA·센서 스푸핑·디버그 포트 등 인터페이스별 위협.
• 심층방어 — 시큐어 부트·HSM·키 관리·메시지 인증(CAN MAC)·IDS·IDPS·네트워크 분할.
• 보안↔기능안전 상호작용 — 보안이 안전의 전제, 공동 분석, 긴장(지연·복잡).
• 개발·운영 수명주기 — secure development·취약점 관리·인시던트 대응·PSIRT.
• 엔비디아 DRIVE 맥락 — Orin 보안 엔진·시큐어 부트·격리(8.6), 시점·구성 의존.

선수 지식: 8.8·8.9(기능안전·ASIL·안전 메커니즘)·8.10(SOTIF)·8.11(AI 안전)·8.6·8.7(DRIVE OS·격리·미들웨어)·8.1(존 아키텍처·차량 네트워크). 인지·센서는 8.13·8.14. 환경은 자동차 사이버보안 공학.

정직(중요): 사이버보안 표준·규제는 판·시점·관할 의존이 매우 크다. ISO/SAE 21434(2021년판), UNECE R155·R156의 적용 시점·범위·관할(어느 시장에서 언제부터 강제인지)·인증 요건은 시점·규제 의존이라 이 책은 단정하지 않고 "확인 필요"로 다룬다(BK-04). 엔비디아 DRIVE·Orin의 보안 기능(시큐어 부트·HSM·Secure Element·OTA 등)은 세대·구성·시점 의존이라 "확인 필요". 이 장은 개념·용어·사고 틀을 가르치며, 실제 위협 분석·보안 설계·인증은 자격 있는 보안 엔지니어·표준·검증의 영역이다 — 이 책으로 보안 시스템을 설계·인증할 수 없고, 어떤 보안 보증도 절대적으로 단정하지 않는다(보안은 "완성"이 아니라 지속적 관리다).

8.12.2 왜 네 번째 기둥인가 — 보안은 안전의 전제

기능안전(8.8)·SOTIF(8.10)·AI 안전(8.11)이 공유하는 가정을 명시하면:

세 기둥의 암묵적 가정 — "악의적 공격자가 없다":

• 기능안전(8.8·8.9): 부품이 '무작위·체계적으로' 고장난다(악의 아님).
• SOTIF(8.10): 기능이 '의도치 않게' 부족하다(악의 아님).
• AI 안전(8.11): 학습 인지가 '불확실'하다(악의 아님).

사이버보안(이 장) — 그 가정을 깨는 '의도적 공격':

• 공격자는 '최악의 입력을 능동적으로 만든다' — 무작위가 아니라 적대적.
• 안전 메커니즘 자체를 표적으로 무력화하려 든다.

네 기둥의 차이를 한 줄로:

• 적대적 위협 모델: 안전은 "자연이 최악으로 굴 때"를 다루지만, 보안은 "지능적 적이 의도적으로 최악을 만들 때"를 다룬다. 공격자는 확률 분포를 따르지 않고, 약한 고리를 능동적으로 찾는다.
• 보안 → 안전: 공격이 성공하면 안전이 무너진다. 원격으로 제동을 거짓 발화시키거나, 인지 입력을 조작하거나, OTA로 악성 펌웨어를 심으면 — 안전 목표(8.8 HARA로 도출한)가 위반된다. 그래서 자동차 보안의 1차 동기는 기밀성 유출이 아니라 안전 침해 방지(security for safety)다.
• 보완, 대체 아님: 사이버보안은 다른 세 기둥을 대체하지 않는다 — 넷 다 필요하다. 보안을 완벽히 해도 부품은 고장나고(기능안전), 인지는 한계가 있다(SOTIF·AI).

핵심: 자율주행에서 사이버보안은 안전의 전제다 — 보안이 뚫리면 기능안전·SOTIF·AI 안전이 세운 모든 보장이 무력화될 수 있다. 그래서 보안은 "나중에 붙이는 IT 기능"이 아니라 개념 단계부터의 안전 공학과 한 몸이다(8.8의 "사후에 못 붙인다"가 보안에도 그대로). 단 보안은 다른 셋을 보완하지 대체하지 않는다 — 자율주행 안전 = 기능안전 + SOTIF + AI 안전 + 사이버보안.

8.12.3 ISO/SAE 21434 — 도로차량 사이버보안 공학 수명주기

ISO/SAE 21434(Road vehicles — Cybersecurity engineering, 2021년판)는 자동차 E/E 시스템의 사이버보안 공학을 수명주기 전체에 걸쳐 정의하는 표준이다. ISO 26262(8.8)가 기능안전에 대해 하는 일을, 사이버보안에 대해 한다.

ISO/SAE 21434 핵심 성격(개념, 시점 의존):

• '프로세스·프레임워크' 표준 — 특정 기술·솔루션을 처방하지 않음(시큐어 부트·HSM을 '쓰라'가 아니라, '위험을 분석·관리하는 규율'을 정의).
• 두 차원의 관리: ① 조직 차원 — 사이버보안 문화·정책·역량(CSMS의 토대), ② 프로젝트 차원 — 특정 아이템의 보안 활동·산출물.
• 수명주기 전체: 개념 → 개발 → 생산 → 운영·유지보수 → 폐기.
• 핵심 산출물: TARA, 사이버보안 목표·요구, '사이버보안 케이스'.
• CAL(Cybersecurity Assurance Level): 보증 활동의 엄격도(확인 필요).

수명주기를 도해로 — 조직 차원(CSMS)이 프로젝트 수명주기를 관통한다:

• 프로세스 표준: 21434는 "이 암호를 써라"가 아니라 "위험을 식별·평가·처리하고 그것을 추적 가능하게 입증하는 규율"을 정의한다(8.8의 안전 생명주기와 같은 철학). 구체 메커니즘(8.12.7)은 그 규율을 충족하는 수단.
• 운영 단계가 핵심 차이: 기능안전은 양산 후 위험 프로파일이 비교적 고정이지만, 보안은 양산 후에도 새 취약점·공격이 계속 등장한다 — 그래서 21434는 운영·유지보수 단계의 지속 모니터링·취약점 관리·인시던트 대응(8.12.9)을 명시적으로 포함한다. 보안은 "출시로 끝"이 아니다.
• 분산 책임: 차량은 다수 공급자(SoC·티어1·OEM)가 만든다 — 21434는 공유 책임(cybersecurity interface agreement 등) 으로 누가 무엇을 책임지는지 합의하게 한다. 엔비디아 DRIVE 같은 SoC·플랫폼 공급자는 그 사슬의 한 요소(8.12.10).
• 사이버보안 케이스: 안전 케이스(8.8)의 보안판 — 위협이 충분히 다뤄졌다는 추적 가능한 논증.

핵심: ISO/SAE 21434는 사이버보안을 "방화벽 하나"가 아니라 "수명주기 전체의 공학 규율" 로 만든다 — 위협을 체계적으로 분석(TARA)하고, 요구로 캐스케이드하고, 메커니즘으로 충족하고, 양산 후에도 지속 관리한다. 정확한 조항·CAL 산정·인증 범위는 판·시점 의존이라 "확인 필요"로 다룬다.

8.12.4 UNECE R155·R156 — CSMS·SUMS와 형식승인

ISO/SAE 21434가 "어떻게(공학 표준)" 라면, UNECE R155·R156은 "해야 한다(규제·법적 요건)" 다. UNECE WP.29(1958 협정) 산하 규정으로, 차량 형식승인(type approval) 에 사이버보안·소프트웨어 업데이트 체계를 요구한다.

• UN Regulation No. 155 (R155) — 사이버보안·CSMS
  • CSMS(Cyber Security Management System): 제조사가 사이버보안을 관리하는 '인증된 체계'를 갖춰야 함(조직 차원).
  • 차량 형식(type)별로 사이버보안이 적절히 다뤄졌음을 입증.
  • ISO/SAE 21434는 이를 '입증하는 수단'으로 흔히 활용(법적으로는 R155가 요건).
• UN Regulation No. 156 (R156) — 소프트웨어 업데이트·SUMS
  • SUMS(Software Update Management System): SW 업데이트(OTA 포함)를 안전하게 관리하는 체계를 갖춰야 함.
  • 업데이트의 무결성·진정성, 형식승인 영향, 롤백·기록 관리.
• 적용 시점·관할: 시장(EU·일본·한국 등 vs 미국·중국)·시점마다 다름 → 확인 필요.
• CSMS vs SUMS: R155=보안 관리 체계(위협 대응 전반), R156=소프트웨어 업데이트 체계(OTA의 무결성·진정성·기록·형식승인 영향). 자율주행은 OTA로 인지·계획 SW를 계속 갱신하므로 R156이 특히 중요 — 업데이트 자체가 공격면(8.12.6)이자 패치 전달 수단(8.12.9)이다.
• 21434와의 관계: R155는 법적 요건이고, ISO/SAE 21434는 그 요건을 입증하는 공학적 수단으로 널리 쓰인다 — 둘은 보완. 21434를 따랐다고 자동으로 R155 인증이 되는 것은 아니고, 그 역도 아니다(관할·시점 의존).
• 관할·시점 의존(엄수): R155·R156은 1958 협정 체약국에서 채택·적용된다 — EU·일본·한국 등 여러 시장이 적용하나, 미국(NHTSA는 다른 접근, 자기인증·가이드라인)·중국 등은 체계가 다르다. "언제부터·어느 차량에 강제인가" 는 시장·시점마다 다르므로 이 책은 구체 날짜·범위를 단정하지 않는다(확인 필요).

정직: R155·R156의 적용 시점·관할·인증 절차는 규제·시점 의존이 매우 크다 — "전 세계 모든 신차에 언제부터 의무"식 단정은 위험하다. 시장별로 다르고 바뀐다. 또 인증(CSMS·형식승인)을 받았다는 것이 "공격이 불가능하다"는 보증은 아니다 — 프로세스·체계의 적절성을 인증할 뿐, 보안은 절대적이지 않다. 정확한 적용 여부는 해당 관할의 최신 규정을 확인해야 한다.

8.12.5 TARA — 위협 분석·위험 평가

기능안전의 출발이 HARA(8.8)라면, 사이버보안의 출발은 TARA(Threat Analysis and Risk Assessment) 다. 무엇이 공격당할 수 있고, 그것이 얼마나 위험한지를 체계적으로 따진다.

각 단계(개념):

• ① 자산(asset): 보호 가치가 있는 것 — 데이터·기능·자원. 각 자산의 보안 속성(기밀성 Confidentiality·무결성 Integrity·가용성 Availability, C·I·A)을 본다. 예: "제동 명령 메시지의 무결성", "인지 모델·키의 기밀성", "자율주행 기능의 가용성".
• ② 위협 시나리오(threat scenario): 자산의 어떤 속성이 어떻게 침해되나. 예: "공격자가 CAN에 거짓 제동 명령을 주입해 무결성을 침해". 손상 시나리오(damage scenario)와 연결.
• ③ 영향(impact) — SFOP: 위협이 실현되면 피해가 얼마나 큰가를 네 범주로 평가:
  • Safety(안전) — 인명 피해(8.8 HARA의 심각도와 연결).
  • Financial(재정) — 금전 손실.
  • Operational(운영) — 기능·운행 차질.
  • Privacy(프라이버시) — 개인정보 침해.

자율주행에서 S(안전) 영향이 가장 크다 — 이것이 보안↔안전의 연결고리(8.12.8).

• ④ 공격 경로(attack path): 자산에 도달하는 단계의 사슬(공격면 8.12.6에서 시작해 내부로). 예: "Wi-Fi → IVI 침해 → 게이트웨이 우회 → CAN 접근 → 제동 메시지 주입".
• ⑤ 공격 실현가능성(attack feasibility): 그 경로가 얼마나 쉬운가. 평가 방식은 여러 가지(확인 필요): 공격 잠재력 기반(소요 시간·전문성·아이템 지식·기회 창·장비), CVSS 기반, 공격 벡터 기반 등.
• ⑥ 위험 값(risk): 영향 × 실현가능성 — 큰 영향 + 쉬운 공격 = 높은 위험. HARA의 S·E·C 조합과 같은 발상.
• ⑦ 위험 처리(risk treatment): 위험을 어떻게 다룰지 — 회피(avoid)·저감(reduce)·전가(share·transfer)·수용(retain). 저감하면 사이버보안 목표·요구가 나오고, 그것이 메커니즘(8.12.7)으로 캐스케이드된다.

CAL(Cybersecurity Assurance Level): 영향·공격 벡터로 결정되는 보증 활동의 엄격도(ASIL과 발상이 비슷하나 위험 등급 그 자체는 아님 — 보증의 깊이를 정함). CAL 1~4가 거론되나 정확한 산정 표·의무성·적용은 판·시점 의존이라 "확인 필요"로 둔다.

핵심: TARA는 보안판 HARA다 — 자산 → 위협 → 영향(SFOP) → 공격 경로 → 실현가능성 → 위험 → 처리의 추적 가능한 사슬. 자율주행에선 SFOP의 S(안전) 가 핵심이라, TARA의 안전 영향은 HARA(8.8)와 맞물린다. 정확한 실현가능성 산정·CAL은 자격 있는 엔지니어가 표준·방법론으로 수행하며 판·시점 의존(확인 필요).

8.12.6 공격면 — 인터페이스별 위협

자율주행 차량은 공격면(attack surface) 이 넓다 — 연결·물리·센서 인터페이스가 모두 진입점이다. TARA의 공격 경로(8.12.5)는 보통 이 표면에서 시작한다.

• CAN·CAN FD: 차내 제어 네트워크의 고전. 기본적으로 브로드캐스트·무인증·무암호 — 누구든 메시지를 읽고, 거짓 메시지를 주입하면 ECU가 믿는다. 대표 위협: 스푸핑·주입·재전송(replay). 차내 침투 후 가장 위험한 표면.
• Automotive Ethernet·TSN: 센서 대역(8.1)을 감당하려 도입 — 대역폭이 크고 스위칭 기반이라 공격면도 넓다(중간자·횡적 이동). 분할·인증이 중요.
• OTA·텔레매틱스: 원격에서 SW를 갱신하는 통로 — 악성 펌웨어 주입의 표적. 동시에 패치 전달 수단(8.12.9)이라 양날의 칼. R156(8.12.4)의 영역.
• 무선(Wi-Fi·BT·셀룰러·V2X·디지털 키): 물리 접근 없이 도달 가능해 원격 대규모 공격의 위험. IVI(인포테인먼트)가 흔한 교두보(pivot) — 거기서 게이트웨이를 넘어 안전 도메인으로 횡적 이동 시도.
• 센서 스푸핑(GNSS·LiDAR·레이더·카메라): 차내에 침투하지 않고 외부 신호로 인지를 속인다 — GNSS 스푸핑(위치 조작)·재밍, LiDAR·레이더에 거짓 반사 주입, 카메라 블라인딩·적대적 패치(adversarial patch). 이것은 사이버보안과 SOTIF·AI 안전(8.10·8.11)의 경계 — 의도적이라 보안이지만, 인지 강건성이라 AI 안전이기도. 융합·플로지빌리티가 완화.
• 물리 인터페이스(OBD-II·UDS·JTAG·UART·USB): 정비·진단·디버그용. 양산에서 디버그를 잠그지 않으면 강력한 진입점 — 펌웨어 추출·키 탈취·제어 우회. 진단(UDS)도 인증 없이 위험한 서비스를 노출하면 표면.

핵심: 자율주행 차량은 원격·물리·센서의 세 부류 공격면을 갖는다. 가장 흔한 침투 경로는 연결 인터페이스(무선·OTA)로 들어와 게이트웨이를 넘어 차내 네트워크(CAN·Ethernet)로 횡적 이동하는 것 — 그래서 네트워크 분할·게이트웨이·메시지 인증(8.12.7)이 핵심 방어다. 센서 스푸핑은 보안과 SOTIF·AI 안전의 경계에 있다(8.10·8.11과 함께 다룸).

8.12.7 심층방어 — 다층 대응

단일 방어선은 뚫린다 — 보안은 심층방어(defense in depth), 즉 여러 층으로 막아 한 층이 뚫려도 다음 계층이 방어하게 한다. TARA(8.12.5)에서 도출한 사이버보안 요구를 이 메커니즘들이 충족한다.

층별로(엔비디아 구체 구현은 8.12.10, 모두 시점·구성 의존):

• 신뢰 사슬·시큐어 부트(secure boot): 변경 불가능한 하드웨어 root of trust(퓨즈에 박힌 루트 키)에서 시작해, 각 부팅 단계가 다음 단계의 서명을 검증한 뒤 실행한다(BootROM → 부트로더 → OS → 앱). 서명이 안 맞으면 멈춘다 — 악성·변조 펌웨어를 막는다. 롤백 방지(취약한 옛 버전으로 되돌리기 차단)도 포함.
• HSM·Secure Element·암호 가속: 키를 하드웨어로 격리해 저장·사용하고(소프트웨어가 키 원본에 접근 못 함), AES·ECC·RSA·SHA 등을 하드웨어로 가속하며, TRNG(진난수)로 안전한 키·논스를 만든다. 자동차에선 보안 처리에 쓸 시간·전력이 제한적이라 가속이 중요.
• 키 관리: 키의 생애주기 — 생산 단계의 프로비저닝, 키 계층(루트·중간·작업 키), 순환(rotation), PKI·인증서 관리, 폐기. 보안의 흔한 실패 지점(하드코딩·공유 키·관리 부재)이라 별도 규율이 필요. R156·생산 단계(8.12.3·8.12.4)와 연결.
• 통신 인증·무결성: 무인증인 CAN을 보강하는 메시지 인증 코드(MAC) — AUTOSAR SecOC(Secure Onboard Communication)가 대표로, 메시지에 MAC과 freshness 값(카운터·타임스탬프)을 붙여 위조·재전송을 막는다. Ethernet은 MACsec·IPsec·TLS. 즉 "메시지가 실제 송신자에게서, 변조·재사용 없이 왔는가"를 검증.
• 격리·네트워크 분할: 하이퍼바이저 격리(FFI, 8.6) 는 안전·비안전을 가르는 동시에 보안 경계다 — IVI가 침해돼도 안전 파티션으로 못 넘어가게. 차량 차원에선 도메인·존(8.1) 분할과 게이트웨이·방화벽으로 안전 critical 네트워크를 인포테인먼트·외부 연결에서 분리하고 최소 권한으로 트래픽을 통제 — 횡적 이동(8.12.6)을 차단.
• 침입 탐지·대응(IDS·IDPS): 막지 못한 공격을 탐지한다. IDS(Intrusion Detection System)는 네트워크·호스트에서 이상(비정상 CAN 메시지율·예상 못 한 통신·서명 일치)을 감지하고, IDPS는 탐지에 더해 차단·대응까지. 차량의 IDS 텔레메트리를 백엔드 VSOC(Vehicle Security Operations Center)로 모아 차량군(fleet) 차원으로 상관·대응한다(8.12.9).

핵심: 보안은 단일 벽이 아니라 다층이다 — 신뢰 사슬(부트)·암호·키·통신 인증·격리·탐지·운영이 겹겹이. CAN MAC(SecOC) 가 무인증 CAN을 보강하고, 격리(8.6)·네트워크 분할(8.1) 이 횡적 이동을 막고, IDS·VSOC 가 뚫린 공격을 탐지·대응한다. 어떤 단일 메커니즘도 "안전을 보장"하지 않으며, 층이 함께 작동해 위험을 줄일 뿐이다(절대 보증 아님).

8.12.8 보안↔기능안전 상호작용 — 보안은 안전의 전제

보안과 기능안전(8.8·8.9)은 별개가 아니라 맞물린다 — 핵심 명제는 "보안은 안전의 전제 조건"(security for safety)이다.

• 위협 → 안전 위반: 공격이 성공하면(예: 제동 메시지 위조, 인지 입력 조작, 악성 OTA) 안전 메커니즘(8.9)이 무력화되어 안전 목표가 위반된다 — TARA의 S(안전) 영향(8.12.5)이 곧 HARA의 위험과 연결되는 지점. 그래서 보안 실패는 안전 실패가 될 수 있다.
• 공동 분석: TARA(보안)와 HARA(8.8, 안전)는 연계되어야 한다 — 안전 위험을 유발할 수 있는 위협을 식별하고, 산출물을 공유한다. 두 규율을 분리해 따로 하면 빈틈이 생긴다(안전이 가정한 신뢰가 보안에서 깨질 수 있음).
• 긴장(trade-off, 정직): 보안과 안전·실시간이 충돌할 수도 있다:
  • 메시지 인증(MAC)·암호는 지연·연산 부하를 더해 실시간·결정성(8.6) 의 데드라인을 압박할 수 있다 — 하드웨어 가속(HSM)·설계로 균형.
  • fail-safe vs fail-secure: 고장 시 "안전한 상태"(예: 정지)와 "보안적으로 잠긴 상태"가 다를 수 있다 — 잠그면 안전 기능까지 막힐 수 있어 조율이 필요.
  • 보안 갱신(OTA 패치)이 안전 인증된 구성을 바꾸므로, R156 SUMS·재검증이 필요(8.12.4·8.12.9).
• 방향성: 보통 보안이 안전을 받친다(security for safety)지만, 안전 메커니즘이 보안을 돕기도 한다(격리·중복화가 공격 전파를 줄임) — 양방향.

핵심: 자동차에서 보안과 안전은 한 몸이다 — 보안은 안전의 전제이고(공격이 안전을 무너뜨림), TARA와 HARA는 공동 분석되어야 한다. 동시에 보안 메커니즘은 실시간·결정성(8.6) 과 긴장할 수 있어 균형이 필요하다. 보안을 안전과 분리해 "IT 팀의 일"로 두면 빈틈이 생긴다 — 둘은 함께 설계·검증되어야 한다(자격 있는 엔지니어·표준의 영역).

8.12.9 개발·운영 수명주기 — secure development·취약점 관리·PSIRT

ISO/SAE 21434의 차별점(8.12.3)은 운영 단계까지 본다는 것이다 — 보안은 출시로 끝나지 않는다. 개발부터 운영까지의 규율을 본다.

• secure development(SDL): 보안을 설계 처음부터(security by design) — 개념 단계의 위협 모델링·TARA(8.12.5), 보안 요구 캐스케이드, 안전한 코딩, 보안 테스트(퍼징 fuzzing·침투 테스트 pentest·취약점 스캔·정적 분석), 보안 코드 리뷰. "잘 작성한 코드"가 아니라 추적 가능한 보안 공학(8.8의 프로세스 철학과 동일).
• SBOM·구성요소 추적: 차량 SW는 수많은 컴포넌트(오픈소스 포함)로 구성된다 — SBOM(Software Bill of Materials)으로 무엇이 들어갔는지 알아야, 그 컴포넌트의 새 취약점(CVE)이 우리 제품에 영향을 주는지 판단할 수 있다.
• 취약점 관리: 양산 후 새 취약점이 계속 등장한다 — 위협 인텔·CVE·연구·IDS 텔레메트리를 지속 모니터링하고, 우리 제품 영향을 재평가(재-TARA) 하고, 우선순위를 매겨 처리.
• 인시던트 대응·PSIRT: PSIRT(Product Security Incident Response Team)가 취약점·인시던트를 접수·트리아지·조율·수정·공개한다 — 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD) 로 연구자와 협력하고, 패치를 개발·검증해 OTA(R156) 로 배포한다. 엔비디아도 제품 보안 대응 조직(PSIRT)을 운영한다(구체 절차·범위는 확인 필요).
• 운영 루프: 위 도해처럼 모니터링 → 평가 → 수정 → 검증 → 배포 → 모니터링의 순환 — 보안은 지속적 관리다. 패치가 안전 인증 구성을 바꾸므로 회귀 안전 검토·재검증·R156 SUMS 기록이 따른다(8.12.8의 긴장).
• VSOC: 차량군의 IDS 텔레메트리를 백엔드에서 상관·분석해 함대 차원의 공격을 조기 탐지·대응(8.12.7의 탐지 층과 연결).

핵심: 보안은 개발 처음부터(SDL·TARA), 그리고 운영 내내(취약점 관리·PSIRT·OTA 패치) 지속되는 규율이다 — "출시하면 끝"이 아니다. 새 취약점은 계속 나오고, PSIRT·VSOC·OTA(R156) 의 순환으로 대응한다. 패치는 안전 구성을 바꾸므로 재검증이 따른다. SBOM·CVD 같은 IT 보안 관행을 안전 맥락으로 가져온다.

8.12.10 엔비디아 DRIVE 맥락 — Orin 보안 엔진·시큐어 부트·격리

엔비디아 DRIVE는 OEM의 사이버보안 케이스를 받치는 플랫폼 요소다 — 기능안전의 SEooC(8.8)와 같은 발상으로, 보안 빌딩 블록을 제공하되 전체 차량 보안(CSMS·R155)은 OEM·티어1과의 공유 책임(8.12.3)이다.

DRIVE 플랫폼의 보안 빌딩 블록(개념, 모두 세대·구성·시점 의존 → 확인 필요):

• 하드웨어 신뢰 기반: root of trust·시큐어 부트(서명 검증 부팅 사슬).
• 보안 엔진·암호 가속: 키 보호·암호 연산·난수(Orin 세대의 보안 엔진).
• 격리: 하이퍼바이저·FFI(8.6) — 안전 경계이자 보안 경계.
• 안전한 업데이트 경로: OTA(무결성·진정성), R156 맥락.
• 엔비디아 제품 보안 대응: PSIRT(취약점 접수·대응) 운영.

→ 그러나 '플랫폼이 안전·보안 빌딩 블록 제공' ≠ '차량이 자동으로 안전·보안'.

• 빌딩 블록 제공자: DRIVE SoC·OS는 시큐어 부트·보안 엔진(암호·키)·격리(8.6) 같은 메커니즘(8.12.7)을 제공해 OEM이 자기 보안 케이스에 통합하게 한다. 격리(FFI, 8.6)는 안전 경계인 동시에 보안 경계다 — 한 파티션의 침해가 다른 파티션으로 전파되지 못하게.
• 공유 책임: 전체 차량의 CSMS·형식승인(R155, 8.12.4)·통합 TARA는 OEM·티어1의 책임이고, DRIVE는 그 사슬의 한 요소. "엔비디아 플랫폼을 쓰니 보안이 끝"이 아니다 — 센서·다른 ECU·네트워크·통합·운영이 모두 보안 요구를 충족해야(약한 고리 하나가 전체를 무너뜨림).
• 시점·구성 의존(엄수): Orin·DRIVE의 구체 보안 기능 명칭·범위·인증은 세대·SKU·구성·시점 의존이라 이 책은 단정하지 않는다(확인 필요). "DRIVE가 R155 준수"·"시큐어 부트가 있으니 안전"식 단정은 위험 — 무엇이·어느 구성에서·어느 범위로인지 확인이 필요하고, 보안은 어차피 절대적이지 않다.

정직: 엔비디아 DRIVE는 사이버보안의 빌딩 블록(시큐어 부트·보안 엔진·격리)을 제공하나, 그 구체 사양·인증은 시점·구성 의존(확인 필요)이고, 전체 차량 보안은 OEM·티어1과의 공유 책임이다(CSMS·R155). 플랫폼이 보안 기능을 갖췄다는 것이 "차량이 안전하다"는 보증은 아니다 — 통합·운영·전체 시스템이 보안 케이스를 성립시켜야 하며, 그조차 절대 보증이 아니라 위험을 줄이는 것이다. 실제 보안 설계·인증은 자격 있는 보안 엔지니어·표준의 영역이다.

8.12.11 따라하기 — 한 자산에 대한 미니 TARA 워크스루

8.12.5의 TARA를 하나의 자산에 개념적으로 적용해 본다(실제 TARA는 자격 있는 엔지니어가 표준·도구로 수행 — 이것은 학습용 사고 연습이다).

대상 자산: "제동 명령 메시지(CAN)의 무결성".

⑦ 처리(저감)에서 도출되는 메커니즘(8.12.7):

• 메시지 인증: CAN SecOC(MAC + freshness) → 위조·재전송 차단(④의 마지막 단계 무력화).
• 네트워크 분할·게이트웨이: IVI↔안전 도메인 분리, 최소권한 → 횡적 이동(④ 중간) 차단.
• 격리(8.6): IVI 침해가 안전 파티션으로 전파 못 하게.
• IDS·IDPS: 비정상 제동 메시지율·미인증 메시지 탐지 → VSOC 보고(8.12.9).
• 시큐어 부트: 변조 펌웨어로 메시지를 위조하는 진입 자체를 차단.

→ 보안↔안전 연계(8.12.8): 이 위협의 S영향은 HARA의 '의도치 않은 제동'(8.8)과 동일 사건.

읽는 법:

• 공격 경로의 각 단계마다 다른 층이 대응한다(심층방어) — 원격 진입(분할·게이트웨이), 횡적 이동(격리·최소권한), 최종 주입(CAN MAC), 탐지(IDS). 한 층이 뚫려도 다음 계층이 방어한다.
• S(안전) 영향이 지배하므로, 이 위협은 안전 위험과 동일 사건(8.8의 "고속 의도치 않은 제동")으로 — TARA와 HARA가 공동 분석되어야 함(8.12.8)을 보여준다.
• 메커니즘은 TARA에서 도출된 요구를 충족한다 — "CAN MAC을 쓰자"가 먼저가 아니라, "이 위협의 위험이 높으니 무결성을 보장하라"는 요구에서 메커니즘이 나온다(8.12.3의 프로세스 철학).

핵심: TARA는 "막연히 보안을 강화"가 아니라 자산·위협·영향·경로에서 위험을 도출하고, 그 위험을 줄이는 메커니즘을 캐스케이드하는 추적 가능한 작업이다. 제동 메시지 무결성 같은 안전 critical 자산은 여러 층(인증·분할·격리·탐지·부트) 으로 막고, 그 위험은 HARA(8.8)와 연계된다. (이것은 학습용 개념 연습 — 실제 TARA는 자격 있는 엔지니어가 표준으로.)

8.12.12 중간 점검 (체크포인트)

• [ ] 사이버보안이 네 번째 안전 기둥이며 보안은 안전의 전제(security for safety)임을 안다 — 다른 셋(8.8·8.9·8.10·8.11)을 보완하되 대체하지 않음.
• [ ] ISO/SAE 21434가 수명주기 전체의 프로세스 표준(특정 기술 처방 아님)이며 운영 단계까지 포함함을 안다(시점 의존).
• [ ] UNECE R155(CSMS)·R156(SUMS·OTA) 가 규제·형식승인 요건이며 적용이 관할·시점 의존임을 안다.
• [ ] TARA의 사슬(자산→위협→영향 SFOP→공격 경로→실현가능성→위험→처리)과 CAL(보증 수준, 확인 필요)을 설명한다.
• [ ] 공격면(CAN·Ethernet·OTA·무선·센서 스푸핑·디버그 포트)과 횡적 이동 시나리오를 안다.
• [ ] 심층방어(시큐어 부트·HSM·키 관리·CAN MAC·SecOC·격리·분할·IDS·IDPS·운영)를 층으로 설명한다.
• [ ] TARA↔HARA 공동 분석과 보안↔실시간(8.6)의 긴장을 안다.
• [ ] secure development·취약점 관리·PSIRT·VSOC·OTA 패치의 지속 운영 루프를 안다.
• [ ] DRIVE는 빌딩 블록(시큐어 부트·보안 엔진·격리 8.6)을 제공하되 전체 보안은 공유 책임이고 사양·인증은 시점·구성 의존임을 안다.

증상→의심: "보안은 IT 팀 일" → 보안은 안전 전제(8.12.8), TARA↔HARA 공동. CAN에 거짓 명령이 먹힘 → 무인증 CAN → SecOC·MAC·freshness. IVI 침해가 제동까지 도달 → 횡적 이동 → 네트워크 분할·게이트웨이·격리(8.6). OTA로 악성 펌웨어 → 시큐어 부트·서명·롤백 방지·R156. 양산 후 새 취약점 방치 → 취약점 관리·PSIRT·VSOC. "인증받았으니 안전" → 인증은 프로세스 적절성, 보안은 절대 아님. "DRIVE 쓰니 보안 끝" → 공유 책임·시점·구성 의존.

8.12.13 트레이드오프·대안

견해: 자율주행 보안의 핵심은 심층방어 + 보안·안전 공동 설계다. CAN MAC(SecOC)·암호는 하드웨어 가속(HSM) 으로 실시간 부담을 줄이며 적용하고, 네트워크 분할·격리(8.1·8.6) 로 횡적 이동을 막고, IDS·VSOC·OTA(R156) 로 탐지·대응한다. OTA는 공격면을 늘리지만 패치 신속성이 더 크므로 서명·시큐어 부트로 보강해 쓴다. 그리고 보안은 안전과 분리하지 말 것(TARA↔HARA) — 어느 메커니즘도 보안을 "보장"하지 않으며, 목표는 위험을 허용 수준까지 줄이고 지속 관리하는 것이다. 모두 자격 있는 엔지니어·표준의 영역.

비엔비디아 정직: ISO/SAE 21434·UNECE R155·R156은 업계·규제 표준이고 모든 차량 제조사·공급자가 직면한다 — 엔비디아만의 것이 아니다. CAN SecOC·MACsec·시큐어 부트·HSM 같은 메커니즘도 자동차·IT 보안의 일반 관행이다. 엔비디아 DRIVE의 기여는 AI 컴퓨팅 SoC·OS가 보안 빌딩 블록(시큐어 부트·보안 엔진·격리)을 갖춰 OEM의 보안 케이스를 받치는 것이며, 전체 CSMS·형식승인·통합 TARA는 OEM·티어1의 책임이고 사양·인증은 시점·구성 의존(확인 필요)이다. 보안은 표준·자격·검증·지속 운영의 영역이고, 이 책은 개념을 가르칠 뿐 보안을 보증하지 않는다.

8.12.14 흔한 함정

• 보안을 안전과 분리. "안전은 안전 팀, 보안은 IT 팀"으로 나누면 빈틈 — 보안은 안전의 전제, TARA↔HARA 공동 분석(8.12.8).
• 보안을 사후에. 개념 단계부터(SDL·TARA) — 사후에 못 붙인다(8.8·8.12.2와 동일).
• 무인증 CAN 신뢰. CAN은 기본 무인증·무암호 — 거짓 메시지 주입·재전송에 취약 → SecOC·MAC·freshness(8.12.7).
• 경계만 막고 내부 평탄. 외곽 방화벽만 믿으면 한 번 뚫리면 끝 — 분할·격리·최소권한·IDS로 심층방어, 횡적 이동 차단.
• 디버그·진단 포트 방치. 양산에서 JTAG·UART·미인증 UDS를 열어두면 강력한 진입점 → 잠금·보안 디버그(8.12.6).
• OTA를 무방비로. OTA는 패치 수단이자 공격면 — 서명·시큐어 부트·롤백 방지·R156 없이는 악성 펌웨어 통로(8.12.4·8.12.7).
• 출시로 끝. 새 취약점은 계속 나온다 — 취약점 관리·PSIRT·VSOC·OTA 패치의 지속 운영(8.12.9).
• "인증=불가침" 오해. CSMS·형식승인·인증은 프로세스 적절성을 인증할 뿐, 공격 불가능 보증이 아니다 — 보안은 절대적이지 않다.
• 센서 스푸핑을 무시·오분류. GNSS·LiDAR·카메라 스푸핑은 의도적이라 보안이자 SOTIF·AI 안전(8.10·8.11) — 융합·플로지빌리티로 완화.
• 규제·표준을 시점 무시하고 단정. R155·R156 적용은 관할·시점 의존 — "전 세계 의무"식 단정 금지(확인 필요).
• "DRIVE 쓰니 보안 끝". 플랫폼은 빌딩 블록, 전체는 공유 책임·시점·구성 의존(8.12.10).
• 이 책으로 보안 설계. 개념·용어를 배우되 실제 위협 분석·보안 설계·인증은 자격 있는 엔지니어·표준.

8.12.15 연습문제

연습 1 (네 번째 기둥). 자율주행 안전의 다른 세 기둥(기능안전·SOTIF·AI 안전)이 공유하는 암묵적 가정은 무엇이고, 사이버보안이 왜 "안전의 전제"인지 설명하라.

연습 2 (TARA). TARA의 단계(자산→...→처리)를 순서대로 설명하고, HARA(8.8)와의 공통점·차이를 답하라. SFOP가 무엇인지도 포함하라.

연습 3 (공격 경로·심층방어). "공격자가 셀룰러로 IVI를 침해한 뒤 제동을 거짓 발화시킨다"는 시나리오의 공격 경로를 단계로 쓰고, 각 단계를 막는 심층방어 메커니즘(8.12.7)을 매핑하라.

연습 4 (보안↔안전). 보안과 기능안전(8.8·8.9)이 어떻게 맞물리는지(전제·공동 분석)와, 둘이 충돌할 수 있는 지점(긴장)을 예로 설명하라.

연습 5 (운영·인증 주장 비판). 한 팀이 "우리는 ISO/SAE 21434를 따르고 R155 인증을 받았으니 차량이 사이버 공격으로부터 안전하다"고 한다. 비판적으로 검토하라.

8.12.16 요약 · 다음 장

• 사이버보안은 자율주행 안전의 네 번째 기둥이며, 다른 셋(기능안전 8.8·8.9, SOTIF 8.10, AI 안전 8.11)이 가정하는 "공격자 없음"을 깨는 의도적 위협을 다룬다 — 그래서 보안은 안전의 전제(security for safety)이고 넷 다 필요(보완, 대체 아님).
• ISO/SAE 21434 는 수명주기 전체(개념→개발→생산→운영→폐기)의 사이버보안 공학 프로세스 표준 — 특정 기술 처방이 아니라 위험 관리 규율이며, 운영 단계의 지속 관리를 포함(시점 의존, 확인 필요).
• UNECE R155(CSMS)·R156(SUMS·OTA) 는 규제·형식승인 요건 — 적용 시점·관할·인증은 규제·시점 의존(확인 필요), 인증이 "공격 불가" 보증은 아님.
• TARA: 자산(C·I·A)→위협 시나리오→영향(SFOP)→공격 경로→실현가능성→위험→처리, CAL(보증 수준, 확인 필요). HARA(8.8)와 공동 분석.
• 공격면(CAN·Automotive Ethernet·OTA·무선·센서 스푸핑·디버그 포트)과 횡적 이동, 심층방어(시큐어 부트·HSM·키 관리·CAN SecOC·MAC·격리·분할 8.1·8.6·IDS·IDPS·운영)로 다층 대응.
• 보안↔기능안전은 한 몸(전제·공동 분석)이되 실시간·결정성(8.6) 과 긴장할 수 있음. secure development·취약점 관리·PSIRT·VSOC·OTA 패치(R156) 의 지속 운영 루프.
• 엔비디아 DRIVE는 보안 빌딩 블록(시큐어 부트·보안 엔진·격리 8.6)을 제공하되 전체 보안은 공유 책임이고 사양·인증은 시점·구성 의존(확인 필요).
• 정직: 이 장은 개념·용어·틀을 가르치되 실제 위협 분석·보안 설계·인증·운영은 자격 있는 보안 엔지니어·표준·검증의 영역 — 어떤 보안도 절대적이지 않으며, 보안은 "완성"이 아니라 위험을 줄이고 지속 관리하는 규율이다.

이로써 자율주행 안전의 4기둥(기능안전 8.8·8.9 + SOTIF 8.10 + AI 안전 8.11 + 사이버보안 8.12)이 모두 갖춰졌다 — 안전은 어느 하나가 아니라 네 기둥이 함께 떠받치며, 모두 자격 있는 엔지니어·표준·규제·지속 검증의 영역이다.

다음 장: 번호상 이 장이 책 끝이지만 내용상으로는 안전 4부작(8.8~8.11) 바로 다음 자리다 — 이어서 8.13 DriveWorks·Hyperion 센서 스택 으로 돌아가 자율주행 개발 도구·센서 파이프라인을 본다.