자동차 산업은 빠르게 디지털화되고 있습니다. 특히 SDV의 등장은 이런 변화를 가속화 시키는 원동력이 되고 있습니다. 이런 변화는 편리함과 혁신을 가져왔지만, 동시에 새로운 위험도 만들어 냈습니다. 해커가 차량 시스템을 악용한다면, 단순한 개인정보 유출을 넘어 운전자와 보행자의 생명 안전까지 위협받을 수 있습니다.
이러한 배경 속에서 국제 표준 ISO/SAE 21434가 등장했습니다. 이 표준은 자동차 사이버보안을 위한 종합적인 프레임워크로, 시스템 개발 단계부터 양산 이후까지 전 과정에서 보안을 관리하도록 요구합니다. 핵심 목표는 명확합니다. 바로 “Unreasonable Risk(비합리적 위험)”을 제거하는 것입니다.
기능안전과 사이버보안의 차이
자동차 시스템의 안전을 다루는 분야에는 크게 두 가지가 있습니다. 하나는 기능안전(Functional Safety), 다른 하나는 사이버보안(Cybersecurity)입니다. 두 영역은 모두 안전과 신뢰성을 다루지만, 접근 방식과 관리 방법은 다릅니다.
기능안전: 예측 가능한 위험 관리
기능안전은 ISO 26262 표준에 기반합니다. 개발 초기 단계에서 HARA(Hazard Analysis and Risk Assessment)를 수행하여 잠재적 위험을 식별하고, 이에 따라 ASIL(Automotive Safety Integrity Level)이라는 등급을 부여합니다.
ASIL은 시스템이 어느 수준의 안전성을 달성해야 하는지를 정의하는 기준으로, 보통 개발 초기부터 설계 전반에 걸쳐 유지됩니다. 물론 큰 설계 변경이나 새로운 위험 요소가 드러날 경우 재검토될 수 있지만, 기본적으로는 비교적 안정적인 기준입니다.
예를 들어 스마트 크루즈 컨트롤(SCC)의 경우, 속도 제어 실패가 운전자와 보행자에게 어떤 위험을 미칠 수 있는지 분석하고, 그 결과 ASIL B나 C 등급을 할당받을 수 있습니다.
사이버보안: 끊임없이 변하는 위험
반면 사이버보안은 성격이 다릅니다. 사이버 위협은 정적인 것이 아니라, 시간에 따라 지속적으로 변하는 특성을 가집니다.
새로운 해킹 기술이 등장하고, 아직 알려지지 않았던 취약점이 발견되며, 공격자들은 기존의 방어책을 우회하는 방법을 계속 찾아냅니다. 따라서 초기 개발 단계에서 완벽하게 안전하다고 판단된 시스템도, 시간이 지나면 위험에 노출될 수 있습니다.
특히 자동차 개발은 1~2년 이상 장기간에 걸쳐 진행되기 때문에, 설계·개발 단계에서도 외부에서 새롭게 보고되는 CVE, CWE와 같은 취약점이나 공격 기법들을 지속적으로 식별·분석해야 합니다. 이를 통해 개발 중인 아키텍처의 Attack Surface나 자산(Asset)에 영향이 없는지, 그리고 변경되는 기능·구조에 추가적인 위험이 없는지를 반복적으로 검토하는 활동이 필요합니다.
이 때문에 ISO/SAE 21434는 개발 이후에도 모니터링과 대응을 계속 이어가야 한다고 요구합니다. 즉, 사이버보안은 한 번으로 끝나는 일이 아니라, 개발 단계부터 양산 이후 운용 단계까지 이어지는 지속적인 관리가 필요한 여정입니다.
TARA: 위협 분석과 위험 평가
사이버보안 활동의 핵심 프로세스는 TARA(Threat Analysis and Risk Assessment)입니다. TARA는 말 그대로 위협을 분석하고 위험을 평가하는 절차로, 다음과 같은 단계로 진행됩니다.
- 손상 시나리오(Damage Scenario) 도출
시스템이 공격받거나 손상되었을 때 어떤 결과가 발생할지 상상합니다.
예: 해커가 SCC의 속도 제어를 장악해 갑자기 가속하거나 급정지시킬 경우, 이는 고속도로 주행 중 심각한 사고를 유발할 수 있습니다. - 위협 시나리오(Threat Scenario) 식별
- 손상 시나리오를 일으킬 수 있는 구체적인 공격 방법을 찾습니다.
예:- CAN 버스에 악성 메시지를 주입하는 공격
- OTA 서버를 해킹하여 악성 펌웨어를 차량에 배포하는 공격
- Risk Value 산정
- 각 위협은 두 가지 기준으로 평가됩니다.
- Impact(영향): 위협이 현실화되었을 때 미치는 피해의 심각도
- Attack Feasibility(공격 가능성): 공격자가 실행할 수 있는 가능성과 난이도
ISO/SAE 21434는 이 두 요소를 조합해 위험 값을 도출하도록 요구합니다. 실제 프로젝트에서는 이를 숫자 등급으로 표현하는 경우가 많습니다. 예를 들어 1(낮음)~5(매우 높음)과 같은 스케일이 널리 사용됩니다.
예시로, SCC 속도 제어 조작은 Impact가 높고(사고 발생 가능), Attack Feasibility가 중간 수준이라면, 조직의 평가 기준에 따라 Risk Value 4로 분류될 수 있습니다.
위험 대응 활동
TARA에서 산정된 Risk Value를 기반으로 적절한 대응 활동이 이루어집니다. 대표적인 접근은 다음과 같습니다.
- 수용(Accept): 위험이 충분히 낮다고 판단되는 경우 별도 조치 없이 받아들입니다.
- 공유(Share): 제3자와 위험을 분담합니다. 예를 들어 클라우드 기반 OTA 시스템의 위협은 클라우드 제공업체와 협력하여 관리할 수 있습니다.
- 경감(Mitigate) 또는 제거(Remove): 높은 수준의 위험은 보안 기능을 추가하거나 설계를 변경하여 줄이거나 제거해야 합니다.
예시:
- CAN 버스 공격(Risk Value 4) → 메시지 인증 코드(MAC) 추가, ECU에 보안 모듈(HSM) 탑재
- OTA 서버 공격(Risk Value 3) → 다중 인증과 침입 탐지 시스템(IDS) 적용
Cybersecurity Validation: Unreasonable Risk 제거 확인
위협에 대응하는 조치를 설계하고 구현했다면, 이제 그것이 실제로 효과적인지 확인해야 합니다. 이 단계가 Cybersecurity Validation입니다.
- Cybersecurity Case 작성
- 위험이 낮아 수용된 항목도 문서화하여, 왜 해당 위험이 허용 가능한지를 증거와 함께 설명합니다.
- 검증 활동 수행
- 위험도가 높은 위협은 모의해킹(Penetration Test)이나 코드 리뷰, 정적·동적 분석 등 다양한 검증 방법을 통해 실제로 방어가 가능한지 확인합니다.
- Unreasonable Risk 제거 입증
- 모든 위협이 수용·경감·제거된 상태임을 검증 결과로 보여줍니다. 이 과정을 통과하면 시스템은 “Unreasonable Risk가 없는 상태”로 간주되어 양산할 수 있습니다.
SCC 사례로 본 적용 과정
스마트 크루즈 컨트롤(SCC)을 예로 들면, 다음과 같이 ISO/SAE 21434의 프로세스를 적용할 수 있습니다.
- TARA 분석
- 손상 시나리오: 해커가 SCC를 조작해 갑작스러운 가속·정지를 유발
- 위협 시나리오:
- CAN 버스 공격
- OTA 서버 해킹
- Risk Value: CAN 버스 공격은 4, OTA 서버 공격은 3
- 위험 대응
- CAN 버스 공격 → MAC 적용, ECU 보안 모듈 통합
- OTA 서버 공격 → 다중 인증, IDS 적용
- Validation
- 검증 활동(예: 모의해킹)으로 방어 체계가 작동하는지 확인
- 결과적으로 모든 위협이 허용 가능한 수준으로 관리됨 → SCC 양산 가능
지속적인 모니터링의 중요성
사이버보안은 여기서 끝나지 않습니다. 새로운 공격 기법과 취약점은 시간이 지나면서 계속 발견됩니다. 따라서 ISO/SAE 21434는 운용 단계에서도 지속적인 관리를 강조합니다.
- 취약점 모니터링: CERT 보고서, 보안 패치 모니터링
- OTA 업데이트: 정기적 보안 패치를 통한 취약점 해결
- 사건 대응: 실제 공격 발생 시 신속한 대응과 분석
결론
ISO/SAE 21434는 자동차 산업에서 사이버보안을 위한 체계적인 가이드라인을 제공합니다.
- TARA로 위협을 분석하고,
- Risk Value를 기반으로 대응책을 마련하며,
- Validation으로 위험이 실제로 제거되었음을 입증합니다.
스마트 크루즈 컨트롤 사례처럼 구체적으로 적용해보면, 표준이 단순한 문서가 아니라 실제 안전한 시스템을 만드는 과정임을 알 수 있습니다. 무엇보다 중요한 점은, 사이버보안은 한 번의 작업으로 끝나지 않는다는 것입니다. 지속적인 모니터링과 대응을 통해서만 안전하고 신뢰할 수 있는 자동차 시스템을 구축할 수 있습니다.