SDL
ちと考えているので。
- 各工程で、どうするかの計画を立て、実装し、実装の内容を確認するというサイクルをまわす(どうするんだったかな?アイデアあったのに忘れたw)
- 要件定義ですること
- 「誰」が「何」を「どうする」かを機能ごとに明確にする->これは、結局要件を明確にすることにつながる
- 明確にした機能についてSTRIDE分析を行う(MSの資料参照)
- STRIDE分析の結果、脅威に対してどうするかを決定する
- 受容:この脅威は発生してもよしとする
- 軽減:いわゆるセキュリティ対策
- 回避:機能の実装自体をやめてしまうとか
- 移転:他組織が提供しているサービスを利用することで、脅威を自組織で起こさないとか
- 設計でやること
- 入力と出力のデータ仕様を明確にする->設計で当たり前にやることだし
- 機能の実行条件を明確にする->これもそう
- 各機能を可能な限り単機能に分割する->これもやるよね?
- 例外処理を明確にする->あんまり設計で意識してやってないかもw
- 軽減するとした脅威に対して、どのような対策を行うかを検討し、機能として定義する
- コーディングでやること
- 設計どおりにコードを書く->当たり前
- 実行時例外をうやむやにしない->結構もれる
- 出力データの仕様通りにエスケープなどの処理を行う->同じくw
- テストでやること
- 仕様どおりの動きをするかのテストケースを作成し、テストを実施->普通にやるし
- 例外時の処理が適切に行われているかのテストケースを作成し、テストを実施->結構もれる
- 出力データにメタ文字が含まれるような入力データのテストケースを作成し、テストを実施->やらなかったりorz
というようなことをやればいいかなぁ?
と書いてはみたものの、これ実際にやるとなると、要件定義と設計で結構工数取られるよね。
まあ、「何」の部分の重要度が高いのだけやりゃいいって話もあるけどな。
(追記)id:hasegawayosukeさんに教えてもらった。
http://e-chishiki.com/jpn/articles/information_security/application_security/security_principals_and_the_sdl/security_development_lifecycle
上のアイデアは、設計やコードに依存するような脆弱性(XSSとかSQLインジェクション、CSRF)は実装でがんばってつぶす。それ以外の問題については、リスク分析やって、その結果に応じて対策する、しないを決定しようぜという感じ&正しいプログラムは脆弱性が少ないという前提に立っている。各工程ではレビューを行うことで抜けとか間違いを正すということも必要。
後開発サイクルのことを考えると、あんまり重くしたくない。ただでさえ工数削減が言われているのに、それに対して重いセキュリティ対策もといわれると、無利!!となるのは目に見えてるからね。
もちろん、MSのSDLのようにあらゆる部分に対してコストかけてセキュリティ対策を行うというのが理想だけど、理想ばっかり言っても出来ないものはできないわけで。そういった落し所がSonyDNAのレビュー中心の手法であったり、考え中の方法だったりするんでないかなぁ?
ま、これでも現場で実践するのは結構難しいとは思う。要件も決まってない、設計も出来てない、でもカットオーバーが決まっているから、コード書かなきゃという現場もあるわけで。その結果バグが発生し、そのバグが脆弱性につながるんじゃないかと考えてる。
そろそろ、再度ウォーターフォールのよさを見直して、それをうまく短期間の開発手法に組み込むというのが必要じゃないのかな?