fbpx

소프트웨어의 취약성은 컴퓨터 코드에 있어 공격자들이 시스템을 장악할 수 있는 약점 혹은 문제가 될 수 있습니다. 인간이 코드를 작성하는 이상 취약성은 존재합니다. 따라서 제조사들은 위협이 되기 전에 취약성을 효과적으로 감지하고 최소화하는 일이 매우 중요합니다.

차량들이 보다 더 깊이 네트워크로 서로 연결되고 소프트웨어에 의존하게 되면서 차량 관련 소프트웨어 취약성은 매우 빠르게 증가하고 있습니다. 하지만 이미 알려진 취약성은 빙산의 일각에 불과합니다. 우리가 마주할 불편한 진실은 공격을 받기 전까지는 차량에 취약성이 있다는 사실을 아무도 모른 채 몇 년 간 도로를 달리게 될 수도 있다는 것입니다! 

새로운 취약성 관리 요구사항을 만나보세요

차량이나      차량군에 대한 사이버 공격은 운전자는 물론 공공의 안전을 위협하고 대규모 리콜이나 브랜드 가치 절하로 이어질 수 있어 잠재적으로 엄청난 위협이 됩니다. 이에 따라 차량에 관련된 취약성은 무시할 수 없습니다.  

차량 제조 분야에 있어 사이버 공격의 중요성을 인식함에 따라 OEM사들이 제조하는 차량군의 생애주기에 따른 사건사고와 위협을 감시하도록 하는 새로운 규제와 기준이 마련되고 있습니다. 2020년 6월, UN은 UNR155 규제 법안을 도입해 차량 제조사(OEM사)들에 대한 새로운 사이버 보안 지침을 마련했습니다. 여기에는 취약성에 대한 감시, 보호, 대응 뿐만 아니라 “타당한 기간 내에” 취약점을 최소화하는 내용이 포함되어 있습니다. 

오늘날 OEM사들과 1차      제조사들은 UNR155와 ISO/SAE 21434에 명기된 바와 같이 빠르고 효과적인 방법으로 취약성을 관리하는 방법을 연구 중에 있습니다. 차량 공급 체인에서 해당 요구사항을 충족하기 위해 필요한 주요 쟁점 몇 가지를 알아보도록 하겠습니다.

쟁점 #1 – 코드의 규모와 복잡성

특정 차량에 사용되는 코드의 규모와 복잡성은 취약성 관리를 악몽으로 만듭니다. 차량 별로 1억개 라인의 코드가 존재하며 코드는 계속 늘어납니다(Windows 10의 두 배이며 최초의 우주왕복선에 사용된 코드의 250배), 이 코드들은 다양한 시스템에 걸쳐 작동하며 여기서 보안 취약점을 찾아내는 건 모래사장에서 바늘 찾기입니다. 

게다가 소프트웨어에는 낮은 티어 공급업체에서 오는 오픈 소스나 서드파티 및 특허 코드도 들어있습니다. 

쟁점 #2 – 분산된 공급 체인

차량 한 대에는 서로 다른 1차      공급업체에서 공급하는 최대 100개의ECU가 탑재되어 있습니다. 게다가 일부 공급업체는 특정 ECU에 대해 복수의 납품 업체와 함께 일하기도 합니다. 심지어 1차      공급업체     들이 2차, 혹은      3차      공급 업체와 일한다는 사실에 더해 여러 개의 ECU가 차량에 탑재되어 있고 서로 다른 하위 공급업체들이 개발한 서로 다른 OS가 사용되고 있습니다.(OEM사에서 모르는 경우도 있습니다)

복수의 OS를 사용하는 경우도 흔하며(AUTOSAR, 리눅스, 안드로이드) 서로 다른 공급자가 공급한 같은 ECU의 소프트웨어는 취약성 관리를 보다 어렵고 복잡하게 만듭니다.

비교 대상을 찾아보려 해도 IT업계에서 이정도로 파편화가 심한 경우는 극히 드뭅니다. 

쟁점 #3 – 제한된 가시성

티어 수가 많고 파편화가 심한 탓에 OEM사들은 ECU의 소스코드 열람에 제한이 생깁니다. 게다가 OEM사들과 1차       업체들은 공급자로부터      항상 소스코드를 구매하지 않고 차량에 해당하는 이미지를 구매할 뿐입니다. 이로 인해 취약점 감지가 더 힘들어지며 감지한 취약점을 수정하기도 힘들어집니다.

다중 티어의 공급망으로 인해 최종적으로 도로      위의 차량에 책임을 져야 하는 OEM사들이 해당 코드의 취약점에 대해 항상 알고 있지 못하는 것입니다. 소프트웨어적인 관점에서 1차사      미만     의 모든 것들을 OEM사에서 열람할 수는 없으며 공급망이 더 복잡할 수록 발견된 취약점이 차량과 관련이 있는지 확인하기가 힘듭니다.

가시성이 제한된다는 것은 OEM사에서 효율적으로 취약성을 발견, 수정, 관리하기 힘들다는 의미입니다.

쟁점 #4 – 차량 생애주기

차량은 보통 디자인에서 생산까지 5년이 걸리고 도로 위에서 10-15년을 달립니다. 이는 내 차량이 보안적인 측면에서 안전하게 디자인되고 테스트를 받았다고 하더라도 향후 발생할 수 있는 취약성에 대한 감지와 최소화가 필요하다는 것입니다.

차량 업계에서 “수명 종료” 선언은 존재하지 않으므로 OEM사는 아직 달리고 있는 차량들에 대한 지원을 중단할 수는 없으며 10에서 15년간은 차량의 안전을 보장해야 합니다. 이는 굉장히 힘든 일이며 차량의      생애주기 전반에 걸친 레거시 소프트웨어 지원 및 패치가 필요합니다.

오늘날엔 OTA      (Over-the-air     ) 업데이트가 차량의 엔터테인먼트 시스템과 텔레매틱 ECU에 흔하게 사용되고 있습니다. 그러나 OTA 사용만으로는 안전에 치명적인 ECU, 예를 들어 스티어링, 가속 등과 같이 긴급한 수정이 요구되는 경우에는 대응할 수 없습니다.

쟁점 #5 – 영향 평가의 어려움

차량에 대한 취약성이 공개되면 OEM사의 보안 전문가가 해당 취약성이 미칠 영향과 차량이 노출된 위험을 파악해야 합니다. 그러나 코드의 복잡성과 앞서 언급한 가시성의 부재로 인해 전문가가 영향 평가에 있어 가장 중요한 해답을 찾기가 매우 어려워집니다.

여기에는 다음과 같은 항목이 포함됩니다. 내 차량의 코드에 취약성이 존재하는가? 어느 ECU인가? 얼마나 많은 차량이 영향을 받는가? 어떤 시스템에 영향을 주는가? 이 취약성을 남용할 수 있는가? 아니면 다른 수단을 통해 ECU를 확보할 수 있는가? 잠재적 영향력이 추가적인 투자를 필요로할 정도로 심각한가? 위와 같은 질문에 대답할 수 있을만큼의 정보에 접근하는 것은 위험성 노출을 줄이고 대응 속도를 빠르게 하는 데에 매우 중요합니다.

쟁점 #6 – 취약성 완화의 복잡성

취약성을 최소화하려는 결정이 내려지게 되면 차량의 소프트웨어 환경에 대한 패치를 적용하는 것 역시 매우 복잡한 일이 됩니다. 단순한 설정 변경이든 전체 소프트웨어 업그레이드건 간에 말이지요. 아키텍처의 관점에서 보면 차량은 “시스템으로 이루어진 시스템”으로 수 많은 ECU가 탑재되어 이들이 전부 네트워크로 연결되어 있는 상황입니다.  따라서 한 ECU에 대한 코드 업데이트나 취약성 패치는 다른 시스템에 영향을 줄 수 있습니다. 그러므로 취약성을 수정하고 나면 해당 ECU의 기능이 유지되면서 이 업그레이드가 다른 시스템에 악영향을 주지는 않았는 지 확인하는 과정이 필요합니다. 

게다가 파편화된 공급망 탓에 OEM사는 스스로 대부분의 취약성을 수정할 수는 없으며 하나 이상의 공급자와 협력해야 합니다. 또한 서로 다른 개발팀이 관여되어 있으므로 어느 팀이 패치를 책임져야 하는지(OEM, 1차사     , 2차사     )도 문제가 됩니다.

이 단계에서 아직 해답이 나오지 않은 과제는 다음과 같습니다. 어떻게 패치하는 것이 최선인가? 언제 패치를 할 것인가? OTA업데이트로 가능한가? 생산 후에 보안 테스트는 어떻게 할 것인가? 등입니다. 

위와 같은 문제를 해결할 솔루션은 아마 향후 2년 안에 나올 것입니다.

어디서부터 시작할까. 협력과 에코시스템 전반에 걸친 투명성

취약성 관리에서 발생하는 쟁점들에 대해 이야기하기 위해서는 전반적인 차량 생산 에코시스템에 해당하는 OEM사와 공급망 전반의 ECU 공급 업체, 커뮤니케이션 공급자와 상위 납품 업체 전반이 협력을 통해 에코시스템 전체에 투명성을 보장     해야 합니다. 

향상된 가시성과 투명성이 올바른 취약성 관리 툴에 더해지면 OEM사들이 사이버 위협 노출을 보다 잘 이해할 수 있으며 감지부터 최소화까지 걸리는 시간을 줄일 수 있습니다. OEM사들이 차량을 더 안전하게 지켜 사람들을 공격으로부터 보호하도록 돕는 것입니다. 

저희의 Argus 보안 라이프사이클 관리 페이지에서 Argus가 어떻게 여러분이 마주한 취약성 관리 문제를 도와드릴 수 있을 지 확인해 보시기 바랍니다.

Subscribe to our blog

Recent Posts
Automotive Ethernet IDS