CSMS(Cybersecurity Management System) 완벽 정리: 자동차 사이버보안 관리 시스템 실무 가이드

CSMS(Cybersecurity Management System) 완벽 정리: 자동차 사이버보안 관리 시스템 실무 가이드

CSMS란?

---

들어가며

2015년 7월, 미국의 보안 연구자 2명이 Jeep Cherokee의 원격 해킹에 성공했습니다

시동을 끄고, 변속기를 조작하고, 브레이크를 무력화해버렸죠

차량은 고속도로에서 시속 145km로 질주하던 중 완전히 정지되었습니다

운전자는 가까스로 안전한 장소에 정차했습니다

이 사건으로 인해....

 

 Jeep은 130만 대를 리콜해야 했습니다

비용은 수백억 원대. 신뢰도는 바닥.

이 사건은 자동차 업계에 "연결된 차량 = 해킹 가능한 차량" 이라는 교훈을 주게 되었죠

 

현대의 자동차는 더 이상 기계가 아닙니다

소프트웨어로 제어되는 하나의 작은 컴퓨터라고 할 수 있죠

WiFi, LTE, Bluetooth, CAN, LIN 등 여러 통신 채널이 존재합니다.

OTA로 원격 업데이트된다. 대시보드에서 인터넷 접속이 가능합니다

 

이렇게 "연결된" 차량을 보호하기 위한 것이 바로 CSMS(Cybersecurity Management System)입니다

설계 단계부터 배포, 모니터링, 그리고 폐기까지 '보안을 관리하는 종합 시스템'인거죠

이 글에서는 CSMS의 원리, 아키텍처, ISO/SAE 21434 표준, 그리고 실무 구현법을 정리해보려 합니다!!

 

오늘도 버없토와 함께 실무에 다가가 봅시다

---

CSMS란?

1. CSMS(Cybersecurity Management System)란?

1.1 정의

CSMS = 차량 사이버보안을 체계적으로 관리하는 조직의 프로세스, 정책, 도구의 종합 시스템

CSMS의 범위:

┌────────────────────────────────────────────────┐
│  Automotive Cybersecurity Management System    │
├────────────────────────────────────────────────┤
│                                                │
│  [1] 조직 & 거버넌스                          │
│  - 보안 팀 구성                               │
│  - 책임 및 권한                               │
│  - 정책 수립                                  │
│                                                │
│  [2] 위협 분석 & 위험 평가                     │
│  - 공격 경로 식별                             │
│  - 심각도 평가                                │
│  - 위험 등급 결정                             │
│                                                │
│  [3] 보안 설계                                │
│  - 암호화 아키텍처                           │
│  - 접근 제어                                  │
│  - 데이터 보호                                │
│                                                │
│  [4] 개발 & 테스트                           │
│  - 보안 코드 리뷰                             │
│  - 취약점 검사                                │
│  - 침투 테스트                                │
│                                                │
│  [5] 배포 & OTA                              │
│  - 안전한 업데이트 메커니즘                  │
│  - 통신 보안                                  │
│  - 버전 관리                                  │
│                                                │
│  [6] 모니터링 & 대응                         │
│  - 이상 탐지                                  │
│  - 인시던트 대응                              │
│  - 보안 패치 배포                             │
│                                                │
│  [7] 공급망 관리                             │
│  - 공급업체 검증                              │
│  - 부품 추적                                  │
│  - 보안 심사                                  │
│                                                │
└────────────────────────────────────────────────┘

1.2 CSMS vs 기존 보안

항목	기존 보안	CSMS
범위	IT 부서 담당	조직 전체 관여
타이밍	개발 후 테스트	설계 단계부터
책임	보안 팀만	전 사원
표준	권장사항	ISO/SAE 21434 강제
업데이트	수동 패치	OTA 보안 업데이트
감시	사후 (침입 후)	사전 (모니터링)
규제	없음	NHTSA, EU 규제

1.3 자동차 보안의 특수성

일반 IT 보안:
- 랩탑 해킹 → 데이터 손실
- 서버 침입 → 서비스 중단
- 복구: 재부팅, 백업 복구

자동차 보안:
- 차량 해킹 → 사람의 생명 위험!
- 브레이크 조작 → 사고, 사망
- 엔진 제어 변조 → 차량 폭발
- 복구: 정비소 방문 (비용 수백억)

차이점:
IT: 데이터 보호 중심
자동차: 생명 보호 중심 (Safety + Security)

---

2. 자동차 보안 위협

2.1 공격 경로 (Attack Surface)

자동차의 진입점들:

               ┌─ OTA (무선 업데이트)
               │
외부 공격      ├─ Telematics (진단 데이터 전송)
(네트워크)    │
               ├─ WiFi (차량 내 네트워크)
               │
               └─ Cellular (LTE, 5G)

               ┌─ 진단 포트 (OBD-II, CAN)
               │
물리적 공격    ├─ USB 포트
               │
               └─ 하드웨어 탈취 (플래시 메모리)

               ┌─ 공급업체 공급망
               │
내부 공격      ├─ 정비소 접근
               │
               └─ 직원의 악의적 행위

예시: Jeep Cherokee 해킹

공격자 → 인터넷 → Jeep의 엔터테인먼트 시스템
      ↓
      CAN 버스에 접근
      ↓
      Brake ECU 제어
      ↓
      브레이크 조작 성공!

2.2 실제 해킹 사례

[사례 1] Jeep Cherokee (2015)
─────────────────────────────
공격자: 보안 연구자 Charlie Miller, Chris Valasek
방법: WiFi를 통한 원격 접근 (OTA 경로)
피해: 엔진 끔, 변속기 조작, 브레이크 무력화
결과: 130만 대 리콜, 수백억 원 손실


[사례 2] Tesla Model S (2015)
─────────────────────────────
공격자: Tencent Security Lab
방법: CAN 버스 조작 (펌웨어 취약점)
피해: 스티어링 휠 제어, 스피드 조작
결과: OTA 보안 패치로 복구


[사례 3] Hyundai Bluelink (2021)
──────────────────────────────
공격자: 보안 연구자들
방법: 불충분한 인증 (원격 기능 해킹)
피해: 원격 시동, 잠금 해제
결과: 긴급 OTA 보안 패치 배포


[사례 4] BMW ConnectedDrive (2022)
─────────────────────────────────
공격자: 보안 연구자들
방법: API 취약점 (계정 탈취)
피해: 다중 차량의 위치 추적, 제어
결과: 즉시 보안 업데이트

2.3 위협 분류

[1] Confidentiality (기밀성) 위협
────────────────────────────────
공격: 데이터 탈취
영향: 개인정보, 주행 기록, GPS 위치 추적
예: 텔레메트리 데이터 노출


[2] Integrity (무결성) 위협
──────────────────────────
공격: 데이터/펌웨어 변조
영향: 엔진 성능 변조, 계기판 조작
예: 마일리지 변조 (부정 판매), 배기 조작


[3] Availability (가용성) 위협
─────────────────────────────
공격: 서비스 중단 (DoS)
영향: 차량 기능 마비
예: OTA 서버 공격으로 업데이트 불가


[4] Safety (안전성) 위협
─────────────────────────
공격: 생명 위험 조작
영향: 사고, 사망
예: 브레이크 무력화, 엔진 급가속

---

3. ISO/SAE 21434 표준

3.1 표준 개요

표준명: Road vehicles - Cybersecurity engineering

출처: 국제표준화기구 (ISO) + 미국자동차공학회 (SAE)

발표: 2021년 (최신: 2023년 업데이트)

적용 범위:
✓ 모든 자동차 제조사 (규제)
✓ 전기차, 수소차, 자율주행차 필수
✓ 부품 공급업체도 준수 필요

요구사항: 7가지 핵심 영역

[1] 사이버보안 거버넌스 (Governance)
- 조직 정책 수립
- 보안 팀 구성
- 예산 배정

[2] 사이버보안 관리 계획 (CSMS)
- 프로세스 정의
- 책임 할당
- 검증 방법

[3] 위협 분석 및 위험 평가 (TARA)
- 공격 경로 식별
- 심각도 평가
- 위험 등급 결정

[4] 보안 요구사항 명세 (Specification)
- 암호화 필요
- 인증 필요
- 접근 제어 필요

[5] 보안 설계 및 개발
- 아키텍처 설계
- 코드 리뷰
- 취약점 검사

[6] 제품 배포 및 유지보수
- OTA 보안
- 버전 관리
- 패치 배포

[7] 인시던트 대응
- 모니터링
- 탐지
- 대응
- 복구

3.2 TARA (Threat Analysis and Risk Assessment)

TARA는 CSMS의 핵심!
→ 모든 보안 요구사항의 기초가 됨

[Step 1] 공격 경로 식별
────────────────────────

자동차 시스템:
┌─────────────────────────────┐
│ Engine Control ECU          │
├─────────────────────────────┤
│ - CAN 인터페이스            │
│ - Bootloader                │
│ - Flash 메모리              │
└─────────────────────────────┘

공격 경로:
1. 진단 포트 (OBD-II) → CAN → Engine ECU
2. OTA → Bootloader → Flash
3. 내부 네트워크 침입 → CAN 스니핑


[Step 2] 위협 식별
────────────────

경로 1: 진단 포트 공격
└─ 위협: 악의적 명령 주입
   └─ 결과: 엔진 제어 변조


경로 2: OTA 공격
└─ 위협: 가짜 펌웨어 설치
   └─ 결과: 차량 완전 제어


경로 3: CAN 스니핑
└─ 위협: 메시지 해석, 메시지 조작
   └─ 결과: RPM, 온도, 위치 변조


[Step 3] 심각도 평가
────────────────────

등급: 매우 낮음 (ASIL QM) ~ 매우 높음 (ASIL D)

평가 지표:
- Severity (S): 얼마나 심각한가?
  Q (Negligible) ~ 3 (Fatal)

- Exploitability (E): 얼마나 쉬운가?
  3 (Very difficult) ~ 0 (Trivial)

- Controllability (C): 운전자가 제어 가능한가?
  3 (Controllable) ~ 0 (Uncontrollable)

계산: Risk = S - E - C

결과:
┌─────────────────────────┐
│ ASIL D (최고 위험)      │
│ - 브레이크 조작         │
│ - 스티어링 조작         │
│ - 엔진 끔               │
├─────────────────────────┤
│ ASIL C (높은 위험)      │
│ - 속도 조작             │
│ - 기어 변경             │
├─────────────────────────┤
│ ASIL B (중간 위험)      │
│ - 에어컨 제어           │
│ - 창문 조작             │
├─────────────────────────┤
│ ASIL A / QM (낮은 위험) │
│ - 라디오 조작           │
│ - 대시보드 정보         │
└─────────────────────────┘


[Step 4] 위험 등급 결정
──────────────────────

각 경로별로 위험 등급 부여:

공격 경로               Severity  Expl  Ctrl  Risk  ASIL
─────────────────────────────────────────────────────
진단 포트 → 브레이크      3        0     0     3     ASIL D
OTA → 펌웨어            3        1     0     2     ASIL C
CAN → 속도              2        1     3     1     ASIL B

→ 각 ASIL 레벨별 보안 요구사항 결정!

3.3 보안 요구사항 예시

ASIL D (최고 위험) 요구사항:

[1] 암호화
┌─────────────────────────────┐
│ - CAN 메시지 암호화 필수    │
│ - OTA 데이터 TLS 암호화     │
│ - 저장 데이터 AES-256      │
└─────────────────────────────┘

[2] 인증
┌─────────────────────────────┐
│ - 모든 ECU 상호 인증        │
│ - OTA 서명 검증 필수        │
│ - 디지털 인증서 사용        │
└─────────────────────────────┘

[3] 접근 제어
┌─────────────────────────────┐
│ - CAN 메시지 필터링         │
│ - OBD-II 포트 제약          │
│ - 진단 기능 잠금            │
└─────────────────────────────┘

[4] 감시
┌─────────────────────────────┐
│ - 이상 메시지 탐지          │
│ - 접근 시도 로깅            │
│ - 실시간 모니터링           │
└─────────────────────────────┘

[5] 복구
┌─────────────────────────────┐
│ - 롤백 메커니즘             │
│ - 안전한 상태 유지          │
│ - 자동 복구 프로토콜        │
└─────────────────────────────┘

---

4. CSMS 아키텍처

4.1 조직 구조

일반 자동차 회사:

┌────────────────────────────────────────┐
│ 최고경영진 (CEO/CTO)                   │
└─────────────┬──────────────────────────┘
              │
┌─────────────▼──────────────────────────┐
│ 보안 거버넌스 위원회                   │
│ - 정책 수립                            │
│ - 예산 결정                            │
│ - 위험 승인                            │
└─────────────┬──────────────────────────┘
              │
    ┌─────────┼─────────┐
    │         │         │
┌───▼──┐ ┌───▼──┐ ┌───▼──┐
│설계  │ │개발  │ │운영  │
│팀    │ │팀    │ │팀    │
├──────┤ ├──────┤ ├──────┤
│TARA  │ │코드  │ │모니터│
│분석  │ │리뷰  │ │링    │
├──────┤ ├──────┤ ├──────┤
│보안  │ │테스트│ │대응  │
│설계  │ │      │ │계획  │
└──────┘ └──────┘ └──────┘


책임:

설계팀:
- 위협 분석 (TARA)
- 보안 요구사항 작성
- 아키텍처 설계
- 보안 심사

개발팀:
- 보안 코딩
- 코드 리뷰
- 취약점 검사
- 침투 테스트

운영팀:
- 모니터링 (IDS)
- 인시던트 탐지
- 보안 패치 배포
- 사고 대응

4.2 CSMS 프로세스

차량 개발 수명주기 전체에 보안 통합:

[1] 설계 단계 (Design)
───────────────────
TARA → 위협 식별
   ↓
보안 요구사항 작성
   ↓
보안 아키텍처 설계
   ↓
리뷰 및 승인

산출물:
- TARA Report
- Security Specification
- Security Architecture


[2] 개발 단계 (Development)
──────────────────────
코드 작성 (보안 규칙 준수)
   ↓
정적 분석 (Static Analysis)
   ↓
보안 코드 리뷰
   ↓
단위 테스트

산출물:
- 보안 코드
- 취약점 레포트
- 코드 리뷰 기록


[3] 검증 단계 (Verification)
───────────────────────
동적 분석 (Dynamic Analysis)
   ↓
펄져 테스팅 (Fuzzing)
   ↓
침투 테스트 (Penetration Test)
   ↓
보안 테스트 리포트 작성

산출물:
- 취약점 목록
- 침투 테스트 결과
- 보안 검증 결과


[4] 배포 단계 (Deployment)
──────────────────────
안전한 OTA 메커니즘 사용
   ↓
버전 관리 및 추적
   ↓
보안 패치 배포 절차 검증

산출물:
- OTA 패키지
- 배포 계획


[5] 운영 단계 (Operation)
──────────────────────
실시간 모니터링
   ↓
이상 탐지 (IDS)
   ↓
인시던트 대응
   ↓
보안 패치 배포

산출물:
- 모니터링 데이터
- 인시던트 로그
- 보안 패치


[6] 폐기 단계 (Decommissioning)
─────────────────────────────
차량 회수
   ↓
데이터 삭제
   ↓
펌웨어 삭제
   ↓
보안 감시

---

5. 보안 설계 & 구현

5.1 CAN 메시지 암호화

// AES-128 암호화로 CAN 메시지 보호
#include <openssl/aes.h>

typedef struct {
    uint8_t data[8];      // 원본 데이터
    uint8_t mac[4];       // 메시지 인증 코드
} CAN_Message_Secure_t;

// CAN 메시지 암호화 및 서명
void CAN_EncryptMessage(
    uint8_t* original_data,
    uint8_t* encryption_key,
    CAN_Message_Secure_t* encrypted_msg
) {
    AES_KEY key;
    uint8_t iv[16] = {0};  // Initialization Vector
    uint8_t encrypted_data[16];

    // AES 키 설정
    AES_set_encrypt_key(encryption_key, 128, &key);

    // 데이터 암호화 (CBC 모드)
    AES_cbc_encrypt(
        original_data,
        encrypted_data,
        16,  // 블록 크기
        &key,
        iv,
        AES_ENCRYPT
    );

    // 암호화된 데이터 복사
    memcpy(encrypted_msg->data, encrypted_data, 8);

    // MAC (Message Authentication Code) 생성
    GenerateMAC(encrypted_data, 8, encryption_key, encrypted_msg->mac);
}

// MAC 생성 함수
void GenerateMAC(
    uint8_t* data,
    int length,
    uint8_t* key,
    uint8_t* mac
) {
    // HMAC-SHA256 사용 (첫 4바이트만 사용)
    unsigned char hmac_result[32];
    unsigned int hmac_len;

    HMAC(
        EVP_sha256(),
        key,
        32,
        data,
        length,
        hmac_result,
        &hmac_len
    );

    // 처음 4바이트만 MAC으로 사용
    memcpy(mac, hmac_result, 4);
}

// CAN 메시지 복호화 및 검증
Std_ReturnType CAN_DecryptMessage(
    CAN_Message_Secure_t* encrypted_msg,
    uint8_t* encryption_key,
    uint8_t* decrypted_data
) {
    AES_KEY key;
    uint8_t iv[16] = {0};
    uint8_t decrypted[16];
    uint8_t calculated_mac[4];

    // 먼저 MAC 검증 (무결성 확인)
    GenerateMAC(encrypted_msg->data, 8, encryption_key, calculated_mac);

    if (memcmp(calculated_mac, encrypted_msg->mac, 4) != 0) {
        // MAC 검증 실패 → 메시지 변조됨!
        return ERROR;
    }

    // AES 키 설정
    AES_set_decrypt_key(encryption_key, 128, &key);

    // 데이터 복호화
    AES_cbc_encrypt(
        encrypted_msg->data,
        decrypted,
        16,
        &key,
        iv,
        AES_DECRYPT
    );

    memcpy(decrypted_data, decrypted, 8);
    return OK;
}

5.2 OTA 서명 검증

// RSA-2048로 OTA 펌웨어 서명 검증
#include <openssl/rsa.h>
#include <openssl/sha.h>

typedef struct {
    uint8_t firmware[0x100000];  // 1MB 펌웨어
    uint8_t signature[256];      // 2048-bit 서명
    uint8_t certificate[2048];   // X.509 인증서
} OTA_Package_t;

// 펌웨어 서명 검증
Std_ReturnType OTA_VerifySignature(
    OTA_Package_t* ota_package,
    uint32_t firmware_size
) {
    RSA* rsa_key = NULL;
    uint8_t sha256_hash[32];
    unsigned int hash_len = SHA256_DIGEST_LENGTH;
    int verify_result;

    // 1. 펌웨어의 SHA-256 해시 계산
    SHA256(
        ota_package->firmware,
        firmware_size,
        sha256_hash
    );

    // 2. 인증서에서 공개키 추출
    X509* cert = d2i_X509(
        NULL,
        (const unsigned char**)&ota_package->certificate,
        sizeof(ota_package->certificate)
    );

    if (cert == NULL) {
        return ERROR;  // 인증서 파싱 실패
    }

    // 3. 인증서 유효성 확인 (만료 날짜 등)
    if (VerifyCertificateValidity(cert) != OK) {
        X509_free(cert);
        return ERROR;
    }

    // 4. 공개키 추출
    EVP_PKEY* public_key = X509_get_pubkey(cert);
    if (public_key == NULL) {
        X509_free(cert);
        return ERROR;
    }

    rsa_key = EVP_PKEY_get1_RSA(public_key);

    // 5. 서명 검증
    verify_result = RSA_verify(
        NID_sha256,
        sha256_hash,
        hash_len,
        ota_package->signature,
        256,
        rsa_key
    );

    // 정리
    RSA_free(rsa_key);
    EVP_PKEY_free(public_key);
    X509_free(cert);

    if (verify_result == 1) {
        return OK;  // 서명 검증 성공!
    } else {
        return ERROR;  // 서명 검증 실패 (가짜 펌웨어!)
    }
}

// 인증서 유효성 확인
Std_ReturnType VerifyCertificateValidity(X509* cert) {
    time_t current_time = time(NULL);
    ASN1_TIME* not_before = X509_getm_notBefore(cert);
    ASN1_TIME* not_after = X509_getm_notAfter(cert);

    // 발급 날짜 확인
    if (X509_cmp_time(not_before, &current_time) > 0) {
        return ERROR;  // 아직 유효하지 않음
    }

    // 만료 날짜 확인
    if (X509_cmp_time(not_after, &current_time) < 0) {
        return ERROR;  // 만료됨
    }

    return OK;  // 유효함
}

---

6. 침투 테스트 (Penetration Testing)

6.1 테스트 항목

침투 테스트: 실제로 해킹해보기!

[1] CAN 버스 테스트
─────────────────

공격 시뮬레이션:
1. CAN 메시지 스니핑
   → 통신 내용 읽기 가능?

2. 메시지 재전송 (Replay Attack)
   → 녹음된 메시지 다시 전송?

3. 메시지 조작
   → 메시지 내용 변경 후 전송?

4. DoS 공격
   → 대량 메시지로 버스 점유?

결과:
✓ 모든 공격 방어 → PASS
❌ 메시지 재전송 성공 → FAIL (보안 패치 필요)


[2] OTA 보안 테스트
──────────────────

공격 시뮬레이션:
1. 중간자 공격 (MITM)
   → 다운로드 중 펌웨어 가로채기?

2. 가짜 펌웨어 주입
   → 악의적 펌웨어 설치 가능?

3. 이전 버전 설치 (Rollback)
   → 버그 있는 구버전 강제?

4. 버전 검증 우회
   → 서명 검증 스킵?

결과:
✓ 모든 공격 방어 → PASS
❌ 가짜 펌웨어 설치됨 → FAIL (서명 검증 강화)


[3] 진단 포트 테스트
───────────────────

공격 시뮬레이션:
1. 무단 접근
   → OBD-II 연결 후 제어?

2. UDS 명령 실행
   → 진단 명령으로 제어?

3. 펌웨어 다운로드
   → 메모리 내용 추출?

결과:
✓ 모든 공격 방어 → PASS
❌ UDS 명령으로 제어 가능 → FAIL (접근 제어 강화)


[4] Wireless 테스트
──────────────────

공격 시뮬레이션:
1. WiFi 스니핑
   → 데이터 암호화 확인?

2. Bluetooth 공격
   → 페어링 정보 탈취?

3. LTE 가로채기
   → 신호 변조?

4. 신호 재밍
   → 통신 차단?

결과: TLS 암호화로 보호됨

6.2 펄져 테스팅 (Fuzzing)

// 랜덤 데이터를 입력해서 버그 찾기
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// CAN 메시지 파서 (버그 있을 가능성)
void CAN_ParseMessage(uint8_t* data, int length) {
    if (length < 8) {
        return;
    }

    uint8_t message_type = data[0];
    uint16_t message_id = (data[1] << 8) | data[2];
    uint32_t value = (data[3] << 24) | (data[4] << 16) | 
                     (data[5] << 8) | data[6];

    switch (message_type) {
        case 0x01:
            Engine_SetRPM(value);
            break;
        case 0x02:
            Brake_SetPressure(value);
            break;
        case 0x03:
            Steering_SetAngle(value);
            break;
        default:
            break;
    }
}

// 펄저: 랜덤 입력 생성
int main() {
    uint8_t fuzz_data[8];
    int iterations = 1000000;
    int crash_count = 0;

    srand(time(NULL));

    for (int i = 0; i < iterations; i++) {
        // 랜덤 데이터 생성
        for (int j = 0; j < 8; j++) {
            fuzz_data[j] = rand() % 256;
        }

        // 파서에 입력 (크래시 감지)
        if (setjmp(crash_handler) == 0) {
            CAN_ParseMessage(fuzz_data, 8);
        } else {
            // 크래시 발생!
            crash_count++;

            printf("[CRASH #%d] Fuzz data: ", crash_count);
            for (int j = 0; j < 8; j++) {
                printf("%02X ", fuzz_data[j]);
            }
            printf("\n");

            // 분석을 위해 데이터 저장
            SaveCrashData("crashes.log", fuzz_data, 8);
        }
    }

    printf("Total iterations: %d\n", iterations);
    printf("Crashes found: %d\n", crash_count);

    return 0;
}

// 결과:
// Total iterations: 1000000
// Crashes found: 3
// 
// [CRASH #1] Fuzz data: FF FF FF FF FF FF FF FF
// [CRASH #2] Fuzz data: 01 00 00 00 00 00 00 00
// [CRASH #3] Fuzz data: 02 7F FF FF FF FF FF FF
//
// → 3개 버그 발견! 즉시 수정 필요

---

7. 모니터링 & 인시던트 대응

7.1 실시간 모니터링 (IDS)

차량 내 IDS (Intrusion Detection System):

┌─────────────────────────────────┐
│ 차량의 여러 ECU에서 신호 수집   │
├─────────────────────────────────┤
│ Engine ECU                      │
│ Brake ECU                       │
│ Gateway ECU                     │
│ Infotainment ECU                │
└──────────────┬──────────────────┘
               │ (CAN 메시지)
               ▼
        ┌──────────────┐
        │ IDS 엔진     │
        ├──────────────┤
        │ 패턴 분석    │
        │ 이상 탐지    │
        │ 로깅         │
        └──────┬───────┘
               │
          ┌────▼────────────────┐
          │ 위험도 판단          │
          ├─────────────────────┤
          │ Low (경고)          │
          │ Medium (제약)       │
          │ High (긴급 중단)    │
          └─────────────────────┘


[탐지 규칙 예시]

규칙 1: CAN 메시지 빈도 이상
─────────────────────────
정상: Engine RPM 메시지 100ms 주기
비정상: 5ms 주기로 들어옴 (1000배 증가!)
→ 의도적인 공격일 수 있음
→ 경고!

규칙 2: 메시지 값 범위 초과
────────────────────────
정상: 엔진 RPM 0 ~ 7000
비정상: 50,000 수신
→ 데이터 변조!
→ 경고!

규칙 3: 암호화 검증 실패
──────────────────────
정상: MAC 검증 성공
비정상: MAC 불일치
→ 메시지 변조됨!
→ 경고!

규칙 4: 진단 포트 접근
────────────────────
정상: 정비소 UDS 명령만
비정상: 일반 주행 중 UDS 명령
→ 불순한 접근!
→ 경고!

7.2 인시던트 대응 절차

보안 인시던트 발생!

[Phase 1] 탐지 (Detection)
─────────────────────────
IDS 알람 발생
    ↓
확인: 진짜 공격인가?
    ↓
예 → Phase 2 진행
아니오 → 오탐 기록


[Phase 2] 격리 (Containment)
──────────────────────────
피해 최소화
    ↓
공격 경로 차단
    ├─ CAN 메시지 필터링
    ├─ OTA 중단
    └─ 외부 통신 차단
    ↓
차량 제어 제약
    ├─ 속도 제한
    ├─ 기능 비활성화
    └─ 안전 모드 활성화


[Phase 3] 대응 (Response)
────────────────────────
증거 수집
    ↓
로그 백업
    ↓
공격 분석
    ↓
제조사에 보고


[Phase 4] 복구 (Recovery)
──────────────────────────
보안 패치 개발
    ↓
OTA로 배포
    ↓
영향받은 차량 업데이트
    ↓
검증 및 모니터링


[Phase 5] 개선 (Improvement)
───────────────────────────
근본 원인 분석
    ↓
방어 메커니즘 강화
    ↓
침투 테스트 반복
    ↓
보안 정책 업데이트

---

8. 공급망 보안

8.1 공급업체 관리

공급망 보안의 핵심:

[문제] 자동차 제조사는 부품을 직접 만들지 않음

제조사 (Tier 0)
    ↓
부품 공급업체 (Tier 1)
    ├─ Bosch (제어 시스템)
    ├─ Continental (센서)
    ├─ Denso (전자 부품)
    └─ Harman (인포테인먼트)
    ↓
부품의 부품 공급업체 (Tier 2)
    ├─ 칩 제조사
    ├─ 반도체 회사
    └─ 소프트웨어 회사
    ↓
부품의 부품의 부품 (Tier 3+)

위험: 어디서나 악의적 코드 주입 가능!

해결책: 공급망 보안 전략

[1] 공급업체 선택
─────────────────
보안 심사:
- ISO/SAE 21434 준수?
- CSMS 보유?
- 과거 보안 사건?

인증:
- ISO 9001 (품질)
- ISO 27001 (정보보안)
- ISO/SAE 21434 (자동차 사이버보안)


[2] 부품 검수
──────────────
소스 코드 검토
    ↓
정적/동적 분석
    ↓
침투 테스트
    ↓
검증 및 승인


[3] 지속적 모니터링
───────────────────
공급업체 감사
    ↓
보안 업데이트 추적
    ↓
취약점 리포트
    ↓
즉시 대응

---

9. 자주 하는 실수

9.1 CSMS를 "보안 팀만의 책임"으로 생각

❌ 잘못된 예:
// CEO: "보안 팀이 알아서 해."
// 개발자: "내 일 아님"
// 운영팀: "그건 설계팀 책임"

문제:
- 개발자가 보안을 무시하고 코드 작성
- TARA 결과가 적용되지 않음
- 취약한 제품 출시
- 리콜 및 평판 손상

✅ 올바른 예:
// 전사적 보안 문화 구축
// - CEO: 보안 예산 배정
// - 개발자: 보안 코드 작성
// - 운영팀: 모니터링 및 대응
// - 모두가 책임짐

9.2 침투 테스트 생략

❌ 잘못된 예:
// "우리 코드는 안전하다고 생각해"
OTA_ReleaseVersion(firmware);  // 테스트 없이 배포!

문제:
- 예상하지 못한 취약점 존재
- 실제 해킹당할 수 있음
- 리콜 및 소송

✅ 올바른 예:
// 의무적 침투 테스트
for (int round = 0; round < 3; round++) {
    Penetration_Test_CAN();
    Penetration_Test_OTA();
    Penetration_Test_DiagPort();

    if (vulnerabilities_found > 0) {
        FixVulnerabilities();
        continue;  // 다시 테스트
    }
}

OTA_ReleaseVersion(firmware);  // 안전한 배포!

9.3 로깅 및 모니터링 없음

❌ 잘못된 예:
void CAN_ReceiveMessage(uint8_t* data) {
    ProcessMessage(data);  // 그냥 처리만 함
    // 로깅 없음!
    // 모니터링 없음!
}

문제:
- 공격이 일어나도 인식 불가
- 사후 분석 불가능
- 증거 없음

✅ 올바른 예:
void CAN_ReceiveMessage(uint8_t* data) {
    // 메시지 로깅
    LogMessage("CAN_RX", data, 8);

    // 무결성 검증
    if (VerifyMAC(data) != OK) {
        LogAlert("CAN_MAC_FAILURE", data, 8);
        return ERROR;
    }

    // 범위 검증
    if (ValidateMessageRange(data) != OK) {
        LogAlert("CAN_OUT_OF_RANGE", data, 8);
        return ERROR;
    }

    ProcessMessage(data);
}

---

10. 핵심 정리

CSMS (Cybersecurity Management System):
- 차량 사이버보안 종합 관리 시스템
- 설계 → 개발 → 배포 → 운영 → 폐기 전체 수명주기 보안

필요성:
- 연결된 자동차 증가 (WiFi, LTE, OTA)
- 해킹 위협 증대 (생명 위험)
- 규제 요구사항 (ISO/SAE 21434)
- 리콜 비용 감소 (수백억 대)

핵심 요소:
- 조직 구조: 전사적 보안 문화
- TARA: 위협 분석 및 위험 평가
- 설계: 보안 아키텍처
- 개발: 보안 코딩 및 리뷰
- 테스트: 침투 테스트, 펄징
- 배포: OTA 보안
- 운영: 모니터링 및 대응

기술:
- 암호화: AES-128, AES-256
- 서명: RSA-2048, SHA-256
- 인증: X.509 인증서
- 감시: IDS (Intrusion Detection)
- 로깅: 모든 이벤트 기록

보안 등급:
- ASIL D (최고): 브레이크, 스티어링
- ASIL C (높음): 속도, 기어
- ASIL B (중간): 에어컨, 창문
- ASIL A/QM (낮음): 라디오, 정보

주의사항:
- CSMS는 모두의 책임 (설계팀, 개발팀, 운영팀)
- 침투 테스트 필수
- 로깅 및 모니터링 필수
- 공급망 보안도 중요
- 지속적인 개선 필요