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あたりの情報を得ておくと初動が速くできる

• 継続的なアップデート運用をする

• 緊急性がなければ、定期メンテナンスで適用する• 利用バージョンと最新バージョンの差を、なるべく減らす運用

• 関係ないからアップデートしない、をなくす

没案のスライドなので、まだ推敲が足りていません。

ないよりはましと思われるので、公開しています。

考慮不足、記載不足については、ご容赦ください。

おわり