CSMS는 실제로 무엇을 관리할까?

자동차 사이버보안 규제 이야기 03

이전 편 | UNECE R155 쉽게 이해하기 — 도대체 뭘 요구하는 규정인가

지난 글에서 R155가 요구하는 핵심이 CSMS라는 걸 이야기했습니다.

그런데 막상 "CSMS를 구축하라"는 말을 들었을 때
실제로 뭘 해야 하는지 감이 안 잡히는 경우가 많습니다.

"보안팀을 만들면 되나요?"
"문서를 작성하면 되나요?"
"특정 툴을 도입하면 되나요?"

이번 글에서는 CSMS가 실제로 어떤 영역을 관리하는지,
현업 관점에서 구체적으로 들여다봅니다.

CSMS를 한 문장으로 정의하면

앞 글에서도 잠깐 언급했지만 다시 한번 명확히 짚고 가겠습니다.

CSMS는 차량 사이버보안을 일회성 작업이 아닌
지속적인 프로세스로 관리하는 조직 체계입니다.

여기서 핵심 단어는 두 개입니다. "지속적"과 "조직 체계". 한 번 잘 만들어두면 끝나는 게 아니고, 특정 개인의 역량에 기대는 게 아니라 조직 전체가 반복적으로 수행할 수 있는 프로세스여야 합니다.

다르게 표현하면 이렇습니다. CSMS의 목표는 "보안을 우연히 잘하는 회사"가 아니라 "보안을 지속적으로 관리할 수 있는 회사"를 만드는 것입니다. 담당자가 바뀌어도, 프로젝트가 바뀌어도 같은 수준으로 보안이 관리될 수 있어야 합니다.

ISO/IEC 27001이 IT 보안을 관리하는 체계라면, CSMS는 그것을 자동차 도메인에 맞게 적용한 것입니다. 관리 대상이 서버나 데이터베이스가 아니라 ECU와 차량 시스템이라는 점이 다를 뿐, 운영 철학은 같습니다.

CSMS가 실제로 관리하는 영역들

ISO/SAE 21434와 R155를 기반으로 CSMS가 커버해야 하는 영역을 정리하면 크게 여섯 가지입니다.

① 위협 분석 및 위험 평가 (TARA)

어떤 자산이 있고, 어떤 위협이 존재하며, 그 위험이 얼마나 심각한지를 체계적으로 분석합니다. 모든 보안 결정의 출발점이 됩니다.

차량 시스템 자산 식별

공격 시나리오 도출

위험도 산정 및 처리 방향 결정

TARA 결과 문서화 및 유지

② 보안 요구사항 관리

TARA에서 도출된 위험에 대응하는 보안 목표와 요구사항을 정의하고, 개발 전 과정에서 추적 관리합니다.

사이버보안 목표(Goal) 설정

기술 보안 요구사항 도출

요구사항 추적성(Traceability) 관리

공급사에 요구사항 전달 및 확인

③ 보안 설계·구현·검증

요구사항을 실제 시스템에 구현하고, 의도한 대로 동작하는지 검증합니다. 기술 팀이 가장 직접적으로 부딪히는 영역입니다.

Secure Boot, SecOC 등 보안 기능 구현

Penetration Test, Fuzzing 수행

V&V 결과 문서화

보안 설계 리뷰

④ 공급망 보안 관리

OEM은 공급사가 납품하는 ECU와 소프트웨어의 보안성도 책임져야 합니다. 공급사 선정부터 납품 후 관리까지 포함됩니다.

공급사 사이버보안 역량 평가

보안 요구사항 계약서 반영

납품물 보안 증거 수령·검토

공급사 감사(Audit)

⑤ 취약점 및 인시던트 관리

차량 출시 이후에도 새로운 취약점이 발견될 수 있습니다. 이를 모니터링하고 대응하는 체계가 R155에서 특히 강조되는 부분입니다.

CVE·보안 공지 모니터링

취약점 심각도 평가 및 우선순위 결정

OTA 패치 또는 리콜 여부 결정

보안 사고 발생 시 대응 및 보고

⑥ 사이버보안 조직·역량 관리

위 다섯 가지가 실제로 돌아가려면 사람과 조직이 뒷받침되어야 합니다. CSMS는 기술만이 아니라 조직 운영도 포함합니다.

사이버보안 담당 조직·역할 정의

직원 보안 교육 및 인식 제고

보안 정책·절차 수립 및 유지

경영진 보고 체계 구축

이 여섯 가지 영역은 독립적으로 존재하지 않습니다. TARA 결과가 보안 요구사항을 만들고, 요구사항이 설계와 구현을 이끌고, 구현이 검증을 거치고, 출시 후 취약점이 발견되면 다시 TARA를 재검토하는 순환 구조입니다.

CSMS는 한 번 만들고 끝이 아니다 — PDCA 사이클

CSMS를 처음 구축하고 인증을 받았다고 해서 끝이 아닙니다. R155는 CSMS가 지속적으로 운영되고 개선되어야 한다고 명시합니다. 이를 가장 잘 표현하는 것이 PDCA 사이클입니다.

P

Plan — 계획

TARA 수행, 보안 목표 설정, 보안 요구사항 정의. 무엇을 보호하고 어떻게 할지 계획합니다.

D

Do — 실행

보안 기능 구현, 공급사 요구사항 전달, 직원 교육. 계획한 것을 실제로 수행합니다.

C

Check — 점검

Penetration Test, V&V, 내부 감사, 취약점 모니터링. 계획대로 되고 있는지 확인합니다.

A

Act — 개선

발견된 취약점 패치, 프로세스 보완, TARA 재검토. 점검 결과를 반영해 체계를 개선합니다.

차량이 도로를 달리는 동안 이 사이클은 계속 돌아야 합니다. 새로운 공격 기법이 등장하고, 사용 중인 오픈소스 라이브러리에서 취약점이 발견되고, 기술 환경이 바뀝니다. CSMS는 그 변화에 대응하는 살아있는 체계여야 합니다.

CSMS가 없으면 실제로 어떤 일이 생기나

추상적인 이야기보다 실제 상황을 보는 게 이해가 빠릅니다.

시나리오 A 출시 후 취약점 발견 — 대응 체계 없는 경우

차량 출시 6개월 후, 텔레매틱스 모듈에서 원격 코드 실행 취약점이 외부 연구자에 의해 발견됐습니다. 언론에 공개되기 전에 OEM에 통보됐지만 문제가 생겼습니다.

어느 팀이 대응 책임을 지는지 불분명합니다. 취약점을 패치하려면 해당 ECU를 납품한 Tier-1에 연락해야 하는데, 보안 요구사항이 계약에 명시되지 않아 Tier-1은 대응 의무가 없다고 합니다. OTA로 배포할 절차도, 어떤 차량에 배포해야 하는지 추적하는 시스템도 없습니다.

결국 언론에 먼저 공개됐고, 대규모 리콜로 이어졌습니다. CSMS가 있었다면 취약점 모니터링 → 심각도 평가 → OTA 패치 배포까지 정해진 절차대로 움직였을 것입니다.

시나리오 B 공급사 납품 소프트웨어 취약점 — 추적 불가 경우

Tier-2 소프트웨어 업체가 납품한 미들웨어 라이브러리에서 심각한 취약점이 발견됐습니다. 그런데 OEM은 그 라이브러리가 어떤 차종의 어떤 ECU에 들어가 있는지 파악하지 못합니다.

공급망 보안 관리가 없었기 때문입니다. SBOM(소프트웨어 구성 목록)도 없고, 납품 소프트웨어 버전 추적도 없습니다. 어떤 차량이 영향을 받는지 알 수 없으니 타깃 패치도 불가능하고, 결국 전체 리콜을 고려해야 합니다.

두 시나리오의 공통점은 "기술이 없어서"가 아니라 "관리 체계가 없어서" 문제가 커졌다는 점입니다. CSMS는 이런 상황을 예방하고, 발생했을 때 피해를 최소화하는 조직 운영 방식입니다.

OEM과 Tier-1에서 CSMS는 다르게 보인다

CSMS는 OEM에게 요구되는 체계이지만, 실제 현장에서는 Tier-1과 Tier-2도 각자의 방식으로 대응해야 합니다.

역할별 CSMS 관점 차이

OEM

→

CSMS 전체 수립·인증

공급사 요구사항 정의

형식 승인 획득

차량 생애주기 총괄

Tier-1

→

OEM 요구사항 수령

ECU 단위 TARA

보안 기능 구현·검증

증거 문서 제출

Tier-2

→

Tier-1 요구사항 수령

SW 보안성 입증

SBOM 제공

취약점 발견 시 통보

OEM 입장에서는 CSMS가 자사의 전체 보안 관리 체계이지만, Tier-1 입장에서는 "OEM이 요구하는 보안 요건을 충족하고 그 증거를 제출하는 것"으로 경험됩니다. 같은 CSMS라는 단어를 쓰지만 바라보는 관점이 다릅니다.

최근에는 OEM이 Tier-1에게 단순히 기술 요건만 전달하는 것을 넘어, Tier-1 자체의 CSMS 구축 여부를 계약 조건으로 요구하는 경우도 늘고 있습니다. "우리 공급망 전체가 보안 관리 체계를 갖춰야 한다"는 방향으로 업계가 움직이고 있습니다.

이 변화를 가장 잘 보여주는 것이 개발 완료의 기준입니다. 예전에는 ECU 기능이 정상적으로 동작하면 개발이 완료됐습니다. 하지만 지금은 "안전하게 동작하는가"까지 검증해야 개발이 완료됩니다. 기능 완성도와 보안 완성도가 동시에 요구되는 시대가 됐습니다. 이제 자동차 공급망에서 사이버보안 역량은 단순한 옵션이 아니라 중요한 경쟁력입니다.

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

OEM별로 요구 수준이 다 다르다 — R155와 ISO 21434가 공통 기준을 제시하지만, 실제로 OEM이 Tier-1에게 전달하는 요구사항의 구체성과 엄격함은 천차만별입니다. A사는 TARA 결과 문서 양식까지 지정하고, B사는 보안 목표만 충족하면 방법은 자유입니다. Tier-1 입장에서는 OEM마다 다른 요구사항에 동시 대응해야 하는 부담이 있습니다.

문서화가 생각보다 훨씬 무겁다 — CSMS 운영의 상당 부분은 사실 문서 작업입니다. TARA 결과, 보안 요구사항 추적표, V&V 결과, 취약점 대응 이력 등 인증기관이나 OEM에게 제출할 증거 문서들을 체계적으로 관리해야 합니다. 기술 개발과 문서화를 병행하는 것이 실무에서 가장 힘든 부분 중 하나입니다.

취약점 모니터링은 아직 초기 단계 — 개발 단계 보안은 많은 회사가 어느 정도 갖추기 시작했지만, 출시 후 취약점 모니터링과 대응 체계는 아직 준비가 덜 된 곳이 많습니다. CVE 추적, SBOM 관리, OTA 패치 프로세스를 CSMS 안에 통합하는 것이 앞으로의 과제입니다.

CSMS 인증은 시작이지 끝이 아니다 — 인증을 받고 나서도 정기적인 재심사가 있습니다. 그 사이에 프로세스가 실제로 운영되고 있다는 증거를 지속적으로 축적해야 합니다. "인증받고 서랍에 넣어두는" 방식은 통하지 않습니다.

마무리

CSMS는 보안 솔루션을 도입하는 것도, 문서 몇 장을 작성하는 것도 아닙니다. 차량이 처음 설계되는 순간부터 마지막 차가 도로에서 사라질 때까지, 사이버보안을 지속적으로 관리하는 조직의 운영 방식 전체입니다.

기술보다 프로세스가, 프로세스보다 조직 문화가 더 근본적인 요소라는 점에서, CSMS는 단순한 컴플라이언스 과제가 아닙니다. 자동차 업계가 소프트웨어 회사로 전환하는 과정에서 반드시 체화해야 할 운영 방식입니다.

핵심 요약

• CSMS는 도구나 문서가 아니라 조직이 사이버보안을 지속적으로 관리하는 체계다
• 관리 영역은 TARA, 보안 요구사항, 설계·구현·검증, 공급망, 취약점 대응, 조직 역량 여섯 가지다
• PDCA 사이클로 운영되며, 차량 생애주기 내내 계속 돌아야 한다
• OEM은 CSMS 전체를 수립·인증받고, Tier-1은 OEM 요구사항에 맞춰 증거를 제출한다
• 취약점 모니터링과 공급망 보안은 아직 많은 업체가 준비 중인 미성숙 영역이다
• 인증 후에도 실제 운영 증거를 지속 축적해야 한다 — 인증은 출발점이다

이 시리즈

1

자동차는 언제부터 '보안'을 고민하게 됐을까?

2

UNECE R155 쉽게 이해하기 — 도대체 뭘 요구하는 규정인가

3

CSMS는 실제로 무엇을 관리할까  ← 현재 글

CSMS UNECE_R155 차량사이버보안 ISO21434 TARA 자동차보안관리 공급망보안 취약점관리 SBOM OTA보안 자동차규제