Comodo が示した、証明書発行リスクは通知および執行リスクでもある

概要

• Comodo は、2011年3月15日に登録局アカウントが侵害され、7つのドメインに対して9つの不正証明書が発行されたと発表した。公開記録は、委任された発行の失敗を示しており、Comodo のルートキーやハードウェアセキュリティモジュールが盗まれたという所見はない。
• 説明責任の問題は9つの証明書にとどまらなかった。証明書は主要なログイン、メール、ブラウザ拡張機能、通信先を標的としており、依存するすべてのブラウザ、プラットフォーム、企業、公共部門ネットワークは、失効と緊急の不信措置が実際にユーザーに届くことを信頼しなければならなかった。
• Mozilla と Microsoft は、発行者による失効だけでは十分ではないと判断した。Mozilla はブラックリスト更新を出荷し、Microsoft は CRL と OCSP の動作がすべてのネットワーク状況で保護を保証できなかったため、証明書を Windows の信頼されていない証明書ストアに配置した。
• Comodo は委任発行モデル、パートナー認証、インシデント証拠を管理し、ブラウザおよび OS ベンダーは緊急執行を管理し、ルートプログラムは継続的信頼を管理し、ドメイン所有者と公的機関は RA アカウントや発行者ログを見ることなく下流リスクを負った。
• 永続的な教訓は、Web PKI の説明責任は証明書の数だけでなく、通知、執行、修復を測定しなければならないということである。CA は証明書を迅速に失効させても、不信が観察可能で強制可能でなければ、依拠者を露出したままにする可能性がある。

証拠記録とその使用方法

この記事は、公開記録を層状の証拠として扱う。インシデントレポート、標準、ブラウザまたはルーティング測定、規制当局または政策資料、および現在の事業者ガイダンスが、異なる主張のために使用される。企業作成の情報源は企業の立場として帰属される。標準とその後のガイダンスは、管理を説明し説明責任の期待を提示するために使用され、私的事実を捏造したり、公開記録がその主張を支持しない場合に後の義務を遡及的に課したりするものではない。

少数の証明書が大きな委任問題を隠していた

Comodo のインシデントは、まさにそれが生の数では大規模な侵害ではなかったからこそ有用である。9つの証明書は、リスト化、検査、推論するのに十分小さい。同時に、証明機関の集中した権力が、委任されたアカウントを通じてどのようにエコシステムリスクに変換され得るかを示すのにも十分である。Comodo は、障害が CA インフラや HSM で保護されたキーの盗難ではなく、登録局アカウントを通じて発生したと述べた。この区別は暗号上の主張を狭めるが、説明責任の主張を狭めるものではない。委任されたアカウントが主要ドメイン向けのブラウザ信頼証明書を取得できたのであれば、発行の実質的な権力はすでに企業ルートセレモニーを超えて、ユーザーが決して見ることのない運用チャネルに分散されていることになる。

委任は証明書市場における偶然ではない。登録局、再販業者、エンタープライズワークフロー、自動発行パスは、証明書発行がスケールしなければならないために存在する。すべての証明書リクエストが特注のセレモニーとして処理されるなら、Web は機能しない。しかし、スケールはガバナンスの単位を変える。CA はルート秘密鍵を守る責任だけでなく、ブラウザによって証明書が信頼される発行面に対しても責任を負う。その表面には、パートナーアカウント、ロール権限、ドメイン検証ワークフロー、異常検出、高価値ドメインゲート、監査記録、緊急失効、公開開示、ルートプログラム報告が含まれる。

影響を受けた名前は問題を明白にした。ログインエンドポイント、メールエンドポイント、またはブラウザ拡張機能宛先の証明書は、ルーティング制御、ローカルネットワーク制御、DNS 妨害、マルウェア、キャプティブポータル、国家レベルのネットワークアクセスと組み合わされると、フィッシングや中間者攻撃を支援する可能性がある。証明書はファイルであるため危険なのではない。ブラウザとユーザーが意図したサイトとして受け入れる可能性のある暗号 ID を不正な者が提示できるようにするため危険なのである。不正な者はドメインの評判とルートストアの信頼を借りることができる。

これが、直接の障害が証明書発行であったにもかかわらず、このインシデントが DNS 委任権限に属する理由である。DNS と TLS は別々のシステムだが、ユーザーはそれらをインターネット上の自分がどこにいるかという主張として一緒に経験する。DNS はユーザーをアドレスに向けることができる。TLS は、そのエンドポイントが名前のために話すことを許可されているかどうかをブラウザに伝える。弱い管理を通じて証明書発行が委任されると、ドメイン所有者は自身の DNS、サーバー、秘密鍵を変更することなく、実質的なアイデンティティ保証を失う可能性がある。

公共部門の継続性の問題も同じ構造に従う。政府機関、学校、病院、自治体サービスは、通常のブラウザ、管理された証明書ストア、ベンダー運用の TLS エンドポイントに依存することが多い。彼らはすべての CA 委任パスを独立して検査することはできない。重要なログインや更新サービスの証明書が疑わしくなった場合、公共部門の対応は、プラットフォームベンダーが不信を出荷できるかどうか、エンドポイントフリートがそれを受け取るかどうか、検査ゲートウェイが正しく動作するかどうか、管理者はどのユーザーが依然として露出しているかを判断できるかどうかに依存する。したがって、小さな証明書インシデントは、侵害された発行者から購入したことのない組織にとって継続性の問題になる可能性がある。

失効は必要だったが十分ではなかった

Comodo は、不正証明書が発見直後に失効されたと述べた。この事実は重要であり、却下されるべきではない。失効は誤発行後の最初の正式な緊急措置である。問題は、失効がコントロールプレーンであり、魔法の消しゴムではないということである。依拠クライアントはステータスを確認し、CRL または OCSP サービスに到達し、結果を解釈し、結果が利用できない場合に安全に失敗し、攻撃者が証明書を悪用する前にそれらすべてを行わなければならない。実際のクライアント、ミドルボックス、ネットワークはそれほど均一ではない。

Microsoft は勧告で実用的なギャップを説明した。発行者が証明書を失効させ、失効メカニズムにリストした後でも、Microsoft は証明書をローカルの信頼されていない証明書ストアに追加する更新を出荷した。その動きにより、パッチ適用済みの Windows システムでは不信がローカルかつ確定的になった。また、運用上、ライブの失効チェックが完全な執行ストーリーではないことを認めた。攻撃者がステータスチェックをブロックできる場合、クライアントがソフトフェイルする場合、デバイスがオフラインの場合、またはエンタープライズ検査が証明書の動作を変更する場合、失効は最も必要とされる瞬間に弱いシグナルのままになる可能性がある。

Mozilla もブラウザのブラックリスト更新を通じて同じ点を指摘した。ローカルブラックリストは鈍器だが、発行者への成功したネットワークルックアップを必要とせずに機能する。それはエコシステムインシデントをソフトウェアアップデートレースに変える。ブラウザと OS が不信をどれだけ早く出荷できるか、そしてユーザーと企業がどれだけ早くそれを受け取ることができるか。そのレースは説明責任の一部である。CA インシデントは、発行者がデータベースを更新したときに修復されるのではない。現実的な条件下で悪意のある証明書によって依拠者がもはやだまされなくなったときに修復されるのである。

この区別は執行方針にとって重要である。ルートプログラムが発行者が迅速に失効したかどうかのみを測定するなら、緊急不信の下流コストを見逃す。ブラウザチームは証明書リストをトリアージし、ブラックリストロジックを作成または更新し、リリースをテストし、勧告を公開し、ユーザーリスクの質問を吸収しなければならない。OS チームは不信ストアとパッチ配信パスを維持しなければならない。ドメイン所有者は可能性のある使用を監視しなければならない。エンタープライズチームは管理対象クライアントが更新を受け取ることを確認しなければならない。発行者が緊急事態を作り出したが、他の多くの関係者が可視の執行作業を行った。

Certificate Transparency は後に、発行された証明書をドメイン所有者とモニターにとってより観察可能にすることで可視性環境を変えた。それは Comodo 2011を遡及的に解決したわけではなく、失効やローカル不信の必要性を取り除くものでもない。しかし、証明書が迅速にログ記録、監視、挑戦されるべき場合、隠された委任発行パスは受け入れられにくくなる。Comodo の記録は、CT が装飾的な透明性ではない理由を説明している。それは、悪用が不可視の損害になる前に、私的な発行力を公に監査可能にする方法である。

通知は異なる役割を持つ関係者に届かなければならなかった

証明書インシデントにおける通知は、1つのメッセージを1つのオーディエンスに送ることではない。CA は、行動するのに十分な詳細を含めてルートプログラムとブラウザベンダーに通知しなければならない。ブラウザとプラットフォームベンダーは、ソフトウェアアップデートが必要かどうかを説明する言葉でユーザーと管理者に通知しなければならない。ドメイン所有者は、自分の名前が標的になったかどうかを知らなければならない。公共機関と企業は、管理対象デバイス、検査アプライアンス、古いシステムが特別な処理を必要とするかどうかを知らなければならない。セキュリティ研究者は、推測を事実に変えずに主張をテストするのに十分な証拠を必要とする。

Comodo の記録は、当時の Web PKI インシデント基準としては異常に具体的だった。同社は影響を受けた証明書とドメインをリストし、委任されたアカウントパスを指定し、即時失効を主張し、ルートキーの境界を区別し、後のブロックされた侵入試行後にレポートを更新した。Mozilla と Microsoft は独自の勧告を公開した。この階層化は、単一のアクターが全オーディエンスを持っていなかったため重要である。CA レポートはルートプログラムとセキュリティチームに有用である。ブラウザ勧告はブラウザユーザーに届く。Windows 勧告はプラットフォーム管理者に届く。ドメイン所有者と公共部門チームは多くの場合、それらすべてを必要とする。

良い通知はまた、証拠と保証を分離しなければならない。CA インフラと HSM キーが侵害されていないと Comodo が言うことは、チェーン内のすべての証明書について過度に広範なパニックを防ぐため有用である。委任された発行が失敗したと言うことも必要である。そうでなければ、ユーザーと購入者はルートキー盗難の欠如が信頼システムが機能したことを意味すると推測する可能性がある。正しいメッセージはより狭く、より深刻である。数学的ルートは安全なままである可能性がある一方、管理上の発行エッジが不正なアイデンティティを生成したのである。

公共部門の継続性はその精度に依存する。政府ネットワークチームは、9つの不正証明書が存在したからといって、国内のすべての証明書を交換する必要はない。しかし、ブラウザと OS が関連する不信更新を持っているかどうか、高リスクユーザーが敵対的なネットワークを通じて露出した可能性があるかどうか、証明書検査ツールがプラットフォームの不信を尊重するかどうか、更新のない古いデバイスが脆弱なままかどうかを知る必要がある。漠然とした安心は運用麻痺を生み出す。特定の証明書シリアル、ドメイン、更新チャネル、および残りの未知数は行動を生み出す。

この通知問題は執行問題でもある。公開記録に証明書の詳細が欠けている場合、ブラウザベンダーは迅速に執行できない。ルートプログラムが私的な保証を受けるが、公開側がほとんど見えない場合、信頼は不透明になり、疑惑が高まる。ドメイン所有者がニュースから知り、直接チャネルからではない場合、時間を失う。Comodo のインシデントはしたがって証拠ルーティングに関する警告である。行動しなければならないすべての関係者は、インシデントが封じ込められたと見なされる前に、正しい形で正しい事実を必要とする。

ルートストアは公共の結果を伴う私的なプログラムである

インシデントはまた、ルートストアのガバナンスの役割を露呈した。ユーザーは自分で信頼できる認証局のリストを構築しない。ブラウザと OS ベンダーがそのリストを出荷する。信頼の決定は、銀行、医療、教育、公共サービス、エンタープライズアクセス、個人通信に使用されるソフトウェアにプレロードされている。それは私的なルートプログラムに公共インフラの結果を与える。彼らは CA に対する信頼を継続し、制約し、不信し、または是正を要求することができ、各オプションは可用性とセキュリティのコストを伴う。

インシデント後の信頼継続は免除ではない。それは将来を見据えたリスク決定である。ルートプログラムは、発行者が問題を検出し、証明書を失効させ、十分に開示し、管理を修正したと判断するかもしれない。また、パターンが許容できないリスクを明らかにすると判断するかもしれない。いずれにせよ、決定は証拠に基づくべきである。委任発行の失敗は、パートナーインベントリ、アカウント認証、高価値名管理、異常検出、インシデント対応、外部監査、再発防止に関する質問を生み出すべきである。

不信のコストは現実的である。主要な CA をルートストアから削除すると、ウェブサイト、エンタープライズアプリケーション、公共ポータル、組み込みシステム、古いデバイスが壊れる可能性がある。そのコストはルートプログラムを慎重にさせるかもしれない。しかし、誤った信頼のコストも現実的である。ユーザーは、通常のセキュリティトレーニングが指示するすべてを行っていても、傍受やフィッシングにさらされる可能性がある。成熟したガバナンスは、演劇的な罰と歯のない寛容の両方を避けなければならない。期待を公開し、有用なインシデントレポートを要求し、是正を追跡し、執行を十分に予測可能にして、ユーザーが害される前に CA が改善できるようにすべきである。

現在の CA/Browser Forum 要件、Mozilla ポリシー、Chromium ポリシー、Apple プログラム資料、Microsoft 要件、CCADB 調整はすべて、2011年よりも明示的なガバナンス環境を表している。それらは、1つの古い管理が現在の条項の1つに違反したという遡及的な証明として誤用されるべきではない。それらの関連性は将来的である。エコシステムがブラウザ信頼を恒久的な評判ではなく条件付き運用信頼として表現することを学んだことを示している。

顧客にとって、実用的な教訓は、CA が委任発行をどのように管理し、修復をどのように証明するかを尋ねることである。公共部門の購入者にとって、この質問は調達と継続性計画の一部であるべきである。認証局は機関から数層離れたサプライヤーであるかもしれないが、その失敗は依然として認証、ソフトウェア配布、市民サービスに影響を与える可能性がある。サーバーをカバーするが証明書信頼をカバーしない継続性計画は不完全である。

執行記録は検証可能であるべきである

最も強力なインシデント後の記録は、秘密を公開する必要はない。影響を受けた証明書シリアル、正確な失効時間、ステータスサービスの可用性、ブラウザとプラットフォームの不信ステータス、委任アカウント特権が制約された証拠、追加された高価値ドメイン管理、レビューされたパートナーアカウント、通知されたルートプログラムを示すべきである。また、観察されたことと推測されたことを区別すべきである。Comodo はこれらの事実のいくつかを提供したが、他の事実は非公開のままであるか、ベンダーチャネルに分散されたままだった。

検証可能な修復が標準である理由は、証明書信頼がほとんどのユーザーにとって不可視だからである。ログインページを訪問する人は、不正証明書が5分前に失効されたかどうか、自分のブラウザがブラックリストを受信したかどうか、エンタープライズプロキシが奇妙な失敗動作を持つかどうかを知ることができない。彼らはシステムに依存することしかできない。したがって、システムは執行が重要なエンドポイントに到達したという証拠を彼らに提供する義務がある。

現代の CA インシデントのための有用な説明責任ダッシュボードには、証明書数、影響を受けた名前、発行パス、検証方法、発見までの時間、失効までの時間、ブラウザ通知までの時間、CT ログの可視性、ステータスサービスの動作、ルートプログラムインシデントチケットステータス、パートナーアカウントの是正、再発防止管理が含まれる。目的は公開辱めではない。緊急事態が発表から執行に移行したかどうかを依拠者が判断する方法を提供することである。

Comodo のインシデントはまた、組織が「サードパーティ」リスクをどのように考えるかを変えるべきである。ドメイン所有者は侵害された CA と契約したことがないかもしれないが、その CA からの証明書は、ブラウザがチェーンを信頼する場合、ドメインを偽装する可能性がある。これは異なる種類のサプライヤーエクスポージャーである。トラストストアへの包含は、Web 全体の共有サプライヤープールを作成する。ドメイン所有者は、CT 監視、CAA レコード、インシデント連絡先、迅速なエスカレーションを通じてリスクを減らすことができるが、公共トラストエコシステムから完全にオプトアウトすることはできない。

結論は、Comodo イベントが委任された権限の説明責任テストであったということである。攻撃者が侵入を引き起こした。発行者は委任モデルと最初の修復ステップを管理した。ブラウザと OS ベンダーはユーザーへの執行を管理した。ルートプログラムは継続的信頼を管理した。公共および私的な依拠者は、直接観察できないリスクを負った。成熟した Web PKI 記録は、それらの役割のすべてを可視化しなければならない。

執行は単一の失効イベントではなく、チェーンである

証明書インシデント対応は、発行者が修正全体を所有しているかのように説明されることが多い。発行者は証明書を失効させ、レポートを公開し、イベントは終了したとして扱われる。Comodo の記録は、なぜそのモデルが小さすぎるかを示している。執行は、互いに運用上独立したいくつかの層を通過しなければならなかった。Comodo は失効と通知ができた。Mozilla はブラウザのブラックリストを出荷できた。Microsoft は Windows の信頼されていないストアを更新できた。ルートプログラムは継続的信頼を評価できた。ドメイン所有者は自分の名前を監視できた。企業は管理対象デバイスにパッチを適用できた。公共部門ネットワークは、古いクライアントや検査デバイスがまだ証明書を受け入れているかどうかを確認できた。目標が実用的なユーザー保護である場合、これらのステップのどれもオプションではなかった。

チェーン構造は、「迅速な対応」の意味を変える。Comodo が失効ボタンをクリックしたり OCSP を更新したりした時間を尋ねるだけでは十分ではない。より良い質問は、現実的なクライアント上のリスクのあるユーザーがいつ不正証明書に対して保護されたかである。そのユーザーは、パッチ適用が遅れた企業マシン、公共図書館のコンピュータ、古い OS、ロックダウンされた機関ワークステーション、プラットフォームトラストストアに依存するモバイルデバイスにいる可能性がある。CA 検出からエンドポイント不信までの経過時間が実際の執行ウィンドウである。公開記録は、Comodo、Mozilla、Microsoft の資料を通じてそのウィンドウの一部を提供するが、単一の統合されたエンドポイント保護メトリックは提供しない。

その欠如は珍しいことではない。Web PKI インシデントは設計上分散されている。ブラウザベンダーは、どのユーザーがいつ更新を受信したかを常に把握しているわけではない。CA は失効ステータスを知っていても、エンドポイント執行を知らないかもしれない。ドメイン所有者は CT ログや OCSP トラフィックを見ても、すべての試行された傍受を見るわけではない。しかし、完全な可視性の欠如は、有用な指標の欠如を許すべきではない。ルートプログラムと CA は、証明書シリアル、失効時間、開示時間、ブラウザ通知時間、CT ログ参照、影響を受けた検証パス、是正カテゴリを公開することができる。それらの指標により、依存組織は自身のリスクウィンドウが依然として開いているかどうかを判断できる。

執行チェーンはまた、ローカル不信メカニズムのポリシー理由を生み出す。ライブの失効チェックは、ステータスサービスに到達するのに十分に正直に動作するネットワークに依存する。中間者シナリオでは、その前提は脆弱である。ローカル不信ストア、ブラウザブラックリスト、ハードフェイル動作はすべて、それ自体が攻撃下にある可能性のあるネットワークパスへの依存を減らす方法である。Comodo イベントはこれを具体化した。Microsoft の勧告は CRL と OCSP の制限について議論し、それでもプラットフォーム不信更新を出荷した。これは、失効が必要なシグナルであるが十分な執行ではないという実用的な告白である。

公共部門の継続性にとって、このチェーンはリハーサルされなければならない。機関はしばしばパッチウィンドウ、互換性テスト、レガシーシステム、証明書検査アプライアンスを持つ。緊急のブラウザまたは OS 不信更新はそれらのプロセスと衝突する可能性がある。更新が遅れると、機関は露出を拡大しながらアプリケーション互換性を維持するかもしれない。急がれると、古いサービスを壊すかもしれない。適切な準備はパニックではなく、インベントリである。どのエンドポイントがブラウザ更新を自動的に受信するか？どのシステムが組み込みトラストストアに依存するか？どのプロキシが TLS を終端するか？どの公開サービスが不正証明書を監視されているか？誰が緊急トラストストア更新を承認できるか？これらの質問は、次の証明書インシデントの前に存在すべきである。

委任発行はパートナーセキュリティを公共インフラに変える

侵害された RA アカウントは、単なる内部アクセス制御の失敗ではなかった。それは、パートナーが実質的な発行権限を持つ場合、パートナーセキュリティが公共インフラになり得ることを示すデモンストレーションであった。再販業者または登録局は経済的に CA の下流にあるかもしれないが、そのアカウントは世界中の依拠者ソフトウェアに証明書を受け入れさせることができる。その非対称性は、CA がパートナーを管理する方法を変えるべきである。パートナーオンボーディング、認証強度、最小特権、発行制限、高リスク名レビュー、異常検出、オフボーディングは、バックオフィスの詳細ではない。それらは信頼製品の一部である。

高価値名は特別な扱いを必要とする。小さな顧客によって管理されるドメインの日常的な証明書は、主要な Web メール、アイデンティティ、ソフトウェア配布、またはブラウザ拡張機能エンドポイントの証明書と同じリスクではない。Comodo の証明書リストはその違いを示している。委任されたアカウントが、通常の関係のない世界的に敏感なブランドの証明書を突然要求した場合、それは追加のレビューをトリガーするべきである。管理はいくつかの形を取ることができる。プリロードされた高リスク名リスト、ブランド所有者の事前承認、ドメイン所有者の確認、手動レビューまでの発行遅延、パートナー固有の制限、CA セキュリティチームへのリアルタイムアラート。正確な設計は異なる可能性があるが、このようなインシデントの後、差別化されたリスク処理の欠如を擁護するのは難しい。

委任発行はまた、監査の問題を提起する。年次監査とコンプライアンス声明は、中央 CA システムに焦点を当て、パートナーアカウントが広範な運用権限を持っている場合、生きたリスクを見逃す可能性がある。有用な監査は、委任されたアカウントをサンプリングし、それらに付随する発行権限をレビューし、高リスクドメイン管理をテストし、認証要件を検査し、監視カバレッジを検証し、最近の異常なリクエストを調査する。また、パートナーアカウントの緊急無効化が迅速に機能するかどうかを確認する。Comodo によって記述された3月26日のブロックされた試みは、攻撃者が委任されたエッジに戻ってきたことを示唆するため重要である。インシデント後の管理は、単一のアカウントを修復するだけでなく、繰り返しの圧力に耐えなければならなかった。

公開市場は、委任発行が購入者にとってほとんど不可視であるため、関心を持つべきである。ウェブサイト所有者は、価格、自動化、サポートに基づいて CA を選択するかもしれず、すべての委任チャネルのセキュリティ態勢に基づいて選択するわけではない。ユーザーにはさらに選択肢が少ない。したがって、ルートプログラムは、ポリシー、インシデントレポートの期待、繰り返される管理の弱さに対する結果を通じて規律を強制できる最も有力な関係者である。CA/Browser Forum、Mozilla、Chromium、Apple、Microsoft、CCADB エコシステムは、信頼が個々の購入者レベルを超えて統治されなければならないために存在する。

この教訓には建設的なバージョンがある。委任は、スコープが設定され監視される場合、安全であり得る。自動化は、ドメイン制御が強力に検証される場合、証明書展開を改善できる。再販業者は、その権限が制約され監査される場合、顧客にうまくサービスを提供できる。Comodo インシデントは、すべての委任チャネルが本質的に無謀であるという議論として読まれるべきではない。それは、公的に信頼された証明書を生成できる場合、委任発行が公共の信頼機能として扱われなければならないという証拠として読まれるべきである。

より強力な現代の事後分析に含めるべきもの

Comodo のようなインシデントの現代の事後分析は、単純な証拠表から始まるだろう。証明書シリアル、サブジェクト名、発行チェーン、発行タイムスタンプ、失効タイムスタンプ、CT ログステータス、検証方法、委任アカウントまたはチャネル、発見源、ブラウザ通知時間、既知の使用証拠。その表は秘密を暴露しない。ドメイン所有者、ブラウザベンダー、研究者、企業が最初の運用上の質問に答えることを可能にする。どの信頼オブジェクトが存在し、いつ、それらを無効化するために何が行われたか？

第二層は、攻撃者の手法を有用な範囲を超えて開示することなく、管理の失敗を説明するだろう。委任アカウントは単一要素認証で保護されていたか？任意のドメインを要求することが許可されていたか？高価値ドメインはフラグされていたか？監視は外部通知の前に異常な発行を検出したか？発見後にパートナー特権は削減されたか？同様のパートナーアカウントはレビューされたか？どの管理が現在同じパスを防いでいるか？これらは罰的な質問ではない。修復の質問である。回答が非公開のままである場合、部外者は一回限りのアカウント侵害と体系的な委任権限の弱さを区別できない。

第三層は、エコシステムの執行を測定するだろう。Mozilla、Microsoft、Apple、Chromium、およびその他の関連するルートまたはプラットフォームプログラムはいつ通知されたか？どの更新または不信メカニズムが出荷されたか？CA は失効応答者が十分な容量と正しいステータスを持っていることを確認したか？OCSP と CRL 応答は、失効後の試行された使用について監視されたか？ドメイン所有者は直接通知を受けたか？公共部門と企業管理者に実行可能なガイダンスが提供されたか？証明書インシデントは、不信を執行できる関係者がそうするのに十分な証拠を持つまで修正されない。

第四層は、残存リスクに正直に対処するだろう。公開記録が大量使用を示さない場合は、そう言う。1つの証明書のみがライブで観察された場合は、そう言い、観察方法を説明する。OCSP トラフィックが失効後の使用を示さなかった場合は、OCSP を可視性メカニズムとしての限界に留意しながらそう言う。敵対的なネットワーク上のユーザーが更新前に証明書を受け入れたかどうかについて未知数がある場合は、それも言う。成熟した保証は不確実性の否定ではなく、何が未知のままであるかの規律ある命名である。

最後に、事後分析はインシデント学習をガバナンスに結び付けるだろう。どのルートプログラム要件が変更されたか？どのパートナー管理が変更されたか？どの検出ルールが現在高リスク名をキャッチするか？どの監査がそれらの変更を検証するか？どのメトリクスがリーダーシップによってレビューされるか？そのガバナンス層がなければ、インシデントは歴史的な逸話になる。それがあれば、インシデントは次の委任発行失敗のための再利用可能な管理マップになる。

証明書信頼に関する読者の決定

読者は、証明機関が注意すべきという漠然とした教訓を得て Comodo の記録を離れるべきではない。実行可能な決定はよりシャープである。公開 TLS に依存するどの組織も、自分が選択しなかった CA によって発行された場合でも、自分のドメインの不正証明書をどのように発見し対応するかを知るべきである。それは、Certificate Transparency ログの監視、最新のセキュリティ連絡先の維持、適切な場合の CAA の使用、CA およびブラウザベンダーへのインシデントエスカレーションのテスト、およびトラストストアの緊急事態によって影響を受ける内部システムの把握を意味する。

証明書サービスの購入者にとって、質問は価格と自動化を超えるべきである。委任アカウントはどのように認証されるか？再販業者と RA の特権はスコープ設定されているか？どの高価値名が追加のレビューを必要とするか？誤発行後にどの証拠が提供されるか？ルートプログラムはどのくらい迅速に通知されるか？失効サービスはどのように監視されるか？失効が十分でない場合のブラウザ不信のテスト済みパスは何か？これらの質問は、証明書がカレンダー上の更新ではなくアイデンティティインフラとして理解されれば、通常のサプライヤーガバナンスの質問である。

ルートプログラムにとって、Comodo イベントは、公開信頼が条件的かつ証拠に基づくべきであるというリマインダーであり続ける。CA は1つのインシデントに迅速に対応できるが、それでもパートナー権限のより深いレビューを必要とするかもしれない。執行はケースバイケースで即興的であるべきではなく、公開ポリシー、インシデントレポートの期待、再発証拠に結び付けられるべきである。公衆はすべての機密監査詳細を必要としないが、委任発行がインシデント後により安全かどうかを知るのに十分なパターンを必要とする。

公共部門の運用者にとって、決定は継続性志向である。機関のブラウザ、プロキシ、モバイルデバイス、レガシーシステムは、緊急証明書不信更新を十分迅速に受信するか？管理者は、不正証明書が機関サービスに関連していたかどうかを特定できるか？信頼された証明書が疑わしくなった場合にユーザーと通信する方法はあるか？公共機関は Web PKI 全体を検査できないが、ローカル対応面を準備することはできる。

したがって、Comodo インシデントはまだ現在進行形である。なぜなら、信頼の抽象化を運用上の質問に変えるからである。誰が発行できるか？誰が見ることができるか？誰が失効できるか？誰が執行できるか？執行が到着したことを誰が証明できるか？これらの質問に答えられない組織は、次の証明書信頼障害の準備ができていない。

1つの最後の実用的なテストは、組織が証明書信頼の所有者を指名できるかどうかである。答えが調達、インフラ、セキュリティ運用、Web エンジニアリング、法務に分割され、インシデント所有者がいない場合、Comodo スタイルのイベントは即興で処理される。所有者はすべてのルートプログラムを管理する必要はないが、証拠が CT モニターから CA 連絡先、ブラウザベンダー、エンタープライズエンドポイントにどのように移動するかを知らなければならない。その所有権が、失効を表明としてではなく保護として区別するものである。

同じ所有者は、高価値名のための証拠プレイブックを維持すべきである。プレイブックは、どのドメインが監視されているか、どの名前が通常の委任発行に敏感すぎるか、どの CA アカウントが承認されているか、どの連絡先が失効を要求できるか、CA の対応が十分でない場合に通知すべきブラウザルートチャネルを指定すべきである。また、事後証拠を保存すべきである。証明書がいつ出現したか、ドメイン所有者がいつ知ったか、CA がいつ失効したか、プラットフォーム更新がいつ到着したか、執行が届く前にどのユーザーが依然として受け入れていた可能性があるか。Comodo の記録は、その詳細が重要である理由を示している。不正な証明書は秒単位で数えることができるが、そのリスクは可視性、通知、執行、および同じ委任パスが閉じられたという信頼を通じて測定される。

結論

説明責任の基準は、実用的な管理と公開証拠の結合である。最も強力な記録は、すべてのアクターがすべての結果を管理したふりをしない。誰が失敗を防ぐことができたか、誰がそれを検出できたか、誰が爆発半径を制限できたか、誰が影響を受ける関係者に通知できたか、誰が信頼関係を修復できたか、修復が依存していたシステムと人々に届いたことを証明する証拠は何かを特定する。