情報セキュリティマネジメント 2019年 春期 午前（科目A） 問38

開発工程のセキュリティ試験【情報セキュリティマネジメント解説】

正解の理由

解法ステップ

1. 観察事項を附属書Aの該当領域に照らす
   • 主に「システムの取得、開発及び保守（A.14）」を確認する。
2. 期待される管理策を整理する
   • セキュリティ要件の定義、設計段階でのレビュー、段階的なテスト（単体・結合・システム・受入）やセキュリティテストの実施。
3. 取得すべき客観的証拠を列挙する
   • テスト計画・テストケース、テスト実施記録、欠陥管理票、設計レビュー記録、受入基準。
4. 観察事項と期待値を照合して判断する
   • セキュリティ試験が「開発終了後のみ」で、各段階の試験や設計レビューが欠落している証拠がある場合は不適合または所見として記載。
5. 監査報告書の書き方（例）
   • 「観察：セキュリティ機能の試験が開発終了後にのみ実施されていることを確認。基準：JIS Q27001 附属書A（A.14）に基づき、開発ライフサイクルの各段階での検証・試験が要求される。影響：脆弱性の早期発見ができず、変更コストおよび情報漏えい等のリスクが増大するおそれがある。改善提案：設計段階からのテスト計画とセキュリティテストケースの導入を推奨。」

選択肢別の誤答解説

• ア：誤り（監査で指摘すべき）
  • 理由：テストを開発終了後に限定すると、設計や実装段階での問題発見が遅れ、修正が困難・高コストになります。JIS Q27001の管理策はライフサイクル全体でのセキュリティ対策を求めます。
• イ：適切（指摘対象ではない）
  • 理由：開発環境自体がセキュリティ配慮されたものになっていることは、附属書Aの考え方に合致します。例えばアクセス制御やテスト用データの管理が行われていれば良い運用です。
• ウ：適切（指摘対象ではない）
  • 理由：外部委託時に委託先の活動に対して監督・監視を行い、セキュリティ観点を考慮しているのは望ましい実務です。契約や受入基準にセキュリティ要件が含まれていることが重要です。
• エ：適切（指摘対象ではない）
  • 理由：パッケージソフトの変更を必要最小限にする方針は、セキュリティ面でのリスク管理上有効です。変更が必要な場合はリスクアセスメントと検証を行う運用が求められます。

よくある誤解

• 「テストは最後にまとめてやればよい」
  • 真意：最後の一度きりのテストでは、設計段階や実装段階の欠陥を見逃しやすい。問題は段階的に小さいうちに発見する方が低コストで確実です。
• 「開発環境が整っていればセキュリティは十分」
  • 真意：開発環境の整備は重要ですが、設計レビューや段階的なテスト、脆弱性検査が伴わなければ不十分です。
• 「パッケージは改変しない方が安全」→勘違い
  • 真意：改変が少ないことは利点ですが、既知脆弱性の修正や設定調整は必要です。変更時には必ずセキュリティ検証を行ってください。

補足コラム

• 「Shift-left（シフトレフト）」という考え方があります。これはテストやセキュリティ対策をライフサイクルの「左側（設計・実装の早い段階）」に移すことを指します。早期に問題を見つけることで対応コストとリスクを大きく下げられます。
• 具体的な技術（初出時に説明）：
  • SAST（Static Application Security Testing：静的解析）— ソースコードを実行せずに解析して脆弱性を検出する手法。開発中の早い段階で有効。
  • DAST（Dynamic Application Security Testing：動的解析）— 実行中のアプリケーションに対して攻撃を模擬し挙動から脆弱性を検出する手法。統合・システムテスト段階で有効。
• 実務イメージ：開発チームは「Definition of Done（完了の定義）」にセキュリティ試験（静的解析の警告解消、脆弱性スキャンの実施、セキュリティ受入基準の満足）を含めます。これにより、"完成後に一度だけテスト"という運用を避けられます。

FAQ