目次
1. はじめに
2. 脅威分析について
3. 脅威分析の方法
4. AWS環境における脅威の洗い出し
5. まとめ
はじめに
業務でAWS環境にあるサービスへの脅威分析について検討することがあり、
その中で悩んだことや発見を書き綴っています。
そもそも脅威分析とはどういうもので、それがどう役立つのか
特にAWS環境への脅威分析と観点の洗い出しいう所に焦点をしぼって書きました！
脅威分析について
そもそも脅威分析とは何なのでしょうか？
脅威分析とは、システムやアーキテクチャの構造における脅威を洗い出し、
想定しうるリスクや守りたい資産は何かを把握する分析のことです。
その分析をすることで、リスクが高い部分を認識し、優先的にどのような対応をしていくかの計画をすることができます。
※この記事内の「リスク」や「脅威」は以下の意味で記載
リスク：損害を発生させる可能性のこと
脅威：リスクを引き起こす要因のこと
ただし、脅威分析をすれば、対応するべき対策がすべて取れるとれるということはなく、
あくまでも、セキュリティ対策の検討する上での一つの参考情報として捉えるのが良いかと思います。
脅威分析の方法
以下は脅威分析の流れの一例になります。
①システム構成図を書く
( Synopsys 脅威モデリングとは より画像引用 )
脅威分析をする場合は、上記のような図を書き出したほうが良いと思います。
図の中には、
- 各コンポーネント(例 ブラウザ、Webサーバ、DBなど)
- 守りたい資産(例 個人情報、機密情報など)
- コンポーネント間の通信(http(s)、sshなど)
- ネットワーク信頼境界線
などを記載します。（正解はない）
② 各コンポーネント間のデータの入出力に注目し、
脅威モデリングの1つである STRIDE の観点で脅威を洗い出します。
※STRIDEとは
STRIDE はマイクロソフトにより提唱されている脅威モデリング手法です
S： Spoofing(なりすまし)
T： Tampering(改ざん)
R： Repudiation(否認)
I： Information disclosure(情報漏えい)
D： Denial of service(サービス停止)
E： Elevation of privilege(権限昇格)
図を書き出し、情報資産へのアクセス経路をSTRIDEに沿って検討していくことで、
設定を注意するべき所やモニタリングするべき所を確認していきます。
分析をする上で、脅威を洗い出すことがポイントになります。
(一番悩んだ部分は、この部分でした)
上記は一例で、この他にも脅威の洗い出しを行なう観点は色々あると思います
順不同
| No. | 観点例 | 補足 |
|---|---|---|
| 1. | 素直にブレストをしてみる | 網羅的に洗い出せない可能性があるので、補助的に活用 |
| 2. | OWASP Top10 | OWASP Top10の観点から脅威がないか考える |
| 3. | セキュリティニュース | ニュースになっているセキュリティ事故が自社サービスにおいても適用するか？という観点で考える |
| 4. | ビジネス要件から考える | ビジネスの要件を出し、一番守りたいこと(もの)は何か？という観点で考える |
| 5. | 攻撃者視点から考える | 攻撃者だったらどこから情報を取得していくか？という観点で考える |
脅威分析の概要と手法に関しての説明はざっとこのような感じになります。
次は、AWS環境ではどうかについて考えたいと思います。
AWS環境における脅威の洗い出し
AWSにおける脅威を洗い出す観点やツールについて記載します。
①責任共有モデル
( 責任共有モデルより画像引用 )
ご存知の方が多いかと思いますが、AWSには責任共有モデルという考え方があります。
クラウドのユーザ側が管理する所にフォーカスし脅威観点を考慮します
例：
MFAの設定不備によるマネジメントコンソールへの不正ログイン
IAMロールの信頼済みエンティティからの不正アクセス
②MITRE ATT&CKを利用する
( MITRE ATT&CKより画像引用 )
MITRE ATT&CKは、サイバー攻撃者の戦略について体系化しまとめているフレームワークで、
脅威分析のインプットとして利用できるかと思います。
MITRE ATT&CKの概要については以下の記事に記載しています。
③Amazon GuardDutyを利用する
( Amazon GuardDuty の開始方法 より画像引用)
AWSのマネージド型の脅威検出サービス
悪意のあるアクティビティやAPIコールなどの脅威を検出します。
GuardDutyを利用して脅威を洗い出しするというよりかは、GuardDutyで検出された脅威をインプットとして利用できるかと思います。
④AWS Exploitation Frameworkを利用する
Pacu というAWSへの攻撃用フレームワークを利用してみる
(https://github.com/RhinoSecurityLabs/pacu)
利用するには、クレデンシャルキーをセットする必要がある。
(画像はローカル実行時のキャプチャ)
こちらについても、Pacuを利用して脅威の洗い出しに利用するというよりは、
クレデンシャルが漏れた場合のリスクをインプットに使えるかと思います。
クレデンシャルキー漏洩した時点で基本的になんでもできてしまいますが、
ツールを使うことでこんなに容易にAWSリソースへの不正利用ができてしまうのかと思ってしまいました。
まとめ
- 脅威分析を利用することで、多面的なセキュリティリスクに対し、どのような対応(軽減・回避・受容など)するのかの検討につながる
- 脅威観点の洗い出しには、攻撃者の視点やフレームワークを利用する
- また、より深い分析のためには開発プロセスやアプリケーションの仕様への理解が必要であり、協力しながら進めていくのが大事だと思いました。
参考
以下を参考にさせて頂きました。