【要点抽出】NIST SP800-53 rev.5, 53B その3

今回は以下目次の4つの管理策ファミリーを読みます。

https://www.ipa.go.jp/security/reports/oversea/nist/about.html

意識向上およびトレーニング(AT)ファミリー

このファミリーに属する管理策は15個と少ないです。
子レベルの管理策は以下です。(グレー字は撤回された管理策)

表1.ATファミリーの管理策

「低」レベルのベースラインとして、全てのシステムユーザに対するトレーニング(AT-2)と職員の役割に応じたトレーニング(AT-3)の実施、および実施状況を記録(AT-4)することを求めています。
トレーニングには以下の種類があり、一部がベースラインとして選ばれています。

  • インシデントをシミュレートする実践的な演習

  • インサイダー脅威の潜在的な兆候(低レベルのベースライン)

  • ソーシャルエンジニアリング(中レベルのベースライン)

  • 不審な通信および不審な動作を認識する

  • APT攻撃

  • サイバー脅威環境

  • 環境面の対策状況(火災検知など)

  • 物理セキュリティの対策状況(入退室管理など)

  • 個人情報の取り扱いに関する対策状況


監査および説明責任(AU)ファミリー

このファミリーには56個の管理策が属します。
ここではログの取得・保護・分析・共有について述べています。
子レベルの管理策は以下です。(グレー字は撤回された管理策)

表2.AUファミリーの管理策

「低」レベルのベースラインとして、まず、どんなシステムであっても必ずログは必要です(AU-2)。
ログにはイベントのタイプ・日時・場所・発生源・結果・関連するアイデンティティの情報を含み、また複数のログの間で時間的な整合が取れるようタイムスタンプを生成する必要があります(AU-3、AU-8)。
取得したログは不正な変更から保護し、必要な期間保持します(AU-9、AU-11)。
そして、ログは取るだけでなく、そこから不審な兆候がないか分析することも重要です(AU-6)。

「中」レベルのベースラインは、上記に加えて徐々にログを使い倒すための記載が増えます。例えば、ログ分析の自動化や相関分析を行ったり、検索やソートができるようにすることが求められます。
また、ログの保護だけでなく、システムのログ取得機能そのものもアクセス制限をかけることで、悪意を持つものによるログ取得の停止ができないようにすることも求めています。

「高」レベルのベースラインは、ログとその他の情報の統合が強調されています。例えば、脆弱性スキャン情報、パフォーマンスデータ、システム監視情報、物理アクセスログ等との統合により、多くの気づきが得られます。
また、ログを確実に取得および保護できるように、ログ保存先の容量不足や障害に気づけるアラートの設定や、物理的に異なる場所への保存ハッシュ関数を用いた完全性の保護策が挙げられています。

その他、ベースラインに含まれていない管理策にも重要なものが多く、
WORMメディアに書き込む、監査対象のシステムとは異なるOSのシステムにログを保存する、ログフォーマットを標準化する、等が挙げられています。


アセスメント、認可、および監視(CA)ファミリー

このファミリーには25個の管理策が属します。
子レベルの管理策は以下です。(グレー字は撤回された管理策)

表3.CAファミリーの管理策

「アセスメント」とは、対象のシステムが必要な管理策を実装できているかチェックすることです。
「認可」とは、英語版ではAuthorizationと表記されており、システムが運用開始して良いか責任者がGoサインを出すことです。
「監視」とは、システムのリスクマネジメントに影響するあらゆる事象の監視を含み、これまでに出たAC-2g「アカウントの使用を監視」とかAC-2(7)「特権アカウントの監視」など幅広く含みます。

「低」レベルのベースラインとして、アセスメントを計画・実施し、発見された指摘事項の是正計画を立てて管理することで継続的な改善を行います(CA-2、CA-5)。
認可責任者を決めて、システムの運用開始や他システムとの接続を認可します(CA-6、CA-9)。
対象システムの重要度に応じたサイクルで継続的に監視を行い、分析します。(CA-7)

「中」レベルのベースラインは、アセスメント実施時に独立性を加えることを求めています。システムのオーナーや担当者自身がアセスメントするのではなく、独立した立場の人に見てもらってこそ意味があります。

「高」レベルのベースラインは、侵入テスト(ペネトレテスト)の実施が求められます。

その他、ベースラインに含まれていない管理策としては、認可を複数人数で行う「共同認可」を行うことでより独立性を高めるものや、レッドチーム演習、施設への物理的な侵入テストが挙げられています。


構成管理(CM)ファミリー

このファミリーには56個の管理策が属します。
子レベルの管理策は以下です。(グレー字は撤回された管理策)

表4.CMファミリーの管理策

「低」レベルのベースラインには、「ベースライン構成」「構成設定」「システムコンポーネントのインベントリ」という若干似た言葉が登場します。
どれも構成情報が並んだリストという面では同じですが、以下の違いと捉えています。

  • ベースライン構成:その組織が定める「ウチが作るシステムは必ずこんな構成を基本とすること」リスト(CM-2)

  • 構成設定:OSやアプリケーション等の細かい設定レベルでの「ウチが作るシステムのコンポーネントは必ずこんな設定をすること」リスト。つまり構成設定はベースライン構成の一部(CM-6)

  • システムコンポーネントのインベントリ:組織が管理する全てのシステムについて、それぞれのシステムを構成するハードウェアやソフトウェアやネットワークの構成情報の一覧。「各システムこんな構成になりました」リスト(CM-8)

「ベースライン構成」や「構成設定」は今後新規に作るシステム(既存システムも含むが)をターゲットにしており、「システムコンポーネントのインベントリ」は既存システムをターゲットにしている。
あるいは、前者2つはルールであり、後者は実態である。とも言えます。

その構成をセキュアに保つための基礎的な考え方が「最小機能性」であり、余計な機能は使わないこと、危険なプロトコルやソフトウェアは使わせないことが求められます(CM-7)。
また、構成管理は、構成情報を整理したら終わりではなく、システム開発や運用により日々構成が変化します。許可のない変更が行われないようアクセス制限を行ったり(CM-5)、変更前にインパクト分析を行ったり(CM-4)することも重要です。
加えて、ライセンス違反にならないようにソフトウェアの使用状況を把握し、P2Pソフト等による不正な複製を行わせないことも構成管理の中で求められます(CM-10)。

「中」レベルのベースラインは、構成管理の計画の作成(CM-9)や、構成変更管理のプロセスを回すこと(CM-3)が加わり、「低」レベルの構成管理をより計画的に・組織的に実行することが求められます。
また、「情報の位置」というタイトルで、どんな情報がどのシステムで処理や保存されているのか把握することも求められます(CM-12)。
そして、ベースライン構成や認められていないコンポーネントの検知を自動化し、構成変更前後のテストや最小機能の定期的なレビューを行うなど、適切な構成の状態を継続的に維持するための管理策が増えます。

「高」レベルのベースラインは、「中」レベルに加えて自動化が強調されています。
具体的には、構成変更管理、変更に対するアクセス制限、構成設定、システムコンポーネントのインベントリに対する自動化に言及しています。
また、インベントリ情報の各コンポ―ネントに対して説明責任を負う個人を定めることも求められます。

その他、ベースラインに含まれていない管理策としては以下のようなものがあります。(一部抜粋)

  • 本番環境と開発環境のベースライン構成は分ける

  • ベースライン構成が認可されずに変更されたら自動的なアクションを発動する

  • 保証のない、あるいはソースコードのないプログラムを実行する時は仮想マシン等の制限された環境とする

  • システム開発に直接関与しない組織の職員に、構成管理プロセスを策定させる


***NIST SP800-53シリーズのリンク***

  1. NIST SP800-53の読み方:こちら

  2. 管理策の概観、ACファミリー:こちら

  3. AT、AU、CA、CMファミリー:こちら(この記事)

  4. CP、IA、IRファミリー:こちら

  5. MA、MP、PEファミリー:こちら

  6. PL、PM、PS、PTファミリー:こちら

  7. RA、SAファミリー:こちら

  8. SCファミリー:こちら

  9. SI、SRファミリー:こちら

***はじめての方へ***
これは何のnoteだ?と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら

この記事が気に入ったらサポートをしてみませんか?