STPA보안 대책이 FTTI를 넘기면 — HARA와 TARA 사이의 빠진 칸, STPA로 메우기
01요약
02장면: 50 ms 안에 끝나야 하는 제동, 메시지마다 늘어나는 검증
전방 카메라와 레이더가 정지 차량을 봅니다. ADAS 도메인의 AEB 제어기는 충돌 위험을 판단하고, 차량 버스로 긴급 제동 요청을 보냅니다. 요청 메시지에는 SecOC의 인증 태그(CMAC)와 신선도 카운터가 붙어 있습니다. 브레이크 바이와이어 제동 ECU는 태그를 다시 계산해 요청이 진짜 AEB 제어기에서 왔는지 확인한 뒤에야 제동압을 겁니다.
Electronics Weekly 기고는 이 과정을 그대로 예로 듭니다. 브레이크·조향 바이와이어의 FTTI는 보통 10~50 ms이고, 지연은 곧 제동 거리로 바뀝니다. 제동 ECU가 AES-128 검증을 소프트웨어로 처리해 메시지당 2 ms가 걸리고 CAN 버스가 포화되면, 쌓인 지연이 FTTI 여유를 크게 줄입니다. 기고의 결론은 분명합니다. 보안 설계 때문에 제동 메시지가 FTTI를 넘기면, 그것은 ISO 26262에서 말하는 기능안전 실패입니다.
이 결론에 반대할 사람은 없습니다. 그런데 실제 프로젝트에서 이 문장은 어디에 적혀 있을까요.
03HARA 표와 TARA 표에는 시간 칸이 없다
| 묻는 것 | 묻지 않는 것 | |
|---|---|---|
| HARA (ISO 26262-3) | 위험 사건의 심각도(S)·노출도(E)·제어 가능성(C), ASIL, 안전 목표 | 안전 목표를 지키는 경로에 보안 대책이 들어갔을 때 시간이 얼마나 남는가 |
| TARA (ISO/SAE 21434) | 자산, 피해 시나리오와 영향(안전·재무·운영·프라이버시), 공격 경로와 실현 가능성 | 대책(인증·암호화)이 안전 기능의 시간 예산을 얼마나 쓰는가 |
| FTTI·안전 메커니즘 (ISO 26262-4·5) | 고장 감지·반응 시간, FTTI | 보안 대책이 같은 시간 예산을 나눠 쓴다는 사실 |
두 분석을 같은 워크숍에서 하더라도, 표의 칸이 이렇다면 이 충돌은 회의록 한 줄로 남고 맙니다. 안전팀은 "FTTI 50 ms"를 요구사항으로, 보안팀은 "인증 성공 전 실행 금지"를 요구사항으로 내고, 두 요구가 같은 50 ms 안에서 부딪친다는 사실은 통합 시험에서야 드러납니다.
한 가지 짚을 점이 있습니다. 기고는 "TARA의 영향 등급을 HARA의 ASIL에서 바로 끌어오라"고 권합니다. 그런데 ISO/SAE 21434에서 피해 시나리오의 안전 영향 등급은 ISO 26262-3의 심각도(S) 를 기준으로 정합니다. ASIL에는 노출도와 제어 가능성이 섞여 있어, 그대로 가져오면 공격이 노출도나 제어 가능성을 바꿀 수 있다는 점을 놓칩니다. 가져올 것은 ASIL이 아니라 S입니다.
04STPA는 시간을 UCA로 묻는다
STPA는 제어기가 내리는 제어행동마다 네 가지 방식으로 위험해질 수 있는지 묻습니다. 제공하지 않음, 위험할 때 제공함, 너무 이르거나 늦게 또는 순서가 틀리게 제공함, 너무 일찍 멈추거나 너무 오래 적용함. 세 번째 질문이 바로 FTTI 자리입니다.
그리고 STPA의 제어 구조에서는 인증과 버스가 제어 경로와 피드백 경로 위에 그대로 놓입니다. 인증 검증은 제동 ECU의 제어 알고리즘 안에, 버스 지연은 제어 경로 안에, 신선도 카운터 동기화는 제동 ECU의 프로세스 모델 안에 있습니다. 보안 대책이 "안전 분석 바깥의 다른 문서"가 아니라 제어 루프의 일부가 되므로, 손실 시나리오를 쓰다 보면 자연스럽게 걸립니다.
05예제: AEB 긴급 제동 요청 경로
교육용 가상 시스템입니다(특정 차량·제조사의 설계가 아닙니다). FTTI는 설명을 위한 예시값 50 ms로 두었습니다. 손실은 인명 피해와 재산 손상 두 가지, 위험원은 "안전 거리를 유지하지 못한다"(H-1)와 "필요 없는 상황에서 급제동한다"(H-2)입니다. 시스템 제약에는 이렇게 적었습니다.
HARA의 안전 목표와 TARA의 사이버보안 목표가 따로 적던 것을 한 문장에 묶은 것이 이 제약입니다.
UCA 4건
| ID | 제어행동 | 비안전 제어행동 | 위험원 |
|---|---|---|---|
| UCA-T-1 | 긴급 제동 요청 | 전방 충돌 위험이 있는데 AEB 제어기가 요청을 늦게 보내, 제동 ECU가 인증 검증을 마친 시점이 FTTI 예산을 넘는다 | H-1 |
| UCA-T-2 | 제동압 인가 | 요청이 도착했는데 제동 ECU가 인증 검증을 기다리느라 제동압 인가를 FTTI 이후에 시작한다 | H-1 |
| UCA-N-3 | 제동압 인가 | 요청이 왔는데 제동 ECU가 인증 실패로 요청을 폐기해 제동압을 인가하지 않는다 | H-1 |
| UCA-P-4 | 제동압 인가 | 충돌 위험이 없는데 제동 ECU가 위조·재전송된 요청을 받아들여 제동압을 인가한다 | H-2 |
UCA-P-4는 TARA라면 위협 시나리오로 적었을 내용입니다. STPA에서는 같은 표 안에서 UCA-T-2와 나란히 놓입니다. 인증을 느슨하게 하면 T-2가 줄고 P-4가 늘어나고, 엄격하게 하면 반대가 됩니다. 이 균형이 한 화면에 보인다는 것이 이 글의 요점입니다.
손실 시나리오 5건
| ID | UCA | 시나리오 요지 | 무엇이 보이나 |
|---|---|---|---|
| LS-1 | T-2 | 인증 검증을 소프트웨어로 해 메시지당 약 2 ms, 버스 포화로 큐 대기·재전송이 겹쳐 누적 지연이 FTTI를 넘음. 검증 시간은 평상시 부하에서만 측정됨 | 기고의 사례 그대로. 대책은 최악 조건 측정과 HSM |
| LS-2 | T-2 | 제동 ECU 알고리즘이 "인증 전 제동 금지"만 정의하고, 검증이 FTTI 안에 끝나지 않을 때의 동작은 정의하지 않음. 두 요구가 HARA·TARA 문서에 따로 있어 충돌이 드러나지 않음 | 빠진 칸 그 자체 |
| LS-3 | T-1 | 카메라·레이더 정보도 같은 버스로 인증되어 오는데, 버스 과부하가 물체 정보와 제동 요청을 함께 지연시킴 | 공통 원인. 지난 글의 조합 원형과 같은 구조 |
| LS-4 | N-3 | 제동 ECU 리셋 뒤 신선도 카운터가 어긋나 정상 요청이 재전송 공격으로 판정되어 폐기됨. "인증 실패" 피드백이 없어 AEB 제어기는 제동이 걸린 줄 앎 | 보안 대책이 만든 은폐 |
| LS-5 | P-4 | 인포테인먼트 도메인이 침해되고 게이트웨이가 제동 요청 ID를 걸러내지 않음. 지연을 줄이려고 신선도 카운터 허용 창을 넓혀 두어 재전송 요청이 통과함 | 시간을 아끼려던 설정이 보안 구멍이 됨 |
다섯 건을 나란히 놓으면 방향이 서로 반대인 시나리오가 섞여 있습니다. LS-1·LS-2는 보안 대책이 너무 느려서, LS-5는 너무 빠르게 하려다 생깁니다. LS-4는 보안 대책이 정상 요청을 막고 그 사실을 숨깁니다. 안전과 보안을 따로 분석하면 앞의 셋은 안전팀 문서에, LS-5는 보안팀 문서에, LS-4는 어느 쪽에도 없을 가능성이 큽니다.
대응방안 6건
| ID | 대응방안 | 연결 시나리오 |
|---|---|---|
| CM-1 | 인증 검증을 HSM 암호 가속기로 넘기고, 검증 시간을 버스 포화를 포함한 최악 조건에서 측정해 지연 예산표에 기록 | LS-1 |
| CM-2 | 감지 → 판단 → 인증 생성 → 전송 → 검증 → 작동 단계별 지연 상한을 FTTI 안에 할당해 요구사항으로 명시 | LS-1, LS-3 |
| CM-3 | 검증이 예산 안에 끝나지 않거나 인증에 실패했을 때의 동작을 안전 개념에 정의(예: 운전자 경고, 저하 모드). 어떤 동작이 안전 측인지는 HARA와 TARA 결과를 함께 보고 정함 | LS-2, LS-4 |
| CM-4 | "인증 실패·요청 폐기" 상태를 AEB 제어기에 피드백하고 신선도 카운터 재동기화 절차 정의 | LS-4 |
| CM-5 | 안전 필수 메시지의 버스 우선순위·대역(CAN FD, 차량 이더넷) 확보, 지터 시뮬레이션 | LS-3 |
| CM-6 | 게이트웨이 도메인 간 필터링, HSM 키를 응용 코어에서 분리, 신선도 허용 창은 지연 예산과 함께 결정 | LS-5 |
CM-3에는 조심할 점이 있습니다. "검증이 늦으면 일단 제동한다"는 선택은 LS-1을 막지만 LS-5를 다시 엽니다. 이 결정은 안전팀이나 보안팀 한쪽이 내릴 수 없고, 그래서 두 분석이 같은 모델 위에 있어야 합니다.
06지연 예산표 — SC-2를 숫자로 바꾸기
시스템 제약 SC-2는 결국 아래 같은 표가 되어야 검증할 수 있습니다. 숫자는 설명을 위한 예시입니다.
| 단계 | 예시 상한 | 책임 | 근거 |
|---|---|---|---|
| 물체 감지·인식 | 15 ms | ADAS | 센서 주기·처리 시간 측정 |
| 충돌 판단·요청 생성 | 10 ms | ADAS | 알고리즘 최악 실행 시간 |
| 인증 태그 생성 | 1 ms | 보안 | HSM 측정값 |
| 버스 전송(최악) | 5 ms | 아키텍처 | 버스 부하·우선순위 분석, 지터 시뮬레이션 |
| 인증 검증 | 1 ms (HSM) / 2 ms 이상 (소프트웨어) | 보안 | 최악 조건 측정 |
| 제동압 형성 | 15 ms | 섀시 | 작동기 응답 시험 |
| 합계 | 47 ms ≤ FTTI 50 ms | 안전 | 예산표 승인 |
이 표의 칸 하나하나가 STPA의 제어 경로·피드백 경로 요소와 대응합니다. 손실 시나리오가 "어느 칸이 넘칠 수 있는가"를 묻고, 대응방안이 "그 칸의 상한을 누가 증명하는가"를 정합니다.
07내일 확인할 것
기능안전 담당
- 안전 목표의 FTTI 예산표에 보안 대책(인증 생성·검증)이 별도 줄로 들어가 있는가?
- 인증 검증 시간이 평상시 부하가 아니라 최악 조건에서 측정되었는가?
사이버보안 담당
- TARA 피해 시나리오의 안전 영향 등급을 HARA의 ASIL이 아니라 심각도(S)에서 가져왔는가?
- 신선도 카운터 허용 창, 인증 실패 시 동작을 정할 때 안전팀과 함께 결정했는가?
아키텍트
- 인증 실패·요청 폐기 상태가 요청을 보낸 제어기에 피드백되는가?
- 안전 필수 메시지가 암호화된 낮은 우선순위 트래픽에 밀리지 않는지 지터 시뮬레이션으로 확인했는가?
08마무리
VisualPro는 HARA·TARA·STPA를 한 프로젝트 안에서 수행할 수 있습니다. 이 글의 STPA 예제는 VisualPro STPA에서 작성했습니다.
09자주 묻는 질문
Q1HARA와 TARA를 같이 하면 되는 것 아닌가요? 왜 STPA까지 필요합니까?
Q2HSM을 쓰면 문제가 해결되지 않나요?
Q3인증 검증이 늦으면 그냥 제동하면 되지 않나요?
Q4TARA 영향 등급을 HARA에서 가져오는 정확한 방법은?
Q5우리 회사는 STPA를 써 본 적이 없습니다. 어디서부터 시작하면 됩니까?
· Electronics Weekly, "Linking functional safety with cybersecurity in the automotive industry", 2026.10.13 (Diego de Azcuénaga) — 기사 보기
· ISO 26262-1:2018 FTTI 정의, ISO 26262-3:2018 HARA
· ISO/SAE 21434:2021 — 피해 시나리오 영향 등급(안전 영향은 ISO 26262-3 심각도 기준)
· AUTOSAR Specification of Secure Onboard Communication (SecOC)
· Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT, 2018 — STPA Handbook 원문(PDF) / MIT PSASS STAMP Tools