Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

ノーコード セキュリティ自動化サービス「Tines」による運用自動化の取り組み

こんにちは。Sansan CSIRT の松田です。
本記事では、Tines というノーコードで自動化するためのサービスを使ってみたので、その紹介と所感をお届けできればと思います。
今回はセキュリティ運用の自動化に挑戦してみました。



なぜ自動化に向き合う必要があるのか

セキュリティに限った話ではないですが、この先常に自動化を意識していく必要があると考えています。
理由は言わずもがなですが、どの企業でも重要視されているセキュリティエンジニアという貴重な人材は潤沢に確保することが困難です。
少数精鋭でも日々の運用の品質を常に向上させ、長期間それらを維持していくことが CSIRT には求められています。事業の急成長に合わせて必ずしも見合う程のリソースを確保できるとは限りませんし、いつ大規模なインシデントが発生するかもわかりません。そんな危機感が今回の挑戦のきっかけでもあります。人間が実施する必要がない作業は自動化していきます。

全部は自動化しない

一言で自動化と言っても、自動化できる領域は限られています。
いままでやってきた運用全てを自動化できるなんてこと、そんな甘い話は無いです。
少なからず人間がやっていたものであるならば、作業の他に、そこには何かしらの意思と意図があることを常に意識しておく必要があります。ここは本題ではないので詳しくは触れませんが、運用自動化、不都合な真実 が非常に参考になります。

SOAR とは

セキュリティ運用の自動化と言えば、SOAR (Security Orchestration, Automation and Response) という概念があります。この概念は非常に重要であり、セキュリティの運用には絶対に必要です。ところが、実装レベルでは SOAR の一部の概念を取り出し、ごく希にしか発生しないような運用に適用したり、人間の判断が必要なケースを無理矢理にでも自動化するようなことが起きます。例えば、「緊急度の高い事象をエンドポイントセキュリティで検知した場合に、その端末を自動的に隔離する」みたいなやつです。一見正しいような自動化にも見えますが、そこには隔離に至るまでにされるべき判断を全て無視していることになり非常に危険です。人間がするべき判断とそうでない判断を正しく区別し、整理できてやっと自動化に至りますが、セキュリティは生き物であり、そこにあるリスクは常に変化すること忘れてはなりません。

適用領域の具体例

今のところ以下を予定しています。

定期確認している作業を自動的にチェックし通知する

確認項目がある場合のみ人間がチェックすることで定期確認を合理化する

機密性の高いファイルを全社で閲覧可能な共有フォルダにアップロードされた事を検知し、そのパスを調査し通知する

クラウドストレージの監査ログにはファイルパスが無く調査に時間を有するが、予め調査した状態で必要なものだけを通知できる

外部から提供された脅威情報を SIEM、各種セキュリティ製品で過去のログを検索し、ブロックリストとして適用する

高度なセキュリティは多層防御という基本の上に成り立つため、ブロックリストを複数存在する監視ポイントに対して一度に適用できる

Slack のワークフローやスラッシュコマンドを用いて複数のサービスから判断根拠となる情報を集約し、整形してスレッドに結果を投稿する

様々な調査で利活用できるため一次調査の品質とスピードを格段に向上できる

Tines

前置きが少々長くなりすぎました。本題に入ります。
Tines *1 は製品及びサービス間の連携を疎結合な状態を維持しつつ、ノーコードでシンプルに SOAR を実現できるサービスです。冒頭でも述べましたが、自動化できる領域は限られています。セキュリティ運用の品質を向上させ、それらを長期的な維持を目的に利用します。
www.tines.comTines を用いると小さいワークフローをピースのように組み合わせて大きなワークフローを構成できるようになり、必要に応じて組み合わせを変更するだけになります。連携するサービスの変化や増減は一定数あることを前提とした一定周期での使い捨ても許容できるようになります。
適用を予定していた領域に対していくつか実装してみたので紹介します。

定期確認している作業を自動的にチェックし通知する

f:id:ss-matsuda:20211220164429p:plain
まずは、定期確認している運用チェックに適用してみました。
Tines のストーリー*2 は以下の通りです。
f:id:ss-matsuda:20211220145057p:plain

基本動作
  • 毎日N時に実行する
    • Slack からもスラッシュコマンドで手動実行できるようにした
  • 完了ボタンを押す
流れ
  1. 平日かどうかを確認する
  2. Google Workspace を確認する
  3. EDR を確認する
  4. MSS Portal を確認する
  5. 確認結果を集計する
  6. 確認のパターンに応じて Slack の通知文言を分ける

f:id:ss-matsuda:20211220163016p:plain
上記のように何も無ければその日の定期作業は不要となります。

機密性の高いファイルを全社で閲覧可能な共有フォルダにアップロードされた事を検知した場合に、そのパスを調査し通知する

f:id:ss-matsuda:20211220165457p:plain
次に SIEM との連携にも挑戦しました。*3
Tines への送信時に以下のように指定することで簡単に連携できます。*4

{{#toJson}}ctx.results.0{{/toJson}}

Tines のストーリーは以下の通りです。
f:id:ss-matsuda:20211220180835p:plain

流れ
  1. SIEM からアラートを受け取る
  2. 複数受け取った場合は分割する
  3. クレデンシャルを元にファイルパスを取得する
  4. 共有フォルダだった場合はアップロード実施者に通知する

利用してみた所感

一切コードを書かずに、セキュリティ運用の品質を向上させ、それらを長期的に維持するための土台として十分に価値があることが分かりました。
Tines は Liquid *5というテンプレート言語を用いて柔軟な加工が可能となっており、少々複雑な要件でもシンプルに実現できることに驚きました。
ただし、各サービス間は API による連携になるため、以下が最低限前提として必要になります。

  • HTTP の基本的な仕組みを理解していること
  • OAuth や JWT の基本的な仕組みを理解していること
  • 各サービス毎の API 利用方法をドキュメントから読み解き、リクエストが組み立てられること

少々複雑なワークフローでも基本をしっかり抑えていれば問題なく対応できます。
引き続きその他に予定している領域に対しても順番に適用して活用していきたいと思います!

*1:使い勝手を把握するために Community Edition の利用から始めます

*2:ワークフローのようなもの https://hub.tines.com/docs/quickstart

*3:SIEM の詳細は 全社統合ログ基盤を構築して得た知見 - Sansan Builders Blog を参照ください

*4:詳しくは Mustache Templates を確認してください

*5:Shopify によって開発されたテンプレート言語 Liquid template language

© Sansan, Inc.