作成日: 2026-06-23
はじめに
「この装置に付帯しているPCは、OSを更新すると装置が動かなくなってしまう。だからインターネットに繋げないで使うことにした。」
製造業のIT担当者なら、似たような話を一度は聞いたことがあるのではないでしょうか。ところが、「いつの間にかセキュリティ更新されていないPCが社内ネットワークやインターネットに繋がっていた」ということが起きることがあります。
これは極端な例かもしれませんが、「自分たちが持っている機器・ネットワークが、今どんな状態にあるか」を正確に把握するのは、想像以上に難しいことだと感じています。
今回から3つ目の大分類「リスクの特定」に入ります。資産とネットワークの把握は、後続のすべてのセキュリティ対策の土台です。「何を守るか」がわからなければ、どんなに費用をかけて対策を打っても、方向性がズレてしまうことになります。
今回は前半として、4つの要求事項・11評価基準のうち「ハードウェア・OS・ソフトウェアの把握」と「ネットワークの一覧作成」の2要求事項・6評価基準を確認します。
「リスクの特定」の全体像
「リスクの特定」は、NIST サイバーセキュリティフレームワーク（CSF）でいう「識別（Identify）」に対応しています。私がCSFの6分類の中で最も重要だと感じている領域です。フレームワーク自体については以前の記事で詳しく説明しているので、合わせて読んでいただけると理解が深まると思います。
→ 第4回：セキュリティ対策の”地図”――NIST サイバーセキュリティフレームワークを知る
SCS★3における「リスクの特定」は、4つの要求事項に対して11の評価基準が定められています。量が多いため、今回と次回の2回に分けて確認します。
| NO | 要求事項 | 評価基準の数 | 今回/次回 |
|---|---|---|---|
| 3-1-1 | ハードウェア、OS及びソフトウェアの把握 | 4つ | 今回 |
| 3-1-2 | ネットワークの一覧作成 | 2つ | 今回 |
| 3-1-3 | 外部情報サービスの管理 | 2つ | 次回 |
| 3-1-4 | 機密区分に応じた情報の管理 | 3つ | 次回 |
| 合計 | 4つの要求事項 | 11つ |
1. 3-1-1 ハードウェア、OS及びソフトウェアの把握（評価基準4つ）
3-1-1-1：適用範囲内のパソコン及びシンクライアントの製造元、OS及び台数を把握するための仕組みを整備すること
3-1-1-2：適用範囲内のサーバ、仮想サーバ及びハイパーバイザの製造元、OS及び台数を把握するための仕組みを整備すること
3-1-1-1と3-1-1-2はセットで考えるとわかりやすいです。PC・シンクライアント・サーバ・仮想サーバ・ハイパーバイザ、つまり適用範囲内にある情報機器を全部把握する仕組みを整えましょう、ということです。
台数が少なければ台帳管理でも対応できますが、ある程度の規模になると手作業での管理は漏れが出やすくなります。資産管理ツール（デバイス管理ツール）を使うと、機器の情報を自動で収集・更新できるため、実態と管理情報のズレを防ぎやすくなります。
3-1-1-3：情報機器、OS及びソフトウェアについて、導入、設置、ネットワーク接続及びセキュリティパッチ適用のルールを含む管理ルールを定めること
ここが冒頭の話と繋がります。ネットワークに接続されていてパッチが適用できるものはパッチ適用のルールを決めておけば良いですが、「ネットに繋いではいけない機器」をきちんとリストアップして、「なぜ繋いではいけないのか」「代わりにどんな対策をするのか」を管理ルールに明記しておくことが求められています。
管理ルールに含めるべき内容としては、以下が考えられます。
- 導入・設置のルール： 新しい機器を購入・設置するときの申請・承認の流れ
- ネットワーク接続のルール： どの機器をどのネットワークに接続するかの基準（接続禁止機器の明示を含む）
- セキュリティパッチ適用のルール： 更新できない機器はどう管理するか（ネットワーク分離・代替策の明示）
細かい内容になりますが、２でITとネットワーク的に切り離した工場などの現場の領域はOTと呼ばれる分野でSCSの対象外になっています。ただし、対象外の機器についても、「なぜ対象外なのか」を説明できるルールを整備しておくことは、要求事項の範囲ではないかと予想しています。
https://www.ntt.com/business/services/rink/knowledge/archive_08.html
3-1-1-4：年1回以上の頻度でNo.3-1-1-3で定めた管理ルールの遵守状況について点検すること
管理ルールを定めた後に、年1回以上の点検が求められています。
「ルールは作ったけれど、現場で守られているか確認していない」という状態は、ガバナンスの整備や取引先管理の項目でも同じ構造でした。SCS★3では「定める」と「点検する」がセットになっているパターンが繰り返し登場します。 「ガバナンスの整備」や「取引先管理」でも同じパターンが出てきましたが、だんだん見えてきたのではないかと思います。
2. 3-1-2 ネットワークの一覧作成（評価基準2つ）
3-1-2-1：適用範囲内のネットワークを把握するための仕組みを整備すること。その際、把握すべき情報の中に各ネットワークの所在地及び目的に関する情報を含めること
個人的には、資産の把握よりもネットワークの把握の方が難しいと感じています。理由は、機器と違ってネットワークは「見えにくい」からです。
「把握するための仕組み」として現実的なのは、多くの企業ではネットワーク構成図の作成になると思います。把握すべき情報として「所在地（どの拠点・フロアか）」と「目的（どういう用途のネットワークか）」が明示されているので、構成図にはその情報も含める必要があります。
なお、ネットワーク構成図の作成は★4の要求事項として別途定められています。★3では「把握するための仕組みを整備すること」と表現されていますが、構成図なしにこの要件を満たす方法は私にはまだイメージできていません。SCS評価制度が本格運用に入ったときに、実際の事例を確認していきたいと思っています。
ネットワークを管理する観点として、拠点間のWAN（広域通信網）と拠点内のLAN（構内通信網）に分けて整理すると把握しやすくなります。
また、近年はSASE（専門用語になりますが説明は割愛します）のようにインターネット上に仮想的な社内ネットワークを構築する技術もあります。この場合、サービスの管理画面からネットワーク構成を確認できる点は便利です。ただし、誤操作や攻撃などでサービスの設定が変更・破壊された場合に「正しい構成が何だったか」がわからなくなるリスクもあります。管理画面の情報を定期的にエクスポートするなど、構成情報のバックアップを別途確保しておくことが望ましいと思います。
3-1-2-2：適用範囲内のネットワーク機器を把握するための仕組みを整備すること。その際、把握すべき情報の中に各機器の製造元、モデル及び保守事業者に関する情報を含めること
サーバと同様に、ネットワーク機器の台帳管理が求められています。ただし、サーバと違ってネットワーク機器には資産管理ツールを導入できないことが多いため、管理の難易度はサーバより高いと感じます。
ネットワークの構築や運用を外部の会社に委託している場合、以下のような対応が現実的です。
- ネットワーク構成図と機器台帳を、成果物として提出してもらう： 委託契約や運用サービスの要件に「構成図・台帳の提出」を含める
- 年1回の更新を義務付ける： サービス更新のタイミングで台帳を最新化してもらう
外部委託先に提出を求める形にすれば、自社担当者の工数を減らしながら台帳を維持できます。 委託先との契約見直し時に、この観点を盛り込んでおくといいかもしれません。
把握すべき情報に「保守事業者」が含まれている点も特徴的です。機器が故障した際や脆弱性対応が必要な際に、誰に連絡すればいいかがすぐわかる状態にしておくことが目的だと思います。
少し脱線：資産だけではリスクは特定できない
今回確認した3-1-1・3-1-2はいずれも「資産管理」の話です。資産を把握することは、リスクの特定の第一歩として間違いなく重要です。
ただ、正直に言うと、資産がわかっただけではリスクの特定は完結しません。
少し整理すると、こうなります。
- 資産がわかる → 何を守らなければいけないかがわかる
- 脆弱性がわかる → 資産のどこに弱点があるかがわかる
- 脅威がわかる → どんな攻撃が来うるかがわかる
- 資産・脆弱性・脅威が揃って → 何をどの優先順位で対策すべきかが決まる
脆弱性の管理については3-2-1として★4の要求事項に入っています。★3の範囲では今回の資産管理と次回の情報管理（3-1-3・3-1-4）が「識別」の土台になります。
資産・脆弱性・脅威の3つを組み合わせたリスク特定の具体例については、今後NoteでCSIRTの現場目線を交えながら投稿しようかなと考えています。
まとめ：今回確認した6つの評価基準
今回の6つの評価基準に共通するのは、「資産を把握する仕組みを整える」という視点です。台帳を作ること・ルールを定めることがゴールではなく、「維持できる仕組み」と「年1回の点検」がセットになっているかどうかが問われています。
このブログが目指していること
私はグローバルな製造業グループのCSIRTリーダーとして働いており、セキュリティ製品を売る立場ではありません。自動車部品メーカーに勤めているため、取引先にセキュリティ要件を「求める側」であり、完成車メーカーから要件を「求められる側」でもあります。
その立場から、「このブログを読んだ担当者が、経営者を動かすための言葉と資料を手に入れられる」ことを目指して書いています。
「要求される側の現場目線」を込めようとしています。難しい言葉をわかりやすく言い換えるだけでなく、「現場では実際にどう判断するか」という視点を大事にします。
次回の予告
次回はリスクの特定の後半として、「外部情報サービスの管理（3-1-3）」と「機密区分に応じた情報の管理（3-1-4）」の5つの評価基準を確認します。
クラウドサービスや社外への情報共有が当たり前になった今、「何を誰に共有していいか」「社内の情報をどう分類して管理するか」は、現場でも悩みやすい領域です。SCS★3が何を求めているのかを整理していきます。
相談してみませんか？
「ちょっと聞いてみたい」という段階でも構いません。私の経歴・支援内容の詳細は「このブログについて」をご覧ください。
なお、SCSへの関心が高まる中、制度に便乗した不審な勧誘も出てきています。私のことも含め、見知らぬ相手を安易に信用しすぎないようご注意ください。経産省も注意喚起を出しています。
→ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に係る不適切な勧誘に御注意ください https://www.meti.go.jp/policy/netsecurity/20260427_scs.html
CISSP・情報処理安全確保支援士 ｜ けい
コメント