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

OHA Shinbun

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

サイバーセキュリティ、AI、情報戦、国家安全保障、インフラ防衛、認知戦、OSINT、ランサムウェア、サプライチェーンリスクを、政策・経営・技術の交差点から整理・解説する音声メディアです。

本番組では、国内外の一次資料、公的機関レポート、政府発表、技術文書、研究論文、OSINT（公開情報分析）などをもとに、
ランサムウェア
ゼロトラスト
AIとサイバー防衛
ダークウェブ
国家支援型攻撃（APT）
インフラ・OTセキュリティ
サプライチェーン攻撃
偽情報・認知戦
半導体・通信・クラウド
ドローンと電子戦
サイバー政策・制度設計
SOC / CSIRT / フォレンジック
経済安全保障
地政学とテクノロジー
などを、非技術者にも分かるよう構造化して解説します。

「技術そのもの」だけではなく、
なぜ事故が起きるのか
なぜ組織は止まるのか
なぜ投資されないのか
なぜサプライチェーンが弱点になるのか
AIが社会・行政・安全保障をどう変えるのか
といった、「経営・政策・組織・社会構造」まで含めて扱います。

対象リスナーは、
省庁・自治体関係者
インフラ事業者
経営層
リスク管理部門
セキュリティ担当者
報道・政策関係者
AI・IT業界
サイバー安全保障に関心のある一般リスナー
です。

本番組は、防御・教育・制度理解・リスク管理・社会啓発を目的としています。

Play

Open in

20 episodes
Avg 22 min
Japanese

Episodes 20

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

S4 · E15
Wednesday · 25 min
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
S3 · E7
August 21 · 22 min
インフラ編#07丨SPOFとは何か——重要インフラを止める単一障害点と人間依存の罠
SPOF、つまり単一障害点とは、壊れやすい機械部品だけを指す言葉ではありません。本エピソードでは、重要インフラに潜むSPOFを、設備・人・権限・認証・通信・ベンダー対応・組織設計の観点から解説します。取り上げる主なテーマ - SPOFとは何か - 単一障害点 - 重要インフラの停止リスク - 物理的故障だけではないFailure - 侵害されたまま稼働するフェイルアンセーフ - 人間系SPOF - エース担当者依存 - ソフトSPOF - 待ち行列理論と過負荷 - 見せかけの冗長化 - 共通原因障害 - ヒースロー空港の電力障害 - 英国鉄道の復旧遅延 - 水処理施設の仮想シナリオ - 権限・技能・情報・認証・通信・独立性 - 職務代行と自動権限移行 - 代行者単独完遂率 - 権限委譲時間 - AI時代の不可視のSPOF SPOFは、単に「1台しかないサーバー」や「1本しかない回線」の問題ではありません。車が壊れることより、車の鍵が1つしかないこと。予備設備があることより、切り替え方法を知っている人が1人しかいないこと。担当者がいることより、その人しか判断できず、その人しか認証トークンを持っていないこと。こうした依存関係の集中こそが、重要インフラを止める本当の単一障害点になります。さらに厄介なのは、人が倒れなくても組織が止まることです。緊急時に問い合わせが集中し、判断が1人に詰まり、待ち時間が許容時間を超えた瞬間、担当者が生きていても、元気に働いていても、組織は機能停止します。冗長化も、単に数を増やせばよいわけではありません。 Teamsとメールがあっても、同じ認証基盤に依存していれば同時に死にます。データセンターが2つあっても、同じ変電所に依存していれば同時に落ちます。正担当と副担当がいても、同じ権限・同じ鍵・同じ通信経路に依存していれば、代替にはなりません。本当に必要なのは、同じ原因で同時に失われない設計です。代行者には、名前だけでなく、権限、技能、情報、認証、通信、時間的・地理的独立性が必要です。そのうち1つでも欠ければ、代替態勢は機能しません。強い組織とは、エースが倒れない組織ではありません。エースが倒れても、権限・情報・認証・技能の連鎖が切れず、別の人が迷わず安全に引き継げる組織です。重要インフラを止めるのは、壊れた機械だけではありません。誰が判断するのか。誰が止めるのか。誰が鍵を持っているのか。誰がベンダーに連絡できるのか。主担当が応答しないとき、何分で権限が移るのか。 SPOFを、機械ではなく組織設計の問題として考えます。
S2 · E12
August 16 · 17 min
実録編#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のような強力な暗号が、スマートフォン、銀行取引、メッセージアプリ、クラウド通信に当たり前のように使われています。しかし、暗号戦争は終わっていません。暗号そのものが強くなったことで、攻撃者は暗号を正面から破るのではなく、端末、クラウド、認証、バックアップ、人間、そしてメタデータを狙うようになりました。メッセージの中身が読めなくても、誰が、誰に、いつ、どれくらいの頻度で連絡しているかが分かれば、人間関係や行動パターンは推測できます。さらに、量子コンピューターの登場によって、現在の暗号方式の前提も揺らぎ始めています。暗号は善人だけを守り、悪人だけを解除することはできません。だからこそ、プライバシー、捜査、国家安全保障、サイバー防衛のあいだで、社会は今も難しい選択を迫られています。「善人だけが使えて、悪人が使ったときだけ政府が解除できる暗号」は存在するのか。暗号戦争の歴史から、デジタル社会の自由と安全を考えます。
S1 · E24
August 15 · 21 min
入門編#24丨脅威モデリングとは何か——攻撃者の行動から逆算するセキュア・バイ・デザイン
脅威モデリングとは、サイバー攻撃の手口をただ並べる作業ではありません。本エピソードでは、脅威モデリングとは何か、なぜ経営者や事業責任者に必要なのかを解説します。取り上げる主なテーマ - 脅威モデリングとは何か - セキュア・バイ・デザイン - 脆弱性診断・ペネトレーションテストとの違い - OWASPの4つの問い - 守るべき資産ではなく「許容できない結果」から考える - 信頼境界（Trust Boundary） - 攻撃者の期待利益 - 金銭目的の犯罪者と国家支援型攻撃者の違い - ランサムウェアと知的財産窃取 - 多層防御 - 残留リスク・残余リスク - CISOと事業責任者の役割分担 - リスク受容のガバナンス - 悪いKPIと良いKPI - STRIDEとチェックリスト化の罠 - 経済産業省・国家サイバー統括室のガイドライン - AI時代の脅威モデリング脅威モデリングの本質は、未来の攻撃を完璧に予言することではありません。自社にとって絶対に起きてはいけない結果は何か。どこに信頼境界があるのか。誰が、どの目的で、どの経路から攻撃してくるのか。どのリスクを設計段階で消すのか。残ったリスクを誰が引き受けるのか。これらを、システムが完成する前に考えるためのプロセスです。完成した家の窓や鍵を後から調べるのが脆弱性診断だとすれば、脅威モデリングは、最初の設計図の段階で「泥棒が届かない位置に窓を置く」「火事が広がらない区画を作る」ための作業です。最新のEDRやゼロトラスト製品を導入しても、構造的な欠陥は後から簡単には直せません。だからこそ重要なのは、攻撃者の視点から逆算し、事業への影響を基準に設計することです。金銭目的の犯罪者は、早く利益を得るためにランサムウェアで業務を止めます。国家支援型の攻撃者は、気づかれないように長期間潜伏し、設計図や知的財産を少しずつ盗みます。同じ侵入口でも、相手によって必要な防御は変わります。そして、どれだけ対策しても最後には残留リスクが残ります。そのリスクを受け入れるのは、CISOだけではありません。そのシステムで利益を得る事業責任者、経営層が、条件と期限を明確にして引き受ける必要があります。脅威モデリングは、IT部門だけの作業ではありません。不確実なリスクに名前をつけ、優先順位をつけ、誰が責任を持って前に進むのかを決めるための、経営の思考技術です。
S4 · E14
July 26 · 21 min
AI編#14丨同意だけでは守れない——個人情報保護法改正・医療データ・AI覇権の行方
個人情報は、本人の同意だけで本当に守れるのでしょうか。本エピソードでは、個人情報保護法改正を起点に、医療データ、購買履歴、AI開発、データ独占、そして集団的プライバシーの問題を解説します。取り上げる主なテーマ - 個人情報保護法改正 - 同意中心主義の限界 - 統計作成等の例外 - AI開発とデータ二次利用 - 課徴金制度 - 個人情報保護委員会の権限強化 - 特定生体個人情報 - 子どもの個人情報保護 - 匿名化の限界 - オントロジーと意味の地図 - 集団的プロファイリング - 医療データと購買履歴 - 住宅ローン・保険・採用への影響 - EUのEHDSとの比較 - Secure Data Environment - Findata - データ集中とサイバーリスク - データ領主 - データフライホイール - 公正取引委員会と競争政策 - グループ・プライバシー今回の法改正は、単なる「同意なしでデータを使えるようになる話」ではありません。より深い論点は、データの使い方が、本人同意の有無から、データの流れ、技術的な隔離、利用目的、事後監督、競争政策へと移っていることです。名前や住所を消しても、データは完全に安全になるとは限りません。深夜の購買履歴。特定の診療科への通院。健康食品の購入。決済履歴。位置情報。生活パターン。これらが組み合わされると、個人を直接名指ししなくても、「このような行動をする集団は、特定の病気や返済リスクが高い」と推論される可能性があります。問題は、あなた個人が特定されるかどうかだけではありません。あなたが属すると推定された集団が、保険、融資、採用、広告、価格設定で不利益に扱われるかもしれないことです。さらに、医療機関や小売業のデータが、一部のAI企業に集中すれば、攻撃者にとっては高価値な標的になり、同時に市場では「データ領主」が生まれる可能性があります。 AIの精度は、データが集まるほど高まります。精度が高まれば、さらに利用者が増えます。利用者が増えれば、さらにデータが集まります。このデータフライホイールが回り始めると、後発企業や中小企業は追いつけなくなります。個人情報保護法改正は、AI開発の追い風になる一方で、技術的統制、セキュアデータ環境、競争政策、集団的プライバシーの設計を迫る制度変更でもあります。私たちのデータは、社会全体を豊かにする公共的なインフラになるのか。それとも、ハッカーの標的となり、一部企業の私有資産になるのか。 AI時代の個人情報保護とデータガバナンスを考えます。
S4 · E13
July 13 · 25 min
AI編#13丨そのプロンプトは、外部送信ではないのか——生成AI時代の患者データ・機微情報・SaaSガバナンス
生成AIに入力したそのプロンプトは、本当に「自分だけの画面の中」に留まっているのでしょうか。本エピソードでは、生成AI時代のプロンプト入力、患者データ、機微情報、SaaSガバナンスについて解説します。取り上げる主なテーマ - プロンプトは外部送信なのか - 生成AIとデータフロー - 患者データ・医療情報・メンタルヘルス情報の扱い - 日本の個人情報保護法とPPCの考え方 - HIPAAとBAA - ePHIとクラウド事業者 - 第三者提供と委託の違い - BetterHelp事案 - GoodRx事案 - 匿名化の罠 - 自由記載と再識別リスク - OpenAI、Azure OpenAI、Google Gemini、AWS Bedrockのデータ保持 - Web検索・音声・メモリー・スレッド機能のリスク - RAGと社内データ連携 - DLP・RBAC・監査ログ - SaaSのサイレントアップデート - AI導入前のガバナンス設計生成AIの問題は、AIが正しい答えを出すかどうかだけではありません。もっと手前にある問題は、何をAIに渡したのか。そのデータはどこへ送られるのか。どこに保存されるのか。誰が見られるのか。どの機能をオンにすると、外部検索、ログ保存、メモリー、音声処理、サードパーティ連携が動くのか。プロンプト入力は、単なる文章作成ではありません。多くの場合、それは外部SaaSへのデータ送信イベントです。特に、患者情報、メンタルヘルス情報、診断名、服薬、通院歴、家族関係、職場の悩み、トラウマ、希死念慮などは、極めて感度の高い情報です。名前を消しても安全とは限りません。自由記載に残る文脈だけで、個人が再識別されることがあります。重要なのは、「どのAIサービスなら安全か」ではありません。どの機能を使うのか。どのデータを入れてよいのか。どのログが残るのか。誰がアクセスできるのか。事故が起きたとき、誰が止めるのか。ブランド名ではなく、機能単位・契約単位・データ経路単位で管理することです。生成AIを安全に使うとは、最新モデルを選ぶことではありません。データを分離し、入力境界を決め、便利機能のスイッチを確認し、ログと緊急停止手順を整えることです。そのプロンプトは、外部送信ではないのか。 AI時代の患者データ、機微情報、SaaSガバナンスを考えます。
S2 · E11
July 7 · 22 min
実録編#11丨生成AIで4万件を退会させた中学生——バンダイチャンネル事件とサイバー教育の盲点
生成AIを使った中学生が、大手動画配信サービスに大量の自動退会リクエストを送り、数万件規模のアカウントを強制退会させたとされる事件。本エピソードでは、この事件を単なる「少年のいたずら」や「AIの悪用」として片付けず、生成AI時代のサイバー教育、API設計、企業側の防御、家庭でのガードレールについて考えます。取り上げる主なテーマ - 生成AIを使った不正プログラム作成 - 未成年によるサイバー加害 - バンダイチャンネル大量退会事件 - APIへの自動リクエスト - レートリミットの重要性 - 退会・削除処理に必要な再認証 - セキュア・バイ・デザイン - OWASP ASVS - 生成AIによる実行ハードルの低下 - スクリプトキディとAI時代の違い - 不正アクセス禁止法 - 電子計算機損壊等業務妨害 - 被害防止から加害予防への教育転換 - 未成年者向けサイバー教育 - 家庭でのAI利用ルール - ガードレールとしてのフィルタリングと対話 - 技術的好奇心と倫理の境界線生成AIは、子供たちに強力な学習ツールを与えました。しかし同時に、かつては専門知識や経験が必要だった自動化スクリプトの作成を、誰でも短時間で実行できる環境も生み出しています。問題は、子供たちの好奇心そのものではありません。問題は、技術的に「できること」と、法律的・倫理的に「やってはいけないこと」の境界線を、社会が十分に教えられていないことです。そして企業側にも課題があります。退会処理、削除処理、個人情報変更、決済処理のような不可逆的でリスクの高い操作には、再認証、レートリミット、異常検知、取り消し可能な設計が必要です。サイバー教育は、もはや「ネットでだまされないための教育」だけでは足りません。これから必要なのは、子供たちが無自覚に加害者にならないための教育です。技術の好奇心を否定せず、しかし超えてはいけない一線を具体的に教えること。生成AI時代の未成年者サイバー教育と、企業のセキュア・バイ・デザインを考えます。
S4 · E12
July 1 · 24 min
AI編#12丨ペンタゴン・ピザ指数とは何か――AI時代のOSINTと予測の罠
ピザの注文は、戦争や危機を予測できるのでしょうか。本エピソードでは、ワシントンD.C.周辺で語られてきた「ペンタゴン・ピザ指数」を出発点に、OSINT、行動データ、AI予測、サイバー防御の危うさを考えます。取り上げる主なテーマ - ペンタゴン・ピザ指数とは何か - 湾岸戦争前夜のピザ注文逸話 - Google Mapsの混雑データ - OSINTと行動データ - 代理変数の危うさ - 確認バイアス - 外れた予測が見えにくい問題 - サイバー防御における外部シグナル - SOCにおけるアラート優先度付け - 行動OSINTと脅威インテリジェンス - 偽情報検出と現実世界データ - AIによる多変量分析 - 説明可能AI（XAI） - EU AI Actと透明性 - 個人情報・プライバシーのリスク - RAGとデータ混入リスク - 物理空間を使ったAIへのノイズ注入 - 監視社会とサイバー防衛の境界線ペンタゴン周辺のピザ店が深夜に混むと、世界で何かが起きる。一見すると都市伝説のような話ですが、そこには現代のAI時代に通じる重要な論点があります。人間は、重大な危機の前に行動を変えます。深夜まで働く。周辺の飲食店が混む。交通量が変わる。 SNSの話題が変わる。ログに出る前に、現実世界の行動に兆候が出る。こうした弱いシグナルを、AIがサイバー攻撃のアラート、脅威インテリジェンス、ニュース、OSINTと組み合わせれば、危機の優先順位付けに使える可能性があります。しかし、そこには大きな危うさもあります。ピザ店が混んでいる理由は、本当に国家危機なのか。ただの観光客、イベント、大学生の集まりではないのか。事件が起きた後に、都合のよいデータだけを拾っていないか。攻撃者がわざと物理空間にノイズを流し、防御AIを誤作動させる可能性はないのか。 AI予測は、未来を当てる魔法ではありません。重要なのは、弱いシグナルを盲信することではなく、なぜそのリスクスコアが上がったのかを説明できることです。デジタル空間を守るために、現実世界の行動データまで読み取る時代。その便利さと危うさを、ペンタゴン・ピザ指数から考えます。
S4 · E11
June 25 · 22 min
AI編#11丨そのAIミスに保険は下りるのか——AI保険市場とサイレントAIリスクの最前線
AIが起こした損害に、保険は下りるのでしょうか。生成AIや自律型AIエージェントが業務に入り込む一方で、AIの誤判断、ハルシネーション、データ漏えい、自動処理の失敗が起きたとき、誰がその損害を負担するのかという問題が浮上しています。本エピソードでは、AI保険市場と「サイレントAIリスク」の最前線を解説します。取り上げる主なテーマ - AI保険とは何か - サイレントAIリスク - 既存のサイバー保険・賠償責任保険の限界 - AI免責条項 - 生成AI除外フォーム - Munich ReのaiSure - Lloyd’s市場のAI専門保険 - AIモデルの性能保証 - 技術的デューデリジェンス - モデルカード - 監査ログ - キルスイッチ - ヒューマン・イン・ザ・ループ - AI事故と責任分界 - Air Canadaチャットボット事案 - AIサプライチェーンと責任の押し付け合い - EU AI Act - 米国保険市場の分裂 - 英国ロイズ市場と実験的商品 - 日本の生成AI保険と損保各社の動き - AIガバナンスと保険取得可能性 AI保険は、何でも肩代わりしてくれる魔法の杖ではありません。むしろ、保険会社が「この企業はAIを安全に運用できているか」を審査する、外部ガバナンスの仕組みになりつつあります。どのAIを使っているのか。どの業務に組み込んでいるのか。どのデータを入力しているのか。 AIの判断を誰が監視しているのか。事故が起きたときに止める権限は誰にあるのか。ログと証拠は残っているのか。これらを説明できない企業は、いざ事故が起きたときに「AIに起因する損害は補償対象外です」と突き返される可能性があります。 AI保険の本質は、単なるリスク移転ではありません。 AIを業務に使う企業が、自社のガバナンス、監査、責任分界、インシデント対応をどこまで整えているかを問われる時代が来ています。 AIを使う企業は、保険で守られる前に、まず保険会社から審査される。 AI時代のリスク、責任、保険、そして企業統治を考えます。
S2 · E10
June 20 · 22 min
実録編#10丨民主主義はどこから攻撃されるのか——選挙、偽情報、ハック・アンド・リーク時代のサイバー防衛
民主主義は、どこから攻撃されるのでしょうか。投票箱でしょうか。選挙システムでしょうか。それとも、私たちが毎日見ているニュースフィードやSNSのタイムラインでしょうか。本エピソードでは、サイバー攻撃、偽情報、ハック・アンド・リーク、ディープフェイクが、民主主義の土台である「信頼」をどのように揺さぶるのかを解説します。取り上げる主なテーマ - サイバーセキュリティと民主主義 - 選挙へのサイバー攻撃 - 民主主義のサプライチェーン - 選挙管理機関・政党・メディア・委託先のリスク - 日本年金機構、ProjectWEB、JAXA事案から見える信頼の毀損 - DNCハッキング - MacronLeaks - ハック・アンド・リーク - 本物の文書に偽物を混ぜる情報操作 - Liar’s Dividend（嘘つきの配当） - ディープフェイクと真実の暴落 - 能登半島地震時の偽救助要請 - SNS上の偽情報と認知戦 - 外国干渉と選挙の正当性 - CISA、ENISA、DSAから見る制度設計 - 能動的サイバー防衛と言論統制の境界線 - 民主主義を守るレジリエンス現代の攻撃者は、必ずしも投票結果を直接書き換えるわけではありません。狙われるのは、投票箱そのものではなく、選挙を支える周辺システムです。政党、行政機関、メディア、クラウド委託先、SNS、災害時の情報流通。そこに侵入し、情報を盗み、偽情報を混ぜ、社会の不信感を増幅させる。その目的は、特定の嘘を信じ込ませることだけではありません。「何が本当なのか分からない」状態を作り、選挙や行政やメディアへの信頼を少しずつ削ることです。一方で、偽情報対策を名目に、政府が「真実の裁判官」になってしまえば、それは言論統制の入り口にもなります。民主主義を守るためのサイバー防衛には、攻撃から社会を守る仕組みと、防衛を名目に権力が肥大化しない仕組みの両方が必要です。サイバー攻撃は、もはやパスワードやサーバーだけを狙うものではありません。私たちの認識、信頼、判断そのものが攻撃対象になる時代に、民主主義をどう守るのかを考えます。
S4 · E10
June 18 · 21 min
AI編#10丨サイバー防御ガイドラインは公開すべきか——フロンティアAI時代の「見せる情報」と「守る情報」
サイバー防御のガイドラインは、どこまで公開すべきなのでしょうか。すべて公開すれば、攻撃者に攻略本を渡すことになる。すべて隠せば、利用者や中小企業は安全な製品を選べなくなる。本エピソードでは、フロンティアAI時代におけるサイバーセキュリティ情報の公開・制限共有・時間差公開について解説します。取り上げる主なテーマ - サイバー防御ガイドラインは公開すべきか - 「全部公開」と「全部非公開」の限界 - 攻撃者にとって価値がある情報とは何か - 一般原則と具体的な弱点の違い - MFA、ポート閉鎖、脆弱性報告窓口 - パッチ遅延・例外設定・未修正脆弱性の危険性 - フロンティアAIによる情報処理コストの破壊 - CVE情報と攻撃コード生成 - Patch-to-PoC - TLP 2.0 - 一般公開・業界内共有・要保護留保・厳格制限 - SBOMの公開範囲 - 生成AIへの機微情報投入制限 - 時間差公開 - 秘密指定の乱用防止 - 中小企業を排除しない制度設計 - EBPMとしての段階的導入重要なのは、「防御法を非公開にすること」ではありません。公開すべきなのは、社会が安全性を判断するために必要な原則、最低要件、責任分界、脆弱性報告窓口、サポート期間です。一方で、制限すべきなのは、攻撃者の探索・選定・実行コストを具体的に下げる情報です。どの製品のどのバージョンが未修正なのか。どのシステムだけMFAの例外になっているのか。どの環境なら脆弱性が成立するのか。どの緩和策がまだ未実施なのか。こうした情報は、AIによって瞬時に結びつけられ、攻撃対象の選定に使われる可能性があります。だからこそ必要なのは、情報を隠すことではなく、情報の粒度、共有先、公開時期を設計することです。サイバーセキュリティは、公開か非公開かの二択ではありません。何を、誰に、どの粒度で、いつ共有し、いつ公開へ移すのか。フロンティアAI時代の「見せる情報」と「守る情報」を考えます。
S1 · E20
June 17 · 15 min
入門編#20｜Active Directoryとは何か——会社のIDと権限を支配する中枢システム
会社のセキュリティで、最も重要な急所はどこにあるのでしょうか。ファイアウォール、VPN、社員のパソコン。もちろんそれらも重要です。しかし、多くの企業にとって本当の心臓部は、Active Directory、通称ADです。本エピソードでは、Active Directoryとは何か、なぜ会社のIDと権限を支配する中枢システムなのか、そしてなぜランサムウェア攻撃者が真っ先にADを狙うのかを解説します。取り上げる主なテーマ - Active Directoryとは何か - IDと権限の一元管理 - シングルサインオン - Kerberos認証 - ドメイン管理者権限 - グループポリシーの悪用 - VPN・RDP経由の侵入 - ラテラルムーブメント - ランサムウェアとAD乗っ取り - 大阪急性期・総合医療センター事案 - 岡山県精神科医療センター事案 - MFA、ログ、バックアップ - Entra IDとハイブリッド環境 - ゼロトラストへの入り口 ADは、会社の会議室、金庫、社長室、ファイルサーバー、業務システムの鍵をまとめて管理する「マスターキー」です。便利である一方、攻撃者に奪われれば、会社の正規ルールを使って会社自身を破壊される危険があります。重要なのは、非技術者のリーダーが技術者になることではありません。ドメイン管理者権限は誰が持っているのか。多要素認証は本当に入っているのか。バックアップはADが乗っ取られても壊されないのか。ログは監視されているのか。正しい問いを投げかけることが、組織の心臓部を守る第一歩になります。
S1 · E19
June 17 · 20 min
入門編#19｜SIEMとは何か｜大量のログからサイバー攻撃の兆候を見つける仕組み
SIEMとは、単なるログ保管庫ではありません。企業のサーバー、端末、クラウド、認証基盤、VPN、EDR、ファイアウォールなどから大量のログを集め、サイバー攻撃や不審な動きの兆候を見つけるための仕組みです。本エピソードでは、SIEMとは何か、なぜ多くの企業が導入しても運用でつまずくのか、そしてログを「集めること」と「意味を読み取ること」の違いを解説します。取り上げる主なテーマ - SIEMとは何か - ログ管理と証跡管理 - SOCとの違い - アラート疲れ - 正規化 - 相関分析 - Entra ID・OktaなどIDログの重要性 - VPN、クラウド、端末ログの統合 - Target事案 - Marriott / Starwood事案 - M&A時の監視ギャップ - 全ログ主義の落とし穴 - ホットデータとコールドデータ - Microsoft Sentinel - Splunk - Google SecOps - Elastic - MDR・管理型SOC - SOAR・XDRとの関係 - AIによるSecOps支援 - セキュリティと従業員監視の境界線 SIEMは、事故が起きたときに「何が起きたのか」「どこから侵入されたのか」「被害はどこまで広がったのか」を説明するための、組織の記憶です。しかし、ログを集めるだけでは会社は守れません。アラートが鳴っても誰も見ていなければ、侵入は止まりません。ログが集まっていても、相関分析できなければ攻撃の流れは見えません。すべてのログを無差別に入れれば、コストとノイズでSOCは疲弊します。重要なのは、どのログを優先して見るのか。どのアラートに誰が責任を持つのか。どこまで自動化し、どこから人間が判断するのか。 SIEMは、放置しておけば守ってくれる魔法の箱ではありません。ログという「点」をつなぎ、攻撃の「線」を見つけ、有事に事実を説明するための経営インフラです。サイバー攻撃を受けたとき、推測ではなく証拠に基づいて動ける組織になるために、SIEMの基本を整理します。経営層、情報システム部門、セキュリティ担当者、SOC・CSIRT体制を検討している企業に向けた、SIEM入門です。
S1 · E18
June 17 · 18 min
入門編#18丨SOCとは何か——サイバー攻撃を見張る組織の管制塔
SOCとは、サイバー攻撃を見張るための「監視ルーム」ではありません。異常に気づき、判断し、必要な部署を動かし、被害が広がる前に止めるための、組織の管制塔です。本エピソードでは、SOC（Security Operations Center）とは何か、なぜ現代の企業に必要なのかを、経営者・管理職にもわかる形で解説します。取り上げる主なテーマ - SOCとは何か - 外部通報で発覚するサイバー侵害 - 内部検知の重要性 - 攻撃者の滞留時間 - 日本年金機構事案 - ログ監視 - SIEM・EDR・XDR・SOARとの関係 - MITRE ATT&CK - AIによるSOC支援と限界 - 内製SOCと外部委託SOC - MDR・マネージドSOC - ハイブリッド型SOC - SOCに必要な人材と24時間365日体制 - 検知後に動けない組織のリスク - コロニアル・パイプライン事案 - Norsk Hydro事案 - 東京2020大会のサイバー防衛 - MTTD・MTTR - 内部検知比率 - ログ改ざんと監視の信頼性サイバー攻撃は、もはや「侵入されるかどうか」だけの問題ではありません。重要なのは、侵入されたときに自社で気づけるか。外部から指摘される前に異常を見つけられるか。被害が広がる前に止められるか。多くの組織では、攻撃者がネットワーク内に潜伏していても、自社では気づけず、外部機関や取引先からの通報で初めて発覚します。 SOCの価値は、攻撃を完全に防ぐことではありません。ログ、ID、端末、クラウド、メール、ネットワークの情報を集め、異常を検知し、優先順位をつけ、必要な初動対応につなげることです。ただし、SOCは高価なツールを導入すれば完成するものではありません。ログが取れていなければ見えません。アラートを判断する人がいなければ動けません。端末を隔離する権限がなければ止められません。夜間休日に意思決定できるルートがなければ、攻撃者の速度に追いつけません。 SOCとは、サイバー攻撃を完全に防ぐ魔法ではなく、異常を見つけ、判断し、組織を動かすための危機管理機能です。サイバー攻撃を事業継続リスクとして捉えたい経営者、情報システム部門、リスク管理担当者、広報・法務・監査に関わる方に向けた、SOC入門です。
S1 · E17
June 17 · 16 min
入門編#17｜ゼロトラストとは何か——“社内だから安全”という前提が崩れた時代の防衛思想
サイバーセキュリティ新聞、今回のテーマは「ゼロトラスト」です。ゼロトラストとは、単に「誰も信じない」という意味ではありません。「社内ネットワークだから安全」「会社支給の端末だから安心」「VPNに入れたから大丈夫」という従来の前提を見直し、ユーザー、端末、アプリ、データ、ネットワークの状態をその都度確認しながらアクセスを許可する防衛思想です。かつて企業のサイバー防衛は、外側に高い城壁を作り、その内側を安全地帯とみなす考え方が中心でした。しかし現在は、クラウド、SaaS、リモートワーク、委託先、子会社、スマートフォン、外部パートナーが業務に深く入り込み、会社の境界線そのものが曖昧になっています。さらに攻撃者は、正面からファイアウォールを突破するだけではありません。盗まれたIDやパスワードを使い、正規の社員や委託先のようにログインしてくることがあります。この時代に必要なのが、ゼロトラストという考え方です。この回では、ゼロトラストの基本概念、なぜ従来型の境界防御だけでは不十分になったのか、VPNやMFAとの関係、ID管理・権限管理の重要性、ランサムウェア対策との接点、そして経営者が最初に確認すべきポイントを、非技術系の方にもわかるように整理します。ゼロトラストは、特定の製品名ではありません。会社の鍵を誰に渡し、どの扉を開けさせ、どの行動を記録し、どこで止めるのかを再設計する、現代企業のための権限統治です。
S4 · E9
June 17 · 24 min
AI編#09｜AIセキュリティは誰の責任か——経営・CISO・情シス・開発・法務・委託先・AIベンダーの責任分界
AIセキュリティは、誰の責任なのでしょうか。経営者でしょうか。 CISOでしょうか。情シスでしょうか。開発部門でしょうか。法務でしょうか。委託先でしょうか。それともAIベンダーでしょうか。本エピソードでは、AI導入が進む企業で必ず問題になる「責任分界」について解説します。取り上げる主なテーマ - AIセキュリティは誰の責任か - 経営層・取締役会の役割 - CISOと情シスに丸投げしてはいけない理由 - AIベンダーとの責任共有モデル - 日本のAI事業者ガイドライン - NIST AI RMF - CISAのAIセキュリティ観点 - EU AI Act - RACIマトリックス - AIエージェントへの過剰な権限付与 - RAG・API・プラグイン・ログ管理 - OpenAIのデータ漏洩事案から見える教訓 - LINEヤフー事案と委託先管理 - MOVEit事案とサプライチェーンリスク - AI for Securityと人間の最終判断 - ヒューマン・オーバーライド - キルスイッチと緊急停止権限 AIセキュリティは、情シスだけの仕事ではありません。 CISOは安全統制を設計します。開発部門はAIを実装します。法務は契約と説明責任を見ます。事業部門は用途とリスクを決めます。委託先やAIベンダーは技術基盤を提供します。しかし、最終的に「どの業務にAIを入れるのか」「どの権限をAIに渡すのか」「どこまでのリスクを会社として許容するのか」を決めるのは、経営の仕事です。重要なのは、事故が起きた後に犯人探しをすることではありません。 AIを導入する前に、誰が用途を決めるのか。誰が監視するのか。誰が止めるのか。誰が社会に説明するのか。その責任分界を文書化しておくことです。 AIは、便利な道具であると同時に、権限を持てば自律的に業務を動かす存在になります。ハンドルが5つある車に乗る前に、誰が運転し、誰がブレーキを踏むのか。 AI時代の組織統治を考えます。
S4 · E8
June 17 · 25 min
AI編#08｜防御側AIの使い方——SOC・脆弱性管理・ログ分析をどう変えるのか
AIは、サイバー防衛の現場をどう変えるのでしょうか。本エピソードでは、防御側AIの使い方を、SOC、脆弱性管理、ログ分析、インシデント対応の観点から解説します。取り上げる主なテーマ - 防御側AIとは何か - AIは魔法の盾ではない - セキュリティ担当者の認知負荷を下げる役割 - SOCにおけるAI活用 - ログ要約とアラート分析 - MITRE ATT&CKへのマッピング - SOARとの連携 - ヒューマン・イン・ザ・ループ - AIによる脆弱性探索 - パッチ優先順位付け - MTTD・MTTRの短縮 - AIの誤検知とハルシネーション - プロンプトインジェクション - 防御側AIそのものが攻撃面になるリスク - AI導入前に必要な資産台帳・ログ・MFA - 人間が設計すべきガードレール防御側AIの本質は、人間の代わりにすべてを判断することではありません。膨大なログを要約する。アラートの意味を整理する。攻撃者の行動をMITRE ATT&CKに対応づける。脆弱性の優先順位をつける。インシデント対応の初動を早める。 AIは、セキュリティ担当者の認知負荷を下げ、判断の速度を上げるための増幅装置です。ただし、AIに広範な実行権限を与えることは危険です。読む、要約する、分類する、提案する。ここまではAIに任せられます。しかし、システムを止める、端末を隔離する、アカウントを停止する、顧客へ通知する。こうした行為には、人間の承認と監査証跡が必要です。攻撃者もAIを使う時代、防御側もAIを使わなければ追いつけません。しかし、防御側AIを入れることは、同時にAI自身を守る責任を引き受けることでもあります。 AIを自動運転の警備員ではなく、人間の判断を支える副操縦士として使う。 AI時代のSOCとサイバー防衛の現実を考えます。
S4 · E7
June 17 · 28 min
AI編#07｜OWASP LLM Top 10で見るAI導入企業の新しい攻撃面——プロンプトインジェクション・RAG汚染・機密漏えい
AIを導入した会社は、どんな新しい攻撃面を抱えるのでしょうか。本エピソードでは、OWASP LLM Top 10を軸に、AI導入企業が直面する新しいサイバーリスクを解説します。取り上げる主なテーマ - OWASP LLM Top 10 - プロンプトインジェクション - 間接プロンプトインジェクション - RAG汚染・RAGポイズニング - 社内文書データベースの汚染 - AIエージェント化のリスク - 過剰な権限付与 - MCPと外部ツール連携 - DNSリバインディング - AIサプライチェーン - Hugging Faceとモデル配布リスク - Pickleファイルの危険性 - 悪意あるパッケージやSDK - ディープフェイクとAIフィッシング - MFA突破とセッショントークン窃取 - シャドーAIとAI資産管理 - ヒューマン・イン・ザ・ループ AIのリスクは、攻撃者がAIを使うことだけではありません。企業がAIを導入した瞬間に、社内データ、RAG、API、プラグイン、外部ツール、AIエージェントの権限が、新しい攻撃面になります。特に危険なのは、AIが自然言語を「命令」として解釈し、メール、PDF、Webページ、社内文書に埋め込まれた見えない指示に従ってしまうことです。 AIに何を読ませるのか。どのデータベースに接続するのか。どのAPIを呼び出せるのか。どこまで自動実行させるのか。その出力を誰が検証するのか。これらを決めないままAIを導入すると、便利な業務支援ツールが、機密漏えい、意思決定の汚染、権限濫用の入口になります。 AI時代のセキュリティは、モデルの賢さだけでは守れません。必要なのは、権限の最小化、データの来歴管理、監査ログ、システムの分離、人間による承認、そして「AIが読んだ情報は本当に信頼できるのか」と問い続ける姿勢です。自然言語がシステムを動かす時代に、企業は何を守り直すべきなのかを考えます。
S4 · E6
June 17 · 20 min
AI編#06｜AI時代の脆弱性管理とは——経営者が備える「3日で直す」パッチ対応と侵害確認
AI時代、脆弱性管理の時間軸は大きく変わりました。かつては、月に一度パッチを当てる運用でも許されていました。しかし今は、脆弱性が公表された直後から、AIを使って攻撃コードが自動生成され、数日以内に実際の侵入へつながる時代です。本エピソードでは、AI時代の脆弱性管理とは何か、経営者がなぜ「3日で直す」体制を考えなければならないのかを解説します。取り上げる主なテーマ - AIが脆弱性攻撃を高速化する理由 - パッチ差分解析と攻撃コード生成 - CISA BOD 22-01 - NIST AI Risk Management Framework - CVSSだけに頼る危険性 - KEVカタログ - EPSSによる悪用確率評価 - 「3日で直す」パッチ対応 - VPN・リモート接続機器のリスク - 侵害確認とフォレンジック・トリアージ - パッチ適用後も侵入済みの可能性 - 経営判断としてのシステム停止 - 権限移譲と例外承認 - AIによる防御支援 - 防衛用AIそのもののリスク脆弱性管理とは、穴を見つけて順番に直す作業ではありません。今問われているのは、どの脆弱性が今まさに狙われているのか。どのシステムを3日以内に止めてでも直すのか。すでに侵入されていないかをどう確認するのか。誰がその判断に責任を持つのか。 AI時代の脆弱性管理は、IT部門だけの仕事ではありません。それは、会社がどれだけ速く「止める、塞ぐ、切り離す、調べる」判断を出せるかという、経営の反応速度のテストです。パッチ対応を「作業」ではなく、事業継続と危機管理の問題として考えます。
S4 · E5
June 17 · 25 min
AI編#05｜高性能AIは脆弱性攻撃をどう変えたのか——攻撃の高速化・ゼロデイ探索・攻撃自動化
AIによって、脆弱性攻撃の時間軸は大きく変わりました。かつては、脆弱性が公開されてから実際に攻撃されるまで、数週間から数か月の猶予があると考えられていました。しかし今は、パッチが公開される前から攻撃が始まり、公開後わずか数日、場合によっては24時間以内に悪用される時代です。本エピソードでは、高性能AIが脆弱性攻撃をどう変えたのかを解説します。取り上げる主なテーマ - 高性能AIと脆弱性攻撃 - TTE（Time to Exploit） - パッチ公開前から始まる攻撃 - Mandiant / M-Trendsが示す攻撃時間の短縮 - サイバー犯罪の産業化 - 初期アクセスブローカー - ランサムウェア・サプライチェーン - CVE情報と攻撃コード生成 - AIによるパッチ差分解析 - ワンデー脆弱性の悪用 - ゼロデイ探索の現実 - CVSS依存の限界 - KEV・EPSSによる優先順位付け - インターネット公開資産の棚卸し - CISA BOD 22-01 - 3日以内の対応とフォレンジック - 防御側AIの限界 - 経営判断としての脆弱性管理 AIは、攻撃者を突然「魔法使い」に変えたわけではありません。すでに産業化していたサイバー犯罪の仕組みに組み込まれ、偵察、脆弱性情報の読解、攻撃コードの作成、標的選定といった下準備を圧倒的に高速化しました。その結果、脆弱性管理は「点数の高いものから順番に直す作業」ではなくなりました。今まさに悪用されているのか。インターネットに公開されているのか。攻撃が自動化できるのか。システムを完全に制御される恐れがあるのか。すでに侵入されていないか。これらを見極め、必要なら事業を止めてでも対応する判断が求められます。 AI時代の脆弱性管理は、IT部門だけの技術作業ではありません。自社の資産を把握し、例外承認の期限を決め、深夜や休日でも意思決定できる体制を作ること。それは、経営の反応速度そのものです。

Showing 1–20 of 20 episodes