すべっちゃったよ、すべっちゃったよ、すべりまくったよ。どうしよう。楽しい雰囲気とは裏腹に、気分がすご〜く寂しくなってきた自分がいたよ。
テーマと講師
第2回東北情報セキュリティ勉強会 - 東北情報セキュリティ勉強会
「セキュア開発プロセスとウェブ健康診断仕様の応用」
ハッシュコンサルティング 徳丸 浩さん
ちょっことLT
「MS09-047の話とか」（nig_luceさん）
質疑応答の拡大版
参加者の皆様と質疑ができたらと思います。
セキュア開発プロセスとウエブ健康診断の応用
徳丸 浩さんの講演。内容は氏のサイトからリンクでたどれるPDFを元にやっていました。
脆弱性尾責任は誰にあるのか
契約の世界では、書面として書いていないものは瑕疵ではない
モデル契約書について
情報サービス・システム取引に係るユーザ・ベンダ間のモデル取引・契約書の策定とその活用に向けた検討を実施しました。
http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05
後で読む
発注者側の視点（RFPをどう書くべきか）
RFPを書くにあたり、大体次のような方法がある。
- 提案を募る
- これは内容についてあいまいになる可能性があります。
- 詳細な仕様をで出す
- たとえば「安全なWebサイトの作り方(http://www.ipa.go.jp/security/vuln/documents/website_security.pdf)に準拠せよ」など
- 検査仕様を出す
- あいまいな仕様は駄目で、具体的な脆弱性を列挙するのが望ましい。
- 実装方式を指定するのもアリだが、ベンダーに対してそれを言うのはコストを上げる原因にもなるので注意（ベンダーは既に確立しているものかも知れないので）
- 検収方法を指定する。
- 専門の会社を指定して、その会社の試験に合格したもののみ検収する
あと、納品物にセキュリティ検査結果を指定することや、検収時に自らもセキュリティ検査を実施するなど。
・・・情報誌さんの洗い出し・・・については、省略。この中で以下のことが気になったのでメモ
RFPに対する３つのポイント
※３つのポイントって言うのは、プロジェクターで見た内容。聞いていたのをメモっていたけど、以下、３つのポイントになっていないので注意！
- セキュリティ要件とセキュリティバグに分ける
- 開発標準と教育に分ける
セキュリティ要件
クライアント証明書、パスワード仕様、アカウントロック、セキュリティログ・・・などの機能であるが、対策を具体的に書く
セキュリティバグ
SQLインジェクションやクロスサイトスクリプティングなどはどちらかと言うとセキュリティバグであるために、基本設計時点で開発標準など方式設計として盛り込む。但し、開発標準ってのはまだまだ大雑把なんで、注意。「クロスサイトスクリプティングをしない」ではなく、「リクエストに入ってきた文字列は、関数escape(String)を通してから使う」とった具体的なもので、開発言語、アーキテクチャ、ライブラリ、チームの習慣等を考慮し、可能なレベルまで具体的に書くのが望ましい。
開発標準と教育
「安全なWebサイトの作り方 改訂第三弾」を参照
「発注者のためのWebシステム／Webアプリケーションセキュリティ要件書」を参照
開発標準なんて、読まれなければ意味がない。２〜３０ページぐらいで作る
んー、ココで自分の所感メモ。
開発標準は、書いていると分かるんだけど、書き始めるとどうしても「まだ足りない、まだ足りない」って気がしていつの間にか１００ページを超えちゃったりするんだよね。これじゃ誰も読まないと分かりつつ・・・でも自虐的に「１５０ページは超えてやるぞ！」とか、馬鹿だなぁ。
ここで言っていたのって自分がいつもやっていることと一部合致していたので安心した。開発が始まる段階としては、コーディング規約などの書面は必要になる。でも経験上それを読むかって言われると読む人がいなかったり、じゃぁどうやるの？っていう質問が来ることから僕は以下のようにしている。
- コーディング規約、システム方針書、テスト方針書などのドキュメント
- コードケース集という、実際にどう作るか、様々なケースに分けたコードサンプル集
- 開発に入る前の、メンバーへの周知（２時間〜半日）
- 開発環境（Eclipse）などによる機械チェック
- Javaなどのオブジェクト指向言語だったら継承による基盤クラスの提供
- 人の目による目視チェック
人が入るまえに「なるべく人を介さないチェックの仕組み」を作るのがポイントだと思っている。個人的には規約なんてナンセンスだと思う。Webから引っ張ってきたコーディング規約を提供なんかするんだったら、殆どの人は分かっているよね。また規約ベースのプログラミング（ここはZ関数を必ず呼ぶこととか）は穴が多いと感じてきた。前述のセキュリティバグに対する要件は、なるべく基盤が知らないうちにやってくれるようにするのがいいんじゃない？
でもどれだけやっても実は穴があったりするし、よく知っている人からは指摘を受けたりするけどね。（だからセキュリティ勉強会なんてのをやんなくちゃいけないんだろうけど）ただ、この辺のことって、自分自身では人に仕事を振る前段階として当たり前のことだと思っているけど、どうなんだろう。この辺までできていれば教育に対するコストなんてあまり無いような気がしていたんだけど。
ここまで自分の所感
ウエブ健康診断とは
遠隔地からインターネット経由による診断を行うテスト。 ラステック？という団体で無償で行われている？２００９年は５００団体実施。テスト仕様書が公開されているので、活用しない手はないと思う。
- １２項目危険度の高い脆弱性を網羅意
- 無償ツールのみで診断
ここで 実際にでもでやってもらった。検査項目自体は簡単なテスト項目にみえるけど、デモ（わざとセキュリティが低く作ってあるのだけれど）では怖い結果がズラズラと・・・おおおお！
テスト工程（セキュリティテスト）のコスト削減方法
- できる部分は自分でやる。専門家に頼むと高いので。
- セキュリティ事象の全項目を実施する必要はない
- テストを実施するよりもソースコード検査の方が効率的な場合もあるので、検討されたし
MS09-047の話とか
こえ〜！！
この人のこと書いていいか分からないので、書かない。
でも、セキュリティ事象を見つけて、報告後、修正まで○ヶ月ってなんか怖くないか？直されるまで「王様の耳はロバの耳！」って言える木のウロがほしくなるよね。でも、こういった事象を発見して貢献できるってのは面白いことだよね。
自分もとあるOSSのフレームワークで、フレームワーク自体のバグではなくフレームワークが使っているライブラリのバージョン関係でバグが出てしまうことを発見して、メーリングリストに流して次のパッチで変わっていたときは凄く「なんか自分も貢献した感があったな」っておもったけど、それに近いのかな。（残念ながら僕の名前は出ていなかったけど）
ディスカッション
内容を言うとちょっとまずいので、自分の所感だけ。以下は関係者（数人）しか分からないような内容ですが。
自分の発言がすご〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜いすべっちゃったんですけど。どうすべか。なんか聞いていると、ABC（当たり前の事を、馬鹿になって、ちゃんとやる）をどこまで実現するかってことじゃないかな。すべて実現したらそれこそコスト高なんてもんじゃないし、仕事は終わらないわけで。でも限られた予算のなかでどこまでなら妥協できるかどうか。その辺を関係者各位と相談できるかってこと。こういうと自分はいつも出来ているように見えちゃうけど、全然できていませんが。
開発標準は、先にも書いたけど、ドキュメントで読ませるものではなくて、作ろうとすれば自然とそうなるような仕組みを作ること。そしてそれを当たり前のよう馬鹿になってちゃんと運営すること。偉そうに標準作って「ヤレ」だけでは人は動かない。なぜ動かないか（動けないか）原因があるはずでヒアリングなどをしていくと、開発標準自体に無理があったり、ちょっとしたところで動くようになることがあったりする。要は、齟齬が無い範囲で作業する人に開発標準のうまみを回していくことじゃないかな。開発標準を作る人の仕事は、作って終わりではなく、人がうまく回れるように潤滑油になるように努力すること。こんなことを言おうとして、頭が真っ白になってすべっちゃって終わったけど。orz...
終わりに
こういった勉強会はいつも運営に頭が下がります。自分もなにか勉強会を開いてみたいと思っていますが、どうやればいいのだろうとか、どういうステップがあるのだろうとか思いながら司会を見ていましたが、今回は非常になんかスゲーって思いました。
