Downloaded 10 times
![[OpenStack Days Korea 2016] Track1 - 카카오는 오픈스택 기반으로 어떻게 5000VM을 운영하고 있을까?](https://cdn.slidesharecdn.com/ss_thumbnails/16kakao-160226171853-thumbnail.jpg?width=640&height=640&fit=bounds)
SIEMやログ監査で重要な事
- 1.
- 2. About Me • お前誰よ？ –井上圭 tw:hogehuga – 千葉県民 • コミュニティ – 脆弱性対応研究会/脆弱性対応勉強協会 • https://zeijyakuseitaioukenkyukai.connpass.com/ – IoTSecJP東京 運営 • https://iotsecjp.connpass.com/ – Vulsユーザ会 運営 • https://vuls.io/ – OWASP membership – OWASP Nagoya立ち上げから参加してます！(参加) • 仕事 – シニア コンサルタントという肩書 – 脆弱性対応アドバイス • 趣味 – 脆弱性情報の観察 – インシデントの観察 – ハニーポットの観察 – ドローンセキュリティ – 水風呂、サウナ チャリバイクで来た (帰りがツラい) 関東で、仕事や勉強会などで • ドローンのセキュリティ • 脆弱性対応 の話をしています
- 3. 本日は、ログ監査やSIEMについての知見を共有したいと思います。 • ログ監査の背景 – ログ監査の重要性 –ログ監査とは – 相関分析 – SIEMについて • 最近の風潮 – よくあるパターン • 導入の実際 – 対象の決定 – 手法の確認 – 内製化か、ベンダ製品か • ベストプラクティスと注意すべきこと 本内容は個人の意見であり、所属企業・部門見解ではありません。
- 4. ログ監査の背景 ログ監査の重要性 • そもそもログとは – 動作の記録であり、発生した事象の記録 –記録の粒度は設定が必要 • デフォルトではログが出ない、特定のログだけ出る、古いものから削除される、etc • ログでできること – 過去に起こった事象の確認 – 過去の傾向からの、将来予測 – 法的保存義務の履行 何らかの問題が発生した場合、過去の状況を確認するためにはログの出力 /保存が必要 • 法的保存期間、実務要求での保存期間 • 必要な粒度でのログ出力 • 保存されたログを分析することで、何があったのかを洗い出す
- 5. ログ監査の背景 ログ監査 • ログ自体をそのまま見ても、発生した事象を 認識するのは難しい – どの場合に、どのようなログが出るのか、という 知識が必要 –そもそも、ログそのままだと、見づらい – ログはシステムごとに出るため、状況によりログ が出る場所が異なることになる
- 6. ログ監査の背景 相関分析 • 単一のシステムではなく、複数システムのログをまと めてみることで、状況を把握する。 – WEBアクセスでファイルを取得する場合 •クライアントの操作ログ • Proxyサーバへのアクセスログ（レピュテーション情報） • Firewallでのアクセスログ • 戻り通信のFirewallでのログ • 戻り通信のサンドボックスでのログ • クライアントへのファイルアクセスログ – これらを時系列でみることで、どのような通信が行われた のか、状況を再現可能 • これらを簡単にできるような仕組みが、SIEM
- 7. ログ監査の背景 SIEMについて • 複数のログを正規化して保存し相互に参照することで、脅威の発見を手 助けや自動化するためのツール • オープンソースなもの、商用のもの、インシデント発見に特化したものが ある –オープンソース • e.g.) ElasticStack – 商用の物 • e.g.) Splunk、セキュリティベンダ提供のSIEM • 違いは何か – オープンソースのものは、すべて自分自身での設定が必要 • ログに対する知識、脅威に対する知識が必要 – 商用のものは、デフォルトの設定ルールが多数搭載されている。 • 各種ログに対応した、正規化ルール（apache httpd, sendmail, etc..） • 特定の脅威の検出やアラートの自動化機能が豊富 • とりあえずは知識が無くても設定、検出ができる
- 8. 最近の風潮 よくあるパターン • 「情報漏洩等があるから、SIEMというやつを入れよう」 – セキュリティ担当者は、いない場合が多い –当然、脅威に対する専門知識も少ない – 費用はかけたくないが、効果を最大限得たい – 既存の運用チームで対応させればよい とりあえず入れるという流れになりがち。 入れたはいいが、運用がうまくいかないパターンも多いようだ。 運用が軌道に乗ったパターンを基に、原因を考えてみる。
- 9. 導入の実際 そもそも、SIEMはどのように構築していくか。 以下のフェーズごとに確認する。 • 対象の決定 • 手法の決定 •使う製品の決定 • 構築 • 運用
- 10. 導入の実際 対象の決定 • 対象となる「ログ」ではなく、「何を監査するか」という対象 ＝対象とする脅威の定義 – ここが疎かになるパターンが多いと推定される –例えば • クライアントのマルウェア感染時に追跡をする • WEBシステムへの攻撃を検出したい • 内部ユーザの不正操作を検出したい • etc… • 上記監査目的に対して、ブレークダウンを行う – クライアントマルウェア感染の追跡であれば • 標的型攻撃のもの（メール添付ファイルによる感染） – pdf, word, excel, 拡張子偽装のbatやexe • WEBから落とした、マルウェアに感染したファイルの実行によるもの – zipファイルダウンロード後、展開したexeで観戦 • Wannacryの横展開の感染 – EternalBlueによる脆弱性、同一サブネット内への異常な通信増加 – 内部ユーザ不正操作の検出であれば • 不正操作、の定義 – sudo失敗、権限のないファイルへのアクセス試行、特定の管理コマンドの利用
- 11. 導入の実際 手法の決定 • 定義した脅威に対して、どのように検知するのか、検知のために変更が必要 なのか、を検討 – 例えばクライアントのマルウェア感染検出 •実行形式ファイルの実行の記録 – プロセスの監査設定→監査の設定の変更が必要 – 監査設定後のログ出力→該当するイベントIDの確認 • 感染後のC&Cサーバへの通信記録 – WEB通信のログ→proxyの設置、ログ出力 – セキュリティproxyでのレピュテーションログ→proxyの通知設定 • 感染後によく使われるコマンドの検出 – 対象となるコマンドの理解→tasklist, ver, ipconfig, systeminfo etc.. – プロセス監査で上記コマンドでフィルタ • 通信状況の記録 – FirewallやUTMでの通信記録→syslog等でのログ出力設定、出力粒度設定 • 上記の設定の、現状値と、変更必要性の確認 – そもそもログが出力されているか – 現状の設定で、必要な項目が出力されるか – ログ出力設定変更をした場合、どの程度の影響が想定されるか – ログの量はどの程度になるのか。 • 特定期間の出力量概要を確認し、ストレージが保存期間分耐えられるかを検討
- 12. 導入の実際 使う製品の検討 • オープンソース – 設定をするだけの技術があるか •自社で構築、運用ができるか • 構築を外部に依頼し、運用者への教育も依頼し、自社で運用する • 構築や運用を外部に委託する＝SOC – 運用開始後に調整はできるか • 手法や監査項目への理解が必要 • 利用データベースのチューニング知識が必要 – 自動化のための項目検討 • 検出閾値、検出時の動作、などの定義 • 商用製品 – 設定の簡略化 • 多彩なデフォルト設定ルール – 運用の簡略化 • SOCサービスと連携した製品も多い
- 13. ベストプラクティスと注意点 ベストプラクティス • 自力で導入できるか、外部に導入を依頼するか – 外部に依頼する場合も、何を検出するのかやどのように動作するかの理解する必要あり –自力で導入する場合は、最初から完全を目指さず、特定の脅威に対して確実に検出できるように進める。 種類は後で増やす戦略。 • 脅威の想定をする – まずは一般的な設定で構築し、運用の成熟共に徐々に対象脅威を追加していく – 導入前に、脅威とそれに対する検出手法などを別途学習しておく • スモールスタートも視野に入れる – オープンソースのSIEMを導入し、効果が確認できる/運用できるように成熟したら、より高度なことをするた めに商用製品を導入する、など – 無いよりはあったほうが良い、という考えもある • 過度な自動化を期待しない – 自動で検出ができるものも多いが、それを基に詳細を掘り下げていくのは人間でしかできない。また、掘り 下げるための知識も必要。 – 導入したら終わりではない。状況に合わせて検出方法や確認方法を変更していく必要がある。 • アプリケーションやシステムの構築段階から、ログ監査を検討しておく – アプリケーション側でログが出ない、出すぎていて保存するのが難しい、などの状況が発生しやすい。
- 14. ベストプラクティスと注意点 注意点 • SIEMは、本当に必要か？ – 運用にはそれなりの「ログに対する」知識が必要 –後で追跡するだけなら「ログが残っている」だけでよい • 相関や即時性はそこまで必要がない – 必要なら、「運用する人」を作る • 対象とする脅威やインシデントに対する知識が必要 • SIEMを「作る人」を得るのは、容易い • 保存期間に根拠はあるか – 法的要件、業界暗黙要件、運用上の要件。最低保存期間を決める – とりあえず期間決めずに保存、は破綻しやすい – 果てなくログを残すには、人生には余りにもディスクが足りない – SIEMに残すのではなく、syslogで圧縮で残す(text扱いで99%の圧縮率) • ログが必要のが出ていないことが多い – どのシステムの、どのようなログが必要か、を洗い出す – 大体のシステムにおいて、ログは抑制気味。有限のディスクスペース。 – 必要なものを必要なだけ出す。必要なら変更をする。変更できないなら代替えの手段を用意 する。
- 15. まとめ まとめると • まずはやってみる • まずは必要な要件を決める •ログに残すべき情報を決める • ログを残す • 分析する • SIEMに手を出してみる • 「何を検出したいか」を明確にする – 「ウイルスにやられたのを検知したい」 • 「ウイルス」とは？＋「やられた」とは？＋「検知」して何をしたいのか？ – 「攻撃とは」「マルウェアとは」「…とは」 • 敵を知り己を知ればインシデント対応危うからず • SIEMにこだわらない – 手段と目的を間違えない – ログを、sed, grep, awk, pythonなどで処理するだけでも良い場合がある – 導入コスト、運用コスト（機器、人員）、得られる効果、を検討 – 必要な場合は、投資から逃げない