サイバー攻撃の基礎とAI — 第7回
180日ロードマップと自己点検チェックリスト
導入の順序と、機能しているかを点検し続けるための道具。
この回の結論:被害の多い入口から先に塞ぐ。最初の30日で入口を、90日で台帳と仕組みを、180日で検知と復旧を固める。その時点でSCS評価制度★3の26件すべてに着手している。あとは毎年の点検で、機能し続けていることを確かめる。
第4〜6回では、対策を領域ごとに扱いました。最終回のこの回は、それをどの順に入れるかと、入れた対策が機能しているかを点検し続ける方法をまとめます。あわせて、取引先から求められることが増えているSCS評価制度★3の要求事項と、このシリーズの対応を示します。
数値の基準日:2026年10月27日
統計は基準日時点の最新版です。事実・数値には [ ] で出典番号を付け、記事末尾に原文へのリンクを載せています。原文で裏付けられない推奨は「本ガイドの提案」と明記しています。
180日
基本対策の導入期間の目安(専任1名程度の組織)
28項目
ロードマップのやること
26件
SCS評価制度★3の要求事項(評価基準は81件)
65項目
自己点検チェックリスト(うち★3対応28項目)
1.導入の順序の考え方
順序は、被害の多い入口から先に塞ぐように組んでいます(本ガイドの提案)。国内のランサムウェア被害の侵入経路は、2021〜2025年の5年計で82.1%がVPN機器とリモートデスクトップでした[J1]。だから最初の30日は、公開面・パッチ・MFA・バックアップに集中します。期間は専任1名程度の組織を想定した目安で、規模と既存の状況に合わせて調整してください。
2.最初に決めること — 推進体制・方針・社内ルール
目的:セキュリティ対策を誰が責任を持って進めるかを決め、全員が従う方針とルールを文書にする。第4〜6回の対策は、ここで決めた担当者とルールの上で運用されます。
なぜ必要か
- SCS評価制度★3は「ガバナンスの整備」を最初の区分に置き、推進体制、守秘義務、方針の3つを要求しています[J7b]。
- 国家サイバー統括室は「サイバーセキュリティ対策を経営課題と位置づけ」ることを求めています[J8]。
- 台帳・手順・点検は、担当者と見直しの頻度が決まっていないと維持されません(本ガイドの提案)。
やること
- 推進体制を決める(★3 1-2-1):セキュリティを統括する役員(CISOを置く会社ではCISO)とセキュリティ担当部署の役割・責任を定め、平時の連絡先リストを作り、年1回以上点検します[J7b]。1人情シスの組織でも、統括する役員と担当者を文書で決めます(本ガイドの提案)。
- 守秘義務のルール(★3 1-2-3):役員、従業員、派遣社員、受入出向者を対象に守秘義務のルールを定め、入社時・社外要員の受入れ時に説明します[J7b]。
- セキュリティ対応方針(★3 1-3-1):自社のセキュリティ対応方針を定め、全員が最新版を参照できるようにし、改正時に周知します[J7b]。IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版の付録に、基本方針と関連規程のサンプルがあります[J6]。
- 社内ルールの体系:第4〜6回で作るルール(機器・ソフトウェアの管理ルール、ID・パスワード・アクセス権のルール、機密区分のルール、インシデント対応手順など)を、方針の下の規程としてまとめます(本ガイドの提案)。
確認方法
- 統括役員・担当部署の役割と連絡先が文書化され、直近1年以内に点検されている
- 守秘義務のルールがあり、入社時・受入れ時の説明が記録されている
- セキュリティ対応方針が、全員の参照できる場所にある
3.30日・90日・180日でやること
表の「該当する回」から、それぞれの手順と確認方法に移れます。番号は通し番号です(本ガイドの提案)。
最初の30日:入口を塞ぐ
| # | やること | 該当する回 |
|---|---|---|
| 1 | セキュリティを統括する役員と担当者を決める | 第7回 2節 |
| 2 | 外部公開面の一覧を作り、不要な公開(RDP、管理画面)を止める | 第4回 2節、第4回 5節 |
| 3 | VPN装置・公開サーバーを最新版にする。KEV・JPCERT/CC注意喚起の確認を毎日の業務にする | 第4回 4節 |
| 4 | 管理者・VPN・メール・クラウドの全アカウントにMFAを設定する。例外を一覧化する | 第4回 3節 |
| 5 | Microsoft 365/Google Workspaceのレガシー認証を止める(セキュリティの既定値など) | 第4回 3節 |
| 6 | 重要データのオフラインまたはイミュータブルなバックアップを1つ確保する | 第5回 6節 |
| 7 | インシデント時の連絡先一覧を作る | 第6回 1節 |
90日まで:台帳と仕組みを作る
| # | やること | 該当する回 |
|---|---|---|
| 8 | ハードウェア・ソフトウェア・アカウント・データ・委託先の台帳を作る | 第4回 2節 |
| 9 | パッチの優先度と期限を決め、PCの自動更新を全台で有効にする | 第4回 4節 |
| 10 | 管理者アカウントを分け、利用者のローカル管理者権限を外す | 第4回 3節、第5回 2節 |
| 11 | マルウェア対策・EDRを全端末に入れ、改ざん防止を有効にする | 第5回 2節 |
| 12 | SPF・DKIM・DMARC(p=none)を設定し、レポートの確認を始める | 第5回 3節 |
| 13 | 送金・振込先変更の確認手順と、生成AIの利用ルールを決める | 第6回 3節 |
| 14 | パスワードの設定・管理のルールを★3とNIST SP 800-63B-4に合わせて定め、周知する | 第4回 3節 |
| 15 | セキュリティ対応方針と守秘義務のルールを定め、周知する | 第7回 2節 |
| 16 | ID・管理者ID・アクセス権・入室権限の申請・承認の手続を定める | 第4回 3節 |
180日まで:検知と復旧を固める
| # | やること | 該当する回 |
|---|---|---|
| 17 | ログを別の場所に集め、通知を設定する | 第5回 7節 |
| 18 | 復元テストを実施し、目標時間内に戻せるか確認する | 第5回 6節 |
| 19 | インシデント対応手順書を作り、机上訓練をする | 第6回 1節 |
| 20 | DMARCをquarantine→rejectへ進める | 第5回 3節 |
| 21 | 委託先契約を見直し、委託先アカウントに期限とMFAを付ける | 第6回 2節 |
| 22 | データの保存期間を決め、不要なデータを削除する。パスワードの保存方式を確認する | 第5回 5節 |
| 23 | クラウドの共有設定・OAuth連携・APIキーを棚卸しする | 第5回 4節 |
| 24 | EOL機器の置き換えと、VPNのZTNA等への移行の計画を立てる | 第4回 4節、第4回 5節 |
| 25 | 機密区分の管理ルールを定める | 第5回 5節 |
| 26 | 重要システムの目標復旧レベルを決め、リストア手順書と遠隔地バックアップを整える | 第5回 6節 |
| 27 | 機密情報を共有する取引先と、取扱いとインシデント時の役割・責任を取り決める | 第6回 2節 |
| 28 | 全員にインシデント対応の教育を行い、記録する | 第6回 1節 |
180日の時点で、★3の26件すべてに着手している
★3の自己評価を受ける場合は、5節の対応表と★3の評価基準の原文[J7b]で、評価基準81件を1件ずつ確認してください。このページの★3の記述は評価基準の要約です。
4.その後 — 維持するための点検
5.SCS評価制度★3との対応
経済産業省などが構築を進める「サプライチェーン強化に向けたセキュリティ対策評価制度」(SCS評価制度)は、発注企業が取引契約の中で受注側に必要な★を示し、対策の実施を促して確認する形を想定しています[J7]。★3は要求事項26件・評価基準81件からなり、★4は43件です[J7b][J7]。
IPAの中小企業向けガイドライン第4.0版は、一つ星(情報セキュリティ6か条)→二つ星(自社診断25項目)→SCS★3→★4の順に段階を示しています[J6]。6か条(OS・ソフトを最新に、ウイルス対策、パスワード強化、共有設定の見直し、バックアップ、脅威・手口を知る)は、このシリーズの第4回・第5回・第6回に当たります。
★3の要求事項(全26件)と、このシリーズの対応
要求事項名とNIST CSFの機能はIPA「★3・★4 要求事項・評価基準」(2026年3月27日版)の記載です[J7b]。番号は連番ではありません(★4だけの要求事項が間に入るため)。CIS Controls v8.1との対応は、各回の冒頭に示しています[G13]。
| ★3 No. | 要求事項名 | 区分 | NIST CSF | このシリーズ |
|---|---|---|---|---|
| 1-2-1 | セキュリティ推進活動部門 | ガバナンスの整備 | 統治(GV) | 第7回 2節 |
| 1-2-3 | 守秘義務のルール | ガバナンスの整備 | 統治(GV) | 第7回 2節 |
| 1-3-1 | セキュリティ対応方針の策定 | ガバナンスの整備 | 統治(GV) | 第7回 2節 |
| 2-1-1 | 取引先とのビジネス又はシステム上の関係 | 取引先管理 | 統治(GV) | 第4回 2節、第6回 2節 |
| 2-1-2 | 機密情報の取扱い | 取引先管理 | 統治(GV) | 第6回 2節 |
| 2-1-4 | セキュリティインシデント発生時の役割・責任 | 取引先管理 | 統治(GV) | 第6回 2節 |
| 3-1-1 | 情報機器、OS及びソフトウェアに関する情報の把握 | リスクの特定 | 識別(ID) | 第4回 2節 |
| 3-1-2 | ネットワークに関する情報の把握 | リスクの特定 | 識別(ID) | 第4回 2節 |
| 3-1-3 | 外部情報サービスの管理 | リスクの特定 | 識別(ID) | 第5回 4節 |
| 3-1-4 | 機密区分に応じた情報の管理 | リスクの特定 | 識別(ID) | 第4回 2節、第5回 5節 |
| 4-1-1 | ユーザIDの管理手続 | 攻撃等の防御 | 防御(PR) | 第4回 3節 |
| 4-1-2 | 管理者IDの管理手続 | 攻撃等の防御 | 防御(PR) | 第4回 3節 |
| 4-1-3 | 認証の強度・実装方法の決定 | 攻撃等の防御 | 防御(PR) | 第4回 3節 |
| 4-1-4 | アカウントロック制御 | 攻撃等の防御 | 防御(PR) | 第4回 3節、第5回 2節 |
| 4-1-5 | パスワード設定ルール | 攻撃等の防御 | 防御(PR) | 第4回 3節、第4回 5節 |
| 4-1-6 | パスワード管理ルール | 攻撃等の防御 | 防御(PR) | 第4回 3節 |
| 4-1-7 | アクセス権の管理ルール | 攻撃等の防御 | 防御(PR) | 第4回 3節 |
| 4-2-2 | セキュリティインシデント発生時の教育・訓練 | 攻撃等の防御 | 防御(PR) | 第6回 1節 |
| 4-3-4 | 適切なバックアップ | 攻撃等の防御 | 防御(PR) | 第5回 6節 |
| 4-4-1 | 情報機器、OS及びソフトウェアの安全な構成 | 攻撃等の防御 | 防御(PR) | 第5回 2節 |
| 4-4-4 | セキュリティパッチ・アップデートの手続 | 攻撃等の防御 | 防御(PR) | 第4回 4節 |
| 4-4-5 | マルウェア感染からの保護 | 攻撃等の防御 | 防御(PR) | 第5回 2節 |
| 4-5-1 | ネットワーク境界防護 | 攻撃等の防御 | 防御(PR) | 第4回 5節 |
| 5-1-1 | ネットワーク接続・データの監視 | 攻撃等の検知 | 検知(DE) | 第5回 7節 |
| 6-1-1 | インシデント対応手順 | インシデントへの対応 | 対応(RS) | 第6回 1節 |
| 7-1-1 | 事業継続要件に沿った復旧準備 | インシデントからの復旧 | 復旧(RC) | 第5回 6節 |
6.★3を超えて推奨する対策
★3は「広く知られた脆弱性等を狙う一般的な攻撃」を想定した最低ラインです[J7]。このシリーズは★3を最低ラインとしつつ、第2回の事例と統計から、次の対策を追加で推奨しています。これらは★3の自己評価では求められません。
| # | 対策 | 該当する回 | 追加する理由 |
|---|---|---|---|
| 1 | 公開面の削減(RDP・管理画面を公開しない)、VPNの更新とZTNA等への移行 | 第4回 5節 | 侵入経路の5年計82.1%がVPN機器とリモートデスクトップ[J1] |
| 2 | インターネットから使える全ログインへのMFA、フィッシング耐性のある方式 | 第4回 3節 | ★3のMFA必須範囲は「重要な機密情報を扱うクラウドサービス」。アスクルの事例はMFAのない1アカウントが入口[J17] |
| 3 | 悪用確認済み(KEV等)の脆弱性を、14日より短い期限で適用 | 第4回 4節 | 悪用はパッチ公開の平均7日前に始まる(推定)[G2] |
| 4 | オフライン・イミュータブルなバックアップと復元テスト | 第5回 6節 | バックアップから復元できなかった組織が72.5%(2026年上半期、29/40件)[J1] |
| 5 | ログの集約・保全 | 第5回 7節 | ログの削除で原因究明が困難になった事例[J17] |
| 6 | メール認証(SPF・DKIM・DMARC) | 第5回 3節 | 行政の要請[J14]、大手メールサービスの送信者要件[G19b] |
| 7 | データの保存期間と削除、パスワードのハッシュ保存、保存時暗号化 | 第5回 5節 | 国家サイバー統括室の要請[J8]、KDDIの事例[J12] |
| 8 | 送金・依頼の別経路確認、生成AIの利用ルール | 第6回 3節 | AIによる偽装の高度化(第3回)、RIZAPの事例[J20] |
★4だけの要求事項(17件)には、ログの取得、データの暗号化、サポート期限の切れたOS・ソフトウェアへの対策、リモートワークのルールなど、この追加推奨と同じ領域のものが含まれます[J7b]。★4を目指す組織にとっては、追加推奨が★4への準備にもなります。
7.自己点検チェックリスト
第4〜7回の「確認方法」に、★3の評価基準の要点を加えた点検項目です。★3の付いた項目は★3に対応します。★3の自己評価そのものは、評価基準の原文[J7b]で行ってください。各分野の右上のリンクから、手順の説明に移れます。
全項目0/65
★3の項目0/28
チェックした状態は、このブラウザの中にだけ保存されます(送信はされません)。
シリーズのおわりに
攻撃の手口はAIで速く、安くなりましたが、入口の多くはこれまでと同じ、公開された機器と、盗まれた認証情報と、未適用のパッチです。基本対策を順に入れ、毎年点検する。このシリーズとチェックリストは、そのための道具です。
Summary
この記事の要点
- 1被害の多い入口から先に塞ぐ。最初の30日は公開面・パッチ・MFA・手の届かないバックアップ・連絡先一覧に集中する。
- 2最初に、統括する役員と担当者、方針、守秘義務のルールを文書で決める。台帳と点検は、担当と頻度が決まっていないと続かない。
- 390日で台帳と仕組み(パッチの期限、管理者の分離、EDR、DMARC、ルール)、180日で検知と復旧(ログ、復元テスト、訓練、委託先)を固める。
- 4180日の時点でSCS評価制度★3の26件すべてに着手している。自己評価は評価基準81件の原文で1件ずつ確認する。
- 5★3は最低ライン。公開面の削減、全ログインへのMFA、短いパッチ期限、手の届かないバックアップ、ログの保全などを追加で推奨する。
- 6維持は毎年の点検で。台帳・委託先・復元テスト・訓練・教育は年1回以上、ログは四半期ごとに確認する。
Sources
出典
本文の事実・数値は、以下の官公庁・公的機関・標準化団体・ベンダー公式の原文に基づいています。数値は各出典の公開時点、または2026年10月27日の集計時点のものです。
- [J1]警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」(2026年9月)
- [J6]IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版(2026-03-27)
- [J7]経済産業省・国家サイバー統括室「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」(2026-03-27)
- [J7b]IPA SCS評価制度「★3・★4 要求事項・評価基準」(2026-03-27版)
- [J8]国家サイバー統括室「不正アクセスによる漏えい等の事案を踏まえた対応について」(2026-10-09)
- [J12]個人情報保護委員会「KDDIのメールサービスに係る事案について」(2026-08-19)
- [J14]総務省「フィッシングメール対策の強化に関する要請」(2025-09-01)
- [J17]アスクル「ランサムウェア攻撃の影響調査結果および安全性強化に向けた取り組みのご報告(第13報)」(2025-12-12)
- [J20]RIZAP 公表(2026-09-03)
- [G2]Mandiant「M-Trends 2026」(2026-03-23)
- [G13]CIS「Critical Security Controls v8.1」
- [G19b]Google「メール送信者のガイドライン」
FAQ
よくある質問
専任1名程度の組織を想定した目安です。規模と既存の状況に合わせて調整してください。順序は、被害の多い入口(VPN機器・リモートデスクトップ、MFAのないアカウント、未適用のパッチ)から先に塞ぐように組んでいます。期間を延ばす場合も、最初の30日の7項目は優先することを勧めます。
経済産業省などが構築を進める「サプライチェーン強化に向けたセキュリティ対策評価制度」の段階の一つです。★3は要求事項26件・評価基準81件からなり、広く知られた脆弱性などを狙う一般的な攻撃を想定した最低ラインとされています。発注企業が取引契約の中で受注側に必要な★を示す形が想定されており、有効期間は1年で、毎年自己評価を行います。
このガイドは★3の26件すべてに対応する対策を含みますが、自己評価は★3の評価基準81件の原文で1件ずつ確認してください。本文の★3の記述は評価基準の要約です。また、このガイドは★3を最低ラインとし、★3では求められない対策(公開面の削減、全ログインへのMFA、手の届かないバックアップなど)も推奨しています。
チェックした状態は、お使いのブラウザの中にだけ保存されます。サーバーには送信されません。別の端末やブラウザでは共有されないので、組織で記録を残す場合は、点検の結果を社内の文書に転記してください。
Next
シリーズの前後
AIの導入とセキュリティを、あわせて相談したい方へ
homulaは、AIエージェントを業務に導入する企業に向けて、統制ポリシー・権限・監査ログの設計から運用までを支援しています。AIを載せる前提となる基盤の点検も含めてご相談ください。