いかにしてわれわれはセキュア開発に取り組み始めたか

Transcript

1. 2019.05.27 DevOpsという選択 いかにしてわれわれは セキュア開発に取り組み始めたか デジタルビジネス本部 セキュア開発推進・プロジェクトサポートチーム 松田 康司
2. 1 自己紹介 株式会社神戸デジタル・ラボ（KDL） デジタルビジネス本部 セキュア開発推進・プロジェクトサポート チームリーダー 松田 康司 （まつだ こうじ） ITで未来を創る 神戸デジタル・ラボ (KDL)
3. 2 いかにしてわれわれは セキュア開発に取り組み始めたか
4. 3 脆弱性診断の内製化
5. 4 脆弱性診断を内製化した結果わかったこと • 似たような診断結果が多く、同じ指摘を何度もしている • 結果の中には、修正に多くの工数がかかる指摘もある • 開発者に説明しても、その脆弱性を知らない
6. 5 KDLの取り組むセキュア開発
7. 6 OWASP SAMM
8. 7 OWASP SAMMとは ソフトウェアセキュリティ保証成熟度モデル Software Assurance Maturity Model 要件定義 設計 開発 テスト 運用 開発ライフサイクルを、よりセキュアにすることを 支援するドキュメント https://owaspsamm.org/ （v1.5 stable, v2.0 beta） https://www.jpcert.or.jp/securecoding_materials.html （v1.0 日本語）
9. 8 OWASP SAMMとは • 開発プロジェクトのセキュリティ成熟度を可視化する • セキュリティ活動の妥当性や効果の評価 • 継続改善をサポート ソフトウェアセキュリティ保証成熟度モデル Software Assurance Maturity Model 準備 調査 目標 設定 計画 立案 実行 評価 継続改善サイクル
10. 9 ビジネス機能 開発プロセスにおける主要なビジネス機能を４つのカテゴリと 12のセキュリティ対策を定義
11. 10 査定項目 セキュリティ対策ごとに、合計７７の査定項目がある
12. 11 セキュリティ対策 セキュリティ対策の例 成功指標 コスト・人員 戦略＆指標 成熟度レベルごとに実施内容を定義 具体的な成果
13. 12 OWASP SAMMを使う
14. 13 現状調査 ある開発プロジェクトのセキュリティ成熟度を可視化する セキュリティテストに大きく依存した体制
15. 14 目標設定・計画立案 組織にあった目標と計画を立てる
16. 15 実行
17. 16 セキュリティ要件（before） 顧客の指定があれば従う。
18. 17 セキュリティ要件（after） プロジェクトメンバーでセキュリティ要件 検討会議を実施し、要件を決定
19. 18 セキュリティ要件 ビジネス要件にあった脅威想定 コンプライアンス セキュリティ7要素のプロファイリング プロジェクトメンバーに共有 セキュリティ要件検討の前に・・・
20. 19 OWASP ASVS（Application Security Verification Standard） https://github.com/OWASP/ASVS/tree/master/4.0 （v4.0） https://www.jpcert.or.jp/securecoding/materials-owaspasvs.html （v3.0.1 日本語） Webアプリケーションの開発、設計、テストで必要となるセキュリティ要件
21. 20 Webシステム／Webアプリケーションセキュリティ要件書 https://github.com/ueno1000/secreq （v3.0 日本語） 安全なWebアプリケーションの開発に必要なセキュリティ要件
22. 21 コードレビュー（before） やってなかった。
23. 22 コードレビュー（after） コードレビュー負荷は激減 コード品質は、確実に上がった
24. 23 コードレビュー みんなでセキュリティ要件の検討 コードレビューは、ライブラリを使っているかどうか？ 設定が正しくされているかどうか？ どう実装するか検討。クリティカルな機能は、 共通ライブラリを使う。
25. 24 コードレビュー ◆要件 ◆設計 • 全ての入力値検証をFormManagerで行うルールとする ◆レビュー観点 • FormManager を使っていること • 文字種、文字列、形式をvalidatorに記載していること
26. 25 診断からのフィードバック 共通ライブラリ 開発者 案件開発者 脆弱性診断 ①セキュリティ要件実装 ②ライブラリ利用 ③納品前診断 ④ライブラリにFB
27. 26 結果 • 似たような診断結果が多く、同じ指摘を何度もしている • 結果の中には、修正に多くの工数がかかる指摘もある • 開発者に説明しても、その脆弱性を知らない 脆弱性診断の指摘が、劇的に減りました
28. 27 まとめ
29. 28 まとめ • 脆弱性診断の内製化がセキュア開発のきっかけ • OWASP SAMMで可視化することから始めました • セキュリティ要件を決めるだけで、コード品質も改善