보안 요구사항은 누가 작성해야 할까? — 시스템 엔지니어 vs 보안 엔지니어의 현실

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

프로젝트 회의실에서 자주 듣는 말

"보안 요구사항은 보안팀이 쓰는 거 아닌가요? 저는 시스템만 알아요."

"저는 보안은 아는데 이 ECU 구조를 몰라서요. 시스템팀이 먼저 써주면 리뷰할게요."

"Secure Boot 적용이라고 쓰면 되는 거 아닌가요?"

"TARA 결과가 나왔으니까 요구사항은 자동으로 나오는 거 아닌가요?"

보안 요구사항 작성 시점이 오면 회의실에 이상한 침묵이 흐른다.

시스템팀은 "보안은 보안팀이 더 잘 알지 않나요?"라고 하고, 보안팀은 "시스템 구조는 시스템팀이 더 잘 아시잖아요."라고 한다.

결국 아무도 쓰지 않는다. 그리고 프로젝트 후반에 터진다.

---

보안 요구사항은 21434 어느 단계에서 나오는가

먼저 짚고 넘어가야 할 것이 있다. 보안 요구사항(Security Requirement)이 개발 프로세스의 어느 단계에서 만들어지는 산출물인지다. 이걸 모르면 누가 작성해야 하는지도 논의가 어렵다.

ISO/SAE 21434 — 보안 요구사항이 등장하는 위치

Clause 9
TARA
위협 분석

→

Cybersecurity
Goal
보안 목표

→

Clause 10
Security
Requirement

→

설계·구현

→

Clause 11
V&V

보안 요구사항은 TARA 이후, 설계·구현 이전 단계에 위치한다. Clause 10의 핵심 산출물이다.

보안 요구사항은 TARA에서 도출된 Cybersecurity Goal을 구체화하는 문서다. Goal이 "차량 속도 메시지의 무결성이 보장되어야 한다"라면, 이것을 달성하기 위해 ECU 레벨에서 무엇을 해야 하는지를 구체적으로 기술하는 것이 Security Requirement다. 그리고 이 요구사항은 이후 Clause 11의 V&V에서 검증 대상이 된다.

ℹ️ 보안 요구사항이 중요한 이유 — 추적성

21434는 Threat Scenario → Cybersecurity Goal → Security Requirement → 구현 → 검증으로 이어지는 추적성(Traceability)을 요구한다. 보안 요구사항이 이 체인의 중간 고리다. 여기서 연결이 끊기면 OEM 심사에서 가장 먼저 지적받는다.

---

보안 요구사항이라고 보안팀이 쓰는 게 맞을까

보안 요구사항이라는 이름 때문에 자연스럽게 "보안 엔지니어가 작성하는 것"으로 인식되는 경우가 많다. 하지만 실제로는 그렇게 단순하지 않다.

❌ 보안 요구사항 = 보안 엔지니어가 작성하는 문서

✅ 보안 요구사항 = 시스템 지식 + 보안 지식이 모두 필요한 문서

보안 엔지니어는 어떤 공격을 막아야 하는지 알지만, 해당 ECU의 부트로더 구조, MCU 성능, HSM 탑재 여부, OTA 지원 여부를 모를 수 있다. 시스템 엔지니어는 ECU 구조를 훤히 알지만, 왜 이 메시지를 보호해야 하는지, 어떤 공격 시나리오를 막아야 하는지까지는 모를 수 있다. 어느 한쪽만으로는 좋은 보안 요구사항이 나오기 어렵다.

시스템 엔지니어가 아는 것

무엇을 보호할 것인가

ECU 기능과 역할

인터페이스와 데이터 흐름

어떤 신호가 안전에 영향을 주는가

MCU 성능·HSM 탑재 여부

구현 가능한 범위

보안 엔지니어가 아는 것

어떻게 보호할 것인가

TARA 결과 해석

공격 시나리오와 위협 맥락

어떤 보안 메커니즘이 필요한가

요구사항 작성 방법론

검증 기준 설정

---

TARA가 끝나면 요구사항이 자동으로 나오지 않는다

또 하나 자주 생기는 오해가 있다. "TARA만 잘 하면 보안 요구사항은 자동으로 나오는 것 아닌가?"라는 생각이다.

TARA는 어떤 위협이 있고 리스크가 얼마나 큰지를 분석한다. 그 결과로 Cybersecurity Goal이 나온다. 예를 들면 "차량 속도 메시지의 무결성이 보장되어야 한다"는 식의 추상적인 목표다.

이것을 실제 ECU 개발에서 구현할 수 있는 요구사항으로 만드는 작업이 Clause 10에서 일어난다. 이 변환 과정이 자동으로 되지 않는다는 게 핵심이다.

Cybersecurity Goal → Security Requirement 변환 과정

1

Cybersecurity Goal (추상적) — "차량 속도 메시지의 무결성이 보장되어야 한다." — TARA에서 나온 결과. 어떤 ECU인지, 어떻게 구현할지는 아직 정해지지 않았다.

2

시스템 맥락 반영 (시스템 엔지니어 역할) — 이 메시지를 수신하는 ECU는 어디인가? 해당 ECU에 HSM이 있는가? 메시지 주기와 payload 크기는? — 이 정보가 없으면 요구사항을 구체화할 수 없다.

3

보안 메커니즘 결정 (보안 엔지니어 역할) — 무결성 검증에는 어떤 방법이 적합한가? SecOC를 쓸 것인가, 다른 방식인가? CAL은 몇 등급인가? — 공격 시나리오와 리스크 수준을 알아야 판단할 수 있다.

4

Security Requirement (구체적) — "속도 제어 ECU는 수신한 차량 속도 메시지의 무결성을 CMAC 기반으로 검증해야 하며, 검증 실패 시 해당 메시지를 폐기해야 한다." — 구현 가능하고 검증 가능한 수준.

---

좋은 요구사항과 나쁜 요구사항 — 가장 흔한 실수

현장에서 가장 자주 나오는 문제는 요구사항이 기술 이름으로 작성되는 경우다.

❌ 나쁜 요구사항 — 해결책이 요구사항 자리에 있다

REQ-001: ECU는 Secure Boot를 적용해야 한다.
REQ-002: 통신 메시지에 SecOC를 적용해야 한다.
REQ-003: HSM을 사용해야 한다.

기술 이름이 요구사항처럼 쓰였다. 설계가 변경되면 추적성이 끊기고, 왜 이 기술이 필요한지 근거가 없다. OEM 리뷰에서 가장 자주 지적받는 패턴이다.

✅ 좋은 요구사항 — 보호 목적이 명확하다

REQ-001: ECU는 부팅 시 실행되는 소프트웨어의 무결성을 검증해야 한다.
REQ-002: ECU는 수신한 제어 메시지의 무결성과 송신자 진위를 검증해야 한다.
REQ-003: 암호키는 외부에서 접근 불가능한 영역에 저장되어야 한다.

무엇을 달성해야 하는지가 명확하다. 이 요구사항을 만족하기 위한 기술(Secure Boot, SecOC, HSM)은 설계 단계에서 선택된다. 설계가 바뀌어도 요구사항은 유지된다.

💡 Requirement → Solution 순서가 되어야 한다

"소프트웨어 무결성을 검증해야 한다(Requirement)" → "Secure Boot를 적용한다(Solution)"
반대로 "Secure Boot 적용(Solution)"이 먼저 결정되고 요구사항을 역으로 쓰면, 설계 변경 시 추적성이 무너진다.

---

실제 프로젝트에서 나타나는 세 가지 패턴

현장을 보면 보안 요구사항 작성 방식이 세 가지로 나뉜다.

패턴	방식	장점	단점	주로 나타나는 곳
시스템팀 주도	시스템 엔지니어 작성 → 보안팀 리뷰	시스템 반영 잘 됨	보안 관점 누락 가능	대형 OEM, 보안 조직 성숙한 곳
보안팀 주도	보안 엔지니어 작성 → 시스템팀 리뷰	보안 품질 확보	구현 가능성 검토 부족	보안 전담팀이 있는 곳
공동 작성	두 팀이 함께 작성	추적성·구현 가능성 모두 높음	시간이 오래 걸림	21434 관점에서 가장 이상적

어느 패턴이 맞는지는 조직 구조와 프로젝트 상황에 따라 다르다. 다만 한 가지는 분명하다. 패턴 자체보다 두 관점이 실제로 반영되었는가가 결과물의 품질을 결정한다.

---

OEM이 보안 요구사항 리뷰에서 실제로 보는 것

OEM 심사에서 보안 요구사항을 볼 때 기술 이름이 맞는지를 먼저 확인하지 않는다. 보는 것은 다음 세 가지다.

OEM 보안 요구사항 리뷰 체크포인트

1

추적성 (Traceability) — Threat Scenario → Cybersecurity Goal → Security Requirement 연결이 끊기지 않는가? 요구사항이 어떤 위협을 근거로 나왔는지 추적 가능한가?

2

검증 가능성 (Verifiability) — 이 요구사항이 만족됐는지 어떻게 확인할 수 있는가? Verification Method가 정의되어 있는가? "검증해야 한다"는 요구사항에 "어떻게 검증할 것인가"가 없으면 Clause 11에서 막힌다.

3

구현 가능성 (Feasibility) — 실제 ECU 환경에서 구현 가능한 수준인가? HSM이 없는 ECU에 HSM 기반 암호 연산을 요구하는 식의 실현 불가능한 요구사항이 없는가?

---

🔧 현업에서 느끼는 변화들

보안 요구사항이 가장 많이 재작업되는 단계다 — TARA는 그나마 프로세스가 잡혀가고 있다. 그런데 TARA 결과를 받아서 이것을 실제 개발 가능한 요구사항으로 변환하는 Clause 10 단계에서 재작업이 가장 많이 발생한다. Goal 수준의 문장을 그대로 요구사항으로 올리거나, 반대로 구현 방법을 요구사항 자리에 쓰는 경우가 많다.

시스템 엔지니어와 보안 엔지니어가 같은 회의에 앉기 시작했다 — 예전에는 TARA는 보안팀이 하고 설계는 시스템팀이 하는 식으로 분리되어 있었다. 최근 OEM 심사에서 추적성 문제가 계속 나오면서, 두 팀이 요구사항 작성 단계부터 함께 앉는 프로젝트가 늘고 있다. 처음에는 회의 시간이 길어지지만, 후반부 재작업이 줄어든다.

"Secure Boot 적용"이 요구사항으로 들어오면 V&V에서 막힌다 — 기술 이름이 요구사항 자리에 있으면, Clause 11 검증 단계에서 이 요구사항을 어떻게 시험해야 하는지 기준을 잡기 어렵다. "Secure Boot가 동작한다"를 어떻게 시험하는가? 반면 "소프트웨어 무결성을 검증해야 한다"는 요구사항은 "변조된 이미지로 부팅 시도 시 부팅이 차단되어야 한다"는 시험 케이스가 자연스럽게 나온다.

보안 요구사항은 보안팀만의 문서도, 시스템팀만의 문서도 아니다.

시스템 엔지니어는 무엇을 보호해야 하는지 알고, 보안 엔지니어는 어떻게 보호해야 하는지 안다.

좋은 보안 요구사항은 누가 작성했는지가 아니라, 두 관점이 모두 반영되었는지로 판단한다.

핵심 요약

1

보안 요구사항은 Clause 10의 산출물이다 — TARA(Clause 9) 이후, 설계·구현 이전에 작성되며, Clause 11 V&V의 검증 대상이 된다.

2

TARA가 끝나도 요구사항은 자동으로 나오지 않는다 — Cybersecurity Goal을 구현 가능한 요구사항으로 변환하는 과정이 별도로 필요하다.

3

시스템 지식 없이는 쓸 수 없고, 보안 지식 없이도 쓸 수 없다 — 두 영역의 협업이 구조적으로 필요한 산출물이다.

4

기술 이름은 해결책이지 요구사항이 아니다 — "Secure Boot 적용"이 아니라 "소프트웨어 무결성을 검증해야 한다"가 올바른 요구사항이다.

5

OEM은 추적성·검증 가능성·구현 가능성을 본다 — Threat Scenario에서 요구사항까지 연결이 끊기지 않아야 하고, 어떻게 검증할지 방법이 있어야 한다.

SecurityRequirement ISO/SAE21434 보안요구사항 TARA Clause10 CybersecurityGoal 추적성 자동차사이버보안 시스템엔지니어 보안엔지니어