そのリスク対応をなぜ優先するのか？——特定・分析・評価、損失の見積り、STRIDE、リスク対応を午後の問われ方で読む｜支援士解説1の2

この記事の重要度：Aランク（午後の大問・設問でよく問われる重要な分野）

この記事で分かること：

• 情報の特性（CIAなど）、資産・脅威・脆弱性の結び付け方と、リスクの特定・分析・評価の違い

• 損失の見積り、分析の方法、STRIDEとアタックツリー、リスク対応の4分類と残留リスク

• 解答欄に書く「原因」と「対策」の型

シラバスとの対応：小項目1-2「情報セキュリティリスクアセスメント」。リスク対応の計画と管理策の選び方は支援士解説1の3、委託先・クラウドのリスクは支援士解説3の10、脆弱性の優先度は支援士解説3の6で扱います。

午後の問題では、「このリスクはどれくらい大きいか」「どれから対策するか」を、決められた手順で判断させる設問が出ます。誰が、何をして、どのような経緯で情報が漏れるのかを具体的に書き、被害の大きさと発生の頻度を決め、基準と比べて対応の要否を決める。そのうえで、対策をしても残るリスクを特定する。どの段階でも、具体性が足りない解答や、問題文の前提と合わない解答が指摘されてきました。

「どちらもリスクは高いと言われました。先に予算を付けるのは、どちらでしょうか」

架空の自治体のオンライン申請サービスで、二つの課題が報告されたとします。一つは、申請情報を外部へ出力する権限が、多くの受付担当者に広く付与されたままになっていること。もう一つは、受付の締切日にサービスが止まった場合の代わりの手段が決まっていないことです。どちらも大切そうですが、「漏えいは怖い」「停止も困る」だけでは、責任者は対応の順番を決められません。

この記事では、この二つの課題を例に、何を守るのか、何が起こり得るのか、どれだけ大きいのか、どう対応するのかを順に整理し、最後になぜその対応を優先するのかを説明できる形にまとめます（11.）。

1. 何が失われたら困るのかを、情報の特性から考える

機密性・完全性・可用性が基本になる

機密性は、情報を扱う権限のない相手へ利用・開示させない性質です。申請情報を担当者だけが見られること、非公開の資料を無関係な人へ渡さないことが例になります。英語ではConfidentialityといいます。

完全性は、情報の正確さと完全さが保たれる性質です。英語はIntegrityです。金額の不正な変更だけでなく、必要な申請記録が欠ける、処理中に一部の内容が失われるといった問題も考えます。

可用性は、権限のある利用者が、必要なときに情報やシステムへアクセスし、利用できる性質です。英語はAvailabilityです。常に無停止であることを一律に求める言葉ではありません。何の業務で、いつ、どの程度利用できる必要があるかを具体化します。

この三つを、英語の頭文字からCIAと呼びます。情報セキュリティではCIAを基本に、真正性などの特性も考えます。JIPDEC「ISMSユーザーズガイド」JIP-ISMS111-4.0、2025年3月31日、3.1.1節

公開済みの避難場所の案内を考えてみましょう。公開内容自体を秘密にする必要は小さくても、場所が不正に書き換えられたり、必要なときに閲覧できなかったりすれば問題です。一方、公開用の画面と同じサービスにある管理画面の認証情報は、公開してよい情報ではありません。情報ごと、用途ごとに分けて考えます。

真正性：名乗っている相手は、本当にその相手か

真正性（Authenticity）は、主体や情報が、主張されているとおりのものであるという性質です。

例えば、保守担当者を名乗る接続が、本当にその担当者によるものかを考えます。IDとパスワードが正しく入力された記録があっても、認証情報を盗まれた可能性までは消えません。確認方法、認証情報の管理、接続元の条件などを合わせて考えます。

真正性と完全性は関係しますが、同じではありません。偽の発信者が作ったデータが、途中で一文字も変わらず届く場合もあります。逆に、本物の発信者が送ったデータが、途中で変わる場合もあります。

責任追跡性：誰の行為かをたどれるか

責任追跡性（Accountability）は、ある行為を、その行為をした主体へ結び付けて追跡できる性質です。

例えば、受付結果を変更した操作について、利用者、時刻、対象、操作内容をたどれるようにします。全員が一つの共通アカウントを使い、ほかの識別情報も残らないなら、操作した人を絞るのが難しくなります。

ただし、個別IDのログがあるだけで、その名義人本人の意図まで確定するわけではありません。アカウントの不正利用、時刻のずれ、記録の欠落や改ざんも確認します。

否認防止：事象と関与した主体を証明できるか

否認防止（Non-repudiation）は、事象や行為が起きたことと、それに関与した主体を証明できる能力を扱います。

例えば、ある内容の申請が提出された事実を、後から確かめられるようにする場面です。電子署名や記録の保護は、そのための手段になり得ます。ただし、鍵の管理、検証、本人との対応、保存の条件などが必要です。

否認防止は、人が「自分はやっていない」と発言できなくなるという意味ではありません。その主張を検討できる証拠を備えることが大切です。責任追跡性が行為をたどる観点なら、否認防止はその発生と主体を証明する観点として区別すると整理しやすくなります。

信頼性：意図した動作と結果が一貫しているか

信頼性（Reliability）は、意図する動作と結果が一貫している性質です。

例えば、申請を一度受け付ける操作に対し、条件によって受付番号が重複したり、受付済みなのに未受付と表示されたりすれば、業務で結果を信頼しにくくなります。正しい仕様、実装、試験、運用の確認が関係します。

画面へ接続できることは可用性の一面ですが、接続後の処理結果が正しいとは限りません。また、信頼性を説明する際に「絶対に不具合がない」という保証へ広げないようにします。

七つの特性を、必ず七列に採点する必要はない

特性は、見落としを減らす観点です。一つの事象が複数の特性に関わることもあります。なりすました利用者が内容を変更すれば、真正性と完全性の問題が結び付きます。

逆に、同じ事故の損失を特性ごとに重ねて合計すると、過大な見積りになります。何が失われ、どの影響へつながるかを、業務の流れに沿って整理しましょう。

【図1】情報の特性を、確認する問いにする

2. 資産・脅威・脆弱性を、起こり得る出来事として結ぶ

リスクは、事故の名前だけでは表せない

リスクは一般に、目的に対する不確かさの影響として捉えます。情報セキュリティでは、情報の保護が損なわれ、組織や利用者へ望ましくない結果が生じる可能性を中心に考えます。NIST用語集：risk（NIST SP 800-160 Vol.1 Rev.1に基づく定義）

例えば「不正アクセス」と書くだけでは、どの資産に、どう接続され、何が起こるのかが分かりません。同じ名称でも、公開情報を閲覧される場合と、非公開の申請情報を大量に取得される場合では、検討すべき影響が異なります。

本稿では、リスクを文章で記述するとき、次の形を使います。これは整理のための提案であり、規格が指定した必須の書式ではありません。

どの情報・業務で、どのような条件から何が起こり、その結果、誰にどんな影響が生じるか。

情報資産：守るべき価値のある情報と、それを支えるもの

情報資産を調べるときは、データそのものに加え、保存・処理・通信を担うシステムや媒体も確認します。資産の定義と台帳の対象は、適用する規程で明らかにします。

例えば、申請書、受付データ、承認結果、出力ファイル、操作記録、バックアップ、サービスの設定情報などがあります。職員や委託先の役割、施設、回線は、それらを扱う業務の依存先としても重要です。

資産の価値は購入価格だけではありません。安価な保存媒体でも、再作成できない記録や、外部へ出せない情報が入っていれば、失われたときの影響は大きくなり得ます。

リスク源と脅威：どこから、何が起こり得るか

リスク源は、単独又はほかの要素と組み合わさってリスクを生じさせ得る要素です。人、設備、自然現象、組織の状態などを広く考える言葉です。

脅威は、望ましくない事象を引き起こし、情報やシステムへ損害を与え得る原因です。攻撃者による不正操作だけでなく、操作ミス、機器故障、停電、災害なども考えます。

例えば「外部の攻撃者」はリスク源の一例であり、「盗んだ認証情報を使ってサービスへ不正に接続する」は具体的な脅威事象の例です。ただし、資料によって脅威という語が主体や出来事を広く指すことがあります。言葉の分類だけで議論を止めず、誰が、どこから、何をするかまで具体化します。

脆弱性：脅威と結び付く弱点

脆弱性は、資産や管理策にある、脅威に利用され得る弱点です。ソフトウェアの欠陥だけを指すわけではありません。

例えば、不要な権限が残る設定、共有リンクの公開範囲を確認する手順の欠落、障害時の連絡先が古いことなども、状況に応じた弱点として扱います。

攻撃を受けることと、弱点があることは区別します。「攻撃メールが送られる」は脅威事象の例です。「危険な添付ファイルを実行できる設定になっている」「不審なメールを相談する経路がない」は、被害に結び付き得る弱点の例です。

冒頭の課題を、一つのシナリオにする

冒頭の一つ目の課題（出力権限が広すぎる）を、リスクとして書いてみます。オンライン申請サービスで、受付担当者は一覧を確認できます。本稿の架空の仕様では、全件の出力も可能ですが、その権限が多くの担当者へ付与されたままになっています。

ここで考えるリスクは、例えば次のようになります。

「受付担当者のアカウントが不正に利用された場合に、広く付与された全件出力権限を使って申請情報が取り出され、申請者の情報が外部へ渡るおそれがある。その際には、影響範囲の調査、本人への説明、通常業務の縮小などが必要になる可能性がある。」

資産は申請情報と出力機能、脅威事象はアカウントの不正利用による取得、弱点は業務上必要な範囲を超えた権限付与です。被害が起きた後の影響も記述したことで、業務部門と調査担当者が検討しやすくなります。

ただし、認証情報がどのように悪用されるか、追加認証や出力制限があるかは、別に確認が必要です。弱点を一つ見つけたことから、攻撃の成功を自動的に断定しません。

リスクを必ず三つの数値の積と考えない

資産・脅威・脆弱性はリスクを考える重要な要素ですが、「資産価値×脅威×脆弱性」が、あらゆる場面で唯一の算定式になるわけではありません。

組織が相対的な点数の算定方法として採用することはあります。その場合は、それぞれの値、既存対策、結果の意味を定義します。情報がないために値を入れられない状態を、ゼロとして計算してはいけません。

また、組織が変えられるのは脆弱性だけではありません。扱うデータを必要な範囲へ減らす、業務の設計を変える、代替手段で影響を抑えるなどの方法も考えられます。具体的な対応の選び方は1-3へつながります。

【図2】リスクは、資産から影響まで結び付ける

3. 特定・分析・評価の前に、判断の基準をそろえる

三つのプロセスは、扱う問いが違う

リスクアセスメントは、リスク特定、リスク分析、リスク評価を含むプロセスです。

リスク特定では、何が起こり得るかを見つけて記述します。先ほどの申請情報の例なら、不正利用によって全件を取得される経路と結果を整理する作業が該当します。

リスク分析では、そのリスクの性質を調べ、起こりやすさと影響などからリスクレベルを決めます。今の権限設定、認証、監視、情報量などを確認する作業が含まれます。

リスク評価では、分析結果をあらかじめ定めたリスク基準と比較し、対応の必要性や優先順位を判断します。根拠が足りなければ、追加分析が必要という判断もあります。

JIS Q 27001の6.1.2を解説するJIPDECのガイドでは、この三つに加え、リスク基準の確立と、一貫性・妥当性を確保することが整理されています。実施方法や判断条件を共有することも大切です。JIPDEC「ISMSユーザーズガイド」JIP-ISMS111-4.0、6.1.2節

目的と範囲を、先に決める

同じサービスでも、設計段階の導入判断と、稼働後の権限の見直しでは、必要な情報が異なります。

最初に、何の判断に使うかを確認します。サービスを開始してよいか、対策の優先順位を決めるか、運用変更の影響を確認するかによって、調査の深さや期限を考えます。

次に、対象の業務、情報、システム、委託関係、場所、期間を定めます。対象外の範囲と、そこへ依存する部分も記録します。「外部事業者の設備なので対象外」として依存先まで消してしまうと、自組織のサービス停止を説明できません。

リスク基準は、受容の点数だけではない

リスク基準は、リスクの重大さを判断するための条件です。本稿では、少なくとも次を確認することを提案します。

• 何への影響を考えるか。利用者、業務、費用、安全、法令・契約など。

• 影響の段階をどう分けるか。対象人数、業務停止、回復の難しさなど。

• 起こりやすさを何の期間・条件で考えるか。

• 既存対策をどう考慮し、リスクレベルをどう決めるか。

• どの条件なら追加対応を要し、どの条件なら受容を検討できるか。

• 判断に必要な根拠が足りない場合、誰が追加確認を決めるか。

リスク受容基準は、このうちリスクを受け入れるか判断する条件に関係します。点数が低くても、適用される義務を満たしていないなら、その点数だけで何もしなくてよいとは決められません。

同じ基準で比較できることと、基準を維持すること

一つの部署が「高」を数時間の停止とし、別の部署が一週間の停止としていると、そのまま横に並べても意味がそろいません。共通基準に加えて、業務ごとの具体例を置くと認識を合わせやすくなります。

一方、基準を永久に変えないことが一貫性ではありません。サービスの対象や契約、社会的な要求が変われば、基準自体の見直しも必要です。改定理由と適用日を残し、以前との比較ができるようにします。

「去年より点数が下がった」という結果も、対策の効果なのか、基準や対象を変えただけなのかを分けて確認します。

リスク所有者は、台帳を入力する人とは限らない

リスク所有者は、リスクに対する責任と権限を持つ人又は主体です。資産の管理者、システム管理者、委託先と必ず同一になるわけではありません。

例えば、受付サービス停止時の業務上の判断には、担当課の責任者が関わります。情報システム部門は技術上の見積りを支援し、外部事業者は設備や復旧条件を説明します。組織横断の判断が必要なら、上位の責任者へつなぎます。

アセスメントを実施した担当者だけで、利用者への重大な影響を受け入れてよいとは限りません。誰の判断に使う分析なのかも、初めに確認しておきます。

【図3】特定・分析・評価は、扱う問いが違う

記述の型

• 分析と評価の違い（規格の定義）：「分析はリスクレベルを決めること、評価はリスク基準と比べて対応の要否を判断すること」

• リスクレベル：「起こり得る結果の大きさと、その起こりやすさの組合せで表す」

4. リスク特定は、台帳と業務の流れから

資産から考える方法と、事象から考える方法

資産ベースのアプローチでは、守る対象から考えます。例えば、申請データ、出力ファイル、認証情報を挙げ、それぞれが漏れる、変わる、使えなくなる条件を調べます。

事象ベースのアプローチでは、起こり得る出来事から考えます。例えば「申請の締切日に受付できない」という結果を置き、回線、認証サービス、アプリケーション、運用判断などの原因や依存先へたどります。

両者は対立する方法ではありません。台帳から個別資産を確認し、業務の停止場面から資産間のつながりを確認すると、別々の見落としを減らせます。総務省の令和8年3月版ガイドラインでも、この二つの考え方が紹介されています。総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」、令和8年3月、第1編・ⅰ-27

作成・利用・共有・保存・廃棄まで見る

資産台帳が稼働中のサーバだけを列挙していると、担当者が出力したファイルや、委託先へ渡した複製を見落とす可能性があります。

例えば、申請情報は、入力画面から保存先へ移り、職員が確認し、別の業務へ連携されるかもしれません。照会対応のために一時出力され、紙に印刷される場合もあります。

それぞれの段階で、誰が扱い、どこへ移し、いつ不要になるかを確認します。保存期間を過ぎたデータや契約終了後のコピーも、残っているなら検討対象になり得ます。

聞取りを、記録や設定で確かめる

担当者へのインタビューは、業務の意味や例外を知るために役立ちます。一方、「権限は適切に管理しています」という回答だけでは、範囲や実施状況が分かりません。

本稿の確認例なら、権限の一覧、申請・承認記録、異動時の変更記録、サービスの設定を照合します。規程に書いてあること、設定されていること、実際に運用されていることを分けます。

構成図、契約、手順書、障害記録、監査結果も材料になります。脆弱性診断は技術上の弱点を調べる助けになりますが、業務への影響や契約上の責任まで自動的に算定するものではありません。

新たなITでも、情報の流れと権限から考える

新しい技術では、既存のチェックリストに項目がない場合があります。それでも、何を渡し、誰が利用し、何が実行されるかという問いは使えます。

例えば、文章作成支援の外部サービスへ業務情報を入力する構成なら、入力・出力・履歴・外部連携の保存先や利用条件を確認します。ほかのシステムを操作する機能を付けるなら、どの権限で何を実行できるかも調べます。

これは特定の製品が危険又は安全だと断定するものではありません。製品の仕様、契約、設定、使い方を確認するための観点です。未確認の挙動は、事実として台帳へ書かず、確認事項として残します。

クラウドサービスや委託先を使う場合は、利用者側の設定・権限・連携と、提供者側の対策、自組織へ提供される情報を分けて特定します。依存関係のリスクは支援士解説3の10で扱います。

午後での問われ方

• 令和5年度秋期 午後問4：百貨店と、配送を受託する運送会社を題材に、個人情報のリスクアセスメントが問われました。リスクの特定として、例えば「G百貨店からW社への連絡を装った電子メールに未知のマルウェアを添付して、配送管理課員宛てに送付する」という攻撃と、その結果、IDとパスワードが窃取されて社外からサービスにログインされ、情報が漏えいするまでの経緯を、具体的に書かせています。

採点講評で指摘されたつまずき

• 令和5年度秋期 午後問4の講評は、リスク特定は担当者の知見が重要なプロセスであり、本文の状況説明と自らの知見を組み合わせてリスクを洗い出す能力を問うたとしています。「誰が、何をして、どのような経緯で、何が起きるか」を、分析に使えるだけ具体的に書きます。

記述の型

• リスクの特定：「（リスク源）が（何をして）、（どのような経緯で）、（どの情報の何が）損なわれる」まで書く

5. 起こりやすさと影響を調べ、基準と比べる

起こりやすさは、何が起こる可能性なのか

分析では、出来事の定義と期間をそろえます。「攻撃が試みられる可能性」と「攻撃が成功して情報が流出する可能性」は同じではありません。

例えば、ログイン試行が頻繁に記録されていても、それがすべて認証の突破や情報取得につながるわけではありません。反対に、事故の記録が少ない理由が、検知できていないことかもしれません。

過去の事象、外部の動向、攻撃を受ける接点、設定、業務頻度、既存対策の有効性を材料にします。期間が一年なのか、一回の作業なのかも明らかにします。

対策があることと、想定どおり効くことを区別する

「追加認証あり」と書いてあっても、全件出力が可能な利用者に適用されていなければ、今回のリスクへ期待した効果が出ない可能性があります。

バックアップについても、取得の有無だけでなく、対象、保存状態、復旧の試験、復旧に必要な権限を確認します。対策の有効性を確認できない場合は、効果を確定した条件にしません。

現在の対策を考慮した評価と、追加対策を実施した後の予測は分けます。予算化しただけの対策を、既に動いている対策として採点すると、現状のリスクを小さく見積もってしまいます。

定性・半定量・定量の違い

定性的な分析では、低・中・高など、意味を定義した区分で表します。数値へ無理に変換しなくても、影響の内容や判断条件を共有できます。

半定量的な分析では、段階に1・2・3などの数値を割り当て、計算や比較に使います。ただし「高＝3」は、「低＝1の損失額の3倍」という測定結果ではありません。

定量的な分析では、損失額、発生頻度、停止時間など、意味と単位のある量を使います。数値の根拠や推定の幅が重要です。金額だけが定量的な情報ではありません。

NIST SP 800-30 Rev.1は、定量・定性・半定量の選択と、不確かさの扱いを説明しています。一つの方式をすべての組織へ固定するための資料ではありません。NIST SP 800-30 Rev.1、2012年9月、2.3.1・2.3.2節

架空の採点例で、分析と評価を分ける

ここからの点数と閾値は、本稿の説明用に設定したものです。国・自治体の公式基準や、一般に適切な基準値ではありません。

対象期間を今後一年とし、影響度は次のように定義したとします。

• 1：限定した担当範囲で回復でき、利用者への影響は小さい。

• 2：複数の担当で調整が必要となり、利用者への影響が生じる。

• 3：多数の利用者への影響、重要な期限の不履行、回復の難しい損害などが想定される。

起こりやすさも、根拠を基に1〜3で判断するとします。

• 1：必要な条件が成立しにくく、抑止・防止の対策の有効性も確認できている。

• 2：成立し得る条件があり、既存対策には一部限界がある。

• 3：成立する条件がそろいやすく、十分な抑止・防止を確認できていない。

区分への当てはめには、根拠の記録と関係者による確認が必要です。情報不足で判断できない場合は、この例でも無理に1へ入れず、未確認とします。

算定方法を「影響度×起こりやすさ」とし、1〜2を低、3〜4を中、6〜9を高と設定します。

• 申請情報の全件取得：影響度3、起こりやすさ2なら、点数は6で高。

• 締切日に受付が止まり、代わりの手段もない（冒頭の二つ目の課題）：重要な期限の不履行に当たるので影響度3、起こりやすさ2なら、点数は6で高。

• 締切日以外の短時間の受付遅延：影響度1、起こりやすさ3なら、点数は3で中。

冒頭の二つの課題は、この基準ではどちらも6で高になります。「どちらも高い」と言われたのは、このためです。同じ受付の停止でも、締切日かどうかで影響度が変わることにも注意します。

ここまでが、リスクレベルを決める分析です。

さらに、組織の受容基準が「高は追加対応を要する。中は業務責任者が影響と根拠を確認する。義務違反や重大な安全上の問題は別に判断する」であれば、この基準との比較が評価です。

同じ点数でも、同じリスクではない

影響度3×起こりやすさ1と、影響度1×起こりやすさ3は、どちらも3です。しかし、重大な損害がまれに生じるケースと、軽微な支障が繰り返されるケースでは、必要な判断は違います。

本稿の採点例では、重大な影響のあるものは点数と別に責任者へ示す条件を加えるなど、意味が失われない基準を設計します。点数を足して総合順位だけを出すと、こうした違いが見えなくなる場合があります。

また、一つの出来事で複数のサービスが止まる場合、各サービスのリスクを独立したものとみなしてよいかを確認します。同時に起こる影響や、別の業務へ波及する影響も判断材料です。

評価の結果は、対応又は放置の二択ではない

評価では、追加対応へ進めるほか、根拠を増やして再分析する、既存対策を維持して監視する、上位の責任者へ判断を求めるなどの結果が考えられます。

例えば、出力権限の実態が不明なら、権限一覧を確認するまでは暫定評価とします。その間の扱い、確認担当、期限も決めます。不明をゼロと扱わず、不明なまま残す場合にも理由と管理方法を持たせます。

【図4】点数の算定と、基準との比較を分ける

午後での問われ方

• 令和5年度秋期 午後問4（4.と同じ問題）：百貨店が定めた手順では、関係する既存の対策の状況を踏まえて、被害の大きさ（大・中・小）と発生頻度（高・中・低）を決め、表に当てはめてリスクレベル（A〜D）を決めます。解答例では、被害がいずれも「大」でも、発生頻度が「高」ならA、「低」ならCです。追加の対策として、配送管理用PCへのEDRの導入、プロキシのURLフィルタリングで閲覧できるURLを必要なものに絞ること、振舞い検知型又はアノマリ検知型のマルウェア対策ソフトの導入などが示されています。

この問題では、表に当てはめてレベルを決める作業を「評価」と呼んでいました。規格の定義（分析でレベルを決め、評価で基準と比べる）とは線の引き方が少し違います。問題文が手順を定めているときは、その呼び方に従います。

記述の型

• 頻度の見積り：「既存の対策の状況を考慮して、発生頻度を決める」

• 同じ点数の扱い：「点数だけでなく、影響の内容と、起こりやすさの根拠を記録する」

6. 損失は、機器代・復旧費・説明の費用まで見る

失われる資産の価値と、業務への影響は別に確認する

故障した機器の再購入額は、分かりやすい費用です。しかし、それだけでは失った情報の再作成、業務の遅延、利用者への影響を表せません。

例えば、受付記録を失った場合、申請者へ再提出を依頼することになるかもしれません。記録を集め直せても、提出時点を確認できないという問題が残る可能性もあります。

情報の再取得・再作成が可能か、権利や手続へどんな影響があるかを確認します。金額を見積もれない影響は、無価値として切り捨てず、別の尺度と説明で残します。

原因究明と復旧には、異なる作業がある

原因究明では、記録の収集、影響範囲の調査、不正な設定や侵入経路の確認などが必要になり得ます。復旧では、機器やデータを戻す作業に加え、安全性と業務上の正しさの確認が必要です。

外部専門家の費用だけでなく、内部の担当者が通常業務を離れる時間、臨時の運用、連携先との調整も考えます。

同じ作業費を「復旧」と「対応」の両方へ入れると二重計上になります。分類名は組織でそろえ、各項目が何を含むかを明記します。

社会的説明の費用を見落とさない

シラバスでは、社会的説明の費用も扱います。例えば、影響を受けた利用者への通知、問い合わせ対応、説明資料の作成、相談窓口の設置などの費用です。

必要な対応は、事象の性質や適用される要求によって異なります。すべての事故で同じ人数への通知や同じ窓口が必要になる、と一律に算定しません。

信用への影響も、根拠のない巨額の数値へ置き換えるより、どの関係者のどんな行動に影響するかを具体化します。説明できる費用と、金額化が難しい影響を分ける方が、判断者に伝わります。

架空の見積りを、項目から積み上げる

次の数字は、計算方法を説明するための仮定です。実際の事故の相場ではありません。

• 原因と影響範囲の調査：200万円。

• 復旧・設定確認・業務上の検証：250万円。

• 通知・問い合わせ対応：150万円。

• 臨時の受付・追加作業：200万円。

重複がなく、これらを一回の事象で要するという仮定なら、合計は800万円です。この金額に、把握していない損害や金額化しにくい影響まで含まれているわけではありません。

各項目には、人数、単価、期間、委託範囲などの前提を添えます。問い合わせの件数で費用が変わるなら、少ない場合と多い場合を分けて見積もる方法もあります。

年間予想損失額は、平均的な量の見積り

一回当たりの損失額と、一年当たりの発生頻度を仮定できる場合、次の簡略なモデルで年間予想損失額を考えられます。

年間予想損失額＝一回当たりの予想損失額×一年当たりの予想発生回数

用語として、年間予想損失額をALE（Annual Loss Expectancy）、一回当たりをSLE（Single Loss Expectancy）、年間発生頻度をARO（Annualized Rate of Occurrence）と表すことがあります。これらは年単位の損失を説明する用語であり、全組織にこの計算の採用を義務付けるものではありません。

先ほどの800万円を一回当たりの平均的な損失とし、年間発生頻度を0.2回／年と仮定すれば、年間予想損失額は160万円／年です。

0.2回／年は、五年ごとに必ず一回起きるという予定表ではありません。また、年に少なくとも一回起こる確率と、年間の平均発生回数は、繰り返し起こり得る事象では同じとは限りません。問題で与えられた値がどちらかを確認します。

この計算は、一回当たりの損失と頻度を単純化して扱うモデルです。複数の種類の事故を一つへ混ぜたり、頻度が高まると一回の損害も変わる状況を無視したりすれば、結果の意味が曖昧になります。

対策費が160万円を超えたら、直ちに無駄なのか

そうは言えません。年間予想損失額だけでは、重大事故が一度起きたときの負担、法令や契約上の要求、利用者への影響、推定の不確かさを判断しきれないためです。

費用面の一材料として使うなら、対策前後の同じ条件で見積もり、どの損失がどれだけ減る見込みかを比較します。初期費用と毎年の費用も同じ期間にそろえます。複数のリスクへ効果がある対策では、効果の重複計上にも注意します。

例えば、同じ仮定の下で対策後の頻度が0.05回／年になるなら、予想損失は40万円／年、差は120万円／年です。これはそのモデル上の年間の減少額であり、毎年必ず120万円が戻る約束ではありません。対策の効果自体にも根拠が必要です。

数字を使う目的は、判断を機械に任せることではなく、前提を変えたら結論が変わるかを確かめることです。

【図5】失うものと、対応に要する費用を分ける

7. 分析方法は、対象と判断に必要な深さで選ぶ

ベースラインアプローチ：共通の基準を手掛かりにする

基準やチェックリストと現状を比較し、基本的な対策の不足を把握する考え方です。多くの対象を一定の観点で確認する際に使えます。

例えば、利用者の管理、バックアップ、委託先の管理などを確認します。ただし、すべてに「実施済み」と回答できても、その組織固有の連携や業務の期限に伴うリスクまで分かったとは限りません。

項目の版、適用範囲、回答の裏付けが重要です。適用されない項目を無理に満たすことや、項目にないから安全と判断することを避けます。

非公式アプローチ：知識と経験から問題を見つける

分析者の知識や経験を中心に、形式を固定せず検討する考え方です。非公式という言葉は、無断で行うという意味ではありません。

経験のある担当者との聞取りで、台帳に現れない例外運用が分かることもあります。一方、得意な分野だけを詳しく見たり、判断理由が残らなかったりするおそれがあります。

実務では、参加者、確認した範囲、根拠、未確認事項を残し、別の担当者にも見てもらうことで偏りを補えます。

詳細リスク分析：シナリオと条件を深く調べる

資産、脅威、脆弱性、既存対策、影響、起こりやすさなどを詳しく調べる方法です。重要な業務や複雑な依存関係を理解する際に役立ちます。

ただし、詳細であることと、必ず金額・確率で表すことは別です。定性的な区分を使いながら、根拠や成立条件を詳しく記述する場合もあります。

調査対象を広げすぎれば、時間と費用が増えます。資料が不正確なら、細かな数字を付けても結論の信頼性は上がりません。

組合せアプローチ：広く見た後、必要な部分を深める

全体を共通の観点で確認し、重要な業務や気になる箇所を詳しく分析するなど、方法を組み合わせる考え方です。

限られた資源を配分しやすい一方、最初の選別で重要な対象を落とすと、その後に詳しく調べられません。新規サービス、外部連携、影響が大きい業務、根拠が不足する箇所などを、深掘りする条件として明らかにします。

四つの整理は方法を理解する手掛かりです。組合せが常に最適、詳細分析が常に最も正確、と順位を固定しません。判断の目的、対象、利用できる情報、時間、人員に合わせて選びます。

診断結果やツールの点数を、そのまま業務リスクにしない

技術的な弱点の深刻さと、自組織でのリスクは関係しますが、同一ではありません。対象の機能を使っているか、外部から到達できるか、何の情報を扱うか、既存対策があるかを確認します。

例えば、深刻な弱点がある製品でも、今回の構成にその機能が含まれているかは確認が必要です。反対に、技術的な点数だけでは目立たない設定の不備が、重要な業務情報の大量取得につながる場合もあります。

ツールの結果は、分析の材料です。調査対象外、誤検知の可能性、確認日を含め、業務への影響と結び付けて読みます。

【図6】分析方法は、目的・情報・資源に合わせる

8. STRIDEで、構成と情報の流れに脅威を当てはめる

脅威モデリングでは、対象の姿を先に共有する

脅威モデリングは、システムの構成や使い方をモデルにし、どのような脅威があり、どう扱うかを検討する取組です。開発時だけでなく、構成や機能が変わる際の見直しにも使います。

まず、誰が利用し、どの処理へ、何のデータを渡し、どこへ保存するかを整理します。データフロー図（DFD）は、処理、保存先、外部の主体、情報の流れを表す方法です。

信頼境界は、信頼の前提や権限・管理主体が変わる境目です。例えば、利用者の端末からサービスへ入力が渡る場所や、利用組織から外部サービスへ情報が渡る場所で、何を信用し、何を検証するかを考えます。OWASP「Threat Modeling Cheat Sheet」、System Modeling節

これは、境界の内側なら何でも安全という意味ではありません。内部の処理間でも、権限や入力への信頼の前提が異なれば、確認が必要です。

STRIDEは六つの問いを用意する

STRIDEは、脅威を六つの観点に整理する方法です。Microsoftの公式説明でも、脅威について具体的な問いを立てるための分類として紹介されています。Microsoft「Threat Modeling Tool threats」、STRIDE model節

以下の例は、本稿の架空の申請サービスに当てはめたものです。

S：Spoofing（なりすまし）

ほかの利用者やサービスを装えないかを考えます。例えば、受付担当者を装って接続する経路です。誰をどう確認し、そのための情報をどう管理するかを調べます。

T：Tampering（改ざん）

データを不正に変更できないかを考えます。例えば、確認済みの申請内容や処理結果を、権限のない利用者が変更する場面です。通信中・保存中・処理中のどこで変えられるかを分けます。

R：Repudiation（否認）

実行した操作を否定されたとき、確認に必要な証拠があるかを考えます。例えば、申請の承認を取り消した操作について、主体と内容を確かめられない場面です。記録の不足は、この脅威を扱いにくくする条件になります。

I：Information Disclosure（情報漏えい）

見る権限のない相手へ情報が渡らないかを考えます。例えば、他人の申請内容が表示される、必要のない情報まで出力に含まれる場面です。

D：Denial of Service（サービス妨害）

正当な利用者がサービスを使えなくならないかを考えます。例えば、大量の要求で受付処理が利用できなくなる場面です。対象となる処理や資源を具体化します。

E：Elevation of Privilege（特権昇格）

本来持たない強い権限を得られないかを考えます。例えば、閲覧のみの利用者が管理者向けの機能を実行できる場面です。単なるなりすましと区別し、与えられた権限を越える条件を調べます。

分類名を並べるだけで終わらせない

「Sあり、Tあり」と記録しても、何を直すべきかは分かりません。本稿では、対象の処理・データ、成立条件、起こること、影響、既存対策、未確認事項を添えることを提案します。

例えば、一覧出力の機能については、なりすましによる利用と、正当な利用者による権限外の出力を分けます。原因が違えば、確認する設定や対策も変わります。

一つのシナリオが複数の分類に関わっても構いません。重要なのは六つへ均等に配分することではなく、構成と業務に即して見落としを減らすことです。

STRIDEだけで、すべてのリスクを扱ったことにはならない

STRIDEは、攻撃に関係する脅威を考える助けになります。しかし、自然災害、単純な故障、担当者の不在、契約終了に伴うサービス停止なども、リスクアセスメントでは必要に応じて扱います。

また、分類できたことと、起こりやすさや影響を評価したことは違います。洗い出したシナリオを、5.の分析と評価へつなげます。

【図7】STRIDE：六つの観点で脅威を考える

9. アタックツリーで、攻撃目標に至る経路を読む

根に目標、枝に達成方法を置く

アタックツリー分析（ATA：Attack Tree Analysis）は、攻撃者が達成しようとする目標を根に置き、その達成方法や条件を枝へ分解する方法です。

ORは、子の条件のいずれかが成立すれば、親の目標へつながる関係です。ANDは、子の条件がすべて成立する必要がある関係です。この区別を曖昧にすると、対策の効果を読み違えます。Bruce Schneier「Attack Trees」、1999年12月、Enter Attack Trees節

架空の出力ファイルを対象に考える

説明用に、攻撃目標を「申請情報の出力ファイルを、権限のない人が取得する」とします。ここでは、次の二経路だけを描いた部分的なモデルにします。

• 経路A：業務アカウントを不正利用して取得する。

• 経路B：外部共有リンクから取得する。

どちらかで目標が達成されるという前提なら、根の接続はORです。

経路Aでは、「出力権限のあるアカウントを不正利用できる」と「そのアカウントから出力機能へ到達して実行できる」の両方が必要とします。この二条件はANDです。

経路Bでは、「閲覧用の共有リンクを入手する」と「そのリンクだけで、追加の本人確認なしにファイルを取得できる」の両方が必要とします。こちらもANDです。

これは本稿で仮定した仕様です。実際には接続制限や追加認証などで条件が増え、別の経路もあり得ます。図には、どこまでをモデルにしたかを明記します。

ORは、一本塞いでも別の経路が残る

経路Aに対策を入れても、経路Bが成立するなら、描いた目標を防ぎ切れません。共有リンクの設定だけ直しても、アカウント経路は別に検討が必要です。

この関係は、対策を一つ選んだときに何が残るかを確認するために役立ちます。目立つ攻撃方法だけを塞いで、別の入口を見落とすことを防ぎます。

ANDは、必要条件の一つを崩すと、その枝が成立しなくなる

経路Bの例なら、共有リンクだけでは取得できないようにすることは、描いた二条件のうち一つを崩す方法になります。

ただし、これはモデルが正しい範囲での話です。別の公開先に複製がある、別の認証情報を盗めるといった経路があれば、図を追加して考えます。「ANDを一つ塞いだから情報漏えいは絶対に起きない」と広げないようにします。

枝の本数から、確率を計算しない

ORが二本あっても、成功確率が二倍になるとは限りません。同じ認証基盤や同じ設定に依存している場合、条件は独立ではありません。

また、ANDの二条件も、単純に二つの確率を掛けられるとは限りません。確率を計算するなら、独立性や条件付き確率など、追加のモデルと根拠が必要です。本稿では、まず成立条件の論理関係を読むところまで押さえます。

STRIDEが見落としを減らす観点なら、アタックツリーは目標への経路と条件を具体化する手段として、組み合わせて使えます。

【図8】アタックツリー：目標への経路と条件を読む

10. リスク対応の4分類と、残留リスク

四つの対応を区別する

評価の結果をもとに、リスクごとに対応を決めます。

• リスク低減：対策によって、起こりやすさや被害を小さくする。例：権限を最小限に見直す、持ち出す端末に保存するデータを必要最小限にする

• リスク回避：リスクの原因となる業務や事象そのものをやめる。例：インターネットに接続する必要のない業務を、接続そのものをやめて行う

• リスク移転：契約などで、リスクを第三者に移す。例：サイバー保険に加入する、専門の事業者に委託する。ただし、委託しても責任のすべてが移るわけではない

• リスク保有：対策をとらずにリスクを受け入れ、損失が起きたら自ら負担する。あえて対策をとらない判断は、リスク受容とも呼ぶ

既存の対策があるから追加は不要、と判断する前に、その対策が想定する攻撃に本当に効くかを確かめます。例えば、パターンマッチング型のマルウェア対策ソフトでは、未知のマルウェアを検知できないことがあります（支援士解説3の2）。

残留リスクは、特定してから承認する

対策をしても、リスクがゼロになるとは限りません。対応した後に残るリスクを残留リスクと呼びます。残留リスクは、まず「誰が、どのような方法で、何をするリスクか」まで具体的に特定し、リスク所有者（そのリスクを管理する責任と権限を持つ人）が承認したうえで受け入れ、その後も監視し、見直します。対応計画の立て方と、管理策の選び方は支援士解説1の3で扱います。

午後での問われ方

• 令和7年度秋期 午後問4：サプライチェーンでのセキュリティ管理が題材で、サイバーセキュリティ経営ガイドラインの指示（サイバー保険の活用や専門ベンダへの委託を含めたリスク対応計画を策定させ、対応後の残留リスクを識別させる）を踏まえた助言が描かれました。リスクに対応する方法は「低減」のほか、「回避」「移転」「保有」の四つに分類されるとして、空欄で問われています。マルウェア対策ソフトを入れているので追加の対策は不要、という考えに対し、パターンマッチング型では検知できないおそれがあるので追加の対策が必要と指摘し、最小権限の原則に沿って権限の設定を見直すことで、リスクを低減する例が示されています。

• 平成29年度秋期 午後II問2：データベースの暗号化と鍵の管理が題材でした。暗号化の対策をした後に残るリスクとして、解答例は「業務担当者及び契約者が業務アプリケーションを利用して持ち出すリスク」と「オペレータ及びシステム管理者が、メモリダンプから平文の契約情報を読み出し、持ち出すリスク」です。

採点講評で指摘されたつまずき

• 平成29年度秋期 午後II問2では、対策後の残留リスクを問う設問の正答率が低く、セキュリティ対策の設計において、対策後の残留リスクを正しく分析する能力を身に付けてほしいとされています。一方、比較的簡単な前提でリスクを特定したり数値化したりする設問の正答率は高かったとされています。

記述の型

• リスク対応の分類：「リスク低減・リスク回避・リスク移転・リスク保有」

• 回避の例：「リスクの原因となる業務や接続そのものをやめる」

• 移転の例：「保険に加入する」「外部の専門事業者に委託する」

• 残留リスクの扱い：「誰がどのような方法で何をするリスクかを特定し、リスク所有者の承認を得て受容し、継続して監視する」

11. 評価結果を、責任者が判断できる形にする

一件のリスクを、資産から判断までたどれるようにする

架空の申請サービスについて、全件出力のリスクをまとめてみます。次は、記録へ残す項目の例です。

• 対象：申請情報と、受付担当者が利用する出力機能。

• シナリオ：アカウントの不正利用が、広い出力権限と結び付き、大量取得へつながる。

• 影響：情報の流出、範囲の調査、申請者への説明、通常業務への支障。

• 既存対策：認証、権限管理、操作記録。実際の適用範囲と有効性を別途確認。

• 分析：今後一年を対象とする。根拠を確認できた条件の下で、影響度3、起こりやすさ2、点数6。

• 評価：説明用の基準では高に該当し、追加対応の検討が必要。

• 判断の責任者：担当業務とリスクに対する権限を持つ人。部署をまたぐ判断は上位へ調整。

• 未確認事項：実際の出力可能者、取得記録の範囲、追加認証の適用。

この例の点数を、そのまま別のサービスへ転記してはいけません。前提と実態を確認して初めて、判断に使えます。

優先順位は、対応の段取りへ渡す

「高が十件あります」と伝えるだけでは、責任者が資源を配分しにくい場合があります。影響、進行中の事象の有無、要求事項の期限、未確認事項、複数のリスクに共通する原因を添えます。

冒頭の問いに戻ります。二つの課題はどちらも点数6の高でした。点数が同じなので、点数だけでは「どちらに先に予算を付けるか」は決まりません。責任者に示すのは、次のような材料です。

• 出力権限：今この時点でも、広い権限が付与されたまま使われているか（進行中か）。不要な権限を外すだけなら、大きな予算を待たずに着手できるか

• 締切日の停止：次の締切はいつか。それまでに、窓口や紙での受付など代わりの手段を用意できるか

• 未確認の事項：実際に出力できる人数、取得の記録、追加認証の有無が分からないなら、確認の担当と期限

こうした材料をそろえると、「出力権限は今週中に不要な権限を外し、締切日の代わりの手段は次の締切までに用意する」のように、なぜその順番で、いつまでに対応するのかを説明できます。リスクアセスメントの目的は、この説明の根拠をそろえることです（数字と順番は説明用の例です）。

例えば、受付停止のリスクが締切直前に高まるなら、時期を含めて示します。複数のリスクが同じ権限管理の問題へつながるなら、その関係をまとめます。

ただし、直しやすいものを先に処理することと、重大さの評価は別です。作業の段取り上は小さな修正を先に行っても、重大なリスクの対応責任や期限を曖昧にしないようにします。

分析担当者の役割と、意思決定者の役割をつなぐ

分析担当者は、分かっていること、仮定したこと、分からないことを分け、選択肢を判断できる情報を用意します。意思決定者は、その根拠と組織の要求を踏まえて、対応や追加調査、必要な資源を決めます。

「専門家が高と言ったから」だけでは、説明として不足します。逆に、意思決定者の希望に合わせて点数を下げることも、分析の意味を失わせます。

意見が分かれた場合は、どの条件の認識が違うかを確認します。停止時間の見積りが違うのか、影響する業務が違うのか、既存対策への信頼が違うのかを分けると、追加確認の対象が見えてきます。

結果を残し、変化に応じて見直す

評価日、対象の版、基準の版、根拠、判断者、判断結果を残します。担当者の交代後も、なぜその結論になったかを確認できることが大切です。

見直しの契機には、定期的な確認のほか、新規導入、外部連携の追加、扱う情報の変更、重大な弱点の判明、事故、契約変更などがあります。

対策を実施した後も、想定した効果が出ているかを確認します。残っているリスクの判断や承認は、次の1-3とつながります。

12. 午前II（科目A-2）で正誤を見分けるポイント

• 「完全性とは、許可された利用者が必要なときに情報を使える性質である」→ 誤り。それは可用性。完全性は正確さと完全さ

• 「否認防止とは、事象とその主体を後から証明できるようにすることである」→ 正しい

• 「リスク分析とは、リスクをリスク基準と比べて、対応の要否を判断するプロセスである」→ 誤り。それはリスク評価

• 「リスクアセスメントは、リスク特定・リスク分析・リスク評価から成る」→ 正しい

• 「ベースラインアプローチは、既存の基準やチェックリストを使って、簡易に分析する方法である」→ 正しい

• 「組合せアプローチは、全体を簡易に分析し、重要な部分を詳細に分析する」→ 正しい

• 「年間予想損失額は、1回の損失額に年間の発生頻度を掛けて求める」→ 正しい

• 「STRIDEのRは、権限の昇格（Elevation of privilege）を表す」→ 誤り。Rは否認（Repudiation）。Eが権限の昇格

• 「アタックツリーのANDの枝は、条件の一つを崩せば、その枝の攻撃が成り立たなくなる」→ 正しい

• 「リスク移転の例として、サイバー保険に加入する」→ 正しい

• 「リスク保有とは、リスクの原因となる業務をやめることである」→ 誤り。それはリスク回避

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　情報の特性

公開済みの案内ページで、避難場所が不正に書き換えられました。まず注目すべき特性はどれでしょうか。

• ア：公開情報なので、情報セキュリティの問題ではない。

• イ：案内の正しさが損なわれているため、完全性。

• ウ：公開情報の内容が見られたことによる機密性。

• エ：書き換えが起きた時点で、必ず可用性だけが損なわれる。

正解：イ。 内容の正確さに関わる問題です。アは公開情報にも保護が必要であることを見落としています。ウは公開内容の閲覧と不正な変更を混同しています。エは、閲覧できるまま内容だけ変わる場合を考慮していません。

問2　脅威と脆弱性

全件出力の権限が不要な職員へ残っています。適切な説明はどれでしょうか。

• ア：権限が残ること自体が、被害額を表す。

• イ：外部からの不正な取得の試みは、必ず脆弱性に分類する。

• ウ：不要な権限は弱点になり得る。不正な取得などの事象と結び付け、影響を検討する。

• エ：権限の不備を見つけたので、被害発生を確認したと扱う。

正解：ウ。 弱点と事象、影響を関連付けます。アは状態と損失を混同しています。イは脅威事象を弱点と取り違えています。エは可能性と発生済みの事実を混同しています。

問3　三つのプロセス

リスクの点数を算定した後、事前に定めた受容基準と比較しています。この作業はどれでしょうか。

• ア：リスク特定。

• イ：資産の購入価格の算定。

• ウ：対策の設定作業。

• エ：リスク評価。

正解：エ。 分析結果と基準を比較する作業です。アは出来事や条件を見つけて記述する段階、イは影響分析の一材料となり得る作業、ウは対策の実施であり、今回の作業とは異なります。

問4　損失の計算

一回当たり800万円、年間発生頻度0.2回／年という仮定で、簡略モデルを使います。適切なものはどれでしょうか。

• ア：年間予想損失額は4,000万円／年である。

• イ：五年後に必ず800万円の損失が発生する。

• ウ：年間予想損失額は160万円／年であり、対策費の上限をこれだけで断定しない。

• エ：年間160万円を超える対策は、適用する義務に関係なくすべて不要である。

正解：ウ。 800×0.2＝160です。アは割り算にしています。イは平均的な頻度を発生の予定へ置き換えています。エは重大な影響や義務、不確かさを無視しています。

問5　リスク対応の分類

業務でインターネットに接続する必要がない端末について、不正アクセスのリスクをなくすため、その端末のインターネットへの接続をやめることにした。この対応の分類として、最も適切なものはどれか。

• ア：リスク低減

• イ：リスク回避

• ウ：リスク移転

• エ：リスク保有

正解：イ。リスクの原因となる接続そのものをやめているので、回避です。保険への加入や委託は移転、対策をとらずに受け入れるのは保有です。

実務と国・自治体では

実務では、評価表を作ることが目的になり、誰も次の判断をしないまま終わることがあります。一件のリスクについて、守る資産、起こり得る出来事、既存の対策の状況、レベルと根拠、対応の案、残るリスク、判断する人を一続きにたどれる形で残します。全項目を「中」にして理由を残さない、事故がなかったので可能性を低とする、件数や平均で大きな影響を隠す、といった落とし穴にも注意します。

政府機関等の統一基準は、目的や点検・監査の結果を考慮したリスクの分析・評価と、その結果の対策基準への反映を求めています。自治体向けのガイドラインも、業務・情報・システムの特性を考慮したリスク分析を例文で示しています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• リスクは、資産・脅威・脆弱性を、起こり得る出来事として結ぶ。 「誰が、何をして、どのような経緯で、何が損なわれるか」まで具体的に書く。

• アセスメントは、特定・分析・評価。 規格では、分析でレベルを決め、評価で基準と比べる。問題文に手順があれば、その呼び方に従う。

• 頻度は、既存の対策の状況を踏まえて見積もる。 点数の根拠と、影響の内容を残す。

• 対応は、低減・回避・移転・保有。 残留リスクは、具体的に特定してから承認し、監視を続ける。

• 同じ点数のリスクの順番は、進行中か、期限、すぐ着手できるか、未確認の事項で説明する。 「なぜその対応を優先するのか」に、根拠を添えて答えられるようにする。

さらに深く学ぶなら

この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。

STRIDEを考案した著者による、脅威モデリングに基づく設計の考え方

関連記事

• 前提：情報セキュリティ方針は、何を守り、誰が決める？｜支援士解説1の1（方針と体制）

• 次に読む：どこまで対策し、何を引きうける？｜支援士解説1の3（リスク対応と管理策）

• あわせて読む：「安全に配慮」を要件に変える｜支援士解説2の1（リスクから要件へ）

• あわせて読む：脆弱性対応の優先順位はどう決める？｜支援士解説3の6（脆弱性の優先度）

2026年10月改訂：午後の出題例と記述の型を加え、リスク対応の4分類と残留リスクの節を新設し（1-3から寄せた要点）、構成を見直しました。