Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20170408 securiy-planning

718 views

Published on

WEBサイトのセキュリティ対策の考え方

Published in: Technology
  • Be the first to comment

  • Be the first to like this

20170408 securiy-planning

  1. 1. 2017/04/08
  2. 2. • WEBサイトの脆弱性に対する考え方 • セキュリティ観点での最近の状況 • セキュリティ対応のフェーズ • セキュリティ対対応の全体像 • どのように考えるべきなのか • 各論 • じゃぁどうすればいいんですか! !:Attention:! 現場での対応の話ではなく、 どのように設計すべきか、構築していくか のお話です :!NOTE!: 勉強会用に用意したが、 内容が発散したので没にしました。 しかし、もったいないので 公開します。
  3. 3. • 最近起こったセキュリティ的事象 • 不正アクセス系のみ。(メール誤送信等は除く) 日付 概要 2017/03/27 設定ミスでDBから顧客情報流出の可能性 - マーケティング会社 2017/03/24 JINS通販サイトで個人情報が流出か - 「Apache Struts 2」脆弱性が再度原因に 2017/03/21 住宅金融支援機構のクレカ情報流出、セキュリティコードはサイト利用者のみ影響 2017/03/16 不正アクセスで顧客クレカ情報が窃取被害 - 家電通販サイト 2017/03/16 沖縄電力でサイト改ざん、原因は「Apache Struts 2」の脆弱性 - 情報流出の可能性も 2017/03/15 通販サイトに不正アクセス、クレカ情報流出 - ヤマサちくわ 2017/03/14 日本郵便に不正アクセス、送り状やメアドが流出 - 「Apache Struts 2」の脆弱性が原因 2017/03/13 サイトに不正アクセス、相談者のメアド2.6万件流出か - JETRO 2017/03/10 住宅金融支援機構の関連サイトでクレカなど個人情報が流出 - セキュリティコードも 2017/03/10 都税支払サイトからクレカ情報67.6万件が流出か - 「Apache Struts 2」の脆弱性突かれる 2017/03/07 不正アクセスでアカウント情報流出か - ねじ販売サイト 2017/02/24 セキュリティコードなどクレカ情報が流出の可能性 - インテリア通販 2017/02/22 不正アクセスによる情報漏洩、会員など最大約6万人に影響 - イベント制作会社 2017/02/14 「SQLi攻撃」で最大13万件の顧客情報が流出 - 日販グループ会社 2017/01/31 イプサ、不正アクセスの調査結果を公表 - デバッグモードによりカード情報残存 2017/01/27 不正アクセスでクレカなど個人情報流出か - 電子たばこ通販サイト 2017/01/27 不正アクセスで個人情報2.2万件が流出の可能性 - ロングランプランニング 2017/01/16 不正アクセスで顧客情報流出の可能性、フィッシング攻撃も - クラウドゲームス 2017/01/16 メールサーバへの不正アクセス、原因わからず - 優良住宅ローン 2017/01/10 会員向けサイトに不正アクセス、個人情報が流出 - イベント制作会社 2017/01/05 印刷通販サイトでクレカなど個人情報が流出か - 「セキュリティコード」や「質問と回答」なども 多すぎて、 わかりません!
  4. 4. • WordPress 4.7.1以下で発生した、REST APIの脆弱性 • 2017/01/26に脆弱性対応版の 4.7.2 がリリース • 2017/02/01に、脆弱性の内容(REST APIの脆弱性)公開 • 2017/02/06頃から、多数のサイトが改ざん発生 • 被害内容はサイトの文字列改竄程度であり、スクリプト埋め込 み等はできない。 • Apache Struts2の脆弱性 • 2017/03/06に、脆弱性が公開 • 2017/03/07に、脆弱性修正バージョンをリリース • 2017/03/08にIPAが、2017/03/09にJPCERTが、注意喚起 • 2017/09/10に、GMO Payment Gatewayで流出が確認 • 以降、不正アクセスと思われるものが続発
  5. 5. • 脆弱性が公開されると、遅くとも1週間以内に攻撃が始 まるようだ • ゼロデイ(および公開前の攻撃)も多数ある。 • 対応は「早さが勝負」の世界になってきている。 • セキュリティリリースが適用されていない • アップデート、もしくはWAFのシグネチャを有効にするだけで防 げるものが、1か月近くたっても発生している? • アップデートもせず、WAFも入れてない? 脆弱性対応をすべき「時間的余裕」が短くなっている アップデートで解決するものが多い =継続的アップデートが必要
  6. 6. アップデートで解決することが多い (むしろ、それ以外方法がない場合もある) • 緊急の脆弱性アップデートは、最新バージョンにセキュ リティ修正のみを足したもので出ることが多い • 最新版を使っていれば、セキュリティ修正以外の差分はないため、 サービスに影響が出る可能性はかなり低い • アップデートをしない運用をしていた場合は、最新版ま での差分を「脆弱性緊急対応」時に適用する必要がある。 • 緊急で適用したいのに、bugfixや新機能追加による変更部分での 動作確認が必要になる。
  7. 7. 日々、下記の作業を行う必要がある • 情報収集 • 影響度調査 • 対応 • ダメージコントロール
  8. 8. • 情報収集 • 影響度調査 • 対応 • ダメージコントロール • 以下を見よう! • US-CERT • https://www.us-cert.gov/ • メーリングリスト • SECLISTS.ORG/oss-secなど • http://seclists.org/oss-sec • OSのerrata • RHEL, Windows, Ubuntu, … 24時間365日見続けるのは不可能 専門家でない限り、見続けるのは意味がないかも ⇒RSSでSlackに流すといい よ 一般の管理者は、 • JPCERT/CC, IPAの情報を見る(US-CERTの情報をまとめてくれ る) • Vulsで検知する⇒パッケージで対処可能なものはこれが便利! • JPCERT/CC, IPAの情報を見る(JVNのRSSなど) • US-CERTの情報をまとめてくれるが、即時性は… •Vulsで検知する⇒パッケージで対処可能なものはこれが便利!
  9. 9. • 情報収集 • 影響度調査 • 対応 • ダメージコントロール • CVE番号が振られている ものであれば、CVSS値を 読もう • CVSS Base Score • CVSS Vector • AC: 攻撃元区分 • AC: 攻撃条件の複雑さ • Au: 攻撃前の認証要否 • C: 機密性への影響 • I: 完全性への影響 • A: 可用性への影響 • 基本はBaseScoreで判断 • Vecotrに慣れてほしい • 内容を吟味して、トリアージする
  10. 10. • 情報収集 • 影響度調査 • 対応 • ダメージコントロール • 「影響度調査」に基づい て対応 • 緊急性の高いもの • まずはアップデートをし、問題 があるようならロールバックす る • 緊急性の低いもの • ステージング環境やホストのス ナップショットイメージを取得 したうえで適用確認 • 問題ないことが確認できれば適 用、問題があれば修正。 設計段階から、アップデートができる ようにするのが重要。 どうしてもアップデートができない場 合は、ワークアラウンドによる回避を 行う。 トリアージ、重要。
  11. 11. • 情報収集 • 影響度調査 • 対応 • ダメージコントロール • 脆弱性が見つかり、それ を利用した攻撃を受けた 時の対応 • 情報流出がある場合は、公 表や保証の話が… • 出来れば、状況をOpenにす るのが望ましい… • 信用、という問題のケアをする • 対:GM〇 Payment Gateway • やっぱり、CSIRTが必 要 フェイルセーフとしての、 ダメージコントロールは必要。 • 脆弱性の告知から、対応までの時 間、が短ければより漏洩リスクは 減る。 • アップデートができる設計で ある必要性
  12. 12. • すべてのフェーズについて検討したいが、セッションの 時間は限られている • 情報収集/影響度調査/ダメージコントロールは、 比較話題になりやすい • 対応については、あまり議論がされていない気がする • 上記から、今回は…
  13. 13. 対応が必要な部分を、まずはゾーンに分けて考えると、対 策がしやすい • アプリケーション層 • サービスのフロントエンドとなる「自作」のアプリケーション • ミドルウェア層 • フレームワークなどの共通基盤 • WEBサーバ、DBサーバなどのプログラム • ライブラリ等 • OS層(単独のパッケージで提供されるもの含む) • WEB系サービス等に影響のないもの • ネットワーク層 • ネットワークアクセスに関する制限等を提供するもの Struts2上のプログラム等 Struts2, httpd, mysql 等 ntpd, bind 等 WAF, IPS/IDS等
  14. 14. 先述の各層に対する対応を考える • アプリケーション層 • 脆弱性を検出する=脆弱性診断をする • ミドルウェア層 • Updata可能かを見極める必要がある • 挙動変更がある場合、適用のためのテストが必要 = ステージングサーバの準備 • OS層 • Updateしても影響はあまりない? • bind, ntpdなど、他のサービスへの影響がないものが多い • Kernel update = OS再起動なので、再起動の計画が必要 • ネットワーク層 • Firewall、WAF、IPS/IDS、など • ファームウェアアップデートで、挙動が変わる可能性あり • 設定の見直し、確認を随時実施 OSSのように、 誰かが脆弱性を 報告してくれる わけではない。 多数のユーザが使って、 脆弱性情報が共有され ている! アップデートがあれば 適用するという運用 ファームウェア情報?
  15. 15. • アプリケーション層 • 作成時に脆弱性を作りこまない • コードの書き方(SQL Injectionなどの対策) • 古い、脆弱性のあるライブラリを使わない • ライフサイクルを考えた、バージョンを利用 • 脆弱性検査は、自分自身で行う必要がある • 作りながら脆弱性テストをする =継続的インテグレーション • ミドルウェア層 • アップデート可能な設計をする • 体制や手順の事前準備 • 依存するライブラリ等の把握 • ステージングやスナップショットを利用した、テスト • ライフサイクルを考えた、バージョンを利用
  16. 16. • OS層 • 依存関係を把握し、アップデート可能なサービスを洗い出し • bind, ntpd等、サービスに影響ないものは、すぐにアップデー ト • ロールバックできるものはアップデート • Kernelなどは、サーバ再起動が必要。事前計画の準備。 • 今は脆弱性に該当しないからアップデートしない、運用をやめる • 最新版との差が広がり、いざというときに差分が多くなり、適 用が困難になる。 • ネットワーク層 • コンフィグの定期確認 (PCI/DSS要件にもある) • 影響度を考慮した、ファームウェアアップデート • WAF、IPS/IDSなどは、あくまで補助と考え、根本解決(アプリ ケーションやミドルウェアの、アップデートや脆弱性修正)を行う。
  17. 17. • 設計時点から、 • アップデートができるようにする • EOLが近いバージョンを使わない • 作りながら脆弱性検査をする • ライブラリ等はJenkins + OWASP Dependency Check + Vuls • WEBは、OWASP ZAPで自己診断や 脆弱性診断会社に任せる • 運用時点では、 • 脆弱性情報を収集/判断を継続的に行う • Vulsで、最新パッケージで修正済みの脆弱性を検知 • US-CERTあたりの情報を得ておくと初動が速くできる • 継続的なアップデート運用をする • 緊急性がなければ、定期メンテナンスで適用する • 利用バージョンと最新バージョンの差を、なるべく減らす運用 • 関係ないからアップデートしない、をなくす
  18. 18. 没案のスライドなので、まだ推敲が足りていません。 ないよりはましと思われるので、公開しています。 考慮不足、記載不足については、ご容赦ください。 おわり

×