トリアージを始める
セキュリティへの取り組みは、リスクの継続的な洗い出しと、リスクの継続的な低減・解決の両輪で成り立つものです。 ここまでのステップを通して、Shisho Cloud の初期設定は完了できましたから、ここからは日々のリスク把握・解決のワークフローを実践してみましょう。
対応すべきことを把握する
Shisho Cloud による検査結果が確認できるようになったら、ダッシュボード の 評価結果欄を確認してみてください。 標準設定では、ここには対応の緊急度順に重要な検出事項(ポリシーへの違反事項)が並びます:
ここではおよそ、検出されたセキュリティ上の課題・推奨事項について、以下の内容を確認できます。
- 詳細にはどのような問題か
- どのようなリスクがあるのか
- 修正に向けた方針や Tips
トリアージ方針を決定する
検出されたセキュリティ課題・推奨事項が把握できたら、その課題にどう向き合うかを検討しましょう。 Shisho Cloud では、新しく検出された事項は必ず レビュー待ち 状態として扱われます。 この状態からは、以下の 3 つの選択肢から方針を選択できます:
- 要対応扱いにする:
- 指定した期限まではリスクを受容する
- リスクは受容できるので、対応しない:
これらを選択することで、検出項目は、以下のいずれかの状態に遷移します:
- レビュー待ち
- 要対応
- リスク受容中(期限付き)
- リスク受容中(無期限)
レビュー待ち と 要対応 ステータスにあるものが、組織的に今向き合うべき課題であり、リスク受容中 ステータスにあるものは今は意識の外に置いてよいもの、と 使い分けるのが好ましいでしょう。
種々の統計が表示されるダッシュボード上で表示されるのは、レビュー待ち と 要対応 ステータスにある検出事項に限られます。 リスクを受容している検知事項の総量は、また別のダッシュボードとして提供予定です。
通知によるトリアージ状況の共有
通知設定 で指定した最低緊急度以上の問題のトリアージプロセスは、以下のように各種通知先にも通知されます。
Slack 通知の例
メールによる通知の例
通知ワークフロー の編集画面にて triggers
セクションを編集することで、トリアージの通知を絞り込むこともできます:
triggers:
triage:
# send notifications when...
- event: [updated]
status_changed_to:
# 問題のレビューが必要です
- awaiting_review
# 問題は認識済みであり、これ以上の対応は不要です
- acknowledged
# 問題は修正が必要な状態としてマークされています
- action_required
# 問題は修正済みです :tada:
- secure
# セキュリティ上の問題があったリソースが削除されました
- deleted
# 対応が必要な検出結果に関する通知を送信する
- event: [created]
status_changed_to:
- awaiting_review
例えば、新たなリスクが検出されたとき、あるいは設定の修正・削除によりリスクが解消された場合にのみ通知し、トリアージに関する途中経過を通知しない場合は、triggers
セクションを以下のように編集することでそれが実現できます:
triggers:
triage:
# send notifications when...
- event: [updated]
status_changed_to:
# the issue was fixed :tada:
- secure
# the resource with security issue(s) gets deleted.
- deleted
# send notifications on a finding needs your action
- event: [created]
status_changed_to:
- awaiting_review