スポンサードリンク
ベリサーブ殿主催の「セキュリティ＆テスト設計支援セミナー」に参加しました
以前、テストPMO設置とテスト進捗管理の共有の話を聞いたことがあって心に残っており知人が在籍してる＆会社から近いからということで参加
セキュリティ対策
標的型攻撃がトップ
それ以外には
内部不正、ウェブサービスから個人情報ぬきとり、IoT機器の脆弱性
対策
内部へ侵入されることを想定した多層防御
継続的なパッチ適用
初期パスワードの変更
何から着手？
現状を知る 棚卸し リスクの認識
WEBサイトのバージョンは出さないようにする
ツール利用して脆弱性チェック（nmapの例）
感想と所見
ISMSの考え方を知っていればマネジメントしやすそう
あとはツールへの理解が必要
セキュアコーディング
WEBのみならず組込も大変
WAF 穴に通さない
ペネトレーションテスト 穴を見つけて塞ぐ
セキュアコーディング 穴を作らない
あらかじめ脅威を想定した上で意図しない利用かされた場合でも想定通り動くプログラムを書くこと
ベストプラクティスが出ている
セキュリティポリシーを実現するための設計をする
信頼できないインプットデータの検証とアウトプットデータの無害化
できるだけ単純に
くるものを拒む（ホワイトリスト）
防げなくても被害を最小限に抑える（アクセス制限）
セキュアコーディング標準あり SEI CERT
コーディング前に評価方法を決めて評価項目をコーディング規約に含める
静的解析ツールを利用する
第三者レビューを行う
感想と所見
セキュリティ関連の話題だったが他のものでも同じかな
作業前に、評価項目を決めてルールに盛り込む
スポンサードリンク
テスト設計支援
テスト設計はちゃんとできているか
何を確認したいテストケースか
どんな条件を組み合わせているか
条件や組み合わせは網羅されているか
作った人しかわからない
テストが生まれた理由がわからない
不要なテストがわからない
属人化したノウハウ
テスト分析、設計の方法論の明確化
プロセスの標準化
方法論について
機能が達成されるか
想定外、弱点などさまざまな観点で問題が起きないか
テスト対象の仕様を理解
テスト観点の抽出
機能とテスト観点の対応付け
テスト項目をカテゴリ分けして考える
testructureの紹介
仕様からテスト観点を作り込み
機能特性からテスト観点を追加する
機能×観点マトリックス
因子と水準（組み合わせ方法など）を決めてテストケースを自動生成
整合性を確認できる仕組である
トレーサビリティが取れているので仕様書が変更になった時の注意点も明確になる
感想と所見
テスト観点とテストシナリオを掛け合わせてテスト項目におとしこめているかどうかが肝
マトリックスで整理してるのは同感
観点の洗い出しは経験がいるがドキュメント化されていれば理解が早くなる
全体を通して
品質は１日にして成らずだけど
いい方法やベースになる考え方、ツールを理解したな
