ISO 21434監査のトレーサビリティ：Fuzzingを成果にする

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つあります。

• 本質的に非決定的である。 クラッシュが再現できなければ、それはエビデンスではなく逸話です。アセッサーは「3月に一度クラッシュした」を受け入れられません。
• 構造ではなく量を生み出す。 数百万回のイテレーションと山積みのログは、短いサイバーセキュリティ要件リストにきれいに対応しません。
• 実行が遅く、まれである。 監査前の単発キャンペーンは、その週に手元にあったソフトウェアについて語るだけで、出荷するソフトウェアについては語らず、履歴も持ちません。

つまり、アセッサーがファジングについて本当に問うのは「ファジングしましたか？」ではありません。*この発見事項を再現できますか、最初に確認したのはいつですか、どの要件に関連しますか、そしてそれに対して何をしましたか？*という問いです。

監査対応のセキュリティテストエビデンスとは

どのツールを使うにせよ、エビデンスは5つの要素を備えている必要があります。

1. 再現性。 保存されたシードまたは設定により、どの発見事項も自分たちとアセッサーの双方が必要に応じて再生できること。
2. 日付付きの履歴。 スナップショットではなく、ECUのライフサイクルにわたって何をいつテストしたかの記録。最終状態だけでなく傾向を示せること。
3. 要件へのリンク。 各発見事項が影響するサイバーセキュリティ要件またはチケットに紐付けられ、双方向のトレースが成立すること。
4. 文書化されたリスク受容。 残存リスクを受容する際、その決定と根拠が記録され、次のテストサイクルまで引き継がれること。
5. 読めるエクスポート。 エビデンスがアセッサーと自社のトラッカーの両方が利用できる形でツールから出力されること。ファイル用にPDF、ツーリング用にSARIFです。

この5つを揃えれば、ファジングキャンペーンはログファイルではなくワークプロダクトになります。

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で監査対応のテストエビデンスがどのようなものかをご覧になりたい方は、デモをご予約ください。実際のターゲットに対して実行してお見せします。