作成日: 2026-06-28
はじめに
「識別して、防御して、検知して、対応して、復旧する」――セキュリティの基本的な考え方を整理したNISTのサイバーセキュリティフレームワーク（CSF）の流れに沿って、SCS★3の要求事項を確認しています。
第4回：セキュリティ対策の”地図”――NIST サイバーセキュリティフレームワークを知る
攻撃等の防御で残る項目は４−２、４−３、４−４、４−５ですが、今回は少し順番を前後させて、４−４のプラットフォームセキュリティと４−５の技術インフラのレジリエンスを確認します。これらは第８回で解説した「識別」の「資産とネットワークの把握」に関係しています。
第8回：SCS★3の要求事項を読む③――「リスクの特定（前半）」資産とネットワークを把握する
今回あえて順番を変えた理由があります。それは、次回扱う「意識向上とトレーニング」が「対応」に、「データセキュリティ」が「復旧」に関係があるため、CSFの順番（識別→防御→検知→対応→復旧）の流れに沿ったほうが理解しやすいと思い、順番を入れ替えることにしました。
今回は4つの要求事項・15の評価基準を確認します。内容的には「パソコンやサーバの設定管理」「パッチ適用」「マルウェア対策」「ネットワーク境界防護」というテーマで、これまでと異なり専門的な知識が必要となる内容になっています。
「攻撃等の防御③」今回の全体像
今回確認するのは、4つの要求事項・15の評価基準です。
| NO | 要求事項 | 評価基準の数 |
|---|---|---|
| 4-4-1 | 情報機器、OS及びソフトウェアの安全な構成 | 3つ |
| 4-4-4 | セキュリティパッチ・アップデートの手続 | 2つ |
| 4-4-5 | マルウェア感染からの保護 | 3つ |
| 4-5-1 | ネットワーク境界防護 | 7つ |
| 合計 | 15 |
1. 4-4-1 情報機器、OS及びソフトウェアの安全な構成（評価基準3つ）
4-4-1は、第8回のリスクの特定で整理した端末やネットワークに対して、ソフトウェア構成を安全に保つための要求事項です。評価基準は以下の3つです。
- 4-4-1-1： パソコン・サーバ・スマートデバイスで、許可していないソフトウェアをすべて削除か無効化するか、または許可したソフトウェア以外を自由にインストールできないようにすること
- 4-4-1-2： 外部記録媒体（USBメモリ等）を使用する端末について、自動実行（auto-run）・自動再生（auto-play）を無効化すること
- 4-4-1-3： サーバ及びネットワーク機器の設定変更を申請・承認制にすること
4-4-1-1は基本的な対策で、今ではパソコンの利用者に管理者権限を与えずに勝手にソフトウェアをインストールできないようにするというのは一般的になってきていると思いますが、スマートフォンなどで実現するにはMDMと呼ばれる管理システムが必要だと思いますので、スマートデバイスまではやっていない企業もあるのではないかと思います（無料でも実現できるかは調査不足なので、今後に調査したらNoteの方で記事にしていきます）。ちょっと要求のレベルが高いかもしれませんが、紛失などのリスクはスマートデバイスの方が高いと思いますので、今回をきっかけに見直して見るのも良いのではないでしょうか。
4-4-1-2の自動実行・自動再生については、現在のWindowsであればデフォルトで無効になっていると思います。そのため、古いOSや管理が行き届いていない端末を意識した要求なのかもしれませんが、ちょっと細かすぎるかなという気もしました。とはいえ「デフォルトで無効だから大丈夫」と確認せずに済ませるのも危ういので、改めて設定を確認してみる価値はあると思います（私もインフラ部門に確認しようと感じました）。
4-4-1-3のサーバ・ネットワーク機器の設定変更を申請・承認制にするという点では、AWSやAzureなどのクラウドプラットフォームが対象になるかどうかが気になるところです。今後のガイドラインで整理されることを期待しています。
2. 4-4-4 セキュリティパッチ・アップデートの手続（評価基準2つ）
4-4-4も、第8回で整理した端末やソフトウェアに対してパッチ適用やアップデートを行う要求事項です。
4-4-4-1ではソフトウェアの脆弱性対策がいろいろと書いてあります。可能であれば自動アップデートを有効にして、サポートされた状態を維持して、サポートが終了したら削除するかインターネットから遮断する——まあ、ここまではそうだよなという内容です。
4-4-4-2では、一気に内容が難しくなります。脆弱性の重大度を確認して、重大なものであれば14日以内にアップデートすることが求められています。具体的には以下のいずれかに該当するアップデートが対象です。
- ベンダーが「重大（Critical）」または「高リスク（High Risk）」と説明している脆弱性を修正するもの
- CVSSの基本値が7.0以上の脆弱性を修正するもの
- 修正する脆弱性の詳細がベンダーから提供されていないもの
14日以内に対応できない場合は、以下のいずれかのリスク低減策が求められています。
- 脆弱性悪用の対象となる機能を無効化する
- ベンダーが推奨する回避策を実施する
- 対象機器を適用範囲内のネットワークから分離する
- 通信を監視し、脆弱性を悪用する不正な通信を遮断する機器またはソフトウェアを導入する
実際に脆弱性診断の結果を見たことがある方なら、件数の膨大さと、パッチを当てるだけでは解決しないケースの対応の難しさをご存知だと思います。私も自社の脆弱性対応には苦労させられており、この要求事項の方向性はそのとおりだと思うのですが、どうやって実現可能な運用に落とし込むかは正直まだ悩んでいます。
また、第8回のリスクの特定の要求事項では「脆弱性の管理・特定」は明示的に求められていないのに、今回は「脆弱性への対応」が求められているという点にもミスマッチを感じます。この点は今後詳細なガイドラインが整備される中で整理されていくのではないかと思っています。
これまでは自分たちで対策することを前提に解説してきましたが、この要求事項については初めて外部の専門家や専門会社の力を借りることを検討しても良いのではないかと思います。脆弱性の情報収集・トリアージ・優先順位付けを自社だけでまかなうのは難しいのではないでしょうか。
3. 4-4-5 マルウェア感染からの保護（評価基準3つ）
4-4-5は、パソコンとサーバにマルウェア対策ソフトウェアを導入して、更新して、スキャンすることを求める要求事項です。古くから言われている対策なので、やっていない会社はほとんどないと思います。
ただ、できればどのような製品を導入して、どのように運用すればよいかも触れてほしいところです。10年くらい前（もっと前かもしれませんが）、パターンマッチ方式のマルウェア対策ソフトウェアが主流でしたが、それではブロックできないマルウェアが増えてきて、マルウェアの挙動で判断するふるまい検知型のEDR（Endpoint Detection and Response）と呼ばれるものが今では主流になっています。単純にアップデートだけ続けている会社では、古いタイプのマルウェア対策ソフトを使い続けている可能性があります。その場合、要求事項は満たしていても、実際の防御効果としては不十分ということもあります。
具体的にEDRと書くと要求が高くなってしまったり、将来的に更新が必要になったりする事情があるのかもしれないので、要求事項をどのように表現するかも難しいのだろうなと思います。
また、マルウェア対策ソフトがアラートを出しているのに、そのアラートを誰も見ていなかったためにやられてしまったというケースもあります。ソフトの導入だけでなく、アラートへの対応まで含めた運用も大切です。
4. 4-5-1 ネットワーク境界防護（評価基準7つ）
ようやく今回最後の要求事項に到達しました。4-5-1の技術インフラのレジリエンスは、同じく第8回のリスクの特定で整理したネットワークに対する防御です。
これらも難しいので、外部の専門家や専門会社の支援があったほうがいいと思います。何が難しいかというと、前提としてネットワークの知識が必要になるからです。パソコンなら普段使っているので何となくわかることもあると思いますが、ファイアウォールやルータは触れる機会自体が少ないと思います。
7つの評価基準は、内容によって3つに分けて解説します。
4-5-1-1〜4-5-1-3：パスワード設定とアクセス制限
ファイアウォールやルータについて、デフォルトの管理パスワードを強固なものに変更するか、リモートアクセスを完全に無効化すること、パスワードの変更手順を定めること、第11回で確認したパスワード設定基準（4-1-5）を満たすことが求められています。
パスワードの設定やリモートからのアクセスを制限するくらいなら、自社内で対応できると思います。
4-5-1-4〜4-5-1-6：通信制御ルール
認証されていないインバウンド通信（外部→内部方向）を遮断するルールを定めること、不要になったルールは速やかに削除・無効化することが求められています。
この部分は、OSI参照モデルを理解したうえでレイヤーによる制御ルールを構築・メンテナンスする作業になります。管理画面から設定できないような機器の場合、黒い画面からコマンドで操作していくことになります。これがイメージできない場合は、外部に任せてしまったほうがいいと思います。ただし、丸投げはよくないので、設計書を提出してもらい、設計書のレベルで内容を確認することをお勧めします。
4-5-1-7：インターネット経由の操作には多要素認証
ファイアウォール・ルールの変更をインターネット経由で行う場合は、多要素認証を適用するか、信頼できるIPアドレスにアクセスを制限することが求められています。
ここでも多要素認証が出てきました。それだけ大事ということだと思います。多要素認証については第10回の記事も参考にしてください。
第10回：SCS★3の要求事項を読む⑤――「攻撃等の防御①」アカウントと認証の12の評価基準
まとめ
長くなりましたが、プラットフォームセキュリティと技術インフラのレジリエンスが終わりました。今回は「専門知識が必要な領域は外部の専門家に任せた方が良いのでは」という話が繰り返し出てきましたが、それだけ自社内だけで対応するのが難しい要求事項が含まれているということでもあります。
どこまで自社でできて、どこからは専門家に頼むのかを考えさせられる要求事項でしたね。
このブログが目指していること
私はグローバルな製造業グループのCSIRTリーダーとして働いており、セキュリティ製品を売る立場ではありません。自動車部品メーカーに勤めているため、取引先にセキュリティ要件を「求める側」であり、完成車メーカーから要件を「求められる側」でもあります。
その立場から、「このブログを読んだ担当者が、経営者を動かすための言葉と資料を手に入れられる」ことを目指して書いています。
「要求される側の現場目線」を込めようとしています。難しい言葉をわかりやすく言い換えるだけでなく、「現場では実際にどう判断するか」という視点を大事にします。
次回の予告
次回は「意識向上とトレーニング」と「データセキュリティ」を確認します。2つの要求事項・6つの評価基準とコンパクトな内容ですが、セキュリティ教育の実践と、データ保護の考え方に触れていきます。
相談してみませんか？
「ちょっと聞いてみたい」という段階でも構いません。私の経歴・支援内容の詳細は「このブログについて」をご覧ください。
なお、SCSへの関心が高まる中、制度に便乗した不審な勧誘も出てきています。私のことも含め、見知らぬ相手を安易に信用しすぎないようご注意ください。経産省も注意喚起を出しています。
→ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に係る不適切な勧誘に御注意ください https://www.meti.go.jp/policy/netsecurity/20260427_scs.html
CISSP・情報処理安全確保支援士 ｜ けい
コメント