情報セキュリティリスクマネジメントについて（２）

ー２．状況の設定ー

はじめに

　情報セキュリティリスクマネジメントの状況の設定プロセス（図中の赤枠部分）について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

図１　リスクマネジメントプロセス上の ”状況の設定” の位置づけ

　注）なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

１）状況の設定とは

　リスクアセスメント及びリスク対応において下した判断には、高い一貫性と再現性が求められます。例えば、同じ状況下で実施したにもかかわらず、実施者や対象部門、あるいは実施時期により異なる結果や対応が採られることは避けなければなりません。
　そのためには、リスクアセスメントを実施する前に、組織内外の状況と課題を理解し、実施手順やリスクの重大性を判断するための基準など（本稿では、それらを全てまとめて「情報セキュリティリスクマネジメント方針」と呼びます）を定め、組織内で標準化する必要があります。ISO/IEC DIS 27005:2021では、その作業を ”Context establishment" と呼ばれるプロセスで実施します。本稿でもそのプロセス名を和訳した状況の設定と呼ぶこととします。

　上記について、JIS Q 27001:2014（ISO/IEC 27001:2013）では、次のように表現されています。

JIS Q 27001:2014 6.1.2 より

組織は、次の事項を行う情報セキュリティリスクアセスメントのプロセスを定め、適用しなければならない。
a) 次を含む情報セキュリティのリスク基準を確立し、維持する。
　 1) リスク受容基準
　 2) 情報セキュリティリスクアセスメントを実施するための基準
b)繰り返し実施した情報セキュリティリスクアセスメントが、一貫性及び妥当性があり、かつ、比較可能な結果を生み出すことを確実にする

　本稿では、情報セキュリティリスクマネジメントを情報セキュリティマネジメントシステム上のプロセスの一部として進めると定義し、情報セキュリティリスクマネジメント方針をその個別方針として位置付けます *1 。

　次項以降で、情報セキュリティリスクマネジメント方針を策定する際に、考慮すべき点と明らかにすべき点についてそれぞれを具体的に考えてみたいと思います。

２）方針策定時に考慮すべき点

　情報セキュリティリスクマネジメント方針を策定する際には、次のような情報セキュリティ目的に影響する点を考慮します。

• 組織及びその内外の状況
• 情報セキュリティ方針（その他、組織で定めた上位方針）

２－１）組織及びその内外の状況

　リスクに係る様々な判断に影響を及ぼす組織内外の価値観（例えば、プライバシー保護に関する世論、デューケア事案に対する法律上の判断や判例、外部利害関係者との契約内容、期待など）は時間とともに変化する可能性があるため、その変化に応じたリスクを特定するためには、常に内外、特に外部状況の変化を捉え、その内容をリスクの判断基準となる情報セキュリティリスクマネジメント方針に反映させることが求められます。

　考慮すべき内外の状況とその優先度について考えてみます。いかなる組織であっても、法規や社会的要求のようなコンプライス要件は、経済的な判断のような組織の目的に関連する要件よりも優先されるべき課題のはずです *2 。したがって、特に外部からのコンプライアンス要件を優先し、さらに、影響が及ぶ範囲という観点で考えると下図のような優先順位の付け方が妥当と思われます。

図２　各コンプライアンス要件の優先度のイメージ

　なお、上図には含まれていませんがリスクマネジメントの方向性については組織内の様々な立場により見解が異なる可能性が十分考えられますので、組織内の利害関係者の意見集約や調整が必要になることもあります（リスクコミュニケーション）。
　また、アカウンタビリティやデューディリジェンスの観点から、リスクに対する意思決定の根拠を求められる可能性があるため、リスクの判断基準を決めた際に根拠とした情報との関連性を明らかにしておくことも検討が必要です（記録及び報告）。

２－２）情報セキュリティ方針（その他、組織内の上位方針）

　リスクマネジメントを実施する目的は、リスクが組織の目的達成に与える影響を明らかにしそれを最適化することです。裏を返せば、効果的なリスクマネジメントのためには、その活動によりコントロールしようとしている組織の目的を十分理解する必要があります。
　本稿では、情報セキュリティリスクマネジメントをテーマとしていますので、情報セキュリティ方針と目的、及びその考え方に影響を及ぼす可能性のある上位方針（例えば、事業目的や経営方針など）や組織が参照している外部のガイドラインの変化も併せて理解し、情報セキュリティリスクマネジメント方針に反映させることとします。

３）方針で明らかにすべき点

　前述のとおり、組織内のリスクアセスメント及びリスク対応の判断結果には、一貫性、再現性が求められるため、情報セキュリティリスクマネジメント方針により次の項目を明らかにし、手法と基準を標準化します。

• 役割と責任（特にリスク受容やリスク対応方法の承認者）
• 実施のタイミング
• 実施手法
• リスクの重大性を決定するための基準
• リスクが受容可能かどうかを決定するための基準
• リスク対応の選択肢

３－１）役割と責任

　情報セキュリティリスクマネジメント方針において、例えば、リスク受容やリスク対応方法の承認者のようなセキュリティリスクに係る役割と責任を決定する、若しくは決定するための基準を明らかにします。この決定は「組織構造の定義・導入と役割・責任の確立」の一部にあたり、マネジメントに実施責任があります。
　過去のブログ 「マネジメントの責任」について が参考になります。

blg8.hatenablog.com

　ここでは、リスクマネジメントに関わる役割の中でも特に重要な位置付けであるリスク所有者について考えてみます。ISMSに関連する用語を定義しているJIS Q 27000：2019には、リスク所有者に関する次の記載があります。

JIS Q 27000：2019　から引用

3.71 リスク所有者（risk owner）
　リスクを運用管理することについて、アカウンタビリティ及び権限をもつ人又は主体。

　以上のことから、リスク所有者を決める際には、次の事項を考慮すべきと考えます。

• リスクを管理するためのアカウンタビリティと権限を、組織内で行使できる地位を有しているか？
• リスクアセスメントの結果を理解し、適切な対応を決定できる立場にあるか？

　適切な対応を決定するためには、そのリスクが情報セキュリティ目的に及ぼす影響を理解しなければなりませんが、リスク所有者が自らリスクアセスメントを実施する必要はなく、通常は相応しい力量を有した担当に実施を委ね、報告された実施結果から最終的な判断（承認）を行います。

　より正確なリスクアセスメントの結果を得るためには、各リスクに応じ個別にリスク所有者を置くことが理想ですが、実際には管理が煩雑になる可能性が高いため、各リスクをグルーピング*3することにより管理を効率化することが多いと思われます。
　誰がリスク所有者に相応しいかは、そのリスクをグルーピングする際のレベルや範囲によって異なります。リスクアセスメントで用いられることの多い２つのアプローチ手法を例にすると、イベントベースアプローチの場合、リスクが顕在化した場合に組織全体に影響が及ぶことが多いと思われるため、CISOやセキュリティ統括部門の長、委員会組織などの組織のセキュリティを統括する立場に在る方、一方、アセットベースアプローチであれば、対象資産を使用している業務に直接影響が及ぶことが多いと思われるため、業務プロセス所有者や資産管理者、対象システムの管理責任者などその資産を管理すべきオーナー的な立場に在る方が適していると思われます。
　なお、アセットベースを考える上で、データレイクのようなデータオーナーを明らかにすることが難しいケースもあるため、想定の下に指針を明らかにしておくことも必要かもしれません。

　イベントベースアプローチとアセットベースアプローチについては、後日、情報セキュリティリスクマネジメントについて（３） で紹介する予定です。

blg8.hatenablog.com

３－２）実施のタイミング

　リスクアセスメントは、定期的（主に戦略サイクル）、及び変化を検知したタイミング（主に運用サイクル）で実施します。
　詳しくは、別途、情報セキュリティリスクマネジメントについて（３） で触れたいと思います。

blg8.hatenablog.com

３－３）実施手法

　情報セキュリティリスクマネジメント、特にその中でもリスクアセスメントを実施するための手法を定めます。その手法は、以下を含め、様々なガイドラインにより複数紹介されていますので、その中から組織に合ったものを選択することも組織独自の手法を考えることも可能です。

• JIS Q 31010：2022（ISO/IEC 31010：2019）附属書A
  　情報セキュリティに限らず一般的なリスクアセスメントの各プロセスに適用可能な手法が多種紹介されています。
  

• ISMSユーザーズガイド　ーリスクマネジメント編－（JIPDEC）
  　情報セキュリティリスクアセスメントを実施するための基準として、４種類のアプローチ手法*4が紹介されています。
  

　他にも次のような手法が参考になります。

• NIST SP800-30 Guide for Conducting Risk Assessments
• NIST SP800-39 Managing Information Security Risk: Organization, Mission, and Information System View
• CCTA Risk Analysis Management Methodology (CRAMM)
• Failure Mode and Effect Analysis (FMEA)
• Fault Tree Analysis (FTA)

　例えば、製造業を例にとると、日頃から製品設計時にFMEA、不良や故障の解析時にFTAなどの手法を用い品質管理を行っている場合、それらの手法をリスクマネジメントに応用することでスムーズに導入できる可能性があります。

３－４）リスクの重大性を決定するための基準

　情報セキュリティリスクアセスメント、特にリスクを分析、評価する際に一貫性と再現性が得られるように、リスクの重大性を評価するための手法と基準を予め定めます。その基準は組織の状況に応じ定めることになりますが、組織外部に対するアカウンタビリティが求められる場合、一般的に見て妥当であり、合理的な内容とする必要があります。
　ここでは、リスクの重大性を決定するための基準を定める上で、理解しておくべき次の３点について考えてみます。

• リスクの構造
• リスクの重大性を評価する指標（定性的、定量的、半定量的）
• リスク因子の関係

① リスクの構造

　リスクの重大性を評価するためにはリスクの構造を理解する必要があります。一般的に、リスクの重大性は、事象の「起こりやすさ」とその「結果」により表されます。JIS Q 31000：2019では、次のように表現されています。

JIS Q 31000：2019（ISO 31000：2018）　6.4.3 リスク分析　より抜粋

リスク分析の意義は、必要に応じてリスクのレベルを含め、リスクの性質及び特徴を理解することである。
（中略）
リスク分析では、例えば、次の要素を検討することが望ましい。
− 事象の起こりやすさ及び結果
− 結果の性質及び大きさ

　また、「資産の価値」、「脅威」、「脆弱性」と表現されていることも多く、例えば、ISMSユーザーズガイド －リスクマネジメント編ー には、次のように記載されています。

JIP-ISMS113-3.0　（３）リスクレベルの決定　より抜粋

リスクレベルは、前の作業で明確になった「資産の価値」、「脅威の大きさ」、「ぜい弱性の度合い」を用いて、例えば、簡易的に次の様な式で算定します。
リスクレベル＝「資産の価値」×「脅威」×「ぜい弱性」

　次のように解釈することで、上記はどちらもリスクを構成する要素として同じものを想定していると考えることができます。

• 「事象の起こりやすさ」の構成要素には、「脅威」と「ぜい弱性」が含まれる
• 「結果の性質及び大きさ」の構成要素には、「資産の価値」が含まれる

　本稿では、最終的なリスクの重大性は事象の「起こりやすさ」と「結果」により評価しますが、情報リスクの要因分析を行うためのフレームワークを提供しているFAIR（Factor Analysis of Information Risk）が提唱しているリスク構造に基づき、「脅威」や「ぜい弱性」の要素も含めさらに深く理解したいと思います。
　FAIRのリスク構造モデルについては、後日、 情報セキュリティリスクマネジメントについて（５） で具体的に考える予定です。

blg8.hatenablog.com

② リスクの重大性を評価する指標

　リスクの重大性を評価する指標とは、対象リスクに対する様々な判断（例えば、当該リスクの受容可否、他のリスクとの対応優先度の比較など）の基準となるものです。
　リスクの重大性は、下表のように定量的、定性的、半定量的に表されることが一般的です。ここでは、各手法の特徴を考えます。

表１　定量的、定性的、半定量的の比較

　 　JIS Q 31000：2019では、次のように定義されており、組織の状況に応じ選択するものと解釈できます。

JIS Q 31000：2019 (ISO 31000：2018)　より抜粋

3.6 結果（consequence）
（中略） 　注記2 結果は、定性的にも定量的にも表現されることがある。

3.7 起こりやすさ（likelihood）
　注記1 （中略）“起こりやすさ”の定義、測定又は判断は、主観的か若しくは客観的か、又は定性的か若しくは定量的かを問わない。

◆ 定量的な表現
　リスクを評価する場合、リスクの重大性やリスク対応の効果はそれぞれ次のように、より具体的、定量的（金額ベース）に表すことで、その対応を判断しやすく、根拠を問われた場合にも効果的な説明が可能になります。

　リスクの重大性を金額で表す例）
　年間予想損失額（ALE）＝　個別損失予測額　×　年間発生率

　リスクを低減するために実施する管理策の費用対効果を金額で表す例）
　管理策の費用対効果（ROI）＝　（管理策を実施しない場合の年間予想損失額　－　管理策を実施した場合の年間予想損失額）／　管理策実施のための年間費用

◆ 定性的・半定量的な表現
　前述のとおり、リスクの重大性を評価する指標とは、対象リスクに対する様々な判断の基準となるものであり、その判断には「他のリスクとの対応優先度の比較」など、相対的な評価でも十分機能するものも多くあります。そのような場合には、定性的、あるいは順位付けが必要な場面では半定量的に評価することにより効率的な実施が可能になります。
　下表では、定性的な評価と、その各結果に対しスコアリングした半定量的な評価の例を表しています。

表２　定性的（半定量的）な評価指標例（3段階と5段階）

　前述のとおり、リスクを評価する場合、リスクの重大性は定量的に表すことで、その対応を判断しやすく根拠として示す際にも効果的です。
　ただし、上記はその根拠が信頼のおける数値に基づいていることが前提であり、例えば、発生確率や発生頻度のような「起こりやすさ」や、損失額のような「結果」は、それ自体が「不確かさ」の性質を有しており、高い精度で推定するためには信頼できる統計結果を得られるだけの十分なデータ量、分析のための専門的な知識などを要することが多く、一組織がその条件を揃えることは容易ではありません。
　例えば、外部の利害関係者からの要求やサイバー保険の料率の根拠など、組織の事情により定量的な分析が求められている場合は、可能な限り精度の高い結果が得られるよう努力が必要ですが、分析手法に制約が無い場合は、定量的、定性的、半定量的の中から組織の状況に応じ、リスクを適切に表現するために妥当と思われる分析手法を選ぶ（又は組み合わせる*5 ）ことが合理的だと思います。
　また、どの手法を用いても算定した値は推定値であるため、算定した条件と結果の不確かさの度合いが対象リスクに対する様々な判断をする際に確認可能になっていることも重要です。

③ リスク因子の関係

　”① リスクの構造” で述べた通り、FAIRのリスク構造モデルでは最終的なリスクの大きさは、個々のリスク因子の組み合わせにより評価されます。例えば、”脅威事象の発生頻度”は、”接触頻度”と”実行の発生確率”の組み合わせにより求められます。
　個々のリスク因子の組み合わせとその結果の関係については、各組織により定めます。多くのガイドラインでは、掛け算による算定方法が例示されており、上記の組み合わせを例にすると次のように表されます。

　脅威事象の発生頻度　＝　接触頻度　×　実行の発生確率

　上記は、起こりやすさで表される２つのリスク因子の組み合わせにより、起こりやすさを示す例ですが、他にも以下のような組み合わせが考えられます。

　結果（損失の大きさ）＝　結果　＋　結果
　結果（リスクの重大性）＝　結果　×　起こりやすさ

　上記のように単純な数式を用いた算定により効率的な作業が可能になりますが、その反面、例えば以下のような起こりやすさと結果を半定量的（低＝１、中＝２、高＝３）にスコアリングし、その掛け算によりリスクの重大性を求める二つのケースで、リスクの重大性が意図せず同じ値になってしまい、各リスクの相対的な比較を目的とする場合、相応しくない結果となる恐れがあります 。

　ケース１）　数十年に一度の確率で起こる重大なインシデント
　（起こりやすさ）１　×（結果）３　＝（リスクの重大性）３

　ケース２）　月に数十回の頻度で起こる軽微な事象
　（起こりやすさ）３　×（結果）１　＝（リスクの重大性）３

　リスク因子の関係を計算式により求める場合は、各リスク因子に重要度に応じた重み付けを行うなど組織の方針を定める必要があります。
　また、各リスク因子が半定量的に求められているような場合は、計算ではなくリスクマップ上でリスク因子同士の組み合わせ結果を推測し、新たに半定量で評価することも可能です。その場合でもリスク因子同士の関係は等価とするのか重み付けを行うのか事前に方針として定めておくことにより混乱なく実施することができます。

図３　リスク因子の重み付けによる差

④ ベースライン管理策

　組織において実施すると決めたセキュリティ管理策をリスト化します。このリストは、特にベースラインアプローチによるリスクアセスメントを実施する際に重要な意味を持ちます。
　具体的には、汎用ベースラインカタログを参考にし、組織における実施内容（適用範囲の調整*6 、テーラリング*7 、追加管理策と拡張管理策による補完*8の観点により判断します) をリストにより明らかにします。各管理策は、実施要否だけではなく要求の度合によるランク分け（例えば、高位、中位、低位など）を行うこともあります。
　詳細については、過去ブログで紹介しています。 　blg8.hatenablog.com

　次のような情報の形態などの支援資産の属性情報とベースライン上の個々の管理策の関連性を明らかにしておくことで、アセットベースのベースラインアプローチによるリスクアセスメント時に関連管理策の抽出を自動的に実施することが可能になります。

• 情報の形態
  データ、紙、物品、開発物、製品（商品）
• 保管形態
  PC、サーバー（オンプレ）、クラウド、キャビネット、部屋（区画）
• 利用形態
  ファイル保管・共有、内製システム、既成システム、サービス
• 利用範囲
  社員、契約社員、派遣社員、業務委託先、顧客（取引先）

　ベースライン管理策を明確にし、組織全体に展開することにより、初期のリスクアセスメントを効率よく実施することが可能になります。

３－５）リスクが受容可能かどうかを決定するための基準

　”３－４）リスクの重大性を評価するための基準” により得られた結果に対し、そのリスクに対し何らかのリスク対応が必要なのか、受容可能なのかを判断するための基準（以下、「リスク受容基準」と呼びます）を定めます。
　リスク受容基準も、組織で定めた情報セキュリティリスクマネジメント方針の一部として、組織及びその内外の状況と上位方針が考慮された内容となります。

３－６）リスク対応の選択肢

　”３－４）リスクの重大性を評価するための基準” と”３－５）リスクが受容可能かどうかを決定するための基準”の結果に基づきリスク対応を判断する際の選択肢を予め定めておきます。
　リスク対応の選択肢として、一般的には「リスク回避」「リスク低減」「リスク移転」「リスク保有」の4分類が使用されていますが、JIS Q 31000：2019 (ISO 31000：2018) では若干細分化され、リスクを取る（リスクテイク）との考え方が追加されています。いずれの組織でも下表のような分類になると思われます。

表３　リスク対応の分類例

３－７）その他の考慮すべき事項

　次の２点についても情報セキュリティリスクマネジメント方針で明らかにしておくことで、マネジメントプロセス全体の維持・改善に効果をもたらします。

• モニタリング及びレビュー
  　モニタリング及びレビューに関する具体的な実施内容、実施時期を示すそれぞれの計画を作成します。
  　詳しい内容については、別途、紹介したいと思います。

blg8.hatenablog.com

• リスクコミュニケーション
  　リスクコミュニケーションに関する具体的な実施内容、実施時期を示すそれぞれの計画を作成します。
  　詳しい内容については、別途、紹介したいと思います。

blg8.hatenablog.com

まとめ

　今回は情報セキュリティリスクマネジメントにおける状況の設定プロセスについてまとめてみました。本文でも述べましたが、このプロセスはリスクアセスメント及びリスク対応において高い一貫性と再現性を得るために実施されています。裏を返せば、このプロセスにおいて検討や方向付けに不十分な点があると、リスクマネジメントに対する一貫性が得られず、次のような問題が発生する可能性があります。

• リスク特定漏れにより、想定外のインシデントが発生する
• リスク対応の優先付けが適切に行われず、重大なリスクが保有されたり、軽微なリスクに過剰な対応が行われる

　また、このプロセスにおいて十分な検討が行われることはもちろんのこと、次のマネジメントサイクルにおいて改善できるように検証を行うことも重要です。

参考資料

　本稿は、主に以下のガイドライン他を参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

• ISO/IEC DIS 27005:2021 Information security, cybersecurity and privacy protection - Guidance on managing information security risks
• JIS Q 27001:2014（ISO/IEC 27001:2013）情報セキュリティマネジメントシステム−要求事項
• JIS Q 27000：2019　情報技術−セキュリティ技術－情報セキュリティ マネジメントシステム－用語
• JIS Q 31010：2022（ISO/IEC 31010：2019）リスクマネジメント－リスクアセスメント技法
• JIPDEC JIP-ISMS113-3.0 ISMSユーザーズガイド ーリスクマネジメント編－
• JIS Q 31000：2019（ISO 31000：2018）リスクマネジメント−指針
• Factor Analysis of Information Risk（FAIR）

脚注

*1:他にも、プロジェクト管理、脆弱性管理、インシデント管理、問題管理などの他のマネジメントシステムのリスク管理プロセスとして実施することが考えられますが、その場合は、上位方針（目的）との整合性、リスクマネジメントを実施した組織と情報セキュリティマネジメントを統括する組織間で（例えば、リスクの状態や受容した根拠の共有、専門知識の活用などの）コミュニケーションが確立されることが重要です。

*2:コンプライアンス要件を、最上位のリスクとして管理するのか、あるいは、リスクマネジメントとは別に遵守事項として管理するのかは、その組織の考え方次第ですが、優先されるべき事項であることには変わりはありません。

*3:リスクの重大性に影響する属性（保管形態、資産価値など）によるグループ化

*4:ベースラインアプローチ（Baseline Approach）、非形式的アプローチ（Informal Approach）、詳細リスク分析（Detail Risk Analysis）、組合せアプローチ（Combined Approach）

*5:一貫性を確保するとの観点とは相反しますが、複数の分析手法を組み合わせることでリスクを適切に表現できるのであれば実施を検討すべきと思います。

*6:適用範囲の調整（scoping）とは、組織にとって範囲外となる管理策を除外することです。例えば、個人情報を保管していない組織においてプライバシーに関連する管理策は不要である可能性があります。

*7:テーラリング（tailoring）とは、組織の実情に合わせ、管理策の内容を調整することです。例えば、頻繁に派遣社員の入れ替わりがある組織では、アクセス権の設定状況など様々なレビューの間隔を一般的なものより短くすることを検討します。

*8:追加管理策と拡張管理策による補完（Supplementing）とは、組織固有の状況を考慮した詳細管理策による補足を行うことです。例えば、組織で利用しているPCのほぼ全てがWindowsOSの場合、Windows固有の詳細管理策による補足を追加することです。

情報セキュリティリスクマネジメントについて（１）

ー１．リスクの定義ー

はじめに

　以前から各ブログで述べているようにセキュリティマネジメントはリスクマネジメントに基づき実施することで合理的な運用が可能になります（不要な管理策や無駄な管理策の重複を避ける効果が期待できます）。
　そのためセキュリティ関連のガイドラインを発行している主な組織からもリスクベースでセキュリティマネジメントを実施するためのフレームワークが提供されています。（例えば、ISO/IEC 27005、NIST SP800-37、CIS RAMなど）
　これまで、セキュリティ管理策について何件か投稿していますが、リスクマネジメントに触れないことにはその説明ができない状況も増えてきましたので、ここで、セキュリティリスクマネジメントについて簡単にまとめておきたいと思います。
　注）なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、誤りがある可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

１）リスクとは

１ー１）リスクに関する一般的なイメージ

　最初にリスクという言葉が一般的にどのような使われ方をしているのか確認しておきたいと思います。
　例えば、2022年8月16日付の日本経済新聞の紙面には、リスクという言葉が多く使用されており、その意味合いは「好ましくない影響や結果（一般的に純粋リスクと呼ばれます）」と「不確実性（一般的に投機的リスク（又はビジネスリスク）と呼ばれます）」の二つに分けることができます。

2022年8月16日の日本経済新聞（デジタル版）より抜粋

好ましくない影響や結果として使用されている例 ）
・米中の対話ルートは細り、偶発的な衝突リスクは増しつつある。
・アクティビストの動きが世界的に活発になってきた。（中略）行き過ぎた要求が経営に混乱をもたらすリスクもある。
・感染すると肺炎を起こすリスクの高い高齢者や5歳未満の子ども、心臓や肺に持病のある人などへのワクチン接種が特に必要。

不確実性として使用されている例 ）
・中国の景気減速懸念が強まったのも、リスク回避時に買われやすい米国債の上昇につながった。
・15日の米国株式市場で主要3指数がそろって上昇し、投資家が運用リスクをとる姿勢を強めている。
・外為市場ではリスク回避ムードが強まり、円に買いが入った。

　他の場面でも、ほぼ同じような意味合いで使われていると思います。

１ー２）情報セキュリティリスクとは？

　今回取り上げるテーマは「情報セキュリティリスクマネジメント」ですので、関連するガイドラインを発行しているISO規格を参考にリスクの定義を理解します。
　リスクマネジメントのガイドライン規格である JIS Q 31000：2019 (ISO 31000：2018) では、リスクは以下のように「目的に対する不確かさの影響」として定義されています。

JIS Q 31000：2019 (ISO 31000：2018)　より

3.1 リスク（risk）
目的に対する不確かさの影響。

注記1 影響とは、期待されていることからかい（乖）離することをいう。影響には、好ましいもの、好ましくないもの、又はその両方の場合があり得る。影響は、機会又は脅威を示したり、創り出したり、もたらしたりすることがあり得る。
注記2 目的は、様々な側面及び分野をもつことがある。また、様々なレベルで適用されることがある。
注記3 一般に、リスクは、「リスク源」、「起こり得る事象」及びそれらの「結果」、並びに「起こりやすさ」として表される。

　前項で触れた一般的な使われ方（不確実性とその結果、影響）と同じ意味で定義されていると解釈できます。

　もう少し掘り下げてみます。情報セキュリティリスクマネジメントのガイドライン規格であるISO/IEC DIS 27005：2021では、リスクの用語定義の注記に以下の文面が追加されています。

ISO/IEC DIS 27005：2021　より

3.1.1 risk
3.1.1 リスク
（中略）

Note 3 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or knowledge of, an event, its consequence, or likelihood.
注記３：不確かさとは、ある事象、その結果、又は起こりやすさに関連する情報、理解または知識が部分的にでも欠落している状態をいう。

Note 5 to entry: In the context of information security management systems, information security risks can be expressed as effect of uncertainty on information security objectives.
注記５：情報セキュリティマネジメントシステムの環境下では、情報セキュリティリスクは、情報セキュリティ目的に対する不確かさの影響として表現することができる。

Note 6 to entry: Information security risks are always associated with a negative effect of uncertainty on information security objectives.
注記６：情報セキュリティリスクは、情報セキュリティ目的に対する不確かさの負の影響が常につきまとう。

Note 7 to entry: Information security risk can be associated with the potential that threats (3.1.5) will exploit vulnerabilities (3.1.6) of an information asset or group of information assets and thereby cause harm to an organization.
注記７：情報セキュリティリスクは、脅威が情報資産又は情報資産群の脆弱性を悪用し、それによって組織に損害を与える可能性と関連付けることができる。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

　ここまでで理解した内容を表現すると下図のようなイメージになると思われます。

図１　リスクのイメージ

　組織は、目的を達成するために行っている活動を不確かにする内外の要素（リスク源）やその影響に直面しています。情報セキュリティマネジメントは情報セキュリティ目的を達成するために実施されますが、同じように内外の様々な要素や影響により結果が不確かなものになる可能性を孕んでいます。
　目的に影響を与える可能性のある内外の状況を理解し、その不確かさを特定し（リスク特定）、その起こりやすさや結果を分析し（リスク分析）、対応を判断し（リスク評価）、判断した内容に基づき対応する（リスク対応）ことにより、不確かさが目的に及ぼす影響をマネジメントすることが可能になります。それを情報セキュリティリスクマネジメントと呼びます。 *1

　なお、リスク全般の定義では、上図のようにリスクはプラスにもマイナスにも影響します（前述の投機的リスク（ビジネスリスク）の考え方） が、情報セキュリティリスクマネジメントでは、通常、負の影響（前述の純粋リスクの考え方）をコントロールすることに主眼が置かれます。

１ー３）情報セキュリティの目的とは？

　前述の通り、リスクは「目的に対する不確かさの影響」と定義されているため、情報セキュリティリスクについて考える場合、情報セキュリティの実施目的を明らかにする必要があります。ここでは、情報セキュリティマネジメントシステムの実施目的と情報セキュリティの実施目的について考えてみます。

　まずは、情報セキュリティマネジメントシステム（ISMS）の実施目的について考えます。
　JIS Q 27001:2014（ISO/IEC27001:2013）には以下の一文が記載されており、これがISMSを組織が適用する目的であると考えられます。

JIS Q 27001:2014　0.1概要より

ISMSは、リスクマネジメントプロセスを適用することによって情報の機密性、完全性及び可用性を維持し、かつ、リスクを適切に管理しているという信頼を利害関係者に与える。

① ISMSの実施目的

　ISMSを組織が適用する目的は、以下の2点であると解釈できます。

• リスクマネジメントプロセスを適用することによって情報の機密性、完全性及び可用性を維持するため
• リスクを適切に管理しているという信頼を利害関係者に与えるため

　次に情報セキュリティの実施目的について考えます。JIS Q 27001:2014に情報セキュリティ目的に関する以下の記載があります。

JIS Q 27001:2014
6.2 情報セキュリティ目的及びそれを達成するための計画策定 より

組織は、関連する部門及び階層において、情報セキュリティ目的を確立しなければならない。
情報セキュリティ目的は、次の事項を満たさなければならない。
a) 情報セキュリティ方針と整合している。
b) （実行可能な場合）測定可能である。
c) 適用される情報セキュリティ要求事項、並びにリスクアセスメント及びリスク対応の結果を考慮に入れる。
d) 伝達する。
e) 必要に応じて、更新する。

　情報セキュリティ目的とは、「情報セキュリティ方針を達成するために、組織のリスクマネジメントの実情（リスクアセスメント及びリスク対応の結果）を考慮し設定される可能な限り測定可能な目標」と解釈できます。
※）情報セキュリティ方針は、事業、法律、法令、規制、契約上の要求事項を考慮し策定されます。詳しくは、過去ブログ「情報セキュリティのための方針」についてを参照下さい。

blg8.hatenablog.com

　リスクマネジメントの実情は組織により異なるため、誤解を生じさせないため具体例を提示することは控えますが、通常、セキュリティ目的は次のように組織内外の状況を考慮し、各組織、あるいは組織内の各部門又は階層毎に設定されます。

② 情報セキュリティ目的

以下を含む内外の状況を考慮し、組織毎に設定します。

• （事業、法律、法令、規制、契約上の要求事項が考慮された）情報セキュリティ方針
• 組織のリスクマネジメントの実情

　実際の運用では、情報セキュリティリスクマネジメントについて（４）で言及する3.1 リスク特定において、上記を含む情報セキュリティ目的に影響を及ぼす可能性のある組織内外の課題を抽出する事になります。

blg8.hatenablog.com

１ー４）情報セキュリティリスクマネジメントとは？

　情報セキュリティリスクマネジメントとは、そのリスクを最適化すること（適切にコントロールすること）です。それを実現するために、次のことを考慮したプロセスを確立する必要があります。

• 組織の状況に沿った情報セキュリティリスクマネジメント方針を策定し、標準、手順等を明らかにする（状況の設定）
• 現状のリスクを理解し、受容可能な範囲なのか判断する（リスクアセスメント）
• 受容できない場合は、そのリスクへの対応（リスク対応）方法を考え、実行し、その結果、残ったリスクについても再度、受容可否を判断する
• 受容すると判断したリスクでも時間の経過と共に起こりやすさや組織への影響の度合いが変わる可能性があるため、その変化を見逃さないためにモニタリングする
• リスクを変化させる要因となる情報を入手するために内外の利害関係者とのコミュニケーションを確立する

　上記プロセスを効率よく管理するためのフレームワークが各種ガイドラインから提示されています。今回はISO/IEC DIS 27005:2021で紹介されている情報セキュリティリスクマネジメントサイクルを紹介します。

図２　情報セキュリティリスクマネジメントサイクル

　上図のようにリスクマネジメントサイクルは反復的に実施されることが一般的です。図中のリスク判定点１、リスク判定点２では、それぞれ以下の考え方により反復の要否が判断されます。

• リスク判定点１
  　担当者のスキルや用いた情報の量など、実施されたリスクアセスメントが妥当な内容だったか？

• リスク判定点２
  　実施したリスク対応により、残留リスクが受容できるほどのレベルまで下がっているか？

　反復的に実施することのメリットは、反復の繰り返しにより、アセスメントの深さと詳細さを徐々に増すことが可能であることがあげられます。具体的には、組織で定めた基準（リスク判定点１、リスク判定点２）に達するまで反復することで過度なアセスメントや管理策の実施を防ぎ、高リスクに優先的に対応することができ、過不足のない効率的な運用が可能となります。
　次回以降、リスクマネジメントサイクルの個々のプロセスについて具体例を交え考えたいと思います。

まとめ

　リスクマネジメントを実施するためには、時間とコストがかかります。特にリスクアセスメントを実施する際は、多くの情報を収集しなければならないため、どうしても判断を先送りにしがちですが、放置したリスクが顕在化した場合、最終的には想定外のコストと時間を浪費する可能性があります。具体的には、次に示す二つのケースは、どちらも最終的にはリスクに対し何も対応しないとの結論ですが、両者には決定的な違いがあります。

• リスクを放置する（リスクを特定せず、結果としてリスク対応しない）

　いつどのような問題が発生するのかわからず、リスクが顕在化した場合、被害を最小限に抑えるための対応を急遽立案しなければならなくなり、被害を拡大させる可能性や時間的・経済的に多くの損失を被る可能性があります

• リスクを保有する（リスクを評価した結果、明確な意思の下、リスク対応しないと判断する）
  

　事前のリスク対応はしませんが、リスクが顕在化した場合でも想定した被害の範囲内で処理できる可能性が高く、想定したインシデントに対する対応策も事前に検討できているため、短期間で対処に取り掛かることが可能になります

　セキュリティマネジメントにおいても、管理策を最適に実装するため、リスクマネジメントに基づいて実施されることが一般的であるため、次回以降で紹介するリスクマネジメントサイクルの個々のプロセスの進め方は、多くの組織にとって有効な内容になると思います。 　

参考資料

• 日本経済新聞（デジタル版）
• JIS Q 31000:2019 リスクマネジメント−指針
• ISO/IEC DIS 27005 : 2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
• JIS Q 27001 : 2014 情報技術−セキュリティ技術− 情報セキュリティマネジメントシステム−要求事項

脚注

*1:不確かさには偶然に左右されるような本質的に変動する要素も含まれるため、全ての不確かさやその影響を理解することはできません（リスクを全てなくすことはできません）。リスクマネジメントとは、リスクを可能な限り特定・分析し、予防策を講じたり、事象を早期に検知し適時に対応したりすることで、その影響を組織が受容すると決めた範囲で管理することと言えます。

セキュリティ侵害を表す用語とIoCについて

はじめに

　セキュリティの管理策を検討する際に参照することが多いNIST SP800-53 Rev.5には、いくつかのセキュリティ侵害を表すための用語が使用されています。その違いについてまとめておきます。
　本ブログでは、本質を理解し、根拠を明らかにし、具体例を示すことを心がけておりますが、本稿については「多分、このようなことであろう」との内容になっており、正確性もいつも以上に劣ります。さらに、今回調べた限りでは、各用語に明確な定義はないと思われますので、用語の正確な意味を捉えるためには、前後の文脈などその使われている状況を加味することが必要です。
　注）なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

各用語の使用例

　次のように、NIST SP800-53 Rev.5の中には、セキュリティ侵害を表す用語として、exposure, intrusion, breach, compromiseが使用されており、理解しておいた方が良いと思い調べることにしました。

PM-16 THREAT AWARENESS PROGRAM
Because of the constantly changing and increasing sophistication of adversaries, especially the advanced persistent threat (APT), it may be more likely that adversaries can successfully breach or compromise organizational systems.
敵対者、特にAPTは常に変化し、高度化しているため、敵対者が組織システムのbreachやcompromiseに成功する可能性はより高くなっているかもしれない。

RA-10 THREAT HUNTING
Threat hunting is an active means of cyber defense in contrast to traditional protection measures, such as firewalls, intrusion detection and prevention systems, quarantining malicious code in sandboxes, and Security Information and Event Management technologies and systems.
脅威ハンティングは、ファイアウォール、intrusion検知・防御システム、サンドボックスによる悪意のあるコードの隔離、SIEMといった従来の防御策とは対照的な、サイバー防御の能動的な手段である。

AC-17 REMOTE ACCESS
As such, restricting the execution of privileged commands and access to security-relevant information via remote access reduces the exposure of the organization and the susceptibility to threats by adversaries to the remote access capability.
このように、リモートアクセスによる特権コマンドの実行やセキュリティ関連情報へのアクセスを制限することで、組織のexposureを減らし、敵対者によるリモートアクセスケイパビリティへの脅威への耐性を向上させることができる。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

解釈した内容

　ネットで調べた結果、類似の内容に言及している記事「Data Compromise＝情報流出は正解か」を見つけることができました。合わせて参照元の「Timehopの発表資料」も確認することである程度理解することはできました。
　Data Compromise＝情報流出は正解か：IT基礎英語 - ITmedia NEWS
　Security — Timehop

　上記と合わせ、NISTでの使われ方も加味した結果、以下のように解釈しました。

Exposure

　組織が実施している管理策に不備があり、潜在的な脅威にさらされている状態です。それが実際に悪用されているかどうかまでの意味は持っていません。具体的には、システムなどの支援資産に脆弱な設定が存在するなどが含まれます。
　なお、データに対するExposureとして使用されている場合は、機密情報が既に漏洩や公開されていることを意味していることがありますので、どちらを意味するのかは文脈からその対象が何なのか理解することで判断することになります。
　あえて、他の用語と比較するため日本語で表現すると、露出になるかと思います。

Intrusion

　組織が実施している予防的管理策を突破し、脅威アクターが情報資産にアクセスできている状態です。具体的には、境界防御の突破によるネットワークへの侵入（Network Intrution）や不正ログインによるシステムへの侵入、マルウェアの実行、ネットワーク上のスニッフィングなどが含まれます。
　あえて、他の用語と比較するため日本語で表現すると、侵入になるかと思います。

Breach

　組織が実施している検知的管理策を回避しつつ行われる脅威アクターの活動により、機密性、完全性、可用性のいずれかが損なわれた状態です。具体的には、データの改ざん・削除・窃取、サービスの停止などが含まれます。
　あえて、他の用語と比較するため日本語で表現すると、侵害になるかと思います。　

Compromise

　情報または関連資産が脅威アクターによって完全に掌握されている状態です。例えば、ランサムウェアによる暗号化、システムの破壊、データの持出などが含まれます。
　あえて、他の用語と比較するため日本語で表現すると、漏洩になるかと思います。

　解釈した内容に基づき、APTの攻撃シーケンスの各フェーズにマッピングすると、各用語が表すセキュリティ侵害度は次のようなイメージになります。

図１　各用語とセキュリティ侵害の度合いのイメージ

Indicators of Compromise（IoC）について

　脅威インテリジェンスでは、Indicators of Compromise（IoC）という言葉がよく使われますので、合わせて触れておくことにします。
　この言葉は、セキュリティ侵害の疑いがある場合に、異常の検知や痕跡の解析をするための指標として使用されます。前述の図１では、Compromiseは最終的に攻撃者（脅威アクター）が目的実行を達成した段階と解釈しましたが、IoCとして使用される場合は、それ以外の全てのフェーズで用いられることがあります*1 。
　APTの各フェーズで検知されるIoCをまとめると次のようになります。

偵察フェーズ

　攻撃者の偵察行動を早期に発見しセキュリティ対策を講じることを目的としています。また、これらの情報を分析することで、攻撃者のTTPsや動機を理解することができ、より効果的な対策を講じることができます。具体的には、次のようなインターネットからの不審な行動を検知します。

• ネットワークアクティビティ
• ウェブサイトやソーシャルメディアへのアクセス
• DNSクエリ
• ポートスキャン、脆弱性スキャン
• アクセス（ログイン）試行

侵入フェーズ

　攻撃者によるネットワークやシステムへの侵入が疑われる行動を早期に発見しセキュリティ対策を講じることを目的としています。また、これらの情報を分析することで、攻撃者のTTPsを理解することができ、より効果的な対策を講じることができます。具体的には、次のような内部ネットワーク上の不審な行動を検知します。

• アクセス（ログイン）試行
• トラフィックやリクエストの急増
• ポートスキャン、脆弱性スキャン
• マルウェアへの感染
• 不審なプロセスの実行
• C2サーバーとの通信

遠隔操作フェーズ

　C2サーバーとの通信や不正なアップロード、ダウンロードのような攻撃者による遠隔操作が疑われる行動を早期に発見しセキュリティ対策を講じることを目的としています。また、これらの情報を分析することで、攻撃者のTTPsを理解することができ、より効果的な対策を講じることができます。具体的には、次のような内部ネットワーク上の不審な行動を検知します。

• C2サーバーとの通信
• 不審なプロセス、コマンドの実行
• 不正なファイルのアップロード、ダウンロード
• リモートアクセスツール（RAT）の使用

横展開フェーズ

　攻撃者が組織のネットワーク内を移動し、他のPCやサーバー、ディレクトリサービスなどのより高い権限を得ようとしている行動を早期に発見しセキュリティ対策を講じることを目的としています。また、これらの情報を分析することで、攻撃者のTTPsを理解することができ、より効果的な対策を講じることができます。具体的には、次のような内部ネットワーク上の不審な行動を検知します。

• 普段と異なるアカウントによるアクセス
• ログイン回数、アクセス回数の増加
• ネットワークトラフィック（偽装パケット、暗号化された通信など）

探索フェーズ

　攻撃者が組織のネットワーク内で、標的としている情報やデータを入手しようとする行動を早期に発見しセキュリティ対策を講じることを目的としています。また、これらの情報を分析することで、攻撃者のTTPsを理解することができ、より効果的な対策を講じることができます。具体的には、次のような内部ネットワーク上の不審な行動を検知します。

• 特定のファイルへのアクセスログ
• ファイル検索、コピーの増加
• ファイルのアップロード、ダウンロードの増加

目的実行フェーズ

　攻撃者が標的としている情報の窃取、暗号化、システムの破壊などの最終目的が達成された疑いがある場合に、上記の各フェーズで得られる情報に加え主に次のような目的で、攻撃の痕跡から分析を行います。

• インシデントの内容把握
  攻撃者による活動を分析することでインシデントの内容を把握します。被害状況を把握することで、利害関係者への速やかな報告が可能になり、さらに、管理策の改善など、再発防止に役立てることができます。

• 被害の最小化
  このフェーズでもまだ攻撃が続いている可能性もあるため、解析により被害を最小化します。

• 類似攻撃への対策
  攻撃者が使用したTTPsを理解することで、類似の攻撃を防ぎます。

• フォレンジック
  IoCの解析により、攻撃者による不正アクセスやデータ窃取などの犯罪行為を特定し、法的措置に役立てます。

まとめ

　適切なインシデント対応やリスクコミュニケーションを行う際には、インシデントの内容を正確に把握し伝えることが求められます。その中でも、侵害の度合いを表す情報は特に正確さが求められます。
　今回、取り上げたようにセキュリティ侵害を表す様々な用語が使われているということは、侵害の度合いが重要であることの裏返しとも言えると思います。ただし、その用語の定義が統一されていない可能性も高いため、用語に頼るのではなくその侵害の度合いを補足説明により正確に伝える*2ことが重要だと思います。
　例えば、本文で触れた記事から引用すると「パスワードは窃取された（Breachはされた）が、ハッシュ化されていたためCompromiseされていない」との言い分は、ある程度、状況が理解できます。このようなケースでは、同じパスワードの漏洩事案であってもインシデントの印象は大きく異なりますので主張することが必要なのかもしれません。

　本文では触れませんでしたが、侵害の兆候を検知することをIoA（Indicator of Attack）*3 、侵害の痕跡を分析することをIoC（Indicators of Compromise）*4 と明確に区別している場合もありますので、こちらも前後の文脈による理解が必要です。

参考資料

　本稿は、以下のガイドライン及び記事を参考にしています。より詳細な情報が欲しい、正確性を重視したい等については以下を参照して下さい。

• NIST SP800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations
• ITmedia　IT基礎英語　Data Compromise＝情報流出は正解か
• TIMEHOP SECURITY INCIDENT, JULY 4TH, 2018

脚注

*1:IoA（Indicator of Attack）と表現されることもありますので、まとめで補足説明します。

*2:どこまで詳細に報告するかは熟慮が必要です。

*3:IoAは、図１では、侵害～探索までのフェーズに相当します。

*4:IoCは、図１では、目的実行フェーズに相当します。

セキュリティ上の「多層防御」について

はじめに

　セキュリティリスクに対応するための各管理策を効果的に実装するためには、多層防御の考え方が欠かせません。今回は、多層防御についてまとめます。
　CISSPを受験する予定の方は、概念的な部分と多重防御との違いを理解しておいた方が良いと思われます。
　注）なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

多層防御とは？

　多層防御とは、特定のリスクに対応するために、そのリスクを低減させる（結果、又は起こりやすさを小さくする）ための異なる管理策を多層的に実装することで、管理策間の相乗効果や他の管理策による補完効果を期待する概念と筆者は解釈しています。

図１　多層防御の概念イメージ

　過去ブログベースライン管理策（セキュリティベースライン）についてで紹介したケイパビリティを把握するためには、この多層防御の概念を理解していることが前提になります。

blg8.hatenablog.com

具体的な実施例

　前項で述べた通り、多層防御は管理策を多層的に実装することでセキュリティケイパビリティを高めることを目的としています。
　その意図からは、次の３つの視点が考えられます。

• 攻撃シナリオに基づく多層防御
• 管理策の種別に基づく多層防御
• 管理策の機能に基づく多層防御

　次項以降で、それぞれについて具体的に考えてみます。

１．攻撃シナリオに基づく多層防御

　多層防御という言葉は、大部分がこの視点で語られることが多いと思われます。
　従来のセキュリティ対策では、組織が保有する情報など、組織内部に存在する重要な資産を外部攻撃から保護するとの視点で考えられることが一般的でした。
　外部からの攻撃シナリオは、大まかに次の３ステップに分けることができます。

　１）初期侵入
　　　マルウェアが添付されたメールなどを送信し、組織内部に侵入する
　２）内部活動
　　　感染PCを外部から遠隔操作し、重要な情報を探し出し持ち出す準備をする
　３）情報送出
　　　収集した情報を外部に送信する

　上記、１）、２）、３）の各ステップの攻撃を入口だけでなく、内部や出口も含め予防・検知することで、入口をすり抜けられた場合でも攻撃者による最終目的（上記ケースでは情報の外部送信）達成の確率を大幅に下げることができます。
　これが、入口対策、内部対策、出口対策の各層における多層防御の概念です。イメージを下図に示します。

図２　攻撃シナリオに基づく多層防御のイメージ

２．管理策の種別に基づく多層防御

　上述に次いで多層防御として使われることが多いのがこの概念です。
　セキュリティリスクに対応するための管理策種別は、一般的に次のように分類されます。

　１）組織的管理策（Organizational controls）
　　　セキュリティのための体制構築、方針に関する管理策
　２）人的管理策（ People controls）
　　　契約、採用などの要員の雇用や教育・訓練に関する管理策
　３）物理的管理策（Physical controls）
　　　区間管理、入退・監視などの物理的な侵入の防止・検知に関連する管理策
　４）技術的管理策（Technological controls）
　　　アクセス制御、ネットワーク、マルウェア対策などのICTに関連する管理策

　現状は、疑わしいメールを見分ける教育・訓練のような人的管理策を実施しても、その攻撃が巧妙化しており全てを防ぐことはできません。そのようなケースでは、メールフィルタリングやWebフィルタリングのような技術的管理策を併用（ORの関係）することで、人的脆弱性を補いインシデントの発生確率を抑える効果が期待できます。
　多層防御の例ではありませんが、管理策種別の組み合わせによっては、複数の管理策が同時に機能しないと効果を発揮しないケースも考えられますので参考までに紹介しておきます。例えば、技術的対策としてアクセス制御を行う場合、アクセス制御方針のような組織的対策が確立している前提でのみ双方の管理策は有効に機能します（ANDの関係）。
　このように同じリスクへの対応又はセキュリティ目的を達成するための各管理策は、相互に作用することが多く、多層的にそれぞれが機能することにより多くの効果が得られます。
　上記で紹介した２つのケースのイメージを表すと下図のようになります。

図３　管理策の種別に基づく多層防御のイメージ

３．管理策の機能に基づく多層防御

　多層防御としてあまり触れられることのない概念ですが、個人的には、同一のリスクへの対応やセキュリティ目的を達成するために複数の管理策を実装する場合に、全体的な能力（セキュリティケイパビリティ）を算定する際に最も重要な考え方だと思っています。
　セキュリティ管理策がどのように機能するのかで分類すると、一般的に次のように分けられます。

　１）予防的管理策（preventive control）
　　好ましくない結果につながる事象の発生を予防することを目的とした管理策
　２）検知的管理策（detective control）
　　同じく事象の発生を検知することを目的とした管理策
　３）是正的管理策（corrective control）
　　事象が発生してしまった場合に、結果を是正することを目的とした管理策

　上記の各管理策の関連性のイメージを下図に示します。

図４　管理策の機能に基づく多層防御のイメージ

　上図のように多層的に管理策の機能を実装することで、マルウェアの侵入を予防できず組織内のPCが感染してしまった場合でも、そのPCの疑わしい行動を検知し、適切に対処することでその後の侵害を止めることが可能です。
　加えて、例えば、二重脅迫型ランサムウェア対策では、攻撃者によるデータの暗号化を想定したオフラインバックアップ、データ窃取を想定したデータの暗号化を事前に実装しておくことで、攻撃を無効化することが可能です。バックアップや暗号化のような是正的管理策は、攻撃そのものを予防・検知することは出来ませんが、結果を変えることができるという点で有効な管理策です。

４．具体的な実施例

　ここでは、マルウェアからの保護を具体例として、個々の詳細管理策と管理策の種別及び機能の関連性をまとめたいと思います。
　ISMSに基づく管理策の指針として活用されることの多い ISO/IEC 27002:2022 では、マルウェアからの保護について次のように記載されています。

ISO/IEC 27002:2022 8.7 Protection against malware から引用

Purpose：
To ensure information and other associated assets are protected against malware.
管理目的：
情報およびその他の関連資産がマルウェアから確実に保護されるようにするため。

Control：
Protection against malware should be implemented and supported by appropriate user awareness.
管理策：
マルウェアからの保護は、利用者による適切な認識と併せて、実施する。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

　上記、管理目的、管理策から具体的な詳細管理策とその種別及び機能の関連性をまとめたものが下表であり、一つの管理策を満たすために多層の種別、機能の観点から詳細管理策を配置しなければならないことが理解できると思います。

表１　マルウェアからの保護に関する詳細管理策とその分類例

多重防御について

　多層防御に似た概念に多重防御というものがあります。入口対策として同じ機能を持った管理策を多重に配置することにより予防・検知の網羅性を向上させるためのものです。例えば、マルウェア対策として、従来型のシグネチャベースの対策ツールをネットワークGW、サーバー、エンドポイントに導入する場合、同一ベンダ製で揃えるとシグネチャ及びその配布タイミングも同じになるため、漏れや遅れの発生が単一障害点的に脆弱性に直結する可能性があります。それを回避するためにそれぞれの箇所に異なるベンダの製品を分散配置することがあり、それを多重防御と呼ぶことがあります。
　一方、多くのセキュリティ製品やサービスでは、例えば、FW、IDS/IPS、Webフィルタリング、VPN-GWなど複数機能が提供されており、複数の製品を導入すると、意図せず機能が重複してしまうことがあります。このような場合は、費用対効果（無駄な管理策の重複）、ネットワーク負荷の増大など負のイメージとして多重防御という言葉が使われることもあります。

まとめ

　今回、このブログを投稿するにあたり、筆者の認識が間違っていないか「多層防御」というキーワードで検索し数件のサイトを確認しましたが、その結果、一部のサイトでは「多層防御はもう古い」、「多層防御だけでは防げない」との記述がありました。
　上記は、数年前から言われている「クラウドサービスとリモートワークの増加により、外部は危険、内部は安全という前提の境界防御が限界に達する」という趣旨のようです。図２のように「入口」、「内部」、「出口」の各領域を多層的に防御すること＝境界防御というイメージを持ち、そのような文章になってしまっているのだと思いますが、重要なのは、内部対策を疎かにしないことと組織の外部に存在する情報及び支援資産（例えば、クラウドサービス上の情報やリモートワーク時のPC）のセキュリティ方針を確立することです。
　また、多層防御は従来の境界防御だけに適用されるものではなく、例えば、SASEであってもSWGやCASBのような個々の構成要素は脅威シナリオベースで考えると多層的に機能しており、マイクロセグメンテーションも多層防御の概念に反するものではありません。今後もその概念の重要性が変わることはないと考えます。

参考資料

　本稿は、以下のガイドラインを参考にしています。より詳細な情報が欲しい、正確性を重視したい等については以下を参照して下さい。

• ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls

脚注

ベースライン管理策（セキュリティベースライン）について

はじめに

　情報セキュリティリスクマネジメントを実施する際に、ベースライン管理策（セキュリティベースライン）を理解することで効率的、効果的に進めることが可能になります。今回は、ベースライン管理策についてまとめます。
　CISSPを受験する予定の方は、各プロセスの関連性と用語の意味を理解しておいた方が良いと思われます。
　注）なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

ベースライン管理策とは？

背景

　ベースライン管理策の背景を理解するために、米国連邦政府における情報セキュリティ政策について簡単に触れておきます。
　米国政府では、PUBLIC LAW 107-347 “E-Government Act of 2002” TITLE III Federal Information Security Management Act of 2002 （一般的に「FISMA」と呼ばれています）が2002年に制定されました。この法律は、連邦政府機関に対し情報セキュリティの強化を義務付け、その実施支援を目的とした「連邦政府の情報及び情報システムのセキュリティをリスクに基づき適切に管理するための分類、及びその分類に応じた最低限のセキュリティ要求事項を明らかにするためのプログラム」の開発をNISTに指示しました。

　上記の指示とその対応についてまとめたものが下図になります。

図１　セキュリティに関連する法律、規格、ガイドラインの関連性（米国）

　上図の中に登場するガイドライン　NIST SP800-53において、各分類（低、中、高）に応じた管理策ベースライン（Control Baselines）カタログが提供されています*1。また、その上位規格である FIPS PUB 200 には次の記述があり、原則、管理策ベースラインで示されている全てのセキュリティ管理策の実施が義務付けられています。

FIPS Publication 200　4 SECURITY CONTROL SELECTIONから引用

Organizations must employ all security controls in the respective security control baselines unless specific exceptions are allowed based on the tailoring guidance provided in NIST Special Publication 800-53.

組織は、NIST Special Publication 800-53 で提供されるテーラリングガイダンスに基づく特定の例外が認められない限り、それぞれのセキュリティ管理策ベースラインにある全てのセキュリティ管理策を採用しなければならない。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

　このような背景があるため、一般的にベースライン管理策とは、民間組織においても、その組織で定める分類（ほとんどのケースではリスクによる分類）に応じた最低限実施すべきセキュリティ管理策の基準を意味します。このベースライン管理策は、リスクアセスメント時に利用されることの多い手法であるベースラインアプローチ*2を実施する際の基準としても使用されます。

組織内標準での位置付け

　組織内の情報セキュリティマネジメントを進める上で、セキュリティポリシーの実装を支援するための構成要素として様々な組織内標準（文書類）を作成します。ベースライン管理策も実施すべき管理策の基準としてその中に含まれ、下図のような位置づけになると考えます。

図２　組織内標準の中でのベースラインの位置付け

　法的要件や事業要件などを含む組織の内外の状況に基づくセキュリティポリシーを満たすベースライン管理策*3を策定することにより、管理策相互の影響を含めた包括的なリスクマネジメントと管理策全体に渡る適切な配備が可能になります。

具体的な実施例

　前項で述べた通り、実装すべき管理策はそれを適用する組織のセキュリティポリシーにより異なり、また、管理策に求める優先度や成熟度も異なります。そのため、効果的な実装のために組織のセキュリティポリシーに合わせ管理策をテーラーリングすることが一般的です。
　以降において、一般的なベースライン管理策の作成（テーラーリング）手順を示します。

１．参照するベースラインカタログの選択

　次に示すような汎用ベースラインカタログ（一般的には、セキュリティのための標準規格、管理策カタログ、管理策フレームワーク、ガイドラインと呼ばれます）から、法的要件を含む組織のセキュリティポリシーに適していると思われるものを選択します。選択したベースラインを本稿では初期ベースラインと呼ぶことにします。

• 法、規制
  FISMA、GDPR、個人情報保護法など

• 国際機関などによる標準規格
  ISO、NIST、ENISA、CISなど

• 業界の標準規格や推奨事項
  PCI DSS、JAMA/JAPIA サイバーセキュリティガイドラインなど

２．管理策のテーラリング（tailoring）

　初期ベースラインを自組織のセキュリティポリシーに合わせテーラリングします。
　このプロセスは、リスクマネジメントの一部として実施されるためデューケア、デューディリジェンスが求められます。したがって、個々の管理策に対するテーラリングがリスクベース*4 *5に基づき実施されていることを説明できるような（特に、管理策の採否を決定した根拠や実施に対する承認などの）記録を保持することが必要とされます*6 。
　以降で、NIST SP800-53Bに例示されているものを参考にテーラリングプロセスの流れを簡単に説明したいと思います。

２－１．共通管理策の識別と指定

　個々の管理策を実装するためのアプローチの方式を定めます。NIST SP800-53では、次に示す3種類の実装アプローチが紹介されています。

• 共通管理策：

　組織内の各部署、施設、各支援資産、それぞれに対し固有ではなく、組織全体として共通で実装すべき管理策です。
　共通管理策として実装することでリソースの効率的な運用や組織全体での管理策の標準化の効果が期待できる反面、実装する管理策が脆弱であった場合に単一障害点（Single Point of Failure）となってしまう点や資産の管理責任と関連する管理策の実施責任の所在が異なることによるガバナンス欠如の点がリスクとして考えられます。
　共通管理策として実装されることが多い管理策は、物理的対策全般、要員の教育などの組織的対策全般、インシデント対応、境界保護、監査などがあげられます。

• 固有管理策：

　各部署、施設、各支援資産などの管理責任及び認可権限のある担当者が管理策の実装責任を担う方式です。
　共通管理策と逆の効果が期待できますが、投資効果が非効率になることと、各管理策の実施内容に差が生じ、脆弱な箇所が発生するリスクがあります。

• ハイブリッド管理策：

　可能な管理策は共通化し、他の部分を個別に実装する方式です。
　共通管理策と固有管理策の良い面を併せ持つメリットを有しますが、管理策の共通部分と固有部分の実装及び維持・継続のための管理責任があいまいになりがちなリスクがあります。

２－２．適用範囲の調整（scoping）

　前項で選択した汎用ベースラインカタログで提供されている個々の管理策について、組織のセキュリティポリシーに従い（リスクベース及びコンプライアンスベースの考え方に基づき）要否を検討し採否を決定します。これにより組織にとって実装不要な管理策を取り除くことができ合理的な管理策の運用が可能になります。 　例えば、次のような管理策は適用範囲外とする可能性があります。

◆ 組織のセキュリティポリシーとの不整合

• 実装することにより法令違反の可能性が高まったり、組織の事業要件を満たさない（機能低下させる）管理策
• 組織において適用外の法的要件を満たすための管理策
  

◆ 対象の管理策が前提としている運用や環境と組織の状況との不整合

• 一時的な仮想インスタンスにより運用されるOSやアプリケーションに対する管理策
  
• 完全なエアギャップ環境に対するネットワーク関連（ネットワークの分離など）の管理策
  
• インターネットVPNなど、組織が認めていない運用または環境に関する管理策
  

２－３．代替管理策の選択

　組織として実装が必要と判断した管理策が、技術面、費用面などの理由により、即時対応が難しい場合、代替となり得る管理策の実装を検討します。初期ベースライン、又は他の汎用ベースラインからの選択や組織独自に検討した代替管理策の実装を想定したリスクアセスメントを行い、リスク許容を根拠とする最終的な実装の判断をします。原則、代替管理策は正規に必要と判断した管理策が実装されるまでの一時的なものとして扱います。
　例えば、人的リソースが豊富ではない組織では、職務の分離を実施するための人員を確保できないため、頻繁な監査、詳細な役割毎の教育・訓練や雇用時の厳しいスクリーニングを代替管理策として実装することが考えられます。また、ツールによる自動化をするための投資がすぐにはできない場合も、同じように手順の明確化、詳細な役割毎の教育・訓練や頻繁な監査により手動で代替されることが考えられます。

２－４．管理策パラメータの調整

　NIST SP800-53のように各管理策のパラメータの数値を利用組織に委ねている場合や汎用ベースラインカタログでパラメータが指定されている場合でも、（例えば、アプリケーションのタイムアウト要件を 10 分間の非アクティブ状態から 5 分間に変更するなど）組織のセキュリティポリシーに従いパラメータを調整することがあります。

２－５．追加管理策と拡張管理策による補完（Supplementing）

　組織のセキュリティポリシーを満たすために、初期ベースラインでは不十分と判断する場合は、追加または拡張管理策を実装します。本アクティビティを効率的、効果的に実施するためには、後述する３．ケイパビリティと４．オーバーレイを理解する必要があります。

２－６．管理策実装のための仕様情報の提供

　初期ベースラインにより示される管理策の内容が、例えば抽象的な表現がとられており、解釈により実際の実装が意図したものと異なる内容になってしまう可能性がある場合には、その管理策の詳細を説明するための仕様情報により補足します。このアクティビティについても効率的、効果的に実施するためには、後述する３．ケイパビリティと４．オーバーレイを理解する必要があります。

３．ケイパビリティ（capability）

　外部脅威などを含む組織内外の状況を踏まえたセキュリティポリシーを満たすために組織全体として満たすべきセキュリティケイパビリティ*7を定めます。
　具体的には、必要なセキュリティ要件を満たしつつ、想定したリスクを許容可能なレベルまで下げるために必要な管理策とその成熟度（それらを満たすための管理策の選択及び構成）を定めることをセキュリティケイパビリティと呼ぶようです。

４．オーバーレイ（overlay）

　オーバーレイ仕様とは、特定の分野・業界、技術・サービス、運用環境においてベースライン管理策を（例えば、拡張管理策や補足ガイダンスなどにより）補完することを目的として提供されているもので、利用することでテーラリングプロセスを効率的、効果的に進めることができます。 例えば、NISTでは、NIST SP800-53を初期ベースラインとする、次のようなオーバーレイ仕様が提供されています。

• 　800-82　Guide to Operational Technology (OT) Security
• 　800-161　Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations

　また、ISMSでも、ISO/IEC 27017（クラウドサービス）やISO/IEC 27701（プライバシーマネジメント）は、ISO/IEC 27002（ISO/IEC 27001）を初期ベースラインとするオーバーレイ仕様（ISOでは、アドオン規格と呼びます）と見なすことができると思います。
　次のようなガイドラインで提供されている管理策や補足ガイダンスも初期ベースラインの各管理策とマッピングすることにより、オーバーレイ仕様として利用することが可能です。

４－１．業界特有の要件及びリスクへの対応

◆ 医療関連

• ISO) ISO 27799
• NIST) NIST SP800-66
• 厚生労働省) 医療情報システムの安全管理に関するガイドライン
• 経済産業省・総務省) 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン

◆ 金融関連

• CRI) CRI Profile
• FSSCC) Cybersecurity Assessment Tool
• PCI SSC) Payment Card Industry Data Security Standard
• FSA) 監督指針
• FISC) 金融機関等コンピュータシステムの安全対策基準・解説書
• ISO)（ISO/IEC TR 27015）現在は廃止

４－２．技術・サービス特有のリスクへの対応

◆ IoT技術関連

• ISO/IEC) ISO/IEC 27400ファミリー
• NIST) NIST SP800-213
• ENISA) Baseline Security Recommendations for IoT
• ITAC・総務省・経済産業省) IoTセキュリティガイドライン

◆ クラウドサービス関連

• ISO/IEC) ISO/IEC 27017
• NIST) NIST SP800-144
• ENISA) Cloud Computing Information Assurance Framework
• CSA) CLOUD CONTROLS MATRIX
• 総務省) クラウドサービス提供における情報セキュリティ対策ガイドライン
• 経済産業省) クラウドサービス利用のための情報セキュリティマネジメントガイドライン

４－３．運用環境特有のリスクへの対応

◆ サプライチェーン関連

• ISO/IEC) ISO/IEC 27036
• NIST) NIST SP800-161
• NCSC) Supply chain security guidance

　採用したオーバーレイについては、採用の根拠や改定内容のベースライン管理策への反映を速やかに実施するための記録を残しておきます。NIST SP800-53Bの第3章に詳しく記載されています。

５．ベースライン管理策の作成例

　ここまでのプロセスに従い作成したベースライン管理策の例（技術的脆弱性管理に関する内容のみ抜粋）を下表に示します。

表１　ベースライン管理策の作成例（技術的脆弱性管理のみ抜粋）

まとめ

　今回はベースライン管理策についてまとめてみました。前述のとおり、ベースライン管理策は、リスクアセスメントを実施する上で重要な情報であるため、例えば、組織のセキュリティポリシー、選択した汎用ベースラインカタログとそれを選んだ根拠、テーラリングの実施内容とその根拠など、その作成に至るまでのプロセスが記録により説明できるようにしておくことが求められます。　

参考資料

　本稿は、次の文献を参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

• PUBLIC LAW 107-347 “E-Government Act of 2002” TITLE III Federal Information Security Management Act of 2002
• Federal Information Processing Standards Publication 199
• Federal Information Processing Standards Publication 200
• NIST SP800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations
• NIST SP800-53B Control Baselines for Information Systems and Organizations

脚注

*1:本ブログを書いている時点での最新版 NIST SP800-53 Rev.5 では、管理策ベースラインカタログはNIST SP800-53Bで提供されています

*2:ベースラインと実際の管理策の実施状況とのギャップ分析によりリスクを評価する手法です。

*3:組織内外の状況は刻々と変化しているため、その変化に応じベースライン管理策も見直します。また、変化に対し適切に対応できていることを定期的にレビューすることも重要です。

*4:例えば、アセットベースアプローチによる場合は、対象となる支援資産やそれに関連する業務の価値、また、イベントベースアプローチによる場合は、対象となるイベントの結果と影響の大きさに応じたもの

*5:一般的にコンプライアンスベースに基づく各種要件はテーラリングすべきではないとされています。

*6:ISMSの適用宣言書をイメージすると理解しやすいかと思います。

*7:個々の管理策によるそれぞれの効果ではなく、同じ管理目的（セキュリティ目的）のための一連の管理策による相互補完を含め全体としてのセキュリティ能力（例えば、組織的（Organizational）、人的（People）、物理的（Physical）、技術的（Technological）、あるいは、予防（Preventive）、検知（Detective）、是正（Corrective）など多角的、多層的にバランス良く管理策を組合せることによりケイパビリティは向上します。）

「パスワードクラック手法」と「有効な管理策」について（後半）

はじめに

　「パスワードクラック手法」と「有効な管理策」に関する2部構成の後半部分です。主に管理策について記述します。
　パスワードクラック手法について記述している前半部分については下記から確認できます。
　blg8.hatenablog.com 　注）なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

パスワードクラックに対し有効な管理策について

　パスワードクラックに対し有効と思われる主な管理策を各ガイドラインを参考に書き出します。

１．パスワードポリシーによる利用者への意識付け・義務化

　脅威に応じて定めた一定レベル以上の強度を持つパスワードが組織内で使用されるように、利用者への意識付け、（ツールの設定による強制を含む）利用者への義務化などの管理策により以下のセキュリティ要件を含むパスワードポリシーを定める必要があります。

• 一定以上の長さの文字列の使用
  　一定以上の長さの文字数を使用することにより、パスワードを特定するために行う試行回数が多くなるため、ほとんどのクラック手法に対し有効です。
  ※）パスワード登録時の条件として「○○文字以上、○○文字以下で設定してください」のように上限を設けている例がありますが、NISTでは上限は設定すべきではないとされており、処理能力の許す限り設定可能な文字数は多くすることが推奨されています。

• 全てのASCII文字、Unicode文字の使用許可
  　SQLインジェクションのように特殊文字を用いた攻撃を回避するために、パスワードにスペースや様々な特殊文字を利用することができないようにしている例がありますが、適切にハッシュ化されているものをデータベースに送信することでインジェクション攻撃は回避できるため、NISTでは利用者が選択可能な文字種に制限を設けるべきではないとされています。

• クラックされ難い（質の良い）パスワードの利用
  　以下のような具体例を提示し、利用者に対しクラックされ難いパスワードの利用を促すことが必要です。
  　・本人に関連する情報（例えば、名前、電話番号、誕生日）のように、第三者が推測できる又は得ることができる内容に基づく文字列を使用しない
  　・異なるサイト（ドメイン）でパスワードの使いまわしをしない
  　（特に組織内と個人利用のパスワード共用の禁止）
  　・従業員同士であってもパスワードを共有しない
  　（組織内でのなりすまし防止、責任追跡性の維持のため）
  　・パスワードが侵害された兆候がある場合は、速やかにパスワードを変更する
  

• パスワードの変更
  　以下のように不正にパスワードを利用される恐れがある場合には、速やかにパスワードを変更することを利用者に周知することが必要です。
  　・インシデントの発生によりパスワードが侵害された恐れがある
  　・共有アカウントを利用している自分以外の誰かが組織を離れた
  

２．パスワードの保管

　パスワードが攻撃者により容易に窃取されないように保護することを考慮した保管方法を定める必要があります。

• 平文パスワード保管の禁止
  　パスワードは、平文ではなく、アカウント毎にランダムに生成したソルトを連結し、ストレッチングにより得られたハッシュ値*1を保管します。
  　また、最終的に生成されたパスワードファイルだけではなく、ハッシュ化処理中のログなど全てのプロセスで平文が残っていないことを確認する必要があります。

• パスワードファイルとアプリケーションシステムのデータとの分離
  　アプリケーションシステム用のデータとは異なる領域に保管することにより、パスワードファイルの窃取はより困難になります。

３．パスワード登録・管理のための支援機能

　パスワード登録・管理を行うシステムには、以下のような利用者が強度の高いパスワードを選択できるような支援機能を備える必要があります。

• パスワードポリシーの強制機能
  　パスワードポリシーを満たさないパスワードの登録を拒否することで、利用者によるポリシー順守を支援します。

• レート制限によるロックアウト機能
  　例えば、同一アカウントへ一定回数以上の認証試行失敗が続いた場合、一定時間または解除するまでそのアカウントを用いた認証を受け付けないなどのレート制限によるロックアウト機能を設けることで、オンラインによる攻撃を防ぐ効果があります。

• パスワード利用禁止リストの参照機能
  　利用者が使用する傾向が高い文字列，攻撃者に類推され得る文字列，危殆化した文字列を含むパスワード利用禁止リスト（攻撃者に利用される可能性の高い文字列を集めたリスト）を作成し、パスワード登録時にその利用を拒否する機能を提供することにより、辞書、マスク、類推の各攻撃手法への耐性を高めることができます。
  　パスワード利用禁止リストは、以下の考え方に基づき外部情報を入手するなどにより最新に維持することが求められます。
  ・組織外のサイトを含む過去に流出した資格情報
  （アカウントとパスワードの組み合わせ）
  ・辞書攻撃用の辞書に含まれる文字列
  ・繰り返しまたは規則的な文字列 (例： aaaaaa，1234abcd）
  ・サービス名，ユーザ名などから推測可能な文字列
  　なお、上記リストに含める文字列は、パスワードポリシーによって定められている文字数以上のものに限定することにより、無駄な照会の機会を減らすことが可能です
  　追加機能として、資格情報の流出リスト更新の際に、組織内で登録されているアカウント情報と照会し、流出の可能性がある場合に当該アカウントの保有者に対しパスワード変更を促すことにより侵害の可能性を低くすることができます。

• ランダムに生成された文字列の利用促進機能
  　パスワードマネジャやブラウザのキーチェーン機能など、信頼できる乱数生成機能によりランダムに生成されたパスワードの利用を許可することにより、辞書、マスク、類推の各攻撃手法への耐性を高くすることができます。また、ランダムに生成されたパスワードを利用しやすいように、パスワード入力時にペースト機能の利用を許可するなどの考慮も必要です。

• パスワード強度メーターの表示機能
  　利用者が登録しようとしているパスワードの強度を表すパスワード強度メーターを表示することにより、利用者がより耐性のある文字列を選択しやすくなります。

• 登録時のパスワード入力値確認機能
  　通常、入力されたパスワードは覗き見を防止するためにドットやアスタリスクとして画面上に表示されることが多いため、利用者がパスワードを登録する際、自らが入力した内容を確認できないことによる入力誤りが発生し、その結果、利用者がパスワードを誤って記憶している可能性があります。
  　そこで、利用者が考えたパスワードが間違いなく入力されていることを確認できる機能（例えば、同じ文字列を２回入力させ比較する機能）を提供することでパスワードの記憶ミスを防ぐことができます。
  　また、パスワード登録の際に正しい入力を行うために、限られた時間内で（例えば、表示ボタン押下時のみ）入力したパスワードを表示できる機能を提供することを検討します。
  　その場合、入力した文字列が盗み見される可能性もあるため、アスタリスク表示により保護しつつ、盗み見される可能性が低い時など、パスワード文字表示のタイミングを利用者によりコントロールできるようにする必要があります。

• パスワードの再利用禁止機能
  　同アカウントに対するパスワード（実際にはハッシュ値）を数世代にわたり履歴保持し、再使用を禁止する機能を提供することにより、パスワード変更の本来の目的である「万が一、漏洩していた場合の補完管理策」が有効に機能します。

あまり効果がないとされている管理策

　以下の管理策は、最新のガイドラインでは効果が薄いと言われています。

• パスワードポリシーの複雑さ要件
  　パスワードの複雑さを利用者に強制すると、記憶との両立が難しいことを理由とする以下のような脆弱性を孕む可能性があります。
  　・推測可能な規則性を持ったものを登録する
  　・メモや暗号化されていないなどのセキュアではない方法により保管される
  

• パスワードの定期更新の強制
  　パスワードを定期的に更新することが分かっている場合、利用者は推測可能な規則性を持ったものを考える傾向があります。

• 「ヒント」や「秘密の質問」
  　類推攻撃のターゲットになり得る（例えば、「ペットの名前は？」などの質問はSNSなどにより到達可能な情報です）ため、「ヒント」や「秘密の質問」への回答を前提としたパスワード変更権限の付与は実施すべきではないとされています。

まとめ

　今回は、パスワードクラック手法と有効な管理策について考えてみました。どちらも時間の経過とともに変化するため、攻撃手法については、MITRE ATT&CKなどの確認による脅威インテリジェンスの維持、有効な管理策についてはMITRE ATT&CKやNISTなどのガイドラインで最新の情報を確認し、組織内のルールを見直す必要があります。
　また、各管理策（例えば、パスワードポリシーとパスワード支援・管理機能）は互いに関連するため、ルールを見直す場合は関連性を見極め総合的な見地で実施する必要があります。

参考資料

　本稿は、以下のサイト、文献を参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

• ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls

• NIST SP800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations IA-5

• NIST SP 800-63B Rev.3 Digital Identity Guidelines — Authentication and Lifecycle Management

脚注

*1:例えば、CRYPTREC暗号リスト（https://www.cryptrec.go.jp/）により危殆化していないことを確認したハッシュ関数により、コンピュータの処理性能・負荷の許容範囲内で繰り返し演算して得られた結果

「パスワードクラック手法」と「有効な管理策」について（前半）

はじめに

　FIDO2を代表とするパスワードレス認証の普及など、最近はパスワード以外の要素による認証が多く提供されているため、今更という感じがしますが、今でもパスワードのみで認証が行われている環境は存在しますし、最新のガイドラインでも認証技術の章でパスワードに関する記述の割合が多いため、ここでパスワードクラック*1と関連する管理策についてまとめておきます。

　本稿は文字数が多くなってしまったため、以下のように2部構成とします。

• 　前半）パスワードクラック手法について
• 　後半）パスワードクラックに有効な管理策について

　注）なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

「オンライン攻撃」と「オフライン攻撃」

　パスワードクラックは、攻撃対象であるパスワードファイルが、攻撃時にどこに存在するのかにより「オンライン攻撃」と「オフライン攻撃」に分けられます。

・オンライン攻撃

　稼働しているサーバーやサービスにネットワーク経由で直接アクセスし、アカウントとパスワードを入力し認証の成否を試す手法です。
　攻撃対象が防御側組織の管理下にあり、レート制限によるロックアウト*2を適用でき、それが有効な管理策として機能するため、後述する総当たり攻撃のように短時間で多くの試行回数を前提としている攻撃が成立する可能性は極めて低いと思われます。
　他方、類推攻撃、パスワードリスト攻撃のようにある程度パスワードの目星がついており少ない試行回数で攻撃する場合は、次に紹介するオフライン攻撃と違いパスワードファイルの事前入手が不要なため、あまり手間をかけることなく攻撃の成否を確認することができます。

・オフライン攻撃

　攻撃者が攻撃対象のハッシュ値（パスワードファイル）*3や暗号化されたファイルまたは媒体を事前に入手し、攻撃者側の環境でそのパスワードを解析する手法です。
　※）パスワードファイルを窃取する手法とその管理策についてはブログ "「資格情報」に関連する攻撃手法と管理策について" で紹介しています。
　攻撃対象となるファイルが攻撃者側の手元に存在し自らの環境下で試行が可能なため、回数・時間に関し制約が無くあらゆるパスワードクラック手法を試すことができます。
　オフライン攻撃は、理論的には時間制限なく試行を繰り返すことが可能ですが、攻撃者もパスワードクラックにより得られるであろう成果とそれに費やす解析用PCなどのリソースの占有時間を比較し、ビジネスとして成立することを重視します。それに対し防御側は、パスワードが解析されるまでの時間を少しでも多くかけさせる（採算性を低下させる）ことがセキュリティ管理策の主目的となるため、各組織で一定の強度を確保するためのパスワードポリシーが設定されています。

攻撃ツールの利用

　オフライン攻撃はツールを利用することにより、効率的（GPUに対応した高速処理）、効果的（パスワードに利用されやすい規則性に基づく文字列候補を優先し、確度を向上させる）な試行が可能になります。

図　ツールを利用したオフライン攻撃の実施例

　ツール自体は違法なものではないため、GitHubなどの以下サイトから入手することができます。
　https://hashcat.net/hashcat/
　https://github.com/hashcat/hashcat

　ツール全般にいえることですが、それをどのように使用するのかによって、善いものにも悪いものにもなります。

• 善：利用者が自分のパスワードを忘れた時にリカバリツールとして利用する
• 善：ペネトレーションテスターが対象組織内で保管しているパスワード群に脆弱なものが含まれていないかどうかを検査により確認する
• 悪：攻撃者が攻撃対象のパスワードをクラックするために悪用する

パスワードクラック手法

　以下に、パスワードクラックに用いられる主な攻撃手法を紹介しますが、各攻撃手法は明確に分類されるものではなく各手法の概念を理解することを目的としています。

図　各手法の関連性イメージ

　パスワードクラック手法は総当たり攻撃から、効率化や検知され難さを目的に進化しています。

１．総当たり攻撃（brute force attack）

　固定したアカウントに対し、考えられる全ての組合せを試すことによりパスワードを特定する手法で、通常は、オフライン攻撃時（時間・回数の制約を受けず攻撃が可能な環境）に使用されます。
　防御のためには、パスワードポリシーにより長い文字列を利用することが有効な管理策として機能します。

２．辞書攻撃（dictionary attack）

　辞書*4にある文字列や文字列を複数組み合わせたものを優先して試行することにより、総当たり攻撃よりも効率的にパスワードを特定しようとする手法です。
　辞書は有償または無償で配布されています。以下に入手先の例を挙げます。
　https://www.scrapmaker.com/data/wordlists/dictionaries/rockyou.txt
　https://github.com/mikejakobsen/dictionary-attack
　ここで紹介した辞書も前述の攻撃用ツール同様、防御側組織により利用されることがあります。例えば、利用者がパスワード登録する際に、辞書を参照し載っている文字列の使用を拒否することで脆弱なパスワードが登録されることを防ぐことができます。

３．マスク攻撃（mask attack）

　パスワードクラックツールで、特定の形式（一般的に使用されることの多いパスワードの規則性を満たす形式）の文字列を優先して使用することにより、少ない試行回数で効率的にパスワードを特定しようとする手法 です。
　一般的に、パスワード登録時に複雑さ要件（大文字、小文字、記号、数字を1文字以上含める）や定期的な変更を強制されると、利用者はその強制を満たしつつ規則性を持つ文字列をパスワードとして選ぶ傾向があると言われているため、その規則性を利用することにより効率的にパスワードクラックをしようとする考え方です。

　例）複雑さ要件と規則性の関係

• 大文字を含めることを強制された場合、1文字目に使用されることが多い 　Password
  
• 数字や記号を含めることを強制された場合、最終文字に使用されることが多い 　Passowrd1!
  
• ○○文字以上の長さを強制された場合、人名と年号の組合せが多い 　Suzuki@1998
  

４．レインボーテーブル攻撃（rainbow table）

　レインボーテーブルは、ある値とその値に対応するハッシュ値を集めたテーブルのことで、そのテーブルを事前に用意することによりハッシュ値からのパスワードの特定が効率化できるとの発想から使用されている手法です。実際には、平文とハッシュ値を1対1で対応させた単純なものではなく、処理を効率化するためハッシュ関数（平文⇒ハッシュ値）と還元関数（ハッシュ値⇒平文）を複数回繰り返した結果を集めたテーブルを利用します。
　パスワードからハッシュ値を計算する処理を省くことができ、その分、クラックに費やされる時間を短縮できるため使われていた手法ですが、近年は、主に以下を理由としてあまり使われなくなっているようです。

• 後述するソルト、ストレッチングの普及により、レインボーテーブルが適用できる機会が減った
• GPUに対応したツールの普及により、制約が少なく強力な処理が可能になっている

５．類推攻撃（password guessing attack）

　事前に攻撃対象に関する情報を収集し、そこから推測される文字列を優先して使用することにより、少ない試行回数で効率的にパスワードを特定しようとする手法 です。
　人は設定したパスワードを記憶しておくため、自分に関連する情報を含める傾向があります。また、勤務先、出身校、ペットの名前、生まれ年、誕生日、所有している車種、好きな有名人、メールアドレスなどの情報は、SNSなどを悪用し攻撃者が入手してしまう恐れがあります。
　上記内容から、どちらかというとソーシャルエンジニアリングの要素が強いとも言えます。
　なお、アカウントと関連性のある文字列は、パスワードクラック時に優先して試行される恐れが高い*5 ため、防御側の管理策として、利用者に注意を促したり、パスワード自動生成機能の利用により意味のない文字列を選択するなどの対応が必要となります。

６．逆総当たり攻撃（reverse brute force attack）

　総当たり攻撃とは逆に、固定したパスワードに対しアカウントを総当たりで入力しログインを試みる手法です。オンラインによる総当たり攻撃を防ぐためのレート制限（同一アカウントに対し設定した回数以上の認証試行失敗が発生した場合、そのアカウントをロックアウトする設定）を回避するために考えられました。
　オンラインによる逆総当たり攻撃を防ぐためには、レート制限に「同一IPアドレスからの一定回数以上の認証試行失敗が続いた場合」などの条件を追加する必要があります。

７．パスワードリスト攻撃（password list-based attack）

　攻撃者が別のサービスから入手したID・パスワードのリストでログインを試みる手口です。同じアカウントとパスワードを複数サイトで使い回している利用者の場合、一回の試行で不正ログインが成立してしまいます。同様の手法をロボットにより自動化したものをクレデンシャルスタッフィング攻撃（Credential Stuffing）と呼ぶことがあります。
　防御側としては、利用者に対しパスワードの使いまわしを禁止するよう注意を促す必要があります。特に、個人利用しているサイトと業務利用しているサイトのように管理が異なるドメインで同じパスワードを利用することの無いようにリスクの内容を含めしっかりと利用者が理解していることが大事です。

　また、不正に入手されダークWebで取引されているアカウント（メールアドレス）とパスワードのリストを公開しているサイトがあり、常に流出した情報が追加されています。（2022/08/14現在　119億件のアカウントが登録されています）
have i been pwned?
　このサイトで、自身が利用しているアカウントに関連するパスワードの流出有無を確認し、もし流出している場合（下図のように、”Oh no - pwned !” と表示されます）、速やかに対象のサイトまたはサービス（Breaches you were pwned in の下に流出対象のサイト情報が表示されます）に登録しているパスワードの変更はもちろん、同じアカウントとパスワードを他のサイトでも使いまわしている場合は、同様に、その全てのサイトでパスワードを変更する必要があります。

図　have i been pwned? によるパスワード流出有無の確認

８．パスワードスプレー攻撃（Password Spraying）

　IDやパスワードを固定せずに 少ない回数でゆっくり（low-and-slowと呼ばれます）連続的に攻撃することでレート制限の検知を回避しつつオンラインでの攻撃を可能にします。
　単純な設定で攻撃を検知することは難しく、UEBA（User and Entity Behavior Analytics ユーザとエンティティの行動分析）などの新しい技術の利用が必要になりますが、過検知の発生も考えられ、チューニングが難しいと思われます。

以下、後半部分（パスワードクラックに有効な管理策について）に続きます。

参考資料

　本稿は、以下のサイト、文献を参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

• ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls

• NIST SP800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations IA-5

• NIST SP 800-63B Rev.3 Digital Identity Guidelines — Authentication and Lifecycle Management

脚注

*1:自身のものではないアカウントに設定されているパスワードを特定する攻撃。特定したパスワードを使用することにより、当該アカウントの所有者になりすまし不正にログインすることなどが可能になる

*2:例えば、同一アカウントへの一定回数以上の認証試行失敗が続いた場合、一定時間または解除するまでそのアカウントを用いた認証を拒否する設定

*3:攻撃者がパスワードファイルにアクセスする可能性を考慮し、多層防御の観点から、通常はパスワードをハッシュ値に変換したものを保管します。もし、パスワードを平文で保管していた場合は、攻撃者にパスワードファイルを窃取されると直接パスワードそのものが攻撃者の手に渡ってしまうため、インシデントがより重いものになります。

*4:例えば、様々なサイトから漏洩したパスワードなど、パスワードとして利用される頻度の高い単語を集めたリスト

*5:アカウント名とパスワードに同じものが使用されているユーザアカウントは「ジョー（Joe） アカウント」と呼ばれており、攻撃者が最優先に試すとされているため、パスワードポリシーで登録を拒否することが一般的です。