20170408 securiy-planning
TRANSCRIPT
2017/04/08
• WEBサイトの脆弱性に対する考え方• セキュリティ観点での最近の状況
• セキュリティ対応のフェーズ
• セキュリティ対対応の全体像
• どのように考えるべきなのか
• 各論
• じゃぁどうすればいいんですか!
!:Attention:!
現場での対応の話ではなく、どのように設計すべきか、構築していくか
のお話です
:!NOTE!:
勉強会用に用意したが、内容が発散したので没にしました。
しかし、もったいないので公開します。
• 最近起こったセキュリティ的事象• 不正アクセス系のみ。(メール誤送信等は除く)
日付 概要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 印刷通販サイトでクレカなど個人情報が流出か -「セキュリティコード」や「質問と回答」なども
多すぎて、わかりません!
• 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で流出が確認
• 以降、不正アクセスと思われるものが続発
• 脆弱性が公開されると、遅くとも1週間以内に攻撃が始まるようだ• ゼロデイ(および公開前の攻撃)も多数ある。
• 対応は「早さが勝負」の世界になってきている。
• セキュリティリリースが適用されていない• アップデート、もしくはWAFのシグネチャを有効にするだけで防げるものが、1か月近くたっても発生している?
• アップデートもせず、WAFも入れてない?
脆弱性対応をすべき「時間的余裕」が短くなっている
アップデートで解決するものが多い=継続的アップデートが必要
アップデートで解決することが多い
(むしろ、それ以外方法がない場合もある)
• 緊急の脆弱性アップデートは、最新バージョンにセキュリティ修正のみを足したもので出ることが多い
• 最新版を使っていれば、セキュリティ修正以外の差分はないため、サービスに影響が出る可能性はかなり低い
• アップデートをしない運用をしていた場合は、最新版までの差分を「脆弱性緊急対応」時に適用する必要がある。• 緊急で適用したいのに、bugfixや新機能追加による変更部分での動作確認が必要になる。
日々、下記の作業を行う必要がある
• 情報収集
• 影響度調査
• 対応
• ダメージコントロール
• 情報収集
• 影響度調査
• 対応
• ダメージコントロール
• 以下を見よう!
• 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で検知する⇒パッケージで対処可能なものはこれが便利!
• 情報収集
• 影響度調査
• 対応
• ダメージコントロール
• CVE番号が振られているものであれば、CVSS値を読もう
• CVSS Base Score
• CVSS Vector
• AC: 攻撃元区分
• AC: 攻撃条件の複雑さ
• Au: 攻撃前の認証要否
• C: 機密性への影響
• I: 完全性への影響
• A: 可用性への影響
• 基本はBaseScoreで判断
• Vecotrに慣れてほしい• 内容を吟味して、トリアージする
• 情報収集
• 影響度調査
• 対応
• ダメージコントロール
• 「影響度調査」に基づいて対応
•緊急性の高いもの
• まずはアップデートをし、問題があるようならロールバックする
•緊急性の低いもの
• ステージング環境やホストのスナップショットイメージを取得したうえで適用確認
• 問題ないことが確認できれば適用、問題があれば修正。
設計段階から、アップデートができるようにするのが重要。
どうしてもアップデートができない場合は、ワークアラウンドによる回避を行う。
トリアージ、重要。
• 情報収集
• 影響度調査
• 対応
• ダメージコントロール
• 脆弱性が見つかり、それを利用した攻撃を受けた時の対応
•情報流出がある場合は、公表や保証の話が…
•出来れば、状況をOpenにするのが望ましい…
• 信用、という問題のケアをする
• 対:GM〇 Payment Gateway
•やっぱり、CSIRTが必要
フェイルセーフとしての、ダメージコントロールは必要。
• 脆弱性の告知から、対応までの時間、が短ければより漏洩リスクは減る。
• アップデートができる設計である必要性
• すべてのフェーズについて検討したいが、セッションの時間は限られている
• 情報収集/影響度調査/ダメージコントロールは、比較話題になりやすい
• 対応については、あまり議論がされていない気がする
• 上記から、今回は…
対応が必要な部分を、まずはゾーンに分けて考えると、対策がしやすい
• アプリケーション層• サービスのフロントエンドとなる「自作」のアプリケーション
• ミドルウェア層• フレームワークなどの共通基盤
• WEBサーバ、DBサーバなどのプログラム
• ライブラリ等
• OS層(単独のパッケージで提供されるもの含む)• WEB系サービス等に影響のないもの
• ネットワーク層• ネットワークアクセスに関する制限等を提供するもの
Struts2上のプログラム等
Struts2, httpd, mysql等
ntpd, bind 等
WAF, IPS/IDS等
先述の各層に対する対応を考える
• アプリケーション層• 脆弱性を検出する=脆弱性診断をする
• ミドルウェア層• Updata可能かを見極める必要がある
• 挙動変更がある場合、適用のためのテストが必要= ステージングサーバの準備
• OS層• Updateしても影響はあまりない?
• bind, ntpdなど、他のサービスへの影響がないものが多い• Kernel update = OS再起動なので、再起動の計画が必要
• ネットワーク層• Firewall、WAF、IPS/IDS、など
• ファームウェアアップデートで、挙動が変わる可能性あり• 設定の見直し、確認を随時実施
OSSのように、
誰かが脆弱性を報告してくれるわけではない。
多数のユーザが使って、脆弱性情報が共有され
ている!
アップデートがあれば適用するという運用
ファームウェア情報?
• アプリケーション層• 作成時に脆弱性を作りこまない
• コードの書き方(SQL Injectionなどの対策)
• 古い、脆弱性のあるライブラリを使わない• ライフサイクルを考えた、バージョンを利用
• 脆弱性検査は、自分自身で行う必要がある
• 作りながら脆弱性テストをする=継続的インテグレーション
• ミドルウェア層• アップデート可能な設計をする
• 体制や手順の事前準備
• 依存するライブラリ等の把握
• ステージングやスナップショットを利用した、テスト
• ライフサイクルを考えた、バージョンを利用
• OS層• 依存関係を把握し、アップデート可能なサービスを洗い出し
• bind, ntpd等、サービスに影響ないものは、すぐにアップデート
• ロールバックできるものはアップデート
• Kernelなどは、サーバ再起動が必要。事前計画の準備。
• 今は脆弱性に該当しないからアップデートしない、運用をやめる
• 最新版との差が広がり、いざというときに差分が多くなり、適用が困難になる。
• ネットワーク層• コンフィグの定期確認 (PCI/DSS要件にもある)
• 影響度を考慮した、ファームウェアアップデート
• WAF、IPS/IDSなどは、あくまで補助と考え、根本解決(アプリケーションやミドルウェアの、アップデートや脆弱性修正)を行う。
• 設計時点から、• アップデートができるようにする
• EOLが近いバージョンを使わない
• 作りながら脆弱性検査をする
• ライブラリ等はJenkins + OWASP Dependency Check + Vuls
• WEBは、OWASP ZAPで自己診断や 脆弱性診断会社に任せる
• 運用時点では、• 脆弱性情報を収集/判断を継続的に行う
• Vulsで、最新パッケージで修正済みの脆弱性を検知
• US-CERTあたりの情報を得ておくと初動が速くできる
• 継続的なアップデート運用をする
• 緊急性がなければ、定期メンテナンスで適用する• 利用バージョンと最新バージョンの差を、なるべく減らす運用
• 関係ないからアップデートしない、をなくす
没案のスライドなので、まだ推敲が足りていません。
ないよりはましと思われるので、公開しています。
考慮不足、記載不足については、ご容赦ください。
おわり