고객의 니즈를 정확히 파악해 맞춤형 솔루션 제시하는, 자동차 전문 BM 이민표 팀장
- 고객의 요구사항을 반영하여 자동차에 특화된 KMS를 설계하는, 자동차 KMS 전문 PM 노준호 매니저
- 임베디드 제어기 환경에 최적화된 보안 기능을 구현하는, 자동차 보안솔루션 개발자 박경연 선임
4. KMS 구축을 위한 OEM 요구사항에는 어떤 것들이 있나요?
5. KMS를 구축한 실제 사례를 듣고 싶어요.
6. KMS를 도입함으로써 제어기 생산에 문제가 발생하진 않나요?
8. OEM의 보안 요구사항을 이해하고 분석하는 방법이 있을까요?
9. 보안 기능을 구현한 뒤, 산출물을 어떻게 만들어야 할지 모르겠어요.
■ 텍스트 Ver.
1. OEM에서 KMS를 적용하라고 합니다. KMS가 왜 필요할까요?
KMS는 Key Management System의 약자로, IT 산업에서 널리 사용하고 있습니다. 메신저의 메시지를 암·복호화 하거나 금융거래 시 사용자를 인증하는 인증서도 KMS 사례로 보시면 됩니다.
최근 자동차 산업에서도 KMS 요구사항이 많이 언급되고 있습니다. KMS는 안전하게 Key를 발급하고 관리하는 시스템으로써 사용자에게 암호키와 복호화키를 배포하게 됩니다. 발신처는 암호키를 통해 정보를 암호화하고 수신처에서는 전달된 정보의 암호해제 목적으로 복호키를 이용하게 됩니다.
자동차 산업에서 KMS에 대한 요구가 증가한 이유는 다음과 같습니다. 자동차 내 커넥티드 기능이 증가하고 차량이 소프트웨어 중심으로 개발됨에 따라 다양한 사이버보안 위협에 노출되고 있기 때문입니다. 이에 유럽, 중국 등 많은 국가에서 자동차 사이버보안을 법제화하였고, 우리나라에서도 올해 하반기부터 자동차관리법을 시행합니다. OEM은 유럽의 사이버보안 법규인 UN R155와 사이버보안 엔지니어링 국제 표준인 ISO/SAE 21434를 준수해서 차량을 개발해야 합니다. 이러한 사이버보안 법규는 보안을 강화하기 위한 것으로, OEM은 Tier들을 대상으로 KMS 적용을 요구하고 있습니다.
KMS는 생산되는 수십, 수백만 대의 자동차 대상으로 개별키와 인증서를 관리합니다. 향후에는 ECU를 생산하는 협력사들도 KMS를 구축 운영하여 사이버보안을 강화할 예정입니다.
KMS는 차량 및 ECU의 키를 발급하고 관리하는 시스템으로, 인가된 사용자만 차량 및 ECU에 접근할 수 있는 보안을 구축합니다.
OEM별 KMS 요구사항에 차이는 있지만 대표적으로 Secure Debug, Secure Flash, SecOC 등을 보안기능에 활용합니다. Secure Debug는 ECU에 접근할 수 있는 개별 패스워드를 사용하는 보안기능이며, Secure Flash는 인증된 펌웨어만 사용되도록 하는 기능입니다. 또 SecOC는 키를 이용하여 메시지의 무결성을 검증하는 기능입니다.
이러한 보안기능들은 KMS에서 발급되는 키와 인증서를 통해 적용할 수 있으며, 사이버보안 이벤트가 발생된다면 KMS를 통해 출고 이후 차량과 ECU의 키를 변경하여 보안을 유지할 수 있습니다.
2. KMS 구축 시 SecOC도 적용하라는데, 어떤 연관성이 있나요?
SecOC는 ECU 간 통신메시지의 무결성과 신뢰성을 보장하기 위한 보안 기능입니다. Broadcast 통신 시, 어느 ECU가 언제 호출한 메시지인지, 언제 응답한 메시지인지 검증이 필요합니다. 흔히 사용되는 해킹방법 중에 기존 메시지 위변조 공격과 재전송 공격이 있습니다.
SecOC는 이러한 공격을 방지하기 위해 호출과 응답 메시지에 MAC(Message Authentication Code)값과 FV(Freshness Value)값을 포함하며 MAC값 생성에 필요한 키값은 KMS를 통해 구현하게 됩니다. SecOC를 적용하더라도 오랜 기간 키값을 사용하게 되면 해당 메시지도 악용될 수 있습니다. 이를 방지하기 위해 KMS에서 키 재발급을 통해 MAC값을 컨트롤할 수 있습니다. OEM 요구사항에서는 키를 언제든지 변경할 수 있도록 요구하고 있습니다.
3. KMS 구축 방법을 알고 싶어요.
금융 및 IT산업의 KMS는 인터넷 및 네트워크에서 서버 사이드에 구축됩니다. 하지만, 자동차 산업의 KMS는 OEM 요구사항 분석부터 서버 간 연동, ECU 키 주입, 보안 기능까지 고려해야 하므로 다양한 기술을 요구합니다. 자동차 산업에서 KMS에 필요한 기술은 IT기술, 보안기술, 임베디드 역량이 있습니다.
대표적인 OEM 요구사항을 설명을 드리겠습니다. OEM 서버와 Tier KMS 서버를 연동하고, 인증서를 통해 증명된 KMS만 키를 받을 수 있습니다. 생산라인에서는 MCU ID를 확인하여 KMS에서 ID가 반영된 키를 생성합니다. KMS에서 생성된 키가 ECU 디버그포트를 통해 MCU의 안전한 공간(HSM)에 주입됩니다. 이것이 전체 시나리오라고 볼 수 있습니다.
KMS는 OEM의 요구사항을 준수하여 구축해야 합니다. OEM의 KMS 요구사항 중 대표적인 두 가지 운영방식이 있습니다. 두 가지 운영방식의 차이는 생산지에 따른 KMS 구축 위치입니다.
통합 운영방식은 중앙시설물에 KMS를 구축하고 각 생산지에 키를 전달하는 방식입니다. KMS가 구축되는 장소는 보안시설까지 요구하며 이미 마련된 물리적 보안과 안정된 시설에 KMS를 구축하고 각 생산지에 키를 발급하게 됩니다. 이 경우 운영관점에서 비용 및 시간을 절감할 수 있습니다. 다만 많은 생산지에 키를 중앙에서 발급하는 경우, KMS 서버 사양도 고려해야 합니다.
로컬 운영방식은 각 생산거점에 KMS를 개별로 구축하는 방식입니다. 이 방식은 개별로 운영되어 네트워크 구조가 통합 운영보다 단순화할 수 있는 장점이 있습니다. 하지만 각 생산거점의 보안시설 준수, 전문 인력을 통한 관리가 필요합니다. 따라서 생산지가 많은 경우 운영비용이 함께 증가됩니다.
4. KMS 구축을 위한 OEM 요구사항에는 어떤 것들이 있나요?
KMS 요구사항은 OEM마다 천차만별이어서 한 마디로 정의하기 어렵습니다. 일부 OEM은 HW스펙부터 키 주입 플로우까지 자세하게 정의된 요구사항을 제공합니다. 반면 다른 OEM은 대략적으로 키 또는 인증서를 관리할 시스템을 적용할 것을 요구하기도 합니다. Secure Debug, Secure Flash, SecOC 등 보안기능 요구사항도 적용 범위와 방식에 따라 차이가 있습니다. 따라서 OEM의 요구사항과 Tier의 상황에 최적화된 솔루션을 찾아내는 것이 KMS 구축의 성패를 결정하는 요소라고 할 수 있습니다.
5. KMS를 구축한 실제 사례를 듣고 싶어요.
페스카로가 Tier용 KMS를 구축한 사례 중 하나를 설명드리겠습니다. 저희와 협력한 고객사는 OEM별 KMS를 구축하기보다는, 하나의 KMS로 다양한 OEM의 요구사항을 대응하기를 원하셨습니다.
그래서 고객사가 OEM으로부터 받은 요구사항 및 고객사의 확장 계획에 부합하도록, 다른 OEM과 다른 제어기 추가를 고려하여 유연성과 확장성을 갖춘 KMS를 구축해 드렸습니다. OEM과 제어기를 직접 등록 및 매핑할 수 있기 때문에, 한 번의 KMS 구축으로 앞으로의 프로젝트에서 발생할 KMS 요구사항을 대응할 수 있게 되었습니다. 또한 프로젝트별·제어기별 담당자를 지정할 수 있어 지정된 사용자만이 관련 업무를 수행할 수 있도록 보안성을 강화했습니다. 업무 체계화와 자동화를 통해 효율성과 편리함을 크게 높여 드렸습니다.
그럼 OEM마다 다른 보안 기능 요구사항을 어떻게 충족할 수 있었는지 설명드리겠습니다. 페스카로는 프로젝트마다 Secure Debug, Secure Flash 등 OEM의 요구사항을 선택적으로 적용할 수 있게 했습니다. 또한 사용할 암호화 알고리즘, 전자서명 유형 등 OEM이 요구한 보안기능에 맞춰 선택할 수 있도록 제공했습니다.
최근 많은 OEM에서 KMS 도입을 요구하면서 어떻게 대응해야 할지 고민이 많으실 것 같습니다. 수동적으로 요구사항만을 맞춰 개발하는 업체보다는 전문적으로 요구사항을 분석하고 Tier사의 상황에 맞춰 적용할 수 있는 업체와 협력하시는 것을 추천드립니다. 유관 부서나 OEM과 소통하며 요구사항을 조율하고 고객사에 최적화된 보안 컨셉과 보안 정책을 선제적으로 제안할 수 있는 기업이면 더욱 좋습니다. 페스카로는 OEM과 Tier에 KMS를 성공적으로 구축한 경험이 있습니다. 이런 노하우를 통해 고객사에 최적화된 KMS를 제안드리고, 또 성공적으로 구축할 수 있도록 지원하겠습니다.
6. KMS를 도입함으로써 제어기 생산에 문제가 발생하진 않나요?
KMS 공정 추가에 따른 사이드이펙트(Side-Effect)에 대한 우려가 있으실 것입니다. 서버 고장 또는 네트워크 에러가 발생 시 라인이 멈추지는 않을지, 공정 추가로 생산성이 저하되지는 않을지, 라인 확장 시 추가 구축 비용이 크게 증가하지는 않을지 걱정될 수 있습니다. 특히 해외에 생산설비가 있을 경우 더욱 신경이 쓰일 것입니다.
고객사의 조건과 OEM의 요구사항을 모두 고려하여 Risk를 낮출 수 있는 구조를 설계할 수 있는 업체와 협력하시는 것을 추천드립니다.
페스카로는 Side-Effect 감소에 최적화된 KMS를 구축한 경험이 있습니다. 생산시간 증가 최소화, 통신 장애로 인한 생산 중단 최소화라는 두 가지 포인트를 극대화하여 최적의 생산라인 연계 컨셉을 도출했습니다.
그 결과로 그림과 같은 방법으로 KMS를 구현했습니다. KMS 서버는 사전에 다수의 키를 생성해 놓고 일정 시간에 일정량의 키를 전송합니다. 예를 들어 라인 유휴 시간에 각 라인의 EOL 공정 프로그램과 서버가 통신하여 키를 전송합니다. 생산이 재개되면 EOL 공정 프로그램은 미리 받아둔 키를 사용하여 키 주입을 이어갈 수 있습니다.
이 구조는 키를 필요할 때마다 키를 생산하지 않고, 키 주입 시마다 서버와 통신할 필요가 없습니다. 따라서 추가적인 단위 생산 시간의 증가를 최소화할 수 있습니다. 또한 라인이 충분한 개수의 키를 서버로부터 확보하고 있어 통신 이슈로 인한 Side-Effect에서 비교적 자유롭습니다. 중앙집중형 서버이기 때문에, 라인을 확장 시 추가 서버를 구축할 필요가 없어 확장에 따른 추가 비용 절감 효과도 있습니다. 페스카로처럼 KMS 구축 시 Side-Effect를 최소화할 수 있는 방안을 함께 제안드리는 업체와 협업하시는 것을 추천드립니다.
7. OEM이 요구하는 대표적인 보안 기능이 궁금해요.
완성차 제작사(OEM)에서 요구하는 보안 기능은 차량 안전성, 해킹방지, 개인정보 보호 등을 보장하기 위해 여러가지 기술적 요구사항을 포함합니다. 이와 관련된 주요 보안 기능과 중요성은 다음과 같습니다.
(1) Secure Boot
Secure Boot는 차량의 부팅 과정에서 시스템의 무결성을 검증한 후 실행하는 기능입니다. 악성 소프트웨어나 변조된 펌웨어가 제어기 내에서 실행되지 않도록 방지합니다. 예를 들어, 전자서명된 펌웨어만 로드하게 하고 서명이 없는 펌웨어는 부팅을 차단합니다. 이를 통해 차량의 시스템이 오염되거나 해킹당하는 것을 방지할 수 있습니다.
(2) Run-Time Tuning Protection (RTP)
Run-Time Tuning Protection(RTP)은 제어기 시스템이 실행 중에 적용되는 기능입니다. RTP는 애플리케이션이나 제어기 동작과 관련된 중요 데이터 영역의 무결성을 실시간으로 검사합니다. 이를 통해 제어기 동작 중 외부 공격으로부터 데이터가 변조되는 것을 방지하고, 시스템의 안전성과 예측 가능한 동작을 보장합니다.
(3) Secure Debug
Secure Debug는 JTAG과 같은 디버그 인터페이스에 대한 접근을 제한하는 기능입니다. 양산 이후 외부에서 디버깅 포트를 통해 제어기 내에 존재하는 민감한 정보에 접근하지 못하도록 방지하며, 디버그 포트를 비활성화하거나 인증된 사용자만 디버깅 모드에 접근할 수 있도록 합니다. 이를 통해 공격자가 시스템의 취약점을 파악하고 악성 소프트웨어를 삽입하는 것을 방지할 수 있습니다. 일반적으로 패스워드나 Challenge-Response 기반의 인증 방식이 사용됩니다. 제어기별로 혹은 제어기 모델별로 패스워드 개별화 사양을 요구하는 OEM도 있습니다.
(4) Access Control
Access Control은 차량 시스템에 대한 접근을 관리하고 제한하는 기능입니다. 특정 사용자나 프로세스만이 민감한 데이터나 시스템에 접근할 수 있도록 제어합니다. 차량의 중요한 구성 요소나 데이터를 보호하고, 인증되지 않은 사용자가 시스템에 접근하는 것을 방지합니다. 대표적으로 UDS 0x27(Security Access) 서비스나 DAC(Discretionary Access Control), MAC(Mandatory Access Control) 적용이 여기에 해당될 수 있습니다.
(5) Secure Flash
Secure Flash는 차량의 플래시 메모리에 저장된 소프트웨어나 펌웨어를 안전하게 업데이트하는 기능입니다. 펌웨어 업데이트 과정에서 암호화된 통신을 사용하거나, 신규 펌웨어에 대한 전자서명을 검증하여 인가된 펌웨어에 대해서만 리프로그래밍을 허용합니다. 플래시 메모리에서의 데이터 쓰기 권한을 제어하여 외부에서의 변조나 악성 코드 삽입을 방지할 수 있습니다.
(6) Secure Storage
Secure Storage는 보안 기능 동작에 필요한 암호화 자산을 안전한 영역에서 보호하는 기능입니다. 차량 내부의 중요한 데이터(암호키, 비밀번호, 인증서 등)을 암호화하여 보호하고, 외부 공격자가 해당 데이터를 추출하거나 변조할 수 없도록 합니다. 이와 함께 HSM이나 Memory Protection 요구사항이 포함될 수 있습니다. 이외에도 OEM에서는 SecOC, FOTA(Firmware Over-the-Air), 보안코딩 준수, 정적·동적 검증 수행 등을 요구하고 있습니다. 각 보안 기능은 차량의 하드웨어와 소프트웨어를 보호하고 외부 공격이나 비인가 접근을 방지하는 데 필수적입니다.
이러한 기능들이 제대로 작동하지 않으면 차량은 악성 공격에 취약해지고 해킹이나 데이터 유출, 원격 조작과 같은 위험이 발생할 수 있습니다. 차량 운행 중 발생할 수 있는 외부 공격을 차단하거나 탐지하기 위해 페스카로의 자동차 사이버보안 전문 솔루션을 활용하시면 좋을 것 같습니다.
8. OEM의 보안 요구사항을 이해하고 분석하는 방법이 있을까요?
OEM마다 보안 요구사항을 정의할 때 자체적인 표준이나 정책, 용어를 사용하기 때문에 이를 해석하는 데 어려움이 있으신 것 같습니다. 예를 들어, Secure Boot이나 Secure Flash와 같은 보안 기능은 기본적으로 동일한 개념일 수 있지만, 각 OEM에서는 이를 다르게 정의하거나 추가적인 요구사항을 첨부할 수 있습니다. 실제 OEM 보안 요구사항을 예로 들어 몇 가지 Tip을 드리겠습니다.
(Tip. 1) 보안 요구사항의 R&R(Role & Responsibility)을 구분하는 것이 중요합니다.
(Tip. 2) 여러 요구사항들 간의 문맥을 통해 구현이 필요한 항목을 도출할 수 있습니다.
(Tip. 3) 암호키가 사용되는 요구사항에서는 해당 키를 생성·관리하는 주체, 키를 주입하는 시점, 그리고 업데이트 여부 등을 파악하는 것이 중요합니다. 만약 OEM에서 Secure Flash 기능을 요구한다고 했을 때 각각의 주체들, 다시 말해 제어기나 Supplier EoL, KMS 혹은 OEM 자체적으로도 적용해야 하는 요구사항은 서로 다를 것입니다.
M사의 Secure Flashing 요구사항의 일부를 발췌하여 구체적으로 설명드리겠습니다.
(SF-01) “KMS는 Secure Flashing을 위한 전자서명을 생성하는 데 사용되는 필수 암호화 자료를 저장해야 한다.”
1번 요구사항에서는 명확히 KMS에게 요구하는 내용을 명시하고 있습니다. 이 요구사항을 통해 KMS가 Secure Flash용 전자서명을 생성하는 주체이자 관련 자료를 관리하는 주체임을 알 수 있습니다.
(SF-02) “서명 인증서는 참조된 역할이 플래시 논리 블록에 서명할 수 있는 경우에만 승인되어야 한다.”
2번 요구사항에서는 1번 요구사항과는 달리, 주체가 명확히 나와있지 않습니다. 하지만 1번 요구사항을 통해 펌웨어에 대한 전자서명을 생성하는 주체가 KMS임을 알 수 있었습니다. 따라서 이 요구사항은 KMS와 KMS 사용자의 관계에 적용되는 내용입니다. KMS 사용자는 서명 권한을 가진 인증서를 가지고 있어야 하고, 해당 역할이 없으면 새로운 펌웨어에 대한 서명할 수 없다는 내용으로 해석할 수 있습니다.
이렇게 요구사항 간 문맥을 통해 실제 구현이 필요한 상세 항목을 도출하고 각 주체들의 역할도 명확하게 정의할 수 있습니다.
(SF-03) “KMS는 전자서명을 위해 RSA_SSA_PSS을 사용해야 한다.”
3번 요구사항은 KMS가 전자서명을 생성할 때 사용할 알고리즘을 지정하고 있습니다. 이를 통해 제어기 개발자는 UDS 기반으로 펌웨어 리프로그래밍을 할 때 RSA 전자서명 검증 기능을 제공해야 한다는 것을 알 수 있습니다.
(SF-04)“MES는 (시리즈)장치가 (시리즈)키와 함께 공장을 떠나도록 보장해야 한다."
만약 KMS의 운영 주체가 Supplier라고 했을 때 이 요구사항에서 말하는 키는 Supplier KMS에서 생성될 것입니다. 그 경우 이 요구사항은 OEM 공정이 아닌, Supplier의 생산공정에 적용되어야 함을 알 수 있습니다. 이 요구사항을 만족시키 위해 각 주체들은 어떤 기능을 제공해야 할까요?먼저 Supplier EoL에서, KMS는 MES와 연동하여 RSA 공개키를 MES로 전송해야 합니다. MES는 다시 제어기에게 키를 전송해야 하고, 마지막으로 제어기는 MES로부터 RSA 공개키를 전송받아 프로그램해야 할 것입니다.
그렇다면 제어기 개발자들은 이 요구사항에 대해 지속적인 질문사항이 생길 수 있습니다. 이 질문들은 다음과 같이 정리할 수 있습니다. 그렇다면 제어기 개발자들은 또 이 요구사항으로부터 몇가지 질문사항이 생길 수 있습니다. 공개키를 제어기 어디에 저장해야 하는지? Pflash에 하드코딩하여 저장해도 되는지? 혹은 HSM에 저장해야 하는지?혹은 RSA 공개키를 공정 프로그램으로부터 어떻게 전송받아야 하는지? UDS를 통해 전송받으면 되는지? 받을 때는 무결성만 유지하면 되는지? 암호화되어야 하는지? 암호화되어야 한다면 어떤 키로 또 어떤 알고리즘으로 암호화해야 하는지? 등과 같이 계속해서 꼬리에 꼬리를 무는 질문사항이 생길 수 있습니다. 이러한 질문들은 5번 요구사항을 함께 보시면 됩니다.
(5) “ECU는 HSM을 Secure Flashing을 위한 Trust Anchor로 사용해야 한다."
5번 요구사항은 RSA 공개키를 HSM에 저장하고 이를 통해 전자서명을 검증하는 방식으로 요구를 충족시킬 수 있습니다. 4번 요구사항에서 생겼던 첫 번째 질문이 5번 요구사항을 통해 명확해졌습니다. 이처럼 OEM의 보안 요구사항을 분석할 때 각 요구사항을 종합적으로 이해하고 어떤 시스템에 어떤 기능을 구현해야 하는지에 대해 세부 항목이나 기능을 식별하는 것이 중요합니다.
이어서 팁을 전달드리겠습니다.
(Tip. 4) 동일한 요구사항이지만 방법론이 다를 수 있습니다. 다음은 L사의 Secure software update 보안 요구사항 일부를 발췌한 것입니다.
(SSU-01) “소프트웨어 이미지는 ECDSA로 서명해야 한다.”
(SSU-02) “이미지 해시의 서명을 얻기 위해 OEM code-sign server 접근을 위한 code signing client를 제공한다.”
앞에서 설명드린 M사의 Secure Flashing 요구사항에서는 리프로그래밍 시 RSA를 요구하고 있지만, L사에서는 소프트웨어 업데이트를 위해 ECDSA 서명을 요구하고 있습니다. 또한 OEM code-sign serve라는 용어를 사용하는 것으로 보아 L사에서는 OEM이 직접 signing 서버를 운영하고, 키를 관리하고 있음을 알 수 있습니다. 그렇다면 이 경우에는 OEM의 EoL에서 직접 ECC 공개키를 프로그램하거나, OEM으로부터 생산용 키를 전달받아 Supplier EoL에서 프로그램하는 방식으로 요구사항을 만족시킬 수 있습니다.
(Tip. 5) Secure Boot과 RTP와 같이 펌웨어에 대한 무결성 검증을 요구하는 사항에 대해서는 검증 대상을 명확히 해야 합니다. OEM에서 Root of Trust를 요구하더라도 제어기 부팅 시간제한이 있을 수 있습니다. 이 경우, 부팅 타임에 검증할 대상과 런타임 중 검증할 대상을 분리하여 Secure Boot과 RTP 기능을 적절히 활용하는 것도 방법이 될 수 있습니다.
(Tip. 6) SecOC와 같이 통신 보안을 요구하는 사항에 대해서는 통신 대상과 보호 대상 즉, 보호 메시지를 명확히 하는 것이 중요합니다. 특히, SecOC는 일반적으로 대칭키를 기반으로 동작하는 보안 기능입니다. 따라서 현재 개발 중인 제어기가 통신하는 제어기는 어떤 것들이 있는지, 어떤 메시지들을 보호해야 하는지, 사용하는 키는 제어기 별로 Unique한지, 공통 키를 사용하는지, Freshness Value를 관리하는 제어기가 별도로 있는지 등을 파악하는 것이 중요합니다.
OEM마다 사용하는 용어는 다를 수 있지만 기본적인 보안 요구사항들은 대체로 유사합니다. 오늘 공유드린 팁을 활용하여 OEM들이 사용하는 용어를 정확히 해석하고, 상세 항목들을 정의하고 또 구현해야하는 기능을 명확히 한다면 보안 요구사항 분석에 도움이 되실 것 같습니다.
9. 보안 기능을 구현한 뒤, 산출물을 어떻게 만들어야 할지 모르겠어요.
요구사항을 정확히 분석했다면 산출물 작성은 어렵지 않습니다. 산출물은 기술적이지만 명확하고 이해하기 쉬운 언어로 작성해야 합니다. 또한, 보안 요구사항에서부터 각 보안 기능 구현, 검증 과정, 수정 사항까지 전체적인 추적 가능성을 확보해야 합니다. 각 요구사항이 어떻게 해결되었는지를 문서화하고, 이를 통해 검증 및 개선이 이루어졌음을 명확히 해야 합니다. 또한 보안 요구사항이나 기능 구현, 검증 과정에서 변경사항이 생겼을 때 버전관리를 통해 문서에 기록해야 하며, 언제 무엇이 왜 변경되었는지를 명확히 해야 합니다. 제어기 협력사들이 사이버보안과 관련하여 제출해야 하는 문서에는 어떤 것들이 있는지 살펴보겠습니다.
(1) 보안 요구사항 명세서: 고객의 보안 요구사항을 정확히 분석하고, 해당 요구사항을 만족시키는데 필요한 보안 기능을 도출합니다. 예를 들어, 인증, 암호화, 접근 제어, 무결성 검증 등 필요한 보안 기능을 정의합니다. 만약 이때 불분명한 부분은 반드시 명확히 하고, 요구사항과 실제 구현이 일치하는지 체크합니다.
(2) 보안 기능 상세 설계서: 설계 시, 각 보안 요소가 어떻게 시스템 내에서 상호작용할지 명확히 정의해야 합니다. 예를 들어, 암호화가 필요한 데이터를 정의하고 해당 데이터를 처리하는 방법을 설계합니다.
(3) 보안 검증 계획 및 결과 보고서: 보안 기능이 제대로 작동하는지 확인하기 위해 기능별 단위 테스트와 통합 검증 테스트를 수행합니다. 테스트가 이루어진 환경을 기록하고 테스트 과정에서의 보안 취약점이 없는지, 요구사항을 충족하는지를 확인하여, 테스트 결과를 상세하게 기록하여 검증합니다. 이때 자동화된 보안 검사 도구나 펜테스트 도구를 사용할 수 있습니다.
(4) 위험 평가 및 대응 문서: 보안 기능 구현 후, 남은 위험 요소를 평가하고 이를 개선하기 위한 대응책을 마련합니다. 필요시, 추가적인 보안 패치를 적용하거나, 시스템 모니터링 도구를 도입합니다.
페스카로는 프로젝트가 완료되는 시점까지 고객사가 OEM의 보안 요구사항을 만족할 수 있도록 적극적으로 대응하고 있습니다. 자동차 보안솔루션, 그리고 산출물까지 고민이 있으시면 페스카로에 연락 부탁드립니다.