こんにちは、セキュリティチームのぐっちです。今回は Slack の DM を経由してファイルを持ち出すようなシナリオに対して Microsoft Sentinel で監査する方法について解説します。とあるプロジェクトで Sentinel を利用して Slack DM によるファイル共有を監査可能としたので、当たり障りのない範囲でブログにしました。
- 2024年10月8日時点の情報を元に作成しています。
- あるプロジェクトで実施したことではありますが、ブログ向けに当たり障りのない感じに補正してだしています。
- 当然、情報システムの構成や設定等によって、今回の設定が有効なケースもあれば、違う検出ロジックの方が優れているケースもあります。あくまで参考程度にお願いします。
3行まとめ
- Slackの DM を経由したファイル持ち出し経路に対し、Microsoft Sentinel と Logic Apps を活用して監視・検出を試みました。
- Slack のファイルアップロード時のアクティビティを監視・検出し、DM判定のために Slack API で自動調査を行い、Sentinel のインシデントにタスクとして登録するフローを作成しました。
- 本手法は全ての組織に当てはまるものではないが、Sentinel のタスクなどは他にも利用ユースケースが幅広いので、活用すると面白いと感じました。
要件の整理
本案件の状況(前提条件)
- Enterprise Grid プランを利用している。
- 社員が使用する PC にはデバイストラストを実施しており、私用のデバイスからのアクセスは不可としている。
- 一方で、業務上の理由から私用スマートフォンから Slack へのアクセス制御は行っていない。
- Slack のスマートフォンでのコピーやペースト、ダウンロード制限は行っていない。
- Slack と Sentinel をコネクタで接続し、Slack のログを Sentinel に流す設定をしている。
脅威シナリオ
今回は、Slack の DM にファイル(顧客リスト等)をアップロードし、私用のスマートフォンでダウンロードして持ち出す経路を想定しています。Slack の Enterprise Grid プランを使用すると「Slack DLP1」という機能が利用可能になりますが、DM には対応していないことや、スマートフォンでのコピーやペーストの制限を行えない諸事情を考慮して対策を講じます。
また、Slack では下書き状態のファイルをスマホでダウンロードすることもできるので、そのようなシナリオにおいても検出することを目指します。
注意:私用スマホ(BYOD)からSlackにアクセスさせないように制限したり、私用スマホ(BYOD)でのファイルのダウンロードを Slack の機能で制限する方が刺さるケースもあります。ユースケースに応じた対応の検討をお勧めいたします。
実装方針
Slack と Microsoft Sentinel を接続し、ファイルアップロード時のアクティビティを監視・検出し、必要に応じてアラートを発する実装を行います。この実装には次の2つのどちらかのログを活用できます。
Slack ログの名称 | ログの説明 | ログの特徴 |
---|---|---|
file_uploaded(採用) | ファイルがアップロードされた瞬間に下書き状態であっても記録されます。 | このログを利用することで網羅性が高い監視が可能となります。しかし、デメリットとしては、アップロードされたチャンネルの情報が取得できないことがあります。 |
file_shared | チャンネルまたはDMにファイルが共有された瞬間(下書きから投稿になった瞬間)に記録されます。 | このログでは、共有されたチャンネル ID を取得可能で、チャンネルの状況に応じたリスク分析が可能です。ただし、ドラフト状態でのリスクに対応するには不十分な部分もあります。 |
今回のユースケースでは、全社的なファイルアップロードを起点に監視を行う方針を採用しました。しかしながら、file_uploaded ログでは、投稿されたチャンネルの情報がとれないので、Slack API を利用してチャンネル情報の自動調査を行い、Sentinelのインシデントにタスクとして登録するフローも作っています。
実装方法
Sentinel で検出
Sentinel で分析ルールを作成し、ファイルアップロードのイベントを検出するクエリを設定します。下記は24時間に1回実行することを想定したクエリです。画像ファイルなどに関してはリスク受容する方針とし、除外設定を行っています。その辺の調整は組織ごとのポリシーに基づいてお願いします。
SlackAudit_CL
| where TimeGenerated > ago(24h)
| where actor_user_name_s != "Slackbot"
| where action_s == "file_uploaded"
| where not(entity_file_name_s endswith ".png" or entity_file_name_s endswith ".jpg" or entity_file_name_s endswith ".jpeg" or entity_file_name_s endswith ".mov")
| summarize
count_of_uploads = count(),
files = make_set(entity_file_title_s, 100),
users = make_set(actor_user_name_s, 100),
user_emails = make_set(actor_user_email_s, 100)
| project
TimeGenerated = now(),
count_of_uploads,
files,
users,
user_emails,
Title = "非画像ファイルアップロードを検出",
Description = strcat("過去24時間で ", count_of_uploads, " 件の非画像ファイルアップロードが検出されました。")
このクエリにより、特定のファイルタイプを除外しつつ、ファイルのアップロードイベントを監視します。
DM 判定自動調査とタスク登録
上記のクエリを使うと、全てのファイルアップロードが検出されますが、そこから次に DM 判定を行います。理由として、Slack のパブリックチャンネルでは多くの目によるチェックが期待できる一方、DM やプライベートチャンネルでの活動はよりリスクが高いと考えられます。そのため本プロジェクトにおいては、DM やプライベートチャンネルに関しては厳格に監査を行う方針としました。DM判定の実装には Logic Apps を利用しました。Logic Apps を使い、Sentinel のインシデントをトリガーにして、各ファイルの共有先チャンネルや DM の判定を行います。
「クエリを実行して結果を一覧表示する」では、下記のクエリを利用して、ファイルアップロードの一覧を取得します。
SlackAudit_CL
| where TimeGenerated > ago(24h)
| where actor_user_name_s != "Slackbot"
| where action_s == "file_uploaded"
| where not(entity_file_name_s endswith ".png" or entity_file_name_s endswith ".jpg" or entity_file_name_s endswith ".jpeg" or entity_file_name_s endswith ".mov" or entity_file_name_s endswith ".pdf")
| project TimeGenerated, actor_user_name_s, entity_file_id_s, entity_file_title_s, actor_user_id_s, entity_file_name_s
続いて、For Each アクションを用いて、ファイルごとに Slack API で情報を取得します。これにより、ファイルがDMに存在するかどうかや、どのチャンネルに共有されているかを調査します。なお、Slack API で調査できるのはBotが存在するチャンネルのみなので、全てのチャンネルにBotを入れている状況であれば、このAPIの実行がエラーとなるとDMとして判定できます。
{
"type": "Http",
"inputs": {
"uri": "https://slack.com/api/files.info",
"method": "GET",
"headers": {
"Authorization": "@{parameters('slack-token')}"
},
"queries": {
"file": "@{items('For_each')['entity_file_id_s']}"
}
},
"runtimeConfiguration": {
"contentTransfer": {
"transferMode": "Chunked"
}
}
}
パブリックチャンネルで共有されたファイルに関しては簡単な確認のみで済ませますが、DM に共有された場合は調査タスクを Sentinel タスクとして作成します。 Sentinel タスクには、ファイル名やファイルURL等の情報を付与し、調査しやすい状況を作ります。
すると、Sentinel のインシデントに以下のように調査タスクを起票することができました。セキュリティ運用担当はこれを見ながら対応することができます。Sentinel の KQL で見ていくより情報が見やすいと感じるので、インシデントタスクは非常に使い勝手が良さそうです。
その後の対応に関して
検出した後の対応については組織ごとに対応ポリシーを作って対応する形が望ましいので、本ブログでは詳細は割愛させていただきます。とはいえ概要だけお伝えすると、必要に応じて ユーザーにインタビューをしたり、Slack のデータ保持ポリシー(リーガルホールド)2を適用するなどの対応を行うことが考えられます。また、Druva等でPCローカルに存在するファイルをバックアップしておくと、ファイルの実態を捉えることができるので、調査にそのような仕組みを利用するのも有効な手段です。加えて前提として、DMでのファイル共有が増えると運用が破綻するので、最小限にするようなルールを施行しておくのも1つの手段です。
まとめ
Slack の DM を通じたファイル持ち出しリスクに対して、Microsoft Sentinel と Logic Apps を活用することで、監視・検出が可能となります。特に、Slack のログを組み合わせて使用することで、より網羅的な監査体制を構築することができます。もちろん、全ての組織で当てはまるものではなく、むしろニッチな要件だとは思いますが、今回紹介した Sentinel のタスクなどは他にも利用ユースケースが幅広いと思いますので、是非活用いただけたら幸いです。
- Slack DLP https://slack.com/intl/ja-jp/help/articles/12914005852819-Slack-%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E6%90%8D%E5%A4%B1%E9%98%B2%E6%AD%A2 ↩︎
- 訴訟ホールドを作成および管理する https://slack.com/intl/ja-jp/help/articles/4401830811795-%E8%A8%B4%E8%A8%9F%E3%83%9B%E3%83%BC%E3%83%AB%E3%83%89%E3%82%92%E4%BD%9C%E6%88%90%E3%81%8A%E3%82%88%E3%81%B3%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B ↩︎