会社のセキュリティで、最も重要な急所はどこにあるのでしょうか。

ファイアウォール、VPN、社員のパソコン。

もちろんそれらも重要です。

しかし、多くの企業にとって本当の心臓部は、Active Directory、通称ADです。

本エピソードでは、Active Directoryとは何か、なぜ会社のIDと権限を支配する中枢システムなのか、そしてなぜランサムウェア攻撃者が真っ先にADを狙うのかを解説します。

取り上げる主なテーマ

- Active Directoryとは何か

- IDと権限の一元管理

- シングルサインオン

- Kerberos認証

- ドメイン管理者権限

- グループポリシーの悪用

- VPN・RDP経由の侵入

- ラテラルムーブメント

- ランサムウェアとAD乗っ取り

- 大阪急性期・総合医療センター事案

- 岡山県精神科医療センター事案

- MFA、ログ、バックアップ

- Entra IDとハイブリッド環境

- ゼロトラストへの入り口

ADは、会社の会議室、金庫、社長室、ファイルサーバー、業務システムの鍵をまとめて管理する「マスターキー」です。

便利である一方、攻撃者に奪われれば、会社の正規ルールを使って会社自身を破壊される危険があります。

重要なのは、非技術者のリーダーが技術者になることではありません。

ドメイン管理者権限は誰が持っているのか。

多要素認証は本当に入っているのか。

バックアップはADが乗っ取られても壊されないのか。

ログは監視されているのか。

正しい問いを投げかけることが、組織の心臓部を守る第一歩になります。

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入門です。

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入門です。

サイバーセキュリティ新聞、今回のテーマは「ゼロトラスト」です。

ゼロトラストとは、単に「誰も信じない」という意味ではありません。

「社内ネットワークだから安全」「会社支給の端末だから安心」「VPNに入れたから大丈夫」という従来の前提を見直し、ユーザー、端末、アプリ、データ、ネットワークの状態をその都度確認しながらアクセスを許可する防衛思想です。

かつて企業のサイバー防衛は、外側に高い城壁を作り、その内側を安全地帯とみなす考え方が中心でした。

しかし現在は、クラウド、SaaS、リモートワーク、委託先、子会社、スマートフォン、外部パートナーが業務に深く入り込み、会社の境界線そのものが曖昧になっています。

さらに攻撃者は、正面からファイアウォールを突破するだけではありません。

盗まれたIDやパスワードを使い、正規の社員や委託先のようにログインしてくることがあります。

この時代に必要なのが、ゼロトラストという考え方です。

この回では、ゼロトラストの基本概念、なぜ従来型の境界防御だけでは不十分になったのか、VPNやMFAとの関係、ID管理・権限管理の重要性、ランサムウェア対策との接点、そして経営者が最初に確認すべきポイントを、非技術系の方にもわかるように整理します。

ゼロトラストは、特定の製品名ではありません。

会社の鍵を誰に渡し、どの扉を開けさせ、どの行動を記録し、どこで止めるのかを再設計する、現代企業のための権限統治です。

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時代の組織統治を考えます。

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とサイバー防衛の現実を考えます。

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が読んだ情報は本当に信頼できるのか」と問い続ける姿勢です。

自然言語がシステムを動かす時代に、企業は何を守り直すべきなのかを考えます。

AI時代、脆弱性管理の時間軸は大きく変わりました。

かつては、月に一度パッチを当てる運用でも許されていました。

しかし今は、脆弱性が公表された直後から、AIを使って攻撃コードが自動生成され、数日以内に実際の侵入へつながる時代です。

本エピソードでは、AI時代の脆弱性管理とは何か、経営者がなぜ「3日で直す」体制を考えなければならないのかを解説します。

取り上げる主なテーマ

- AIが脆弱性攻撃を高速化する理由

- パッチ差分解析と攻撃コード生成

- CISA BOD 22-01

- NIST AI Risk Management Framework

- CVSSだけに頼る危険性

- KEVカタログ

- EPSSによる悪用確率評価

- 「3日で直す」パッチ対応

- VPN・リモート接続機器のリスク

- 侵害確認とフォレンジック・トリアージ

- パッチ適用後も侵入済みの可能性

- 経営判断としてのシステム停止

- 権限移譲と例外承認

- AIによる防御支援

- 防衛用AIそのもののリスク

脆弱性管理とは、穴を見つけて順番に直す作業ではありません。

今問われているのは、

どの脆弱性が今まさに狙われているのか。

どのシステムを3日以内に止めてでも直すのか。

すでに侵入されていないかをどう確認するのか。

誰がその判断に責任を持つのか。

AI時代の脆弱性管理は、IT部門だけの仕事ではありません。

それは、会社がどれだけ速く「止める、塞ぐ、切り離す、調べる」判断を出せるかという、経営の反応速度のテストです。

パッチ対応を「作業」ではなく、事業継続と危機管理の問題として考えます。

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部門だけの技術作業ではありません。

自社の資産を把握し、例外承認の期限を決め、深夜や休日でも意思決定できる体制を作ること。

それは、経営の反応速度そのものです。

バックアップを取っているだけで、本当に会社は守れるのでしょうか。

本エピソードでは、ランサムウェア被害において「バックアップがあるのに復旧できない」現実を、事例と実務視点から解説します。

取り上げる主なテーマ

- バックアップへの過信

- ランサムウェアによるバックアップ暗号化

- VPN・RDP経由の侵入

- 復旧訓練不足が招くパニック

- 名古屋港NUTS事案

- KADOKAWA事案

- クリーンリストアの重要性

- クラウドの冗長性とバックアップの違い

- 3-2-1ルールの限界

- イミュータブルバックアップ

- RTO・RPO

- ティアリングと経営判断

- 全社演習と説明責任

「バックアップがある」ことと、「事業を再開できる」ことは別物です。

重要なのは、データを保存しているかではなく、

本当に戻せるのか。

安全な状態で戻せるのか。

どの業務から優先して復旧するのか。

サイバー攻撃を受けたとき、復旧はIT部門だけの作業ではありません。

経営、法務、広報、事業部門を含めた全社的な危機対応になります。

バックアップを「希望」ではなく「事実」に変えるために、何を準備すべきかを考えます。