개념
지능적인 적이 등장하면 안전의 정의가 바뀐다
레슨 4에서 ISO 26262를 봤다. 거기서 다룬 위험은 고장 이었다. 부품이 닳고, 비트가 뒤집히고, 센서가 값을 잘못 읽는다. 이런 고장은 확률로 다룰 수 있다. 고장률을 계산하고, 중복 설계를 넣고, 안전 상태로 빠지는 경로를 만들면 된다.
사이버보안이 다루는 위험은 성질이 다르다.
| 기능안전(ISO 26262) | 사이버보안(ISO/SAE 21434) | |
|---|---|---|
| 위험의 원천 | 무작위 고장, 체계적 결함 | 의도를 가진 공격자 |
| 확률 모델 | 고장률로 추정 가능 | 확률이 아니라 공격 가능성 추정 |
| 시간에 따른 변화 | 대체로 일정하거나 마모로 증가 | 출시 후 계속 나빠진다(새 취약점·새 도구 등장) |
| 대응 시점 | 설계 단계에서 대부분 결정 | 설계 + 운영 중 지속 대응 필수 |
| 검증 성격 | 요구사항 충족 확인 | 충족 확인 + 뚫으려는 시도 |
가장 중요한 줄은 세 번째다. 부품은 출고 시점이 가장 안전하고 시간이 지나며 마모되지만, 소프트웨어 보안은 출고 시점의 방어력이 그대로여도 바깥 세계가 강해져서 상대적으로 약해진다. 어제까지 안전했던 암호 방식이 오늘 논문 하나로 무너진다. 그래서 사이버보안 규격은 "출시하면 끝"이라는 구조를 애초에 허용하지 않는다.
ISO/SAE 21434 — 자동차 사이버보안 엔지니어링의 뼈대
ISO/SAE 21434(Road vehicles — Cybersecurity engineering)는 차량용 전기·전자 시스템의 개념 단계부터 폐기까지 전 생애주기에 걸친 사이버보안 활동 을 규정한다. ISO와 SAE가 공동으로 만든 규격이라는 점에서 이름 앞에 두 기관이 함께 붙는다.
구조를 크게 네 덩어리로 잡으면 기억하기 쉽다.
① 조직 차원
사이버보안 정책·규칙, 역할과 책임, 역량 관리, 도구 관리,
사이버보안 문화, 지속적 활동(취약점 모니터링·대응)
② 프로젝트 차원
사이버보안 계획, 사이버보안 케이스, 사이버보안 심사,
릴리즈 판단(post-development 이관)
③ 제품 개발
아이템 정의 → TARA → 사이버보안 목표·요구사항 →
설계 → 구현 → 검증(단위·통합·차량 레벨)
④ 개발 이후
생산, 운영·유지보수(모니터링·사고 대응·업데이트), 폐기레슨 4에서 ISO 26262의 구조를 봤다면 ①~③이 낯설지 않을 것이다. V 모델의 좌우 대칭, 요구사항에서 검증으로 이어지는 추적성, 등급에 따른 활동 강도의 차등. 뼈대는 같다. 결정적으로 다른 것은 ④가 형식적인 부록이 아니라 규격의 무게중심 중 하나 라는 점이다.
TARA — 이 규격의 심장
21434를 한 단어로 요약하라면 TARA(Threat Analysis and Risk Assessment, 위협 분석 및 리스크 평가)다. ISO 26262에서 HARA(위험원 분석 및 리스크 평가)가 ASIL을 만들어냈듯이, 21434에서는 TARA가 무엇을 얼마나 방어할지를 결정한다.
TARA는 대체로 이런 순서로 진행된다.
1단계 — 자산 식별과 피해 시나리오
먼저 "무엇을 지키는가"를 정한다. 자산은 부품이 아니라 그 부품이 담고 있는 가치 다. 그리고 그 자산이 훼손됐을 때 어떤 피해가 생기는지 쓴다.
| 자산 | 훼손되면 생기는 일 |
|---|---|
| 조향 제어 명령의 무결성 | 주행 중 의도치 않은 조향 → 사고 |
| 차량 위치 이력 | 개인의 이동 패턴 노출 |
| 도어 언락 인증 키 | 차량 절도 |
| OTA 펌웨어 서명 검증 | 악성 펌웨어 설치 |
2단계 — 영향 평가 (S·F·O·P)
각 피해 시나리오의 영향을 네 범주로 평가한다. 기능안전이 사람의 안전 하나만 봤던 것과 달리, 사이버보안은 네 방향을 본다.
- Safety — 신체적 상해로 이어지는가
- Financial — 금전적 손실이 발생하는가
- Operational — 차량 기능이 정상적으로 수행되지 못하는가
- Privacy — 개인정보가 침해되는가
이 확장이 실무에서 큰 차이를 만든다. "사람이 다치지 않으니 낮은 등급" 이라는 판단이 통하지 않는다. 위치 이력 유출은 안전 영향이 없어도 프라이버시 영향이 최고 수준일 수 있다.
3단계 — 공격 경로 분석과 공격 가능성 평가
"어떻게 하면 그 자산에 닿을 수 있는가"를 경로로 그린다. 공격 트리를 쓰는 것이 일반적이다.
[목표] 주행 중 조향 명령 주입
├─ 경로 A: OBD-II 포트 물리 접근 → CAN 버스에 프레임 주입
│ └─ 전제: 차량 내부 물리 접근, 진단 세션 인증 우회
├─ 경로 B: 텔레매틱스 유닛 원격 취약점 → 게이트웨이 우회 → CAN
│ ├─ 전제: 셀룰러 인터페이스의 원격 코드 실행 취약점
│ └─ 전제: 게이트웨이의 메시지 필터링 미흡
└─ 경로 C: 정비소 진단 장비 공급망 침해 → 서명된 경로로 진입
└─ 전제: 진단 장비 인증 체계의 신뢰 저장소 침해그리고 각 경로의 공격 가능성(attack feasibility) 을 평가한다. 평가 축은 대체로 다음과 같다 — 소요 시간, 필요한 전문성, 대상에 대한 지식, 접근 기회(물리 접근이 필요한가, 원격으로 되는가), 필요한 장비.
여기서 QA에게 중요한 통찰이 하나 있다. 경로 C처럼 "우리 코드에 버그가 없어도 성립하는 경로"가 존재한다. 공급망과 신뢰 체계까지 시야에 넣지 않으면 TARA는 절반짜리가 된다.
4단계 — 리스크 결정과 처리
영향과 공격 가능성을 조합해 리스크 값을 내고, 각 리스크에 대해 네 가지 중 하나를 정한다.
| 처리 방식 | 의미 | 예 |
|---|---|---|
| 회피 | 그 기능·인터페이스를 없앤다 | 양산 차량에서 디버그 포트 제거 |
| 저감 | 통제를 넣어 리스크를 낮춘다 | 메시지 인증(MAC), 게이트웨이 필터링 |
| 이전 | 계약·보험으로 넘긴다 | 공급사 책임 범위 명시 |
| 수용 | 근거를 남기고 받아들인다 | 잔여 리스크로 문서화 |
"수용"에도 문서가 필요하다는 점이 핵심이다. 아무 조치를 하지 않기로 한 결정도 근거와 함께 기록돼야 하고, 그 기록이 곧 사이버보안 케이스의 일부가 된다. 조용히 넘어간 리스크는 규격 관점에서 존재하지 않는 것이 아니라 처리되지 않은 것 이다.
CAL — 활동 강도를 정하는 또 하나의 눈금
21434에는 CAL(Cybersecurity Assurance Level)이라는 개념도 등장한다. ASIL이 안전 활동의 강도를 정했듯, CAL은 사이버보안 활동을 얼마나 엄격하게 수행할지를 나타내는 눈금(CAL1~CAL4)이다.
다만 실무에서 ASIL만큼 기계적으로 쓰이지는 않는다. ASIL은 26262에서 필수 산출물과 기법 표에 직접 연결되지만, CAL은 활동 강도를 조율하는 보조 수단에 가깝게 다뤄지는 경우가 많다. CAL 값 자체보다, "이 리스크에 대해 우리가 어느 정도로 검증했는가"를 설명할 수 있는지가 중요하다.
UNECE R155·R156 — 규격을 법으로 만드는 장치
21434는 규격이다. 지키면 좋지만 강제력은 계약에서 나온다. 그런데 UNECE 규정 이 여기에 법적 강제력을 덧붙였다.
R155(사이버보안 및 CSMS) 는 차량 형식승인의 조건으로 두 가지를 요구한다.
- 제조사가 CSMS(Cyber Security Management System, 사이버보안 관리체계)를 갖추고 있고, 그것이 인증받았을 것
- 승인받으려는 각 차종에 대해 위험 평가와 대응이 적절히 수행됐음을 보일 것
즉 조직 차원의 체계 인증과 차종 차원의 증빙이 둘 다 필요하다. CSMS 인증이 없으면 차를 팔 수 없다 는 구조라, 규격이 곧 시장 진입 조건이 된다. GS인증이 국내 조달 시장의 입장권이었다면, R155는 UNECE 협정 당사국 시장의 입장권이다 — 레슨 7에서 본 구조가 도메인만 바꿔 반복된다.
R156(소프트웨어 업데이트 및 SUMS) 은 짝을 이루는 규정이다. 무선 업데이트(OTA)를 포함한 소프트웨어 업데이트를 안전하게 관리하는 체계 (SUMS, Software Update Management System)를 요구하고, RXSWIN (Regulation X Software Identification Number)이라는 식별자로 "지금 이 차에 실린 소프트웨어가 승인받은 그 버전인지"를 추적할 수 있게 한다.
QA 관점에서 R156이 요구하는 것은 결국 이것이다.
- 업데이트 전후 차량이 승인된 형식을 벗어나지 않는지 확인할 수 있는가
- 업데이트가 중단되거나 실패했을 때 차량이 안전한 상태로 남는가
- 어떤 차량에 어떤 버전이 설치돼 있는지 추적 가능한가
- 사용자에게 업데이트의 영향을 알리고 필요한 경우 동의를 받는가
모듈 14에서 배운 배포 파이프라인·롤백 전략이 여기서는 형식승인의 요건 이 된다. "롤백이 되나요"라는 질문이 엔지니어링 취향의 문제가 아니라 법규 대응 항목이 되는 것이다.
그래서 QA는 무엇을 하는가
규격 이름과 절차를 아는 것과, 그 안에서 테스트 엔지니어로 일하는 것은 다르다. 이 도메인에서 QA가 실제로 맡는 일은 대체로 다섯 갈래다.
1. 사이버보안 요구사항의 검증 가능성 확보
"통신은 안전해야 한다" 같은 문장은 검증할 수 없다. 모듈 2에서 배운 그대로다. "게이트웨이는 진단 세션 인증 없이 수신된 진단 요청 프레임을 전달하지 않는다"처럼 관찰 가능한 문장 으로 바꾸는 것이 첫 일이다.
2. 요구사항 기반 보안 테스트
각 사이버보안 요구사항에 대응하는 정상·비정상 케이스를 만든다. 인증 실패, 만료된 인증서, 변조된 서명, 재전송(replay) 프레임 등. 여기까지는 기능 테스트의 연장이다.
3. 취약점 지향 테스트 — 여기서부터 성격이 달라진다
- 퍼징(Fuzzing) — CAN 프레임, UDS 진단 서비스, 블루투스·Wi-Fi 스택에 변형된 입력을 대량으로 밀어넣어 예외 처리 결함을 찾는다.
- 침투 테스트 — 공격자 관점에서 TARA가 그린 경로를 실제로 시도한다. TARA가 문서로 남긴 가정("이 경로는 전문 장비가 필요해 가능성 낮음")이 현실에서도 유효한지 확인하는 절차이기도 하다.
- 알려진 취약점 스캔 — 사용 중인 오픈소스·서드파티 컴포넌트의 CVE를 지속적으로 확인한다. 레슨 4에서 배운 SOUP 개념이 여기서 그대로 이어진다. 자동차 도메인에서는 이것이 SBOM 관리로 제도화되는 추세다.
4. 잔여 리스크와 근거의 문서화
시험 결과가 사이버보안 케이스로 들어간다. 여기서 요구되는 것은 레슨 4와 같다 — "테스트했다"가 아니라 "이 요구사항을 이 방법으로 검증했고 결과가 이러하다"를 추적 가능한 형태로 남기는 것.
5. 출시 이후의 감시
새 CVE가 우리가 쓰는 컴포넌트에 나왔을 때, "이 차종에 영향이 있는가"를 몇 시간 안에 판단할 수 있어야 한다. 그 판단을 가능하게 하는 것은 평소에 관리해둔 부품–소프트웨어–버전–차종의 연결 정보 다. 이건 사고가 난 뒤에 만들 수 없다.
세 규격의 관계를 한 장으로
ISO 26262 ISO/SAE 21434 R155 / R156
(기능안전) (사이버보안 엔지니어링) (법적 강제)
│ │ │
고장으로부터 공격으로부터 체계·차종 증빙 없으면
사람을 지킨다 자산을 지킨다 형식승인 불가
│ │ │
HARA → ASIL TARA → 리스크 처리 CSMS 인증 + 차종 증빙
│ │ SUMS + RXSWIN
└───────────┬───────────┘
│
같은 뼈대: 요구사항 → 설계 → 검증의 추적성,
등급에 따른 활동 강도, 근거의 문서화두 규격은 경쟁하지 않는다. 실제 프로젝트는 대개 둘을 동시에 만족해야 하고, 그때 충돌 지점이 생긴다. 예를 들어 안전 관점에서는 "이상 시 즉시 안전 상태로 전이"가 정답인데, 보안 관점에서는 그 전이를 공격자가 일부러 유발할 수 있는 서비스 거부 경로 로 본다. 이런 충돌을 찾아내 드러내는 것도 QA의 일이다.
사례 — 충돌을 먼저 찾아낸 QA
차량 도어 제어 모듈의 원격 잠금 해제 기능 검증에서 실제로 겪은 구조다. 요구는 두 쪽에서 왔다.
| 출처 | 요구 |
|---|---|
| 기능안전(ISO 26262) | 사고 감지 시 도어 잠금을 즉시 해제한다(구조 접근 보장) |
| 사이버보안(21434) | 도어 잠금 해제 명령은 인증된 요청만 수락한다 |
두 요구는 각각 타당하고, 각각의 검증도 통과했다. 문제는 교차점이었다.
QA가 TARA 표를 읽다가 질문 하나를 던졌다.
"사고 감지 신호가 인증 경로를 우회하도록 설계돼 있는데, 그 신호를 위조하면 어떻게 되나요?"
| 답 | 결과 |
|---|---|
| 사고 신호는 내부 버스에서만 온다 | 버스에 접근하면 위조 가능(OBD 포트·게이트웨이 경유) |
| 위조되면? | 주차된 차량의 도어가 열린다 — 절도 경로 |
이 공백은 어느 한쪽 검증으로도 안 보였다. 안전 쪽 테스트는 "사고 시 열리는가" 를 확인하고 통과했고, 보안 쪽 테스트는 "인증 없는 해제 명령이 거부되는가" 를 확인하고 통과했다. 사고 신호 자체가 인증을 우회하는 경로 라는 사실은 두 요구를 나란히 놓았을 때만 보였다.
조치는 설계 변경이었다 — 사고 신호에 다중 센서 합의(충격·에어백 전개· 속도 변화)를 요구하고, 차량 정지·주차 상태에서는 그 경로를 비활성화 하는 것. 그리고 QA 쪽에서 한 일이 더 있었다.
- 두 요구의 교차 지점을 목록으로 만들었다(안전 전이 ↔ 인증 우회)
- 그 목록을 TARA 의 공격 경로 후보로 등록했다
- 검증 케이스에 "안전 기능을 악용하는" 시나리오를 추가했다
세 번째가 이 사례의 핵심 산출물이다. 안전 기능은 보통 "정상 동작하는가" 로만 검증되는데, 보안 관점에서는 그 기능 자체가 공격 수단일 수 있다. 두 시각을 한 사람이 들고 있을 때 이 공백이 보이고, 그래서 QA가 두 규격을 모두 아는 것에 실질적 값이 있다.
실무에서 왜 필요한가
자동차 도메인에 있지 않더라도 이 규격이 주는 사고 틀은 넓게 쓰인다. "이 기능이 요구대로 동작하는가"에서 "이 기능을 악용하면 무엇을 얻을 수 있는가"로 질문을 바꾸는 훈련 이기 때문이다. 결제, 인증, 권한, 파일 업로드가 있는 모든 서비스에서 같은 질문이 성립한다.
실제로 TARA의 구조는 모듈 4에서 배운 리스크 기반 테스트 와 골격이 같다. 영향과 발생 가능성을 곱해 우선순위를 만들고, 높은 것부터 자원을 투입한다. 다른 점은 '발생 가능성'을 자연 확률이 아니라 공격자의 비용 으로 추정한다는 것뿐이다. 이 치환을 이해하면 보안 테스트 계획은 훨씬 익숙한 작업이 된다.
조직 차원에서는 R155가 만든 구조를 눈여겨볼 만하다. 출시 후 지속적인 모니터링과 대응 능력이 인증 요건에 포함된다 는 것은, 품질 활동이 릴리즈에서 끝나지 않는다는 원칙을 규제가 강제한 사례다. 모듈 14의 관측 가능성(observability)과 모듈 6의 결함 관리가 여기서 하나의 요구로 합쳐진다.
채용시장에서의 위치
자동차 사이버보안은 국내에서 인력 대비 수요가 뚜렷하게 앞서 있는 영역이다. 완성차·부품사·컨설팅사·시험인증기관이 모두 같은 인력 풀을 두고 경쟁한다. 채용공고의 요건은 회사가 달라도 대체로 다음 형태로 수렴한다.
- ISO/SAE 21434 및 UNECE R155 기준에 따른 사이버보안 체계 점검·구축
- 고객사 맞춤 보안 솔루션·컨설팅 제공
- 자동차 산업 또는 정보보안 경력 3년 이상, 관련 전공 학사 이상
- 우대: 완성차·부품사 경험, 정보보안 자격증, 프로젝트 관리 경험
주목할 점은 요구 역량이 "뚫는 기술"보다 "체계를 만들고 증명하는 능력" 쪽에 무게가 실려 있다는 것이다. TARA 워크숍을 진행하고, 산출물을 규격 조항에 매핑하고, 심사에서 방어하는 일이 업무의 상당 부분을 차지한다. 그래서 QA·테스트 배경을 가진 사람이 진입하기 좋은 영역이다 — 추적성 문서를 만들고 유지해본 경험 이 그대로 통한다.
면접에서 자주 나오는 질문 하나만 미리 생각해두면 좋다. "기능안전과 사이버보안의 차이를 설명해보세요." 표면적 답은 "고장 대 공격"이지만, 한 겹 더 들어간 답은 "위험이 시간에 따라 어떻게 변하는가, 그래서 출시 이후 활동이 왜 필수인가" 다.