セキュア開発の3つの敵
71
-
Upload
riotaro-okada -
Category
Engineering
-
view
316 -
download
1
Transcript of セキュア開発の3つの敵
OWASP – Open Web Application Security Project
<mission: ソフトウェアセキュリティについて 意思決定をする人のために役立つ十分な情報を 提供すること >
– 技術者、ビジネスオーナ、ユーザ– ソフトウェアに関する技術・セキュアプロセス– 現状理解・普及啓発・適用推進– オープンソース・コミュニティベースで実現
Red pill, or blue pill?
From : MATRIX
7http://itpro.nikkeibp.co.jp/atcl/interview/14/262522/090700192/
「日本はオイシイ」からサイバー攻撃で狙われる奈良先端科学技術大学院大学 山口英教授
Enabling Security ©2016 Asterisk Research, Inc. 8
ー 一般教養としてのセキュリティで今、いちばん情報が足りない分野はなんでしょうか？ 設計・開発段階からセキュリティの機能を組み込む「セキュアプログラミング」だろう。…すべてのプログラマーがセキュアプログラミングを常識として知っているべきだと思うが、残念ながらセキュアプログラミングを学ぶための情報は限られている。山口 英
奈良先端科学技術大学院大学教授 , JPCERT/CC 設立者 ,内閣官房初代情報セキュリティ補佐官
http://itpro.nikkeibp.co.jp/atcl/interview/14/262522/090700192/?ST=management&P=4
その１ ネットワーク・セキュリティセキュア開発の敵
Security: Network or Application
L7
特許情報財務情報
人事・人材取引情報不祥事・インサイダー研究開発
Security: Network or Application
Security: Network or Application
Sources: Gartner, OWASP
Network Server
WebApplications
% of Attacks % of Dollars
90%
セキュリティ攻撃 セキュリティ支出
75%
25%
10%
脆弱なウェブアプリケーション、 67%
Intel Edison SD Card size PC Bluetooth/LE
Wi-Fi
24x32x2.1mm22nm 500MHz
Linux1GB RAM
4GB storage
Dual Core IA
“ コンピュータやスマートフォンのみならず、椅子やコーヒーメーカーや、マグカップまでがネットワークデバイスになります。”http://www.intel.com/content/www/us/en/do-it-yourself/edison.html
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
Sensors on Shelves
Automated Checkout
Proximity Advertising
Security Alarm & Environmental Sensors
Elements of a Protection Architecture for IoT
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 セキュリティへのアタックサーフィス
IoT は IT の 総合格闘技だ
© MMA
Requirements to use ネットワーク・セキュリティ
• 許可された通信から情報は窃取されている。– “ ファイアウォール” は L7 を理解しない。役割が異なる
• システムを総合的に守る価値– ネットワーク・セキュリティとアプリケーションセキュリティは役割が異
なり、バランスよく投資しなければならない。
• ネットワーク・セキュリティの人材と、アプリケーション・セキュリティの人材ではスキルセットが異なる– 取り扱っているものは、単なる”データ”ではない。
その 2 オープンソース・ソフトウェアセキュア開発の敵
アプリケーション
パッケージ , クラウドサービス , OSS, 3rd party
IoT Node Types and Data Paths
http://www.rtcmagazine.com/articles/view/105734
IoT Open Source “Heat Map”
http://www.rtcmagazine.com/articles/view/105734
Requirements to use Open Source Software
• プロジェクトとコードをチェックせよ– Open である意味はそこにある
• 組み込むなら OSS のコードもテストせよ– Found issue? Shut up and fix it!
• アップデートが重要– モジュール、コードいずれのレベルでも
その 3 脆弱性検査セキュア開発の敵
テスト(DAST)
直す 隠す無視・あきらめ
テスト(SAST)開発サイドの悩み
アプリケーションセキュリティスキルとツールの不足予算配分管理の欠如デリバリー再優先
セキュリティチームの悩み全アプリケーション資産の把握ができていない開発、セキュリティ、事業部のサイロ化によるコミュニケーションコスト増脆弱性修正すると動かなくなることへの恐れ
出典： SANS Institute (2015)Q. “Top Challenges for Builders and Defenders ”
?
間際のテストではオワコン
脆弱性検査 ?
| Enabling Security | ©Asterisk Research, Inc. 34
フェーズ Percent
企画・要件定義フェーズ 53.4%
設計フェーズ 16.5%
開発中 14.6%
コードのチェックイン 4.9%
リリース前 8.7%
Other 1.9%出典： SANS Institute (2015)
開発プロセスで最も参照されているガイドライン
Enabling Security ©2016 Asterisk Research, Inc. 35CERT Se
cure Coding S
tandard
s
OWASP To
p 10
ISO/IE
C 27034
NIST 800-53/64
Mitre/SA
NS CWE T
op 25
Microso
ft SDL
BSIMM
Critical S
ecurity
Controls
OpenSAMM
SAFE
CodeOther
出典： SANS Institute (2015)
容易 x 甚大な影響を及ぼす脆弱性。
Enabling Security ©2016 Asterisk Research, Inc. 36
A1 – インジェクションA2 – 認証とセッション管理の不備A3 – クロスサイトスクリプティング (XSS)A4 – 安全でないオブジェクト直接参照A5 – セキュリティ設定のミスA6 – 機密データの露出A7 – 機能レベルアクセス制御の欠落A8 – クロスサイトリクエストフォージェリ(CSRF)A9 – 既知の脆弱性を持つコンポーネントの使用A10 – 未検証のリダイレクトとフォーワード
Focus: “ 脆弱な現象から、その原因を探ること”
１．早期に、繰り返しセキュリティ検証する２．クエリーのパラメータ化３．エンコード処理４．全ての入力値を検証する５．アイデンティティと認証６．アクセス制御の実装７．データの保護８．ロギングと侵入検知９．セキュリティフレームワークやライブラリの活用１０．エラー処理と例外処理
05/01/2023 ©2015 Asterisk Research, Inc. 37
2016 年 1 月リリース日本語版もでました
Focus: “ 脆弱な現象から、その原因を探ること”
05/01/2023 ©2015 Asterisk Research, Inc. 38
1 ：早期に、繰り返しセキュリティ検証
• セキュリティ要件を決める– はっきりさせるには OWASP ASVS が役立つ
• 「テストによって品質は作り込めない」– ならば「テストによってセキュリティは作り込めない」
• むしろ開発作業者をテストするべき– 継続教育
• 毎回のイテレーション（スプリント）ごとに実装し検証できる範囲のテスト– コーディングチェッカー、 OWASP ZAP
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);
3. データのエンコーディング• 以下はそれぞれエンコーディングで回
避できる– コマンドインジェクション– LDAP インジェクション– XML インジェクション– クロスサイトスクリプティング
• モバイル– Webview の悪用で写真、
GPS 情報、 SMS を操作可能
• Java Encoder"Encode.forContextName(untrustedData)"
• Escaper クラスの利用
4. すべての入力値を検証する• すべての値を信頼できない
– HTTPヘッダ– Cookie– GET/POST パラメータ– アップロードファイル
• 形式と意味– 権限
• どこでやるか？– JavaScript?
• モバイル– プロセス間通信– バックエンドのサーバデータ– ファイルからの読み込みデータ
• 方式– ブラックリスト– ホワイトリスト– 正規表現– HTML サニタイズ
5. アイデンティティと認証管理の実装
• 多要素認証
• トークン認証
• パスワードの保管はどこに？
• リカバリー方式の実装
• セッションの生成と破棄
• 重要な処理を行う場合には、再認証
• パスワードのハッシュ化
https://www.reddit.com/r/funny/comments/1m628n/the_new_iphone_5s_provides_unmatched_security/
6. 適切なアクセス制御の実装• すべてのリクエストがアクセス制御を通る
ようにする• アクセス制御のデフォルトは「拒否」
• 最小権限の原則
• アクセス制御をプログラムにハードコーディングしない
• アクティビティに基づいて記述する
• アクセス制御には、サーバー側の信頼できるデータを使う
7 ：データの保護• 通信経路のデータは暗号化する
• データを保存する際の暗号化
• 保存先を変更する場合にも、データが保護されるようにする
• モバイルアプリケーション：端末に安全にデータを保存する
８．ロギングと侵入検知の実装• 重要
– アプリケーションの運用監視– ビジネスの分析と洞察– アクティビティの監査やコン
プライアンスの監視– システムに対する侵入検知– フォレンジック
• モバイル– ログ出力を無効化してリリー
スする方法
9 ．セキュリティフレームワークやライブラリの活用
• Spring• Apache Shiro• Django Security• Flask Security
• 攻撃されやすい”フレームワーク”もある
10 ．エラー処理と例外処理• 例外処理の重要ポイント
– 集中管理せよ– ユーザに見えるところへ
の出力メッセージに機密が含まれないように。
– 品質保証やフォレンジックチームが調査に十分な例外を出力
“Build Security In”ステージゲートと対策のマッピング
©2016 Asterisk Research, Inc.
犯罪ケース セキュリティ要件脅威分析リスクベーステストプラン コード検査
ペネトレーションテストビルド品質分析 セキュリティ運用
vulnerability
１．早い段階に、繰り返しセキュリティ検証２．クエリーのパラメータ化３．エンコード処理４．全ての入力値を検証する５．アイデンティティと認証６．アクセス制御の実装７．データの保護８．ロギングと侵入検知９．セキュリティフレームワークやライブラリの活用１０．エラー処理と例外処理
Requirements to use 脆弱性検査
• 活用できる脆弱性検査を– 脆弱性ありました！にとどまらないこと– Proactive な施策に変換。
• プロアクティブ・コントロール– 脆弱性はなぜ出るのかを推察し改善の方向性を示す
• ライフサイクル– 早期に、繰り返しセキュリティテストできる方法はある
その 4 セキュリティは報われるのか？セキュア開発の敵 番外編
強い動機は？
| 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)
他業界のビルド・イン・セキュリティ例： PCI DSS コンプライアンス
53
PCI DSS 3.0 要件 ( 引用 )
要件 6安全性の高いシステムとアプリケーションを開発し、保守する
要件 6 は、現在および変化し続ける脆弱性、および安全なコード化ガイドラインを反映させるため要件が追加・更新されています。開発環境、開発者トレーニングに関する要件が更新されています。また、コーディング実践に関する要件が追加されています。
要件 11: セキュリティシステムおよびプロセスを定期的にテストする。
要件 11 では、発展型要件、追加のガイダンス、明確化と多角的に要件が発展しています。特に、脆弱性テストには期間（四半期ごと）のみならず、訂正内容を検証するための繰り返しテストの要件についても明確化されました。
要件 12 すべての担当者の情報セキュリティに対応するポリシーを維持する。
要件 12 では、 2.0 に引き続き、担当者教育の重要性が強調されています。入社時、また年ごとに行うよう規定されています。
他業界のビルド・イン・セキュリティ例： 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
「セキュリティ・バイ・デザイン」2015/9/4 サイバーセキュリティ戦略 閣議決定
55
The biggest barrier is…
©2015 Asterisk Research, Inc. 56RMS Titanic departing Southampton on April 10, 1912. (Photo: Creative Commons)
対策 : コミュニケーション x セキュリティ
社会価値• 協調領域• 競争領域
連携• 新しいリスク• 解決策
• 問題対応？• 事前対策？
Enabling Security ©2016 Asterisk Research, Inc. 61
日本語への翻訳・執筆プロジェクト
62
連携・コラボレーション
22
OWASP Japan Local Chapter Meetings
Reasons for holding OWASP Global AppSec in Japan – OWASP Japan Local Chapter – 2013.3.1
定期的なミーティング・トレーニング
64
国際コンファレンスの開催 (2014, 東京 )
2015/9 リリース , OWASP 2014 年次報告書日本での活動を特集
報告書・レポートの制作
Local Activities
数々のプロジェクトへの参画・設立
Hardening ProjectIPA セキュリティ１０大脅威 , JPCERT/CC,総務省サイバー演習 CYDER, SECON,沖縄サイバーセキュリティネットワーク , Security Camp,
IoT x Healthcare Hackathon
OWASP FUKUSHIMA 発足おめでとうございます。
OWASP OKINAWA 2016 淵上真一・又吉伸穂OWASP SENDAI 2015 小笠貴晴OWASP KYUSHU 2015 服部 祐一・花田智洋OWASP FUKUSHIMA 2014 6 金子正人・八幡圭嗣OWASP KANSAI 2014 長谷川陽介・斉藤太一OWASP JAPAN 2011 岡田良太郎・上野宣
Come on
Be the enabler!Folks!
