ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

「IoTセキュリティのための動的テスト(ファジング)」 #IoTテストアドカレ(21)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の21日目です。いったいいつから・・・アドベントカレンダーはその年のうちに終わると錯覚していた? 20日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Security Testing the Internet of Things IoT: Dynamic testing (Fuzzing) for IoT security』
  • 著者: Beyond Security
  • 参照サイト: Beyond Security

ポイント

 IoTのマーケットに各製造業者が押し寄せているが、ネットワークデバイスについての経験がないことが多く、ハードウェア・ソフトウェアのセキュリティ設計・構築の複雑さは見逃されがち。プロダクトが普及した後に脆弱性が発見されると、個人・家庭内・移動体・ビジネスといった各エリアにおいて、攻撃を受けるポテンシャルを抱えてしまうことになる。

静的テストと動的テスト

  • 静的テスト脆弱性の検出の手段としてよく使われるが、プロセッサーやメモリといった、アプリケーションのインストール先に潜む脆弱性を見つけるようには設計されていない。
  • 動的テストでは、静的テストでは見つけられない隠れた欠陥・脆弱性を見つけることができる。たとえば、古いプロセッサー上で新しいコードが動く際の脆弱性を見つけるのに重要な役割を果たす。

ファザー

  • バイスやアプリケーションを攻撃する攻撃者は「ファザー」(fuzzer)を利用している。予期しないような壊れたデータを生成・入力したり、プロトコルの境界を狙ったりして、アプリケーションを破壊する組み合わせを探す。
  • 開発側もファザーを用いることで、脆弱性をできる限り低減しておく必要がある。ただし、多くのファザーはある特定のタイプの脆弱性プロトコルに特化していることが多い。
  • ファザーは、バッファオーバーフローエラーのテスト、プロトコル違反のテスト、ブラックボックステストなどの助けになる。
バッファオーバーフローのテスト
  • バッファオーバーフローの問題がある場合、バッファの外にあるメモリの内容を上書きされ、悪意あるコードを埋め込まれたりするので、脆弱性の元である。
  • beSTORM™では、ヘッダを改竄したパケットを送り込んだりすることで、欠陥を検出する。
プロトコル違反のテスト
  • バイス間の通信のために用いられるAPIに対して、攻撃が行われる。たとえば、入力値に対する誤ったバリデーション・境界値チェックや、設計の瑕疵、プロトコル自体の実装の問題を突く。攻撃の組み合わせの量が膨大になるので、もっともエラーの原因になりそうな箇所から試行したうえで、組み合わせ空間をカバーしていく。
  • 値の操作だけでなく、プロトコルの操作、ロジックの操作といった先進的なアルゴリズムが、ファザーの能力を決める要因である。
  • beSTORM™は、おそらく唯一のマルチプロトコル対応のファザー。50のプロトコルをサポートしているうえ、固有のプロトコルであっても自動的に学習することができる。
ブラックボックステスト
  • アプリケーションの内部について知識がない場合、テスターはまずトラフィックを調べて、それをベースにして、正当な入力、ランダムな入力、おかしな入力を試す。
  • ツールでは、内部エラーを引き起こすために組み立てられた入力を、繰り返しプログラムに食わせる。「フォールトインジェクション」とも言う。
  • beSTORM™は攻撃の組み合わせを徹底的かつ賢く行い、アプリケーションの異常な動作を検出する、強力なブラックボックステストツールである。

所感

この文章って・・・

 ファジングについての話なのですが、beSTORM™という特定プロダクトをやたら推してくる。

bestorm.jp

のはまあいいとして、とにかく読みづらい・・・! 文章と文章のつながりがわかりづらい部分が多く、読み進めるのに苦労しました。で、内容も理解できない点が多かったので、いろいろ調べていると・・・。

Open Source Fuzzing Tools

Open Source Fuzzing Tools

 なんか、この本*1文章がものすごく似ているんですよね。読みづらいのも当然で、書籍の文章が、この記事の複数箇所に切り貼りされているんです。これは何なんだ、記事と書籍の著者が同じならいいのかもしれないけれど・・・。
 まああまり闇に突っ込みたくないので、記事では不明だった点を、書籍の方の記述に基づいて少し補足しておきます。

ファジングの技術

 ファジングの技術として、「値の操作」「プロトコルの操作」「ロジックの操作」というのがありました。具体的には、以下のようなことみたいです。

  • 値の操作: たとえばTCPセグメントにおけるポート番号のフィールドに、記号を入れたり、RFC規定の外の数字を入れたりして、アプリケーションに送り込むこと。各フィールドの意味自体は気にせず、エラーを引き起こしそうな入力パターンを試します。
  • プロトコルの操作: たとえばHTTPにおいて、「GET GET GET」などと送り込んでみる。プロトコルのフィールドやコマンドの意味を把握したうえで、それを壊そうとする試みのようです。
  • ロジックの操作: たとえばSMTPにおいて、EHLOの前にRCPT TOを送り込む。プロトコルの正規手順を理解したうえで、例外的な手順だったり違反した手順を試して脆弱性を探すイメージでしょうか。

ファジングって動的テストなの?

 正直申しまして、動的テストとファジングによるテストの違いがわかっていません。ファジングは動的テストの一種?
 過去にIBM AppScanを見たことがありますが、これはファザーなのか?

www-03.ibm.com

 ネットワークセキュリティの調査では、BreakingPointに関わったこともありました。ちょっとだけ。

jp.ixiacom.com

 なおJaSST'17 Tokyoでは、ベリサーブの松木さんが「IoT時代に立ち向かうテスト・ファジング技術入門」というチュートリアルを行う予定になっていますね。   

 ソフトウェア化していく世界のなか、まずコンピュータがクラウドという形で結実し、昨今はモノのソフトウェア化=IoTが進んでいます。実在の世界における"環境変数"を事前に想定することがどんどん難しくなっていくこれからの時代に立ち向かうために、いわゆる"異常系"の膨大なテストを実現する「ファジング」技術についてその概要、およびウェブサーバを例にとったファザー設計の実例をお話します。

 興味のある方は、受講してみてはいかがでしょうか。

 22日目はコチラです。(いつの日か公開されます)

http://kzsuzuki.hatenablog.com/entry/ac_20161222kzsuzuki.hatenablog.com

*1:っていうかこんな本が売られていて、かつ7,992円というのに驚いた。円安かよ。

「IoTのテスト:5つの大きな課題をどう乗り越えるか」 #IoTテストアドカレ(20)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の20日目です。19日目はコチラ。一体いつから・・・、アドベントカレンダーは12月25日に完結すると錯覚していた?

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『IoT testing: How to overcome 5 big challenges』
  • 著者: TechBeacon
  • 参照サイト: TechBeacon

ポイント

 IoTの時代には、効果的なテストが重要である。Iotデバイスのテストにおける考慮事項を述べる。

IoTプラットフォームが多い

 デバイスのハードウェアとソフトウェアが多彩すぎて、すべての組み合わせをテストすることはほとんど不可能。エンドユーザの情報を集め、どのデバイスとソフトウェアが使われているかを理解したうえで、最もよく使われる組み合わせを中心にテストする。

テストする通信プロトコルが多い

 現在のIoTデバイスでは、コントローラとやり取りするための様々な通信プロトコルを使っている。MQTT、XMPP、CoAPなどがよく使われており、それぞれ長所と短所がある。
 テスト設計は、IoTデバイスがどのようなプロトコルAPIを使っているかに依存する。テストツールはそれらを利用できるものでなければならない。

攻撃されるポイントとセキュリティ上の脅威が増える

 IoTデバイスの70%以上が、セキュリティ上の脆弱性を抱えているとされる。開発者やテスターは、パスワードポリシーをはじめとするセキュリティの問題にも注意を払う必要がある。

IoTアプリケーション、デバイスが多様になる

 テスターは、しっかりしたテスト戦略を持ち、アーキテクチャを理解し、デバイスとソフトウェアが適切なバージョンに設定されていることを確実にしておく必要がある。

 システムがサードパーティーのサービスを使っていれば、そのサービスの変更によりテストが失敗する可能性がある。サードパーティーのサービスが利用できない場合、サービスの仮想化を使うことで実際のサービスへの依存性を排除することができる。仮想化を行うツールがカスタマイズ可能なものであれば、様々な状況のレスポンスをテストできる。

データの高速化と負荷の増加が巨大になる

 WiFiチャネルの高負荷、信頼性の低いネットワークハードウェア、低速で一貫性のないインターネット接続など、ネットワーク状態は、デバイスの性能に重大な影響を持つ。様々なネットワーク条件でテストし、データを失うことなく適切なレスポンスができることを確認しなければならない。そのために、ソフトウェア的に様々なネットワーク状態をエミュレートするためのネットワーク仮想化を利用する。

 またテスト中は、CPU使用率やメモリ使用率のようなシステムのメトリクスをモニタする必要がある。ただIoTデバイスは、デスクトップアプリケーションのようにユーザの操作によって起動・テストされるとは限らないので、どのデバイスが利用されているのか、どのように振る舞うのかを把握する必要がある。

所感

 プラットフォームの組み合わせ、プロトコル、セキュリティ、性能など、これまでの資料でも言及されたポイントが整理されていてわかりやすいですね。

 21日目はコチラです。(いつの日か公開されます)

kzsuzuki.hatenablog.com

「モノのインターネットをテストする: ヒトの体験」 #IoTテストアドカレ(19)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の19日目です。18日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Testing the Internet of Things: The Human Experience 』
  • 著者: Gerie Owen
  • 参照サイト: InfoQ

ポイント

ユーザの理解

  • IoTデバイスをテストするということは、人間のユーザを深く理解すること。人間との相互作用とテストしないと、品質の判断において重要な情報が欠くことになる。
  • 「ヒトの体験」(human experience)というとユーザビリティが頭に浮かぶが、もっと深い。単なる見た目や使いやすさだけでなく、ユーザの感情的、物理的、知覚的な反応や、マインドセット、バイアスといった観点で、徹底的にテストする必要がある。
  • バイスを使用するうえでは多くの失敗が考えられるので、ネガティブなテストシナリオが、ポジティブなものより重要になる。非機能要件(-ability)のテストも重要。
  • ヒトがデバイスに何を求めるのか、知見を集める必要がある。新しい種類のデバイスであれば、プロトタイプでユーザの反応を観察したり、デバイスに対する印象をインタビューしたりする。
  • 現実世界におけるユーザのテストシナリオをどのように設計するか。「ヒトの体験」をテストする最も効果的な方法は、人間-コンピューター相互作用の設計原理を用いることである。

ペルソナ

  • 「ペルソナ」は、潜在的なユーザのモデル。年齢、性別、家庭的な背景、教育レベル、職業、社会・経済的な状況、価値観、欲求といった特徴をすべてリストアップしたもの。場合によってはペルソナが動物の場合もある。
  • ペルソナから、ユーザがデバイスに期待することを引き出し、それを元にテストシナリオを作る。

ユーザ価値ストーリー

  • バイスがどのようにユーザに価値をもたらすかを、「ユーザ価値ストーリー」に基づいてテストする。
    • たとえばマラソンの終盤という状況を考えて、「汗をかいている」「ゆるい上りが急坂に感じる」「群衆の声が聞こえてくる」といった状況で、ゴールの瞬間にスマートウォッチをクリックする・・・といったストーリーを記述していく。
  • ペルソナとユーザ価値ストーリーに基づくテストシナリオは、物理的な期待、知覚的な期待、方向や地理に関する期待、状況に基づく期待や、バイアス、マインドセットもなどを含む。
  • どんなデバイスにも複数のペルソナがあり、各ペルソナに複数のユーザ価値ストーリーがある。ペルソナとユーザ価値ストーリーを組み合わせるだけでも、多くの「ヒトの体験」シナリオが生み出される。シナリオの絞り込みのために、リスクベースドテストを使ってもよい。

所感

 IoTの中でも、人間と密接にやり取りするパーソナルデバイスを念頭においた記事。マラソンランナーとしての筆者が、自分の走りをスマートデバイスでモニター・記録していたにも関わらず、そのデータが大会側に反映されていなかったというエピソードをベースに、「ヒトの体験のテスト」についての説明をしてます。具体的で読みやすい内容でした。

 このカレンダーの前日の記事もシナリオテストに関するものでしたが、今日の資料は、ペルソナやユーザ価値ストーリーの導出の流れをわかりやすく説明してくれています。だいぶはしょっているので、ぜひ原文をお読みください。
 この中で言及されている「人間-コンピューター相互作用」については僕は知識が全然ないのですが、これから特に重要になってきそうな分野だと感じます。

 20日目はコチラです。(12月20日の0時に公開されます)

kzsuzuki.hatenablog.com

「モノのインターネットのテスト」 #IoTテストアドカレ(18)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の18日目です。17日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

ポイント

  • 自律システムのソフトウェアのV&V*1には、英国のTSI*2によるPAS 754:2014という規格がある。この中で、Trustworthinessは以下の5つからなる。

    • 安全性(Safety)
    • 信頼性(Reliability)
    • 可用性(Availability)
    • レジリエンス(Resilience)
    • セキュリティ(Security)
  • Trustworthinessの中でも特に、安全性とセキュリティが重要になってくる。
    安全性の規格には、たとえば以下のようなものがある。

    • IEC61508: 電気・電子・プログラマブル電子の機能安全に関する国際規格
    • DO178: 航空機搭載システム・設備のソフトウェア考慮事項に関する認証
    • EN50128: 鉄道制御・保護システムのソフトウェア
    • IEC60880: カテゴリーA機能を実行するためのコンピュータベースのシステムのソフトウェア面*3
    • IEC62304: 医療デバイスのソフトウェアとライフサイクルプロセス
    • ISO26262: 自動車の機能安全
  • IoTデバイスは現在、ほとんどがセキュアでない。最初の攻撃はおそらく、もともと知られた方法(認証に対する攻撃、コードインジェクション、オーバーフローなど)で行われるだろう。新しい技術にはすぐに新しい攻撃が続き、新しい防御はその後になる。

  • 防御策として、セキュアな設計やコーディングプラクティス、セキュリティのテスト、ネットワーク境界での防御、セキュアな技術・プロセス・人間などがある。
  • IoTビジネスの参入障壁が低くなることで、セキュリティスキルの低い人間がたくさん参入してくることになる。脅威に対するアセスメント*4が重要である。

    所感

     ほぼ、安全性とセキュリティに特化した内容です(スライド資料なので、単語の羅列がどうしても多いのですが)。規格がたくさんありますが、まずは自分の分野に関するものを押さえることですね。
     セーフティとセキュリティについては、2017年1月13日に日科技連で「「IoT時代」のセーフティ&セキュリティbyデザイン ~アシュアランスケースとコモンクライテリア(ISO/IEC 15408)によるセキュリティの品質保証を考える」という長いタイトルの特別講義を行うみたいですよ。

    www.juse.or.jp

     さて、最初に紹介されているPAS 754(Publicly Available Specification)という規格について、軽くググっただけでは日本語の資料が見当たりませんでした。
     Wikipediaから引用(鈴木参考訳)してみます。

    The PAS defines the overall principles for effective software trustworthiness, and includes technical, physical, cultural and behavioral measures alongside effective leadership and governance. It also identifies the necessary tools, techniques and processes and addresses safety, reliability, availability, security and resilience issues.[2]
    PASは、効果的なソフトウェア信頼性のための全体的な原則を定義している。これには、効果的なリーダーシップとガバナンスとともに、技術的、物理的、文化的、そして行動的な対策を含む。また、必要なツール、技法、プロセスを特定し、安全性、信頼性、可用性、セキュリティ、レジリエンスの問題を扱う。

     困ってしまうのは、Trustworthinessという言葉ですね。
     まず信頼性といえば、Reliability。ISO/IEC25010の品質モデルにおける主特性である「信頼性」は、Reliabilityです。一方SQuBOKでは、副知識領域として「ディペンダビリティ」を紹介しています。JIS Z 8115:2000では

    ディペンダビリティは、Availability、Reliability、Maintenabilityを含む包括的な概念で、定性的な意味での総称として用いられる。

    としています。
     で、PASにおけるTrustworthinessはReliabilityを含む、と。普通の英語では、ReliableもDependableもTrustworthyもそれほど変わらないようなのですが。また規格によってもそれぞれの言葉の位置づけが違ったりするようなので、注意が必要です。

     19日目はコチラです。(12月19日の0時に公開されます)

    kzsuzuki.hatenablog.com

    *1:Verification and Validation: 検証と妥当性確認

    *2:Trustworthy Software Initiative

    *3:原子力発電所におけるセーフティレベルがA、ということのようです

    *4:ここでは、2日目の記事で紹介したOWASPがリンクされています。

kzsuzuki.hatenablog.com

「IoTと、テストへのインパクト」 #IoTテストアドカレ(17)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の17日目です。16日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『IoT and it's Impact on Testing』
  • 著者: Bob Crews, President and Co-founder of Checkpoint Technologies
  • 参照サイト: Zephyr

ポイント

IoTデバイスとそのテストの特徴

  • Dr. John Barrettによると、IoTデバイスが備えている特徴は以下。
    • ユニークな識別子
    • ワイヤレス通信
    • センシングや測定を行う能力
    • 組み込みエレクトロニクス
  • バイルデバイスのテストでは、タッチスクリーンでのジェスチャーや位置情報の検知といった、新しい考慮事項が加わった。スマートデバイスでは、センサーからの入力を考慮する必要がある。たとえばフィットネスデバイスであれば、脈拍、体温、位置、標高、運動の様子など。
  • バイスは、収集したデータを人間が見られるようにしたり、モバイル機器と同期したり、クラウドにデータを送ったりする。どんな状況でも装着できることを確認するには、複雑なテストが必要になる。

テストケースの例*1

 以下のようなテストケースの例を考えてみる。

テストケース名: ヘルスフィットネスデバイス v3.2の、氷点下における、3時間の高い活動レベルでの使用
テストケースの目的: センサー機能と、長時間(3時間)の高い活動レベル(ジョギング・ランニング)を通したデータ読み取りの正確さを、氷点下(摂氏0度以下)で確認する。
テスト対象: デバイスは以下のようなモデルに合わせてプログラムされている。

  • 性別: 男性
  • 体重: 84Kg
  • 身長: 183cm

テストステップ

  • ステップ#1

    • アクション: プログラム済みのデバイスをテスト対象の腕に正しく装着し、デバイスが露出している(衣服に覆われていない)ことと、確実なモニターのために肌に接していることを確認する。
    • 期待結果: なし
  • ステップ#2
    (以下省略)

  • ネットワークへの接続がまばらで、位置の特定も不完全な、雑多な現実世界でのシナリオでテストを行う必要がある。
  • ユーザエクスペリエンスへの配慮が必要。文字の大きさや明るさは、夜にジョギングするユーザにとって十分か? 着けたまま寝るユーザにとってまぶしすぎないか?
  • いろいろな人を採用してくる必要がある。選任のランナー、その人の体温や脈拍を測る人・・・。
  • 自動化は重要であるが、スマートデバイスのテストでは効果が小さくなるかもしれない。環境をシミュレートしたり、「走る」といった物理的なイベントを自動化したりするのは、ブラウザの操作よりはるかに難しい。また、法規制のある業界(たとえば医療)では、現実世界におけるテスト以外は受け入れられないかもしれない。

QAはどう変わっていくのか

  • テストプロセスにおいて、計画と管理が今後さらに重要になり、QAのロールも変わっていく。
    • テストのニーズの把握
    • テストの検討
    • テストに必要な人の検討、調整
    • テストの結果の分析、対策の管理
    • テストに関する情報の管理と関連付け(テストリリース、テストサイクル、テスト要求、テストケース、テストスクリプト、テストセット、テスト実行、欠陥、・・・)
  • IoTにおいては、多彩なデバイス・ハードウェア・OS、多数のユーザ、多くのデプロイツール、リリースツールなど選択肢が極めて多い。圧倒的な数の組み合わせのテストを管理できるようにする必要がある。

所感

 これまでの資料の中では珍しく、パーソナルユースのIoTデバイスを例にとった記事でした。規格、ワイヤレスプトロコル、セキュリティといった、他の記事で声高に主張されてきたポイントにはほとんど触れず、テストの最終工程に近いところに注目した記事です。ですので、これまで有効とされてきた自動化の力も弱くなっています。現実世界における実際のユーザによるテストにおいては、自動化できる範囲がどうしても限られるからでしょう。

 一方、この工程でのテストにおいては、テストシナリオ*2が重要になってきます。
 秋山浩一さんの『ソフトウェアテスト技法ドリル』において、シナリオテストは、「さまざまな視点を織り込んだシナリオを描いてそれをテストするという方法」と説明されています。そして「シナリオに闇雲にテストの支店を入れ込むとマトリクスになってしま」うため、以下の制約を設けるとしています。

  1. 人の動きを中心にシナリオを作成する: ある人が抱えている問題がソフトウェアを使用することで解決することを確認する
  2. 狭く深くシナリオを書く: 広く浅くはそれ以前のテストで確認済みのはずなので、問題の出そうなところや重要な部分を確認する

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

 数学や論理に基づくテスト技法と比べて、「正解」の難しいテストと言えるでしょう。
 シナリオテストを導出するための標準的な技法は、これ以外あまり見たことがありません。たとえば鈴木三紀夫さんの2016年12月16日の一連のツイート(たとえば以下)が参考になりそうですが、「業務」とはまた違うんですよね・・・。

 結局、勉強しないといけないことがまた増えていくわけですね!

 18日目はコチラです。(12月18日の0時に公開されます)

kzsuzuki.hatenablog.com

*1:※テストのステップについては、一部だけ紹介しています。ぜひ原文をご覧になってください。

*2:「テストシナリオ」「テストシナリオ」という言葉はあまりに曖昧ですが、ここではサンプルとして示されたテストケースのようなものを意図しています。