<보안고민상담소> 소개
페스카로는 자동차 산업 관계자들의 사이버보안 고민 해소를 위해 <보안고민상담소>를 운영하고 있습니다. 올해는 실시간 웨비나 형태로 아래 네 가지 주제를 다루었습니다. 실무진에서 가장 많이 하는 질문에 페스카로의 전문가 패널이 답변하는 형식으로 진행하여 좋은 반응을 얻었습니다. 혹시 관심 있는 주제를 놓쳤다면 아래 링크를 클릭하여 녹화본과 텍스트 정리본을 모두 확인할 수 있습니다.
1️⃣ 자동차 사이버보안 대응 전략
9월 20일 개최한 페스카로의 <유럽 필수 인증 VTA 성공 사례 기반 자동차 사이버보안 테스트 TALK> 웨비나가 성황리에 마무리되었습니다. 그동안 보안테스트에 대한 문의를 꾸준히 받아 준비한 웨비나인 만큼, 60여 개 기업에서 100여 명이 신청해 주셨습니다.
완성차 제작사는 형식승인(VTA)을 위해 제어기 및 실차 대상 사이버보안 테스트를 수행하고, 제어기 개발사에도 신뢰할 수 있는 수준의 사이버보안을 요구합니다. 정말 궁금했지만 아무도 알려주지 않았던 VTA를 위한 사이버보안 보안테스트 노하우! 성공 사례를 보유한 페스카로 레드팀(RedTeam)이 속 시원히 답변해 드립니다. 같이 확인해 볼까요?
■ 페스카로 레드팀 소개
VTA 획득 완료 (글로벌 완성차 제작사와 협력)
제어기 150개, 실차 보안테스트 수행 (정차 및 주행 환경)
100여 개 테스트 항목, 200여 개 테스트케이스 보유 및 지속 개발 중
■ 질문 LIST
- 영상 Ver.
- 텍스트 Ver.
1. 자동차 보안테스트 종류가 궁금해요.
자동차 보안테스트 종류를 말씀드리기 전에 보안테스트 필요성에 대해 먼저 알아보겠습니다. 자동차 사이버보안 법규인 UN R155에 따라 차량제작사들은 사이버보안 관리체계(CSMS, Cyber Security Management System) 인증과 차량 형식승인(VTA, Vehicle Type Approval)을 받아야 합니다. UN R155 법규의 5절 VTA 구절을 보면, 차량에 적용되어야 하는 사이버보안 대책 요건과 이러한 대책을 어떻게 평가해야 하는지 언급되어 있습니다.
특히 5.1.2에 보면 승인기관인 Approval Authority나 승인을 대신 수행하는 Technical Service Provider는 '차량제작사가 인증을 위하여 문서를 통해 소명한 내용을 테스팅을 통해 확인해야 한다'고 나와 있습니다. 보안테스트는 AA나 TS가 직접 수행할 수도 있고 차량제작사와 협력하여 진행할 수도 있습니다. 아직은 AA나 TS가 직접 하기보다는 차량제작사가 테스팅하는 것을 보고 평가하는 것이 일반적입니다.
AA, TS, 차량제작사는 결국 보안테스팅을 수행해야 하는데, 어떤 테스트를 해야 하는지는 자동차 사이버보안 엔지니어링 표준인 ISO/SAE 21434에 언급되어 있습니다. 크게 functional testing, vulnerability scanning, fuzzing testing, penetration testing 이 있습니다.
먼저 functional testing부터 간략하게 소개하겠습니다. 기능 테스트는 이미 Tier에서 많이 알고 계실 것입니다. OEM의 보안 요구사항을 받아 분석한 후 설계에 반영하고 제어기의 SW나 HW에 그 요구사항을 반영할 텐데요. 요구사항이 제대로 반영되었는지를 확인하는 것이 functional testing입니다. 일부 차량제작사는 설계 사양서와 평가 사양서를 함께 제공하는데 평가 사양서에 따라 테스팅을 수행합니다.
다음은 vulnerability scanning입니다. 알려진 취약점이 우리 제어기의 SW나 HW에 여전히 남아있는지를 찾는 테스트입니다. 요즘 제어기 SW를 개발할 때 Open Source를 많이 사용하는데 Open Source의 취약점이 충분히 해결되었는지 확인합니다.
Fuzzing test는 주로 제어기나 차량의 외부 접점을 대상으로 정의되지 않은 데이터를 무작위로 주입합니다. 이 과정에서 SW나 HW에 존재할 수 있는 오류와 취약점을 발견하는 것이 목적입니다.
마지막으로 penetration testing은 모의 해킹입니다. 차량이나 제어기 대상으로 실제 발생할 수 있는 해킹 공격을 모사하여 현재 적용된 보안 대책이 충분한지 판단하는 방법입니다.
UN R155의 VTA를 받기 위해서는 이런 테스팅을 통해 차량에 대한 사이버보안이 충분히 검증되었음을 소명해야 합니다. 그렇다면 모든 제어기를 대상으로 4개의 테스트가 모두 수행되어야 할까요? 다행히도 그렇지는 않습니다. ISO/SAE 21434 Annex E에 보면 Cybersecurity Assurance Level(CAL)에 따른 테스팅 방법이 소개되어 있습니다.
CAL 1에 해당하는 제어기는 Functional testing과 vulnerability scanning을 수행하고, CAL 2는 Fuzzing test까지 수행하면 됩니다. CAL 3와 4에 해당하는 제어기는 모의해킹까지 수행해야 합니다. 참고로 테스팅 기법은 T2가 조금 더 높은 것을 의미하고, CAL은 제어기 단위의 TARA(Threat Analysis and Risk Assessment)를 수행하며 결정됩니다.
2. VTA를 위해 심사관이 확인하는 보안테스트가 있나요?
VTA 과정에서 심사관이 보는 중요한 사항은 무엇일까요? 바로 차량제작사가 수립한 '사이버보안 검증 프로세스에 의해 실제 차량이 제대로 테스팅되었는가'입니다. 그리고 이러한 검증 프로세스 과정에서 수행된 모든 활동에 대한 '추적성이 확보되어 있는가'입니다. 심사관들은 증적 자료를 미리 제출받아 그 유효성을 확인합니다. 그리고 현장 점검 과정에서 사전에 제출된 테스팅 결과물과 실제로 수행하는 테스팅 결과물이 동일한지 확인합니다.
UN R155에서 요구하는 VTA를 위한 테스팅 내용과 심사관들이 어떤 부분을 중점적으로 확인하는지 조금 더 구체적으로 알아보겠습니다. UN R155 법규를 보면 차량제작사는 사이버보안 대책이 효과적이라는 것을 적절하고 충분한 테스트를 통해 검증해야 한다고 명시되어 있습니다. VTA 과정에서 심사관들은 차량제작사가 이것을 제대로 수행했는지를 다음과 같은 질문을 통해 확인합니다.
보안 테스팅 추적이 가능하고 사이버보안 요구사항을 검증하는데 충분한가?
모든 테스트케이스는 리포트되었고 사전에 수행되었는가?
사용된 툴/테스트에 대상 설명/결과 등 테스팅과 관련된 모든 정보가 리포트 되었는가?
모든 테스팅은 시연 가능한가? 만일 그렇지 않을 경우 근거가 있는가?
On-site 평가 전에 입회 테스팅 항목들에 대하여 정보가 제공되었는가?
입회 테스팅 결과 자료에 대하여 제공되었는가?
CG goals와 요구사항 그리고 테스팅에 대한 mapping이 가능한가?
법규에서 가이드를 상세하게 설명하지는 않습니다. 위 질문은 페스카로가 실제로 VTA 인증을 수행하면서 들었던 사항을 토대로 만든 가이드라고 보시면 됩니다. VTA를 위해서는 위 질문들에 대비하는 것을 권유합니다.
3. TARA와 보안테스트가 dependency가 있나요?
TARA(Threat Analysis and Risk Assessment)와 보안테스트는 서로 깊은 연관이 있습니다. ISO/SAE 21434 에서의 TARA는 상기의 이미지와 같이 진행됩니다. 이 중 파란 박스에 있는 내용들은 asset을 공격하는 시나리오, 공격 경로, 공격의 가능성 등을 평가합니다. 해당 절차를 통해 대상의 위협을 Risk value Determination 하여 CAL(Cybersecurity Assurance Level) 등급이 결정됩니다.
이러한 과정을 수행하기 위해서는 사이버보안 테스트에 대한 노하우와 경험이 중요하게 반영됩니다. 위협을 식별하고 시나리오화하여 공격 경로를 만들고 이를 통해 가능성을 평가하는 과정은 추상적으로 이루어지는 것이 아닌 경험을 바탕으로 작성됩니다. 즉, 다양한 경험이 TARA에 녹아들어야만 제어기나 차량 등의 사이버보안 위협을 다각도로 검증할 수 있습니다.
뿐만 아니라 사이버보안 테스트에서도 TARA는 중요한 지표가 됩니다. TARA는 제어기 내의 다양한 자산을 정의하고, 이에 발생할 수 있는 보안 위협들을 식별해냅니다. TARA에서 식별된 다양한 위협들을 통해 Security goal이 도출되면 완화 대책을 통해 완화를 시도합니다. 이후 사이버보안 위협으로부터 안전함이 보장되는지 보안테스트를 통해 검증합니다. 레드팀의 경험을 바탕으로 제작된 다양한 테스트케이스들을 적용하여 다른 위협 혹은 취약점은 없는지 다양한 공격들을 시도해보고 사이버보안 위협으로부터 안전함을 검증합니다.
즉, TARA를 통해서 보안테스트 기준 사항들이 나오기 때문에, 같은 업체가 TARA와 보안테스트를 함께 수행했을 때 시너지가 더 좋습니다. 페스카로 같은 경우는 TARA와 보안테스트 전문팀이 별도로 구분되어 있어 객관적인 접근이 가능합니다.
4. Attack Surface 동향이 궁금해요.
최신의 차량들은 다양한 통신을 지원하고 있습니다. 다른 말로 표현하자면 다양한 Attack Surface를 가지고 있다고 볼 수 있습니다. 사례를 통해 설명하겠습니다.
먼저 차량의 스마트키에서 사용하는 RF/LF 통신은 재전송 공격을 막기 위한 보안 대책으로 롤링 코드 방식이 적용되어 있습니다. 취약하게 설계/개발된 롤링 코드의 취약점을 통해 공격자는 피해자의 정상적인 문 잠금/해제 신호를 스니핑하여 복제하고 롤링 코드 보안 기능을 우회하여 차량의 잠금을 해제할 수 있습니다.
게다가 공격자가 차량 내 접근에 성공했다면 USB 포트를 통해 내비게이션에 접근할 수 있습니다. 공격자가 의도한 악의적인 행동을 수행하는 악성코드를 심어 차량에 저장된 연락처/통화목록/최근 행선지 등의 민감한 개인정보 데이터를 탈취할 수도 있습니다.
이러한 공격들은 외부 접점을 통해 진입한 것입니다. 그러나 저희 연구 사례에 의하면 내부 네트워크 침투를 위해 차량의 범퍼를 탈거하고 헤드램프 제어기에 접근하여 내부 네트워크에 침투했던 사례도 있습니다. 헤드램프 제어기에 연결하여 악의적인 메시지를 삽입하였고, 바디 컨트롤 제어기에 스마트키가 차량 내 존재하는 것으로 인식하게 했습니다. 그 결과 스마트키 없이 문을 열고 시동을 걸고 주행까지 가능했습니다. 이러한 공격이 가능한 이유는 헤드램프 제어기와 바디 컨트롤 제어기가 같은 CAN 버스를 사용했기 때문입니다.
마지막으로 자율주행 초기 단계로 볼 수 있는 ADAS에서 LIDAR/RADAR/CAMERA와 같은 제어기들도 위협 발생 시 주행 중 비정상 행동을 통해 탑승자에게 피해를 줄 수 있는 중요한 Attack surface입니다. 페스카로는 이에 대해 관심을 갖고 연구하고 있습니다.
5. 자동차 암호 해킹 시나리오나 기법 사례가 궁금해요.
실제 페스카로 레드팀에서 수행한 내용을 바탕으로 설명하겠습니다. 우선 실차에서 CAN 네트워크에 침투하여 리모트키 제어기에 자체 개발한 CAN 도구를 통해 임의의 메시지를 주입하였습니다. 주입 중 특정 메시지에 의해 에어백 컨트롤 제어기에서 Crash out이 발생하는 현상을 확인하였고, 콕핏이 사고 발생으로 인지함과 동시에 비상등이 무한 점멸되는 증상의 취약점을 확인했습니다.
다음으로 외부 접점인 WiFi를 통해 침투에 성공하였고, 내비게이션 내에 백도어를 통해 내비게이션 재부팅/영상/소리 변조가 가능했습니다. 이 공격을 통해 Drive mode, 공조 등 내비게이션에서 수행할 수 있는 모든 기능을 임의 변경 가능한 취약점을 발견했습니다.
일반적인 제어기의 경우 디버그 포트 보안이 없다면 디버그 포트를 통해 내부의 펌웨어 추출이 가능합니다. 추출한 펌웨어를 분석하면서 동작 로직을 파악하고, 변조하여 업데이트한다면 비정상 동작을 유발하거나 정상 동작을 하지 않도록 할 수도 있습니다.
마지막으로 주행 중인 차량의 GPS 위치 데이터 변조를 통해 임의의 장소를 주행 중인 것으로 변조할 수 있습니다. 이는 규정 속도에 맞춰 자율주행 중인 자동차에 GPS 위치 데이터를 어린이 보호구역으로 변조한다면, 주행 중인 자동차는 규정 속도인 30km로 급 감속하게 되고 이는 사고로 유발될 수 있는 심각한 취약점입니다.
이렇듯 차량의 모든 Attack Surface 들을 고려하여 공격 시나리오가 만들어지고, 이를 수행하면서 테스트 항목과 테스트 케이스를 개발하고 있습니다.
6. 보안테스트는 어떤 절차로 진행되나요?
보안테스트 절차는 크게 5단계로 나누어 볼 수 있습니다. 먼저 정보를 수집하는 단계입니다. 수집 정보로는 MCU와 AP의 칩셋 정보, 핀아웃 정보, 제어기 입출력 관련 기능, CAN 메시지 정보 등이 있습니다. 이러한 정보는 기능 설명서, 설계 사양서를 확인하고 칩셋의 data sheet, 담당자 인터뷰 등을 활용하여 수집할 수 있습니다.
다음은 공격 표면과 공격 벡터를 식별하는 단계입니다. 공격 표면은 타깃 제어기의 공격 접점 또는 공격 포인트를 뜻하고, 공격 벡터는 공격 방법이나 수단을 의미합니다. 공격 표면의 예로는 MCU를 사용하는 제어기의 경우 JTAG, UART, USB와 같은 디버그 인터페이스가 있고 통신과 관련된 공격 표면에는 CAN, 이더넷, 와이파이, NFC, 블루투스, RF 등이 있습니다. 그 밖에 스토리지나 flash 메모리와 같은 저장 매체도 공격 표면에 해당합니다. 공격 방법에는 통신데이터를 분석하기 위한 스니핑이나 스니핑 후 메시지나 신호를 가로채기하는 MITM, 가로챈 정보를 위조하는 스푸핑, 펌웨어 추출을 목적으로 하는 디솔더링이 있습니다. 펌웨어가 확보된 후에는 바이너리를 역공학하여 결함을 찾는 공격 방법이 있습니다.
세 번째 단계에서는 테스트케이스를 작성하게 됩니다. 작성해야 하는 주요 내용으로 제어기 정보와 Test의 목적, 공격 방법과 절차, 취약점 정보 등이 있습니다. 여기에 TARA(Threat Analysis and Risk Assessment)를 통한 사이버보안 목표까지 확인하여 테스트케이스와 맵핑해 줌으로써 사이버보안 목표가 제대로 달성되었는지 확인합니다.
네 번째와 다섯 번째 단계는 실제 공격을 수행하는 단계입니다. 제어기 장악을 위한 권한 획득을 시도합니다. 권한을 확보하게 되면 공격 확산을 위해 펌웨어 변조, 악성 스크립트와 백도어 설치, 서비스 거부 등을 통해 최종적으로 차량 내부 네트워크로 침투하는 것을 목표로 합니다.
7. 보안테스트 진행 시 우리는 어떤 것을 해야하나요?
크게 두 가지가 있습니다. 먼저 원활한 테스트가 진행될 수 있도록 테스트 환경을 제공해야 합니다. 테스트 대상 제어기를 여벌 포함 2~3대가 필요한데, 이때 가급적 사이버보안 솔루션이 적용된 제어기이면 verification 활동에 도움이 됩니다. 그 밖에 제어기 하네스 커넥터와 제어기와 관련된 HW 정보를 식별할 수 있는 사양서, 제어기 기능 설명서를 제공해 주시면 좋습니다. 추가로 제어기 Firmware 바이너리와 CAN DB 정보 등을 공유해주시면 빠르고 원활한 테스트에 도움이 됩니다.
다음은 테스트 결과 발견된 취약점에 대한 이벤트 대응 및 기록에 대한 부분입니다. 이 부분은 ISO/SAE 21434 8절(Continual cybersecurity activities)에 근거한 것입니다. 발견된 취약점 내역과 이력 관리, 취약점 분석, 대응 방안 수립/배포, 버전관리를 해주시면 좋습니다.
8. 단품 제어기와 실차 테스트 수행에 차이가 있나요?
동일한 테스트케이스를 활용하더라도 개별 제어기를 단독으로 테스트하는 것과 실차에서 테스트하는 것은 서로 다른 결과가 나올 수 있습니다. 제어기가 CAN 네트워크에 연결되어 연관된 다른 제어기로부터 주기 신호와 같은 프로파일 정보를 받을 때만 기능이 활성화되거나 정상 동작하도록 개발된 경우가 많습니다. 이런 경우 단품으로만 테스트할 때는 입출력 신호, 메시지 등을 확인할 수 없어 정상적인 테스트가 이루어지지 않기 때문에 실차환경에서 테스트하는 것이 효과적입니다.
특히 실차기반 주행테스트도 중요하다는 점을 강조하고 싶습니다. 상기의 그래프에서 녹색 실선은 공격이 없는 상태에서 측정된 엔진 속도(RPM)이며, 주황색 점선은 공격 상태에서 측정된 것입니다. 테스트를 위해 주행 환경에서 PCAN을 대상으로 비정상 메시지를 주입하면, 비정상적인 변속 타이밍으로 인해 기준 엔진 속도와 차이가 발생하여 실제 사용자 안전에 영향을 줄 수 있습니다. 반면 단순히 IGN ‘ON’ 상태에서 비정상 메시지를 주입하면 공격의 영향으로 CAN 통신의 지연은 확인되지만 주행테스트처럼 실제 영향도를 확인할 수 없습니다.
실제로 페스카로는 최근 글로벌 자동차 제작사에서 양산 준비 중인 전기차를 대상으로 VTA 평가 시연을 앞두고, 다양한 조건에서 모의 평가를 수행했습니다. 주행테스트에서 E-PT(전기차 파워트레인 구동계)를 대상으로 비정상 메시지 주입 시 구동이 멈추고 가속 페달이 동작하지 않는 문제가 발생했습니다. 동일한 공격을 정차 테스트에서 진행했을 때는 미세한 통신 지연 외에는 영향도를 확인할 수 없었던 부분입니다. 저희는 즉시 OEM과 제어기 개발사에 관련 내용을 공유하였고 기술 논의를 거쳐 소프트웨어 패치를 적용한 이후에 문제가 해결된 것을 확인할 수 있었습니다. 이 과정을 통해 VTA 인증 시연도 무사히 마무리할 수 있었습니다.
제어기나 실차의 테스트 환경은 그 자체로도 충분히 유의미하지만 통합 환경에서 테스트를 수행했을 때 시너지가 발생합니다. 테스트 환경에 따라 다양한 결과가 도출되므로 다방면으로 검토해 보시면 좋을 것 같습니다.
페스카로는 화이트해커 그룹의 전문 레드팀이 국제 법규와 표준을 준수하는 사이버보안 테스트를 수행합니다. 최근 글로벌 차량제작사와 협력하여 VTA 획득을 완료했고, 총 150개의 제어기와 정차 환경/주행 환경의 실차를 대상으로 보안테스트도 수행했습니다. 또한 100여 개의 테스트 항목과 200여 개의 테스트 케이스를 보유했으며 자동차 제어기, 전기차 충전기 등 보안테스트 영역을 확장하고 있습니다.
혹시 OEM 보안 요구사항에 직접 대응하기 어렵거나, 자동차 사이버보안 테스트 관련 전문 인력과 조직 운영에 대한 어려움이 있으시다면, 페스카로와의 협업을 통해 해결할 수 있을 것 같습니다.
<웨비나 소감 이벤트 당첨자>
웨비나 소감 이벤트를 통해 총 8명에게 <신세계 상품권>을 드립니다. 귀한 의견들을 참고하여 더 발전하여 찾아오겠습니다. 아래에 이벤트 당첨자의 소감을 일부 공유합니다. ■ 10만원권 (1명)
• 노*훈 "그동안 VTA 사례를 다룬 웨비나는 없었기에 귀중한 시간이었습니다. OEM이 아니고서는 경험하기 어려운 내용이라 흥미로웠습니다."
■ 5만원권 (2명)
• 전*택 "실무자 특히 모의해커분이 사례를 자세히 설명하여 도움이 되었고, TARA와 모의 해킹이 어떻게 접목되는지 배울 수 있어 유익했습니다."
• 김*규 "이번 웨비나를 마중물 삼아서 심도있게 사이버보안을 이해하고 학습해야겠다는 의욕이 생겼습니다."
■ 3만원권 (5명)
• 송*기 "다양한 산업체에서 어디에서도 쉽게 물어보지 못한 실무 관련 질문을 하고, 전문가의 답변을 받을 수 있는 기회의 장이 되어서 좋았습니다."
• 정*국 "사전 질문을 풍부하게 다루면 좋을것 같습니다. 기술적인 부분과 모의 해킹 과정에 대한 설명도 더 상세하면 더 좋을것 같습니다."
• 정*교 "진행하고 있는 업무(CSMS)와 연관성이 높은 주제라 관심이 많았고 도움이 되는 웨비나였으며, 향후 웨비나에도 참여하고 싶습니다."
• 이*준 "사전질문에 대한 전문가들의 답변 형식이 효율적이었고, 이런 형태가 페스카로만의 문화가 될 수 있을 것 같습니다."
• 이*수 "앞으로는 웨비나로 다루기 어려운 좀 더 심도있는 주제로 유료세미나나 교육을 진행해도 좋을 것 같습니다."