Kirt Cathey's Facebook profile

2008年4月30日水曜日

セキュリティメトリクはS.M.A.R.T. !!

役立つメトリックは、セキュリティゴールの達成率を示し、組織のセキュリティプログラムを改良するための活動を進めてサポートする。その性質ほどの指数としてメトリクは、明確であり、測定可能、メトリクによって決定する目的数値が達成可能、測定の再実施可能と、時間の依存性がある。

後述に詳しく取り上げるが、特徴によってメトリクの性質がかわるので、性質要素とも言えるだろう。下記の「S.M.A.R.T.[1]方式で性質を判断して、セキュリティのプログラムにどのメトリクを取り入れるかと計画に役立つと思う。


明確である - Specific

メトリクは複雑であればあるほど、情報のエンドユーザには、指数の重要性、情報とする価値と、セキュリティ環境を改善する動機が与え難くなり得ることである。

逆に、一定のメトリクは情報のエンドユーザに説明し易いし、エンドユーザにとって理解し易いことである。その上、改善活動の為の対応が求められる時に、対応する部門やマネジャーに納得するのがより簡単で、担当部署のどこにセキュリティ パフォーマンスを向上するべきかと関連づけることがより明確である。

と言えば、最近の(いわゆる)数量的なリスク分析のような1から5までのスケールで何かの状況を主観的に評価するみたいな判断に頼られるようなメトリクやメトリク測定項目[2]を絶対に避けた方が情報とする納得力があるだろう。リスク評価にも使われているヒートマップや虹色スケール等は、(ビジネス上の判断をするべきの)情報を受ける相手に理解させ難いことは少なくないことである。それに、曖昧な評価基準、不明確な計算、又は、明確で大変複雑で、数学博士でも理解時間が100時間以上掛かるメトリクを作成して報告する必要が一切ないことである。

測定可能 - Measurable

メトリクを作成するための情報収集の活動には、測定する必要な項目を実際に測定ができるかと確認するべきである。ある情報をシステムから取り出したいと思ったら、何でもすぐに抽出できる訳ではなく、ログのシステムから取り出せても、ログ項目別の洗い出しと分析は大量時間がかかる場合が少なくないだろう。これを考えると、人間、時間、予算等の話しすぐ上がってくるので、とてもシンプルなファイル参照アクセス拒否の件数を取り出すことだけが多大な仕事が掛かるだろう。しかし、コンピューチング環境、当該組織の業界、システム管理環境などの要素によって測定能力が変わることがある。

達成可能 - Attainable

メトリクをKPIとして使われた場合には、事前に決定された目的値や目的数が実際に達成が可能であるかどうか確認するべきである。目的値は達成可能でなければ、改善をするために協力する方々にとっては、やってもやらなくてもという態度になりかねないことだろう。この状況を避けるのには、ベースライン[3]を定めた後に、目的値を決定するべきであるが、セキュリティメトリクのプログラムの中には、定期的なレビューとゴール、KPI調整も必要である。

測定の再実施可能 - Repeatable

測定結果を正確に報告するのにキーであるのは、標準化された測定手順がなければならない。測定方法は余り難しければ、その他の測定手続きを検討した方が推奨であり、システムのログ等をスクリプトや管理ソフトのフィルタを使用して自動化にすることも強く進めることである。スクリプトのフィルタを使ってログ情報を収集すると、スクリプト作成段階で、ログ項目の選別基準を文書化する機会があり、協力部署の人材と時間という抵抗がなくなり、自動の測定手順と結果の安定さに対する疑問がなくなるであろう。

時間の依存性がある - Time Dependent

測定結果は、ある時点に当該システムのセキュリティ状況の「写真」とのことであるので、数日間に渡って測定手順を実施すると、測定とメトリクの情報とする価値が下がることである。

2008年4月の報告をする為には、2008年4月1日から2008年4月30日までの測定情報を集めてから、メトリクを迅速かつ適時に報告するべきである。上記に取り上げた例として、2008年5月10日以前が望ましいと思う。


全てはログではない

この章の最後には、前述に測定とログの話しが続々とでてきたが、全てのセキュリティメトリクはログではないだろう。特に、アタックパターンを分析するような予防活動に関しては、ログに共有項目のアクセス拒否とアプリケーションのアクセス拒否情報は典型的なシステムログには見つからないことである。[IN]SECUREというオンライン雑誌記事では、2007年で異彩を放るセキュリティ事件要約の中、「ログのデータ分析から始まりのがよい考えだが、問題は殆どのログ管理システムはイベントログを中心にして、全てのセキュリティ関係データが含まれていない」[4]と説明する。それに、日常のデータだけではなく、月次、新半期、年次のデータを分析する時代になり、最近の攻撃は低いフットプリントで長期間という傾向がある。











[1] A Guide to Security Metrics, SANS Security Essentials GSEC Practical Assignment Version 1.2e; Shirley C. Payne, June 19, 2006. http://www.sans.org/reading_room/whitepapers/auditing/55.php





[2] この文書には、「メトリク」と「メトリク測定項目」をよく使われるが、前述されたようにメトリクは一つの測定からなることもあることである。





[3] 事前に最低2回計った結果を見て、平均値、中央値などを加えたトレンド提示である。





[4] Vijay Basani. "Building a secure future: lessons learned fro 2007's highest-profile security events." [IN]SECURE Issue 16 (April 2008): 31+. HNS Consulting Ltd. 2008. http://www.net-security.org/dl/insecure/INSECURE-Mag-16.pdf










1 件のコメント:

Typh00n さんのコメント...

コメントをして下さい!