主要領域
セキュリティ
主要領域 の観点では、「セキュリティ」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
IETF
証明が通ったあと、ラベルの責任は誰に残るのか
鍵透明性は、ディレクトリの応答が履歴と整合することを証明できる。しかし、変更権限、検索の根拠、後日の監視責任までは決めない。IETF の最新レビューは、暗号学の成功表示の背後に残る役割の空白を突いた。
インターネット史
「G & R for Security Incident Processing」— ガイダンスは執筆組織より長く生きる
1998年に公開されたコンピュータセキュリティインシデント対応の期待水準を定める RFC 2350(BCP 21)は、今日に至るまで現行のベストカレントプラクティスであり続けている。しかし、その文書を生み出した IETF ワーキンググループ「GRIP」は2001年12月に終了している。本稿は、インシデント処理に関する制度的期待を誰が所有し、その執筆組織が存在しなくなった今、検証可能性と是正がどこで担保されるのかを、一次記録のみに基づいて検証する。
ケースファイル
値は同じだった。再構成したバイト列は一致しなかった
署名側と検証側が表示した CBOR マップは、キーも値も同一だった。それでも署名入力のハッシュは違った。攻撃者が値を書き換えたのではない。二つのエンコーダーが、規格上許された別々の表現を選び、プロトコルがその選択を未定のまま残していた。欠けていたのは、正確なバイト列を誰がどう決めるかという合意だった。
ケースファイル
証明は結び付かなかった。それでも封筒が同じ人を示した：BBS署名
BBS の証明値だけを比べれば、二つの提示が同じ署名から作られたとは分からない。ところが、同じ希少なヘッダー、十個というメッセージ数、同じ開示インデックス、十二人にしか配られていない署名者鍵が外側に残っていた。暗号は約束を守った。「提示全体も追跡不能だ」と読み替えた運用が境界を越えた。
ケースファイル
`co` は登録された。ハンドシェイクで使われたとは限らない：RFC 9952
二文字に短縮した理由は、制約の厳しいリンクでフラグメントを一つでも減らすためだった。しかし短い識別子が IANA 表に載ったことと、実際の ClientHello に載ったことは別である。RFC 9952は、その差を埋める規則をあえて書かなかった。
ケースファイル
AEGISという名は同じでも、再利用規則は役割で変わる：RFC 10032
テストベクトルのダッシュボードはすべて緑だった。ところが障害時のトレースには、どの API がどのバイトを返したかが残っていない。暗号コアの一致は確認できても、タグを捨てたストリームなのか、検証後の平文なのか、再利用例外を持つ MAC なのかは証明できなかった。
IETF
IDMEFv2の204は受領証になるが、再送の意味までは決めない
アラートを保存した直後に応答経路だけが切れたら、送信側には失敗、受信側には成功が残る。IDMEFv2 の HTTPS ドラフトは2xx を堅い受領証に近づけた。次の POST を重複と見るかは、連合側の仕事である。
ケースファイル
署名は検証できた。それでも承認者は分からない：RFC 9591
障害後に残ったのは、対象メッセージ、グループ公開鍵、そして有効な Schnorr 署名だけだった。署名能力がしきい値を超えて使われたことは分かる。だが、どのメンバーが参加し、何を確認し、どの権限で同意したかは復元できない。RFC 9591の FROST は複数の署名シェアを一つの通常署名へ畳み込む。帰属を必要とする組織は、その前段の証拠を別に保持しなければならない。
ケースファイル
EdDSA対応と書いてあっても、曲線はまだ決まっていなかった：RFC 9864
能力表に同じアルゴリズム名が並んでも、同じ処理を実行できるとは限らない。`EdDSA` だけでは Ed25519 と Ed448 のどちらを扱えるか分からないからだ。RFC 9864は曲線とハッシュを含む名前へ進める。だが新しい名前は、実装や有効化、鍵の拘束、相互運用の成功まで保証しない。
ケースファイル
バックアップは鍵と一緒に昨日の状態まで戻した：RFC 9802
復旧した署名装置が正しい秘密鍵を持ち、有効な署名を返した。それだけでは復旧成功とは言えない。別の装置が同じワンタイム索引をすでに使っていれば、検証に通る二つの署名が安全性の前提を壊す。RFC 9802は X.509 に HSS と XMSS を識別させるが、署名者の状態履歴までは証明しない。
IETF
送る前の言葉は誰のものか――RFC 9787の下書き暗号化とコミットメント境界
これは仮想の場面だ。一台の端末で書きかけた文章が自動保存され、数分後、別の端末で同じメールボックスを開くと、その続きが現れる。しかし、その同期が成功したからといって予定受信者が文章を読めるわけではないし、著者が書かれた内容にすでに責任ある意思表示をしたことにもならない。RFC 9787 が下書き暗号化について引く重要な線は、まさにこの途中状態にある。保存と送信は同じメッセージの前後ではあっても、権限、可視性、そしてコミットメントの状態は同じではない。
北米のクラウドサービストレンド
CISA の是正期限経過、PaperCut が緊急パッチから保守ビルドへ移行
PaperCut の新しい保守ビルドで管理者はバージョン記録を明確にできるが、サイトサーバーとセカンダリサーバーの確認は引き続き必要だ。
北米のクラウドサービストレンド
悪用されている ScreenConnect の脆弱性、CISA の修正期限が経過
ConnectWise は、脆弱性の影響対象が ScreenConnect のサーバーではなくクライアントだと説明している。事業者は、サポート対象端末全体の更新状況を確認する必要がある。
欧州・中東の機関トレンド
EU のサイバーセキュリティ報告義務が24時間期限から始動
製造業者は調査が完了する前に当局へ通知し、その後、技術的情報が進展するのに応じてより詳しい調査結果や対応状況を報告することが求められる。
IETF
暗号化できた断片が、メール全体を安全にするわけではない：RFC 9787
メール画面は一つでも、その内部には本文、添付、転送されたメッセージ、署名、暗号化層が別々の境界で存在する。RFC 9787 が求める一つの暗号学的サマリーは、この複雑さを隠すための万能印ではない。Crypto Payload を連続して包む層だけを、ひとまとまりとして説明するための表示である。
ケースファイル
五つの表記を通過した同じ対象：RFC 9804で署名されたバイトは何か
RFC 9804 は、SPKI S-expression を人が読む表記、通信向け表現、正規バイト列、実装固有のメモリ構造に分ける。見た目の同一性は証拠の同一性ではない。署名対象と、その後の解釈・認可・実行を示すには、各変換を別々に記録する必要がある。
記事
APNICのハニーネットが記録した127万件は「攻撃」ではなくイベントだ
APNIC 62で示されたダッカ大学の観測は、意図的に公開した1台のサーバーを有力なセキュリティセンサーに変えた。ただし、同じ127万という数字に「攻撃」「攻撃イベント」「イベント」という三つの名前を載せることはできない。
IETF
TLS再ネゴシエーションの修復はプロトコルを直したが、展開記録までは直していない
TLS の再ネゴシエーション問題は、単なる古い暗号方式の欠陥ではなかった。同じ接続上で続けて行われるハンドシェイク同士を暗号学的に結び付ける仕組みがなかったため、攻撃者が先に置いたアプリケーションデータの前に、別の利用者の認証コンテキストを接続できた。RFC 5746はその境界を修復し、TLS 1.3は再ネゴシエーション自体を廃止した。しかし、仕様の公開は、稼働中の全経路が修復済みだという証明ではない。
IETF
Transform は合意された。それでも replay はまだ拒否されていない：RFC 9827
RFC 9827 は、IKEv2 の Transform Type 5 を ESN の有無という狭い選択から、シーケンス番号の性質を表す契約へ広げた。その契約が示すのは SA のパケットがネットワークへ入る時点までであり、受信側の anti-replay 方針や実際の破棄結果までは保証しない。
IETF
ログ行は解析できた。しかし接続を読む権限は証明されていない：RFC 9850
RFC 9850 は TLS の診断用シークレットに共通の書式を与えた。小さな文法が大きな観測能力を運ぶからこそ、構文、許可、保管、利用、廃棄を一つの「デバッグ」に畳み込んではならない。