차량의 제어기는 받은 메시지가 이상하면 그 메시지에 기대는 기능을 끄거나 성능을 낮추고, 계기판에 경고를 띄웁니다. ISO 26262는 이렇게 고장이 났을 때 불합리한 위험 없이 머물 수 있는 동작 모드를 안전 상태(safe state)라고 부릅니다. 고장이 의도 없이 일어난다는 전제에서 이것은 합리적인 대응입니다. 그런데 누군가 그 고장 조건을 원하는 때에 원하는 만큼 만들어 낼 수 있다면 어떨까요? 안전을 지키려고 만든 반응이 공격자가 마음대로 켜고 끄는 서비스 거부(DoS) 스위치가 됩니다.
반대 방향의 충돌도 있습니다. IT 보안에서는 공격을 탐지하면 접근을 끊고 시스템을 리셋하거나 멈추는 것이 익숙한 대응입니다. 하지만 달리는 차에서 제어기를 갑자기 리셋하면, 그 대응 자체가 위험원이 될 수 있습니다.
기능안전과 사이버보안, 이제는 ‘함께’ 봐야 한다에서 몇 줄로 짚고 넘어갔던 이 문제를 이번에는 설계 수준에서 들여다봅니다. 안전 메커니즘이 왜 공격 도구가 되는지, 실제로 어떤 일이 있었는지, 고장과 공격을 어떻게 나눠 기록할지, 보안 대응을 안전과 어떻게 맞출지, 두 대응을 같은 시간 예산 안에 넣는 방법과 충돌을 미리 정해 두는 규칙까지 차례로 정리합니다. 여러분 조직의 오류 처리 전략은 보안 엔지니어의 검토를 거쳤습니까?
1. 안전 메커니즘은 고장을 가정하고, 공격자는 그 가정을 이용한다
기능안전의 오류 처리는 고장이 의도 없이 생긴다는 전제 위에 서 있습니다. 기능안전이 무작위 하드웨어 고장만 보는 것은 아닙니다. 설계와 소프트웨어의 체계적 결함, 여러 요소를 한꺼번에 무너뜨리는 공통 원인 고장까지 분석합니다. 하지만 어느 경우든 누군가 그 고장 조건을 일부러, 원하는 때에, 원하는 만큼 만들어 낸다고 가정하지는 않습니다. 오류를 탐지했을 때의 반응도 이 전제에 맞춰 정합니다. 대표적인 반응은 세 가지입니다.
- 기능 비활성화: 고장 난 기능을 꺼서 안전 상태를 유지합니다.
- 정적 복구: 적극적인 개입 없이 시스템을 미리 정한 안전 상태로 되돌립니다.
- 점진적 성능 저하(graceful degradation): 핵심 기능은 지키고 나머지 기능의 성능을 단계적으로 낮춥니다.
공격자는 이 전제를 따르지 않습니다. 기능안전에서 분석한 바로 그 고장 조건을 의도적으로 만들어 내고, 언제 일으킬지 고르고, 몇 번이든 되풀이합니다. 게다가 안전 반응은 결정적(deterministic)입니다. 어떤 조건에서 기능이 꺼지고 어떤 조건에서 돌아오는지가 설계로 정해져 있고, CAN의 오류 격리 규칙처럼 공개된 표준에 적혀 있는 경우도 많습니다. 예측할 수 있는 반응은 공격자가 다루기 쉬운 대상입니다.
결론은 단순합니다. 안전 메커니즘의 탐지 조건과 반응은 그 자체로 공격 표면이 될 수 있습니다. 안전 메커니즘이 잘못 만들어졌다는 뜻은 아닙니다. 우발적 고장에 대해서는 여전히 꼭 필요한 장치입니다. 다만 안전 분석은 악의 없는 고장을 전제로 하므로, 그 반응을 누군가 일부러 일으키는 경우는 보안 분석이 맡아야 합니다. 안전 메커니즘의 종류와 적용은 ISO 26262 기반 안전 메커니즘 개요 및 실무 적용 가이드에서 정리했습니다.
2. 실제 사례: CAN 오류 격리로 멀쩡한 ECU를 떼어 내다
이 구조가 실제 공격으로 이어진 대표 사례가 CAN의 오류 격리(fault confinement)입니다. CAN 노드는 송신 오류 카운터와 수신 오류 카운터를 두고, 송신 오류가 나면 송신 오류 카운터를 8씩 올리고 송신에 성공하면 1씩 내립니다. 어느 카운터든 127을 넘으면 오류를 알릴 때 다른 노드의 프레임을 깨뜨리지 않는 수동 오류 플래그만 보내는 오류 수동(error passive) 상태가 되고, 송신 오류 카운터가 255를 넘으면 버스 오프(bus-off) 상태가 되어 복구 절차를 거치기 전까지 버스에서 빠집니다. 고장 난 노드 하나가 계속 오류를 내며 버스 전체를 마비시키지 못하게 하려는, 견고성을 위한 장치입니다.
2016년 미시간 대학교의 Cho와 Shin은 이 장치를 공격에 쓰는 버스 오프 공격을 발표했습니다(ACM CCS 2016). 공격자는 표적 ECU와 같은 ID의 메시지를 같은 시점에 보내되 한 비트를 다르게 만들어 표적의 송신에 비트 오류를 일으킵니다. 표적은 자신이 오류를 냈다고 판단해 송신 오류 카운터를 올리고, CAN 컨트롤러의 자동 재전송 때문에 같은 충돌이 곧바로 되풀이되어 공격 메시지 한 번만으로 오류 수동 상태가 됩니다. 그 뒤로는 표적 메시지가 주기적으로 나갈 때마다 공격자가 다시 끼어들어 카운터를 계속 올리고, 결국 멀쩡한 ECU가 고장 난 노드로 몰려 버스 오프 상태가 됩니다. 연구진은 실제 차량에서 기록한 CAN 트래픽을 분석해 공격 조건이 현실적임을 보이고, CAN 시험 환경에서 공격을 시연했습니다. 연구진이 짚은 특징 가운데 두 가지가 이 글의 주제와 직접 맞닿아 있습니다.
- 메시지 보호로는 막지 못합니다. 공격은 메시지 수신이 끝나기 전에 비트 오류를 일으키므로, 메시지에 붙인 체크섬이나 MAC은 검사될 기회조차 얻지 못합니다.
- 고장처럼 보입니다. 증상이 버스 종단 불량, 비트 반전 같은 시스템 오류와 비슷해, 침입 탐지 시스템이 공격이 아니라 네트워크 오류로 판단할 수 있다고 연구진은 지적했습니다.
연구진이 내놓은 대책도 오류 격리를 걷어 내는 것이 아니라, 고장과 공격을 가르는 증거를 찾는 것이었습니다. 연속된 오류 프레임만으로는 심한 배선 문제 같은 시스템 오류와 구분할 수 없습니다. 그래서 오류 수동 상태의 표적이 송신 오류를 겪는 바로 그때 같은 ID의 메시지가 다른 누군가에 의해 정상 송신되는지를 봅니다. CAN에서는 두 노드가 같은 ID의 메시지를 동시에 보내는 것이 허용되지 않으므로, 고장만으로는 일어나기 어려운 현상입니다. 이 증거가 연속 오류 뒤에 확인되면 ECU나 오류 카운터를 초기화해 표적이 버스에서 밀려나지 않게 합니다.
2017년에는 밀라노 공과대학교와 보안 업계 연구진(Palanca 외)이 완전한 프레임을 보내지 않고 비트 수준에서 오류를 일으켜 특정 ECU만 골라 끊는 공격을 발표했습니다(DIMVA 2017). 연구진은 이 공격이 프레임 단위 분석으로는 탐지되지 않는다고 설명했고, 개조하지 않은 실제 차량에서 개념 증명을 보였습니다. 미국 ICS-CERT(지금의 CISA)는 CAN 프로토콜의 약점을 이용한 서비스 거부 공격이라며 경보를 냈습니다.
두 연구가 보여 주는 것은 특정 제품의 결함이 아니라 설계 원리의 충돌입니다. 고장을 견디려고 넣은 규칙이 결정적이고 공개되어 있으면, 공격자는 그 규칙을 거꾸로 씁니다.
3. 안전 반응을 반복해서 일으키는 공격
버스 오프 공격은 프로토콜 계층의 이야기지만, 같은 구조는 애플리케이션의 오류 처리에서도 생깁니다. 다음과 같이 설계된 수신 ECU를 생각해 보겠습니다.
- 같은 카운터 값을 가진 메시지가 다섯 번 연속으로 들어오면 ‘오래된 메시지’ 오류를 보고하고, 그 메시지에 기대는 안전 기능을 끕니다.
- 새 메시지를 일정 개수 이상 정상적으로 받으면 기능을 다시 켭니다.
고장만 생각하면 합리적인 설계입니다. 그런데 네트워크에 접근한 공격자가 예전에 관찰한 메시지를 주기적으로 다시 보내면, 기능은 꺼졌다가 복구되고 다시 꺼지기를 되풀이합니다. 적어도 계기판에 경고가 반복해서 뜨고, 운전자는 차를 정비소에 맡기게 됩니다. 정비소에서는 고장이 재현되지 않거나 멀쩡한 부품을 바꾸기 쉽고, 그 비용은 보증 비용으로 제조사에 돌아올 수 있습니다. 안전 개념상 기능이 꺼진 상태는 위험하지 않도록 설계했더라도, 기능이 수시로 꺼졌다 켜지는 상황까지 가정했는지는 따로 확인해야 합니다.
안전 설정값이 공격 조건이 된다
AUTOSAR의 종단 간(E2E) 보호를 쓰는 경우를 보겠습니다. 수신 측 E2E 상태 기계는 정해진 창(window) 안에서 유효한 메시지가 기준보다 적거나 오류가 기준보다 많으면 통신 채널을 무효(INVALID)로 판정합니다. 무효 상태에서는 무효 상태용 창 안에서 유효한 메시지가 기준 이상이고 오류가 기준 이하여야 다시 유효(VALID)로 돌아옵니다. AUTOSAR E2E 명세는 이 창 크기와 기준값을 FTTI를 지킬 수 있도록 고르라고 안내합니다.
안전 엔지니어에게 이 값은 고장을 제때 잡아내기 위한 설정입니다. 공격자에게는 기능을 끄려면 몇 주기 동안 방해해야 하고, 손을 떼면 몇 주기 뒤에 기능이 돌아오는지를 알려 주는 값이기도 합니다. 그래서 오류 처리 파라미터를 정할 때 “이 조건을 누군가 일부러 반복해서 만들면 어떻게 되는가”를 함께 물어야 합니다.
메시지 인증을 넣으면 달라지는 것과 그대로인 것
메시지에 MAC과 신선도 값(freshness value)을 붙이면 이 예의 단순한 재전송은 상당 부분 걸러집니다. AUTOSAR SecOC는 기본 설정에서 인증 검증에 실패하거나 신선도 값을 확인하지 못한 메시지를 상위 계층에 넘기지 않고 버립니다(검증 결과를 무시하거나 상태를 재정의하도록 설정하면 통과시킬 수도 있습니다). 정상 송신자의 메시지가 제때 도착해 검증까지 마치는 한, 수신 측 E2E 검사에는 SecOC 인증을 통과한 메시지가 전달됩니다. 다만 인증 통과는 정당한 키를 가진 송신자가 보냈고 전송 중에 바뀌지 않았다는 뜻일 뿐, 내용이 기능적으로 올바르다는 보장은 아닙니다. 송신 ECU 자체의 결함이나 침해로 잘못된 값이 정상적으로 인증되어 오는 경우는 수신 측의 타당성 검사 같은 안전 메커니즘으로 따로 다뤄야 합니다. 그리고 다음 세 가지는 그대로이거나 새로 생깁니다.
- 정상 메시지를 못 오게 만들면 결과는 같습니다. 앞의 버스 오프 공격이나 버스 플러딩으로 정상 송신자의 메시지를 막으면, 수신 측은 ‘메시지 없음’을 보고 같은 안전 반응을 합니다. MAC은 무결성과 진정성을 지킬 뿐 가용성을 만들어 주지는 않습니다. 정상 메시지에 바짝 붙여 같은 ID의 위조 메시지를 보내 수신 버퍼에서 정상 메시지를 밀어내는 방법도 있습니다. SecOC는 받은 메시지를 다음 주기 함수 호출 때 검증하는데, 그 사이에 같은 메시지가 또 들어오면 수신 넘침 전략에 따라 먼저 온 것(REPLACE)이나 나중에 온 것(REJECT)을 버립니다. 이 설정과 수신 버퍼 구성도 함께 검토해야 합니다.
- 인증 실패를 안전 쪽 오류로 세면 공격이 쉬워집니다. 검증에 실패한 메시지 하나하나를 안전 상태 판정의 오류로 세도록 설계하면, 공격자는 키 없이 틀린 MAC을 단 메시지를 뿌리는 것만으로 기능을 끌 수 있습니다. 안전 판정은 “유효한 메시지가 기한 안에 들어오는가”를 기준으로 하고, 검증 실패는 다음 절처럼 보안 이벤트로 따로 모아 판단하는 설계를 검토할 만합니다. SecOC가 검증 결과를 상위로 알리는 범위(모두, 실패만, 알리지 않음)를 설정으로 고를 수 있는 것도 이 선택과 이어집니다. 다만 맞바꾸는 것이 있습니다. 검증 실패 알림을 안전 판정에 쓰면 탐지는 빨라지지만 키 없는 DoS에 열리고, 쓰지 않으면 손상되어 버려진 메시지도 ‘메시지 없음’으로만 잡혀 탐지가 그만큼 늦어집니다. 그 탐지 시간이 FTTI 안에 드는지 확인해야 합니다(6절).
- 보안 메커니즘이 안전 메커니즘이 됩니다. MAC 검증으로 CRC를 대신해 안전 메시지의 손상까지 탐지하려면, 그 검증 경로는 ISO 26262와 ISO/SAE 21434를 모두 적용받고, 대체가 성립하는지도 따로 입증해야 합니다. 먼저 보호 구간이 다릅니다. SecOC는 송신 측과 수신 측 SecOC 모듈 사이의 PDU를 보호하므로, 애플리케이션 사이를 덮는 E2E와 범위가 같지 않습니다. 오류 검출 특성도 CRC와 다르므로, 태그 길이만으로 대체 가능성을 판단할 수는 없습니다. 보호 구간과 가정한 고장 모델에 따라 미검출 위험을 따로 평가해야 합니다. 구현의 안전성도 필요합니다. 암호 엔진의 고장으로 검증 결과가 틀어질 수 있는지 안전 분석을 해야 하고, 그 결과로 바꾼 설계가 새 취약점을 만들지 않는지 보안 쪽에서 다시 봐야 합니다(7절의 예).
4. 고장으로만 기록하면 공격은 보이지 않는다
반복 유발 공격을 기술적으로 완전히 막기 어려운 경우도 있습니다. 그렇더라도 지켜야 할 선이 있습니다. 공격을 평범한 고장으로 기록하고 끝내지 않는 것입니다.
안전 메커니즘이 잡은 이상이 진단 고장 코드(DTC)로만 남으면, 정비 현장에서는 통신 오류로 보고 배선이나 부품을 점검합니다. 원인을 찾지 못한 채 같은 증상이 되풀이되고, 공격자가 차량에 들어온 경로는 그대로 남습니다. 여러 차량에서 같은 증상이 동시에 나타나도 각각 개별 고장으로 처리되면 그 연결을 알아채기 어렵습니다.
그래서 안전 쪽 감시 장치가 잡는 이상 가운데 공격의 단서가 될 만한 것은 보안 이벤트로도 보내야 합니다. AUTOSAR Classic Platform에서는 침입 탐지 시스템 관리자(IdsM)가 이 역할을 맡습니다. 기본 소프트웨어 모듈과 애플리케이션의 보안 센서가 보안 이벤트를 보고하면, IdsM은 설정한 규칙(집계, 문턱값, 빈도 제한 등)으로 걸러 ‘자격을 갖춘 보안 이벤트’로 바꾸고, 진단 이벤트 관리자(Dem)의 보안 이벤트 메모리에 저장해 ECU에 남기거나 IDS 리포터(IdsR)로 넘깁니다. IdsR은 이를 백엔드 보안 운영 센터(SOC)로 전달할 수 있습니다. SecOC 명세도 MAC 검증 실패와 신선도 값 획득 실패를 표준 보안 이벤트로 정의해 두었습니다(R24-11 기준 초안 상태). 같은 이상을 고장 기록과 보안 기록 양쪽에 남길 수 있는 구조입니다.
어떤 이상을 보안 센서로 삼을지는 TARA와 안전 분석을 함께 보고 정합니다. 예를 들면 다음과 같은 것이 단서가 됩니다.
- 같은 메시지의 카운터 반복이나 순서 오류가 일정한 주기로 되풀이됨
- 오류가 특정 메시지 ID나 특정 송신 노드에 몰림
- 같은 버스의 다른 노드는 멀쩡한데 한 노드만 오류 수동이나 버스 오프를 되풀이함
- 기능이 복구된 직후 같은 오류가 다시 시작됨
- 여러 차량에서 같은 시기에 같은 증상이 나타남(백엔드에서만 보임)
어느 하나만으로 공격이라고 단정할 수는 없습니다. 2절의 연구처럼 고장만으로는 일어나기 어려운 현상을 찾아 증거를 좁혀 가야 합니다. 그래도 이런 기록이 남아 있어야 보안 운영 센터가 패턴을 보고 취약점 분석을 시작할 수 있습니다. TARA를 실무에서 어떻게 돌리는지는 TARA, 형식적 절차를 넘어 실질적 보안 성과를 만드는 법에서 다뤘습니다.
5. 보안 대응이 안전을 해칠 때
이제 방향을 바꿔 보겠습니다. 공격을 탐지했을 때 IT 보안의 기본 대응은 자산 접근을 즉시 끊고, 피해가 번지지 않게 시스템을 리셋하거나 멈추는 것입니다. 서버라면 합리적입니다. 하지만 주행 중인 차량의 제어기에서 같은 대응을 하면 안전 기능이 갑자기 끊길 수 있습니다. 기능을 끄는 것만으로는 안전 상태가 되지 않아 고장 뒤에도 일정 시간 동작을 이어 가야 하는 시스템(ISO 26262의 비상 운전(emergency operation) 개념)이라면 더욱 그렇습니다.
그래서 보안 팀은 안전 팀과 함께 허용 가능한 보안 상태를 정해야 합니다. 자산은 지키되, 시스템이 단계적으로 기능을 낮추고 다시 돌아올 수 있는 상태입니다. 좋은 출발점은 보안 대응이 안전 개념이 이미 다루는 고장 형태로 나타나게 하는 것입니다. 예를 들어 공격을 탐지했을 때 시스템 전체를 멈추는 대신 암호 키 접근을 막으면, 시스템은 계속 동작하지만 인증이 필요한 메시지를 더 이상 처리할 수 없습니다. 상대 ECU 입장에서는 통신 두절과 비슷한 상황이 되고, 안전 개념에 이미 있는 통신 두절 대응(경고와 기능 저하)이 작동합니다. 이미 검증된 반응 경로를 다시 쓰므로 분석과 검증의 부담이 줄어듭니다. 다만 한 번의 대응으로 여러 메시지가 동시에 끊기는 경우와, 오탐으로 대응이 걸리는 빈도는 안전 분석에 새로 반영해야 합니다.
메시지를 차단하는 침입 방지는 특히 조심해야 합니다. IT 환경에서는 연결을 막는 오탐이 어느 정도 용인되지만, 차량에서 안전 관련 메시지를 잘못 거부하면 그 기능의 가용성이 흔들립니다. 라우팅 표나 허용 ID 목록 같은 결정적 규칙도 오탐에서 자유롭지는 않습니다. 같은 입력에 늘 같은 판단을 내릴 뿐이어서, 목록이 잘못되었거나 특정 운전 모드의 정상 통신을 빠뜨렸다면 정상 메시지를 매번 막습니다. 그래서 판단 기준을 하나로 두는 것이 좋습니다. 안전 필수 트래픽을 막는 차단은 오탐과 미탐 각각의 안전 영향, 처리 지연, 차단했을 때의 대체 동작을 검증한 경우에만 적용하고, 이 조건을 채우지 못한 판단은 탐지와 기록에만 씁니다. 심층 패킷 검사처럼 오탐을 충분히 줄이기 어려운 기법은 대개 탐지와 기록 쪽에 둡니다.
주요 보안 대응을 안전 관점에서 검토하면 다음과 같습니다. 프로젝트의 안전 개념에 따라 결론은 달라질 수 있으니 출발점으로만 참고하시기 바랍니다.
| 보안 대응 | 주행 중 안전에 주는 영향 | 검토 방향 |
|---|---|---|
| 제어기 즉시 리셋, 정지 | 재시작하는 동안 기능 상실, 재시작 시간이 FTTI를 넘을 수 있음 | 주행 중에는 기능 저하 모드로 버티고 리셋은 정차 뒤로 미룸 |
| 의심 메시지 차단(침입 방지) | 오탐이면 정상 안전 메시지가 사라짐 | 안전 필수 트래픽의 차단은 오탐과 미탐의 안전 영향, 처리 지연, 대체 동작을 검증한 규칙에만 쓰고, 나머지 판단은 탐지와 기록으로 |
| 암호 키 접근 차단 | 인증 메시지가 끊겨 통신 두절처럼 보임 | 안전 개념의 통신 두절 대응으로 이어지는지 확인 |
| 진단, 프로그래밍 세션 잠금 | 주행 기능에 주는 영향이 작음 | 주행 중에도 적용할 수 있는 후보 |
| 보안 이벤트 기록과 보고 | 자원 사용 외에는 영향이 작음 | 기본 대응으로 둠 |
차량 상태에 따라 대응 수위를 달리하는 것도 방법입니다. 주행 중에는 기능을 지키는 쪽으로 대응하고, 정차나 주차 상태에서는 진단 접근을 막거나 소프트웨어 무결성을 다시 확인하는 식으로 더 강하게 대응합니다. 진단 접근을 잠그는 방법은 진단 서비스가 해킹 통로가 될 때: UDS 0x27에서 0x29로에서 다뤘습니다. 어떤 경우든 그 대응이 어떤 고장 형태로 나타나는지, 안전 개념이 그것을 이미 다루는지를 안전 팀과 함께 확인해야 합니다.
6. 같은 시간 예산 안에서: FTTI와 보안 처리 시간
안전과 보안의 대응을 맞출 때 놓치기 쉬운 것이 시간입니다. ISO 26262는 고장 처리에 걸리는 시간을 다음 지표로 다룹니다.
- FTTI(고장 허용 시간 간격): 고장이 생긴 뒤 안전 메커니즘이 작동하지 않으면 위험한 사건이 일어날 수 있기까지의 최소 시간
- FDTI(고장 탐지 시간 간격): 고장이 생긴 뒤 탐지되기까지의 시간
- FRTI(고장 반응 시간 간격): 탐지한 뒤 안전 상태나 비상 운전에 이르기까지의 시간
- FHTI(고장 처리 시간 간격): FDTI와 FRTI의 합으로, FTTI를 넘지 않아야 합니다.
여기서 시간의 출발점은 공격을 시작한 때가 아니라 안전 관련 고장이 생긴 때입니다. 공격이 그 고장을 일으킨 경우도 마찬가지입니다. 침입을 조사하고 막는 보안 대응 전체가 FTTI에 묶이는 것은 아닙니다. 보안 처리가 그 안전 경로의 탐지나 반응에 끼어들 때, 그 지연이 이 예산에서 나갑니다. 예를 들어 MAC 검증으로 안전 메시지의 손상을 탐지한다면, 암호 기능은 FHTI 안에 무결성 판정 결과를 내서 애플리케이션이 손상된 값을 처리할 시간을 남겨야 합니다. 따져 볼 항목은 다음과 같습니다.
- MAC 검증 시간: SecOC 주기 함수 호출을 기다리는 시간과 HSM이나 암호 가속기에서 다른 암호 작업 뒤에 기다리는 시간까지 포함합니다. 공격자가 검증할 메시지를 쏟아부어 암호 자원을 바쁘게 만들 때의 최악 시간도 봐야 합니다.
- 신선도 값 재시도: 신선도 값이 어긋날 때 다른 후보 값으로 검증을 다시 시도하도록 설정하면 그만큼 시간이 늘어납니다.
- 버린 메시지를 알아채는 시간: SecOC가 검증에 실패한 메시지를 버리면, 상위 안전 계층은 그 사실을 메시지 부재로만 알게 될 수 있습니다. E2E 검사를 주기적으로 호출하는 구성이라면 창 안에서 유효한 메시지가 기준보다 적어질 때까지 기다린 뒤에 무효로 판정하고, 메시지를 받을 때만 검사하는 구성이라면 별도의 수신 기한 감시가 있어야 부재를 잡습니다. 검증 결과를 알리는 설정과 E2E 창 크기, 검사 주기를 함께 정해야 하는 이유입니다.
- 보안 대응이 만든 고장을 처리하는 시간: 키 접근 차단으로 생긴 통신 두절도 안전 관점에서는 하나의 고장입니다. 차단한 시점부터 상대 ECU가 이를 탐지하고 안전 반응에 이르기까지가 FTTI 안에 들어야 합니다.
반대로 IdsM의 집계나 문턱값처럼 여러 이벤트를 일부러 모은 뒤 판단하는 보안 경로는 안전 반응의 경로 밖에 둡니다. 안전 반응이 보안 판단을 기다리지 않도록 경로를 나누는 것이 바람직합니다.
7. 충돌은 미리 정해 둔다: 우선순위 규칙과 교차 검토
안전과 보안은 다루는 범위도, 위험을 평가하는 방식도 다르니 개발 중 여러 지점에서 부딪치는 것이 자연스럽습니다. 문제는 충돌 자체가 아니라, 충돌이 생겼을 때 무엇을 기준으로 정할지가 없는 것입니다. 일정에 쫓기는 프로젝트에서 안전 활동이나 보안 활동을 멈추고 충돌을 풀기는 어렵습니다. 두 팀의 프로세스가 맞물려 있지 않으면 충돌은 게이트 심사에 가서야 드러나 재작업으로 이어지기 쉽습니다.
그래서 조직 차원의 충돌 해결 규칙을 미리 정해 둡니다. 예를 들면 다음과 같습니다.
- 보안 요구사항이나 설계가 안전 목표를 해치면, 안전 목표를 우선하고 보안 쪽을 고칩니다.
- 재무적 손실을 다루는 보안 요구사항이 인명 피해를 다루는 안전 요구사항과 부딪치면, 안전 요구사항을 우선합니다.
- 고장 분석을 위해 보안상 민감한 정보(암호 키, 개인정보 등)를 기록하라는 안전 요구사항이 있으면, 원문 값 대신 식별자나 요약 정보를 남기거나 기록에 접근 통제를 거는 방법을 먼저 찾습니다. 그래도 노출 위험이 남는 원문 기록은 금지하는 보안 요구사항을 우선합니다.
세 번째 규칙이 보여 주듯 “언제나 안전 우선”은 아닙니다. 그렇다고 필요한 안전 증거까지 없애자는 뜻은 아닙니다. 고장 분석에 필요한 증거는 남기되, 민감한 정보가 드러나는 범위를 줄이는 쪽으로 푸는 것이 핵심입니다. 규칙은 조직이 경험을 쌓으며 계속 다듬어 갑니다.
규칙만큼 중요한 것은 충돌을 드러내는 절차입니다.
- 오류 처리 전략의 교차 검토: 안전 쪽 오류 처리 전략(탐지 조건, 반응, 복구 조건)은 보안 엔지니어가, 보안 쪽 대응 정책은 안전 엔지니어가 검토합니다. 이 글에서 본 충돌의 상당수는 이 검토에서 드러날 수 있습니다.
- 요구사항의 추적 연결: 안전 요구사항과 보안 요구사항을 같은 요구사항 관리 체계에 두고 서로 추적해 두면, 하위 요구사항으로 세분화하기 전 교차 검토에서 충돌과 중복을 찾기 쉬워집니다.
- 고친 설계를 다시 검토: 안전을 위해 고친 설계가 새 취약점을 만들 수 있습니다. 예를 들어 MAC 검증 결과를 안전 애플리케이션이 직접 다시 확인하도록 수신한 MAC과 함께 기대 MAC 값까지 넘기면, 안전 관점에서는 탄탄해 보입니다. 문제는 MAC 알고리즘이 약해지는 데 있지 않습니다. 검증 인터페이스가 공격자가 고른 입력에 대한 올바른 MAC을 계산해 주는 도구가 된다는 데 있습니다. 수신 애플리케이션에 접근한 공격자는 원하는 내용을 단 메시지를 틀린 MAC과 함께 넣어 기대 MAC 값을 받아 낼 수 있고, 그 메시지가 신선도 값 같은 다른 수신 조건까지 충족하면 인증을 통과할 수 있습니다. 그래서 먼저 기대 MAC 값을 공격자가 닿을 수 있는 경계 밖으로 내보내지 않는 설계를 찾습니다. 비교는 HSM이나 SecOC처럼 보호된 쪽에서 끝내고 안전 애플리케이션에는 검증 결과만 넘기며, 검증이 잘못될 가능성은 암호 엔진의 기지값 시험(KAT) 같은 자체 시험 등으로 따로 다루는 식입니다. 신선도 값 제약은 그다음의 보완 대책입니다. 신선도 값이 카운터인지 타임스탬프인지, 수신 측이 어떤 범위의 값을 받아들이는지를 먼저 분명히 하고, 그 범위 밖의 값에는 기대 MAC 값을 계산해 주지 않도록 제약을 더합니다. 교차 검토는 한 번으로 끝나지 않습니다.
표준도 이런 소통을 요구합니다. ISO 26262-2:2018은 안전 문화 요구의 하나로 사이버보안처럼 기능안전과 관련된 분야와 효과적인 소통 채널을 갖추도록 요구하고, 두 분야의 접점을 정리한 참고용 부속서를 두고 있습니다.
8. 마무리: 오류 처리 전략 점검 질문
안전 메커니즘은 고장으로부터 차를 지키지만, 공격자에게는 결정적이고 예측할 수 있는 스위치가 될 수 있습니다. 반대로 IT식 보안 대응은 차 안에서 그 자체로 위험원이 될 수 있습니다. 두 분야를 각자 완성한 뒤 맞춰 보는 방식으로는 이 틈이 메워지기 어렵습니다. 오류 처리 전략을 정하는 그 자리에서 두 팀이 함께 물어야 합니다. 다음 질문으로 지금의 설계를 점검해 보시기 바랍니다.
- 안전 쪽 오류 처리 전략(탐지 조건, 반응, 복구 조건)을 보안 엔지니어가 검토했습니까?
- 공격자가 그 탐지 조건을 일부러 반복해서 만들면 어떻게 되는지 TARA에서 따져 봤습니까?
- 메시지 인증 실패를 안전 쪽 오류로 세고 있지는 않습니까? 그렇다면 키 없이도 기능을 끌 수 있지 않습니까?
- 안전 감시 장치가 잡은 이상 가운데 공격의 단서가 될 만한 것을 보안 이벤트로도 보내고 있습니까?
- 공격을 탐지했을 때의 보안 대응이 어떤 고장 형태로 나타나는지, 안전 개념이 그것을 이미 다루는지 확인했습니까?
- 안전 필수 트래픽을 막는 차단이나 주행 중 리셋은 오탐과 미탐의 안전 영향, 처리 지연, 대체 동작을 검증한 경우에만 쓰고 있습니까?
- MAC 검증, 신선도 값 재시도, 버려진 메시지를 알아채는 시간까지 FTTI 예산에 넣었습니까?
- 안전과 보안이 부딪칠 때의 우선순위 규칙이 문서로 있습니까?
두 팀이 같은 고장, 같은 시간 예산, 같은 반응을 함께 놓고 설계할 때, 서로를 약하게 만드는 틈이 줄어듭니다.
참고 문헌
- 아흐마드 MK 나세르 지음, 주백수, 신승환 옮김, 『자동차 사이버보안 엔지니어링 핸드북』, 에이콘출판, 2026. 6장 기능 안전과 사이버보안의 상호작용, 8장 차량 수준 보안 통제.
- ISO 26262-1:2018, Road vehicles, Functional safety, Part 1: Vocabulary. 안전 상태, 비상 운전, FTTI, FDTI, FRTI, FHTI 용어.
- ISO 26262-2:2018, Road vehicles, Functional safety, Part 2: Management of functional safety.
- ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering.
- K.-T. Cho, K. G. Shin, Error Handling of In-vehicle Networks Makes Them Vulnerable, Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS 2016), pp. 1044-1055.
- A. Palanca, E. Evenchick, F. Maggi, S. Zanero, A Stealth, Selective, Link-Layer Denial-of-Service Attack Against Automotive Networks, DIMVA 2017, Lecture Notes in Computer Science, Springer, pp. 185-206.
- CISA(ICS-CERT), CAN Bus Standard Vulnerability, ICS-ALERT-17-209-01, 2017.
- AUTOSAR, E2E Protocol Specification, Foundation R24-11, 6.20절 E2E 상태 기계, 6.20.4절 FTTI와 E2E 파라미터.
- AUTOSAR, Specification of Secure Onboard Communication, Classic Platform R24-11, 검증 실패 처리와 7.8절 Security Events.
- AUTOSAR, Specification of Intrusion Detection System Manager, Classic Platform R24-11.
이 글은 2026년 10월 11일 기준 공개 자료를 바탕으로 정리했습니다. AUTOSAR 모듈의 세부 동작은 릴리스별 명세와 실제로 쓰는 소프트웨어 플랫폼의 구현을 따르며, 오류 처리와 보안 대응의 적합성은 각 프로젝트의 안전 개념과 TARA로 판단해야 합니다.
관련 서비스
안전 메커니즘과 오류 처리 전략까지 TARA와 사이버보안 콘셉트에서 함께 따져 보고 싶으시다면, 세온이앤에스의 접근 방식을 확인해 보세요.
관련 영상
이 글의 핵심을 영상으로도 정리했습니다.