Skip to content

Security in Agile Software Development.md

Latest commit

 

History

History
362 lines (276 loc) · 23.5 KB

Security in Agile Software Development.md

File metadata and controls

362 lines (276 loc) · 23.5 KB
Raw

アジャイル開発におけるセキュリティ | パターン・ランゲージ

本ドキュメントについて

本ドキュメントは脆弱性診断士スキルマッププロジェクトが作成した『アジャイル開発においてセキュリティをどのように担保するか』のヒントを過去の成功事例などを基にパターン・ランゲージを使って解説したものです。

ウォーターフォール開発では、要件定義のフェーズではセキュリティ要件があり、それに沿ったセキュアな設計や実装が行われ、脆弱性診断を行ってからリリースされます。しかし、アジャイル開発ではそれらのフェーズが明確でないこともあり、セキュリティを如何に担保するかということが疎かになることもあります。 本ドキュメントを活用して頂くことで、アジャイル開発のどの段階でどういった取り組みをすることでセキュリティを担保できるかといったヒントを得ることができます。

本ドキュメントがアジャイル開発においてセキュリティが担保される一助になればと願います。

目次

  • チームビルディング
  1. セキュリティ・チャンピオンの役割定義と任命
  2. 各自がセキュリティに責任を持ったチームビルディング
  3. セキュリティ向上のためのルール整備
  4. セキュリティスキル底上げのための開発者向けトレーニング
  • 開発計画・プロジェクト計画
  1. スプリント成果物に必要なセキュリティ要件の決定
  2. リスクに応じた脆弱性対応方針の策定
  3. 脆弱性トリアージ
  • セキュリティテスト
  1. セキュリティテストの実施タイミングと方針検討
  2. スプリント内で実施するテスト内容の策定
  3. 利用環境の脆弱性管理
  4. セキュリティテストの自動化
  • セキュリティ品質向上
  1. セキュリティの継続的向上のためのふりかえり

チームビルディング

1. セキュリティ・チャンピオンの役割定義と任命

概要

各プロダクトチームの中にセキュリティ上の問題をチェックし、開発者との橋渡しの役割を担う『セキュリティ・チャンピオン』を置くことで、セキュリティが開発工程の中に組み込まれるDevSecOpsの文化を創ろう

状況

  • セキュリティを考慮する文化がない
  • セキュリティのことをメンバーの誰もが気にしていない
  • セキュリティを主体的に考える人が誰もいない

解決したい問題

  • 機能優先のみで実装を行うことによる非セキュアなプロダクトがリリースされてしまう

解決策

  • プロジェクト立ち上げの際にメンバーの役割を決めるとき、チーム内の開発メンバーの一人にセキュリティ・チャンピオンの役割を担わせる
    • プロダクトオーナーが具体的な役割などを定義し、担当者を任命
  • セキュリティ・チャンピオンはセキュリティの専門家である必要はありませんが、開発チームにおけるセキュリティの担当者として、開発している製品やサービスにおけるセキュリティ上の問題や脅威に対して、中心となってリーダーシップを発揮しながら対処を行わなければなりません。チーム内のリソースで対応できない場合、外部ベンダーなどの利用も検討してください。
  • 具体的な役割の例としては以下が挙げられ、実現可能なチームを編成することが望ましいです。
    • セキュリティレビューの実施
    • 開発物に対する脅威分析の実施
    • 開発におけるセキュリティ要件の定義やコーディング規約などの整備
    • 検出した脆弱性の管理や問題の報告、対策の優先順位付けなど
    • セキュリティテスト・脆弱性スキャンの導入・実施・検証
    • 教育や情報の共有などによって、チーム内のセキュリティ知識の標準化やセキュリティ意識の向上を促進
    • 外部セキュリティベンダーの選定やコントロール

参考資料

2. 各自がセキュリティに責任を持ったチームビルディング

概要

開発する成果物のセキュリティ面での品質に対して各自が責任を持つようにしよう

状況

  • セキュリティチャンピオン以外のメンバーがセキュリティのことを気にしていない
  • チームビルディングを実施するときに、自分の担当範囲で責任を持つセキュリティ機能を理解していない
  • セキュリティのことをメンバーの誰もが気にしていない

解決したい問題

  • セキュリティ担当者、もしくはセキュリティチャンピオンへの負荷の集中

解決策

  • セキュリティ教育を実施し、リスクや脆弱性、対策方法に対する理解を深める様にしてください。
  • 開発時に混入したバグに関するケーススタディやコードレビューの結果などについて、チーム内で情報の共有を行いましょう。
  • セキュリティについての議論を各フェーズで実施しましょう。
    • 要件の段階で事前にリスクの洗い出しを行い、成果物に脆弱性が含まれる可能性を最小限にする。
    • 脆弱性検証を実施するタイミングを事前に検討しておく。
  • セキュリティの失敗で個人を責めないようにしましょう。
    • 仲間に対するHRT（Humility：謙虚、Respect：尊敬、信頼：Trust）の精神を大事にしよう。

参考資料

3. セキュリティ向上のためのルール整備

概要

セキュリティに関して専門家にすべてを任せるのではなく、開発時に気を付けなければならない最低限のポイントについて開発者全員が実施できるルールを話し合って整備しよう

状況

  • チーム内でのセキュリティ対策については個人に依存している

解決したい問題

  • 開発者によってセキュリティ面での品質が異なる実装が行われる

解決策

  • チーム内で話し合い、セキュリティ面での品質を担保するためのルールを整備しましょう。

    • 以下で列挙されているものの中に脆弱性の扱いに関するルールを組み込みましょう。
      • コーディングルール
      • コードレビュー手法
      • 承認フロー
      • デプロイまでのフロー
      • セキュリティテストのルール
      • 脆弱性発見時の対応フロー
      • 脆弱性管理
      • 構成管理
    • 例:
      • 入力値に対してエスケープ処理を実施するなど開発者が開発時に気を付けるポイントをコーディングルールとして組み込む
      • 脆弱性の検出時に、どのタイミングで誰が対応するかなどについて脆弱性発見時の対応フローに組み込む

  • 整備したルールはチーム内に周知し、可能であれば見直しの機会などを設けましょう。

4. セキュリティスキル底上げのための開発者向けトレーニング

概要

セキュリティに関して専門家にすべてを任せるのではなく、開発時に気を付けなければならない最低限のポイントについてはトレーニングを受けることで開発者全員が理解できるようになろう。

状況

  • 開発者によってセキュリティに対する知識にばらつきがある
  • 開発者にセキュリティの知識がない

解決したい問題

  • 開発者によってセキュリティ面での品質が異なる実装が行われる
  • セキュリティについて詳しい個人に負荷が集中する

解決策

  • 次のようなセキュリティトレーニングを実施しましょう。
    • 同業他社のインシデント事例
    • 発生しやすい脆弱性について
    • セキュアな要件定義、設計、コーディング、テストについて
    • セキュリティテストの種類（SAST,DAST…）
  • 自社でトレーニングを実施できない場合には、外部のコンテンツを利用したり、トレーニングを受講しましょう。

参考資料

開発計画・プロジェクト計画

5. スプリント成果物に必要なセキュリティ要件の決定

概要

スプリント期間内に開発する成果物の完成の定義には、機能要件だけでなく、実装しておかなければいけないセキュリティ要件とそのテスト項目についても含めておこう

状況

  • セキュリティについての要件が曖昧なままスプリントが始まる

解決したい問題

  • 十分なテストがされないまま開発が進み、脆弱性診断などで多くの脆弱性が発見され手戻りが多くなる
  • 脆弱性が残ったままの非セキュアなプロダクトがリリースされてしまう

解決策

  • スプリントプランニングで成果物の完成の定義を検討するとき、Web システム／Web アプリケーションセキュリティ要件書やOWASP アプリケーションセキュリティ検証標準 4.0を参考に、成果物が実装しておかなければいけないセキュリティ要件を定義してください。
  • これらは一般的なセキュリティ要件が書かれており、スプリントで開発する対象によっては無関係な項目も含まれていますので、開発対象に応じて必要な項目を選定してください。
  • たとえば、入力値の検証や出力時のエスケープなどは、どのような場合でも必要になるでしょう。認証やセッション管理などは、それらの機能を実装するスプリントの場合にのみ必要になるでしょう。
  • スプリントのセキュリティ要件が決まったら、Webアプリケーション脆弱性診断ガイドラインを参考に、それぞれに対応するテスト項目も併せて検討してください。

参考資料

6. リスクに応じた脆弱性対応方針の策定

概要

システムのアーキテクチャや扱う情報、サイバー攻撃のトレンドなどのリスクに応じて脆弱性の対応方針を決めよう

状況

  • どの脆弱性に対応するべきか判断できない

解決したい問題

  • 重大な脆弱性が残ったままの非セキュアなプロダクトがリリースされてしまう

解決策

  • リスクの大きさの判断基準を決めましょう。具体的には次のような基準が挙げられます。
    • CVSSの算出方法でリスクの大きさの判断基準を設定する
      • 脆弱性の危険度（CVSS基本評価値）
      • 攻撃コードが出回っているかどうか（CVSS現状評価値）
      • システムにとって大きな影響がある脅威かどうかで判断する（CVSS環境評価値）
    • WAFなど緩和策が導入され、緩和可能な状態かどうか
  • 判断基準に応じたリスクの対応方針を決めましょう。
    • 例：CVSS7.0以上なら即日対応にする
    • 例：脆弱性の種類で対応方針を決める

7. 脆弱性トリアージ

概要

発見した脆弱性をチケット管理し、対応の優先順位を決めよう

状況

  • 脆弱性診断を始めたところ、スプリント内で捌ききれないほどの大量の脆弱性が発見される

解決したい問題

  • 発見した脆弱性が多く対応しきれない
  • 発見した脆弱性をどれから対応したら良いのかわからない
  • 発見した脆弱性が多すぎて優先度付けできない
  • 発見した脆弱性の内、対処が必要なものの選別ができない

解決策

  • 脆弱性のリスクを分析しましょう。
    • 参考：リスクに応じた脆弱性の対応方針を決めよう
  • 脆弱性をチケット管理しましょう。
  • 修正のためのコストを分析しましょう。

参考資料

セキュリティテスト

8. セキュリティテストの実施タイミングと方針検討

概要

プロジェクトの特性を考慮し、テストの実施タイミングや内容を計画しておき、開発したアプリや機能の安全性を適切に確認できるようにしよう

状況

  • プロジェクト内でいつセキュリティテストを実施したら良いのかわからない

解決したい問題

  • 適切ではないタイミングでテストを行ってしまい非効率な開発が行われる
  • セキュリティテストの計画が組み込まれていない。あるいは不十分である。
  • リリース前にまとめて実施となった場合にスケジュールに間に合わない
  • セキュリティテストを都度実施しなくていいか判断できない

解決策

  • 開発者、テスターと話し合い、セキュリティテストのタイミングや実施するテストの種類、内容の概要を計画として明記します。
  • テストによっては設計・製造に組み込んだり、CI/CDツールで自動実行されるようにするほうが良いものもあれば、リリース直前に実施するほうが望ましいテストもあるため、これらを抽出します。
  • プロジェクト内でのセキュリティテスト戦略の一例

    • 開発前

      • プロダクトのリリースサイクルにあったセキュリティ診断の計画を立てる
      • リリース前の脆弱性診断を外注するかどうかを決める

    • スプリント中

      • スプリントの成果物が満たすべきセキュリティ要件通り実装されているか確認
        • DAST等のツールを用いる
        • DASTがカバーできない箇所を手動で診断する

    • リリース前

      • 脆弱性診断士による診断を実施する

    • 運用開始後

      • 環境の既知の脆弱性のスキャンを実施する

9. スプリント内で実施するテスト内容の策定

概要

スプリントごとに行うテストを決めることで、セキュリティテストの実施漏れをなくす

状況

  • スプリント内でどのようなセキュリティテストを実施したら良いのかわからない

解決したい問題

  • 本来必要なセキュリティテストが行われていない
  • 不要なセキュリティテストが行われていてコストがかさんでいる

解決策

  • 毎回のスプリントごとに実施するテストを決めましょう。スキャナーを使用するなど自動的に実施されるセキュリティテストを導入しましょう。この段階では、脆弱性をゼロにするのが目的ではなく、低減することが目的です。
  • スプリントで追加・修正した機能に応じて実施するテストを決めましょう。スキャナーがカバーしない認可制御やビジネスロジックのテストは手動で行ってください。脆弱性診断ガイドラインで、スプリントで作成項目に関連したセキュリテイテストの項目を明らかにした上で、スプリント内でどのテストを行うかを考えましょう。
  • モジュール単体で実行できるテストについては、スプリント単位でセキュリティテストが完了していることが理想的です。

参考資料

10. 利用環境の脆弱性管理

概要

自分たちが管理すべき環境（OS、フレームワーク、データベース、アプリケーション、ライブラリなど）に脆弱性がないかを確認し、対応状況を確認しよう

状況

  • 現在利用している環境の状態が管理できていない
  • 運用開始後に脆弱性の最新情報の取得と管理が行われていない
  • 脆弱性の最新情報の取得と管理が一元化できていない

解決したい問題

  • 既知の脆弱性が残ったままリリースされている

解決策

  • 情報源を定期チェックしましょう。
    • JVN, JPCERT/CC, IPA、Mitre、各ベンダー
  • 脆弱性スキャナを定期的に利用しましょう。
    • 構成情報を作成、管理する
    • ソフトウェア・コンポジション解析（SCA）
      • Black Duck、Fortify SCA、CodeSentry、CAST Highlight、Contrast OSS、Checkmarx SCA、FlexNet Code Insight、Synk、VeraCode、ASoC
    • 脆弱性スキャナ
      • Vuls、Nessus、yamory、OpenVAS(GVM)
    • コンテナの脆弱性管理
      • Trivy、Tenable.io

11. セキュリティテストの自動化

概要

セキュリティテストを効率よく実施するためには自動化ツールの導入が必要となります。開発環境、体制にとって適切な最適な自動化ツールを選択し、効率的に実施しよう

状況

  • セキュリティテストに時間が掛かる
  • セキュリティテストをすべて手動で行っている
  • セキュリティテストを効率的に行えていない

解決したい問題

  • スプリント内でWebアプリケーションの脆弱性が効率よく見つからない
  • スプリント内で必要なセキュリティテストが終わらない
  • セキュリティテストの品質にばらつきがでる

解決策

  • すべての脆弱性がスキャナーで発見できる訳ではありませんが、スキャナーを利用することで一部の脆弱性発見について効率化が図れます。
  • 開発環境、体制、運用方法によって最適な自動化ツールは異なります。以下の観点で適切なツールを決定しましょう。
    • 自分たちの開発工程に組み込みやすいか
    • 脆弱性の誤検出が少ないか
    • 脆弱性のトリアージがしやすいか
    • 診断したい対象を診断できるか
    • 運用しやすいか・使いやすいか
    • 費用対効果に見合うか
    • ツールのサポート体制
  • DAST：脆弱性スキャナを利用しよう
    • オープンソース: OWASP ZAP
    • 商用:Vex(ユービーセキュア社)、AeyeScan(エーアイセキュリティラボ)、AppScan（HCL)
    • スプリント内で追加・修正があった機能に対して実施すると効率が良い
  • SASTを利用しよう

参考文献

セキュリティ品質向上

12. セキュリティの継続的向上のためのふりかえり

概要

反復的に繰り返される開発の中で、レトロスペクティブなどを活用し、セキュリティを実装するプロセスも見直しを行い、サービス・プロダクトのセキュリティを向上させよう

状況

  • スプリントごとに同じような脆弱性が繰り返し作り込まれてしまう

解決したい問題

  • セキュリティテストで検出される脆弱性を減らしたい
  • 脆弱性対応にかかるコストが減らない、あるいは増大していく
  • 手戻りの防止

解決策

  • スプリントレトロスペクティブを活用し、スプリント内で実施されたセキュリティ実装・セキュリティテストを振り返ります。
    • 開発者が中心となって行い、スクラムマスターは支援します。
  • 例えば以下のテーマで、セキュリティに関係する部分も話し合い、次のスプリント以降で改善すべき項目を抽出し、実行していきます。
    • コーディングルールの見直し
    • テスト方法の見直し
    • メンバーの意識の見直し
    • 脆弱性対処基準の見直し
    • リソース配分の見直し