ISO 21434는 대체 어떤 내용을 담고 있을까?
(2편: 자동차 개발 V 사이클에서의 사이버보안)
앞선 1편에서는 5절부터 8절까지, 조직 차원에서 고려해야 할 구조적인 사이버보안에 대해 살펴봤습니다. 회사 전체가 보안을 책임지고, 프로젝트 단위에서 실행하며, 공급망과 협력하고, 운영 단계에서도 위협을 모니터링하는 큰 틀이었죠.
앞에서는 조직과 공급망 차원의 큰 그림을 살펴봤다면, 이번에는 실제 개발 현장으로 시선을 옮겨보겠습니다. 차량 개발의 V 사이클 안에서 사이버보안이 어떻게 자리 잡고 있는지 알아보겠습니다. ISO 21434의 9절부터 14절까지는 차량 개발 과정 전반에 걸쳐 보안이 어떻게 관리되어야 하는지를 구체적으로 정의하고 있습니다. 즉, 개발 전 → 제품 개발 → 검증 → 생산 → 운영 → 지원 종료로 이어지는 전 과정을 따라, 보안 요구사항을 정의하고 있습니다.
9절. 컨셉트 단계 (Concept)
9절은 제품을 설계하기 이전, 개념 단계에서 수행해야 하는 보안 활동을 정의하고 있습니다. 쉽게 말해, “우리가 어떤 제품을 만들 것이며, 어떤 보안 위협에 노출될 수 있을까?”를 미리 고민하는 단계라고 볼 수 있습니다.
핵심 보안 활동은 아이템 정의와 TARA(Threat Analysis and Risk Assessment)입니다. 아이템 정의는 제품의 기능과 범위, 외부와 연결되는 인터페이스를 명확히 기록하는 과정으로, 무엇을 보호할지 기준을 세우는 작업이라고 이해하면 됩니다. 이어서 TARA는 이렇게 정의된 제품을 바탕으로 잠재적 위협 시나리오를 도출하고, 공격 경로를 분석하며, 위험도를 평가하는 단계입니다. 마지막으로 이 결과를 토대로 사이버보안 목표와 클레임을 수립합니다. 쉽게 말해, “이 제품은 반드시 이런 위협으로부터 안전해야 한다”는 선언을 하는 것이죠.
즉, 9절은 “보안은 설계 이후가 아니라 개념 단계부터 시행되어야 한다”는 것을 강조한다고 볼 수 있습니다.
- 아이템 정의 - 제품의 기능과 범위, 외부와 연결되는 인터페이스, 운영 환경에서 가정해야 할 조건을 체계적으로 정리하는 과정입니다. 시스템 경계의 범위와 보호 대상이 되는 주요 기능을 이 단계에서 명확히 명세합니다. 이렇게 정의된 문서는 이후 수행되는 TARA가 정확한 범위 안에서 진행되도록 하는 기준선 역할을 합니다.
- TARA(위협 분석 및 위험 평가) - 자산을 식별하고, 가능한 위협 시나리오를 도출하며, 그에 따른 영향도와 공격 용이성을 평가해 위험도를 산정하는 과정입니다. 이를 통해 “어떤 공격이 가장 치명적이고, 어떤 부분이 가장 취약한가”를 알 수 있습니다. 이 분석은 향후 모든 보안 설계의 기반이 됩니다.
- 사이버보안 목표 – TARA의 위험 대응 방법 중 ‘위험 감소’로 결정한 보안 위험에 대해 “무엇을 어느 수준까지” 보호할지를 최상위 수준으로 선언합니다. 즉, 어떤 위협을 어떤 수준까지 줄일 것인가를 명시하는 상위 요구입니다. 예를 들어 “차량 제어 신호는 반드시 인증된 출처에서만 수신되어야 한다” 같은 목표를 수립하는 거죠. 이는 보안 활동의 최종 도달점을 명확히 제시합니다. 이후 설계·구현·검증의 기준선이 되며, 목표와 하위 요구사항 간 추적성이 유지되어야 합니다.
- 사이버보안 클레임 - TARA에서 위험 대응 방법이 유지(보유)하거나 공유(전가)하기로 결정한 위험에 대해 그 판단의 근거와 전제 조건을 기록하는 문서입니다. 즉 “이 위험은 이런 이유로 유지/공유하며, 이후 이렇게 감시한다”라는 선언이며, 운영 단계의 모니터링·취약점 관리 대상이 됩니다.
- 사이버보안 목표 검증 보고서 - 수립한 보안 목표가 적절하고 현실적으로 달성 가능한지를 검토한 결과를 담습니다. 단순히 목표를 선언하는 것에서 끝나는 것이 아니라, 그 목표가 실제 제품 특성과 개발 상황에 비춰 타당한지를 증명해야 합니다. 분석 근거와 리뷰 결과, 필요한 샘플 테스트의 요약이 포함되어 보안 목표의 타당성을 문서로 담습니다.
- 사이버보안 콘셉트 - 목표를 달성하기 위한 보안 요구사항과 운영 환경 요구사항을 체계화해 만든 전략 문서입니다. 이후 제품 개발 단계에서 설계 명세로 구체화됩니다.
- 사이버보안 콘셉트 검증 보고서 - 수립된 콘셉트가 목표 달성에 충분한지, 전제와 제약이 일관성 있게 연결되는지를 확인한 결과입니다. 콘셉트의 빈틈을 초기에 발견해 다음 단계의 손실을 줄이는 안전장치 역할을 합니다.
10절. 제품 개발 단계 (Product Development)
10절은 개념 단계에서 세운 목표와 콘셉트를 실제 제품 설계와 구현에 반영하는 과정입니다. 쉽게 말해, “보안 요구사항을 어떻게 구체적으로 설계에 녹여내고, 실제 코드와 시스템에 반영할 것인가?”를 정의하는 단계라고 볼 수 있습니다. 이 단계에서 중요한 점은 보안 요구사항을 단순히 나열하는 것이 아니라, 실제 제품 개발 과정에서의 보안 약점 관리, 검증 활동, 통합 과정까지 모두 포함해야 한다는 것입니다. 예를 들어, 암호화 모듈을 반드시 사용해야 한다는 요구사항이 있다면, 설계 문서에 그 위치와 동작 방식을 명확히 기록해야 하고, 구현 단계에서는 해당 규칙이 지켜졌는지를 검증해야 한다는 것이죠. 또, 이 과정에서 발견된 약점들은 반드시 기록으로 남겨 관리되어야 하며, 이를 통해 향후 동일한 문제가 반복되지 않도록 해야 합니다. 즉, 10절은 “보안 요구사항을 실제 설계와 구현으로 옮기고, 검증을 통해 증거를 남겨야 한다”는 것을 강조한다고 할 수 있습니다.
- 사이버보안 사양서 - 제품과 컴포넌트 차원에서 사이버보안 요구사항을 정의할 것을 요구합니다. 즉, 제품에 필요한 보안 요구사항이 구체적으로 정리된 문서로, 이후 모든 설계와 구현의 기준이 됩니다
- 개발 이후 단계에 대한 사이버보안 요구사항- 운영·유지보수 등 개발 이후 단계에서도 적용해야 할 보안 요구사항을 정의할 것을 규정합니다. 즉, 출시 이후에도 어떤 보안 조건이 충족되어야 하는지에 대해 정의한 문서입니다
- 모델링·설계·프로그래밍 언어 및 코딩 지침 문서 - 개발에 사용되는 모델링, 설계 언어, 프로그래밍 언어와 코딩 가이드라인을 문서화하도록 요구합니다. 어떤 기준과 규칙에 따라 구현했는지를 추적 가능하게 하는 것이 중요합니다.
- 사이버보안 사양 검증 보고서 - 사이버보안 사양서가 타당한지를 검증할 것을 요구합니다. 사양서가 실제 제품 특성과 일치하고 이에 따라 구현되었다는 것을 보여주는 검증 결과 보고서입니다.
- 제품 개발 중 발견된 약점 목록 - 개발 과정에서 발견된 약점을 문서화할 것을 요구합니다. 또한 테스트를 통해 남아 있는 약점을 최소화해야 한다고 권고하고 있습니다. 즉, 개발 과정에서 드러난 약점들을 정리하고, 개선 여부를 추적할 수 있게 하는 문서입니다.
- 통합 및 검증 사양서 - 어떤 환경과 절차에서 보안을 검증할 것인지, 구성 요소들을 통합해 검증하는 방법과 절차를 정의할 것을 요구합니다. 이에 따라 통합 단계에서 어떤 검증 활동을 어떻게 수행할지에 대한 계획을 다루고 있습니다.
- 통합 및 검증 보고서 – 통합 및 검증 사양서에 대한 수행 결과와 결론을 남긴 보고서입니다. 검증 활동의 결과를 기록할 것을 요구하고, 테스트를 통해 발견된 약점에 대한 확인을 권장하고 있습니다. 즉, 실제 통합 및 검증을 수행한 결과를 정리한 문서로 생각하시면 됩니다.
11절. 사이버보안 검증 (Cybersecurity validation)
11절은 실제 차량 환경과 양산 구성에 대한 개발 계획을 고려해 차량 전체에 대한 보안을 검증하는 단계입니다. TARA 과정에서 도출했던 사이버보안 목표와 클레임이 적절하고 달성되었는지를 확인한다고 볼 수 있죠. 특히 사이버보안 목표가 적절한지와 아이템이 그 목표를 달성했는지, 사이버보안 클레임이 타당한지. 운영 환경 요구사항이 유효한지를 평가합니다. 즉 “우리가 세운 목표와 클레임을 실제 차량 생산 전에 검증하는 단계’입니다.
- 하드웨어 보안 요구사항 문서: TARA 단계에서 도출한 사이버보안 목표의 적절성과 달성 여부, 클레임의 타당성, 운영환경 요구사항 검토 결과가 포함되어야 합니다. 이를 위해 작업 산출물 검토, 침투 시험, 위험 검토 등이 활용되어야 하고, 어떤 검증 방법을 선택했는지와 그 근거를 제시해야 합니다.
12절. 생산 단계 (Production)
12절은 제품이나 차량을 실제로 생산하는 과정에서의 보안 요구사항을 다룹니다. 즉, 제조와 조립 단계에서 새로운 취약점이 끼어들지 않도록 제어하는 것이 핵심입니다 표준은 두 가지 목표를 제시합니다. 첫째는 개발 이후 단계에서 정의된 사이버보안 요구사항을 생산 단계에서도 적용해야 한다는 것이고, 둘째는 생산 과정에서 취약점이 유입되는 것을 방지해야 한다는 것입니다. 또한 이를 위해 표준은 생산 제어 계획을 수립할 것을 요구합니다. 어떻게 실제 생산 과정에서 취약점이 유입되는 것을 제어할 것에 대한 계획을 세워야한다는 것이죠.
- 생산 제어 계획- 생산 공정에서 어떻게 보안 요구사항을 적용하고, 어떤 장비와 절차, 검증 방식을 통해 취약점 유입을 차단할 것인지 상세히 담아야 합니다. 개발 이후에 요구사항을 적용하기 위한 절차와 순서, 생산에 활용되는 도구와 장비를 정확히 명시해야 합니다. 또한 생산 중 무단 변경을 막기 위한 사이버보안 통제에는 어떤 것들이 있는 지 또한 포함합니다. 예를 들어 서버 접근 통제 방법이나 암호기술 적용 등에 대한 내용을 포함해야 하죠.
13절. 운영 및 유지보수 (Operations and Maintenance)
차량이 출시되고 실제 도로 위에서 운행되기 시작하면, 사이버보안은 새로운 국면을 맞이합니다. 개발 단계에서 아무리 철저하게 대비했다고 해도, 운영 중에는 예상치 못한 위협이나 사건이 발생할 수 있기 때문이죠. 새로운 위협을 탐지하고, 취약점이 발견되면 신속히 대응해야 합니다. 13절은 차량이 시장에 출시된 이후의 운영과 유지보수 단계에서 사이버보안을 어떻게 관리해야 하는지를 규정하고 있습니다. 또한 생산 이후부터 지원 종료 시점까지, 업데이트 과정에서도 보안을 유지할 것을 강조하고 있습니다. 13절은 이렇게 정리할 수 있습니다. “운영 단계에서도 사이버보안은 계속된다. 사이버보안 사건이 터졌을 때 당황하지 않도록 대응 계획을 준비하고, 업데이트 과정에서도 보안이 흔들리지 않게 유지하라”
- 사이버보안 사건 대응 계획 - 실제 사건이 발생했을 때 누가 무엇을 어떻게 할지를 구체적으로 정리한 문서입니다. 여기에는 시정 조치 절차, 커뮤니케이션 전략, 책임 체계, 사건 관련 정보 기록 방식, 진행 상황 측정 방법, 종료 기준까지 포함되어야 함을 강조하고 있습니다. 단순한 선언문이 아니라, 실제 현장에서 바로 실행할 수 있는 매뉴얼에 가깝다고 보시면 됩니다.
14절. 보안 지원 종료 및 서비스 해지 (End of Cybersecurity Support & Decommissioning)
차량은 언젠가 사이버보안 지원이 끝나는 시점에 도달합니다. 지원 종료와 서비스 해지는 서로 다른 개념입니다. 지원 종료는 조직이 더 이상 보안 업데이트를 제공하지 않겠다고 선언하는 것이고, 서비스 해지는 실제로 해당 제품이나 부품이 사용을 멈추는 것을 뜻하죠. ISO 21434는 이 둘을 명확히 구분해야 함을 강조하고 있습니다. 조직이 보안 지원을 끝내기로 했을 때는 이를 고객에게 전달하는 절차를 반드시 만들어야 한다고 요구합니다. 또한 서비스 해지의 경우 10절의 ‘개발 이후 단계에 대한 사이버보안 요구사항’에서 서비스 해지과정에서 지켜야할 보안 지침을 포함하고 있어야 함을 명시하고 있습니다.
- 사이버보안 지원 종료 절차 - 이 문서는 바로 위 요구사항을 충족하기 위한 결과물입니다. 보안 업데이트 제공을 언제, 어떻게 종료할지, 그 사실을 고객과 사용자에게 어떤 방식으로 알릴지를 체계적으로 담아야 합니다
이번 2편에서는 ISO 21434의 9절부터 14절까지, 자동차 개발 V-사이클에 따라 각 단계에서 요구되는 사이버보안 활동들을 살펴봤습니다. 자동차의 생애 전 주기에 걸쳐 보안은 처음부터 끝까지 끊김 없이 이어져야 한다는 것과, 각 단계에서 필요한 보안 활동들에 대한 감을 잡으셨다면 좋겠네요..! 다음 3편에서는 15절에서 정의한 TARA에 대한 자세한 설명을 중심으로, 실제 위협과 위험을 어떻게 체계적으로 분석하는지를 살펴보겠습니다.
