ISMS の PDCA が何を回しているのかを整理し、認証の対象・適用範囲の考え方を解説。脆弱性を共通の物差しで測る CVSS と CVE、攻撃の手口を整理した知識体系、各種ガイドラインの位置づけまで。
規格やガイドラインが多く登場する分野です。個々の名前を覚えるだけでは点になりにくく、「何のための枠組みか」「誰が使うものか」で整理すると、設問に対応しやすくなります。
ISMS（情報セキュリティマネジメントシステム）は、対策の一覧ではなく、対策を決めて実施し、確かめて直す、という仕組みそのものを指します。技術は変わり、脅威も変わるので、一度作った対策は必ず古くなります。だから「回し続ける」ことを枠組みにしました。国際規格は ISO/IEC 27001 で、国内では JIS 化されたものが使われます。
| 段階 | やること |
|---|---|
| 計画（Plan） | 適用範囲を決め、リスクアセスメントを行い、方針と管理策を定める |
| 実施（Do） | 管理策を導入し、運用する。教育を行い、記録を残す |
| 点検（Check） | 有効性を測定し、内部監査とマネジメントレビューを行う |
| 処置（Act） | 見つかった不備を是正し、次の計画へ反映する |
「有効性の測定と見直しを行う段階」は点検（Check）です。実施と点検を取り違える設問がよく出るので、どの段階で何をするかを対応づけておきます。
もう一つの要点が「適用範囲」です。組織全体で取らなければならないわけではなく、部門や事業を単位に定めることができます。ただし、範囲を狭く取れば、その外は認証の対象外です。認証を取得している、という表示だけを見て全社が対象だと考えるのは誤りで、範囲を確かめる必要があります。
ISMS では、経営層の責任が明示されています。方針を定め、資源を割り当て、結果をレビューする。担当部署だけの取り組みにしない、という設計です。実務でも、権限と予算が伴わない対策は進まないため、この点は形式ではなく実質的な要件になります。設問でも、「経営層が行うべきことはどれか」という形で問われます。
CVE は、個々の脆弱性に付ける共通の識別番号です。同じ問題を各社が別々の名前で呼ぶと話が通じないため、番号で指せるようにしました。CVSS は、その脆弱性の深刻度を数値で表すための評価手法です。
実務で誤りやすいのが、基本評価値だけで優先順位を決めてしまうことです。公表されている値は自組織の事情を含んでいません。同じ脆弱性でも、外部に公開しているサーバと、内部の隔離された機器では、対応の急ぎ方が変わります。環境評価まで含めて判断する、というのが本来の使い方です。この考え方を問う設問が出ます。
攻撃者の行動を、段階と手法で整理した知識体系（MITRE ATT&CK など）は、検知の設計や訓練の設計に使われます。「何を検知できていて、何が抜けているか」を並べて確かめられるのが利点です。同様に、侵入の段階を追って考える枠組み（サイバーキルチェーン）は、どの段階で止められるかを検討するために使われます。
国内では、経営層向けに何を指示すべきかを整理した指針、中小企業向けの手引き、Web アプリケーションの安全な作り方をまとめた資料などが公開されています。それぞれ想定する読み手が違うので、「誰が何のために使うものか」で覚えると混同しません。
規格には、参考となる管理策の一覧が添えられています。ここから、自組織のリスクアセスメントの結果に基づいて必要なものを選びます。全部を採用する必要はなく、採用しないものについては理由を示します。この選定の結果をまとめたものが適用宣言書で、なぜその対策になったのかを説明する材料になります。
注意したいのは、一覧をそのまま導入すれば済むという考え方です。自組織のリスクを見ないまま形だけ整えると、必要な対策が抜け、不要な負担だけが残ります。順序としては、リスクを見てから管理策を選ぶ。逆にはしない、という点が問われます。
午前Ⅱでは、PDCA の各段階の内容、CVSS の三つの基準、CVE の位置づけ、各ガイドラインの対象読者が問われます。午後では、脆弱性の一覧を示して「対応の優先順位とその理由」を書かせる形が出ます。優先順位を答えるときは、公表値だけでなく、公開範囲・扱う情報・既にある対策を根拠に挙げると、環境を踏まえた判断として評価されます。
IPA 公式 PDF：令和5年度 秋期 午前Ⅱ問題 ↗本文はこの公式 PDF でご覧ください（アプリ内には転載していません）。