1. 시스템을 모르면 TARA는 공허해진다
TARA의 첫 번째이자 가장 중요한 전제는 분석 대상 시스템에 대한 충분한 이해입니다. 당연한 이야기처럼 들리지만, 실제로는 시스템 아키텍처 문서를 대충 훑어본 뒤 곧바로 자산 식별에 들어가는 경우가 많습니다. 이렇게 시작된 TARA는 높은 확률로 두 가지 문제를 만듭니다.
첫째, 공격 표면을 놓칩니다. 데이터가 어디서 생성되어 어디로 흐르는지, 어떤 인터페이스를 통해 외부와 접촉하는지를 파악하지 못하면, 위협 열거 단계에서 중요한 공격 경로가 빠집니다. 예를 들어, ADAS 시스템에서 카메라 센서 데이터가 전용 링크로 전달되는지, 차량 내부 네트워크를 경유하는지에 따라 위협의 성격이 완전히 달라집니다.
둘째, 가정이 암묵적으로 남습니다. “이 ECU는 신뢰할 수 있는 소프트웨어만 실행한다”와 같은 가정은 명시적으로 문서화되지 않으면, 나중에 해당 가정이 깨졌을 때 TARA 전체를 재검토해야 하는 상황에 놓이게 됩니다.
실무 권장 사항: TARA를 시작하기 전에 반드시 컨텍스트 다이어그램을 준비하십시오. 분석 대상 시스템이 차량 환경 내에서 어떤 위치에 있는지, 어떤 외부 엔티티와 어떤 방식으로 통신하는지를 시각화해야 합니다. 그리고 가정 목록을 별도로 작성하십시오. “카메라 센서와 SoC 사이는 전용 링크이므로 네트워크 기반 위협은 제외한다”처럼, 분석 범위에 영향을 미치는 모든 전제를 명시하는 것이 중요합니다. 이 가정들은 나중에 시스템 변경이 발생했을 때 TARA를 업데이트해야 하는지 판단하는 기준이 됩니다.
2. 범위 설정의 딜레마 - 너무 넓지도, 너무 좁지도 않게
ISO/SAE 21434는 아이템(Item) 또는 컴포넌트(Component) 단위로 TARA를 수행하도록 안내합니다. 그러나 현실에서는 “아이템”의 경계를 어디까지로 볼 것인가에 대해 팀 내에서 합의가 이루어지지 않는 경우가 빈번합니다.
한 가지 주의할 점은, 범위를 좁게 설정했을 때 인접 시스템의 위협을 “남의 일”로 치부하지 않는 것입니다. DVR 기능의 TARA에서 AEB 기능 자체의 위협은 제외하더라도, AEB 이벤트 트리거 신호가 DVR로 전달되는 과정의 위협은 DVR TARA의 범위에 포함되어야 합니다.
3. 자산 식별 - 카탈로그를 만들어 반복을 줄여라
자산 식별은 TARA의 기초 공사입니다. 여기서 빠진 자산은 이후 모든 단계에서 보이지 않는 사각지대가 됩니다. 그런데 프로젝트마다 매번 백지 상태에서 자산을 도출하는 것은 비효율적일 뿐만 아니라, 팀마다 자산 정의의 추상화 수준이 달라지는 문제를 야기합니다.
이를 해결하는 방법이 자산 카탈로그입니다. 보안 아키텍트가 시스템을 자산 카테고리로 분류한 참조 목록을 만들어 두면, 각 TARA 수행 팀은 이 카탈로그를 체크리스트처럼 활용하여 누락 없이 자산을 식별할 수 있습니다.
자산 카탈로그의 카테고리 예시로는 플래시 메모리에 저장된 소프트웨어 바이너리, 런타임 메모리에 로드된 캘리브레이션 데이터, 네트워크를 통해 전송 중인 제어 메시지, 외부 저장 매체에 기록된 로그 데이터, 하드웨어 보안 모듈(HSM/HPSE) 내부의 암호화 키 등이 있습니다.
자산을 식별할 때 반드시 자산의 상태를 함께 기록하십시오. 동일한 데이터라도 전송 중(in transit), 저장 중(at rest), 사용 중(in use)에 따라 노출되는 위협이 다릅니다. “카메라 영상 데이터”라고만 적는 것과 “LPDDR5 메모리에 버퍼링 중인 카메라 영상 데이터”라고 적는 것은 이후 위협 분석의 구체성에서 큰 차이를 만듭니다.또한 자산 카테고리를 위협 클래스에 미리 매핑해 두면, 새로운 TARA를 시작할 때 공통 위협 카탈로그의 위협을 바로 활용할 수 있어 위협 커버리지를 극대화하고 팀 간 불일치를 방지할 수 있습니다.
4. 피해 시나리오 - "누가, 무엇을 잃는가"에 집중하라
피해 시나리오(Damage Scenario)는 자산의 사이버보안 속성이 침해되었을 때 이해관계자에게 미치는 실질적 피해를 기술하는 단계입니다. 이 단계에서 흔히 발생하는 실수는 피해 시나리오를 기술적 용어로만 작성하는 것입니다. “CAN 메시지의 무결성 침해”는 위협 설명이지, 피해 시나리오가 아닙니다. 피해 시나리오는 “조향 제어 알고리즘의 오작동으로 인한 불규칙한 조향, 부족 조향 또는 과조향”처럼 최종 사용자나 이해관계자 관점에서의 결과를 담아야 합니다.
ISO/SAE 21434는 피해를 안전(Safety), 재정(Financial), 운영(Operational), 프라이버시(Privacy) 네 가지 영역으로 분류합니다. 피해 시나리오를 작성할 때 이 네 가지 관점을 체크리스트로 활용하면 누락을 줄일 수 있습니다.
한 가지 실무적 팁을 덧붙이자면, 피해 시나리오에 원인을 포함하지 않는 것이 분석 효율 면에서 유리합니다. “네트워크 공격으로 인한 비디오 삭제”와 “물리적 접근으로 인한 비디오 삭제”를 별도 피해 시나리오로 분리하면, 영향 등급 산정과 위협 매핑의 조합이 불필요하게 늘어납니다. 피해 시나리오는 “비디오 기록의 영구 삭제로 인한 사고 책임 규명 불가”처럼 원인과 무관하게 결과만 기술하고, 원인은 위협 시나리오 단계에서 다루는 것이 효율적입니다.
5. 위협 열거 - STRIDE를 자산 속성 중심으로 적용하라
위협을 열거할 때 가장 널리 사용되는 프레임워크가 STRIDE입니다. 스푸핑(Spoofing), 변조(Tampering), 부인(Repudiation), 정보 노출(Information Disclosure), 서비스 거부(Denial of Service), 권한 상승(Elevation of Privilege)의 여섯 가지 위협 유형을 자산 속성에 대입하여 위협을 체계적으로 도출합니다.
여기서 중요한 원칙이 있습니다. STRIDE는 공격 기법의 분류가 아니라, 자산 속성에 대한 위협의 분류라는 점입니다. “CAN 메시지를 변조한다”는 공격 기법이고, “카메라 영상 데이터의 무결성이 침해된다”가 위협입니다. 이 구분이 흐려지면 동일한 위협이 여러 번 중복 열거되거나, 반대로 하나의 공격이 여러 자산 속성에 미치는 영향이 누락됩니다.
예를 들어, 카메라 영상 데이터의 CRC 필드를 변조하는 공격을 생각해 봅시다. 이 공격의 직접적 결과는 영상 데이터의 무결성 침해입니다. 그러나 ADAS가 해당 데이터를 무효로 판단하여 폐기하면, 결과적으로 영상 데이터의 가용성 손실로 이어집니다. 하나의 공격이 두 가지 자산 속성에 영향을 미치는 것이며, 각각에 대해 피해 시나리오와의 매핑이 필요합니다.
위협 카탈로그를 구축하는 것도 강력히 권장합니다. 자산 카테고리별로 반복적으로 나타나는 위협 패턴을 카탈로그화하면, 새로운 TARA에서 위협 열거의 출발점으로 활용할 수 있습니다. ENISA의 차량 보안 보고서, CWE(Common Weakness Enumeration), CAPEC(Common Attack Pattern Enumeration and Classification) 같은 외부 데이터베이스도 위협 카탈로그의 좋은 입력 소스가 됩니다.
6. 공격 경로 분석 - 아키텍처 지식이 핵심이다
위협 시나리오가 정의되었다면, 이제 그 위협이 실제로 어떤 경로를 통해 실현될 수 있는지 분석해야 합니다. 이 단계야말로 시스템 아키텍처에 대한 깊은 이해가 빛을 발하는 지점입니다.
공격 경로 분석에서 공격 트리(Attack Tree)는 매우 유용한 도구입니다. 최종 목표(위협 시나리오 실현)를 루트 노드에 놓고, 이를 달성하기 위한 하위 단계들을 트리 형태로 전개합니다. 각 단계가 어떤 피해 시나리오에 기여하는지를 시각적으로 표현할 수 있어, 복잡한 다단계 공격의 구조를 명확히 파악할 수 있습니다.
실무에서 공격 경로를 정의할 때 주의해야 할 점은, 외부 아이템을 공격의 시작점으로 삼지 않는 것입니다. “텔레매틱스 장치가 이미 침해된 상태에서 CAN 메시지를 조작한다”는 유효한 공격 경로이지만, 텔레매틱스 장치 자체를 어떻게 침해하는지는 해당 TARA의 범위가 아닙니다. 공격 경로는 분석 대상 시스템의 경계에서 시작되어야 합니다.
비디오 녹화 기능의 예를 들면, 텔레매틱스 장치를 통한 네트워크 접근에서 시작하여 ADAS 시스템과의 CAN 통신 세션에서 유효한 카메라 영상 메시지를 주입하고, 카메라 영상을 위조하여 ADAS 시스템의 비디오 녹화 데이터를 오염시키는 것이 하나의 공격 경로가 될 수 있습니다.
7. 리스크 평가 - 공격 가능성과 영향의 균형
리스크 값은 공격 가능성 등급(Attack Feasibility Rating)과 영향 등급(Impact Rating)의 조합으로 산출됩니다. ISO/SAE 21434는 구체적인 산출 방법을 강제하지 않지만, 최종 리스크 값이 1에서 5 사이의 정수여야 한다고 요구합니다.
공격 가능성을 평가할 때는 다음 요소들을 고려합니다.
- 필요 시간: 공격을 준비하고 실행하는 데 소요되는 기간
- 전문 지식: 공격자에게 요구되는 기술적 역량 수준
- 장비: 공격에 필요한 하드웨어/소프트웨어 도구의 접근성
- 시스템 접근성: 공격 대상에 물리적 또는 논리적으로 접근하는 난이도
영향 등급은 안전, 재정, 운영, 프라이버시 각 영역에서의 피해 심각도를 평가하되, 가장 높은 영향을 대표값으로 사용합니다. 자동차 도메인에서는 HEAVENS나 EVITA 같은 기존 프레임워크를 활용하거나 조직 자체의 프레임워크를 개발하여 사용할 수 있습니다.
리스크 평가에서 가장 빈번하게 발생하는 논쟁은 공격 가능성의 주관성입니다. 같은 공격 경로에 대해 “전문가급 장비가 필요하므로 낮음”이라고 보는 시각과 “공개된 취약점이 있으므로 높음”이라고 보는 시각이 충돌합니다. 이를 완화하기 위해, 공격 가능성 평가 시 근거(rationale)를 반드시 함께 기록하고, 가능한 한 공개된 취약점 데이터베이스나 업계 사례를 참조하여 객관성을 확보하십시오.
8. 리스크 처리 결정 - "모든 위험을 완화"가 답은 아니다
리스크 평가가 완료되면, 각 위험에 대해 처리 방식을 결정해야 합니다. ISO/SAE 21434는 위험 완화(mitigation), 위험 전가(transfer), 위험 수용(acceptance)의 선택지를 제공합니다.
현장에서 자주 관찰되는 두 가지 극단이 있습니다.
첫 번째 극단은 모든 위험을 완화하려는 접근입니다. 이 경우 보안 요구사항의 수가 폭발적으로 증가하여 프로젝트 일정과 비용에 심각한 영향을 미칩니다. 더 심각한 것은, 정작 고위험 항목에 충분한 자원이 투입되지 못하는 결과를 초래할 수 있다는 것입니다.
두 번째 극단은 대부분의 위험을 수용하는 접근입니다. “현실적으로 발생 가능성이 낮다”는 논리로 위험을 수용하다 보면, 결국 아무 조치도 취하지 않는 상황에 빠집니다. 이는 이해관계자 모두가 보안 위험에 노출되어 있다는 사실 자체를 모호하게 만들고, 사후 사고 발생 시 적절한 주의의무(due diligence)를 다했는지 의문을 제기하게 합니다.
올바른 접근은 리스크 값에 기반한 체계적 의사결정입니다. 즉 현재 TARA나 HARA 모두 Risk 기반 접근법입니다. TARA의 경우, 5- Critical, 4-High, 3-Medium, 2-Low, 1-Very low로 분류를 합니다. 이런 리스크 값에 따라서 조직 내에서 리스크 처리 정책을 사전에 정의하고, 예를 들어 리스크 값 4 이상은 반드시 완화, 2 이하는 근거와 함께 수용 가능, 3은 사례별 판단과 같은 기준을 수립하면, 개별 TARA에서의 의사결정이 일관되고 효율적으로 이루어집니다.
위험을 수용할 때는 반드시 사이버보안 클레임(Cybersecurity Claim)을 작성하여, 수용의 근거와 조건을 명확히 문서화해야 합니다. “SoC 내부에 악성 애플리케이션을 설치하는 것이 기술적으로 어렵고, 그에 따른 리스크 값이 낮으므로 해당 위험을 수용한다”는 식으로, 어떤 조건 하에서 해당 결정이 유효한지를 분명히 남겨야 합니다.
9. 보안 요구사항 도출 - 컨트롤과 요구사항을 통합하라
리스크 처리 결정에서 완화로 분류된 항목들에 대해 사이버보안 목표(Cybersecurity Goal)를 정의하고, 이를 달성하기 위한 보안 컨트롤 및 요구사항을 도출합니다.
실무에서 효과적인 방법은 보안 컨트롤을 요구사항 정의에 통합하는 것입니다. “ADAS 시스템은 비휘발성 메모리에 저장하기 전에 위조 불가능한 타임스탬프를 포함하는 비디오 데이터에 디지털 서명을 적용해야 한다”처럼, 요구사항 문장 자체에 적용되는 컨트롤(데이터 인증, 재생 방지)이 드러나도록 작성하면 가독성과 추적성이 모두 향상됩니다.
보안 요구사항을 도출할 때 반드시 공격 경로를 역으로 검토하십시오. 각 공격 경로의 어떤 단계를 차단하는 것이 가장 효과적인지, 하나의 컨트롤이 여러 공격 경로를 동시에 차단할 수 있는지를 분석하면, 최소한의 보안 컨트롤로 최대한의 위험 감소 효과를 얻을 수 있습니다.
컨셉 수준의 요구사항이 도출되면, 이를 하드웨어 및 소프트웨어 보안 요구사항으로 분해하는 과정이 이어집니다. 이 과정에서 설계 각 계층의 아키텍처 약점을 식별하기 위해 TARA의 추가 정제가 필요할 수 있습니다.
10. 검토, 유지보수, 그리고 TARA의 생명주기
TARA는 한 번 작성하고 끝나는 산출물이 아닙니다. 검토와 승인을 거친 후에도 유지보수 단계에서 지속적으로 업데이트되어야 합니다.
검토 단계에서는 다음 항목들을 체크리스트로 활용할 수 있습니다. 자산 범위가 적절한지, 위협이 충분히 열거되었는지, 공격 설명이 의미 있는지, 피해 시나리오와 위협 시나리오의 매핑이 적절한지, 잔존 위험 점수가 정확한지, 리스크 처리 결정의 근거가 타당한지, 선택된 보안 컨트롤이 적절한지를 평가합니다.
유지보수 관점에서 특히 중요한 원칙은, TARA 외부에서 비공식적인 보안 분석을 수행하지 않는 것입니다. 개발 과정에서 “이건 간단한 문제니까 TARA에 안 넣어도 되겠지”라는 판단이 반복되면, 위험이 중앙에서 관리되지 않고 분산되어 전체적인 보안 상황을 파악하기 어려워집니다. 모든 보안 관련 결정은 TARA에 공식적으로 기록하여, 체계적인 위험 주도 접근 방식이 일관되게 적용되도록 해야 합니다.
또한 앞서 기술한 가정 목록이 여기서 다시 중요해집니다. 시스템에 새로운 기능이 추가되거나 아키텍처가 변경될 때, 기존 가정이 여전히 유효한지를 검토하는 것만으로도 TARA 업데이트의 필요성을 빠르게 판단할 수 있습니다.
마무리 - 합리적 시간 안에 가치 있는 결과를
TARA의 궁극적 목표는 형식적 절차의 완수가 아니라, 합리적인 시간 안에 제품의 보안 수준을 실질적으로 높이는 것입니다. 이를 위해 핵심 원칙을 정리하면 다음과 같습니다.
- 시스템을 먼저 이해하고, 가정을 명시적으로 문서화하십시오
- 자산 카탈로그와 위협 카탈로그를 조직 차원에서 구축하여 반복적인 분석 비용을 줄이십시오
- 피해 시나리오는 이해관계자 관점에서, 위협은 자산 속성 중심으로 작성하십시오
- 리스크 처리 정책을 사전에 정의하여 의사결정의 일관성을 확보하십시오
- 보안 요구사항 도출 시 공격 경로를 역으로 검토하여 효율적인 컨트롤을 선택하십시오
- 모든 보안 결정을 TARA에 공식 기록하고, 시스템 변경 시 반드시 재검토하십시오
TARA는 보안 엔지니어링의 출발점입니다. 잘 수행된 TARA는 프로젝트 전체의 보안 활동에 명확한 방향을 제시하고, 한정된 자원을 가장 효과적으로 배분할 수 있는 근거를 제공합니다.
참고문헌
- Automotive Cybersecurity Engineering Handbook