【要点抽出】NIST SP800-53 rev.5, 53B その7
今回は以下目次の2つの管理策ファミリーを読みます。
リスクアセスメント（RA）ファミリー
このファミリーには22個の管理策が属します。
ここではリスクの特定・分析・評価といった一連の流れだけでなく、脆弱性のスキャンや脅威ハンティングにも触れます。
子レベルの管理策は以下です。(グレー字は撤回された管理策）
「低」レベルのベースラインとして、侵害された場合の影響の大きさをもとにシステムや扱われる情報を分類します（RA-2）。そしてリスクアセスメントを通じて対象システムあるいはサプライチェーンに対するリスクを特定・分析・評価します（RA-3、RA-3(1)）。
「リスクの特定」とは、つまり脅威や脆弱性を特定することです。
「低」レベルでは脅威の特定への言及はありませんが、脆弱性の特定については、システムを構成するコンポーネントに対してネットワークのポートの確認、インフラ部分の脆弱性スキャン、アプリケーションの評価（コードレビューや動的分析など様々）を行うことを求めています。発見した脆弱性は評価し、修正し、他のシステムにも情報共有して類似の問題を防ぎます（RA-5)。
また、脆弱性の報告窓口を一般向けに設けることも必要です（RA-5(11)）。
こうして洗い出され評価されたリスクについては、低減・回避・受容・移転のいずれかの対応を行います（RA-7）。
「中」レベルのベースラインとして、メリハリをつけた保護を行うためにシステムの重要度分析を行います（RA-9）。
また、「低」で挙げた脆弱性スキャンについて、対象システムが個人情報や機密情報を扱う場合などに「特権アクセス」することで徹底したスキャンを行います（多分クレデンシャルスキャンのことと推測）（RA-5(5)）。
「高」レベルのベースラインとして、外部から見つけられる情報を極力減らすこと（ハニーポットなどの囮は除く）を求めています（RA-5(4)）。
その他、ベースラインに選ばれていないものは、「技術監視対策調査」の実施（RA-6）、システムでどのように個人情報が扱われ、どのようなプライバシーリスクに繋がるか特定し、リスクの軽減策を決める「プライバシー影響評価」をシステムのライフサイクル全般で実施すること（RA-8）、脅威ハンティングの実施（RA-10）が挙げられます。
「技術監視対策調査」が何かは明確ではありませんが、英語文の説明を読む限り、施設に対する物理的なペネトレテストのようにも見えました。
システムおよびサービスの取得（SA）ファミリー
このファミリーには106個の管理策が属します。
ここではシステムの開発ライフサイクルや外部からの取得時に検討すべき管理策が挙げられています。
CSSLPの学習領域と重複するものが多いです。
子レベルの管理策は以下です。(グレー字は撤回された管理策）
「低」レベルのベースラインとして、システムのセキュリティやプライバシー要件を定め、その実現に必要なリソースを確保します（SA-2)。
開発ライフサイクルにリスクマネジメントを統合し、プライバシーの保護やセキュアなシステム作りを行います（SA-3）。
この際、「最小権限」などの原則的な考え方を適用します（SA-8）。
開発または取得したシステムについては、セキュアに使うための情報が記載された管理者向けドキュメントとユーザ向けドキュメントを作成・入手します（SA-5)。
管理者ドキュメントには、例えばセキュアな構成、インストール、既知の脆弱性、管理機能や特権についての説明が記されます。
ユーザ向けドキュメントには、例えばセキュリティやプライバシーを保護するためにユーザが気を付けるべき操作方法や、ユーザの責任が記されます。
システムで用いるコンポーネントがサポート切れになった場合はバージョンアップや乗換を行います。それができない場合は個別の延長保守契約を締結する等のリスク低減策が必要です（SA-22）。
また、システムを外部から取得する場合、求めるセキュリティ要件を明記した上で契約を締結し（SA-4)、提供元が遵守することを要求・監視します（SA-9)。
「中」レベルのベースラインとして、「低」レベルでないのが意外ですが、開発者に対して開発プロセスや組織が定めたツールの利用に従うことを求めます（SA-15)。
システム開発においては構成管理を行います（SA-10）。管理すべきアイテムには、プログラムやライブラリだけでなく、ドキュメント類やソースコードも含まれます。
システムの設計後には、適切に要件が実装されたことをアセスメントし、検出された欠陥を是正します（SA-11）。アセスメントとは、アーキテクチャのレビュー、コードレビュー、侵入テストなどです。
また、開発者には実装する管理策の機能や設計についての説明を求めたり（SA-4(1)、SA-4(1)）、開発あるいは外部から取得するシステムで何の機能、ポート、プロトコルが用いられているのかを特定します（SA-4(9)、SA-9(2)）。これを特定しておくことで、最小権限の設計に寄与したり、一部のポートをブロックする際の影響を理解できます。
「高」レベルのベースラインとして、組織が定めるセキュリティ構成に沿った設計を求めます（SA-4(5)）。ここで言うセキュリティ構成とは認められたポートやプロトコルを使うようなものもありますし、デフォルトのパスワードを変更させることも含みます。
そして、開発したシステムを正しく使用するためのトレーニングの提供を開発者に求めます（SA-16）。
また、このベースラインには過去に出た管理策と似たものが登場します。
セキュリティおよびプライバシーのアーキテクチャを作成させる管理策（SA-17）は、PL-8でも触れましたが、こちらは外部の開発者を対象、PL-8は内部の開発者を対象としています。
開発者のスクリーニングを行う管理策（SA-21)は、PS-3でも触れましたが、こちらは外部の開発者を対象、PS-3は内部の開発者を対象としています。
それぞれ何故分けたのかは不明です。
その他、ベースラインに選ばれていないものは85個もあります。
このうち33個がSA-8の設計原則を具体化したものです(SA-8(1)～SA-8(33)）。
この中には「最小共通メカニズム」「共有の最小化」「複雑さの軽減」「最小特権」といった分かりやすいものから、「半順序の依存関係」「逆変更しきい値」といった意味不明なものまであります。後者は詳細説明を読んでも理解できないものもありました。
余談ですが、この原則部分はIPAの翻訳にも誤字脱字が多かったり、
セキュリティメカニズムがもどかしいか、または使用するのが難しい場合、ユーザはそれらを無効にするか、回避するか、またはメカニズムが満たすように設計されたセキュリティ要件および保護ニーズと矛盾する方法で使用しても良い。
といった誤訳があったり（原文はthen users may disable themなのでユーザが回避しちゃうかもしれない と言いたいはず）、翻訳者もかなり骨を折ったであろう様子が伺えます。
以下、SA-8以外で代表的な管理策をピックアップします。
テストや開発時には本番データを使わずテストデータを使う（SA-3(2)）
外部からシステムを取得する場合は、データオーナーを契約に盛り込み、システムからデータを削除できるようにする（SA-4(12)）
外部からシステムを取得する場合は、外部企業のスタッフが暗号データを復号できないように、暗号鍵を排他的に管理する（SA-9(6)）
開発したシステムに対し、改ざんされていないことを確認できるような仕組み（ハッシュ値等）を提供する（SA-10(1)）
開発したシステムの脆弱性を発見するために、脅威モデリング、アタックサーフェス分析、ツール診断(SAST、IAST、DAST）、手動コードレビュー、侵入テストを行う（SA-11(1)、SA-11(2)、SA-11(4)、SA-11(5)、SA-11(6)、SA-11(8)、SA-11(9)）
開発したシステムに対し、独立したエージェントによるアセスメントを実施する（SA-11(3)）
＊＊＊NIST SP800-53シリーズのリンク＊＊＊
NIST SP800-53の読み方：こちら
管理策の概観、ACファミリー：こちら
AT、AU、CA、CMファミリー：こちら
CP、IA、IRファミリー：こちら
MA、MP、PEファミリー：こちら
PL、PM、PS、PTファミリー：こちら
RA、SAファミリー：こちら(この記事)
SCファミリー：こちら
SI、SRファミリー：こちら
＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら
この記事が気に入ったらサポートをしてみませんか？