ログ分析勉強会vol.1（初心者のセキュリティログ分析〜開発者は見た！ログの重要性〜）

1. セキュリティログ分析
∼開発者は見た！ログの重要性∼
小林 賢司
(@kkb1016)

2. その前に！

3. 本日は、たくさんの方にお越しいただき、
ありがとうございます。

4. こんなにたくさん応募があるとは思って
いなかったのでとても驚いています。

5. そろそろ始めます。

6. 話したいこと
• 自己紹介
• ログ分析をする目的とは？
• セキュリティとしてのログ分析とは？
• セキュリティログ分析は⃝⃝⃝？
• 開発者目線で振り返るログの重要性
• まとめ

7. 自己紹介
• 名前：小林 賢司(@kkb1016)
フォージビジョンという会社に所属しています
twitterはアニメツイートが多いので要注意です。
• 趣味：ダーツ、アニメ鑑賞、お酒、お寿司
• 経験値：Web開発(主にJava)、最近はインフラ周り
• 興味がある分野：アニメ、IoT、セキュリティ、
データ分析
Rubyistになるため勉強中です。

8. 最初に宣言しておきます。

9. ログ分析は携わっていますが、
セキュリティに関しては
まだまだ初心者！！

10. そんな方でも始められるように
紹介していきます。

11. 初心者でもはじめられる
セキュリティログ分析
∼開発者は見た！ログの重要性∼
小林 賢司

12. 仕切りなおしです。

13. ログ分析をする目的とは？

14. 質問です！
今現在、お仕事や趣味などでログ分析を
されている方はどのくらいいらっしゃいますか？

15. ログ分析をやってみようと
思っている方？

16. 当たり前ですが、
ログ分析をするにあたり
みなさん、それぞれ目的が
あると思います。

17. 目的 用途
マーケティング分野における
意思決定
キャンペーン・施策の成果(投資効果)の確認、
売上げやコンバージョンに対する
チャネルの寄与の分析
システムパフォーマンス改善
クエリの処理時間の改善、
システム処理時間のボトルネック解消
セキュリティ
インシデントの発見
サイバー攻撃の発見、不審なアクセスの発見
参考：SoftwareDesign7月 あなたにもできるログを読む技術[セキュリティ編] p21

18. セキュリティの為に
ログ分析をやってみようと
思っている方？

19. 安心して下さい
今日のテーマはセキュリティです

20. 最近、私自身も業務など
セキュリティ視点でのログ分析
に関わる機会が増えています。

21. セキュリティとしての
ログ分析とは？

22. 例えば、セキュリティ視点での
ログ分析を行うことで、
セキュリティインシデントの発見、
発生原因の特定、対策方法の検討
を実現出来ます。

23. どのようなログを見ればよいか？

24. • ファイヤーウォールを通過、または拒否された
通信ログ
• IDS、IPSが検知した不正通信ログ
• Webサーバへのアクセスログ
• プロキシサーバーのアクセスログ
• データベースサーバへのアクセス/クエリログ
• アプリケーションが出力する処理結果の
正常終了、異常終了、実行ログなど

25. セキュリティログ分析は
⃝⃝⃝？

26. ⃝⃝⃝？

27. セキュリティログ分析は
難しい

28. 「難しい」でした。
なぜ、そう感じたか・・・

29. MINI Hardening Project
への参加

30. MINI Hardening Projectとは？
• 元祖Hardening Projectとは違い初心者向け
• サーバハードニングを気軽に競技形式で学ぶ
• 自分達のサーバを攻撃者から守りぬく！
• １チーム 3∼4名で、作業を分担、
何をやるかは自分次第！

31. 初心者向けということで、
僕も参加してみました。
※July Tech枠で

32. 出来るだろうと思っていたことが
その場になるとほとんど出来ない
・ログから∼∼を見る
・∼∼のログから攻撃を判断する

33. 普段からセキュリティに深く
携わっている人でなければ
何か起きたその場でログを解析して
すぐに対処するのは難しい
攻撃されると焦るし、頭が真っ白に
なってくるよ・・・

34. ぐぬぬ！
そうだ、僕にも焦らないで
分析できる方法があるじゃないか！！

35. 分析ツールを使って、
事前に監視するログや見るべき
キーワードなどを定義しよう
ログ全文を見なくても視覚的に
判断出来るようにしよう

36. アクセス頻度に応じて増えていく
膨大な量のログを分析、
検索するには人力では難しい
目grepは都市伝説でした

37. 分析ツールを利用すると、
複数のログ・ファイルに対して横断的に
検索を素早く行ったり、
グラフなどの可視化を行ったり出来る。
１行のログからは見つけるのが難しい
アクセス傾向やサーバの挙動を発見
するのに便利

38. • Splunk
• Elasticsearch(ELK)
• ManageEngine
• ALog
• Logstrage
• Log Parser
• fulentd
ログ分析に活用できるツール例

39. ちょっとイメージつきませんよね
実際見てみましょう

40. アクセスログがたくさん！

41. 随時流れているログを見るのも辛い

42. たくさんログがあると
特定の文字列やデータを探すのに
時間がかかります
特にインシデントが発生している
状況では見逃す可能性も高い

43. さらにデータの集計を行うと
時間と労力が掛かります
攻撃を受けているであろう最中に
Excelやりますか？

44. 例えばHTTPレスポンスの
ステータスの統計を調べたい

45. このデータをExcelで集計

46. ログを手元に持ってきて、
インポートして、
整形して、
抽出して、
SUMとって、
そしてグラフ作って、、、
定常的なものであればマクロでいいけど
セキュリティインシデント対応など
突発的な場合は手作業になりますよね
しかも、この間も攻撃は続いています

47. 例えば、Splunkを使ってみると

48. 分析ツールをつかってみる！

49. ステータスコードの集計が瞬時に

50. グラフだって簡単に

51. そう、分析ツールを使うとね。

52. ただし、このように
ログ分析ツールを使う場合でも
定義するログの仕様を把握している
必要があります。
(Apacheのログとかは大体わかりますよね)

53. ∼おまけ∼
開発者目線で振り返る
ログの重要性

54. ご注意
あくまでも個人の見解ですが、
僕の実体験をもとにしています。
用法・用量を守り正しくお使い
下さい。

55. 質問です
開発者でログ分析のことを
考えて設計したことがある方？

56. 個人的な感想ですが、
僕は意識していませんでした。

57. たぶん、インハウスの
ソフトウェア開発者は
意識していない人が多いと思う。
理由は、何かあっても自分達の中
だけでクローズできるから
スケジュールなど他のことが重要視
されてしまう。

58. 意識して開発していないと
ログ出力の粒度が開発者に
依存してしまう。
レビューアー次第なところもある。
システム共通のログ出力標準化
ドキュメントとか見たことない。

59. 粒度が異なると、欲しい情報が
得られなく分析をする上で余計な
手間や作業が増えてしまう。
リリース後のアプリケーションの
機能変更はなかなかハードルが高いです。
特にログ出力の為に変更なんて出来ない。
出来るとすればバグ修正のタイミングくらい

60. とある、経験談ですが
(今の会社に入る前の話です)

61. 自分が所属する開発チームが
開発したシステムを
保守チームへ渡すときがあった

62. ログのパターンを全部記載した資料
を作成して渡したが、
ログのメッセージと原因を
ログのみでは判断できるよう作って
いなかった。
ログ+αの調査が必要でした。

63. この時、スケジュールが最優先で、
ログ出力の分岐パターンを
減らさざるを得なかった。
結果、ログだけでは原因を調査するのが
難しくなってしまった。
プロジェクト責任者の部長が降格もした
(ログのせいじゃないけど、たぶん)

64. 障害調査だけでもこんな感じなのに
利用状況、予測、セキュリティ
などのログ分析なんて考えてる
余裕はなかったよ・・・
パトラッシュ・・・

65. 今、ログ分析に携わる立場になって
開発者の時にログ出力に関して
プロジェクトリーダに上申するなど
もっと考えて実装しておけば
よかったと思います

66. アプリケーション開発の際は、
運用フェーズに入ったあとの
ログ分析を考えたログ出力実装を
出来る限り実行する必要があると
考えています

67. まとめ
• ログ分析をする目的を明確にしよう
• セキュリティインシデント発生時のログ分析は
非常に難しいので事前に準備をしておき対策をする
• 分析ツールを使うことを検討しよう
• アプリケーションを設計する場合は、
ログ分析をすることも考慮してログ出力機能の
実装を設計する事を推奨したい

68. ご静聴ありがとうございました。
MINI Hardening Projectの参加おすすめです