脅威と脆弱性から考えるSlackを安全に使う方法

この記事はSlackにどのような脅威、脆弱性があるか再認識し、安全に使うための方法を考えた資料です。

今、Slackのセキュリティポリシーがあまり決まっていない企業はこれをチェックリスト的に使ってもよいですし、私のように脅威と脆弱性を網羅的に考えてみるのもよいと思います。

今回の発端はSlackを使う上でのリスクはなにか？という問いが来たら、どう答えるかと考え始めたのがきっかけです。

最初はただの思考実験としてやっていたのですが、そのさなかで実はSlackを安全に使う情報ってあまりないなって気づきました。英語での記事はいくつかみつかりました。

4 tips to mitigate Slack security risks

そうSlackの情報で多いのは、Slackを使うとこんなに便利に使えますよって記事です。なので今回、記事化に至りました。

また本記事を作成するにあたって、脅威モデリング関係の記事、そして海外のSlackセキュリティ関係の記事を大いに参考にさせていただいています。

前提

* 資産とは
　* 守るべきデータ、情報
* 脅威とは
　* 資産への損害を発生させる直接的な原因
* 脆弱性とは
　* リスクを発生・拡大する要因となる弱点や欠陥
* リスクとは
　* 損害を受ける可能性、影響の大きさ
* セキュリティ対策とは
　* 損害を受ける可能性を減らしたり損害を受けても影響を小さくしたりしてリスクをコントロールすること

結論

下記のような対策を行うことで一定レベル安全に使用することができる
対策の工数や効果は定量的なものではなく、私の感覚的なものです。

難易度はAが簡単でCが難しいとしており、これは実行難易度と工数（時間がかかるか）をあわせて考えています。効果はAが効果が高く、Cが効果が低いとしています。

脅威、脆弱性、対策の洗い出し手順

1. 使用環境の可視化
Slackを含む周辺の使用環境を絵にします。
絵で表せないものは分析できない、とのこと。

細かいところは各企業ごとに違いますが、Slacアプリケーションがあって、Slackのバックエンドがあって、SlackアプリやSlack Connectでつながるアプリや企業があって、利用者や管理者がいるというところは変わらないでしょう。

今回はこの粒度で書きました。重要な要素の抜け漏れがなければそれで良しとします。

2. 資産

Slackでやり取りされる情報、つまり資産は各社異なってくると思います。
ここにSlackでやり取りされているであろう情報を想定で記載しておきます。

1. 経営に関する情報
　1. 会社の方針、戦略（一部）
　2. 新規事業に関する情報
　3. 既存事業の数字
　4. 会計に関する情報（一部）
2. 業務マニュアル、ノウハウ
3. 取引先、委託先とのやり取り
4. システムの構成や設定に関する情報
5. 社員の個人情報
6. 認証情報（IDやパスワード）
7. （場合により）顧客の個人情報

守るべき資産の定義と照らし合わせて、もし該当する資産がSlack上に存在するならきちんとセキュリティ対策を行っていく必要があります。

逆に守るべき資産がSlack上に存在しないなら、Slackに不正アクセスされても会社へのインパクトは低いと言えるので、セキュリティレベルは落としてもよいと言えます。（ただし、Slackを経由して攻撃されるというリスクは残ります）

重要なのはSlackにどのような情報があるかを認識しておくことだと思います。そのうえでセキュリティレベルは高いほうがいいのか低くてもいいのか、という判断を会社として行って置いたほうがいいでしょう。

3. 脅威

脅威は資産を脅かす存在、状況、イベントです。これらを洗い出していくわけですが、いくつかフレームワークが存在します。その1つがSTRIDEです。脅威がカテゴリ化されており、それをベースに洗い出す方法です。

今回はSTRIDEを使ってみました。ただ初めてなので細かい部分がわかってないです。否認とかよく理解できなくて難しい...またSlackのバックエンド（といったSlack社サイド）などの脅威を出しても、利用者としてはどうにもならない

1. なりすまし
　1. IDパスワードが盗まれる
　2. デバイスが盗まれる
　3. 認証のセッション期間が長い
　4. キャッシュファイルを解析される
2. 改ざん
　1. Slack上のメッセージ、ファイルが改ざんされる
　2. Slackアプリケーションのコードが改ざんされる
3. 否認
　1. ログが消される
4. 情報漏えい
　1. Slack社のシステムに不正アクセス
　2. Slackアプリケーションとバックエンドの間の暗号化通信が解読される
5. サービス拒否
　1. Slack社のシステムがDoS攻撃されSlackが使用できなくなる
6. 特権の昇格
　1. Slack社のシステムに侵入され、特権昇格される
　2. 何らかの脆弱性でゲストユーザから管理者権限などに昇格される

その他
- ダークなSlack管理者の存在
- Slack Connectでつながっている取引先のダークな従業員の存在
- Slackアプリとして接続されているシステムが不正アクセスされる

4. 脆弱性
次は脆弱性を洗い出します。脆弱性は弱点です。さきほど洗い出した脅威がこの脆弱性を突くことでリスクが顕在化されます。

1. 弱いパスワード
2. IDパスワードのみの認証
3. どのデバイスからでも接続できる
4. セッション設定が永続的
5. 誰でもSlackアプリが入れ放題
6. 誰でもSlack Connect増やし放題
7. Slackのトークンが整理されていない
8. Slackアプリが整理されてない
9. Slackチャンネルが整理されてない
10. 監査ログがない
11. アクセスログが見にくい
12. Slackチャンネルにファイルが永続的に残ってる
13. 重要データがSlackに存在するというSlack使用者の理解不足
14. 業務効率を何よりも優先するSlack使用者の意識
15. Slack管理者の設定不備
16. 特権が整理されていない
17. Slackに価値ある資産がある

5. リスク軽減

リスクを減らすには、下記3つを行っていきます。

1. Slackにある資産価値を減らす
2. 脅威を減らす
3. 脆弱なポイントを対策する

ここまで洗い出した資産、脅威、脆弱性を元に考えてみます。

やってみた感想

一定の手順に沿って脅威、脆弱性を洗い出せるのはすごくよかった。しかし、ある程度の慣れが必要だなと思いました。特に脅威を洗い出すのが難しくてNIST SP800-30とかを参考にしていたのですが、読んでもよくわからずじまいでした。

この分野について指導できる人と一緒に行って、やり方を指摘してもらいながら行うのが習熟するには良さそうです。

セキュリティ対策といったときに根拠なく、なんとなく対策をすることが見受けられますが、そのシステムにどんな資産があるのか、といったことから考えていくと説得力があり、かつ、意味のあるセキュリティ対策（リスクのコントロール）が行えるのではないでしょうか。

参考サイト
* https://www.slideshare.net/takutoyamada2/ss-226479043
* https://docs.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool-threats
* https://qiita.com/takutoy/items/688b6b0517003f35e79a
* https://docs.microsoft.com/ja-jp/security-updates/planningandimplementationguide/19871782
* https://www.ipa.go.jp/files/000046476.pdf