NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'14 Kyushu

基調講演
「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩 （HASHコンサルティング）

基調講演に登壇されたのは、通称「徳丸本」こと『体系的に学ぶ 安全なWebアプリケーションの作り方』の著者であり、またセキュリティのスペシャリストとして著名な徳丸浩氏である。

最初に、脆弱性とは何か、なぜ生じるのとかという基本的な説明が行われた。この中で特に印象的だったのは「脆弱性はバグである」という言葉である。ソフトウェアの脆弱性というと悪意のある外部の者によるもので仕方ないと思われがちだが、少なくとも一般に認知されている攻撃方法に対して対策を講じないのはバグであると指摘した。

次に、実際に脆弱性による被害がでた際の責任の所在について、いくつかの観点・事例から説明が行われた。
一般には、脆弱性対策を仕様として明示的に記載しない発注者の責任であり、経済産業省が提示している契約モデルでも「セキュリティ要件をシステム仕様としている場合」のみ受注者の責任としている。ただあくまで一般論でのことで、これまでは裁判による判例が存在しなかった。しかし、最近では脆弱性での被害が発生した際に裁判まで発展した事例があり、そのケーススタディの説明が行われた。
SQLインジェクションの脆弱性より被害が発生したと断定し、その対策を怠ったことを受注者の重過失と判断された。ただし、発注者側の不備（受注者側からの修正提案の不採用）もあったため、過失相殺が認定され損害賠償が行われた。
この事例に対する徳丸氏の感想が述べられた。発注者/受注者ともに問題があったが、発注者責任を果たしていなかったにも関わらず受注者に厳しい判決だった。だが経済産業省およびIPAからの注意喚起が「専門家として当然果たすべき責務」の基準と判断されたことには注目したいとのことだった。なお余談だが、徳丸氏は判決文中のシステムの管理機能のID/パスワードがadmin/passwordだったとの記載について唖然としたようだ。
本ケーススタディのまとめとして徳丸氏から、我々が今後行うべきこととしては、少なくともIPAより公開されている「安全なウェブサイトの作り方」に記載されている脆弱性に関しては対策を行った方がよいだろうというアドバイスがあった。

ケーススタディの後は、脆弱性がある架空のWebシステムに対して、各種脆弱性を利用した攻撃のデモンストレーションが行われた。
Web上の情報や書籍ではなかなかイメージしにくいセキュリティ攻撃を実演するというのは、画期的でわかり易い試みだと感じた。実際のシステムに対する攻撃では実演のように簡単にはいかないだろうが、攻撃にあたってかなりの回数のアクセスが必要な場合であっても攻撃用プログラムを用いることであっさりと攻略できるという実演は、参加者にインパクトがあったのではないだろうか。

話は脆弱性対策と開発プロセスへと進んでいった。
脆弱性対策はセキュリティ診断の結果をもって行うものと思われがちだが、開発を通して常に行うべきものであること、脆弱性対策は開発標準に盛り込むのが良いということが説明された。また脆弱性対策とは別に、パスワード仕様やアカウントロックポリシーなどのセキュリティ要件については、通常の機能と同様の手順で要件定義、設計、実装と進めていけばよいということだった。

最後に、脆弱性診断の説明とその実演が行われた。
脆弱性診断は、対象となるシステムのソースコードを読んで実施するホワイトボックス診断と、攻撃者と同じ立場で外部から行うブラックボックス診断があるという。通常のソフトウェアテストでも使われている「ホワイトボックス」「ブラックボックス」が、セキュリティの領域でも同じ意味で使われていることが興味深かった。同じなのは名称だけではなく、それぞれで発見できる脆弱性も異なるということだ。原則として、内部ロジックを把握した上で行うホワイトボックステストの方が、SQLインジェクションやOSコマンドインジェクションなど、サーバ内部で発生する脆弱性は発見しやすく、ブラックボックステストはクロスサイトスクリプティングの様な表示系の脆弱性に有効だという。
徳丸氏の脆弱性診断についての説明の中で特に重要だと感じたのは、脆弱性診断によるPDCAサイクルについてだ。システムの設計(P)、実装(D)、脆弱性診断(C)、そしてその対応(A)ではなく、セキュア開発手順の策定(P)、システム開発(D)、開発プロセスの問題点分析(C)、セキュア開発手順の見直し(A)となるべきだという点だ。徳丸氏はセキュアプログラミング成熟度モデルを提唱し、より高いレベルへ登っていく必要があると説明された。筆者はCMMI(能力成熟度モデル統合)と類似していると感じた。
脆弱性診断の実演では、脆弱性のデモンストレーションと同様に架空のWebシステムを利用し、そこに対してアクセスし解析するというブラックボックスの手法がとられた。この時、脆弱性診断用ツールを使い手早く作業をしていく様は見事としか言いようがなかった。

基調講演に対する筆者の感想を述べる。過去10年以上に渡りソフトウェアテストシンポジウムが開催されているが、「セキュリティ」をテーマとした基調講演は今回が初めてだったのではないだろうか。「セキュリティテスト」という言葉があるように、セキュリティとテストは無関係ではない。だが、セキュリティは極めて特殊なスペシャリストの領域と思われており、一般のテスト担当者がセキュリティテストを行うことには疑問もあるだろう。だが、徳丸氏の「脆弱性はバグ」という言葉の通り、やはりそれはバグでありテストで検出するものであり、テスト技法のように勉強さえすれば検出可能であることがこの講演で示されたのではないだろうか。

事例発表・経験発表

事例発表・経験発表として以下の三つの講演が行われた。

「Test Engineer/Developerの良好な関係」
松谷 峰生 （LINE Fukuoka）

「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉 （九州ソフトウェアテスト勉強会）

「テストする人。の思うところ」
福田 里奈 （九州ソフトウェアテスト勉強会）

松谷氏は、テストエンジニアと開発者とでよい関係を保つために気を付けること工夫することを、実際の社内の事例を元に説明した。
木下氏は、当初興味を持っていなかった自分がどのようにしてテストに対する興味を持ち、勉強するに至ったかが語られた。テストは「楽しくない」「仕様書通りであることの確認でしかない」と当初思っていた。しかし、仕様書通りの挙動であってもバグは存在していると気がついた。最終的には「テストは設計するものである」まで行き着く過程は、同じ開発エンジニアとしても興味深く聞くことができた。
福田氏は、「ログインIDは6桁から14桁の範囲である」という開発者から提示された仕様に疑問を思ったことに端を発し、「その仕様は何のため？誰のため？」をテストエンジニアの立場から探求するというミステリ風なものだった。

この三者の発表内容は、全てテストエンジンアと開発者とのかかわりを、そしてその重要性を説明したという共通点があるのが興味深かった。

なお、福田氏の発表の中で、基調講演を担当された徳丸氏に過去にTwitterで、システム上の仕様についてセキュリティ上の観点からのアドバイスを求めていたことが紹介された。業界の著名人に直接質問し回答を得られるということは一昔前には考えられなかった。質問に対して丁寧に応答した徳丸氏の人柄もあるが、学ぶことのハードルが以前よりも確実に下がっていることを実感した。

招待講演
「テストエンジニアを育てるためのポイント」
鈴木 三紀夫 （リコーＩＴソリューションズ）

招待講演は「テストエンジニアを育てるためのポイント」と題してリコーＩＴソリューションズの鈴木三紀夫氏が登壇した。
鈴木氏は三色ボールペンやマインドマップを用いたテスト設計・分析技法などで有名だが、本講演ではそれまでと趣を異にして人材育成を題材としていた。ここでいう人材育成とは、例えばJSTQBの資格取得のような「何を勉強するか」ではなく、いかにしてテストエンジニアの設計力を上げるかについて鈴木氏の経験を元にした指導法が語られた。

まずテストエンジニアの3つの成長段階に合わせて指導法を変えるべきだとする。
その成長段階とは以下のものだという。

1. テストエンジニアになりたてのころ
2. 少し自信が付いてきたころ
3. リーダー的な役割になった頃

各段階での育成のための「キーワード」と「道具」そして方針が説明された。
印象的だったのは

1. 比較的自由にさせて欠点の是正よりも長所を伸ばす
2. 標準を学ばせる
3. それまで蓄えた知見を組織に活かすよう促す

という順番で指導法を変えるというもので、「守破離」のように最初に型ありきではないことだった。

テストエンジニア育成についての一通りの講演を終えた後 、エンジニア育成方法の中ででてきた「テストの道具」について紹介されたが、その中で特に興味深かったものを二つほど取り上げてみる。
一つ目は鈴木氏が発案し代名詞にもなった「三色ボールペンで読む仕様書」についてだ。これは三色ボールペンを使い、仕様書を読み進めていく中で重要な部分、やや重要な部分、疑問に思う箇所をそれぞれ別の色でチェック・コメントを記入していくというもの。この手法が生まれたきっかけについて解説があった。普段テストエンジニアが仕様書を読んでいる最中にでてくる「ぼやき」を可視化することから始まったとのことである。些細なことだが、その効果は抜群であり、テストエンジニアの育成への応用例もあるとのことだった。
もう一つは「テスト観点リスト＆不具合推測リスト」のうち特に不具合推測リストの事例だ。これは過去に発生したバグの事例集をまとめたものなのだが、鈴木氏は過去のプロジェクトにおいて、開発者全員に対して開発者自身が体験したバグを話してもらい、それを全員で共有したという。この結果、共有されたバグについては意識的に注意が向くため、バグの混入がなくなり、非常に効果があったとのことだった。

企画イベント：グループディスカッション

最後のセッションでは、講演ではなく参加者がテーマ毎に集まってのグループディスカッションが行われた。当日の講演に沿った「セキュリティテスト」「テストエンジニアの育成」について悩みを持っている人たちで集まるが、私は、テーマを設けないグループへ参加した。
各自の悩みを渡された紙に書き、その紙を隣の人に渡しては悩みに対する提案を追記してまた隣に渡すということを、全員の意見がもらえるまで繰り返していく。 その後、その悩みと参加者からもらった提案についてフリーディスカッションが行われた。悩みは各自様々であった。最初の方で私が挙手をし、悩みと各自から頂いた提案について話をすると、同じ悩みを持っている人が多数いた。結果的に、ほぼ最後まで私が悩みとして挙げた「自部署の品質意識の低さへの対応」をテーマに議論が行われた。議論には、参加者だけでなくJaSST'15 Kyushuのスタッフ、およびアドバイザである電気通信大学西康晴氏も加わり活発に進んでいった。議論の経過は省くが、「メトリクス(数字)だけで解決するのか」「技術者が持つ品質に対する意識を、営業に対しても主張するべきなのでは」「問題対人ではなく、問題対我々にする」「時間がないことが問題の本質なのか」など重要な示唆をもらえた。

終わりに

今回のJaSST'15 Kyushuは「知識の広がりは可能性の広がり」をテーマとして行われ、これまでなかったセキュリティテストの講演が行われるなど、見事にテーマに沿ったものになったのではないだろうか。
最後に、ディスカッションなどで一緒に会場を盛り上げた参加者の皆さま、開催にかかわった実行委員およびアドバイザの方々に感謝する。本当に楽しい、そして貴重な体験だった。