サイバーセキュリティ新聞

OHA Shinbun
  • 0.0 (0)
  • Technology
  • Weekly

サイバーセキュリティ新聞 サイバーセキュリティ、AI、情報戦、国家安全保障、インフラ防衛、認知戦、OSINT、ランサムウェア、サプライチェーンリスクを、政策・経営・技術の交差点から整理・解説する音声メディアです。 本番組では、国内外の一次資料、公的機関レポート、政府発表、技術文書、研究論文、OSINT（公開情報分析）などをもとに、 ランサムウェア ゼロトラスト AIとサイバー防衛 ダークウェブ 国家支援型攻撃（APT） インフラ・OTセキュリティ サプライチェーン攻撃 偽情報・認知戦 半導体・通信・クラウド ドローンと電子戦 サイバー政策・制度設計 SOC / CSIRT / フォレンジック 経済安全保障 地政学とテクノロジー などを、非技術者にも分かるよう構造化して解説します。 「技術そのもの」だけではなく、 なぜ事故が起きるのか なぜ組織は止まるのか なぜ投資されないのか なぜサプライチェーンが弱点になるのか AIが社会・行政・安全保障をどう変えるのか といった、「経営・政策・組織・社会構造」まで含めて扱います。 対象リスナーは、 省庁・自治体関係者 インフラ事業者 経営層 リスク管理部門 セキュリティ担当者 報道・政策関係者 AI・IT業界 サイバー安全保障に関心のある一般リスナー です。 本番組は、防御・教育・制度理解・リスク管理・社会啓発を目的としています。

  1. 1d ago

    実録編#14丨HTTP2Shellとは何か——Brotliの重大脆弱性・Node.js・ソフトウェア更新の盲点

    外部から直接侵入できない社内システムでも、危険なデータを自ら取得した瞬間、攻撃を受ける可能性があります。 本エピソードでは、2026年10月に公表された重大な脆弱性「HTTP2Shell（Node2Shell／CVE-2026-111497）」を取り上げ、Brotliの圧縮データ展開処理に潜む欠陥、Node.jsなどへの影響、リモートコード実行の危険性、そして企業が直面するパッチ適用と運用管理の難しさについて解説します。 取り上げる主なテーマ - HTTP2Shell・Node2Shellとは何か - CVE-2026-111497 - Google Brotliとデータ圧縮 - HTTP/2とHTTPSの違い - 境界外書き込み（CWE-787） - バッファオーバーフロー - リモートコード実行（RCE） - メモリ破損と情報漏洩 - Node.jsの脆弱性とセキュリティ更新 - Impervaによる攻撃実証 - CISAの悪用確認済み脆弱性（KEV） - 外部からのリクエストと内部からのデータ取得 - URLプレビュー・API通信を通じた攻撃経路 - HTTPSによる暗号化の限界 - AWS Lambdaとクラウドの責任共有モデル - Dockerコンテナと再ビルド - ソフトウェアの多層的な依存関係 - SBOM（ソフトウェア部品表） - VEX（脆弱性影響説明） - CVSSと実際の事業リスク - WAFによる防御の限界 - パッチ適用と本番環境での修正確認 - オープンソースの公共インフラとしての役割 今回の問題は、HTTP/2という通信規格そのものの欠陥ではありません。 データを小さく圧縮するBrotliという技術の、圧縮データを元に戻す処理に存在する欠陥です。 攻撃者が細工した圧縮データをシステムに処理させることで、メモリの破損、情報漏洩、異常終了、さらには不正なプログラムの実行につながる可能性があります。 しかも危険なのは、外部から直接サーバーへ攻撃される場合だけではありません。 社内のチャットツールがURLのプレビューを取得する。 業務システムが外部APIからデータを受け取る。 自動処理プログラムがWebサイトへアクセスする。 こうした日常的な処理の中でも、攻撃者が用意した圧縮データを読み込めば、脆弱性に到達する可能性があります。 ファイアウォールで外部からの侵入を防いでいても、内部システムが自ら危険なデータを取得する経路は残り得るのです。 さらに、HTTPSで通信を暗号化していても、その通信で受け取ったデータ自体が安全とは限りません。 今回の事件が浮き彫りにしたのは、もう1つの深刻な問題です。 脆弱性を修正するプログラムが公開されても、それだけでは企業のシステムは安全にならないという現実です。 現代のソフトウェアは、無数の部品が複雑に組み合わされて構築されています。 開発者が直接Brotliを使っていなくても、Node.jsや各種フレームワーク、通信ライブラリ、コンテナの内部に組み込まれている場合があります。 そのため、最初に必要なのは、自社のどこに問題の部品が存在するのかを把握することです。 SBOMで構成部品を可視化し、VEXなどの情報も参考に実際の影響を判断する。 次に、攻撃者が制御するデータが脆弱な処理へ到達するかを確認する。 そして影響を受ける環境について、修正版への更新、アプリケーションの再ビルド、コンテナの再配置、本番環境での適用確認を行う必要があります。 WAFによる遮断は、補助的な防御にはなります。 しかし、内部システムが外部から取得する応答データなど、WAFの監視対象にならない経路もあります。 根本的な修正の代わりにはなりません。 また、脆弱性の深刻度を示すCVSSの点数だけで、企業の優先順位を決めることもできません。 そのシステムはどのデータにアクセスできるのか。 どの業務を動かしているのか。 攻撃された場合、どのような事業損失が発生するのか。 誰が更新し、誰が稼働確認まで責任を持つのか。 これらを含めた判断が求められます。 そして最後に、より大きな問いがあります。 世界中の企業、クラウドサービス、業務システムが、少数の共通したオープンソース部品に依存しています。 その部品に重大な欠陥が発見されたとき、社会全体が膨大な修正コストを負担します。 私たちは、こうしたソフトウェアを道路や橋と同じように、社会を支える共通インフラとして考える必要があるのではないでしょうか。 守るべきものは、単にプログラムの正常動作ではありません。 脆弱性を把握し、影響を判断し、修正を届け、本番環境で確認するという、組織の防御能力そのものです。 HTTP2Shellから、現代のソフトウェア依存とサイバーセキュリティの構造的課題を考えます。

  2. Oct 22

    実録編#13丨PHP祭りより深刻な「証明書祭り」——eMudhra秘密鍵問題とHTTPS信頼基盤の危機

    PHP祭りの裏側で、インターネットの信頼基盤そのものを揺るがす事件が起きていました。 本エピソードでは、2026年10月に発覚したeMudhraの中間認証局（中間CA）秘密鍵問題を取り上げ、PHPの重大な脆弱性との違い、HTTPSの信頼構造、デジタル証明書の偽造リスク、そして第三者監査の限界について解説します。 取り上げる主なテーマ - PHP祭りとは何か - CVE-2026-109618・CVE-2026-109619 - eMudhra中間CA秘密鍵問題 - HTTPSとデジタル証明書 - ルートCAと中間CAの信頼構造 - 公開鍵・秘密鍵の仕組み - P-384楕円曲線暗号 - 秘密鍵の値が「4」だった問題 - 暗号鍵生成時の乱数品質 - TLS証明書とコード署名証明書 - 偽造証明書によるWebサイトのなりすまし - DNS・中間者攻撃 - 証明書透明性（CTログ） - ChromeのCRLSet - FirefoxのOneCRL - Sectigoによる交差署名 - API通信と証明書ストア - Python・Docker・Cloudflareへの影響 - HSMとFIPS 140-2認証 - 第三者監査と実装検証の限界 - 信頼の撤回とサイバーガバナンス PHPの重大な脆弱性は、攻撃者が未修正のサーバーで不正なコードを実行し、データを盗んだり、システムを乗っ取ったりする危険を生みます。 しかしeMudhraの問題は、異なる階層のリスクを突きつけました。 それは、インターネット上で「相手が本物である」と証明する仕組み自体が、偽造に利用できる状態になっていたことです。 今回問題となったのは、8件の中間CA証明書に対応する秘密鍵でした。 本来、極めて大きな乱数から生成されるべきP-384の秘密鍵が、すべて256未満という異常に小さな値になっていました。 そのうちの1つは、なんと「4」。 強力な暗号アルゴリズムを採用していても、鍵の生成過程に重大な欠陥があれば、安全性は失われます。 さらに恐ろしいのは、攻撃者が認証局のサーバーへ侵入する必要すらなかったことです。 公開証明書の情報から、秘密鍵を短時間で再現できる状態だったのです。 これにより、影響を受けた認証局を引き続き信頼するシステムでは、第三者が偽造した証明書を正規のものとして受け入れてしまう危険が生じました。 HTTPSは通信を暗号化します。 しかし、暗号化された通信の相手が本当に正しい相手なのかを確認できなければ、利用者は安全だと信じながら偽のサーバーへ情報を渡してしまう可能性があります。 今回、Google ChromeとMozilla Firefoxは緊急対応を実施しました。 証明書透明性、失効情報の配信、信頼ストアの更新など、複数の防御策が重要な役割を果たしています。 一方で、企業には別の課題があります。 ブラウザが保護されても、独自の証明書ストアを利用するAPI、業務アプリケーション、Dockerコンテナなどが同じ状態とは限りません。 OSをアップデートしただけで、すべての通信が安全になるわけではないのです。 そして、今回の事件が突きつけたもう1つの教訓があります。 認証されたハードウェアを使っていることと、そのハードウェアを通じて作られた成果物が安全であることは、同じではありません。 eMudhraは、FIPS 140-2 Level 3に適合するHSMを利用し、独立監査も受けていたと説明しています。 それでも、弱い秘密鍵の問題は見逃されました。 監査済みだから安全。 暗号化されているから安全。 有名な認証局だから安全。 こうした判断だけでは、十分ではありません。 重要なのは、何を信頼するかだけでなく、信頼の根拠が破綻したときに、その信頼をどれだけ迅速に撤回できるかです。 PHPの脆弱性とeMudhraの秘密鍵問題。 一方はサーバーの安全性、もう一方は通信相手の真正性を脅かす問題でした。 サイバーセキュリティは、侵入を防ぐことだけではありません。 私たちが何を根拠に、誰を信頼しているのか。 その信頼を、誰が検証し、誰が取り消せるのか。 インターネットの信頼基盤と、監査・認証・ガバナンスの本質を考えます。

  3. Oct 10

    インフラ編#08丨クラウド障害はなぜ社会を止めるのか——共通基盤・委託先・BCPのサイバー防衛

    クラウドが止まると、何が止まるのでしょうか。 本エピソードでは、クラウド基盤へのランサムウェア攻撃、委託先経由のシステム障害、APIやSaaSへの依存、そして事業継続の現実を解説します。 取り上げる主なテーマ クラウド基盤へのランサムウェア攻撃 共通基盤が止まるリスク IDCFクラウド事案 複数組織への連鎖影響 単一障害点としてのクラウド 日理物流・入出荷停止の事例 委託先経由のサイバー被害 第一興商・日本コロムビアグループの事例 APIと管理ツールのリスク スカイチケット、NewsPicks事案 Commune、ココナラ事案 システム停止だけでは封じ込めにならない理由 ログ保全と証拠保全 バックアップの独立性 シックス・アパートの復旧事例 大阪公立大学のランサムウェア対応 BCPと手動運用 効率化と冗長性のバランス サイバー攻撃は、もはや「自社のサーバーが侵入されたかどうか」だけの問題ではありません。 自社が直接攻撃されていなくても、利用しているクラウド、委託先、SaaS、API、物流管理システムが止まれば、業務は止まります。 トラックは動く。 倉庫には商品がある。 担当者も出社している。 それでも、出荷指示、在庫確認、配送先情報、顧客連絡先がクラウドの中に閉じ込められていれば、現場は動けません。 現代の企業は、効率化のために多くの業務を共通基盤へ集約してきました。 しかし、その便利さは同時に、巨大な単一障害点を生み出します。 同じクラウドに相乗りする。 同じSaaSに依存する。 同じ委託先にデータ処理を任せる。 同じAPIで複数の業務をつなぐ。 そこが止まれば、自社だけでなく、取引先、顧客、物流、教育、行政サービスまで連鎖的に止まる可能性があります。 重要なのは、システムを守ることだけではありません。 そのシステムが止まったとき、業務をどう続けるのか。 どの業務は何時間まで止められるのか。 どのデータを別環境に保管しているのか。 紙、電話、Excel、人手で代替できる手順はあるのか。 誰が代替運用への切り替えを決めるのか。 サイバーセキュリティは、侵入を防ぐ技術から、事業を止めない設計へと変わっています。 守るべきものは、サーバーではありません。 事業活動そのものです。 効率化を突き詰めた社会が、どこで脆くなるのか。 クラウド障害、委託先侵害、BCPの現実から考えます。

  4. Sep 30

    AI編#16丨ホワイトハウス「White House Accord on Super Intelligence」とは何か——超知能合意・外部評価・AIエージェントの責任分界

    AIに、どこまでの権限を渡してよいのでしょうか。 本エピソードでは、ホワイトハウスで署名された「White House Accord on Super Intelligence」を手がかりに、フロンティアAI企業の責任、外部評価、取締役会監督、そしてAIエージェント時代の権限管理について解説します。 取り上げる主なテーマ - White House Accord on Super Intelligenceとは何か - フロンティアAI企業の自主的コミットメント - 超知能と安全性 - 内部統制 - 内部監視チーム - 独立した外部評価・外部監査 - 取締役会レベルの監督 - AIモデルの能力監視 - サイバーセキュリティとAI - AIが攻撃の道具になるリスク - AIシステム自体が攻撃対象になるリスク - 間接プロンプトインジェクション - 過剰なエージェンシー - AIエージェントへの過剰な権限付与 - ゼロトラスト - アクセス制御ゲートウェイ - モデル単体評価とシステム全体評価 - AIベンダー評価 - ログ・監査証跡・取締役会報告 - NIST CSF 2.0のGOVERN この合意は、AI企業が「安全に取り組んでいます」と宣言するだけの文書ではありません。 重要なのは、AIの能力が上がるほど、モデルそのものだけでなく、AIが接続するツール、API、データ、権限、承認手順まで含めて評価しなければならないという点です。 AIが危険になるのは、悪意を持ったときだけではありません。 人間の指示が曖昧だったとき。 外部資料に悪意ある命令が埋め込まれていたとき。 AIが文脈を読み間違えたとき。 本来不要な送信権限や書き込み権限まで与えられていたとき。 そのとき、AIは正規の権限を使って、想定外の行動を実行してしまう可能性があります。 だからこそ、AIの安全性は「モデルが賢いかどうか」だけでは決まりません。 AIにどのシステムを触らせるのか。 どのAPIを呼び出せるのか。 どのデータを読ませるのか。 どの権限をいつ、どの条件で渡すのか。 暴走したときに、どこで止めるのか。 その記録を、誰が後から検証できるのか。 これらを設計する必要があります。 外部評価を受けたAIだから安全。 有名企業のモデルだから安全。 合意に参加している企業だから安全。 そう考えるのは危険です。 評価されたのは、モデル単体なのか。 ツール連携を含む本番環境なのか。 外部送信権限を持たせた状態なのか。 自社のデータや業務フローに組み込んだ状態なのか。 利用企業側も、そこを確認しなければなりません。 AI時代のセキュリティは、AIに「してはいけない」と言い聞かせるだけでは不十分です。 AIからの要求を無条件に信用せず、システム側で権限を絞り、文脈に応じて実行を止め、ログを残し、取締役会や経営層が是正まで確認する。 超知能合意から、AIエージェント時代のガバナンスを考えます。

  5. Sep 23

    AI編#15丨AIエージェントはデータ基盤をどう変えるのか——データレイクハウス・権限管理・プロンプトインジェクション

    AIエージェントは、企業のデータ基盤をどう変えるのでしょうか。 本エピソードでは、津田通隆氏（Open Data Spaces Chief Architect／IPA AI&データアーキテクチャ戦略室長）によるデータ基盤の技術変遷に関する分析を手がかりに、ビッグデータの3Vから、GFS、MapReduce、NoSQL、JSON、データレイク、データウェアハウス、データレイクハウスまでの流れをたどります。 その上で、AIエージェント時代に、企業のデータ基盤がどのような新しいサイバーリスクを抱えるのかを解説します。 取り上げる主なテーマ - ビッグデータの3V - Volume・Variety・Velocity - Google File System - MapReduce - Hadoop - NoSQL - JSONとXML - データレイク - データウェアハウス - データスワンプ - データレイクハウス - コンピュートとストレージの分離 - Apache Parquet - Apache Iceberg - コントロールプレーンとデータプレーン - データカタログ - AIエージェントとデータ基盤 - ABAC（属性ベースアクセス制御） - 一時的なアクセス権限 - 間接プロンプトインジェクション - RAGとキャッシュ - ゼロコピーアーキテクチャ - AI時代のインシデント対応 この20年、企業はデータを集め、保存し、検索し、分析するための巨大な基盤を作ってきました。 かつての課題は、データの量、多様性、速度でした。 大量のデータをどう保存するか。 画像、動画、ログ、テキストのような非構造化データをどう扱うか。 リアルタイムに発生するデータをどう処理するか。 その結果、企業はデータレイクハウスという巨大な図書館を作り上げました。 しかし今、その図書館の読者が変わろうとしています。 人間のデータサイエンティストではなく、AIエージェントが、膨大なデータを読み、解釈し、APIを呼び出し、外部システムを操作する時代が来ています。 問題は、AIが賢いことではありません。 AIが読んだデータの内容によって、次に何を実行するかを自律的に判断してしまうことです。 メール、PDF、請求書、チャット、社内文書。 そこに悪意ある指示が埋め込まれていれば、AIはそれを業務指示として解釈するかもしれません。 だからこそ、AI時代のデータ基盤では、単にデータを集めるだけでは不十分です。 誰が、いつ、どの目的で、どのデータに、どれくらいの時間アクセスできるのか。 AIには何を読ませてよいのか。 AIが作った提案と、実際のシステム実行をどう分離するのか。 削除したはずのデータが、RAGやキャッシュに残っていないか。 事故が起きたとき、業務状態まで巻き戻せるのか。 AIエージェント時代のセキュリティは、モデルの性能だけでは決まりません。 データ基盤、権限管理、監査ログ、実行承認、インシデント対応を一体で設計できるかが問われます。 巨大な図書館を作った企業は、次に「誰に読ませるのか」「どこまで行動させるのか」を決めなければなりません。 データレイクハウスとAIエージェントの時代に、企業のサイバーセキュリティがどう変わるのかを考えます。 【参考資料】 1. 津田通隆「The 3Vsからデータレイクハウスまでの技術変遷【AIとデータ基盤 #1】」https://note.com/tsuda_michitaka/n/ncc877587ec8c 2. NIST “Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents” (2026)https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai 3. NIST / NCCoE “Accelerating the Adoption of Software and AI Agent Identity and Authorization Concept Paper” (2026)https://www.nccoe.nist.gov/publications/other/accelerating-adoption-software-and-ai-agent-identity-and-authorization-concept 4. OWASP “LLM06:2025 Excessive Agency”https://genai.owasp.org/llmrisk/llm062025-excessive-agency/5. NIST SP 800-207 “Zero Trust Architecture”https://csrc.nist.gov/pubs/sp/800/207/final 6. Databricks “Unity Catalog best practices”https://docs.databricks.com/aws/en/data-governance/unity-catalog/best-practices 7. Apache Polaris “CVE-2026-42809 — Stage-Create Credential Vending”https://polaris.apache.org/community/security-advisories/cve-2026-42809/ 8. AWS IAM “Disabling permissions for temporary security credentials”https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html 9. NIST SP 800-162 “Guide to Attribute Based Access Control (ABAC)”https://www.nist.gov/publications/guide-attribute-based-access-control-abac-definition-and-considerations-0 10. UK NCSC “Prompt injection is not SQL injection (it may be worse)”https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection 11. OWASP “Retrieval-Augmented Generation (RAG) Security Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html 12. OWASP “Transaction Authorization Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html 13. Beurer-Kellner et al. “Design Patterns for Securing LLM Agents against Prompt Injections” (2025)https://arxiv.org/abs/2506.08837 14. OWASP “AI Agent Security Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html 15. NIST SP 800-61 Rev.3 “Incident Response Recommendations and Considerations for Cybersecurity Risk Management”https://csrc.nist.gov/pubs/sp/800/61/r3/final 16. OWASP “Logging Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html 17. NIST “Cybersecurity Framework (CSF) 2.0”https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final

  6. Aug 21

    インフラ編#07丨SPOFとは何か——重要インフラを止める単一障害点と人間依存の罠

    SPOF、つまり単一障害点とは、壊れやすい機械部品だけを指す言葉ではありません。 本エピソードでは、重要インフラに潜むSPOFを、設備・人・権限・認証・通信・ベンダー対応・組織設計の観点から解説します。 取り上げる主なテーマ - SPOFとは何か - 単一障害点 - 重要インフラの停止リスク - 物理的故障だけではないFailure - 侵害されたまま稼働するフェイルアンセーフ - 人間系SPOF - エース担当者依存 - ソフトSPOF - 待ち行列理論と過負荷 - 見せかけの冗長化 - 共通原因障害 - ヒースロー空港の電力障害 - 英国鉄道の復旧遅延 - 水処理施設の仮想シナリオ - 権限・技能・情報・認証・通信・独立性 - 職務代行と自動権限移行 - 代行者単独完遂率 - 権限委譲時間 - AI時代の不可視のSPOF SPOFは、単に「1台しかないサーバー」や「1本しかない回線」の問題ではありません。 車が壊れることより、車の鍵が1つしかないこと。 予備設備があることより、切り替え方法を知っている人が1人しかいないこと。 担当者がいることより、その人しか判断できず、その人しか認証トークンを持っていないこと。 こうした依存関係の集中こそが、重要インフラを止める本当の単一障害点になります。 さらに厄介なのは、人が倒れなくても組織が止まることです。 緊急時に問い合わせが集中し、判断が1人に詰まり、待ち時間が許容時間を超えた瞬間、担当者が生きていても、元気に働いていても、組織は機能停止します。 冗長化も、単に数を増やせばよいわけではありません。 Teamsとメールがあっても、同じ認証基盤に依存していれば同時に死にます。 データセンターが2つあっても、同じ変電所に依存していれば同時に落ちます。 正担当と副担当がいても、同じ権限・同じ鍵・同じ通信経路に依存していれば、代替にはなりません。 本当に必要なのは、同じ原因で同時に失われない設計です。 代行者には、名前だけでなく、権限、技能、情報、認証、通信、時間的・地理的独立性が必要です。 そのうち1つでも欠ければ、代替態勢は機能しません。 強い組織とは、エースが倒れない組織ではありません。 エースが倒れても、権限・情報・認証・技能の連鎖が切れず、別の人が迷わず安全に引き継げる組織です。 重要インフラを止めるのは、壊れた機械だけではありません。 誰が判断するのか。 誰が止めるのか。 誰が鍵を持っているのか。 誰がベンダーに連絡できるのか。 主担当が応答しないとき、何分で権限が移るのか。 SPOFを、機械ではなく組織設計の問題として考えます。

  7. Aug 16

    実録編#12丨暗号戦争とは何だったのか——サイファーパンク、国家監視、バックドア、量子時代のプライバシー

    暗号は、ただの技術なのでしょうか。 本エピソードでは、1990年代の「暗号戦争」から、サイファーパンク、国家監視、バックドア論争、メタデータ、量子コンピューター時代の暗号移行までを解説します。 取り上げる主なテーマ - 暗号戦争とは何か - サイファーパンク - Eric Hughes - Tim May - John Gilmore - Hal Finney - Electronic Frontier Foundation - 法律によるプライバシー保護とコードによる保護 - データ最小化と選択的開示 - 暗号輸出規制 - 40ビット暗号と56ビットDES - Deep Crack - コードは言論か - Clipper Chip - バックドア論争 - 端末・クラウド・認証への攻撃移行 - メタデータの危険性 - Signalとシールドセンダー - 量子コンピューター - 耐量子暗号 - ML-KEM・ML-DSA - プライバシーと捜査のジレンマ サイファーパンクが目指したのは、国家や企業に「プライバシーを守ってください」とお願いすることではありませんでした。 強力な暗号によって、第三者がそもそも情報を読めない構造を作ること。 つまり、法律による保護ではなく、コードと数学による保護を実装することでした。 1990年代、アメリカ政府は強力な暗号を武器のように扱い、民間利用や輸出を制限しようとしました。 しかし、サイファーパンクやEFFは、弱い暗号がどれほど脆いかを実際に破って示しました。 40ビット暗号は短時間で解読され、56ビットDESも専用機によって現実的な時間で破られました。 その結果、暗号を意図的に弱くしておくという発想は後退し、現在ではAESのような強力な暗号が、スマートフォン、銀行取引、メッセージアプリ、クラウド通信に当たり前のように使われています。 しかし、暗号戦争は終わっていません。 暗号そのものが強くなったことで、攻撃者は暗号を正面から破るのではなく、端末、クラウド、認証、バックアップ、人間、そしてメタデータを狙うようになりました。 メッセージの中身が読めなくても、誰が、誰に、いつ、どれくらいの頻度で連絡しているかが分かれば、人間関係や行動パターンは推測できます。 さらに、量子コンピューターの登場によって、現在の暗号方式の前提も揺らぎ始めています。 暗号は善人だけを守り、悪人だけを解除することはできません。 だからこそ、プライバシー、捜査、国家安全保障、サイバー防衛のあいだで、社会は今も難しい選択を迫られています。 「善人だけが使えて、悪人が使ったときだけ政府が解除できる暗号」は存在するのか。 暗号戦争の歴史から、デジタル社会の自由と安全を考えます。

  8. Aug 15

    入門編#24丨脅威モデリングとは何か——攻撃者の行動から逆算するセキュア・バイ・デザイン

    脅威モデリングとは、サイバー攻撃の手口をただ並べる作業ではありません。 本エピソードでは、脅威モデリングとは何か、なぜ経営者や事業責任者に必要なのかを解説します。 取り上げる主なテーマ - 脅威モデリングとは何か - セキュア・バイ・デザイン - 脆弱性診断・ペネトレーションテストとの違い - OWASPの4つの問い - 守るべき資産ではなく「許容できない結果」から考える - 信頼境界（Trust Boundary） - 攻撃者の期待利益 - 金銭目的の犯罪者と国家支援型攻撃者の違い - ランサムウェアと知的財産窃取 - 多層防御 - 残留リスク・残余リスク - CISOと事業責任者の役割分担 - リスク受容のガバナンス - 悪いKPIと良いKPI - STRIDEとチェックリスト化の罠 - 経済産業省・国家サイバー統括室のガイドライン - AI時代の脅威モデリング 脅威モデリングの本質は、未来の攻撃を完璧に予言することではありません。 自社にとって絶対に起きてはいけない結果は何か。 どこに信頼境界があるのか。 誰が、どの目的で、どの経路から攻撃してくるのか。 どのリスクを設計段階で消すのか。 残ったリスクを誰が引き受けるのか。 これらを、システムが完成する前に考えるためのプロセスです。 完成した家の窓や鍵を後から調べるのが脆弱性診断だとすれば、脅威モデリングは、最初の設計図の段階で「泥棒が届かない位置に窓を置く」「火事が広がらない区画を作る」ための作業です。 最新のEDRやゼロトラスト製品を導入しても、構造的な欠陥は後から簡単には直せません。 だからこそ重要なのは、攻撃者の視点から逆算し、事業への影響を基準に設計することです。 金銭目的の犯罪者は、早く利益を得るためにランサムウェアで業務を止めます。 国家支援型の攻撃者は、気づかれないように長期間潜伏し、設計図や知的財産を少しずつ盗みます。 同じ侵入口でも、相手によって必要な防御は変わります。 そして、どれだけ対策しても最後には残留リスクが残ります。 そのリスクを受け入れるのは、CISOだけではありません。 そのシステムで利益を得る事業責任者、経営層が、条件と期限を明確にして引き受ける必要があります。 脅威モデリングは、IT部門だけの作業ではありません。 不確実なリスクに名前をつけ、優先順位をつけ、誰が責任を持って前に進むのかを決めるための、経営の思考技術です。

See All (59)

About

サイバーセキュリティ新聞 サイバーセキュリティ、AI、情報戦、国家安全保障、インフラ防衛、認知戦、OSINT、ランサムウェア、サプライチェーンリスクを、政策・経営・技術の交差点から整理・解説する音声メディアです。 本番組では、国内外の一次資料、公的機関レポート、政府発表、技術文書、研究論文、OSINT（公開情報分析）などをもとに、 ランサムウェア ゼロトラスト AIとサイバー防衛 ダークウェブ 国家支援型攻撃（APT） インフラ・OTセキュリティ サプライチェーン攻撃 偽情報・認知戦 半導体・通信・クラウド ドローンと電子戦 サイバー政策・制度設計 SOC / CSIRT / フォレンジック 経済安全保障 地政学とテクノロジー などを、非技術者にも分かるよう構造化して解説します。 「技術そのもの」だけではなく、 なぜ事故が起きるのか なぜ組織は止まるのか なぜ投資されないのか なぜサプライチェーンが弱点になるのか AIが社会・行政・安全保障をどう変えるのか といった、「経営・政策・組織・社会構造」まで含めて扱います。 対象リスナーは、 省庁・自治体関係者 インフラ事業者 経営層 リスク管理部門 セキュリティ担当者 報道・政策関係者 AI・IT業界 サイバー安全保障に関心のある一般リスナー です。 本番組は、防御・教育・制度理解・リスク管理・社会啓発を目的としています。

Information

You Might Also Like