Security Impact Analysis는 어떻게 수행할까? — 변경관리에서 가장 중요한 한 장의 문서

보안 규제와 프로세스 — 실무 현장

변경관리 시리즈

1

이전 글

TARA는 언제 다시 해야 할까?

변경관리(Change Management)의 현실

DONE

2

지금 읽는 글

Security Impact Analysis는 어떻게 수행할까?

변경관리에서 가장 중요한 한 장의 문서

NOW

SIA를 논의할 때 자주 나오는 말

"SIA는 보안팀이 쓰는 거 아닌가요? 저는 시스템 담당인데요."

"No Impact라고 쓰면 왜 그런지 설명해야 하는 건가요?"

"변경이 너무 많아서 매번 SIA 하면 프로젝트가 안 돌아가요."

"OEM이 SIA 결과를 보고 싶다는데 어떤 형태로 제출해야 하나요?"

TARA 재수행 여부를 논하기 전에 먼저 해야 하는 활동이 있다.

이 변경이 보안에 영향을 주는가 — 그리고 왜 그렇게 판단했는가.

Security Impact Analysis(SIA)는 이 질문에 답하는 문서다. 그리고 OEM 심사에서 "TARA를 왜 다시 하지 않았는가"에 대한 유일한 근거가 되기도 한다.

---

SIA는 21434 어디에 위치하는가

먼저 한 가지를 명확히 해야 한다. ISO/SAE 21434가 "Security Impact Analysis"라는 이름으로 별도의 활동을 명시적으로 규정하지는 않는다. 다만 21434는 변경이 발생했을 때 보안 영향을 평가하고, 필요 시 사이버보안 활동을 재수행하도록 요구한다. SIA는 이 요구를 실무에서 구현하는 방식으로 업계에서 자리 잡은 개념이다.

ℹ️ 21434에서 변경 관련 요구사항 위치

Clause 8(사이버보안 관리)과 Clause 10(사이버보안 엔지니어링), Clause 12(사이버보안 운영)에 걸쳐 변경 발생 시 보안 영향을 평가하고 적절히 대응해야 한다는 요구가 분산되어 있다. 개발 단계와 양산 후 운영 단계 모두에서 변경관리 개념이 적용된다.

변경관리 흐름에서 SIA의 위치

변경 발생
(ECR/CR)

→

SIA
보안 영향
판단

→

TARA
재검토
여부 결정

→

Req·V&V
영향 분석

→

Cybersecurity
Case 업데이트

SIA는 TARA 재수행 여부를 결정하는 판단 단계다. 여기서 "No Impact"가 나오면 TARA는 그대로 유지된다 — 단, 그 판단 근거가 문서화되어야 한다.

---

SIA에서 답해야 하는 5가지 질문

SIA의 구조는 다음 다섯 가지 질문으로 구성된다. 하나라도 "예"가 나오면 TARA 재검토로 넘어가야 한다.

SIA 핵심 점검 항목

1

공격 표면(Attack Surface)이 변했는가? — 새로운 외부 연결(OTA, Bluetooth, Wi-Fi, USB 등)이 추가됐거나, 기존 인터페이스의 접근 범위가 달라졌다면 공격 표면이 변한 것이다. 공격자가 접근할 수 있는 진입점이 늘어났다는 의미다.

2

Asset이 변했거나 Asset 중요도가 달라졌는가? — 새로운 자산이 추가됐거나, 기존 자산의 역할이 바뀌어 Impact Rating이 달라질 수 있는 경우다. 상태 표시 ECU에 제어 기능이 추가되는 것이 대표적인 예다.

3

신뢰 경계(Trust Boundary)가 변했는가? — 차량 내부 네트워크에서 클라우드 연동, 외부 앱 연결 등으로 신뢰 경계가 확장됐다면 기존 TARA의 Item Boundary가 더 이상 유효하지 않을 수 있다. 가장 많이 놓치는 항목이다.

4

기존 보안 요구사항이 영향을 받는가? — 변경으로 인해 기존 Requirement가 더 이상 충분하지 않거나, 새로운 Requirement가 필요해지는 경우다. OTA가 추가되면 Update Package 인증, Rollback Protection 등이 새로 필요해지는 식이다.

5

기존 시험 결과가 여전히 유효한가? — Penetration Test나 Vulnerability Analysis 결과가 변경 이후에도 충분한 커버리지를 제공하는가. 새로운 공격 표면이 생겼다면 기존 시험 범위 밖일 수 있다.

---

SIA는 보안팀 혼자 쓰는 문서가 아니다

SIA를 "보안팀이 작성하는 문서"로 오해하는 경우가 많다. 그런데 위 5가지 질문을 보면 알 수 있듯이, 보안 지식만으로는 답할 수 없는 항목이 절반 이상이다.

❌ SIA는 보안 엔지니어가 혼자 작성하는 문서다

✅ SIA는 시스템 지식과 보안 지식이 모두 필요한 협업 결과물이다

"Trust Boundary가 변했는가"를 판단하려면 시스템 엔지니어가 아키텍처 변경 내용을 이해해야 한다. "Attack Surface가 변했는가"를 판단하려면 어떤 인터페이스가 추가됐는지 알아야 한다. "기존 V&V가 유효한가"는 시험 범위를 아는 사람이 답해야 한다. 보안 엔지니어는 이 정보를 받아 보안 관점에서 해석하고 판단한다.

---

SIA 결과는 세 가지로 나온다

SIA 수행 결과는 일반적으로 영향 수준에 따라 세 가지로 분류된다. 조직마다 표현이 다를 수 있지만 실무에서 자주 쓰이는 구조다.

CASE 1

No Security Impact

예: 오타 수정, UI 변경, 로그 추가, 보안 기능과 무관한 버그 수정

TARA 유지

Requirement 유지

V&V 유지

CASE 2

Limited Impact

예: 기존 범위 내 파라미터 변경, 인터페이스 변경 없는 내부 로직 수정

TARA 부분 검토

일부 Req 재검토

영향 범위 시험 재수행

CASE 3

Major Security Impact

예: 새 인터페이스 추가, OTA 기능 추가, 아키텍처 변경, 중대 CVE 발견

TARA 재검토

Requirement 재작성

V&V 재계획

⚠️ "No Impact"가 가장 어렵다

실무에서 "Major Impact"는 오히려 처리가 명확하다 — 다시 하면 된다. 어려운 것은 "No Impact" 판정이다. OEM 심사에서 가장 많이 받는 질문이 "왜 영향이 없다고 판단했는가? 근거가 무엇인가?"다. No Impact 결론을 내릴수록 근거 문서가 더 탄탄해야 한다.

---

좋은 SIA 문서에 들어가야 하는 것

SIA 문서의 형식은 조직마다 다르다. 다만 OEM 심사에서 공통적으로 요구받는 내용들이 있다.

항목	내용	없으면 생기는 문제
변경 내용 요약	어떤 변경인지, 무엇이 달라지는지 명확히 기술	심사관이 변경 범위를 알 수 없음
영향 판단 근거	5가지 질문 항목별로 "예/아니오" + 판단 이유	"왜 영향 없다고 했나" 질문에 답 불가
관련 TARA 항목 참조	영향받을 수 있는 Asset, Threat Scenario, Risk 항목	추적성 연결 불가
결론 및 후속 조치	No Impact / Limited / Major 분류, 재수행 필요 항목 목록	다음 단계가 무엇인지 불명확
검토자·승인자	누가 판단했고 누가 승인했는지	"누가 책임지는가" 질문에 답 불가

💡 한 장짜리 문서로도 충분하다

SIA는 반드시 긴 문서일 필요가 없다. 위 5가지 질문에 항목별로 "예/아니오 + 한 줄 근거"를 작성하고, 결론과 후속 조치, 검토자가 명시된 한 장짜리 문서로도 OEM 심사에서 설명이 된다. 형식보다 판단 근거의 논리성이 더 중요하다.

---

모든 변경에 SIA를 해야 하는가

현실적인 질문이다. 개발 중 변경은 수백 건이 발생한다. 모든 변경에 SIA를 수행하면 프로젝트가 느려진다.

실무에서 작동하는 방식은 변경 요청(CR/ECR) 단계에서 빠른 사전 필터링을 두는 것이다. 보안 관련 가능성이 있는 변경은 SIA로 넘기고, 명백하게 보안과 무관한 변경(텍스트 수정, UI 색상 변경 등)은 그냥 처리한다. 이 필터링 자체도 간단한 체크리스트로 운영할 수 있다.

ℹ️ SIA 필요 여부를 빠르게 판단하는 질문 3가지

1. 이 변경이 외부 인터페이스나 통신 프로토콜과 관련이 있는가?
2. 이 변경이 보안 기능(인증, 암호화, 접근 제어)의 동작에 영향을 주는가?
3. 이 변경으로 인해 새로운 기능이 추가되거나 ECU의 역할이 달라지는가?

하나라도 "예"라면 SIA가 필요하다. 셋 다 "아니오"라면 SIA 없이 처리 가능하다.

---

🔧 현업에서 느끼는 변화들

SIA 없이 TARA 재수행 여부를 논하면 매번 직관에 의존하게 된다 — 변경이 생길 때마다 "이거 TARA 다시 해야 하나?"를 회의에서 결정하면 담당자마다 판단이 다르고 일관성이 없다. SIA를 프로세스로 두면 판단의 기준이 생기고, 결과가 문서로 남는다.

CVE 대응과 SIA가 연결되지 않는 경우가 많다 — CVE가 발견되면 패치를 적용하는 것은 잘 된다. 그런데 그 CVE가 기존 TARA의 어떤 위협 시나리오와 연결되는지, Attack Feasibility가 달라지는지까지 SIA로 검토하는 경우는 드물다. 패치는 했지만 TARA·Requirement와 추적성이 끊기는 전형적인 패턴이다.

양산 후 운영 단계에서 SIA의 중요성이 더 커진다 — 개발 단계에서는 그나마 변경 관리 프로세스가 있다. 양산 이후 OTA 업데이트, 취약점 패치, 기능 추가가 반복되는 시점에서 SIA 없이 운영하면 어느 순간 보안 상태를 추적하기 어려워진다. R155가 양산 후 운영을 CSMS의 범위에 포함시킨 이유가 여기 있다.

변경관리에서 중요한 것은 모든 변경을 TARA로 끌어올리는 것이 아니다.

영향 있는 변경을 놓치지 않는 것 — 그리고 영향 없다는 판단도 근거를 남기는 것.

Security Impact Analysis는 그 판단을 문서로 만드는 활동이다.

핵심 요약

1

SIA는 TARA 재수행 전에 수행하는 영향 판단 활동이다 — 21434에 해당 이름으로 명시되진 않지만, 변경 발생 시 보안 영향을 평가하라는 요구를 실무에서 구현하는 방식이다.

2

5가지 질문이 핵심이다 — 공격 표면 변화 / Asset 변화 / Trust Boundary 변화 / Requirement 영향 / V&V 유효성. 하나라도 "예"가 나오면 TARA 재검토로 넘어간다.

3

시스템 엔지니어와 보안 엔지니어 협업이 필요하다 — 아키텍처와 인터페이스 변경 내용은 시스템 엔지니어가, 보안 관점 해석은 보안 엔지니어가 담당한다.

4

"No Impact"가 가장 어렵다 — OEM 심사에서 "왜 영향 없다고 판단했는가"가 가장 많이 나오는 질문이다. 결론보다 근거가 중요하다.

5

한 장짜리 문서도 충분하다 — 형식보다 판단 근거의 논리성이 중요하다. 5가지 질문 항목별 판단 이유, 결론, 검토자·승인자가 있으면 기본은 된다.

SecurityImpactAnalysis SIA 변경관리 ChangeManagement ISO/SAE21434 TARA 자동차사이버보안 추적성 CSMS CybersecurityCase