[論文レビュー] Secure Scrum: Development of Secure Software with Scrum

Christoph Pohl, Hans‐Joachim Hof|arXiv (Cornell University)|Jul 10, 2015

Software Engineering Techniques and Practices参考文献 17被引用数 29

ひとこと要約

この論文では、スクラムフレームワークの拡張版として、セキュリティ実践をアジャイル開発ライフサイクル全体に統合するが、スクラムのコア構造を変更しない「Secure Scrum」を提案する。S-マーキングを導入してセキュリティ関連のバックログ項目をマークし、セキュリティタスクの分解と検証を支援することで、専門外のメンバーがセキュリティ対策を特定・実装・検証できるようにする。フィールドテストの結果、脆弱性が顕著に減少した—標準スクラムを使用するチームと比較して、Secure Scrumを採用したチーム3ははるかに少ない欠陥を示した。これは、最小限のオーバーヘッドで、より優れたセキュリティ成果を達成できることを示している。

ABSTRACT

Nowadays, the use of agile software development methods like Scrum is common in industry and academia. Considering the current attacking landscape, it is clear that developing secure software should be a main concern in all software development projects. In traditional software projects, security issues require detailed planning in an initial planning phase, typically resulting in a detailed security analysis (e.g., threat and risk analysis), a security architecture, and instructions for security implementation (e.g., specification of key sizes and cryptographic algorithms to use). Agile software development methods like Scrum are known for reducing the initial planning phases (e.g., sprint 0 in Scrum) and for focusing more on producing running code. Scrum is also known for allowing fast adaption of the emerging software to changes of customer wishes. For security, this means that it is likely that there are no detailed security architecture or security implementation instructions from the start of the project. It also means that a lot of design decisions will be made during the runtime of the project. Hence, to address security in Scrum, it is necessary to consider security issues throughout the whole software development process. Secure Scrum is a variation of the Scrum framework with special focus on the development of secure software throughout the whole software development process. It puts emphasis on implementation of security related issues without the need of changing the underlying Scrum process or influencing team dynamics. Secure Scrum allows even non- security experts to spot security issues, to implement security features, and to verify implementations. A field test of Secure Scrum shows that the security level of software developed using Secure Scrum is higher then the security level of software developed using standard Scrum.

研究の動機と目的

• 標準スクラムにおいてセキュリティが後から追加される傾向にあるという、体系的なセキュリティ統合の欠如に対処すること。
• セキュリティ専門家でないメンバーが、アジャイルスプリント内でのセキュリティ対策の特定・実装・検証を可能にすること。
• 開発ライフサイクル全体にわたりセキュリティを優先しつつ、スクラムの柔軟性とチームの自律性を維持すること。
• 攻撃コストが潜在的利得を上回る「適切な」セキュリティ水準を定義・達成すること。過剰設計を避けること。
• 実世界のアジャイルチーム環境におけるSecure Scrumの実用性・使いやすさ・有効性を評価すること。

提案手法

• 製品バックログおよびスプリントバックログ内のユーザーストーリーやタスクにセキュリティ関連の懸念を強調するS-マーキング（セキュリティアノテーション）を導入する。
• チームがセキュリティ関連のユーザーストーリーを、S-マーキング付きの具体的かつ実行可能なタスクに分解できるように支援し、実装段階でセキュリティが確保されるようにする。
• 攻撃のしやすさと潜在的利得に基づいてリスクを評価する脅威ベースの優先順位付けモデルを採用し、『適切なセキュリティ水準』の原則に整合させる。
• 訓練や管理負荷を最小限に抑えるために、軽量でスクラム互換性のあるツール（例：S-マーキング用の色付きカード）を活用する。
• 脆弱性カウントメカニズムを適用：$sp = \sum cpf(cf)$、ここで $cpf(cf)$ は脆弱性（例：SQLインジェクション、XSS、CSRF）を引き起こす関数を数える。
• 制御されたフィールド実験において、Secure Scrumを使用するチームと標準スクラムを使用するチームの間で、脆弱性数と文書化品質を比較することで有効性を評価する。

実験結果

リサーチクエスチョン

• RQ1 Secure Scrumは、チームの自律性や柔軟性を損なうことなく、スクラムフレームワークにセキュリティ実践を効果的に統合できるか？
• RQ2 非セキュリティ専門家は、S-マーキングと構造化されたタスク分解を用いて、どの程度セキュリティ対策を特定・実装できるか？
• RQ3 Secure Scrumの使用は、標準スクラムと比較して、ソフトウェアの脆弱性を顕著に減少させるか？
• RQ4 Secure Scrumは、要件およびタスク追跡の観点から、チームの生産性と文書化品質にどのような影響を与えるか？
• RQ5 脅威ベースのリスク評価を用いて、『適切なセキュリティ水準』の原則をアジャイル環境で実際的に適用できるか？

主な発見

• Secure Scrumを採用したチーム3は、標準スクラムを使用するチーム（チーム1の18件、チーム2の12件）と比較して、顕著に少ない脆弱性を示した。
• 標準スクラムを使用する両チームとも、SQLインジェクション、XSS、CSRF、不適切なセッション管理といった攻撃可能な欠陥を示した。
• S-マーキングの使用により、チーム3は14件のユーザーストーリーおよび8つのタスクグループすべてにセキュリティ関連の懸念をマークでき、セキュリティ問題の高い認知度と可視性を実現した。
• チーム3のアプローチである関連するユーザーストーリーやタスクをグループ化することで、断片化が軽減され、トレーサビリティが向上した一方で、高いセキュリティカバレッジを維持した。
• 評価結果から、Secure Scrumは理解・使用が容易であり、訓練や管理負荷が最小限に抑えられ、既存のスクラムツールにスムーズに統合可能であることが確認された。
• 非機能要件（セキュリティ、パフォーマンスなど）の追加追跡にやや生産性の低下が見られたが、そのコストを上回るセキュリティ上の利点が得られた。