ISO 21434 심사의 추적성: 퍼징을 증거로 만들기

ISO/SAE 21434는 단순히 안전하라고 요구하지 않습니다. 심사관에게 증거를 가지고 보여주라고 요구합니다. 바로 이 차이에서 많은 훌륭한 보안 작업이 심사에서 무너지며, 보안 테스트는 그 가장 뚜렷한 예입니다.

표준은 테스트를 요구합니다. 그리고 서면 기록도 요구합니다

테스트 요구사항은 충분히 명확합니다. Clause 10.4.2(통합 및 검증)는 구현이 사이버보안 사양을 충족하는지 검증할 것을 요구하며([RQ-10-09]), [RC-10-12]는 식별되지 않은 약점을 최소화하기 위해 퍼즈 테스트와 취약점 스캔을 포함한 컴포넌트 테스트를 권고합니다. Clause 11(사이버보안 검증)은 침투 테스트를 명시합니다([RQ-11-01]). CAL 2 이상부터는 통신 인터페이스 퍼징이 사실상 기대됩니다.

그러나 21434 심사는 퍼저를 실행했는지 여부로 평가되지 않습니다. 평가 대상은 작업 산출물입니다. 검증 보고서, 확인 보고서, 그리고 궁극적으로 아이템이 충분히 안전하다고 논증하는 사이버보안 케이스이며, 이는 사이버보안 심사(Clause 6.4.9)에서 판단됩니다. 심사관은 논증과 그 뒤에 있는 증거를 읽습니다. 그 논증에 기록되지 않은 퍼징 캠페인은 아예 없었던 것이나 다름없습니다.

양방향 추적성을 한 문장으로

심사관이 계속 요구하는 것은 양방향 추적성입니다. 모든 사이버보안 요구사항에서 그것을 검증하는 테스트로, 그리고 모든 테스트에서 다시 요구사항으로 이어지는 문서화된 연결입니다.

보안 테스트에서 이는 심사관이 사이버보안 목표(“ECU는 인증 없이 진단 쓰기를 수락해서는 안 된다”)에서 출발하여 사이버보안 요구사항으로, 다시 그것을 확인하는 테스트로 따라가서 결과와 날짜, 그리고 발견 사항에 대한 조치를 볼 수 있다는 뜻입니다. 반대 방향도 가능해야 합니다. 발견 사항 하나를 골라 그것이 위협하는 요구사항까지 거슬러 올라갈 수 있어야 합니다.

대부분의 팀은 테스트를 제시할 수 있습니다. 그러나 심사 당일에 그 연결 고리를 제시할 수 있는 팀은 훨씬 적습니다.

퍼징이 특히 어려운 지점

퍼징을 추적 가능하게 만드는 것은 세 가지 이유로 유독 까다롭습니다.

• 본질적으로 비결정적입니다. 크래시를 재현할 수 없다면 그것은 증거가 아니라 일화입니다. 심사관은 “3월에 한 번 크래시가 났습니다”를 받아들일 수 없습니다.
• 구조가 아니라 양을 만들어냅니다. 수백만 번의 반복과 쌓인 로그 더미는 짧은 사이버보안 요구사항 목록에 깔끔하게 대응되지 않습니다.
• 늦게, 그리고 드물게 실행됩니다. 심사 전 일회성 캠페인은 그 주에 가지고 있던 소프트웨어에 대해서만 말해줄 뿐, 출시하는 소프트웨어에 대해서는 말해주지 않으며 이력도 남기지 않습니다.

따라서 심사관이 퍼징에 대해 실제로 묻는 질문은 “퍼징을 했습니까?“가 아닙니다. *이 발견 사항을 재현할 수 있습니까, 처음 발견한 시점은 언제입니까, 어떤 요구사항과 관련이 있습니까, 그리고 어떤 조치를 취했습니까?*입니다.

심사 대응 가능한 보안 테스트 증거의 모습

어떤 도구를 사용하든 증거는 다섯 가지를 담고 있어야 합니다.

1. 재현성. 저장된 시드 또는 구성이 있어야 모든 발견 사항을 귀사와 심사관이 언제든 재생할 수 있습니다.
2. 날짜가 기록된 이력. 스냅샷이 아니라 ECU의 수명 전반에 걸쳐 무엇을 언제 테스트했는지에 대한 기록이 있어야 최종 상태만이 아니라 추세를 보여줄 수 있습니다.
3. 요구사항과의 연결. 각 발견 사항이 영향을 미치는 사이버보안 요구사항 또는 티켓과 연결되어야 양방향 추적이 유지됩니다.
4. 문서화된 리스크 수용. 잔여 리스크를 수용할 때 그 결정과 근거가 기록되고 다음 테스트 주기까지 유지되어야 합니다.
5. 읽을 수 있는 내보내기. 증거는 심사관과 귀사의 트래커가 사용할 수 있는 형태로 도구 밖으로 나와야 합니다. 파일용으로는 PDF, 툴링용으로는 SARIF입니다.

이 다섯 가지를 제대로 갖추면 퍼징 캠페인은 더 이상 로그 파일이 아니라 작업 산출물이 됩니다.

AutoST가 이를 위해 설계된 방식

이것이 21434 프로그램에서 AutoST가 담당하도록 설계된 부분입니다.

모든 실행은 재현 가능합니다. 퍼징 시드가 저장되고 표시되므로 크래시를 정확히 재생할 수 있습니다. 모든 스캔은 날짜와 함께 보관되므로 ECU 수명 전반의 이력이 재구성이 아니라 그대로 존재합니다. 모든 발견 사항에는 심각도와 구체적인 수정 방안이 포함되며, Fix Plan은 각 작업에 상태와 ALM/PLM 참조 필드를 부여합니다. 바로 이 필드에 귀사의 요구사항이나 티켓으로 되돌아가는 연결이 담깁니다. 리스크 수용과 코멘트는 재테스트에도 이어지므로 수용된 잔여 리스크는 문서화된 상태로 유지되고 수정된 이슈는 해결됨으로 표시됩니다. 그리고 출력물은 심사 파일용 PDF와 툴링용 SARIF입니다.

AutoST는 API와 CI에서 실행되기 때문에 테스트는 심사 직전의 급박한 작업이 아니라 Clause 8.5가 의도하는 의미의 지속적인 활동이 됩니다. 심사관은 단 한 번의 영웅적인 캠페인이 아니라 추세와 흔적을 보게 됩니다.

솔직한 경계

AutoST는 테스트 증거를 생성하고 추적 가능하게 유지합니다. 귀사의 TARA를 작성하거나, 사이버보안 관리 시스템을 운영하거나, 사이버보안 케이스를 저술하지는 않습니다. 그것은 프로세스와 엔지니어링 판단의 영역입니다. Zyberum은 그 영역도 컨설팅으로 담당합니다. ISO/SAE 21434에 대한 SAE 및 TÜV SÜD Automotive Cybersecurity 인증을 보유하고, Tier 1, Tier 2, OEM 프로그램을 바로 이 과정으로 이끌어 온 팀이 함께합니다. 레퍼런스는 요청 시 제공합니다.

귀사의 ECU에서 심사 대응 가능한 테스트 증거가 어떤 모습인지 확인하고 싶으시다면 데모를 예약해 주십시오. 실제 대상에서 직접 실행해 드리겠습니다.