メインコンテンツまでスキップ

トリアージを始める

セキュリティへの取り組みは、リスクの継続的な洗い出しと、リスクの継続的な低減・解決の両輪で成り立つものです。 ここまでのステップを通して、Shisho Cloud の初期設定は完了できましたから、ここからは日々のリスク把握・解決のワークフローを実践してみましょう。

対応すべきことを把握する

Shisho Cloud による検査結果が確認できるようになったら、ダッシュボード評価結果欄を確認してみてください。 標準設定では、ここには対応の緊急度順に重要な検出事項(ポリシーへの違反事項)が並びます:

ここではおよそ、検出されたセキュリティ上の課題・推奨事項について、以下の内容を確認できます。

  • 詳細にはどのような問題か
  • どのようなリスクがあるのか
  • 修正に向けた方針や Tips

トリアージ方針を決定する

検出されたセキュリティ課題・推奨事項が把握できたら、その課題にどう向き合うかを検討しましょう。 Shisho Cloud では、新しく検出された事項は必ず レビュー待ち 状態として扱われます。 この状態からは、以下の 3 つの選択肢から方針を選択できます:

  • 要対応扱いにする:
  • 指定した期限まではリスクを受容する
  • リスクは受容できるので、対応しない:

これらを選択することで、検出項目は、以下のいずれかの状態に遷移します:

  • レビュー待ち
  • 要対応
  • リスク受容中(期限付き)
  • リスク受容中(無期限)

レビュー待ち要対応 ステータスにあるものが、組織的に今向き合うべき課題であり、リスク受容中 ステータスにあるものは今は意識の外に置いてよいもの、と使い分けるのが好ましいでしょう。

info

種々の統計が表示されるダッシュボード上で表示されるのは、レビュー待ち要対応 ステータスにある検出事項に限られます。 リスクを受容している検知事項の総量は、また別のダッシュボードとして提供予定です。

通知によるトリアージ状況の共有

通知設定 で指定した最低緊急度以上の問題のトリアージプロセスは、以下のように各種通知先にも通知されます。

Slack 通知の例

メールによる通知の例

note

通知ワークフロー の編集画面にて 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