そこそこボリューミーな内容でした。
自分のためにメモを残します。
あくまで、自分目線で自分の興味・関心に基づくメモです。
(この日付でこのメモを書いている筆者は、ご想像のとおり、かなりギリギリです（もう土日がない！）)

単元1 情報処理安全確保支援士に期待される役割と知識

サイバー・フィジカル・セキュリティ対策フレームワーク
Society5.0 における新たなサプライチェーン（バリュークリエイションプロセス）の信頼性の確保に向けて
https://www.meti.go.jp/press/2019/04/20190418002/20190418002-2.pdf
ISMAP 政府情報システム調達のためのセキュリティ評価制度。政府がクラウドサービスを調達する際の評価制度。リストも公開され、クラウドサービス選定の判断材料として活用できる。
https://www.ismap.go.jp/csm
脆弱性対策の効果的な進め方　ツール活用編
https://www.ipa.go.jp/topic/isec-technicalwatch-201902.html
情報共有のトライアングル（ジレンマ）
速さ、正確性、網羅性はいずれか２つしか満たせない
出典：[セキュリティ対応組織力を上げるコツ〜成熟度の可視化と、情報共有の心得〜]（https://www.jnsa.org/seminar/nsf/2018/data/NSF2018_B1.pdf）
The Pyramid ob pain
情報を６層のピラミッドに分類。上に行くほど「守る側の難易度も高いが攻撃側も手を変えにくい」このため、長期的な対策を考える。下に行くほど「守る側が対策しやすいが、攻撃側も手を変えやすい」、このため短期的な対策とする。
上から、TTPs、Tools、Netowrk／Host　Attacks、Domain　Names、IP　Address、Hash　Values

単元２　セキュア開発

設計と実装からセキュリティリスクを軽減する！

ソフトウェア設計段階の初期で、脅威モデリングを行う。
脅威を分析するとき、NIST　SP８００-３０ Rev.1を用いたリスクアセスメントが参考になる。
ソフトウェアの脅威を分類するための方法として、STRIDEがある（Microsoftが提唱）。
　S:なりすまし、T：データの改竄、R:拒否、I:情報の漏洩、D：サービス拒否、E:特権の昇格
脅威のランク付は、被害の程度、再現性、容易さ、被害者数などの尺度に対して大まかな評価（大中小など）を行なって総合的に評価する。
システムの要件定義の段階で、セキュリティはある程度は暗黙的に担保されるものとして要件に組み込まれることがあるが、それゆえ非機能要件となってしまうことがある。明示的に機能要件として組み込むべき。

DevSecOps

開発と運用が強調して利用者に安心・安全を含めた価値を届ける。
自動化された各種ツール（インフラ、情報共有などなど）、お互いを尊重し信頼する組織文化、セキュリティの観点が必要。

残存リスクの管理と許容した理由の把握

全てのリスク排除は非現実的=>資源や目的への悪影響を抑えつつリスク対策を実施=>もっともコストのかからない方法を選んで許容レベルまで対策（回避、移転、低減）し受容する。
そうして残ったのが「残存リスク」。コントロールできないクラウドサービスやAIとの連携も残存リスクとして認識する。
残存リスクを管理する。許容理由を関係者全体で確認・把握、許容できるレベルまで軽減されているか判断、責任者から受容の承認を得る、定期的に、また、変更時に見直し実施。

単元３　継続して実施していくセキュリティ対応

脆弱性情報の情報の公表日一致の原則

たまに、血気盛んな研究グループが脆弱性の研究結果を先走って公開して大騒ぎになるケースがある。（ただの感想）

「セキュリティは単に禁止することではない」

セキュリティを強化することは必ずしも利用の制限を行なったり、地道なチェックリストによる確認項目や回数を増やすことではない。
セキュリティを担保し、ビジネス価値を向上させる、危惧すべきリスクが守られているか確認できる　ことである。
禁止から活用へ！。CISSPにも共通する考え方ですね。

情報セキュリティ監査について

情報セキュリティ監査とシステム監査の違い
共通点は、リスクアセスメントに基づくコントロールの整備状況を、独立かつ客観的に評価して、状況に対して保証または助言を行う
相違点はセキュリティ監査は「情報資産」に対して、システム監査は「情報システム」を対象とする。
情報セキュリティ監査とは、企業などの情報セキュリティ対策が有効に実施されているかどうかを監査することである。
IIAの3ラインモデル
https://www.theiia.org/

単元４　様々な脅威への対応

脅威・脆弱性・リスクの定義

必ずしも情報システムに限ったものではない。

脅威は、システムや組織に損害を与える可能性がある、望ましくないインシデントの潜在的な原因。大きく分けて二つ。人為的脅威と環境的脅威に分けられる。
脆弱性は、一つ以上の脅威によって付け込まれるかの性のある、資産または管理策の弱点。具体的には製品やサービスにおけるセキュリティ上の弱点。開発体制や運営などの環境に起因した不備も該当する。
リスクは目的に対する不確かさの影響。悪い事象が発生する可能性。情報セキュリティリスクの場合はシステムやデータに損害を与える可能性を指す。

内部に潜む脅威

サプライチェーン、クラウド、テレワークなどが昨今は脅威が増した場所としては新しめか。
テレワークは人為的な脅威、内部不正の文脈もある。対策の観点としてゼロトラストにもつながる。
サプライチェーンは実際にトヨタの部品製造者の事例が記憶に新しい。Gitに不正なコードが混入するのもこれか。

脅威への対応サイクル

脅威への対応は、守るべきものを定めて、必要に応じたシステムを構築してアナリシスをする。平常時から継続した対応を行う。闇雲に製品を導入したり、事件が起きてから慌ててやるのではダメ。
シャドーITを生み出さない取り組みも必要。危険だが禁止にできないので、上手く付き合う。CASBなども有効。エンドポイントの監視やゼロトラストへの移行も有効（ネットワークを無条件で信頼しない）。

脅威への対応と対策

準備=>検知と分析=>封じ込め/根絶/復旧=>事件後の対応
インシデンとの対応サイクルだけでなく、脅威への対応サイクルを回す必要がある
経営視点での見直しも必要

単元５　倫理と法

倫理と法を学ぶ必要性。

RISSやCxxxxなどの資格について勉強したことがある人なら、必ずこのテーマについてカテゴリが一つあることをすでにご存知のはず。
ほぼ全ての有資格者が所属している組織は社会的に妥当な存在（倫理的存在）であるはず
現場において判断を求められたときに倫理的な判断を下すためには、根拠となる法律の知識が必要なのだ
特に「内部統制」「公益通報」に関する法律は、組織の倫理面に関する規定という位置付けで密接に結びついている。

倫理とは何か

法律以外にも、善悪や正邪の判断において根拠となる規範を一般的に「倫理」と呼んでいる。道徳、モラル。
倫理的な組織とはどういうことか、所属組織が社会的に求められる倫理とは何かを考えておくことは重要
業種ごとにも違うはず。医療や報道などでもそれぞれの分野であるはず。組織の形態（企業か団体か）などでも違うはず。
掲載されている事例のほかにも、ネット企業なら個人情報の提供など、法律を守っていても倫理的な説明を尽くさなかったために問題になった事例はたくさんある。

情報処理安全確保支援士の倫理感

五つの基本原則
組織の倫理と情報処理安全確保支援士の倫理が相反する例題。考え方や正解の例示はない。自分なりに考えるべし。

コンプライアンス

狭義のコンプライアンス　ー　法律を遵守。企業では法令や規則に従うことを「コンプライアンス」と整理。
広義のコンプライアンス　ー　法律だけでなく倫理や社会規範い従うこと。企業では「経営倫理」として整理。
コンプライアンスをベースに経営倫理の確立と実践を目指す経営を「コンプライアンス経営」という。
ソフトロー　ー　業界の自主規制や行政のガイドラインなど必ずしも法令となっていない。
ハードロー　ー　法令になっている。
内部統制。会社法、金融商品取引法。
公益通報者保護法
それ以外にも改正の動向などを抑えておくべき法律の一覧とポイントが紹介されている。転記になるので載せないが、要チェック。まとまっていてありがたい。

単元６　情報セキュリティ関連の標準やガイドライン

国内のガイドライン

Security Action1つ星　ー　中小企業自らが、情報セキュリティ対策に取組むことを自己宣言する制度
COSO Enterprise Risk Management　ー　リスクや事業機会に有効に対応し、価値を創造する事業体の能力を向上させることを目的としている

海外のガイドライン

こちらもまとまっていてありがたい。

COBIT2019 - Control OBjectives　for Information and related Technologyの略。IT統制に関するフレームワーク。米国ISACとITガバナンス協会が共同で発表。
ISO/IEC27001 - ISMSに関する国際規格。情報のCIAの３つをバランスよくマネジメントして情報を有効活用するための組織の枠組みが示されている。
ISO/IEC27002 - ISMSを実施するためのベストプラクティスをまとめた規格
ISO/IEC27017 - ISO/IEC27002にクラウドサービス固有の事項に関する指針を追加・補足。
NIST　CSF ー米NISTが発行したサイバーセキュリティリスクを把握、管理するためのフレームワーク。
　　- SP 800-63-3 Digital Identity Guidelines　リスクアセスメントの方法論など
　　　　- A　Enrollment and Identity Proofing
　　　　- B Authentication and Lifecycle Management
　　　　- C Federation and Assertions
　- SP 800-207 Zero Trust Architecture
NIS指令　ー　サイバーセキュリティに関するEU最初の指令。適切なセキュリティ対策（リスクの予防、ネットワークと情報システムのセキュリティ確保、インシデンとハンドリング）とインシデントの通報を義務としている。
EU　Cybersecurity　Act ー　EU共通のセキュリティレベルや認証制度の枠組みを規定する「EU　Cybersecurity Certification Framework」を含む。メタ言語を使う試みも。
PSIRT　ー　組織が提供する製品の脆弱性に起因するリスクに対応するための組織内機能。