監査は「何をしたか」ではなく「それをどう示すか」を問う

一言でいうと

監査対応で実際に引っかかるのは、やっていないことではなく、やったことと、それを証明するファイルがつながっていない状態です。要求1行ごとに、どのファイルのどの部分が根拠なのかをあらかじめ結んでおくこと(証拠索引)が対応の本体であり、その索引は、根拠ファイルのハッシュまで抱えていてはじめて、あとで自分自身が嘘をつかなくなります。

なぜ必要なのか

納品後の最初の監査で、最もよくある場面はこうです。要求事項を1行読み上げて、根拠を尋ねます。担当者は「それはやっています」と答えます。すると、どこで見られるのかという質問が返ってきて、そこからサーバーに入って設定を開き、ログを漁り始めます。20分が過ぎると、その項目は飛ばされ、記録には根拠未提出として残ります。やったことがなかったからではなく、やったこととファイルの間の道を、誰もあらかじめ敷いておかなかったからです。

この道を敷く作業は、監査の前日にはできません。根拠は、時間が経つと変わるからです。設定ファイルは次の変更で上書きされ、ログはローテーションで消え、点検結果は次の点検が上書きします。そのため、索引は、パスだけを書いても役に立たず、そのときそのファイルが何だったかを一緒に固定しなければなりません。そこにハッシュが入ります。ファイルが変われば、索引が自らそれを現し、現れれば、再収集すればよいのです。現れないことが問題です。

公開標準も、同じ構造を前提にしています。NIST SP 800-171 Rev 3は、協力会社が扱う資料に対する保護要求をファミリーにまとめていて、NIST SP 800-53 Rev 5は、はるかに広い統制の一覧と、その選び方を定めています。どちらでも、文書が定めるのは「何を満たさなければならないか」であり、「それをどのファイルで示せ」ではありません。その間をつなぐ表は、各現場が自分で作らなければならず、作らなければ、毎回人の記憶で埋め合わせることになります。ログを根拠に使うとき何を管理しなければならないかは、NIST SP 800-92が別に扱っています。

どう動くのか

1つ目に、根拠が自分で説明するようにします。どのファイルがどの要求の根拠なのかを、人の頭の中や別のExcelに置くと、すぐにずれます。根拠ファイル自体にヘッダーを付けて、自分が何を覆うのかを書かせれば、索引作りは、ディレクトリを走査する作業になります。形式がばらばらなのは避けられません。設定ファイルにはコメント行で、点検結果のJSONには最上位のキーで付きます。読む側が両方の場合を扱えばよいのです。

2つ目に、ハッシュを索引に入れます。パスと収集時刻だけでは、「今のそのファイル」を指すだけです。ハッシュを入れた瞬間に、索引はそのときのそのファイルを指すようになり、検証器が3つを数えられるようになります。存在しないファイルを指す項目、ハッシュがずれた項目、根拠が1つもない要求事項。3つの数字が、対応の状態を要約します。

3つ目に、根拠の強さを分けます。設定ファイルとポリシー文書は、「そうなっている」を示します。ログと点検結果は、「実際にそう動いた」を示します。2つは代替になりません。アクセス制限を設定に書いておいたという事実は、その設定が実際に適用されて動作したことを教えてくれず、反対に、ログだけでは、それが意図したルールなのか偶然なのかがわかりません。要求事項ごとに、どちらが必要かを決めておけば、根拠があるのに足りない場所が現れます。その場所が、次の四半期のやることです。

4つ目に、収集をもう一度回してみます。同じスクリプトをもう一度回したとき、収集時刻以外は同じ索引が出なければなりません。出なければ、その索引に、順序や時刻のように判定と無関係なものが混ざっているという意味で、そうなると、2回の結果を比べられません。比べられないデータは、次の四半期に何が変わったかも教えてくれません。

5つ目に、出すときに再審査します。根拠ファイルは内部用に集めたものなので、そのまま出してはいけないものが混ざっています。内部アドレス、認証手段、個人の連絡先のようなものです。伏せると、ファイルの内容が変わるので、ハッシュも変わります。ここでよく起きる事故が、伏せた複製を入れて、索引は元のハッシュのまま出してしまうことです。受け取る側で検証すると、すべてハッシュ不一致として出て、そのパッケージは、まるごと疑われます。伏せた複製には、伏せた複製のハッシュを付けなければなりません。

現場での姿

ある現場で、前四半期に提出した索引をそのまま再提出しようとして、立ち止まったことがあります。そのまま検証してみると、4項目が途切れていました。2つは、ファイルが整理作業の途中でなくなったもので、2つは、内容が変わったものでした。変わったほうが、より悪い状況でした。ファイルはその場所にあるので、人の目には問題なく見えるのに、内容は、そのとき根拠にしたものではありませんでした。ハッシュがなければ、そのまま提出していたはずで、監査が開いて見た内容は、私たちが説明したものと違っていたでしょう。

もう1つよく見るのは、根拠があるのに足りない場所です。インシデント対応手順書はよく書かれているのに、実際に訓練したり対応したりした記録が1つもない場合が代表的です。索引だけを見ると、根拠が1件付いていて緑色ですが、要求が尋ねているのは、手順の存在ではなく、その手順が回っているという事実です。根拠を強さで分けておけば、こうした場所が一覧として出て、その一覧が、次の四半期の計画になります。

次のラボですること

合成要求事項12件と根拠ファイル14個で証拠索引を作り、ハッシュを固定し、索引検証器で途切れた箇所を3種類数えます。根拠を設計と運用に分けて、要求ごとに何が足りないかを判定し、同じ収集をもう一度回して、収集時刻以外は同じかを確認します。最後に、持ち出し審査のルールで伏せた複製を作り、伏せた複製のハッシュで索引を封印し直して、検証器がそのパッケージだけを見て、途切れた箇所がないと言うようにします。残った空白は隠さず、目次にそのまま書きます。