TARA는 실제로 어떻게 수행할까?

자동차 사이버보안 규제 이야기 05

이전 편 | ISO/SAE 21434는 왜 자동차 개발 프로세스를 바꿨을까?

자동차 사이버보안에서 가장 먼저 해야 할 질문은 이것입니다.

"무엇이 가장 위험한가?"

현대 차량에는 수십~수백 개의 ECU가 있습니다.
모든 시스템에 동일한 수준의 보안을 적용하는 건
비용과 성능 측면에서 현실적으로 불가능합니다.

그래서 자동차 업계는 먼저 어떤 공격이 가능한지 분석하고,
어떤 위험이 실제로 치명적인지 평가하기 시작했습니다.

이 과정을 TARA(Threat Analysis and Risk Assessment)라고 부릅니다.

TARA — 보안 결정의 근거를 만드는 프로세스

TARA(Threat Analysis and Risk Assessment)는 말 그대로 위협을 분석하고 위험을 평가하는 프로세스입니다. 하지만 단순한 체크리스트가 아닙니다.

TARA의 진짜 목적은 "무엇을 왜 보호해야 하는가"에 대한 근거를 만드는 것입니다.
Secure Boot를 적용하는 이유, 게이트웨이 필터링이 필요한 이유,
SecOC를 선택한 이유 — 모두 TARA에서 나와야 합니다.

TARA 없이 보안 기능을 구현하면 "다들 하니까 넣었다"가 됩니다. TARA가 있으면 "이 위협의 위험도가 높기 때문에 이 대책을 선택했다"가 됩니다. OEM과의 협의에서도, 인증 심사에서도, 이 차이는 엄청납니다.

그리고 단순히 공격이 가능하다는 이유만으로 모든 위험이 높은 것은 아닙니다. 실제 공격 난이도와 공격 성공 시 영향도를 함께 고려해야 합니다. 공격은 가능하지만 극도로 어렵거나, 성공해도 피해가 미미하다면 우선순위는 내려갑니다. TARA는 이 판단을 구조적으로 하는 방법입니다.

TARA는 일회성 작업이 아닙니다. 시스템이 변경되거나, 새로운 공격 기법이 등장하거나, 운영 중 취약점이 발견되면 재검토해야 합니다. 살아있는 문서입니다.

TARA 전체 흐름 — 6단계로 이해하기

ISO/SAE 21434 기반의 TARA는 크게 6단계로 진행됩니다. 예시는 차량 OTA 업데이트를 담당하는 텔레매틱스 ECU를 대상으로 합니다.

1

아이템 정의 (Item Definition)

분석 대상 시스템의 경계와 기능을 정의합니다. 무엇을 분석할 것인지, 어디서 끝나는지를 먼저 합의해야 이후 단계가 일관성 있게 진행됩니다. 범위가 너무 넓으면 TARA가 끝나지 않고, 너무 좁으면 중요한 위협을 놓칩니다.

예시

분석 대상: 텔레매틱스 ECU (TCU)
주요 기능: OTA 패키지 수신·검증·전달, 원격 진단, 위치 정보 전송
연결 인터페이스: 셀룰러(LTE), CAN 버스, 내부 이더넷
분석 범위: TCU 자체 + TCU가 통신하는 게이트웨이 ECU까지

2

자산 식별 (Asset Identification)

시스템 안에서 보호해야 할 가치 있는 것들을 식별합니다. 자산은 데이터, 기능, 하드웨어 자원으로 나눌 수 있습니다. 여기서 빠진 자산은 이후 단계에서 위협 분석도 되지 않습니다. 충분히 넓게 생각해야 합니다.

예시 — TCU 주요 자산

· OTA 펌웨어 패키지 (무결성, 진본성)
· 서명 검증용 공개키 (기밀성, 무결성)
· 차량 위치 데이터 (기밀성)
· 셀룰러 통신 채널 (가용성)
· CAN 버스 메시지 전달 기능 (무결성, 가용성)

3

위협 시나리오 도출 (Threat Scenario)

각 자산에 대해 어떤 공격이 가능한지 시나리오를 작성합니다. 공격자의 목표(기밀성 침해, 무결성 침해, 가용성 침해)와 공격 경로를 조합해서 구체적인 시나리오를 만듭니다. 이 단계에서 STRIDE 같은 위협 모델링 기법을 활용하기도 합니다.

예시 — 위협 시나리오

TS-01: 공격자가 MITM으로 OTA 패키지를 악성 펌웨어로 교체한다
TS-02: 공격자가 셀룰러망을 통해 TCU에 원격 코드를 실행한다
TS-03: 공격자가 TCU를 통해 CAN 버스에 악성 메시지를 주입한다
TS-04: 공격자가 대량 요청으로 셀룰러 통신을 마비시킨다 (DoS)
TS-05: 공격자가 위치 데이터를 탈취해 차량을 추적한다

4

영향 평가 (Impact Rating)

각 위협 시나리오가 실제로 발생했을 때 얼마나 심각한지를 평가합니다. ISO/SAE 21434는 네 가지 영향 범주를 씁니다. 각 범주별로 심각도를 S1(경미)~S4(심각) 4단계로 평가하고, 가장 높은 값이 해당 시나리오의 영향도가 됩니다.

영향 범주

· Safety(안전): 인명 피해 가능성
· Financial(재정): 경제적 손실 규모
· Operational(운영): 차량·서비스 기능 장애
· Privacy(개인정보): 개인정보 유출 범위

시나리오	Safety	Financial	Operational	Privacy	최종 영향도
TS-01 (OTA 변조)	S4	S4	S4	S1	S4 — 심각
TS-03 (CAN 주입)	S4	S3	S4	S1	S4 — 심각
TS-05 (위치 탈취)	S1	S1	S1	S3	S3 — 높음

5

공격 가능성 평가 (Attack Feasibility)

공격자가 이 위협을 실제로 실행하기 얼마나 어려운지를 평가합니다. 영향이 아무리 심각해도 공격이 현실적으로 불가능하다면 위험 우선순위가 내려갑니다. ISO/SAE 21434는 네 가지 요소를 고려합니다.

공격 가능성 평가 요소

· 경과 시간(Elapsed Time): 공격 준비에 필요한 시간
· 전문 지식(Specialist Expertise): 필요한 기술 수준
· 대상 지식(Knowledge of Item): 시스템 내부 정보 필요 여부
· 장비(Equipment): 특수 장비 필요 여부

각 요소를 점수화해 합산 → Low / Medium / High / Very High 4단계로 결정

6

위험도 결정 및 처리 방향 (Risk Determination & Treatment)

영향도와 공격 가능성을 조합해 최종 위험도를 결정합니다. 그리고 위험도에 따라 어떻게 처리할지를 결정합니다. 이 결정이 이후 보안 요구사항과 보안 설계로 이어집니다.

영향도 \ 공격 가능성	Low	Medium	High	Very High
S4 (심각)	높음	심각	심각	심각
S3 (높음)	중간	높음	심각	심각
S2 (보통)	낮음	중간	높음	높음
S1 (경미)	낮음	낮음	중간	중간

위험도가 나왔다 — 그다음은?

위험도가 결정됐다고 TARA가 끝나는 게 아닙니다. 각 위험에 대해 어떻게 처리할지를 결정해야 합니다. 선택지는 네 가지입니다.

경감 (Reduce)

보안 대책으로 위험을 낮춘다

가장 일반적인 선택입니다. Secure Boot, 코드 서명, SecOC 같은 기술 대책을 적용해 공격 가능성이나 영향도를 낮춥니다. 이 결정이 보안 요구사항으로 이어집니다.

허용 (Accept)

위험을 그대로 받아들인다

위험도가 낮거나, 대책 비용이 위험보다 훨씬 클 때 선택합니다. 단, "허용"도 근거가 문서화돼야 합니다. 이유 없는 허용은 심사에서 문제가 됩니다.

회피 (Avoid)

위험의 원인 자체를 제거한다

위험을 만드는 기능이나 연결 자체를 제거합니다. 예를 들어 "불필요한 외부 인터페이스를 아예 없앤다"는 식입니다. 근본적이지만 기능 제약이 따릅니다.

전가 (Share)

위험 책임을 다른 주체와 나눈다

보험, 계약, 사용자 동의 등으로 위험 책임을 분산합니다. 자동차 분야에서는 제한적으로 쓰이며, Safety 관련 위험에는 적용이 어렵습니다.

TS-01(OTA 변조)의 경우 위험도가 "심각"으로 나왔다면 → "경감" 선택 → 코드 서명 검증, TLS 통신, 안티 롤백 적용 → 이것이 보안 요구사항이 됩니다. TARA가 Secure Flash 구현의 근거가 되는 방식입니다.

TARA를 처음 수행할 때 자주 하는 실수들

• ⚠️
  자산 식별을 너무 좁게 한다 "ECU 펌웨어만 자산이다"라고 생각하기 쉽습니다. 하지만 통신 채널, 진단 인터페이스, 암호화 키, 사용자 데이터도 모두 자산입니다. 자산이 빠지면 그에 대한 위협도 빠집니다.
• ⚠️
  위협 시나리오를 너무 추상적으로 작성한다 "공격자가 시스템을 침해한다"는 위협 시나리오가 아닙니다. 누가, 어떤 경로로, 무엇을 목표로 공격하는지를 구체적으로 써야 합니다. 구체적이어야 영향도와 공격 가능성 평가도 의미가 있습니다.
• ⚠️
  공격 가능성을 감으로 평가한다 "이 공격은 어려울 것 같다"는 근거가 없는 평가입니다. 필요한 전문 지식, 장비, 시간을 구체적으로 검토해야 합니다. 근거 없는 낮은 공격 가능성 평가는 심사에서 반드시 지적됩니다.
• ⚠️
  TARA를 한 번 하고 서랍에 넣는다 시스템이 변경되거나 새로운 취약점이 발견되면 TARA를 업데이트해야 합니다. 처음 작성한 TARA가 양산까지 그대로 가는 경우가 있는데, 이는 CSMS 운영의 기본을 지키지 않는 것입니다.
• ⚠️
  위험 허용 근거를 문서화하지 않는다 "이 위험은 낮으니 그냥 둔다"고 결정했다면 왜 낮은지, 왜 대책이 필요 없는지를 기록해야 합니다. 근거 없는 허용은 인증 심사에서 반드시 문제가 됩니다.

현업에서는 실제로 이렇게 경험한다

TARA는 혼자 하는 게 아니다 — 제대로 된 TARA는 시스템 아키텍처를 아는 사람, 보안을 아는 사람, 실제 개발자가 함께 해야 합니다. 보안 담당자 혼자 문서를 쓰면 실제 공격 경로를 놓치기 쉽고, 개발자 혼자 하면 위협 평가가 너무 낙관적이 됩니다. 워크숍 형태로 진행하는 게 효과적입니다.

OEM마다 요구하는 깊이가 다르다 — 어떤 OEM은 위협 시나리오 수십 개를 요구하고, 어떤 OEM은 주요 시나리오 10개 정도면 충분합니다. 처음에 OEM의 요구 수준을 파악하지 않으면 너무 많이 하거나 너무 적게 해서 재작업이 발생합니다.

TARA 결과가 개발 결정을 바꾼다 — 잘 수행된 TARA는 단순한 문서가 아닙니다. "이 인터페이스는 위험도가 낮으니 SecOC 없이 가자", "이 공격 경로는 위험도가 높으니 게이트웨이 필터링을 강화하자" 같은 실제 설계 결정이 TARA에서 나옵니다. 처음에는 부담스럽지만 익숙해지면 설계 논의의 공통 언어가 됩니다.

추적성이 핵심이다 — TARA에서 도출된 위협 시나리오 → 보안 요구사항 → 설계 결정 → 검증 결과까지 이어지는 추적성이 없으면 TARA를 했더라도 의미가 반감됩니다. OEM에 증거를 제출할 때 "이 요구사항이 어느 위협에서 나왔냐"는 질문이 반드시 나옵니다.

마무리

TARA는 어렵습니다. 처음에는 어디서 시작해야 할지, 얼마나 깊이 해야 할지, 뭘 빠뜨렸는지 계속 불안합니다. 그건 다들 겪는 과정입니다.

중요한 건 완벽한 TARA가 아닙니다. 근거가 있는 TARA입니다. 왜 이 위협을 선택했는지, 왜 이 위험도를 매겼는지, 왜 이 대책을 골랐는지 — 그 판단의 흔적이 문서에 남아 있어야 합니다.

TARA는 보안의 정답을 찾는 도구가 아닙니다.
보안 결정을 방어 가능하게 만드는 도구입니다.

핵심 요약

• TARA는 "무엇을 왜 보호해야 하는가"에 대한 근거를 만드는 프로세스다
• 6단계: 아이템 정의 → 자산 식별 → 위협 시나리오 → 영향 평가 → 공격 가능성 → 위험도·처리 방향
• 영향 평가는 Safety·Financial·Operational·Privacy 4개 범주, 각 S1~S4
• 위험 처리는 경감·허용·회피·전가 중 선택 — 허용과 회피도 반드시 근거를 문서화해야 한다
• 자주 하는 실수: 자산 범위를 좁게 잡는 것, 위협을 추상적으로 쓰는 것, 공격 가능성을 감으로 평가하는 것
• TARA에서 나온 위협 → 보안 요구사항 → 설계 → 검증까지 추적성이 유지돼야 한다
• TARA는 일회성이 아니다 — 시스템 변경·새 취약점 발견 시 재검토가 필요하다

이 시리즈

1

자동차는 언제부터 '보안'을 고민하게 됐을까?

2

UNECE R155 쉽게 이해하기 — 도대체 뭘 요구하는 규정인가

3

CSMS는 실제로 무엇을 관리할까

4

ISO/SAE 21434는 왜 자동차 개발 프로세스를 바꿨을까?

5

TARA는 실제로 어떻게 수행할까?  ← 현재 글

TARA 위협분석 ISO21434 차량사이버보안 위험평가 UNECE_R155 보안요구사항 자동차보안개발 공격가능성평가 SecuritybyDesign