要約

  • IODEF の共有制限は階層を通じて引き継がれる。子要素では制限を強めることも、明示して緩めることもできるため、報告全体の表示だけでは足りない。
  • 情報の値が正確にコピーされても、上位から継承した条件が失われれば、共有範囲の解釈は変わり得る。
  • IODEF の旧来の amber と現行の TLP:AMBER は同じ受信者範囲を示さない。色名の置換も、開示範囲を決める作業になり得る。

連絡先を別のシステムへ渡す際、氏名、アドレス、担当業務の三つが元の報告と一致していれば、抽出は正しくできたように見える。だが、その連絡先を誰まで共有してよいかという条件が、元の報告の上位階層にだけ書かれていたらどうか。値の照合は通っても、利用の判断材料は欠けている。

これは特定の製品で確認された不具合ではない。情報の意味が周囲の構造にも依存するとき、抜粋に何を残すべきかを考えるための仮定である。暗号を破ったり、アドレスを書き換えたりしなくても、この種の欠落は説明できる。失われるのは値ではなく、値と条件の関係だからだ。

セキュリティ上のインシデントや指標を表現する IODEF は、この関係を明示している。2016 年 11 月の RFC 7970 は、その第 2 版の情報モデルと XML による表現を定義した。現在の公式記録では Proposed Standard とされる。形式を共通にすることと、一つ一つの断片が独立して解釈できることは別である。RFC 7970、公式記録。

上位の制限がすべてを決めるわけではない

第 3.3.1 節の restriction は、送信者が示す開示の指針である。そのクラスと子要素に適用されるが、子要素は異なる値で上書きできる。変更の方向は、厳格化だけではない。緩和も認められている。属性が指定されていなければ、最も近い、値を明示した上位要素から引き継ぐ。一般規則では Incident に private という既定値がある。

例えば、明示的に private とされた Incident の中に、public と明示された Contact があるとする。これは、報告全体を開放せず、その連絡先だけは共有可能だと伝える表現になり得る。逆に、協力先向けの報告に private の連絡先を含めることもできる。いずれも形式上の送信者の指針を説明する例であり、送信者が開示に必要な権利をすべて持つことを証明するものではない。RFC 7970、第 3.3.1 節。

したがって、最上位のラベルだけを表示する方式では、内部の厳しい制限を見落とす可能性がある。一方、全体を最も厳しい値にそろえる方式では、明示的に認められた局所的な共有を見えなくしてしまう。後者は受信組織が選ぶ保守的な運用として成立するが、各要素の指針をそのまま再現しているわけではない。

この違いには実務上の意味がある。別のネットワーク運用者に適切な連絡先だけを渡せれば、機微な調査内容を広めずに対応を助けられる。全体のラベルに従って一律に止めると、その経路も閉じてしまう。人が再確認する手間や協力の遅れという費用は考えられるが、本稿はその大きさを測定していない。必要なのは、厳しくした判断も組織自身の判断として説明することだ。

省略と「既定」は違う参照先を持つ

partner の Incident に、restriction を個別に指定していない Contact が入っている場合を考える。連絡先を切り出すときに上位の文脈を捨てれば、受信者は継承された指針を見つけられなくなる。姓名やアドレスの保存だけでは、この問題を解決できない。

さらに、明示的な default という値は、属性の省略と同じではない。これは通信する当事者間で事前に合意した開示方針を指す。省略なら上位要素を調べる必要があり、default なら当事者間の合意を調べる必要がある。両方をアプリケーションの「標準設定」に置き換えると、元の報告が参照していなかった受信側の方針を持ち込むおそれがある。IANA の Restriction 登録表。

すべてのクラスについて、省略時の扱いを簡単に断定できるわけでもない。一般規則、個別クラスの記述、XML スキーマの間には、注意して読み合わせるべき箇所がある。本稿の例は Contact と明示的な属性を用い、EventData や Expectation での省略を、疑義のない事例として扱っていない。交換する側が明確な値と運用上の解釈を合意することはできる。それを規格全体に対する公式な解決と呼ぶべきではない。

色をそろえても意味はそろわない

文脈には階層だけでなく語彙の版も含まれる。今回確認した IANA の登録表では、IODEF の旧来の別名として white は public、green は partner、amber は need-to-know、red は private に対応する。ここで need-to-know は、組織内部の知る必要がある人への共有を示す。IANA。

これに対し、FIRST の現行 TLP 2.0 は、2022 年 8 月から正式な版として扱われている。その TLP:AMBER では、組織と顧客を保護するために必要な範囲で、受信組織の内部とその顧客に共有できる。組織内部だけに限定するのは TLP:AMBER+STRICT である。情報源は追加の制限を示すことができ、範囲を広げるには情報源の明示的な許可が必要になる。ラベルの文字列は、日本語の文章でも変更しない。FIRST TLP 2.0。

この定義の比較から、古い amber を無条件に TLP:AMBER へ置き換えると、従来は内部だけだった範囲に顧客が加わる可能性があると分かる。ただし、これは公開定義に基づく分析であって、製品の誤動作や実際の漏えいを確認した結果ではない。また、万人に適用できる承認済みの変換規則を示すものでもない。組織の境界や追加指示を含め、交換の取り決めが必要だ。

変換表を更新する担当者は、見た目を整えるだけのつもりでも、結果として情報を渡せる相手の範囲に関わる。どの版の意味を使うのか、範囲を広げる変更を誰が確認するのか。その責任を「形式の互換性」という名目の中に埋めないことが重要になる。

読み込めることと、判断できること

RFC 7970 の第 4.3 節は、XML が整形式であることを要求し、スキーマへの適合を推奨する一方、情報モデルの追加制約も考慮しなければならないとする。スキーマ検証だけで意味の妥当性がすべて確認できるわけではない。受け入れ処理の成功を、共有条件を理解した証拠として扱うのは範囲を広げすぎている。

その区別を示す限定的な例が、2018 年 11 月に確認された技術的勘誤 5543 である。Confidence のスキーマを修正し、本文が説明する数値内容を持てるようにした。しかし、数値を受け取れるようにすることは、数値の意味を統一することではない。数値による信頼度の解釈は RFC の定義範囲外に残る。この勘誤は restriction の既定値についても結論を与えない。勘誤 5543、RFC 7970。

届いた後にも共有の仕事は残る

IODEF は基盤となる交換に機密性、完全性、真正性を求める。同時に、開示指針そのものには受信者の遵守を保証する技術的手段がないと認める。プライバシーの検討対象は伝送中だけではない。保存した報告や派生分析、第三者の情報、複数回の交換を通じて関連づけられる識別子も関係する。RFC 7970、第 9 節。

RID を扱う RFC 6545 は、プライバシーの合意や共有プロファイルについて、データの種類、保護、転送範囲、承認の扱いを論じている。攻撃元の身元を知らせずに、緩和措置を実施した結果を伝えることも想定する。役立つ協力が、常に最大量の開示を必要とするわけではない。また、各区間の通信を守ることだけで、経路全体の誰に内容が見えるかが決まるわけでもない。これらは設計上の議論であり、現在の個別の法的許可ではない。RFC 6545、第 9.5〜9.6 節。

本稿が提案するのは、抜粋を独立した出力として確認する運用である。有効な共有条件、その継承元、明示された例外、参照した方針や語彙の版を、説明に必要な範囲で残す。これは RFC が特定の監査台帳や実装方式を要求しているという主張ではない。機微な原文を至る所に複製せずに、なぜこの相手へ渡せるのかを説明できるようにするという提案だ。

Lu Heng が論じる象徴的な記述と実際に作用する力の違いは、ここで限定的な手がかりになる。ラベルは境界を表現し、抽出処理、受信者を承認する人、受信組織の取扱いがその境界を実際に保つ。Lu Heng が IODEF を論評したという意味ではない。表記を見るだけでは見落とす判断の所在を探すための読み方である。Lu Heng の現実の層に関する論考。

報告を使いやすくすることと、条件を失わせないことは両立すべきだ。断片が元の報告を離れても、共有できる理由まで見えなくする必要はない。