차량 ECU Fuzzing Test(퍼징 테스트), 왜 필요하고 어떻게 활용할까?

1. 자동차 사이버보안 강화와 퍼징 테스트의 필요성차량의 주요 기능을 소프트웨어로 구현하는 범위가 확대되고 있으며, 외부 통신을 통한 서비스 제공과 소프트웨어 업데이트도 자동차의 중요한 기능으로 자리 잡고 있습니다. 이러한 변화는 차량의 기능과 서비스 확장에 새로운 가능성을 제공하는 동시에, 사이버보안 관점에서 고려해야 할 공격 표면(Attack Surface)도 확대하고 있습니다. 과거에는 차량 내부의 제한된 네트워크와 ECU 간 통신을 중심으로 보안 문제를 살펴보았다면, 이제는 차량 외부의 통신 인터페이스, 진단 시스템, 소프트웨어 업데이트 경로, 외부 서비스와의 연계까지 함께 고려해야 합니다. 특히 차량 내부의 여러 ECU가 네트워크로 연결되어 있다는 점에서 하나의 인터페이스에 존재하는 취약점이 다..

1. 기능안전 전문가는 왜 Engineering Decision에서 멀어졌을까?기능안전 업무를 오래 수행하다 보면, 늘 아쉬운 모습 중 하나로 "기능안전 담당자는 HARA, FMEA, FTA, Safety Requirement와 같은 전문적인 활동을 수행하고 ISO 26262에 대해서도 상당한 지식을 가지고 있지만, 실제 시스템의 아키텍처나 설계를 결정하는 자리에서는 상대적으로 한 발 떨어져 있는 경우가 많다"는 점입니다. 실제 회의에서도 이런 모습을 종종 볼 수 있는데요, 개발자는 센서 구성이나 통신 구조, 진단 방식, 제어 로직, degraded mode와 같은 구체적인 설계 대안에 관심을 가지고 논의하는 반면, 기능안전 담당자는 이러한 논의가 어느 정도 진행된 이후 안전 요구사항이 충족되는지 확인하..

“기능안전 심사를 통과하면 기능안전이 달성된 건가요?” 과거 함께 일했던 상사가 제게 던진 질문입니다. 물론 당시 대화의 취지는 기능안전 심사의 중요성을 부정하려는 것이 아니라, 안전 분석을 통해 위험을 식별하고, 이를 통제할 수 있는 적절한 안전 메커니즘을 설계하며, 실제 제품에 구현한 후 검증을 통해 그 효과를 입증해야 비로소 기능안전 달성을 설명할 수 있다는 것이었습니다. 하지만, 그 대화는 이후 제게 또 다른 고민을 남겼습니다. “기능안전 달성 여부를 과연 PASS와 FAIL로 판단할 수 있을까?” 기능안전은 시스템의 기능 이상으로 인한 불합리한 위험을 방지하는 것을 의미합니다. 이러한 안전을 달성했는지 판단하려면 위험 분석의 적절성, 안전 대책의 효과성, 검증 증거의 충분성 등 여러 기술적 근..

1. 기능안전의 중요성은 크게 높아졌다.자동차 개발에서 "기능안전"이라는 단어가 지금처럼 자연스럽게 사용되기 시작한 것은 그리 오래된 일이 아닙니다. 10~20년 전만 하더라도 기능안전은 일부 안전 전문가나 특정 프로젝트에서 주로 다루는 전문 영역에 가까웠습니다. 그러다 보니 자연스럽게 개발자는 자신의 기능을 설계하고 구현하는 일이 중심이었고, 기능안전은 그 과정에서 필요한 경우 "별도로 검토하는 업무"로 인식되는 경우가 많았습니다.그런데 지금은 ISO 26262가 많이 보편화 되었고, 그에 따른 자동차 개발 프로세스도 어느정도 정착되었습니다. 그리고 자연스럽게 시스템 개발 전반에 녹아들어 시스템 개발의 일부 단계에만 머무르지 않습니다. 먼저 자동차 제조사에서는 Concept 단계에서 Hazard를 분석..

1. 위험 가설은 아직 시험 시나리오가 아니다어떤 시스템이 특정 조건에서 위험해질 수 있다는 생각(위험 가설)을 했다고 해서, 곧바로 시험을 시작할 수는 없습니다. 위험 가설은 어디까지나 “이런 상황에서 문제가 발생할 가능성이 있다”는 수준의 문제 제기 수준이므로, 실제 시험에서 필요한 "무엇을 변화시킬 것인지", "어떤 조건을 고정할 것인지", "무엇을 관찰할 것인지", 그리고" 어떤 결과를 위험의 징후로 판단할 것인지"가 더 구체적으로 더 정의되어야 합니다.예를 들어 “AEB가 보행자를 늦게 인식할 수 있다.”라는 위험 가설이 있다고 할 때, 이 문장은 충분히 중요한 안전 문제를 제기하고 있지만, 이 상태로는 시험 시나리오라고 보기 어렵습니다. 보행자를 늦게 인식한다는 현상이 어떤 조건에서 발생하는지..

이번 포스팅은 지난 포스팅에서 이어집니다.ISO 21448(SOTIF): 고장이 없는데도 위험하다면, 무엇을 더 분석해야 할까? ISO 21448(SOTIF): 고장이 없는데도 위험하다면, 무엇을 더 분석해야 할까?자동차의 기능안전은 오랫동안 ISO 26262를 중심으로 발전해 왔습니다. 자동차 개발 조직은 HARA(Hazard Analysis and Risk Assessment)를 통해 위험을 식별하고, 안전 목표와 안전 요구사항을 수립하며, FMEA와habana4.tistory.com지난 포스팅에서는 ISO 26262 기반 기능안전 체계에 SOTIF를 적용할 때, 차량 수준의 위험은 통합적으로 바라보되 고장과 기능적 불충분함이라는 발생 원인은 구분해서 분석해야 한다는 점을 살펴보았습니다.그런데 여기에..