はじめに
少し前の私は、セキュリティ対策を「技術の問題」だとほとんど無意識に思い込んでいました。依存ライブラリを最新に保つ、脆弱性スキャンを回す、WAF を前に置く、入力値を検証する。こうした「コードとインフラの防御」は、それなりに手を動かしてきたつもりでした。
ところが、あるとき採用チームが受け取った「取引先を装った振込先変更メール」の話を聞いて、背筋が寒くなりました。私が積み上げてきた技術対策は、その1通のメールの前ではほとんど無力だったからです。攻撃者はコードの穴ではなく、人の判断の隙をまっすぐ突いてきていました。内部の人間がデータを持ち出す「内部不正」にいたっては、そもそも体系的に考えたことすらありませんでした。
この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で再構成した復習ログです。分量が多いため前後編に分け、本記事はその前編(攻撃と人間)にあたります。後編(規範と社会:倫理・法・フェイク)はこちらです。
想定読者は、少し前の私と同じように「ライブラリ更新や WAF といった技術対策はやってきたが、"人を狙う攻撃" や "社内の内部不正" を体系的に考えたことがなかった」開発者・運用者です。この記事の軸を、1行と3点(TL;DR)でまとめておきます。本文はこれをほどいていく形です。
サイバー攻撃の大半は、コードの穴ではなく「人」を経由して成立します。だから開発者も、コードの外側にある心理と手口の地図を持っておくと、明日のレビューや設計判断が変わります。
- 攻撃者はまず公開情報で人を下調べする。 なりすましも詐欺も、標的の名前・関係・技術スタックを OSINT(公開情報)から集めるところから始まります。だから防御側も、自分たちが扱う情報を「誰向けか(経営 / 設計 / 現場)」で仕分けると、ログやアラートの扱いが整理できます。
- 攻撃の多くは人を狙う。 技術対策だけでは、内部不正とソーシャルエンジニアリングは防げません。内部不正には「恨み系」と「金銭目的系」という動機の型があり、環境(監視の目・管理の甘さ)が犯行を後押しします。
- ソーシャルエンジニアリングは実装で受け止められる。 なりすまし・BEC・フィッシングは「気をつけましょう」で終わらせず、別経路での確認・多段承認・送金フローの多重化・送信ドメイン認証といった具体的な設計と運用に落とせます。
記事中の数値・事件・用語は執筆時点(2026年7月現在)の一次情報で確認し、確認しきれなかったものは「講義では〜と紹介された」と帰属を明示しています。私自身まだ学習中の身なので、間違いがあれば指摘していただけると助かります。
情報とインテリジェンスは何が違うのか
いきなり心理学に入る前に、セキュリティでよく耳にする「インテリジェンス」という言葉を整理させてください。ここが曖昧なままだと、「攻撃者は何を集めているのか」「防御側は何を扱うべきか」という話が全部ぼやけてしまいます。
インフォメーションとインテリジェンス
講義でまず区別されたのが、インフォメーション(Information)とインテリジェンス(Intelligence)の違いでした。日本語ではどちらも「情報」と訳してしまいがちですが、中身は違います。
- インフォメーション: 生の情報。集めてきただけの、まだ評価されていないデータ。
- インテリジェンス: その生の情報に、判断・評価・分析を加えたもの。意思決定に使える形になった情報。
小谷賢『インテリジェンス』(ちくま学芸文庫, 2012)や、伊東寛『サイバー・インテリジェンス』(祥伝社新書, 2015)でも、この「生の情報 vs 判断を加えた情報」という区別が土台になっています。
エンジニアの日常に置き換えると、しっくりきます。サーバから吐き出される生のアクセスログは インフォメーション です。それを集計し、「深夜に特定 IP から管理画面への総当たりが来ている。これは攻撃の予兆だ」と評価した瞬間に、それは インテリジェンス になります。ログを集めているだけでは、まだ情報を持っているとは言えない、というわけです。
情報を得る3つの手段:OSINT / HUMINT / SIGINT
では、その生の情報はどこから得るのか。情報収集の手段は、大きく3つに分類されます。
| 略語 | 正式名 | 情報源 | 身近な例 |
|---|---|---|---|
| OSINT | Open Source INTelligence | 公開されている情報 | 企業サイト・SNS・登記・ニュース |
| HUMINT | HUMan INTelligence | 人的な情報源 | 内部関係者・協力者からの聞き取り |
| SIGINT | SIGnals INTelligence | 通信・電波の傍受 | 通信内容やメタデータの傍受 |
このうち攻撃者がまず頼るのが OSINT です。標的の組織図、担当者の名前、使っている技術スタック、取引先の関係──こうした「攻撃の下ごしらえ」に必要な情報の多くは、わざわざ侵入しなくても、公開情報だけでかなり集まってしまいます。
講義では「OSINT だけで、知りたい情報の 98% が得られる」という数字が紹介されました。ただしこの「98%」は諜報の世界で広く引用される一方、出典には諸説あり、確たる一次情報を私は確認できませんでした。ここでは断定せず「講義ではそう紹介された」と留めておきますが、割合の正確さはさておき、攻撃者は侵入する前に、まず公開情報をなめるように調べているという事実は、開発者として頭に入れておいて損はありません。自社の GitHub リポジトリやエラー画面、求人票の技術要件が、攻撃者にとっての OSINT になっていないか──という視点です。
サイバーインテリジェンスとセキュリティインテリジェンス
「インテリジェンス」を情報セキュリティの文脈に持ち込むと、似て非なる2つの言葉が出てきます。
ひとつが サイバーインテリジェンス です。攻撃者側の営みを指す色が強く、講義では警察庁の表現を引いて「情報通信技術を用いた諜報活動」であり「最も安全で安価なスパイ」だと説明されました。物理的に潜入せずに済み、リスクもコストも小さいからです。
もうひとつが セキュリティインテリジェンス です。こちらは守る側の言葉で、NTT・IBM・講義とで定義は揺れますが、要は「対策に役立つ高度な情報と、それを得るための行動」と押さえれば十分です。むしろ実務で効くのは、この情報を「誰に届けるか」でした(次節)。
ここまでの関係を1枚の図にすると、頭の中が整理できます。3つの手段で生の情報を集め、それに評価を加えてインテリジェンスにし、攻める文脈(サイバー)と守る文脈(セキュリティ)で使い分ける、という流れです。
3分類で「誰向けの情報か」を整理する
セキュリティインテリジェンスは、さらに「誰に届ける情報か」で3つに分けられます。講義は scientia-security.org のブログ記事を引用してこの分類を紹介していました。これがいちばん実務に効く整理だと感じたので、開発現場での対応物まで足して表にします。
| 分類 | 主な宛先 | 中身 | 目的 | 開発現場での対応物 |
|---|---|---|---|---|
| Strategic | 経営者層・リーダ | リスク変化のハイレベルな情報 | 意思決定・投資判断 | 経営向けリスク報告・年次サマリ |
| Operational | セキュリティアーキテクト・管理者・SOC 担当者 | 攻撃者のプロファイル・手法 | 短中期の改善 | 脅威モデリング・設計や運用の見直し |
| Tactical | SOC 担当者 | IOC(攻撃のシグネチャ) | インシデントを未然に防ぐ | WAF / IDS へのシグネチャ・ブロックリスト投入 |
ここで IOC(Indicator of Compromise、侵害の痕跡) とは、「この IP・このハッシュ・このドメインが来たら攻撃の兆候」という具体的な指標のことです。
講義メモの段階では「Operational = 管理者」「Tactical = SOC」と簡略化してしまっていましたが、引用元のスライドでは Operational の宛先に セキュリティアーキテクト・管理者・SOC 担当者、Tactical の宛先に SOC 担当者 が挙げられていました。本記事はスライドの記述に合わせています。
開発者としての実務接続はここです。自分たちが日々見ているログやアラートを、この3分類で仕分けてみると、扱い方が変わります。「四半期のインシデント傾向」は経営に上げる Strategic、「この攻撃者はこういう手口を使う」は設計改善につなぐ Operational、「このドメインからのアクセスは即ブロック」は WAF に落とす Tactical。同じ「セキュリティ情報」でも、宛先を意識すると、経営報告に IOC の羅列を出してしまうようなミスマッチが減ります。
攻撃の"大半"は「人」を狙う(セキュリティ心理学)
ここからが本題です。講義の中心的なメッセージは、シンプルでした。サイバー攻撃の大半は、技術ではなく人を狙う。だからこそ「セキュリティ心理学」という視点が要る、という話です。
なお、本記事のタイトルにある「8〜9割」は、講義で示された表現です。講義ではこの割合の明確な出典までは示されませんでした。そこで近い公開データを当たってみると、Verizon の『2024 Data Breach Investigations Report(DBIR)』では、侵害(breach)の約 68% に人的要素(human element)が関与していると報告されています(悪意ある権限濫用を除いた集計値)。「8〜9割」という具体的な割合には幅がありますが、「侵害の大多数に人が絡んでいる」という方向性そのものは、公開データでも裏付けられます。正確な割合は調査によって振れる、という前提で読んでください。
なぜ技術対策だけでは防げないのか
なぜ人を狙うのかは、攻撃者の合理性で説明がつきます。どれだけコードを堅牢にしても、その堅牢なシステムを運用する人間がだまされたり、内側から裏切ったりすれば、防御は迂回されます。攻撃者からすれば、暗号を破るより人をだます方が、はるかに安くて速いのです。人を狙う攻撃は、大きく2つに分けられます。ひとつは組織の内側からの内部不正、もうひとつは外側から人をだますソーシャルエンジニアリングです。まず内側から見ていきます。
内部不正の動機と類型
内部不正と聞くと「一部の悪い人がやること」と思いがちですが、講義で示されたデータはもっと生々しいものでした。IPA『情報セキュリティ白書2013』(p124)に載っている、内部不正の動機の上位はこうです。
| 順位 | 動機 | 割合 |
|---|---|---|
| 1 | 不当だと思う解雇通告を受けた | 34.2% |
| 2 | 給与や賞与に不満 | 23.2% |
| 3 | 社内の人事評価に不満 | 22.7% |
| 4 | 職場で頻繁にルール違反があった | 20.8% |
| 5 | システム管理がずさんで、顧客情報を簡単に持ち出せると知っていた | 20.1% |
上位は「解雇」「給与」「評価」と、どこの職場にもある不満です。特別に邪悪な動機ではありません。
法政大学の越智啓太教授が示した内部犯罪者の類型論(JSSM 第27回学術講演会資料を参考に構成)では、この動機を2系統に整理します。
| 動機の系統 | 心理学の分類 | 典型的な行動 |
|---|---|---|
| 恨み系 | Expressive(表出的) | システム破壊 / 情報流出II |
| 金銭目的系 | Instrumental(道具的) | システム悪用 / 情報流出I |
なお講義では、情報流出Iは金銭目的での持ち出し、情報流出IIは報復的な暴露、と区別されていました。表の「I / II」はこの2系統に対応しています。
「恨み系」は、感情の発露として行動します。その背景として挙げられていた心理が、開発者にも刺さる話でした。
- ナルシシズム傾向の肥大:「オレ様」化。自分は正当に評価されていない、という肥大した自己像。
- 仮想有能感: 他人を見下すことで得る有能感。
- 相対的剥奪感: 所属グループの中で、自分は相対的に恵まれていない、と感じる感覚。
一方の「金銭目的系」は、感情ではなく損得で動く道具的(Instrumental)な犯行です。ここで効いてくるのが、次に述べる「環境」です。
内側の犯行が起きたときの規模を思い知らされるのが、2014年に発覚したベネッセ個人情報漏えい事件です。委託先(系列会社のシンフォーム)の外部委託者だった元派遣システムエンジニアが、貸与された PC から私用のスマートフォンへデータを転送して持ち出しました。流出した顧客情報は名簿業者を経由し、最大で数千万件規模がジャストシステムなど複数社へ渡りました。報道によれば、犯人は「金が欲しかった」と述べており、まさに金銭目的系の典型です。技術的な脆弱性ではなく、「持ち出せてしまう環境」に置かれた人間が起こした事件でした。
環境が犯行を後押しする
越智教授の整理でとりわけ実務に効くのが、「金銭目的系の犯行は環境が誘発する」という視点です。人だけを疑うのではなく、環境を設計で変えられるという話だからです。誘因として2つが挙げられていました。
- 監視性: 自然な人の目や監査が働いているか。ある仕事が特定個人に完全に任され、監査が実質的に行われていないとき、犯行のハードルは大きく下がります。
- 管理性: 職場が整理整頓され、出退勤やルール遵守がきちんと管理されているか。ゆるい環境は「これくらい大丈夫だろう」を生みます。
ベネッセ事件がまさにそうでした。特定の委託者にデータへのアクセスがゆだねられ、私用端末への持ち出しがチェックされていなかった。監視性が失われていたわけです。これは「悪い人を見抜けなかった」のではなく、「悪いことをしやすい環境を放置していた」という設計の問題です。
開発者としての実務接続は明快です。監視性と管理性は、そのまま設計に翻訳できます。ある権限や操作が特定の1人に完結していないか(職務分掌。1人に権限を集中させない分担)、本番データへのアクセスに監査ログが残っているか、その操作を誰かがレビューする経路があるか。「あの人は信用できるから」で権限を集中させることが、実は監視性を下げている、という視点が持てるようになります。
IPA「組織における内部不正防止ガイドライン」を開発・運用に落とす
では具体的にどう手を打つのか。IPA が公開している「組織における内部不正防止ガイドライン」が、実践的な指針をまとめています。技術的な要点を3つに絞ると、こうです。
- 重要情報の明確化と、適切なアクセス権限の付与
- 重要情報の持ち出し・可搬媒体等の持ち込みの監視
- 定期的な操作履歴の監視・監査
これを開発・運用の言葉に翻訳すると、日々の判断リストになります。
- 1 → 最小権限(least privilege)と RBAC(ロールで権限を束ねる方式)。 まず「どれが重要情報か」を決め、全員に一律のアクセスを渡さない。ロールで絞り、必要な人に必要なぶんだけ渡します。
- 2 → 持ち出し経路の監視。 本番 DB のダンプ、可搬媒体、私用端末への転送といった経路を監視・制御します(ベネッセ事件の教訓そのものです)。
- 3 → 監査ログと定期レビュー。 「誰が・いつ・どのデータに触れたか」を残し、定期的に見直します。ログは取るだけでなく、見る運用とセットにして初めて意味を持ちます。
そしてもうひとつ、地味だけれど効くのが 退職者・異動者のアカウント無効化です。動機の第1位が「不当だと思う解雇通告」だったことを思い出してください。退職手続きとアクセス権の剥奪が連動していなければ、いちばん動機を持った人が、いちばん危険なタイミングでアクセスを持ち続けることになります。
ソーシャルエンジニアリング:技術の外側から入ってくる
内側の話が終わったので、次は外側です。ソーシャルエンジニアリング(Social Engineering、SE)は、技術的な脆弱性ではなく、人間の心理や行動の隙を突いて情報を得たり、不正な操作をさせたりする攻撃の総称です。
狭義と広義
講義では、この言葉の定義を Wikipedia(2024年9月21日確認)から引きつつ、狭義と広義に分けて整理していました。
狭義のソーシャルエンジニアリングは、古典的な手口を指します。
- なりすまし: システム管理者や取引先を装って、パスワードなどを聞き出す。
- ショルダーハッキング: 肩越しにパスワード入力やディスプレイをのぞき見る。
古典的ですが、なりすましの威力は今も色あせません。講義で紹介されていた古典的なメール例(三輪信雄・新井悠『ネットワーク攻撃詳解』ソフト・リサーチ・センター, 2002 を参考に再構成)が分かりやすいので、雰囲気を再現します。
差出人: root@example.com ← システム管理者を詐称
件名: 【重要】至急パスワードを変更してください
サーバへの侵入の形跡が確認されました。
セキュリティのため、直ちにパスワードを
「SAFETY123」に変更してください。
このメールが突いているのは2つの心理です。ひとつは 権威(システム管理者=偉い人の指示だから従う)、もうひとつは 緊急性(至急・侵入されている、と急かされて冷静さを失う)。攻撃者は "SAFETY123" という固定値に変えさせることで、その後いつでもログインできる状態を作ります。技術的にはただのパスワード変更依頼ですが、人の心理を突くことで成立しています。
一方の 広義のソーシャルエンジニアリングは、もっと広く「攻撃成功の原因が、人間の心理的な隙・行動のミスにあるもの全般」を指します。この視点で見ると、いろいろな攻撃が「結果として何を得たか」で分類できます。
| 突いた隙の結果 | 分類される攻撃 |
|---|---|
| パスワードを入手した | 狭義のソーシャルエンジニアリング |
| 不正な送金をさせた | BEC(ビジネスメール詐欺) |
| 偽サイトへ誘導した | フィッシング |
つまり BEC もフィッシングも、大きくは「人をだます攻撃」という同じ根から生えています。
BEC(ビジネスメール詐欺)とディープフェイク詐欺
BEC(Business Email Compromise、ビジネスメール詐欺)は、取引先や経営者になりすまし、偽の請求書や送金指示で、振込先を攻撃者の口座に変えさせる攻撃です。標的は経理・財務の担当者で、被害額が大きくなりがちです。
日本での有名な事例が、JAL(日本航空)の被害です。2017年12月に公表されたもので、通常やり取りしている取引先になりすましたメールで、航空機のリース料の「訂正版」請求書などにより偽の振込先(香港の口座)を指定され、合計約3億8000万円(うちリース料案件が約3億6000万円)を送金してしまいました。セキュリティ意識が低い会社の話ではありません。大企業でも、業務の流れに紛れ込んだ1通のメールで突破されるというのが、この事件の怖いところです。
さらに近年、BEC は AI と結びついて凶悪化しています。ディープフェイクを使った詐欺です。
- 2019年3月・英国のAI音声CEO詐欺: 英国のエネルギー会社の CEO が、ドイツ親会社の CEO を装った AI 音声の電話にだまされ、約22万ユーロ(当時のレートで約24万3千ドル)を送金しました。保険会社 Euler Hermes は、これを AI 音声のなりすましによる詐欺の初の既知の事例とみられる、としています。
- 2024年・香港のディープフェイクCFO詐欺: 英エンジニアリング大手 Arup の香港拠点で、ビデオ会議に登場した CFO や同僚が全員ディープフェイクという手口により、担当者が複数回にわたって計 2億香港ドル(約38億円)を送金してしまいました。
音声も映像も偽装できる時代になり、「本人の顔と声で指示された」ことは、もはや本人確認になりません。
開発者・運用者としての実務接続は、この一点に尽きます。送金や重要な操作の指示は、指示が来たのと同じ経路で確認しない。 メールで来た振込先変更を、そのメールへの返信で確認しても意味がありません(攻撃者がその受信箱を握っているかもしれない)。電話番号を台帳で引き直して電話する、承認を複数人にする、金額の閾値でフローを分岐させる──こうした多重化を業務フローとシステムに作り込むのが、開発側からできる BEC 対策です。
たとえば「振込先変更」を、こんな承認フローに落とし込みます。
この図のポイントは、確認の経路を「指示が来た経路」から強制的に切り離していることです。人が「たぶん本物だろう」と判断する余地を、フローの分岐そのもので消しています。「注意喚起」だけに頼らない、というのはこういうことです。
フィッシングと派生
フィッシング(Phishing)は、正規のサービスを装った偽サイトへ誘導し、ID・パスワード・カード情報などを入力させて盗む攻撃です。メールが主流でしたが、いまは経路が多様化しています。
| 派生 | 経路 | ひとことで |
|---|---|---|
| スミッシング(Smishing) | SMS(ショートメッセージ) | 「荷物の不在通知」などを装う SMS 版フィッシング |
| クイッシング(Quishing) | QR コード | 悪性 URL を QR 画像に隠す。メールフィルタで検知しにくい |
| Man-in-the-Browser | ブラウザ内のマルウェア | 通信そのものを乗っ取り、表示や取引を改ざんする |
| サポート詐欺 | 偽の警告画面・電話 | 「ウイルス感染」と偽り、電話させて操作・課金させる |
特に開発者として気に留めたいのが Man-in-the-Browser(MitB)です。これはブラウザに感染したマルウェアが、利用者と Web サイトの「間」に居座り、通信を復号したあとの中身を書き換える攻撃です。厄介なのは、HTTPS で通信が暗号化されていても防げないことです。暗号化はブラウザとサーバの区間を守りますが、MitB はその内側(ブラウザの中)にいるからです。利用者の画面には正しい残高や送金先が表示されたまま、裏で取引内容だけがすり替えられる、といったことが起こり得ます。
フィッシング対策として、講義でも強調され、私も改めて肝に銘じたのが「見た目にだまされない」ことです。
- HTTPS(鍵マーク)は "安全" の証明ではありません。 鍵マークは「通信が暗号化されている」ことを示すだけで、「そのサイトが正当だ」とは保証しません。偽サイトも HTTPS を使えます。
-
IP アドレス直書きの URL は危険信号です。
https://192.0.2.1/loginのような URL は、正規サービスがまず使いません。 -
似せたドメインに注意。
gooogle.com(o が多い)、amaz0n.co(o が 0、TLD も違う)のように、正規ドメインをわずかにいじったタイポスクワッティングは、ぱっと見では気づけません。
なお、開発する側としては、自社がなりすまされる側になる可能性も忘れないでください。送信ドメイン認証(SPF / DKIM / DMARC)を正しく設定しておくことは、自社を装ったフィッシングメールが「正規に見えてしまう」のを防ぐ、開発・運用側の基本的な備えです。
開発者・運用者としてできること
ソーシャルエンジニアリングに対して作る側・運用する側からできることは、SE 特有の一点に集約できます。「本人らしさ」を信用しない導線を作ることです(監査ログや最小権限は内部不正の節で触れたとおりです)。
- 別経路での確認: 重要操作(送金・権限変更)の指示は、指示が来たのと別の経路で本人に確認する。
- 多段承認: 金額や影響度の閾値で承認者を増やし、1人の判断で完結させない。
- 送信ドメイン認証: SPF / DKIM / DMARC を設定し、自社がなりすまされる側になるのを防ぐ。
「人はだまされる」という前提を、精神論ではなくシステムの制約として組み込む。これが、セキュリティ心理学を開発の現場に持ち帰るときのいちばんの成果だと感じました。
まとめ
CySec「3IN」の前編として、「攻撃の8〜9割は人を狙う」という切り口から、インテリジェンス・内部不正・ソーシャルエンジニアリングを見てきました。幹を3点で再掲します。
- 攻撃者はまず公開情報で人を下調べする。 なりすましも詐欺も OSINT(公開情報)による下調べから始まります。だから防御側も、扱う情報を Strategic / Operational / Tactical の3分類で「誰向けか」を仕分けると、ログやアラートの扱いが整理できます。
- 攻撃の多くは人を経由する。 内部不正には「恨み系 / 金銭目的系」という動機の型があり、監視性と管理性という環境が犯行を後押しします。だから対策は「人を疑う」より「環境を設計で変える」──最小権限・監査ログ・職務分掌・退職者アカウントの無効化です。
- ソーシャルエンジニアリングは実装で受け止められる。 BEC もフィッシングも「人の隙」を突く攻撃です。別経路での確認・多段承認・送信ドメイン認証という作る側の対策に落とせます。
いちばん伝えたかったのは、セキュリティは「技術の外側」も含めて初めて成立するということです。少し前の私は、セキュリティをコードとインフラの問題だと閉じて考えていました。でも実際には、攻撃の大半は人を経由します。だからといって「人に気をつけてもらう」で終わらせるのではなく、人がだまされ、人が魔が差す前提で、環境とフローを設計する。それが開発者にできる、いちばん現実的な人への対策でした。「へえ」で終わらせず、明日のレビューで「この機能、人がだまされたら何が起きる?」と一言問える。この記事がそのきっかけになればうれしいです。
後編(規範と社会:倫理・法・フェイク)では、「そもそも攻撃してはいけないのはなぜか」「ランサムの身代金は払うべきか」といった、倫理・法・フェイク情報の話に進みます。
ここまで読んでいただき、ありがとうございました。私自身まだ学習中の身なので、間違いがあれば指摘していただけると助かります。
参考
- セキュリティインテリジェンスの3分類(Strategic / Operational / Tactical): scientia-security.org「Cyber Threat Intelligenceとは何か?(2018年度版)」その2・Tactical https://www.scientia-security.org/entry/2018/02/05/080540 / その3・Strategic・Operational https://www.scientia-security.org/entry/2018/02/06/065530
- 小谷賢『インテリジェンス』ちくま学芸文庫, 2012
- 伊東寛『サイバー・インテリジェンス』祥伝社新書, 2015
- 三輪信雄・新井悠『ネットワーク攻撃詳解』ソフト・リサーチ・センター, 2002
- 警察庁「サイバー空間をめぐる脅威の情勢等」 https://www.npa.go.jp/publications/statistics/cybersecurity/
- IPA「組織における内部不正防止ガイドライン」 https://www.ipa.go.jp/security/announce/20140710-insider.html
- IPA『情報セキュリティ白書2013』(内部不正の動機、p124)
- Verizon「2024 Data Breach Investigations Report(DBIR)」 https://www.verizon.com/business/resources/reports/dbir.html
- JAL のビジネスメール詐欺被害(2017年12月): ITmedia「JAL もだまされた こんなに怖い『ビジネスメール詐欺』」 https://www.itmedia.co.jp/business/articles/1801/10/news097.html
- 香港のディープフェイク CFO 詐欺(2024年): CNN.co.jp「会計担当が38億円を詐欺グループに送金、ビデオ会議のCFOは偽物」 https://www.cnn.co.jp/world/35214839.html
- 英国の AI 音声 CEO 詐欺(2019年): Forbes「A Voice Deepfake Was Used To Scam A CEO Out Of $243,000」 https://www.forbes.com/sites/jessedamiani/2019/09/03/a-voice-deepfake-was-used-to-scam-a-ceo-out-of-243000/
- ベネッセ個人情報漏えい事件(2014年): ベネッセお客様本部「事故の概要」 https://www.benesse.co.jp/customer/bcinfo/01.html
用語・数値についての補足
講義メモやスライドの転記由来で、本記事にあたり確認・補正した点を残しておきます。
- 「8〜9割」(タイトル)と「OSINT で 98%」は、いずれも講義での表現です。 一次情報では確認できず断定を避けました(本文参照)。「8〜9割」だけは、近い公開データの Verizon DBIR 2024(侵害の約68%に人的要素が関与)で方向性のみ裏付けています。
- 各事件の年次・金額(JAL 約3億8000万円=2017年12月公表、香港 Arup の約38億円=2024年、英国の約22万ユーロ=2019年3月、ベネッセ=2014年7月発覚)は、上記の報道・公式情報で確認しています。
あわせて読みたい
- 本シリーズ後編:ランサムの身代金は払うべきか ── エンジニアのためのセキュリティ倫理・法・フェイク入門【CySec復習ログ 3IN#2】(規範と社会:倫理・法・フェイク)
同じ CySec の学びを1回ずつ記事にした「復習ログ」シリーズも書いています(著者: @amu-kuroneko)。内部不正やインシデント対応まわりに関心があれば、あわせてどうぞ。