監査証跡は事後ではなく事前に設計される

一言でいうと

誰が何をいつ行ったかは、事故のあとに探すものではなく、作業の前に残るようにしておくものであり、引き継ぎ文書は、その設計が次の人に受け継がれる通路です。

なぜ必要なのか

事故が起きたあとで「誰がこれを変えましたか」と尋ねる状況を考えてみましょう。答えが出る組織と出ない組織の違いは、調査能力ではありません。作業の前に何を残すようにしておいたかの違いです。残していないものは、どれだけうまく探しても出てきません。

統制された環境で、この設計は3つでできています。

承認。すべての作業に承認者がいなければなりません。承認欄が空だということは、承認を受けていないという意味ではなく、承認の有無を私たちが証明できないという意味です。監査では、2つは同じ扱いを受けます。

2人統制。実行者と承認者が別でなければなりません。これは人を信用できないからではなく、1人の思い違いがそのままシステムに反映される経路をなくすためです。自己承認は、その経路を復活させます。そして自己承認は、規定違反というより、設計の失敗のサインであることが多くあります。承認すべき人がその時間にいなかったという意味だからです。

作業ウィンドウ。承認を受けた時間の中で行わなければなりません。ウィンドウの外の作業は、見守る人も、問題が起きたときに元に戻す人もいない時間に行われたものです。ウィンドウを守ることは、形式ではなく、安全網を有効にしておくことです。

どう動くのか

この3つを事後に確認するときには、1つ注意が必要です。3つの違反の合計は、違反作業の数ではありません。

1つの作業が、2つを同時に破ることがあります。午前3時に1人で入ってきて、自己承認で処理した作業は、「自己承認」であると同時に「ウィンドウ外」です。3つの一覧の件数を単純に足すと、この作業が2回数えられます。報告書に「違反11件」と書くと、実際には9件なのに、2件をでっち上げたことになります。ない事故を作って報告することは、事故を漏らすことと同じくらい、信頼を失います。

そのため、作業識別子で和集合を作り、重複を除いた数を数えます。そして報告書には、3つの件数と、重複を除いた数を一緒に書きます。1つだけ書くと、読む側がまた尋ねてきます。

승인 없음     3건 ┐
자기 승인     3건 ├─ 단순 합계 11건
작업 창 밖    5건 ┘
                    실제 위반 작업 9건  ← 두 건이 두 가지를 동시에 어겼다

現場での姿

いつか常駐が終わります。その日、次の人が受け取るのは、ファイル数個と、私たちが頭の中にだけ置いていたもののすべての不在です。そのため、引き継ぎ文書は、エアギャップ環境で3つの点が違わなければなりません。

• リンクではなく手順。外の文書を開けないので、リンクは死んだ文字です。どこを見ろではなく、何をしろを書きます。
• 画面ではなくコマンド。画面キャプチャは持ち込みも持ち出しもできず、バージョンが変わると嘘になります。実際に打てるコマンドを書き、書く前に一度打ってみます。中では、間違ったコマンドを検索で直せません。
• 名前ではなく役割。「困ったら誰それに聞いてください」は、その人が出ていく日に一緒に消える情報です。役割で書けば、人が変わっても文書が生きています。

わかっている問題は、必ず引き継ぎます。すでに判断が終わった脆弱性の項目を引き継がなければ、次の人が同じアドバイザリを受けて、最初から調べ直します。緩和の状態と再評価の時点を一緒に引き継げば、その数日がなくなります。

引き継いだものが引き継いだままであるかを確認する手段を、一緒に渡します。成果物のハッシュ一覧を付け、受け取った側が最初にすることを、文書の冒頭に書きます。確認手段がなければ、それは引き継ぎではなく、ファイルの受け渡しです。

次のラボですること

夜間作業ログ14件から、承認なしで実行された作業、実行者と承認者が同じ作業、作業ウィンドウ外で実行された作業を、それぞれ見つけ出します。そして3つの一覧を合わせて、重複を除いた実際の違反作業数を数えます。単純な合計とは違います。最後に、リンクなしで、コマンドで、役割で書いた引き継ぎ手順書と、ハッシュマニフェストが付いた引き継ぎパッケージを完成させます。