先日公開した「基礎からわかるセキュリティフレームワーク」の後編になります。前編では主要なセキュリティフレームワークを紹介しましたが、どちらかというと問題意識（本当に書きたかったこと）は今回書く部分にありました。
という訳で、今日はセキュリティフレームワーク利用におけるアンチパターンについて考えてみます。
1.アンチパターンとは
あまり意識せずアンチパターンという言葉を使用していましたが、Wikipediaによると…
必ず否定的な結果に導く、しかも一般的に良く見られる開発方式を記述する文献形式を言う
そうです。必ずと言って良いかは微妙ですが、この記事では「見聞きする範囲でよくハマっている失敗」位の意味合いで用います。
2.ISO27000シリーズの功罪
ISO27000シリーズとは、情報セキュリティについての規格群です。これらに基づきISMS認証を取得されている企業も多いのではないでしょうか？
(1)功
まず最初に明確に申し上げたいのは、ISO27000シリーズは非常に優れたセキュリティフレームワークだということです。業務上で何度も参照した経験があり、 読む度に勉強になります。（技術面がやや弱いとの指摘はありますが）カバー範囲も広く、とても有用なフレームワークです。
(2)罪
ISMS（ISO27000）と聞いて最初に思い浮かぶものは何でしょうか？
- 沢山の規程
- 台帳の更新
- 監査対応
- E-learningと確認テスト
とかでしょうか？
なんだか良く解らないけど規程と台帳を大量に作る。規程は読んだことがない、台帳は更新すること自体が目的化している、E-learningは業務の裏で流し見しておく。そんなことになって無いでしょうか？
形から入ることによるルールの形骸化と無関心。これがISO27000のもたらした負の部分だと思っています。
3.文書化の価値
では、そもそも規程や台帳を作ることに意味は無いのでしょうか？
規程なんて作っても意味が無いという意見も聞きますが、私は全くそうは思いません。文書化には非常に高い価値があると思っています。例えばGoogleの人たちが書いた"Site Reliability Engineering"という本（以下SRE本）には以下のような一節があります。
Implementations are ephemeral, but the documented reasoning is priceless.
（実装は一時のものですが、ドキュメント化された理論には計り知れない価値があります。）
この本では、その後も随所でドキュメント化の重要性が説かれています。
今回の記事ではメインの論点では無いためGoogelの権威を笠に着て強引に議論を終えますが、機会があればまたどこかで文書化の価値について書いてみたいです。*1
なお少し脱線しますが、上記SRE本はエンジニア視点での用語（「バグ」「トイル」等）をご自身の業務で扱う類似の単語に置き換えることができれば、管理系の職種であってもめちゃくちゃ役に立つ良い本だと思っています。
4.成熟度
以上の通り適切に扱えば価値が高いと考えられる文書化を進めていく上で、参考になるのが成熟度の考え方です。（なお、成熟度は色々な所で用いられバリエーションも豊富なため、ここでは一般名詞として用います。）。
(1)成熟度とは
成熟度とは、業務やプロセスを改善する際の指標です。細かい種類や学術的なあれこれはwikipediaに譲りますが、ざっくり説明すると「プロセスが存在しない状態」を最低レベルとし、「プロセスが出来た状態」→「文書化された状態」→「継続的な改善がされた状態」と順を追ってレベル（成熟度）が上がっていくという考え方です。
例えばNISTのCSFでは成熟度的な概念を以下の4段階で表現しています。Tier1からTier4に向けてどんどん成熟度が上がっていくイメージです（カッコ内は私の理解に基づく簡単な要約です）。
Tier1：Partial（個別的で受動的な対応）
Tier2：Risk Informed（暗黙知に基づく対応）
Tier3：Repeatable（形式知に基づく対応）
Tier4：Adaptive（継続的改善に基づく対応）
ここでは、Tier3の前提として文書化が求められていると理解することができます。
(2)「成熟度」のアンチパターン
上記のような成熟度を得点表というか、高ければ高い方が良いものとして見てしまうことが失敗の原因（形骸化への第一歩）だと思っています。
成熟度は文字通り「成熟」度なのです。Tier1からTier4に順々に、まさに成熟していくことに意味があるのです。現場レベルでの取り組みすら十分に出来ていない状態（Tier1-Tier2）で、いきなり網羅的な規程/台帳群（TIer3）を作ってもダメです。
まさにこのアンチパターンのような取り組みの仕方、皆さんもどこかで見かけた気がしませんか？
5.結論
それではどのように対応していけば良いのかと言うと、フレームワークをボトムアップで使ってみるのが一つの方法だと思います（→参考:基礎からわかるセキュリティフレームワーク【前編】）。個別の項目に着目し、手を広げすぎずスモールスタートでやれることを増やしていく訳です。
「リスクアセスメントに基づいてリスクが高い所から」と言うのが理想ですが、それが出来ないから苦労しているケースは多いです。むしろパラパラとフレームワークを眺めてみて、実際に手を動かす人達が「面白そう」「他社での取り組みを聞いたことがある」「うちでもやってみたい」と思える所から手をつけていくのが良いと思います。
そのような意味で、セキュリティ/プライバシーのリーディングカンパニーには自社の先進的な取り組みをもっともっと積極的に公開してもらいたいし、私もそうありたいなと考えています。
