セキュア開発の<s>3つの</s>敵
•Download as PPTX, PDF•
1 like•1,030 views
IoTxHealthcare Hackathon Pre-eventにて公開した講演資料。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to セキュア開発の<s>3つの</s>敵
Similar to セキュア開発の<s>3つの</s>敵 (20)
More from Riotaro OKADA
More from Riotaro OKADA (11)
セキュア開発の<s>3つの</s>敵
- 5. OWASP – Open Web Application Security Project <mission: ソフトウェアセキュリティについて 意思決定をする人のために役立つ十分な情報を 提供すること> – 技術者、ビジネスオーナ、ユーザ – ソフトウェアに関する技術・セキュアプロセス – 現状理解・普及啓発・適用推進 – オープンソース・コミュニティベースで実現
- 6. Red pill, or blue pill? From : MATRIX
- 8. Enabling Security ©2016 Asterisk Research, Inc. 8 ー 一般教養としてのセキュリティで今、いちばん情報が足りない分野はなんでしょうか？ 設計・開発段階からセキュリティの機能を組み込む「セキュアプログラミング」だろう。… すべてのプログラマーがセキュアプログラミングを常識として知っているべきだと思うが、 残念ながらセキュアプログラミングを学ぶための情報は限られている。 山口 英 奈良先端科学技術大学院大学教授, JPCERT/CC設立者, 内閣官房初代情報セキュリティ補佐官 http://itpro.nikkeibp.co.jp/atcl/interview/14/262522/090700192/?ST=management&P=4
- 10. Security: Network or Application L7
- 11. Security: Network or Application
- 12. Security: Network or Application Sources: Gartner, OWASP Network Server Web Applications % of Attacks % of Dollars 90% セキュリティ攻撃 セキュリティ支出 75% 25% 10% 脆弱なウェブアプリケーション、67%
- 13. Intel Edison SD Card size PC Bluetooth/LE Wi-Fi 24x32x2.1mm 22nm 500MHz Linux 1GB RAM 4GB storage Dual Core IA “コンピュータやスマートフォンのみならず、椅子や コーヒーメーカーや、マグカップまでがネットワーク デバイスになります。” http://www.intel.com/content/www/us/en/do-it-yourself/edison.html
- 15. Privacy-by-Design Principals • Proactive not Reactive: • Preventive not Remedial • Privacy as the default • Privacy Embedded • Full Functionality • End-to-end Security • Visibility and Transparency • Respect for User Privacy • Privacy Impact Assessment
- 20. Security Alarm & Environmental Sensors
- 21. Elements of a Protection Architecture for IoT
- 22. 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セキュリティへのアタックサーフィス
- 23. IoT は ITの 総合格闘技だ © MMA
- 24. Requirements to use ネットワーク・セキュリティ • 許可された通信から情報は窃取されている。 – “ファイアウォール” はL7を理解しない。役割が異なる • システムを総合的に守る価値 – ネットワーク・セキュリティとアプリケーションセキュリティ は役割が異なり、バランスよく投資しなければならない。 • ネットワーク・セキュリティの人材と、アプリケーショ ン・セキュリティの人材ではスキルセットが異なる – 取り扱っているものは、単なる”データ”ではない。
- 26. アプリケーション
- 27. パッケージ, クラウドサービス, OSS, 3rd party
- 28. IoT Node Types and Data Paths http://www.rtcmagazine.com/articles/view/105734
- 29. IoT Open Source “Heat Map” http://www.rtcmagazine.com/articles/view/105734
- 31. Requirements to use Open Source Software • プロジェクトとコードをチェックせよ – Openである意味はそこにある • 組み込むならOSSのコードもテストせよ – Found issue? Shut up and fix it! • アップデートが重要 – モジュール、コードいずれのレベルでも
- 33. テスト (DAST) 直す 隠す無視・ あきらめ テスト (SAST) 開発サイドの悩み アプリケーションセキュリティスキ ルとツールの不足 予算配分管理の欠如 デリバリー再優先 セキュリティチームの悩み 全アプリケーション資産の把握がで きていない 開発、セキュリティ、事業部のサ イロ化によるコミュニケーションコ スト増 脆弱性修正すると動かなくなるこ とへの恐れ 出典：SANS Institute (2015) Q. “Top Challenges for Builders and Defenders ” ? 間際のテストではオワコン
- 34. 脆弱性検査 ? | Enabling Security | ©Asterisk Research, Inc. 34 フェーズ Percent 企画・要件定義フェーズ 53.4% 設計フェーズ 16.5% 開発中 14.6% コードのチェックイン 4.9% リリース前 8.7% Other 1.9% 出典：SANS Institute (2015)
- 35. 開発プロセスで最も参照されているガイドライン Enabling Security ©2016 Asterisk Research, Inc. 35 出典：SANS Institute (2015)
- 36. 容易 x 甚大な影響を及ぼす脆弱性。 Enabling Security ©2016 Asterisk Research, Inc. 36 A1 – インジェクション A2 – 認証とセッション管理の不備 A3 – クロスサイトスクリプティング (XSS) A4 – 安全でないオブジェクト直接参照 A5 – セキュリティ設定のミス A6 – 機密データの露出 A7 – 機能レベルアクセス制御の欠落 A8 – クロスサイトリクエストフォージェリ(CSRF) A9 – 既知の脆弱性を持つコンポーネントの使用 A10 – 未検証のリダイレクトとフォーワード
- 37. Focus: “脆弱な現象から、その原因を探ること” １．早期に、繰り返しセキュリティ検証する ２．クエリーのパラメータ化 ３．エンコード処理 ４．全ての入力値を検証する ５．アイデンティティと認証 ６．アクセス制御の実装 ７．データの保護 ８．ロギングと侵入検知 ９．セキュリティフレームワークやライブラリの活用 １０．エラー処理と例外処理 2016/3/26 ©2015 Asterisk Research, Inc. 37 2016年1月リリース 日本語版もでました
- 38. Focus: “脆弱な現象から、その原因を探ること” 2016/3/26 ©2015 Asterisk Research, Inc. 38
- 39. 1：早期に、繰り返しセキュリティ検証 • セキュリティ要件を決める – はっきりさせるにはOWASP ASVSが役立つ • 「テストによって品質は作り込めない」 – ならば「テストによってセキュリティは作り込めない」 • むしろ開発作業者をテストするべき – 継続教育 • 毎回のイテレーション（スプリント）ごとに実装し検証できる範囲のテスト – コーディングチェッカー、OWASP ZAP
- 40. 2: クエリーのパラメータ化 • SQLインジェクション – データ盗難だけではない。 – 踏み台化するのに使う。 • 入力値がSQLコマンドの 一部になってしまうこと を防ぐ – ORモデルの利用 – 静的コード解析（動的に SQLを作っていないか） – パラメータ・クエリー String newName = request.getParameter("newName"); int id = Integer.parseInt(request.getParameter("id")); PreparedStatement pstmt = con.prepareStatement(“UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); pstmt.setString(1, newName); pstmt.setInt(2, id);
- 41. 3. データのエンコーディング • 以下はそれぞれエンコーディングで 回避できる – コマンドインジェクション – LDAPインジェクション – XMLインジェクション – クロスサイトスクリプティング • モバイル – Webview の悪用で写真、 GPS情報、SMSを操作可 能 • Java Encoder "Encode.forContextName(untrustedData)" • Escaperクラスの利用
- 42. 4. すべての入力値を検証する • すべての値を信頼できない – HTTPヘッダ – Cookie – GET/POSTパラメータ – アップロードファイル • 形式と意味 – 権限 • どこでやるか？ – JavaScript? • モバイル – プロセス間通信 – バックエンドのサーバデータ – ファイルからの読み込みデータ • 方式 – ブラックリスト – ホワイトリスト – 正規表現 – HTMLサニタイズ
- 43. 5. アイデンティティと認証管理の実装 • 多要素認証 • トークン認証 • パスワードの保管はどこに？ • リカバリー方式の実装 • セッションの生成と破棄 • 重要な処理を行う場合には、再認証 • パスワードのハッシュ化 https://www.reddit.com/r/funny/comments/1m628n/th ty/
- 44. 6.適切なアクセス制御の実装 • すべてのリクエストがアクセス制御を通る ようにする • アクセス制御のデフォルトは「拒否」 • 最小権限の原則 • アクセス制御をプログラムにハードコー ディングしない • アクティビティに基づいて記述する • アクセス制御には、サーバー側の信頼でき るデータを使う
- 45. 7：データの保護 • 通信経路のデータは暗号化する • データを保存する際の暗号化 • 保存先を変更する場合にも、 データが保護されるようにする • モバイルアプリケーション：端末 に安全にデータを保存する
- 46. ８．ロギングと侵入検知の実装 • 重要 – アプリケーションの運用監視 – ビジネスの分析と洞察 – アクティビティの監査やコン プライアンスの監視 – システムに対する侵入検知 – フォレンジック • モバイル – ログ出力を無効化してリリー スする方法
- 47. 9．セキュリティフレームワークやライブラリの活用 • Spring • Apache Shiro • Django Security • Flask Security • 攻撃されやすい ”フレームワーク”も ある
- 48. 10．エラー処理と例外処理 • 例外処理の重要ポイント – 集中管理せよ – ユーザに見えるところへの 出力メッセージに機密が含 まれないように。 – 品質保証やフォレンジック チームが調査に十分な例外 を出力
- 49. “Build Security In” ステージゲートと対策のマッピング ©2016 Asterisk Research, Inc. 犯罪 ケース セキュリティ 要件 脅威 分析 リスクベース テストプラン コード 検査 ペネトレーション テストビルド 品質分析 セキュリティ 運用 vulnerability １．早い段階に、繰り返しセキュリティ検証 ２．クエリーのパラメータ化 ３．エンコード処理 ４．全ての入力値を検証する ５．アイデンティティと認証 ６．アクセス制御の実装 ７．データの保護 ８．ロギングと侵入検知 ９．セキュリティフレームワークやライブラリの活用 １０．エラー処理と例外処理
- 50. Requirements to use 脆弱性検査 • 活用できる脆弱性検査を – 脆弱性ありました！にとどまらないこと – Proactiveな施策に変換。 • プロアクティブ・コントロール – 脆弱性はなぜ出るのかを推察し改善の方向性を示す • ライフサイクル – 早期に、繰り返しセキュリティテストできる方法はある
- 52. 強い動機は？ | Enabling Security | ©Asterisk Research, Inc. 52 Drivers for AppSec Programs Response Percent コンプライアンス、内部監査、調査レポートの率直な指摘 71.5% 漏洩時の経済的打撃に対するリスクベースの意識 69.6% 顧客への「当然の品質」としての魅力提示 39.9% セキュリティ・インシデントの指摘 36.7% 業界の予算、ROI、TCO比較による 33.5% Other 1.3% 出典：SANS Institute (2015)
- 53. 他業界のビルド・イン・セキュリティ例： PCI DSSコンプライアンス 53 PCI DSS 3.0要件(引用) 要件6 安全性の高いシステム とアプリケーションを開 発し、保守する 要件6は、現在および変化し続ける脆弱性、および安全なコード化ガイドラインを反 映させるため要件が追加・更新されています。開発環境、開発者トレーニングに関 する要件が更新されています。また、コーディング実践に関する要件が追加されて います。 要件 11: セキュリティシステムお よびプロセスを定期的 にテストする。 要件11では、発展型要件、追加のガイダンス、明確化と多角的に要件が発展して います。特に、脆弱性テストには期間（四半期ごと）のみならず、訂正内容を検証 するための繰り返しテストの要件についても明確化されました。 要件12 すべての担当者の情 報セキュリティに対応 するポリシーを維持す る。 要件12では、2.0に引き続き、担当者教育の重要性が強調されています。入社時、 また年ごとに行うよう規定されています。
- 54. 他業界のビルド・イン・セキュリティ例： HIPAA コンプライアンス + HITECH法 54 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
- 56. The biggest barrier is… ©2015 Asterisk Research, Inc. 56 RMS Titanic departing Southampton on April 10, 1912. (Photo: Creative Commons)
- 57. 対策: コミュニケーション x セキュリティ 社会価値 • 協調領域 • 競争領域 連携 • 新しいリスク • 解決策 個別の 問題 • 問題対応？ • 事前対策？
- 61. Enabling Security ©2016 Asterisk Research, Inc. 61 日本語への翻訳・執筆プロジェクト
- 62. 62 連携・コラボレーション
- 63. 22 OWASP Japan Local Chapter Meetings Reasons for holding OWASP Global AppSec in Japan – OWASP Japan Local Chapter – 2013.3.1 定期的なミーティング・トレーニング
- 67. Hardening Project IPA セキュリティ１０大脅威, JPCERT/CC, 総務省サイバー演習CYDER, SECON, 沖縄サイバーセキュリティネットワーク, Security Camp, IoT x Healthcare Hackathon
- 70. OWASP OKINAWA 2016 淵上真一・又吉伸穂 OWASP SENDAI 2015 小笠貴晴 OWASP KYUSHU 2015 服部 祐一・花田智洋 OWASP FUKUSHIMA 2014 6 金子正人・八幡圭嗣 OWASP KANSAI 2014 長谷川陽介・斉藤太一 OWASP JAPAN 2011 岡田良太郎・上野宣 Come on
Editor's Notes
- ほとんどの組織で行われているセキュリティテストは、開発・テストのサイクルとは無関係に実施されています。そのほとんどが「診断して、問題があれば、治す」というやり方で行われています。セキュリティチームが診断ツールを用いてテストを行ったり、侵入テストを実施して出てきた問題点を、「修正が必要な脆弱性リスト」として開発チームに渡して終わりです。この状況はさながら、「車輪を回し続けているハムスター」と同じではないでしょうか。もっと良いやり方があるはずです。 セキュリティテストも、ソフトウエアエンジニアリングの一部として統合されたプロセスであるべきです。「テストによって品質は作り込めない」と言われますが、セキュリティに関しても同じです。プロジェクトの最後の局面でセキュリティテストを行うだけでは意味がありません。「テストによってセキュリティは作り込めない」のです。手動で検証するにせよ、ツールを用いて自動でテストするにせよ、開発プロジェクトの早い段階から繰り返し何度も検証する必要があります。
- 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.