あなたの DLP が 3 か月目に切られる理由

このパターンはカレンダーに予定を入れられるほど規則的です。1 か月目、プロジェクトに目に見える成果が必要でポリシーをブロックモードにする。2 か月目、経理が毎月送っているファイルを送れなくなる。3 か月目、権限のある誰かが「とりあえず切っておいて」と言い、二度と入らない。

故障モードは過剰ブロックであって、過少ブロックではない

流出経路を一つ見逃す DLP は、隙間です。営業部長が正当な契約書を送れなくする DLP は、業務停止であり、業務停止はエスカレーションされます。後者は製品を撤去させ、前者はたいてい何年も気づかれません。この非対称性を真剣に扱わない導入計画は負けます。

検知漏れをエスカレーションする人はいません。止められた請求書は全員がエスカレーションします。

まず観察する、それも本気で

代表的なグループで監視のみのモードを実行してください。ただし IT 部門は除きます。彼らが送るものは何一つ普通ではありません。期間は完全な業務サイクルが見えるだけ確保します。月末は月中と違います。四半期末はさらに違います。四半期の最後の 3 日に自社が何をしているか見たことがないなら、何かをブロックする準備はできていません。

次に、誤検知が説明されるようになるまでではなく、稀になるまで調整します。「これは想定内の動作で、アナリストは無視すると知っている」——キューが壁紙になるのはそうやってです。

スイッチではなく三段階

• 本当に議論の余地がないものはブロック。カード番号入りの表を個人メールへ送る、など。
• 曖昧なものは警告して許可し、利用者に一行の理由を入力させます。実トラフィックの大半はここにあり、その理由が調整用のデータになります。
• 残りは静かに記録し、摩擦なしに可視性を保ちます。

例外プロセスは必要になる前に作る

2 か月目に経理がエスカレーションしたのは、ブロックされたからではありません。ブロックの先に、上位者へ電話する以外の逃げ道がなかったからです。期限付きで承認され記録される例外——その場で申請し、数分で承認され、自動的に失効する——は、業務停止を小さな摩擦に変え、同時にどの統制が実務の邪魔をしているかの正確な記録を与えてくれます。

当社が実施するすべての導入では、いずれかのポリシーがブロックモードになる前に例外フローを納品します。あれば良いものではありません。そのプラットフォームが来年も動いているかどうかを決める要素です。