レッドチーミングRed Teaming

守る目と突破する目は見え方が違います

作った人は自分が描いた流れに沿って確かめます。このボタンを押せばこうなり、この要求が来ればこう止まる、という順序どおりにです。ところが問題になる場所はたいてい、その順序の外にあります。誰もそう使うとは思わなかった使い方が通り道になります。

突破する側の目は順序を無視して見ます。ここからあそこへ飛んだらどうなるか、二つの機能を妙な順番でつなげたらどうなるか、とても長い会話の最後ではどうなるかを問います。同じシステムなのに、見えるものが変わります。

そのためレッドチーミングは、作った人が自分でする点検とは別に置きます。作った人も参加しますが、設計を知らない人や背景の異なる人が混ざってこそ、それぞれ違う穴が出てきます。

範囲を先に決めて始めます

始める前に合意しておくことがあります。どのシステムまでが対象か、実際のユーザーの資料に触れてよいか、どこまで確かめて止めるか、見つけた内容を誰にどう知らせるかです。家を見て回っても扉は壊さないのと同じです。

記録も一緒に決めます。何を試して、どんな条件で通ったのかを書き留めておかなければ、直す側が再現できません。たまたま一度通ったのか、安定して通るのかも何度か試してみないと分かりません。

この合意がなければ、点検が事故になります。範囲を書き留めることが、手続きの形式ではなく安全装置である理由です。

何を乗り越えてみるのか

乗り越えてみる場所はセキュリティ一つではありません。規則の外の答えが出るか、ユーザーや会社の情報が答えに混ざって出るか、確認されていない内容を自信満々に語るか、読み込んだ資料に隠れた指示をそのまま従うか、集団によって結果が分かれるか、持たせた道具を見当違いに使うかを合わせて見ます。

場所ごとに必要な人が違います。言葉の機微を見るには言語と文化を知る人が、道具の誤用を見るにはそのシステムを知る人が必要です。一つのチームだけでは全部を見られないので、複数の背景を混ぜます。

人が手で行う方式と、たくさんの試みを自動で作って回す方式を合わせて使います。自動のほうは広く洗い出し、人のほうは自動では思いつかない角度を探します。

結果は直す一覧です

点検が終わって出てくるのは、突破できた事例の集まりです。ここで大事なのは個数ではなく種類です。似た事例が百個出るより、違う種類が十個出るほうが広く見た点検です。

各事例は直す側へ渡されます。あるものは検査規則へ、あるものは学習資料へ、あるものは機能をそもそも外す判断へつながります。直した事例は次の点検でもう一度確かめる一覧に入ります。一か所ふさいだ場所が、別のところを直しているうちにまた開いてしまうことがよくあるからです。

一度では終わりません

モデルを入れ替えたり、新しい機能を付けたり、参照する資料を変えたりすると、前の点検の結論はもう一度確かめる必要があります。家を一度手入れしたからといって、翌年も見て回らなくていいわけではないのと同じです。

そして何度回っても全部を確かめきることはできません。点検の目標は穴をゼロにすることではなく、どれくらいの危険が残っているかを知ったうえで世に出すことです。知らずに出すことと知って出すことは、まったく違う状態です。