homula

サイバー攻撃の基礎とAI — 第7回

180日ロードマップと自己点検チェックリスト

導入の順序と、機能しているかを点検し続けるための道具。

15〜20分対象: IT・情報システム担当(専門知識は前提にしません)最終更新: 2026年10月

この回の結論:被害の多い入口から先に塞ぐ。最初の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名程度の組織を想定した目安で、規模と既存の状況に合わせて調整してください。

0日30日90日180日最初の30日7項目入口を塞ぐ・統括役員・担当者・不要な公開を止める・VPN・公開機器を最新に・全アカウントにMFA・手の届かないバックアップ90日まで9項目台帳と仕組みを作る・5つの台帳・パッチの優先度と期限・管理者の分離・EDR・DMARC(p=none)・方針・ルールの周知180日まで12項目検知と復旧を固める・ログの集約と通知・復元テスト・訓練・DMARCをrejectへ・委託先契約の見直し・★3の26件すべてに着手その後毎年維持する・台帳・委託先の確認・復元テスト・訓練・教育・ログの定期確認・★3の自己評価
図1180日ロードマップの全体像(本ガイドの提案)。各期間の項目は3節の表のとおり。

2.最初に決めること — 推進体制・方針・社内ルール

目的:セキュリティ対策を誰が責任を持って進めるかを決め、全員が従う方針とルールを文書にする。第4〜6回の対策は、ここで決めた担当者とルールの上で運用されます。

なぜ必要か

  • SCS評価制度★3は「ガバナンスの整備」を最初の区分に置き、推進体制、守秘義務、方針の3つを要求しています[J7b]。
  • 国家サイバー統括室は「サイバーセキュリティ対策を経営課題と位置づけ」ることを求めています[J8]。
  • 台帳・手順・点検は、担当者と見直しの頻度が決まっていないと維持されません(本ガイドの提案)。
推進体制統括する役員+担当部署・担当者★3 1-2-1セキュリティ対応方針全員が最新版を参照できる場所に置き、改正時に周知する★3 1-3-1規程(方針の下に置くルール)守秘義務のルール★3 1-2-3機器・ソフトウェアの管理ルールID・パスワード・アクセス権のルール機密区分のルールインシデント対応手順台帳・手順書・点検の記録第4〜6回で作るもの年1回以上点検し、方針と規程を見直す。1人情シスの組織でも、統括する役員と担当者は文書で決める(本ガイドの提案)。
図2推進体制・方針・規程・記録の関係。★3の番号は要求事項の番号。

やること

  1. 推進体制を決める(★3 1-2-1):セキュリティを統括する役員(CISOを置く会社ではCISO)とセキュリティ担当部署の役割・責任を定め、平時の連絡先リストを作り、年1回以上点検します[J7b]。1人情シスの組織でも、統括する役員と担当者を文書で決めます(本ガイドの提案)。
  2. 守秘義務のルール(★3 1-2-3):役員、従業員、派遣社員、受入出向者を対象に守秘義務のルールを定め、入社時・社外要員の受入れ時に説明します[J7b]。
  3. セキュリティ対応方針(★3 1-3-1):自社のセキュリティ対応方針を定め、全員が最新版を参照できるようにし、改正時に周知します[J7b]。IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版の付録に、基本方針と関連規程のサンプルがあります[J6]。
  4. 社内ルールの体系:第4〜6回で作るルール(機器・ソフトウェアの管理ルール、ID・パスワード・アクセス権のルール、機密区分のルール、インシデント対応手順など)を、方針の下の規程としてまとめます(本ガイドの提案)。

確認方法

  • 統括役員・担当部署の役割と連絡先が文書化され、直近1年以内に点検されている
  • 守秘義務のルールがあり、入社時・受入れ時の説明が記録されている
  • セキュリティ対応方針が、全員の参照できる場所にある

3.30日・90日・180日でやること

表の「該当する回」から、それぞれの手順と確認方法に移れます。番号は通し番号です(本ガイドの提案)。

最初の30日:入口を塞ぐ

#やること該当する回
1セキュリティを統括する役員と担当者を決める第7回 2節
2外部公開面の一覧を作り、不要な公開(RDP、管理画面)を止める第4回 2節、第4回 5節
3VPN装置・公開サーバーを最新版にする。KEV・JPCERT/CC注意喚起の確認を毎日の業務にする第4回 4節
4管理者・VPN・メール・クラウドの全アカウントにMFAを設定する。例外を一覧化する第4回 3節
5Microsoft 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節
12SPF・DKIM・DMARC(p=none)を設定し、レポートの確認を始める第5回 3節
13送金・振込先変更の確認手順と、生成AIの利用ルールを決める第6回 3節
14パスワードの設定・管理のルールを★3とNIST SP 800-63B-4に合わせて定め、周知する第4回 3節
15セキュリティ対応方針と守秘義務のルールを定め、周知する第7回 2節
16ID・管理者ID・アクセス権・入室権限の申請・承認の手続を定める第4回 3節

180日まで:検知と復旧を固める

#やること該当する回
17ログを別の場所に集め、通知を設定する第5回 7節
18復元テストを実施し、目標時間内に戻せるか確認する第5回 6節
19インシデント対応手順書を作り、机上訓練をする第6回 1節
20DMARCをquarantine→rejectへ進める第5回 3節
21委託先契約を見直し、委託先アカウントに期限とMFAを付ける第6回 2節
22データの保存期間を決め、不要なデータを削除する。パスワードの保存方式を確認する第5回 5節
23クラウドの共有設定・OAuth連携・APIキーを棚卸しする第5回 4節
24EOL機器の置き換えと、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.その後 — 維持するための点検

対策は、入れた後に崩れていきます。アカウントは増え、機器は入れ替わり、委託先は変わります。年間の点検項目は次のとおりです(頻度は本ガイドの提案)。

  • 年1回以上:台帳の更新、委託先の確認、復元テスト、インシデント訓練、教育
  • 定期的に:休眠アカウントの無効化
  • 四半期ごと:ログの定期確認

★3は、推進体制、機器・ソフトウェアの管理ルールの遵守状況、取引先システムとの接続、機密区分のルール、インシデント対応体制、教育の内容について、それぞれ年1回以上の点検を求めています[J7b]。★3の有効期間は1年で、毎年自己評価を行います[J7]。

0か月3か月6か月9か月12か月四半期ごとログの定期確認定期的に休眠アカウントの無効化年1回以上時期は自社で決める台帳の更新委託先の確認復元テストインシデント訓練教育★3の自己評価頻度は本ガイドの提案。★3は推進体制・管理ルールの遵守状況・機密区分・インシデント対応体制・教育などに年1回以上の点検を求め、有効期間は1年。
図3維持するための点検の頻度。年1回の点検の時期は自社で決める。

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回に当たります。

一つ星6か条情報セキュリティ6か条二つ星25項目自社診断SCS ★326件要求事項・評価基準81件SCS ★443件★3+★4のみの17件このガイドの追加推奨公開面の削減全ログインにMFAKEVは14日より短く手の届かないバックアップログの保全メール認証 ほか★3は「広く知られた脆弱性等を狙う一般的な攻撃」を想定した最低ライン。このガイドは★3を最低ラインとし、事例と統計から必要と判断した対策を追加で推奨する(6節)。★4のみの要求事項には、追加推奨と同じ領域のものも含まれる。
図4中小企業の対策の段階と、SCS評価制度★3の位置[J6][J7b]。追加推奨は6節。
区分(件数)要求事項の番号(1マス=1件、色は主に扱う回)ガバナンスの整備 (3)1-2-11-2-31-3-1取引先管理 (3)2-1-12-1-22-1-4リスクの特定 (4)3-1-13-1-23-1-33-1-4攻撃等の防御 (13)4-1-14-1-24-1-34-1-44-1-54-1-64-1-74-2-24-3-44-4-14-4-44-4-54-5-1攻撃等の検知 (1)5-1-1インシデントへの対応 (1)6-1-1インシデントからの復旧 (1)7-1-1第4回第5回第6回第7回
図5★3の要求事項26件と、このシリーズで主に扱う回。複数の回にまたがる要求事項は、主な回で色分けしている。

★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の自己評価では求められません。

★3最低ラインこのガイドが追加で推奨する対策追加する理由公開面の削減・VPNの更新とZTNA等への移行侵入経路の82.1%がVPN機器とリモートデスクトップインターネットから使える全ログインにMFA★3のMFA必須は重要な機密情報を扱うクラウドに限る悪用確認済みの脆弱性は14日より短い期限で悪用はパッチ公開の平均7日前に始まる(推定)オフライン・イミュータブルなバックアップと復元テスト被害組織の72.5%がバックアップから復元できずログの集約・保全ログ削除で原因究明が困難になった事例メール認証(SPF・DKIM・DMARC)行政の要請、大手メールサービスの送信者要件データの保存期間と削除、パスワードのハッシュ保存国家サイバー統括室の要請、平文保存の事例送金・依頼の別経路確認、生成AIの利用ルールAIによる偽装の高度化、個人AIサービスへの入力の事例
図6★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

体制・方針

体制・方針0/3

第7回 2節
棚卸し

棚卸し0/6

第4回 2節
ID・認証

ID・認証0/9

第4回 3節
脆弱性・パッチ

脆弱性・パッチ0/5

第4回 4節
外部公開面・ネットワーク

外部公開面・ネットワーク0/5

第4回 5節
端末

端末0/7

第5回 2節
メール

メール0/2

第5回 3節
クラウド・SaaS

クラウド・SaaS0/4

第5回 4節
データ保護

データ保護0/3

第5回 5節
バックアップ

バックアップ0/5

第5回 6節
ログ・監視

ログ・監視0/4

第5回 7節
インシデント対応

インシデント対応0/6

第6回 1節
委託先

委託先0/3

第6回 2節
人とルール

人とルール0/3

第6回 3節

チェックした状態は、このブラウザの中にだけ保存されます(送信はされません)。

シリーズのおわりに

攻撃の手口はAIで速く、安くなりましたが、入口の多くはこれまでと同じ、公開された機器と、盗まれた認証情報と、未適用のパッチです。基本対策を順に入れ、毎年点検する。このシリーズとチェックリストは、そのための道具です。

Summary

この記事の要点

  1. 1被害の多い入口から先に塞ぐ。最初の30日は公開面・パッチ・MFA・手の届かないバックアップ・連絡先一覧に集中する。
  2. 2最初に、統括する役員と担当者、方針、守秘義務のルールを文書で決める。台帳と点検は、担当と頻度が決まっていないと続かない。
  3. 390日で台帳と仕組み(パッチの期限、管理者の分離、EDR、DMARC、ルール)、180日で検知と復旧(ログ、復元テスト、訓練、委託先)を固める。
  4. 4180日の時点でSCS評価制度★3の26件すべてに着手している。自己評価は評価基準81件の原文で1件ずつ確認する。
  5. 5★3は最低ライン。公開面の削減、全ログインへのMFA、短いパッチ期限、手の届かないバックアップ、ログの保全などを追加で推奨する。
  6. 6維持は毎年の点検で。台帳・委託先・復元テスト・訓練・教育は年1回以上、ログは四半期ごとに確認する。

FAQ

よくある質問

専任1名程度の組織を想定した目安です。規模と既存の状況に合わせて調整してください。順序は、被害の多い入口(VPN機器・リモートデスクトップ、MFAのないアカウント、未適用のパッチ)から先に塞ぐように組んでいます。期間を延ばす場合も、最初の30日の7項目は優先することを勧めます。

経済産業省などが構築を進める「サプライチェーン強化に向けたセキュリティ対策評価制度」の段階の一つです。★3は要求事項26件・評価基準81件からなり、広く知られた脆弱性などを狙う一般的な攻撃を想定した最低ラインとされています。発注企業が取引契約の中で受注側に必要な★を示す形が想定されており、有効期間は1年で、毎年自己評価を行います。

このガイドは★3の26件すべてに対応する対策を含みますが、自己評価は★3の評価基準81件の原文で1件ずつ確認してください。本文の★3の記述は評価基準の要約です。また、このガイドは★3を最低ラインとし、★3では求められない対策(公開面の削減、全ログインへのMFA、手の届かないバックアップなど)も推奨しています。

チェックした状態は、お使いのブラウザの中にだけ保存されます。サーバーには送信されません。別の端末やブラウザでは共有されないので、組織で記録を残す場合は、点検の結果を社内の文書に転記してください。

Next

シリーズの前後

AIの導入とセキュリティを、あわせて相談したい方へ

homulaは、AIエージェントを業務に導入する企業に向けて、統制ポリシー・権限・監査ログの設計から運用までを支援しています。AIを載せる前提となる基盤の点検も含めてご相談ください。

資料DLデモ・相談を依頼