4 Enemies of DevSecOps 2016
•10 gostaram•2,234 visualizações
Denunciar
Compartilhar
「経営課題としてのITセキュリティ DevSecOpsに立ち塞がる４つの問題」 日本セキュリティ・マネージメント学会 (JSSM 30th 記念事業)にともなう講演会で用いたスライドです。 スピーカー：岡田良太郎 OWASP Japan WASForum Hardening Project Hackademy 株式会社アスタリスク・リサーチ
Mais conteúdo relacionado
Mais procurados
Mais procurados(20)
Destaque
Destaque(20)
Similar a 4 Enemies of DevSecOps 2016
Similar a 4 Enemies of DevSecOps 2016(20)
![[AWS Summit 2012] スポンサーセッション#5 Securing your journey to the cloud － 企業システムのAW...](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-sponser06-20120914-121001101548-phpapp01-thumbnail.jpg?width=768&fit=bounds)
![20220710_[JPN]Japan_Forward_KeynoteDeck.pptx.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20220710jpnjapanforwardkeynotedeck-221111061712-b3782658-thumbnail.jpg?width=768&fit=bounds)
Mais de Riotaro OKADA
Mais de Riotaro OKADA(10)
Último
Último(11)
4 Enemies of DevSecOps 2016
- 1. 4 enemies of DevSecOps 岡田良太郎 riotaro@owasp.org
- 3. Faculty of Business Breakthrough (BBT) 「教養としてのサイバーセキュリティ」
- 5. ビジネス環境は騒ぎ始めている “2013年、監査した96% に１つ以上の深刻な脆弱性” - Cenzic Vulnerability Report 2014 報告されたセキュリティ問題の95% はアプリケーション - NIST グローバルでは…コンプライアンス・規制・業界の動き – “データ”を安全に • PCI DSS, HIPAA, SOX, California Security Breach Information Act (SB-1386)
- 7. DevSecOps = DevOps + Sec ビジネス要件 カイハツ 運用 セキュリティ ウォーター フォール アジャイル DevOps DevSecOps !
- 8. DevSecOps 4 factors • ネットワーク セキュリティ • 脆弱性対応 • オープンソース ソフトウェア • コンプライアンス 「カエサルの死」（ヴィンチェンツォ・カムッチーニ）
- 10. セキュリティ支出の90%は、わずか10%の 攻撃にしか対応していない Sources: Gartner, OWASP Network Server Web Applications % of Attacks % of Dollars 90% セキュリティ攻撃 セキュリティ支出 75% 25% 10% 攻撃の７５％ はアプリケー ションレイヤー。 ８０％以上の ウェブサイトは 脆弱性を抱え ている インターネットのア プリケーションの安 全性に気を配って いない。 ネットワーク予算が ITの大半に費やさ れている。
- 11. Network security or Application Security L7 =$
- 12. CSC-1 許可された機器と無許可の機器の資産一覧 CSC-2 許可されたソフトウェアと無許可のソフトウェアの資産一覧 CSC-3 モバイル装置、ラップトップ、ワークステーション、サーバでの、 ハードウェアおよびソフトウェアのためのセキュアな構成 CSC-4 継続的な脆弱性診断と改善 CSC-5 管理者権限のコントロールされた使用 CSC-6 セキュリティ監査ログの保守、モニタリング、および分析 CSC-7 メールとウェブブラウザの保護 CSC-8 マルウェアの防御 CSC-9 ネットワークポート、プロトコル、サービスの制限とコントロール CSC-10 データ復旧能力 20 Critical Security Controls for Effective Cyber Defense – Version 6より | https://www.sans.org/critical-security-controls 12
- 13. Report NRI Secure Information Security Report 2015
- 14. Report NRI Secure Information Security Report 2015
- 16. 自作アプリケーションとOSS
- 17. 自作アプリケーションと パッケージ, クラウドサービス, OSS, 3rd party
- 19. IoT Open Source “Heat Map” http://www.rtcmagazine.com/articles/view/105734
- 20. Error 混入率 “Industry avg: 1-25 errors per 1000 lines” “Microsoft: after 10-20 testing, 0.5 error per 1000 lines” - S. McConnell CODE COMPLETE 第2版
- 21. Error 混入率 Lines of code • WordPress: 423,759 • PHP: 3,617,916 • Apache: 1,832,007 • Linux: 18,963,973
- 22. 1. 利用状況把握、2. 自動更新テスト、3. アップデート http://codezine.jp/article/detail/9608?p=4 OWASP Dependency Check
- 23. 1. 利用状況把握、2. 自動更新テスト、3. アップデート http://qiita.com/sadayuki-matsuno/items/0bb8bb1689425bb9a21c Vuls
- 25. ©2016 Asterisk Research, Inc.25 ー 一般教養としてのセキュリティで今、いちばん情報が足りない分野はなんでしょうか？ 設計・開発段階からセキュリティの機能を組み込む「セキュアプログラミング」だろう。… すべてのプログラマーがセキュアプログラミングを常識として知っているべきだと思うが、 残念ながらセキュアプログラミングを学ぶための情報は限られている。 山口 英 奈良先端科学技術大学院大学教授, JPCERT/CC設立者, 内閣官房初代情報セキュリティ補佐官 http://itpro.nikkeibp.co.jp/atcl/interview/14/262522/090700192/?ST=management&P=4
- 26. 脆弱性類型の複雑さ •TOTAL CVE IDs: 79475 (2016/12) http://cve.mitre.org •http://cwe.mitre.org •SNS, Cloud, Bigdata, IoT, マイナンバー…
- 27. OWASP Top 10 容易 x 甚大な影響を及ぼす脆弱性。 27 A1 – インジェクション A2 – 認証とセッション管理の不備 A3 – クロスサイトスクリプティング (XSS) A4 – 安全でないオブジェクト直接参照 A5 – セキュリティ設定のミス A6 – 機密データの露出 A7 – 機能レベルアクセス制御の欠落 A8 – クロスサイトリクエストフォージェリ(CSRF) A9 – 既知の脆弱性を持つコンポーネントの使用 A10 – 未検証のリダイレクトとフォーワード
- 28. OWASP Top 10 2010-> 2013
- 29. 大人気 OWASP Top 10 ©2016 Asterisk Research, Inc.29 出典：SANS Institute (2015)
- 32. テスト (DAST) 直す 隠す無視・ あきらめ テスト (SAST) 開発サイドの悩み アプリケーションセキュリティスキ ルとツールの不足 予算配分管理の欠如 デリバリー再優先 セキュリティチームの悩み 全アプリケーション資産の把握がで きていない 開発、セキュリティ、事業部のサ イロ化によるコミュニケーションコ スト増 脆弱性修正すると動かなくなるこ とへの恐れ 出典：SANS Institute (2015) Q. “Top Challenges for Builders and Defenders ” ? 間際のテストではオワコン
- 33. クルマ 33
- 34. 脆弱性検査 ? |©Asterisk Research, Inc.34 フェーズ Percent 企画・要件定義フェーズ 53.4% 設計フェーズ 16.5% 開発中 14.6% コードのチェックイン 4.9% リリース前 8.7% Other 1.9% 出典：SANS Institute (2015)
- 38. 9．セキュリティフレームワークやライブラリの活用 Spring Apache Shiro Django Security Flask Security 攻撃されやすい ”フレームワーク”もある
- 39. 原因 → 結果 正しい設計とコーディング → 脆弱性根絶。 39 OWASP Top 10 1:インジェクショ ン 2:認証とセッショ ン管理の不備 3:クロスサイトス クリプティング 4:安全でないオ ブジェクト直接参 照 5:セキュリティ設 定のミス 6:機密データの 露出 7:機能レベルの アクセス制御の 欠落 8:クロスサイトリ クエストフォー ジェリ 9:既知の脆弱性 を持つコンポーネ ントの使用 10:未検証のリダ イレクトとフォ ワード ProactiveControls 1: クエリのパラメータ化 ✔ 2: エンコード処理 ✔ ✔ 3: 入力値検証 ✔ ✔ ✔ 4: 適切なアクセス制御 ✔ ✔ 5: アイデンティティ及び認証制御 ✔ 6: データ及びプライバシー保護 ✔ 7: ロギング、エラーハンドリング、侵入検知 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ 8: フレームワークとセキュリティライブラリ の活用 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ 9: セキュリティ要件の考慮 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ 10: セキュリティ設計 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
- 40. Proactive vs Reactive Proactive 予防 脆弱性を悪用されないよう にあらかじめ対策 • 脅威査定による防御計画 • 実装の強化 • 異常の早期発見の仕組み の導入 Reactive 治療 脆弱性を悪用されてからの 事後対応 • システム修正、実装改善 • システムの回復 • 可用性の維持あるいは遮 断
- 43. https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project • アタックサーフィスの概説 • 脅威エージェント • 攻撃の経路（アタックベクター） • セキュリティの弱点 • 技術面のインパクト • ビジネス面のインパクト • 脆弱性の例 • 攻撃の例 • この問題を避けるガイダンス • OWASP、他のリソース・参照情報 • 製造者、開発者、消費者それぞれ が考慮すべきことのリスト I1 安全でないウェブインターフェース I2 欠陥のある認証・認可機構 I3 安全でないネットワークサービス I4 通信路の暗号化の欠如 I5 プライバシー I6 安全でないクラウドインターフェース I7 弱いモバイルインターフェース I8 設定の不備 I9 ソフトウェア・ファームウェアの問題 I10 物理的な問題 OWASP Internet of Things Top 10 もっとも甚大なIoTセキュリティへのアタックサーフィス
- 44. Security Touch points アプリケーションが適切な安全性を 持っているかを保証できるよう各段階で働く 犯罪 ケース セキュリティ 要件 脅威 分析 リスクベース テストプラン コード 検査 ペネトレーション テスト ビルド 品質分析 セキュリティ 運用 テスター構築担当 運用担当者ビジネス担当オーナー
- 45. コンプライアンス
- 46. アプリケーションセキュリティ実施の強い動機 46 Drivers for AppSec Programs Response Percent コンプライアンス、内部監査、調査レポートの率直な指摘 71.5% 漏洩時の経済的打撃に対するリスクベースの意識 69.6% 顧客への「当然の品質」としての魅力提示 39.9% セキュリティ・インシデントの指摘 36.7% 業界の予算、ROI、TCO比較による 33.5% Couching security as a direct “enablement” for new applications 30.4% Other 1.3% 出典：SANS Institute (2015)
- 47. 他業界のビルド・イン・セキュリティ例： PCI DSSコンプライアンス 47 PCI DSS 3.0要件(引用) 要件6 安全性の高いシステム とアプリケーションを開 発し、保守する 要件6は、現在および変化し続ける脆弱性、および安全なコード化ガイドラインを反 映させるため要件が追加・更新されています。開発環境、開発者トレーニングに関 する要件が更新されています。また、コーディング実践に関する要件が追加されて います。 要件 11: セキュリティシステムお よびプロセスを定期的 にテストする。 要件11では、発展型要件、追加のガイダンス、明確化と多角的に要件が発展して います。特に、脆弱性テストには期間（四半期ごと）のみならず、訂正内容を検証 するための繰り返しテストの要件についても明確化されました。 要件12 すべての担当者の情 報セキュリティに対応 するポリシーを維持す る。 要件12では、2.0に引き続き、担当者教育の重要性が強調されています。入社時、 また年ごとに行うよう規定されています。
- 48. 他業界のビルド・イン・セキュリティ例： HIPAA コンプライアンス + HITECH法 48 HIPAA Privacy Rule Security Rule Breach Notification Rule Patient Safety Rule https://www.ibm.com/developerworks/jp/cloud/library/cl-hipaa/ http://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
- 52. The biggest barrier is… ©2015 Asterisk Research, Inc.52 RMS Titanic departing Southampton on April 10, 1912. (Photo: Creative Commons)
- 53. |©2015 Asterisk Research, Inc.53 NISTIR-8151 Dramatically Reducing Software Vulnerabilities Report to the White House Office of Science and Technology Policy Dramatic Estimates of software vulnerabilities are up to 25 errors per 1000 lines of code. These approaches have been selected for the possibility of getting to 2.5 errors per 10000 lines of code. 3. Measures and Metrics 指標の使用を奨励します。 プロセスを継続的に改善するこのアプローチは、 最高水準の成熟度モデルにあります。 メトリックを使用すると脆弱性は大幅に軽減します。
- 54. DevSecOps Metric 1. P = 開発プロセス 2. S = ソフトウェアの検証と分析 3. E = 復元力のある実行環境 Aは保証の価値、 pはプロセスの知識から得られる保証 sは静的および動的分析からの保証 eは厳密な実行環境から得られる保証 A = f（p, s, e） |©2015 Asterisk Research, Inc.54
- 55. OWASP SAMM ソフトウェアセキュリティ保証成熟度モデル ソフトウェアセキュリティ保証成熟度モデル http://www.opensamm.org |©2015 Asterisk Research, Inc.55 グローバルのOWASP コミュニティが策定 ・ 日本語訳は経済産業省のプロジェクトで翻訳
- 56. SAMM 4カテゴリ・12アクティビティに、成熟度別のベス トプラクティスを定義し、それをアセッサが評価すること により定量化 合計77チェック項目で開発体制の成熟度を評価し、開発の組織の全体像及び特徴を把握 開発アクティビティのガバナンスに関するコアな知識の深化 バランスのよいチームビルディング / 教育 / 運用システムの介入 必要な部分の特定 ©2015 Asterisk Research, Inc.56 ソフトウェア開発 ガバナンス 構築 検証 デプロイ OpenSAMMの特徴 ビジネス機能と各フェーズでのセキュリティ対策： 戦略＆指標 ポリシー＆コンプライアンス 教育＆指導 脅威の査定 セキュリティー要件 セキュアなアーキテクチャ 設計レビュー コードレビュー セキュリティテスト 脆弱性管理 環境の堅牢化 運用体制の セキュリティ対応
- 57. SAMM v1.1 |©2015 Asterisk Research, Inc.57
- 58. ガバナンス・構築・検証・配備の４カテゴリ 12アクティビティのスコアカードによる可視化 |©2015 Asterisk Research, Inc.58 計画ベンチマーク スコアカード
- 59. SO WHAT
- 60. DevSecOps 4 factors • ネットワーク セキュリティ • 脆弱性対応 • オープンソース ソフトウェア • コンプライアンス 「カエサルの死」（ヴィンチェンツォ・カムッチーニ）
- 61. セキュリティは ITの 総合格闘技 © MMA
- 63. 最近、日本語でました https://downloads.cloudsecurityalliance.org/whitepapers/Security_Guidance_for_Early_Adopters_of_the_Internet_of_Things.pdf * OWASP IoT Top 10を参照している
- 64. https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project • アタックサーフィスの概説 • 脅威エージェント • 攻撃の経路（アタックベクター） • セキュリティの弱点 • 技術面のインパクト • ビジネス面のインパクト • 脆弱性の例 • 攻撃の例 • この問題を避けるガイダンス • OWASP、他のリソース・参照情報 • 製造者、開発者、消費者それぞれ が考慮すべきことのリスト I1 安全でないウェブインターフェース I2 欠陥のある認証・認可機構 I3 安全でないネットワークサービス I4 通信路の暗号化の欠如 I5 プライバシー I6 安全でないクラウドインターフェース I7 弱いモバイルインターフェース I8 設定の不備 I9 ソフトウェア・ファームウェアの問題 I10 物理的な問題 OWASP Internet of Things Top 10 もっとも甚大なIoTセキュリティへのアタックサーフィス
- 66. 社会価値 • 協調領域 • 競争領域 • あたらしい コンセンサス 連携 • 新しいリスク • 従来手法の見直し • 解決策 個別の 問題 • 問題対応？ • 事前対策？
- 68. OWASP Japan Chapter Lead
Notas do Editor
- アプリケーションがビジネスに貢献する役割は増えています。 それぞれに問題が生じると、とたんにビジネスに影響が出ます。 いくつか例を挙げられますか？ システムをささえる基盤を考えるとき、ネットワークセキュリティはOS、ネットワーク、サーバを守ります。 アプリケーションセキュリテイは、ビジネス機能に直結した機能とその運用に焦点をあてます。
- http://searchcio.techtarget.com/definition/California-Security-Breach-Information-Act
- ネットワークレイヤーHTTP 80, 443ポートを有効にするはず SSLですら、トンネルを提供するだけで、攻撃者のトラフィックを保護することにさえなる。
- ネットワークレイヤーHTTP 80, 443ポートを有効にするはず SSLですら、トンネルを提供するだけで、攻撃者のトラフィックを保護することにさえなる。
- 公開されているウェブサイトの把握ができていないって！
- Steve McConnell, “Code Complete,” 2nd Microsoft Press, 2004. ISBN: 0735619670 https://www.openhub.net/p/wordpress https://www.openhub.net/p/apache
- Steve McConnell, “Code Complete,” 2nd Microsoft Press, 2004. ISBN: 0735619670 https://www.openhub.net/p/wordpress https://www.openhub.net/p/apache
- 課題１ Mitre: マイターは脆弱性と危険性の１０００以上のリストがある。
- (From the Open Web Application Security Project – www.owasp.org)
- HIPAA 違反には州政府レベルと連邦政府レベルの両方で、刑事処分や民事処罰が課せられます。しかもこれらの罰則は、HITECH 法でさらに厳しくなっています。連邦政府レベルでは、民事上の罰金として 1 年間最大 150 万ドルが課せられ、刑事処分については 10 年の懲役と、最大 25 万ドルの罰金が課せられることもあります。これとは別に、州政府による罰則もあります。
- About One hundred years ago, the “unsinkable” Titanic foundered after striking an iceberg off the coast of Newfoundland. More than 1,500 people died in what became one of the deadliest maritime accidents ever. Several factors contributed to this massive death toll, but perhaps the most critical was that there simply weren’t enough lifeboats. The ship carried 2,224 people, but fewer than half of them could squeeze into the boats. As we know, passengers who didn’t get a spot in one of those lifeboats quickly died in the freezing waters of the North Atlantic. What’s less well known is that the Titanic’s supply of lifeboats was in full compliance with the British marine regulations in force at time. The law required the ship to carry 16 lifeboats; the Titanic actually had 20 lifeboats. The ship’s owners did a good job of providing enough boats to address the regulatory risk of noncompliance. Unfortunately, meeting regulatory requirements did little to prevent the tragic loss of life. This is a case of misperception of risk.
- <mission: ソフトウェアセキュリティについて 意思決定をする人のために役立つ十分な情報を 提供すること> 技術者、ビジネスオーナ、ユーザ ソフトウェアに関する技術・セキュアプロセス 現状理解・普及啓発・適用推進 オープンソース・コミュニティベースで実現