情報セキュリティ管理
SG試験 ケース問題の解き方テンプレ【情報セキュリティマネジメント】
- Source: pages\sg\case-solving-template.md
- Permalink: /sg/case-solving-template/
まず結論
- SGのケース問題は「原因 → 対策の種類 → 順番」で解く
- 迷ったら「人・ルール・技術・委託・インシデント」のどれかで切る
直感的な説明
SGの問題は一見むずかしく見えますが、やっていることはシンプルです👇
👉 「何が原因?」
👉 「どの対策が合う?」
この2つだけ
定義・仕組み
解き方テンプレ(これだけ覚える)
① 原因を特定する
👉 人?ルール?技術?外部?事故?
② 対策の種類を決める
👉 教育?安全管理?委託管理?インシデント対応?
③ 順番を確認する
👉 いまやるべきことか?
対策の分類(超重要)
問題を見たらまずこれ👇
- 人の問題 → 教育・訓練
- ルール不足 → 組織的対策
- システム問題 → 技術的対策
- 外部委託 → 委託先管理
- 事故発生後 → インシデント対応
👉 ここで8割決まる
どんな場面で使う?
ケース問題の典型パターン
パターン①:人的ミス
例👇
- 誤送信
- フィッシング
👉 教育・訓練
パターン②:管理不足
例👇
- ルール未整備
- 責任不明
👉 組織的対策
パターン③:技術不足
例👇
- アクセス制御なし
- ログなし
👉 技術的対策
パターン④:委託問題
例👇
- 外部業者のミス
👉 委託先管理
パターン⑤:事故発生後
例👇
- ウイルス感染
👉 インシデント対応(拡大防止)
よくある誤解・混同
❌ よくある誤解
- とりあえず技術対策を選ぶ
- 強そうな対策を選ぶ
⭕ 正しい理解
- 原因に合った対策を選ぶ
- 順番を守る
SG試験のひっかけ
典型パターン👇
- 人の問題なのに技術対策 → ❌
- 初動対応なのに原因調査 → ❌
- 委託なのに自社対策 → ❌
👉 原因とズレた選択肢を切る
まとめ(試験直前用)
- 「原因 → 対策 → 順番」で考える
- 人・ルール・技術・委託・事故で分類
- 強そうな対策ではなく適切な対策
- インシデントはまず拡大防止
- 「ズレている選択肢」を消す
🔗 関連記事
- 関連記事は準備中です。
ケース問題の解き方!CIAとリスク対応で考える実践手順【SG試験】
- Source: pages\sg\case-study-approach.md
- Permalink: /sg/case-study-approach/
まず結論
ケース問題は「CIA → 対策 → リスク対応」の順で考えると安定して解けます。
SG試験では「何が起きているか → どう対応するか」の判断力が問われます。
直感的な説明
問題文は長いですが、やることはシンプルです👇
- 何が起きているか見る
- 何が困るか考える
- どうすればいいか選ぶ
👉 順番を守るだけで解ける
定義・仕組み
解く手順(最重要)
① 事象の把握
- どんな攻撃・問題かを確認
例:
- DDoS → サービス停止
② CIAで分類
- 何が壊れているか
例:
- サービス停止 → 可用性
③ 対策を考える
- どの対策が適切か
例:
- 冗長化・負荷分散
④ リスク対応を判断
- 実施するかどうか
例:
- コストを考えて低減を選択
👉 この4ステップで解く
どんな場面で使う?
典型問題パターン
- 「最も適切な対応はどれか」
- 「優先すべき対策はどれか」
解き方のコツ
- いきなり選択肢を見ない
- まずCIAを決める
👉 これだけで正答率が上がる
よくある誤解・混同
❌ 知っている用語で選ぶ
→ ⭕ 問題に合っているかで選ぶ
❌ 強そうな対策を選ぶ
→ ⭕ 目的に合った対策を選ぶ
❌ 完璧な対策を選ぶ
→ ⭕ 現実的な対応を選ぶ
SG試験のひっかけ
- 「暗号化」など万能そうな選択肢に注意
- 「目的とズレている対策」は不正解
例:
- DDoS対策 → 暗号化 ❌
- 改ざん対策 → バックアップ ❌(直接ではない)
👉 CIAと一致しているかで切る
まとめ(試験直前用)
- 手順は4ステップ
→ 事象 → CIA → 対策 → リスク対応 - まずCIAを決める
- 対策は目的と一致させる
- 最後は現実的な判断
- SG試験は「流れ」で解く
🔗 関連記事
- 関連記事は準備中です。
よくある誤答パターンまとめ!SG試験で選択肢を切るコツ【情報セキュリティマネジメント】
- Source: pages\sg\common-mistakes.md
- Permalink: /sg/common-mistakes/
まず結論
SG試験の誤答は「目的とズレた対策を選んでしまうこと」が原因です。
「CIAと一致しているか」で選択肢を切ることが最重要です。
直感的な説明
間違いはだいたい同じです。
- 強そうな対策を選ぶ
- とりあえず安全そうなものを選ぶ
- 用語を知っているから選ぶ
👉 全部ダメです
正しくは👇
👉 「この問題で必要な対策か?」を見る
定義・仕組み
誤答の原因(3パターン)
① CIAのズレ
- 問題:可用性
- 選択:機密性対策 → ❌
例:
- DDoS対策 → 暗号化 ❌
② 手段と目的の混同
- 手段だけ見て選ぶ
例:
- ボットネット=攻撃そのもの ❌
→ 実際は攻撃の仕組み
③ 現実性の無視
- 完璧すぎる対策を選ぶ
例:
- サービス停止(回避)を選ぶ ❌
→ 業務が成り立たない
どんな場面で使う?
SG試験の典型ミス
問題文👇
- 「サービス停止を防ぐ」
- 「情報漏えいを防止」
なのに👇
- 違う目的の対策を選ぶ
👉 ここで落とす人が多い
正しい判断の流れ
- 何が問題か
- CIAで分類
- 対策が一致しているか
👉 この3つで切る
よくある誤解・混同
❌ 暗号化は万能
→ ⭕ 機密性だけ
❌ バックアップは最強
→ ⭕ 可用性中心
❌ 強い対策=正解
→ ⭕ 目的に合っているかが重要
SG試験のひっかけ(超重要)
パターン①
- DDoS問題
→ 暗号化・認証を選ばせる
👉 ❌(可用性とズレ)
パターン②
- 改ざん問題
→ バックアップを選ばせる
👉 ❌(直接対策ではない)
パターン③
- 現実的判断
→ 回避(サービス停止)を選ばせる
👉 ❌(過剰対応)
まとめ(試験直前用)
- 誤答の原因=CIAのズレ
- まずCIAを判断する
- 対策が一致しているか確認
- 強そうな選択肢に注意
- SG試験は「目的一致」で切る
🔗 関連記事
- 関連記事は準備中です。
CSIRTとは?組織内インシデント対応の基本【情報セキュリティマネジメント】
- Source: pages\sg\csirt.md
- Permalink: /sg/csirt/
まず結論
- CSIRTは、組織内で発生したセキュリティインシデントに対応する専門チームである。
- SG試験では「社内対応か、外部支援か(JPCERT/CC)」を見分ける問題が多い。
直感的な説明
会社でトラブルが起きたとき、
現場で対応する「社内の専門チーム」が必要ですよね。
CSIRTはまさにそれで、
会社の中でセキュリティ事故に対応する“専任チーム”です。
例えば:
- ウイルス感染したPCの対応
- 不正アクセスの調査
- 情報漏えいの原因分析
などを担当します。
👉 イメージ:
CSIRT=社内の消防隊(火事が起きたらすぐ出動)
定義・仕組み
CSIRT(Computer Security Incident Response Team)は、
- セキュリティインシデントの
- 検知
- 分析
- 対応
- 復旧
を行う組織内のチームです。
基本の役割
- インシデントの検知(異常の発見)
- 影響範囲の調査
- 被害拡大の防止
- 原因分析と再発防止
ポイント
- 組織内に設置される
- 実際に手を動かして対応する
- 必要に応じて外部(JPCERT/CCなど)と連携する
SG試験では
「インシデントに対処する実働部隊」として理解すればOKです。
どんな場面で使う?
使う場面(正しい理解)
- 自社でセキュリティ事故が発生したとき
- 社内ネットワークで異常が検知されたとき
- 被害の拡大を防ぐための初動対応
使うと誤解しやすい場面
- ❌ 外部の相談窓口(それはJPCERT/CC)
- ❌ 経営判断を行う組織(それは経営層やISMS)
よくある誤解・混同
① JPCERT/CCとの違い
- CSIRT:組織内の対応チーム(自社で動く)
- JPCERT/CC:外部から支援する組織
👉 SG試験ではここをよく入れ替えてくる
② SOCとの違い
- SOC:監視・検知が中心
- CSIRT:実際の対応・復旧まで行う
👉 「対応までやるか?」で切る
③ ISMSとの違い
- ISMS:管理の仕組み(ルール・体制)
- CSIRT:実務の対応チーム
👉 「仕組み」か「実働」かで判断
まとめ(試験直前用)
- CSIRT=組織内のインシデント対応チーム
- 実際に対応・復旧まで行う「現場部隊」
- 選択肢では
- 「外部機関」→×
- 「監視だけ」→×
- 「対応・復旧を行う」→○
👉 「社内で実際に動くかどうか」で切る
🔗 関連記事
- 関連記事は準備中です。
不正のトライアングルとは?内部不正が起こる3要素【情報セキュリティマネジメント】
- Source: pages\sg\fraud-triangle.md
- Permalink: /sg/fraud-triangle/
まず結論
不正のトライアングルとは、「動機・機会・正当化」の3つがそろうと不正が発生しやすくなるという考え方であり、SG試験では不正を防ぐためにどの要素を断つべきかを判断させる問題として出題されます。
直感的な説明
たとえば、社内で不正が起きる場面を考えてみます。
- お金に困っている(動機)
- 一人で処理できてチェックがない(機会)
- 「これくらい大丈夫」と思ってしまう(正当化)
この3つがそろうと、不正が起きやすくなります。
逆に言うと、どれか1つでも崩せば不正は起きにくくなるというのがポイントです。
定義・仕組み
不正のトライアングルは、内部不正や不祥事の原因分析に使われる基本概念です。
3つの要素は以下のとおりです。
① 動機(Motivation)
不正をしたくなる理由
例:
- 金銭的な問題
- ノルマ・プレッシャー
- 不満(待遇・評価)
② 機会(Opportunity)
不正ができてしまう状況
例:
- チェック体制がない
- 権限が集中している
- ログ監視が不十分
👉 業務設計やアクセス管理の問題がここに該当
③ 正当化(Rationalization)
「やっても仕方ない」と思う心理
例:
- 「会社も不正している」
- 「自分は正当に評価されていない」
- 「一度だけなら問題ない」
👉 教育や組織文化の問題がここに該当
どんな場面で使う?
不正対策を考えるとき
SG試験では、「どう防ぐか」が問われます。
-
機会を減らす
→ 職務分掌、アクセス制御、監査ログ -
動機を減らす
→ 適切な評価制度、労務管理 -
正当化を防ぐ
→ セキュリティ教育、倫理意識の向上
ケース問題(科目B)
- 「なぜ不正が起きたか」
- 「どの対策が有効か」
👉 3要素のどこに問題があったかを見抜くのがポイント
よくある誤解・混同
❌ 技術対策だけで防げる
→ ⭕ 正当化や動機も関係する
SG試験では
「アクセス制御を強化すれば十分」といった選択肢が出ますが不正解になりやすいです。
❌ 不正は悪い人がやるもの
→ ⭕ 誰でも条件がそろえば起こり得る
👉 人ではなく「環境」に注目するのが重要
❌ 動機がなければ安全
→ ⭕ 機会があるだけでもリスク
👉 権限集中・チェック不足は要注意
まとめ(試験直前用)
- 不正は「動機・機会・正当化」の3つがそろうと起きる
- 対策は「どれか1つを断つ」視点で考える
- SG試験では「機会(統制の不備)」がよく問われる
- 技術対策だけでなく、教育・組織も含めて判断する
🔗 関連記事
- 関連記事は準備中です。
インシデント対応とは?初動対応の判断基準を整理【情報セキュリティマネジメント】
- Source: pages\sg\incident-response.md
- Permalink: /sg/incident-response/
まず結論
- インシデント対応とは「事故発生時に被害を最小化するための対応」
- SG試験では「最初にやるべき行動(初動対応)」を判断させる問題がよく出る
直感的な説明
情報漏えいや不正アクセスが起きたとき👇
- すぐ復旧する?
- 原因を調べる?
👉 実はどっちも違う
まずやるべきは👇
👉 被害の拡大を止める
定義・仕組み
インシデントとは
- 情報セキュリティ上の事故
例👇 - 情報漏えい
- 不正アクセス
- マルウェア感染
インシデント対応の基本流れ
① 検知・把握
→ 何が起きたか確認
② 初動対応(最重要)
→ 拡大防止
③ 原因調査
→ なぜ起きたか
④ 復旧
→ 元の状態に戻す
⑤ 再発防止
→ 同じ事故を防ぐ
👉 SG試験は「②初動対応」をよく聞く
どんな場面で使う?
科目Bの典型パターン
- ウイルス感染
- 不正アクセス検知
- 誤送信発覚
正しい初動対応(超重要)
例👇
- ネットワークから切り離す
- アカウント停止
- システム隔離
👉 共通点👇
👉 拡大防止
NG対応(よく出る)
- いきなり復旧
- 原因調査を優先
- 報告せず自己判断
👉 順番ミスが狙われる
よくある誤解・混同
❌ よくある誤解
- まず原因調査
- すぐ復旧が最優先
⭕ 正しい理解
- 最優先は拡大防止
- その後に調査・復旧
SG試験のひっかけ
典型パターン👇
- 「原因調査」→ ❌(まだ早い)
- 「復旧作業」→ ❌(まだ早い)
- 「隔離・停止」→ ⭕
👉 「順番」で判断する
まとめ(試験直前用)
- インシデント対応=事故時の対応
- 最優先は拡大防止
- 流れは「検知→拡大防止→調査→復旧→再発防止」
- 原因調査や復旧は後
- 「最初に何をするか」で選択肢を切る
🔗 関連記事
- 関連記事は準備中です。
JPCERT/CCとは?役割とCSIRTとの違いを整理【情報セキュリティマネジメント】
- Source: pages\sg\jpcert-cc.md
- Permalink: /sg/jpcert-cc/
まず結論
- JPCERT/CCは、日本国内のセキュリティインシデント対応を支援する中立的な組織(CSIRT)である。
- SG試験では「政府機関ではない独立組織」という点を判断させる問題が多い。
直感的な説明
会社でトラブルが起きたときに、
「専門家に相談して対処を手伝ってもらう」ことがありますよね。
JPCERT/CCは、
日本全体のセキュリティ相談窓口+専門支援チームのような存在です。
- 不正アクセスがあった
- マルウェアに感染した
- 情報漏えいの可能性がある
こういったときに、
企業や組織をまたいで対応をサポートする役割を担っています。
定義・仕組み
JPCERT/CC(JPCERT Coordination Center)は、
- コンピュータセキュリティインシデントに関する
- 報告の受付
- 対応支援
- 情報共有
- 再発防止の助言
を行う組織です。
ポイントは次の3つです。
① 中立・独立の組織
- 特定の政府機関や企業に属さない
- 公平な立場で対応できる
② 日本版CSIRT
- CSIRT(Computer Security Incident Response Team)の一種
- 国内全体を対象にした「調整役」
③ 情報共有のハブ
- 攻撃手法や脆弱性情報を収集・共有
- 被害の拡大を防ぐ役割
SG試験では
「インシデント対応を支援する組織」=JPCERT/CC
と押さえておけばOKです。
どんな場面で使う?
使う場面(正しい理解)
- インシデントが発生したときの相談・支援
- 複数組織にまたがる攻撃への対応
- 攻撃情報の共有・注意喚起
使うと誤解しやすい場面
- ❌ 社内対応チーム(それはCSIRT)
- ❌ 政府の司令塔(それはNCOなど)
よくある誤解・混同
① CSIRTとの違い
- CSIRT:組織内の対応チーム
- JPCERT/CC:外部の支援・調整機関
👉 SG試験ではここを混同させてきます
② NCO(国家サイバー統括室)との違い
- NCO:政府の司令塔(内閣官房)
- JPCERT/CC:独立した民間組織
👉 「政府かどうか」で切るのがポイント
③ CRYPTRECとの違い
- CRYPTREC:暗号の評価・推奨
- JPCERT/CC:インシデント対応
👉 「暗号か?インシデントか?」で判断
④ JISCとの違い
- JISC:標準化(JIS)
- JPCERT/CC:セキュリティ対応支援
👉 分野が全く違う
まとめ(試験直前用)
- JPCERT/CC=日本のインシデント対応支援組織(CSIRT)
- 政府ではなく中立・独立の組織
- 役割は「報告受付・対応支援・情報共有」
- 選択肢では
- 「政府機関」→×
- 「暗号評価」→×
- 「インシデント対応支援」→○
👉 「誰の組織か」ではなく「何をするか」で切る
🔗 関連記事
- 関連記事は準備中です。
NCOとは?政府のサイバー司令塔を理解する【情報セキュリティマネジメント】
- Source: pages\sg\nco.md
- Permalink: /sg/nco/
まず結論
- NCOは、内閣官房に設置された日本のサイバーセキュリティ対策の司令塔となる組織である。
- SG試験では「政府の司令塔」か「現場対応組織(CSIRTやJPCERT/CC)」かを見分ける問題が多い。
直感的な説明
会社でいうと、
- 現場で対応するチーム(CSIRT)
- 外部から支援する専門家(JPCERT/CC)
- 全体方針を決める経営層
がありますよね。
NCOはこの中で、
国レベルの“経営層・司令塔”の役割です。
👉 イメージ
- CSIRT:現場
- JPCERT/CC:外部支援
- NCO:全体を指揮するトップ
定義・仕組み
NCO(国家サイバー統括室)は、
- 内閣官房に設置された組織で
- 日本全体のサイバーセキュリティ対策を統括する
役割を持ちます。
主な役割
- 政府全体のセキュリティ方針の策定
- サイバー攻撃への対応方針の決定
- 関係省庁・機関の連携・調整
- 重要インフラの保護に関する指示
ポイント
- 政府の組織である(内閣官房)
- 現場で対応するのではなく、方針を決める
- 全体の統括・指揮が役割
SG試験では
「司令塔」=NCO
と押さえると判断しやすくなります。
どんな場面で使う?
使う場面(正しい理解)
- 国家レベルのサイバー攻撃対応
- 政府全体のセキュリティ方針の決定
- 重要インフラ防護の指揮
使うと誤解しやすい場面
- ❌ 個別企業のインシデント対応(それはCSIRT)
- ❌ 技術的な支援・助言(それはJPCERT/CC)
よくある誤解・混同
① CSIRTとの違い
- CSIRT:組織内の実務対応
- NCO:全体方針を決める司令塔
👉 「実際に対応するか?」で切る
② JPCERT/CCとの違い
- JPCERT/CC:中立な外部支援機関
- NCO:政府の組織(内閣官房)
👉 「政府かどうか」で判断
③ SG試験のひっかけ
SG試験では次のように混同させてきます:
- 「インシデント対応を行う」→CSIRTやJPCERT/CC
- 「統括・指揮する」→NCO
👉 選択肢では
“対応する”か“指揮する”かに注目
まとめ(試験直前用)
- NCO=政府のサイバーセキュリティ司令塔(内閣官房)
- 現場対応ではなく方針決定・統括が役割
- 選択肢では
- 「インシデント対応を行う」→×
- 「中立組織」→×
- 「政府の司令塔」→○
👉 「政府か?現場か?」で切る
🔗 関連記事
- 関連記事は準備中です。
SG試験 よく出るNG選択肢まとめ【情報セキュリティマネジメント】
- Source: pages\sg\ng-patterns.md
- Permalink: /sg/ng-patterns/
まず結論
- SG試験は「ズレた対策」を選ばせる問題が多い
- 「原因と対策が合っているか」「順番が正しいか」で切る
直感的な説明
SGの問題はこうなっています👇
👉 正しそうな選択肢が並ぶ
👉 でも1つだけ「ズレている」
つまり👇
👉 完璧を選ぶのではなく「ズレ」を見抜く試験
定義・仕組み
NG選択肢の作られ方(超重要)
SG試験のひっかけはパターン化されています👇
パターン①:対策の種類ズレ
例👇
- 人のミス → 技術対策を選ばせる
- ルール問題 → 教育を選ばせる
👉 原因と対策がズレている
パターン②:順番ミス
例👇
- インシデントで原因調査を先にやる
- 復旧を優先する
👉 本来は拡大防止が先
パターン③:やりすぎ(過剰対策)
例👇
- 軽微な違反で重い処分
- 全面禁止など極端な対策
👉 合理性がない
パターン④:丸投げ
例👇
- 委託したので責任なし
- 契約したから管理不要
👉 委託元の責任は残る
パターン⑤:手続き無視
例👇
- 就業規則を勝手に変更
- 意見聴取なし
👉 プロセス違反
どんな場面で使う?
問題の見方テンプレ
① 原因を見る
👉 人・ルール・技術・委託・事故
② 選択肢を見る
👉 合っているか?ズレているか?
③ NGパターンに当てはめる
実戦イメージ
問題👇
「誤送信が多い」
選択肢👇
- A:教育強化
- B:システム変更
👉 正解:A
👉 Bは「ズレ」
よくある誤解・混同
❌ よくある誤解
- 強そうな対策を選ぶ
- 完璧な対策を選ぶ
⭕ 正しい理解
- 原因に合った対策を選ぶ
- ズレているものを消す
SG試験のひっかけ(まとめ)
- 対策の種類ズレ
- 順番ミス
- 過剰対策
- 丸投げ
- 手続き違反
👉 この5つでほぼ全て説明できる
まとめ(試験直前用)
- SGは「ズレ」を見抜く試験
- 原因と対策が一致しているかを見る
- インシデントは順番に注意
- 委託は丸投げNG
- 手続き違反は即NG
🔗 関連記事
- 関連記事は準備中です。
残留リスクとは?対応後にも残るリスクを理解する【情報セキュリティマネジメント】
- Source: pages\sg\residual-risk.md
- Permalink: /sg/residual-risk/
まず結論
- 残留リスクとは「リスク対応を行った後でも残るリスク」
- SG試験では「対応してもゼロにならない」という前提を理解できているかが問われる
直感的な説明
例えば「鍵をかける」対策をしても、泥棒が絶対に入れないわけではありません。
- 鍵をかける → リスクは下がる
- でも「ゼロにはならない」
この「対策してもまだ残っているリスク」が残留リスクです。
👉 対策=リスク消滅ではない、というのがポイント
定義・仕組み
残留リスクは、リスクマネジメントの流れの中で次のように位置づけられます。
- リスクを特定する
- リスクを評価する
- リスク対応(回避・低減・移転・受容)を行う
- それでも残るリスクが「残留リスク」
つまり、
- 対策後の状態で
- 「まだ許容するか?」を判断する対象
になります。
ISMSでも、最終的に「残留リスクを受容できるか」が重要な判断になります。
どんな場面で使う?
よく使う場面
- セキュリティ対策を実施した後の最終判断
- 管理者が「これ以上対策するか?」を決める場面
- コストとリスクのバランスを取る場面
👉 実務では
「コストをかけすぎず、どこまで許容するか」が重要
誤解しやすい場面
- 「対策したから安全」と考える
- 「リスクはゼロにできる」と思う
👉 SG試験ではこの考えは明確に誤り
よくある誤解・混同
❌ よくある誤解
- 残留リスク=対策が不十分な状態
- 残留リスク=対応前のリスク
⭕ 正しい理解
- 残留リスク=対応後でも残るリスク(正常な状態)
混同しやすい用語
- 固有リスク(Inherent Risk)
- 対策前のリスク
- まだ何もしていない状態
- 残留リスク(Residual Risk)
- 対策後のリスク
- それでも残るもの
👉 SG試験では
「対策前か、対策後か」で切り分ける
典型的なひっかけ
- 「対策したらリスクはなくなる」→ ❌
- 「残留リスクはゼロにするべき」→ ❌
- 「残留リスクは受容するか判断する対象」→ ⭕
👉 選択肢では
「残る」「許容」「判断」などのキーワードが出たら正解に近い
まとめ(試験直前用)
- 残留リスク=対策後にも残るリスク
- リスクはゼロにならないのが前提
- 最終的に「受容するか」を判断する対象
- 固有リスク(対策前)との違いが頻出
- SG試験では「ゼロになる」と書いてあれば誤りと判断する
🔗 関連記事
- 関連記事は準備中です。
リスク対応とCIAの関係を整理!試験で迷わない判断フロー【SG試験】
- Source: pages\sg\risk-response-cia.md
- Permalink: /sg/risk-response-cia/
まず結論
リスク対応は「CIAで特定したリスクに対してどう対処するかの意思決定」です。
SG試験では「この状況でどの対応を選ぶべきか」が問われます。
直感的な説明
これまでの流れを1本にするとこうなります👇
- 攻撃を受ける
- 何が壊れるか(CIA)を判断
- 対策を考える
- 最後に「どう対応するか」を決める
👉 リスク対応=最終判断
定義・仕組み
リスク対応は4つに分類されます。
① 回避(Risk Avoidance)
- 危険なことをやらない
例:
- 危険なサービスを停止する
👉 リスクをゼロにするが、機能も失う
② 低減(Risk Mitigation)
- リスクを減らす
例:
- DDoS対策導入
- アクセス制御強化
👉 最も一般的な対応
③ 移転(Risk Transfer)
- リスクを他者に移す
例:
- 保険加入
- クラウド利用
👉 自社で抱えない
④ 受容(Risk Acceptance)
- リスクを受け入れる
例:
- 影響が小さいので対策しない
👉 コストとのバランスで判断
どんな場面で使う?
SG試験での典型パターン
問題はこう聞いてきます👇
- 「最も適切な対応はどれか?」
- 「現実的な対応はどれか?」
👉 完璧ではなく“現実的な判断”を選ぶ
判断の流れ(超重要)
- どのCIAが影響を受けるか
- 適切な対策は何か
- その対策を実施するか判断
👉 最後がリスク対応
よくある誤解・混同
❌ とにかく対策すればよい
→ ⭕ コストと効果で判断する
❌ すべて回避が正しい
→ ⭕ 現実的ではない(業務が止まる)
❌ 受容は何もしない=悪い
→ ⭕ 合理的な判断の一つ
SG試験のひっかけ
- 「サービス停止」 → 回避
- 「対策導入」 → 低減
- 「保険・外部委託」 → 移転
- 「影響軽微」 → 受容
👉 キーワードで判断
まとめ(試験直前用)
- リスク対応=最終意思決定
- 回避=やめる
- 低減=減らす
- 移転=任せる
- 受容=そのまま
- SG試験では「現実的か」で切る
🔗 関連記事
- 関連記事は準備中です。
リスク対応とは?4つの対処方法を整理【情報セキュリティマネジメント】
- Source: pages\sg\risk-treatment.md
- Permalink: /sg/risk-treatment/
まず結論
リスク対応とは、リスク評価の結果をもとに「そのリスクをどう扱うか(減らす・避ける・共有する・受け入れる)」を決めて実行することです。
SG試験では「その対策がどの種類のリスク対応か」を判断させる問題がよく出ます。
直感的な説明
リスク対応は「事故にどう備えるかの選択」です。
たとえば地震リスクなら:
- 家を建てない → 回避
- 耐震補強する → 低減
- 保険に入る → 共有
- 何もしない → 受容
同じリスクでも「どう向き合うか」は複数の選択肢があります。
SG試験は、この選択の違いを見抜けるかがポイントです。
定義・仕組み
■ リスク対応とは
JIS Q 31000:2010(リスクマネジメントの指針)では、
リスク対応は「リスクを修正するためのプロセス」と定義されています。
■ 主な4つの対応方法(試験重要)
実務・試験では次の4つで整理すると理解しやすいです。
-
リスク回避
→ リスクを生む活動をやめる(例:危険なシステムを使わない) -
リスク低減(軽減)
→ 発生確率や影響を下げる(例:ウイルス対策ソフト導入) -
リスク共有(移転)
→ 他者と分担する(例:保険加入、外部委託)
※金銭的リスクを移すものは「リスクファイナンシング」 -
リスク受容(保有)
→ あえて対策せず受け入れる(例:軽微なリスクは放置)
どんな場面で使う?
■ よくある業務判断
- システム障害リスク → 冗長化(低減)
- 情報漏えいリスク → 委託契約で責任分担(共有)
- 高コストすぎる対策 → 受容
■ SG試験での出題パターン
- 「この対策はどのリスク対応か?」
- 「適切なリスク対応を選べ」
選択肢では「行動内容」から分類させる問題が多いです。
よくある誤解・混同
❌ 保険はリスクをなくす → 間違い
→ ⭕ 保険は「リスク共有(移転)」
(損失の負担を他者に移すだけ)
❌ セキュリティ対策=すべて低減
→ ⭕ 対策の種類で変わる
- 利用停止 → 回避
- 保険 → 共有
- 何もしない → 受容
❌ リスク対応は1つだけ選ぶ
→ ⭕ 複数を組み合わせることもある
■ SG試験のひっかけポイント
- 「保険」「契約」→ 共有
- 「やめる」「中止」→ 回避
- 「対策導入」→ 低減
この対応関係を覚えておくと、選択肢をかなり切れます。
まとめ(試験直前用)
- リスク対応=「どう扱うか」の意思決定
- 4分類:回避・低減・共有・受容
- 保険・委託 → 共有(超頻出)
- SG試験は「行動から分類」を問う問題が多い
- キーワードで即判定できるようにするのがコツ
🔗 関連記事
- 関連記事は準備中です。
情報セキュリティ基本方針とは?経営者の宣言を理解する【情報セキュリティマネジメント】
- Source: pages\sg\security-policy-basic.md
- Permalink: /sg/security-policy-basic/
まず結論
- 情報セキュリティ基本方針とは、経営者が示す「情報をどう守るか」という方向性と意思を表した文書
- SG試験では「具体的な対策ではなく、方針レベルかどうか」を判断させる問題が多い
直感的な説明
会社のトップが
「うちは情報セキュリティをこういう考えで守ります」と宣言するのが基本方針です。
たとえば:
- 情報を守ることを重要視する
- 法令を守る
- 継続的に改善する
👉 現場の細かいルールではなく
“会社としての考え方”を示すものです
定義・仕組み
情報セキュリティ基本方針は、情報セキュリティポリシーの最上位に位置します。
主な内容は以下のようなものです:
- 情報セキュリティの目的(なぜ守るのか)
- 適用範囲(どこまで守るのか)
- 経営者の責任と関与
- 法令・規格の遵守
- 継続的改善の方針
👉 ポイントは
「具体的な対策は書かない」こと
また、基本方針は
- 社内に周知される
- 必要に応じて社外にも公開される
という特徴があります
どんな場面で使う?
使う場面
- ISMSの構築・運用
- 社内のセキュリティ教育
- 外部への信頼性アピール(Web公開など)
👉 「この会社はちゃんとセキュリティを考えているか」を示す土台になります
注意が必要な場面
- 手順書のような細かい内容を書く
- システム単位の対策を書く
👉 それは
対策基準や実施手順の役割です
よくある誤解・混同
❌ 誤解1
- 基本方針は機密文書なので外部に出さない
👉 ⭕ 正しくは
外部公開されることもある(信頼性の証明)
❌ 誤解2
- 一度決めたら変更しない
👉 ⭕ 正しくは
環境変化(法改正・技術)に応じて見直す
❌ 誤解3
- 具体的な対策を書く文書
👉 ⭕ 正しくは
方向性だけを書く(具体策は下位文書)
SG試験では
👉「それは方針レベルか?具体策か?」
と問われることが多いです
まとめ(試験直前用)
- 基本方針=経営者の宣言(方向性)
- 具体的対策は書かない(→対策基準・手順)
- 社外公開されることがある
- 環境に応じて見直す
- 「具体的すぎる内容」は誤りと判断
🔗 関連記事
- 関連記事は準備中です。
情報セキュリティ実施手順とは?現場でのやり方を理解する【情報セキュリティマネジメント】
- Source: pages\sg\security-policy-procedures.md
- Permalink: /sg/security-policy-procedures/
まず結論
- 情報セキュリティ実施手順とは、対策基準で決めたルールを「どうやって実行するか」を具体的な手順として示した文書
- SG試験では「ルールではなく作業レベルかどうか」を見極める問題がよく出る
直感的な説明
対策基準が「何を守るか(ルール)」なら、
実施手順は
👉「どうやってやるの?」をまとめたものです
たとえば:
- バックアップの取り方(どの時間に・どの手順で)
- ログの確認方法(どこを見るか・どの順番で)
- インシデント発生時の対応手順
👉 現場で使うマニュアル・作業手順書のイメージです
定義・仕組み
情報セキュリティ実施手順は、ポリシーの最下位レイヤーです。
役割:
- 対策基準を現場で実行できる形にする
- 作業のばらつきを防ぐ
- 誰でも同じ対応ができるようにする
主な内容:
- 作業手順(ステップごとの操作)
- 使用ツール・操作方法
- 異常時の対応フロー
- 記録・報告方法
👉 ポイント
「具体的な操作レベルまで書く」こと
どんな場面で使う?
使う場面
- 日常運用(バックアップ、ログ確認など)
- インシデント対応
- 新人教育・引き継ぎ
👉 現場では
「人によってやり方が違う」問題を防ぐために重要です
注意が必要な場面
- ルールだけを書いて具体性がない
- 経営方針のような抽象的な内容を書く
👉 それは
- ルール → 対策基準
- 抽象 → 基本方針
の役割です
よくある誤解・混同
❌ 誤解1
- 実施手順=ルール
👉 ⭕ 正しくは
ルールを実行するためのやり方
❌ 誤解2
- 抽象的な内容でもOK
👉 ⭕ 正しくは
誰でも同じように実行できる具体性が必要
❌ 誤解3
- 組織全体の方針を書く
👉 ⭕ 正しくは
現場の作業内容を書く
SG試験では
👉「これは作業レベルか?」
👉「具体的すぎる=手順」
と判断できるかが重要です
まとめ(試験直前用)
- 実施手順=どうやるか(作業レベル)
- 対策基準を実行するための具体手順
- 最も具体的な文書
- マニュアル・手順書に相当
- 「抽象的な内容」→手順ではないので誤り
🔗 関連記事
- 関連記事は準備中です。
情報セキュリティ対策基準とは?ルールレベルの考え方【情報セキュリティマネジメント】
- Source: pages\sg\security-policy-standards.md
- Permalink: /sg/security-policy-standards/
まず結論
- 情報セキュリティ対策基準とは、基本方針を実現するために「何を守るか」を具体的なルールとして定めた文書
- SG試験では「方針ではなくルールレベルかどうか」を見極める問題がよく出る
直感的な説明
基本方針が「こういう考えで守る!」という宣言だとすると、
対策基準は
👉「じゃあ何を守るの?」を決めるルールです
たとえば:
- パスワードは〇文字以上にする
- USBは許可されたものだけ使う
- アクセス権は必要最小限にする
👉 現場で守るべき“約束ごと”のイメージです
定義・仕組み
情報セキュリティ対策基準は、ポリシーの中間レイヤーです。
役割は以下の通り:
- 基本方針を具体化する
- 組織全体で守るルールを統一する
- セキュリティ対策の基準を示す
主な内容:
- アクセス制御のルール
- パスワード管理の基準
- ログ管理・監視のルール
- 端末・ネットワーク利用ルール
👉 ポイント
「何を守るか」まで書くが、「どうやるか」は書かない
どんな場面で使う?
使う場面
- 社内ルールの整備
- セキュリティ監査の基準
- 委託先への要求事項の提示
👉 現場では
「人によってやり方が違う」状態を防ぐために使います
注意が必要な場面
- 手順レベルまで細かく書く
- 経営方針のような抽象的な内容を書く
👉 それは
- 手順 → 実施手順
- 抽象 → 基本方針
の役割です
よくある誤解・混同
❌ 誤解1
- 対策基準=作業手順
👉 ⭕ 正しくは
ルールであり、手順ではない
❌ 誤解2
- 対策基準=経営方針
👉 ⭕ 正しくは
基本方針を具体化したもの
❌ 誤解3
- システムごとの詳細設定を書く
👉 ⭕ 正しくは
組織全体のルールを書く
SG試験では
👉「これはルールか?手順か?」
👉「これは方針か?基準か?」
の切り分けが重要です
まとめ(試験直前用)
- 対策基準=何を守るか(ルール)
- 基本方針より具体的、手順より抽象的
- 手順までは書かない
- 組織全体の共通ルール
- 「やり方が書いてある」→手順なので誤り
🔗 関連記事
- 関連記事は準備中です。
情報セキュリティポリシーとは?3階層で理解する基本ルール【情報セキュリティマネジメント】
- Source: pages\sg\security-policy.md
- Permalink: /sg/security-policy/
まず結論
- 情報セキュリティポリシーとは、組織が情報を守るためのルールを3階層(基本方針・対策基準・実施手順)で整理したもの
- SG試験では「どのレベルの文書か」を判断させる問題がよく出る
直感的な説明
会社で「セキュリティちゃんとやろう!」と言っても、それだけでは何も動きません。
そこで次のように分けて考えます:
- 方針(どういう考えで守るか)
- ルール(何を守るか)
- 手順(どうやってやるか)
👉 この3つをまとめたものが「情報セキュリティポリシー」です
現場でいうと
「社長の宣言 → 社内ルール → 作業マニュアル」のイメージです
定義・仕組み
情報セキュリティポリシーは、通常3階層で構成されます。
① 情報セキュリティ基本方針
- 経営者が示す「セキュリティの考え方」
- 例:情報を守る目的、取り組む姿勢
- 社外公開されることも多い
👉 ポイント:方向性・宣言レベル
② 情報セキュリティ対策基準
- 方針を実現するためのルール
- 例:パスワードの長さ、アクセス制御のルール
👉 ポイント:守るべきルール
③ 情報セキュリティ実施手順
- 実際の作業手順
- 例:バックアップの手順、ログ確認方法
👉 ポイント:現場のやり方
SG試験ではこの3つをまとめて
「情報セキュリティポリシー」と呼びます
どんな場面で使う?
使う場面
- ISMS(情報セキュリティマネジメントシステム)の構築
- 社内ルール整備
- 委託先管理や監査対応
👉 現場では
「ルールが曖昧で属人化している」状態を防ぐために使います
注意が必要な場面
- 「基本方針に具体的な手順を書く」
- 「手順書に経営方針を書く」
👉 レベルが混ざるとNG(試験でもよく出る)
よくある誤解・混同
❌ よくある誤解1
- 基本方針は機密文書で外部に出さない
👉 ⭕ 正しくは
基本方針は社外にも公開されることがある
❌ よくある誤解2
- 基本方針は一度決めたら変えない
👉 ⭕ 正しくは
環境変化(法改正・技術)に応じて見直す
❌ よくある誤解3
- 基本方針に具体的な対策を書く
👉 ⭕ 正しくは
具体策は対策基準・手順に書く
SG試験では
👉「それはどの階層の話?」
と切り分けるのが最重要ポイントです
まとめ(試験直前用)
- 情報セキュリティポリシー=基本方針+対策基準+実施手順
- 基本方針=方向性(経営者の宣言)
- 対策基準=ルール、実施手順=やり方
- 「具体的すぎる」→基本方針ではない
- 「変更しない」→誤り(環境に応じて見直す)
🔗 関連記事
- 関連記事は準備中です。
情報セキュリティ教育・訓練とは?人的対策の基本を整理【情報セキュリティマネジメント】
- Source: pages\sg\security-training.md
- Permalink: /sg/security-training/
まず結論
- 情報セキュリティ教育・訓練とは「人によるミスや不正を防ぐための対策」
- SG試験では「教育で対応すべきか」「技術対策と混同しないか」を判断させる問題がよく出る
直感的な説明
セキュリティ事故の多くは👇
- メールの誤送信
- パスワードの使い回し
- 不審メールを開く
👉 つまり「人のミス」
だから👇
👉 人を変える対策が必要
それが教育・訓練です
定義・仕組み
教育・訓練とは
- 従業員のセキュリティ意識・行動を改善する取り組み
主な内容
教育(知識)
- ルールの理解
- 脅威の理解
訓練(実践)
- 標的型メール訓練
- インシデント対応訓練
👉 「知る」+「できる」がセット
なぜ重要か
👉 技術対策だけでは防げない
例👇
- 強いシステムでも
→ パスワードを教えたら終わり
どんな場面で使う?
科目Bの典型パターン
- 誤送信が多発
- フィッシング被害
- 内部不正
正しい判断例
問題でこう聞かれます👇
-
「不審メールを開いてしまう」
→ 教育・訓練 -
「ルールが守られていない」
→ 教育 -
「操作ミスが多い」
→ 訓練
よくある誤解・混同
❌ よくある誤解
- システムを強化すれば解決
- マニュアル配布で十分
⭕ 正しい理解
- 人的対策は必須
- 教育+訓練の両方が必要
SG試験のひっかけ
典型パターン👇
- 「教育すべき場面で技術対策を選ばせる」
- 「ルール違反なのにシステム対応を選ばせる」
👉 問題の原因を見ることが重要
まとめ(試験直前用)
- 教育・訓練=人的リスク対策
- 教育(知識)+訓練(実践)がセット
- 人のミスは技術だけでは防げない
- 問題は「原因が人か」で判断
- 「対策の種類ズレ」に注意
🔗 関連記事
- 関連記事は準備中です。
委託先管理とは?外部委託のリスク対策を整理【情報セキュリティマネジメント】
- Source: pages\sg\vendor-management.md
- Permalink: /sg/vendor-management/
まず結論
- 委託先管理とは「外部委託による情報漏えいリスクを管理すること」
- SG試験では「委託前・委託中・委託後のどの対策か」を判断させる問題がよく出る
直感的な説明
会社が仕事を外部に任せるとき👇
👉 「自分の会社の情報」を外に出すことになる
つまり👇
👉 委託先が事故を起こしたら、自社の責任になる
だから👇
👉 「任せる前・任せている間・終わった後」すべて管理が必要
定義・仕組み
委託先管理は3段階で考えると理解しやすい👇
① 委託前(選定・契約)
- 信頼できる会社か確認
例👇
- セキュリティ体制の確認
- 実績の確認
- 契約で義務を明確化
👉 ここでミスると全部アウト
② 委託中(監督・管理)
- 任せっぱなしにしない
例👇
- 定期的な監査
- 作業状況の確認
- アクセス権の制御
👉 「丸投げ」が一番危険
③ 委託後(終了時)
- 情報を残させない
例👇
- データの返却・削除
- アカウントの停止
👉 ここ忘れる問題よく出る
どんな場面で使う?
科目Bの典型パターン
- システム開発の外注
- データ処理の委託
- クラウドサービス利用
正しい判断の流れ
問題ではこう見ます👇
- 委託前の話?
- 委託中の話?
- 委託後の話?
👉 フェーズで切る
よくある誤解・混同
❌ よくある誤解
- 委託したら責任も移る
- 契約書があればOK
⭕ 正しい理解
- 責任は委託元に残る
- 契約+監督が必要
SG試験のひっかけ
典型パターン👇
- 「委託したので責任なし」→ ❌
- 「契約しただけで監督なし」→ ❌
- 「終了時のデータ削除なし」→ ❌
👉 丸投げは全部NG
まとめ(試験直前用)
- 委託先管理=外部委託のリスク管理
- 3段階(委託前・中・後)で考える
- 責任は委託元に残る
- 契約だけでなく監督が必要
- 「丸投げしていないか」で判断する
🔗 関連記事
- 関連記事は準備中です。