ikepyonのだめ人間日記

セキュリティに関することを書いていく予定。

セキュリティ要件

いくら開発者サイドでXSS対策をどうたら、SQL Injectionをどうたらと言っていても、依頼サイドが要件としてあげていなければ、無駄なコストだったり、不要な機能だったりするわけで、開発者のモチベーションなんてあがりゃしないし・・・
ということで、セキュリティ要件が必要なんだが、セキュリティ要件ってどうやって決めればいいんだろう?

思いっきり手を抜くのであれば、「適切なセキュリティ対策を施すこと」みたいなのでもOKなのか?
じゃ、「適切なセキュリティ対策」って何よってことにつながるんだよなぁ。でもって、「適切なセキュリティ対策」というものがあいまいなために、受け入れ側も、それで十分かどうかというのが疑問だったりするわけだ。要件定義たるもの、「何」を「どうする」のかをきちんと示さなきゃいけないと思うわけで。

となると、最も手っ取り早いのはリスク分析を行って、そこからセキュリティ要件を出すことだと思うんだけど、リスク分析という手法自体かなり難しいところがあるからなぁ。これを毎回開発案件毎にやるのは手間だし、顧客サイドには難しいかもしれない。
リスク分析のパターンを作って各案件毎にそれを適用するしないを判断するというのが出来れば、簡単に行えるかもしれないなぁ。その上でセキュリティ要件をデザインパターンみたいにパターン化してしまうともっと簡単になるかなぁ?
で、その幾つかは第1回のSKUFでも資料として乗っけてみた。
http://skuf.s-lines.net/presen/20050903/skuf-meeting-0903-ikepyon.lzh
何とか網羅的にセキュリティ要件をパターン化してみんなで使えるようにしたいなぁ。
誰か作ってくれないかな、と他力本願になってみるw

一応こういうのもある
http://www.jnsa.org/active/2005/active2005_1_4a.html (from yamagataさん)
http://www.ipa.go.jp/security/ccj/archive/cc_cem/CCpart2_v13-j.pdf
http://www.ipa.go.jp/security/jisec/documents/jisec_system_st_v1.1.pdf

しかしなぁ、JNSAの奴はどうも開発サイドからの視点っぽいので、これが必要かどうかの判断が今一分かりづらいかも・・・
CCとかSTはあまりにむずすぎるのでちょっとした開発案件では適用するのは難しいし・・・
イメージ的には機能毎に脅威が記述してあって、それに対する対策が書かれているマトリックス表みたい
なのがあれば簡単かなぁと思ったりするんだけどなぁ。