
1. Overview
TARA 는 Threat Analysis and Risk Assessment 의 약자로 차량 사이버보안 관리 시스템 (CSMS) 에서 사용하는 위험 평가 방법론이다. TARA 활동을 통해 시스템, 제품, 또는 서비스와 관련된 위협과 취약점을 체계적으로 식별하고, 그로 인한 위험을 정량화 하여 보안 요구사항을 도출하는 것에 목적을 둔다.
TARA 활동은 CSMS Section 15에 정의되어 있다. 물론 아는 사람은 알겠지만 Section 15에 정의되어 있다고 해서 V 사이클의 가장 마지막에 수행되는 활동은 아니다. 앞서 언급한바와 같이 TARA는 보안 요구사항 도출을 위한 '방법론' 으로서 CSMS 활동 중 보안 요구사항 도출, 취약점 분석 과정에서 대표적으로 사용되는 방식이다.
자동차 업계에서 근무하면, 많은 CSMS 담당자 또는 사이버보안 엔지니어, 사이버보안 매니저 역할을 담당하는 사람들이 TARA 활동 때문에 힘들어 하는 것을 볼 수 있다. 그 이유가 무엇인지는... 직접 아이템을 정해서 TARA를 수행해보면 알게 될 것이다...
이번 포스팅에서 TARA 방법론에 대해 설펴보고 수행 방법을 함께 살펴보는 시간을 가져보자.
2. TARA Structure
Overview에서 언급한 바와 같이, TARA 활동은 ISO / SAE 21434 Section 15에 별도로 정의되어 있으며, 이는 수행 순서가 아닌 하나의 방법론이다. (왜 한글자료를 안썻나면... 일부 잘못 표시된 박스가 있어서 그대로 쓸 수 없었다.)
각 세션에서 TARA 모듈이 어떻게 활용되는지는 추후에 설명하기로 하고, 먼저 Section 15에 표시된 TARA의 methods를 먼저 살펴보자. 단 하기의 내용은 실제 TARA 진행 순서를
2.1 Asset Identification (15.3)
Concept phase에서 Item definition 과정을 통해 식별된 아이템에 대한 Asset(자산)을 식별하는 것이다. 여기서 자산이란 보호해야 할 중요한 요소를 의미하며, 시스템, 제품, 또는 서비스와 관련된 모든 요소 중 공격자가 표적으로 삼을 가능성이 있는 부분으로, 이를 통해 공격자가 이익을 얻거나, 시스템에 피해를 줄 수 있는 모든 요소를 자산으로 분류한다. Asset의 예시는 하기와 같이 정의할 수 있다.
- 아이템에서 사용하는 데이터 (Data) : 차량 내부 및 외부의 중요한 정보.
- 하드웨어 (H/W) : 차량의 물리적 장치나 전자 제어 장치
- 소프트웨어 (S/W) : 차량 시스템의 동작을 제어하는 코드
- 기능 (Function) : 차량이 제공하는 기능
이렇게 설명하면... 솔직하게 처음 하는 입장에서 이해가 불가능하다. 추 후 TARA Example 을 통해 Asset Identification에 대해서 자세하게 설명하도록 하겠다.
2.2 Damange Scenario & Impact Rating (15.5)
Asset Identification 을 통해서 식별된 자산은 각각 사이버보안 속성이 설정된다.
- 기밀성 (Confidentiality) : 정보가 인가되지 않은 사람이나 시스템에 접근되지 않도록 보호하는 것
- 가용성 (Availability) : 시스템, 서비스, 또는 데이터가 정당한 사용자가 필요로 할 때 사용할 수 있도록 보장하는 것
- 무결성 (Integrity) : 데이터나 시스템이 인가되지 않은 방식으로 변경되지 않도록 보장하는 것
- 부인 방지 (Non-repudation) : 특정 행위나 데이터 교환이 발생했다는 사실을 추후에 부인하지 못하도록 보장하는 것
- 인증 (Authentication) : 사용자의 신원 또는 시스템의 정당성을 확인하여 접근 권한을 부여하는 것
그리고 이 사이버보안 속성이 침해되었을 때 발생할 수 있는 실제적인 영향을 Damange Scenario로 작성하게 된다. Damage Scenario 작성 시 가장 좋은 방법은 < Asset > 의 < Property > 위반으로 인한 < Function > 의 오동작은 < adverse consequences > 를 유발함으로 작성하면 좋다.
예를 들어 ADAS ECU 중 스마트크루즈 컨트롤(SCC) 기능과 관련된 데이터의 Asset을 'A'라고 가정한다면 데미지 시나리오는 하기와 같이 작성될 수 있다. 하기는 어디까지나 예시이며 실제 데미지 시나리오는 각 Property 마다 도출된다.
Asset | Cybersecurity Property | Damage Scenario | |||||
C | I | A | NR | Auth | ID | Scenario | |
A | ● | DS001 | 'A'의 가용성 위반으로 인한 SCC의 오동작은 운전 중 자동 변속 불가를 유발함. |
Damage Scenario 가 작성되면 작성된 시나리오에 대한 영향 평가(Impact Rating)를 수행한다. 영향평가는 정의된 Damage Scenario에 대한 영향을 F, S, O, P 측면에서 평가한다.
- F : 재정(Financial) 을 의미하며 경제적 피해나 금전적 손실로 이어지는 정도
- S : 안전(Safety)을 의미하며 사람의 생명과 신체에 미칠 수 있는 영향
- O : 운영(Operational)을 의미하며 시스템이 정상적으로 작동하지 못하거나 서비스가 중단될 때 운영에 미치는 영향
- P : 프라이버시(Privacy)을 의미하며 개인정보나 민감 정보의 유출 가능성
Security Threat Severity Class |
Aspects of security threats | |||
Safety (S) | Financial (F) | Operational (O) | Privacy (P) | |
Severe | S3 : 생명을 위협하는 부상 (생존 불확실), 치명적인 상해 | 이해 관계자가 극복할 수 없는 치명적인 재정적 손실 | 차량 핵심 기능의 손실 또는 손상 | 사용자에게 중대하거나 돌이킬 수 없는 피해를 끼치는 정보 노출 |
Major | S2 : 중상 및 생명을 위협하는 부상 (생존 가능성 높음) | 이해 관계자에게 상당한 영향을 끼치지만 극복 가능한 재정적 손실 | 차량 주요 기능 상실 | 사용자에게 심각한 피해를 끼치는 정보 노출 |
Moderate | S1 : 가볍고 경미한 부상 | 이해 관계자가 제한된 자원으로 극복 가능한 재정적 손실 | 차량 성능의 부분적 저하 | 사용자에게 불편을 끼치는 개인 정보 노출 |
Nigligible | S0 : 부상 당하지 않음 | 이해 관계자에게 영향이 없거나 인식할 수 없음 | 손상이 없거나 인식 불가능한 수준 | 사용자에게 영향이 없거나 불편을 거의 주지 않음. |
그렇다면 상기 예시로 든 Damage Scenario에 대한 Impact Rating 예시는 하기와 같이 작성할 수 있다.
Damage Scenario | Impact Rating | ||||
ID | Scenario | S | F | O | P |
DS001 | 'A'의 가용성 위반으로 인한 SCC의 오동작은 운전 중 자동 변속 불가를 유발함. | Severe | Nigligible | Major | Nigligible |
2.3 Threat Scenario Identification (15.2) with Attack Path (15.6)
Damage Scenario 에 대한 Impact Rating이 완료 되면 식별된 자산에 대한 Threat Scenario를 정의한다. Threat Scenario 와 Damage Scenario의 차이점을 간단하게 설명하자면 Damage Scenario 는 사이버보안 속성이 침해될 경우 발생할 수 있는 부정적인 결과를 시나리오로 작성하는 반면, Threat Scenario는 공격자가 특정 목표를 달성하기 위해 수행할 수 있는 공격 방법을 의미한다. 따라서 위협 시나리오는 Attack Path (15.6) 와 함께 작성되는 것이 일반적이다.
상기 ISO / SAE 21434에서 Threat Scenario Identification 이후 Attack Path Analysis를 수행하도록 기술되어 있으나, Attack Path가 명확하다면 굳이 해당 영역을 따로 떼어내어 수행할 필요는 없다. 그래서 보통 Concept Phase에서 Item Definition 수행 시 Attack Path를 정의하며, 해당 Item에서 공격 경로로 사용될 수 있는 Communication Channel(e.g, CAN, Ethernet, Bluetooth, WI-FI etc...) 을 명시하면 된다.
Threat Scenario 정의는 식별된 자산에 STRIDE 기법을 사용하여 Damage Scenario 를 달성하기 위한 위협 시나리오를 작성하는 것이다. STRIDE 기법에 대한 설명은 하기와 같다.
STRIDE | Threat | Property Violated | Threat Definition |
S | Spoofing | Authentication, Freshness | 공격자가 시스템이나 사용자로 가장하여 무단으로 접근하는 행위 |
T | Tampering | Integrity | 데이터가 전송되거나 저장되는 동안 무단으로 수정되는 행위 |
R | Repudation | Non-repudation | 사용자나 시스템이 특정 행동이나 메시지 전송 사실을 부인할 수 있는 상태 |
I | Information Disclosure | Confidentiality | 인가되지 않은 사용자에게 민감한 정보가 노출되는 행위. |
D | Denial of Service | Availability | 시스템 자원이나 서비스를 사용 불가능하게 만들어 정당한 사용자의 접근을 차단하는 행위. (DoS) |
E | Elevation of privilege | Authorization | 공격자가 자신의 권한을 상승시켜 더 높은 수준의 액세스 권한을 획득하는 행위. |
위헙 시나리오 작성 패턴은 < Asset >의 < Property >을 침해하는 <Attack Path>를 통한 < STRIDE > 는 "Damage Result" 를 초래한다. 형태로 작성된다. 예를 들어 CAN Communication Channel을 Attack Path로 가지는 상기 Damage Scenario 에 대한 Threat Scenario에대한 예시는 하기와 같다.
Threat Scenario |
|||
ID | Attack Path | Scenario | Damage Scenario |
TS001 | OBD | 'A'의 가용성을 침해하는 OBD 를 통한 DoS 공격은 운전 중 자동 변속 불가를 초래할 수 있다. | DS001 |
Threat Scenario 작성 시 Attack Path가 표시 된 Attack Tree 등 시나리오에 대한 단계 별 설명이 작성된 순서도 등이 포함되어야 한다. Attack Tree 작성은 추후 별도 포스팅을 통해 설명하도록 하겠다.
2.4 Attack Feasibility Rating (15.7)
Threat Scenario 작성 후
'Automotive Security > CSMS' 카테고리의 다른 글
CSMS Overview (2) | 2024.11.27 |
---|