要求一行とファイル一か所をつなぐ表を作る

目標

要求事項ごとに、どのファイルが根拠なのかを結んだ証拠索引を作り、ハッシュで封印し、検証器で途切れた箇所を数え、持ち出し審査を経た複製で、監査対応パッケージを閉じます。

なぜ重要なのか

監査で落ちる項目は、たいてい、やっていないことではなく、見せられなかったことです。要求1行とファイル1か所の間に道が敷かれていなければ、その場で答えられず、答えられなかった項目は、やっていないことと同じように記録されます。その道は、監査の前日には敷けません。根拠ファイルは、時間が経つと上書きされ、消えるからです。そのため、索引にはパスだけでなく、そのときそのファイルのハッシュが入り、出すときに値を伏せると、ハッシュも一緒に変わります。このラボで難しい部分は、ルールではなく、この一貫性です。

ステップ

python3で/root/audit/dataに、要求事項・根拠ファイル14個・ポリシー・前回の索引を作ります。生成スクリプトをそのまま使ってください。
根拠ファイルのヘッダーを読んで、要求ごとの根拠一覧を/root/audit/index.jsonに書きます。
根拠ごとにSHA-256を付けて、/root/audit/index-sealed.jsonとして封印します。
前回の点検で出した/root/audit/data/snapshot.jsonを検証して、結果を/root/audit/verify.jsonに書きます。
根拠を設計と運用に分けて、要求ごとの判定を/root/audit/strength.csvに書きます。
同じ収集をもう一度回して/root/audit/index-rerun.jsonを作り、決定性を/root/audit/determinism.jsonに書きます。
持ち出し審査のルールで伏せた複製を/root/audit/submit/evidence/に作り、/root/audit/redaction.csvを残します。
伏せた複製のハッシュで/root/audit/submit/index.jsonを封印し、/root/audit/submit/verify.jsonと/root/audit/submit/INDEX.mdでパッケージを閉じます。

参考

基準日は/root/audit/data/asof.txtにあります。dateで今日を使うと、同じデータから日ごとに違う答えが出ます。
根拠ファイルのヘッダーは、2種類の形式です。.jsonは最上位のキー(evidence_id・covers・kind・collected_at)に、それ以外は、先頭のコメント行(# evidence-id:のように)に入っています。
索引のpathは、/root/audit基準の相対パスです。パッケージの中の索引だけが、/root/audit/submit基準です。
根拠の強さの区分と、持ち出し審査のルールは、/root/audit/data/policy.jsonにあります。ルールをコードに埋め込まず、そのファイルから読んでください。
ステップ6の標準形は、索引からgenerated_atを除いたあと、json.dumps(..., ensure_ascii=False, sort_keys=True, separators=(",", ":"))した文字列のSHA-256です。
よくある間違い1: ステップ7で元の根拠ファイルを直してしまうことです。伏せるのは複製でなければならず、元はそのまま残っていなければなりません。
よくある間違い2: ステップ8で元のハッシュをそのまま移してしまうことです。伏せた複製には、伏せた複製のハッシュを付けてはじめて、受け取る側の検証が通ります。
標準文書: NIST SP 800-171 Rev 3、NIST SP 800-53 Rev 5、NIST SP 800-92。このラボのREQ番号とRED番号は、標準の統制番号ではなく、データの中でだけ使う合成番号です。

要求事項と根拠ファイルを作る

python3で/root/audit/dataにrequirements.json・policy.json・snapshot.json・asof.txtと、evidence/の下の根拠ファイル14個を作ります。乱数を使わない生成スクリプトをそのまま使ってください。

エアギャップ環境にはダウンロードできるサンプルがないので、まずデータを自分で作ります。乱数を使わないからこそ、誰が何回回しても同じデータが出て、互いの判定を突き合わせられます。採点ツールは、データを標準形に変えてフィンガープリントを突き合わせるので、データを手で直すと、後のステップがすべて止まります。

要求ごとに根拠をつなぐ索引を作る

/root/audit/index.jsonにgenerated_at・asof・entriesの3つのキーを置き、entriesは、要求idごとに根拠項目の一覧(evidence_id・path・kind・collected_at)を入れます。根拠がない要求も、空の一覧で入れてください。

根拠ファイルが、自分がどの要求を覆うかをヘッダーに書いています。ディレクトリを走査してヘッダーを読み、逆さにすれば索引になります。形式が2つあることを忘れないでください。項目は根拠idの順にソートし、pathは/root/audit基準の相対パスで書きます。

根拠のハッシュを索引に固定する

/root/audit/index-sealed.jsonに、索引をそのまま移しつつ、根拠項目ごとにsha256を加えます。generated_atは、ステップ2の索引の値をそのままにします。

封印は、再収集ではなく、今の索引にフィンガープリントを加える作業です。そのため、収集時刻は変わってはいけません。ハッシュは、ファイル全体のバイトに対するSHA-256を、小文字の16進数で書きます。

前回の点検で出した索引を検証器にかけてみる

/root/audit/verify.jsonに、/root/audit/data/snapshot.jsonを検証した結果を書きます。missing_file・hash_mismatch・uncoveredの3つのキーに、それぞれcountと一覧(evidence_idsまたはreq_ids)を入れてください。

3つは、それぞれ別の故障です。指しているファイルがないもの、ファイルはあるのにハッシュがずれたもの、そして根拠項目が1つもない要求事項です。3つ目は、索引がその要求をそもそも書いていない場合まで数える必要があるので、要求一覧の側から回らなければなりません。項目が1つあるのに、それが途切れた要求は、根拠なしではありません。

根拠の強さを分けて足りない場所を探す

/root/audit/strength.csvに先頭行req_id,needs,has_design,has_operational,verdictを置き、要求12件を1行ずつ書きます。needsは설계または설계+운영、保有の有無は예/아니오、判定は충족・설계근거없음・운영근거없음・근거없음のいずれかです(韓国語で順に「設計」「設計と運用」、「はい」「いいえ」、「充足」「設計根拠なし」「運用根拠なし」「根拠なし」を意味する語です)。

設定とポリシー文書は「そうなっている」を示し、ログと点検結果は「実際にそう動いた」を示します。どの種類がどちらかは、ポリシーファイルにあります。根拠がそもそもなければ、根拠なしが先で、そのあと、必要な側が空かどうかを、設計から見ます。

再収集しても同じ索引が出るかを見る

同じ方法で/root/audit/index-rerun.jsonを新しく作り、/root/audit/determinism.jsonに、generated_at_differs・normalized_sha256_first・normalized_sha256_second・same_without_timeの4つのキーを書きます。

2つの索引から、収集時刻だけを除いて、標準形にシリアライズし、ハッシュを比べます。2つのハッシュが同じであってはじめて、この収集は決定的です。逆に、収集時刻は違っていなければ、もう一度回したことにならないので、時刻はマイクロ秒まで書いてください。

持ち出し審査で伏せた複製を作る

ポリシーの審査ルールを、ルール番号順に適用して、根拠14個の複製を/root/audit/submit/evidence/の下に同じ相対パスで作り、ルールに引っかかったファイルだけを/root/audit/redaction.csvにevidence_id,rules,hits,sha256_afterで書きます。

引っかかるものがないファイルも、複製は作らなければ、パッケージが完成しません。rulesは、引っかかったルール番号をプラスでつないで書き、hitsは、変えた場所の総数です。sha256_afterは、伏せた複製のハッシュです。元には手を付けないでください。

パッケージを閉じて検証器で自分で確認する

/root/audit/submit/index.jsonを伏せた複製を基準に封印し(パスは/root/audit/submit基準)、同じ検証器を回した結果を/root/audit/submit/verify.jsonに、要求ごとの根拠数と判定を表にまとめた目次を/root/audit/submit/INDEX.mdに残してください。

パッケージの中の索引は、伏せた複製のハッシュを使ってはじめて、受け取る側の検証が通ります。存在しないファイルとハッシュ不一致は0になりますが、根拠がそもそもない要求は、そのまま残ります。その空白は隠さず、目次に判定として書いてください。目次の表は、要求id、根拠数、ステップ5の判定の3つの欄です。