要約

  • 設定変更によって過去の測定値そのものが間違いになるわけではない。ただし、その値を新しい構成の説明に使えるかどうかは、別に確かめる必要がある。
  • RFC 9411 は性能試験での構成の一貫性を求め、付録のセキュリティー有効性試験も同じ試験環境と構成に結びつけている。機種名の一致だけでは、この条件を満たしたことにはならない。
  • 省略された機能や試験の限界を明示することと、その条件を自社の用途に十分だと認めることは異なる。後者の判断を誰が担うかが、結果を再利用する際の問題になる。

変更申請に添付された古い報告書

ある企業が、使用中のファイアウォールで検査機能を追加するとしよう。変更担当者は必要な保護を説明し、設備担当者は十分な処理能力があると答える。その根拠として、導入時の性能報告書が添えられる。

これは特定の企業で確認された事例ではなく、証拠の使い方を考えるための仮定である。報告書は正確かもしれない。装置も同じ機種かもしれない。それでも、新しい検査を有効にした状態で、その処理能力と保護が両立するとまでは分からない。

逆に、変更があったというだけで報告書を捨てるのも早計だ。変更内容が測定の対象とどう関係するかを見ずに、すべてを再試験の対象にすれば、判断に必要な確認と形式的なやり直しを区別できなくなる。

必要なのは、有効か無効かの二択に飛びつくことではない。過去の試験がどの状態を観察したのか、今回の判断がどの状態についてのものなのか、その間に何が変わったのかをつなぐ作業である。

RFC 9411 は、この作業の手掛かりになる。2023 年 3 月に公表された IETF の情報提供文書で、ネットワーク・セキュリティー装置の性能評価方法を扱い、RFC 3511 を置き換えた。インターネット標準化過程の仕様ではなく、特定製品の認証書でもない。

過去の数値と現在の主張を分ける

試験報告書が残すのは、ある条件の下で得られた観察である。後日その条件が変わっても、当時の観察が自動的に消えるわけではない。問題は、その観察から導こうとする主張の範囲が変わることにある。

たとえば、以前は対象外だった通信を検査するようになった場合、装置が処理する仕事は増えたり変わったりし得る。ただし、どの程度性能が変わるかは、機能、実装、通信内容、環境に左右される。設定差があるという事実だけから、一定割合の性能低下を計算することはできない。

そこで同文書の第 4.2 節は、第 7 節の性能試験を通じて装置またはシステムの構成を同じにするよう求めている。選択した保護機能も、一貫して有効にしておく。試験ごとに仕事を変えながら、製品名だけを共通の見出しにするための方法ではない。

構成には、実際の、または一般的な配備に相当する機能や設定を使う。装置は通信経路上で能動的に検査を行う。結果に添える構成の説明が重要なのは、数値の背景を飾るためではなく、何を測ったのかを読者が特定するためだ。

機種を買うことと、受け入れ可能な動作状態を確認することは、近いが同じではない。試験後に構成を変えた企業が引き継ぐべきなのは製品の評価だけでなく、評価と状態の対応関係である。

保護の試験と速度の試験を結ぶ条件

RFC 9411 の主眼は性能評価にある。第 4.2.1 節では、性能試験に先立ってセキュリティー機能の有効性を評価することを推奨する。それを行わない場合は、影響を説明しなければならない。したがって、報告書に RFC 9411 と書いてあるだけで、有効性評価まで実施されたと推定することはできない。

付録 A の方法で有効性を調べる場合には、つながりがさらに明確になる。試験環境と装置構成を性能試験と同じにすることが定められている。クライアントとサーバーのアドレス範囲や暗号の条件にも対応関係が必要となる。

この条件によって、二つの試験が同じ仕事をする装置について語っているかどうかを確認できる。ある構成で攻撃を阻止したという記録と、別の構成で通信を処理したという記録は、それぞれ有用でも、直ちに一つの能力を証明するわけではない。

変更審査に置き換えると、問いは具体的になる。新しい保護を説明する資料と、処理能力を説明する資料は、共通の構成に立っているのか。違いがあるなら、その違いを認めても今回の判断に足りる理由は何か。

単に「性能の実績あり」「セキュリティー評価済み」と並べると、この問いが消える。二つの正しい説明を接続するところに、未確認の前提が残り得るのである。

例外は、失敗とも無条件の許可とも違う

同文書は、あらゆる製品機能を無差別に有効にするよう要求しているわけではない。推奨機能を有効にしない場合には、その理由を報告し、性能に影響し得ることを示す必要がある。用途によって不要な機能があることも認めている。

したがって、機能の省略を発見しただけで、試験が不正だったと結論するのは誤りだ。一方、省略が丁寧に書かれているからといって、自社が必要とする機能を有効にした場合にも結果がそのまま当てはまるわけではない。

開示が答えるのは「どのような試験だったか」であり、採用判断が答えるのは「その試験で今回の目的に足りるか」である。試験の実施者が前者を正確に説明していても、後者まで代わりに決めたことにはならない。

試験構成では、障害時に検査をせず通信を通す動作を無効にし、ログ記録と報告機能を有効にすることも求められる。ただし、ログの粒度などについて製品設計上の違いを扱う余地がある。その場合も、条件を読み取れる形で残すことが大切だ。

これは本番設定の万能な指示書ではない。数値を成立させた条件の説明である。本番で別の判断をするなら、その判断と試験結果の使い方を混同しないことが求められる。

試験方法そのものにも対象外がある

特に見落としにくくしておきたいのが、第 3 節の範囲だ。この性能評価方法は、機械学習や行動分析に依存するシステムを対象としていない。該当する機能があれば、この方法での試験では無効にすることが想定されている。

それを「機械学習を使わない方が安全だ」という助言に読み替える根拠はない。示しているのは測定方法の対象範囲であって、現在のすべてのセキュリティー機能の優劣ではない。

利用者がそのような機能を重要な保護として使う予定なら、報告書がどこまでを評価したかを一層明確にする必要がある。対象外の機能を含む構成の能力まで、対象内の構成から無条件に広げることはできない。

有効性の評価にも、別の限界がある。付録 A は、阻止した脆弱性だけでなく、阻止できなかったもの、背景トラフィックへの影響、装置の報告の正確さを扱う。背景トラフィックの検証には、誤検知がないことも含まれる。

しかし、定めた条件で誤検知がなかったことは、将来のあらゆる通信で誤検知しないという保証ではない。試験した攻撃の範囲を超える防御能力も、それだけで証明されたことにはならない。本稿は製品試験を実施しておらず、特定の装置の結果を示していない。

装置を変えなくても、試験環境は変わる

設定の同一性だけを確認しても十分ではない。仮想環境で動くセキュリティー装置なら、割り当てられた資源や周囲の条件も結果の解釈に関わる。第 4.1 節と第 5 節は、試験環境自体が装置のボトルネックに見えないよう、基準となる試験を求めている。

装置を置かない状態や、実質的に単純転送させる状態で環境を確かめることは、測定対象を切り分けるための確認だ。そのときの速さを、保護機能を働かせた装置の成績に置き換えてはならない。

通信を生成する側の余力、環境の損失や遅延、仮想資源の安定性を確かめることで、何に結果を帰属させられるかが変わる。後日ホスト環境を変えたなら、装置の設定ファイルが同じでも、過去の説明を再利用できるか検討する理由になる。

負荷の与え方も結果の一部である。第 4.3.4 節は試験を複数の段階に分け、測定を負荷維持の段階で行う。推奨される維持時間の下限は 300 秒で、生データの採取間隔は 2 秒未満とされている。これを顧客向けの稼働保証や応答時間の約束とみなすことはできない。

結果を読む際には、通信内容や接続条件、測定したプロトコルの層も必要になる。検査を受け、通過を認められた通信の処理量と、機能を省いた単純な転送速度は、同じ名称の欄に置けば同じ指標になるわけではない。

RFC 6815 が説明するように、こうしたベンチマークは隔離された試験環境で扱うべきものだ。本番ネットワークで負荷をかけ直せば簡単に疑問が解ける、という話ではない。確認すべき主張を先に絞らなければ、追加試験も判断から離れてしまう。

説明責任を置く場所

ここで参照する編集上の視点は、Lu Heng が インターネット統治の代理問題を論じた文章 にある、決定する側と不利益を負う側の関係である。これは試験機関や製品供給者に問題があったという証拠ではない。

また、BTW.Media の役割を論じた文章 は、主張の擁護よりも現実を記述することを重視する。この題材で守るべきなのは、製品への賛否ではなく、観察した事実とそこから導く判断を分ける姿勢だ。

試験結果は、再利用できるから価値がある。ただし、その価値を維持するには、数値だけでなく条件も引き継がなくてはならない。構成が変わったとき、過去の報告書を残すことと、そのまま現在の根拠にすることは、別の決定なのである。