今回はこちら。最近はサイバーセキュリティの文脈でもよく聞くようになった「MTTD（平均検知時間）」「MTTR（平均復旧期間）」について、いつもよりちょっとだけ掘り下げて考えてみます。Sciencelogic社のブログがとってもいい感じでした。実は奥が深いぜMTTR！
https://sciencelogic.com/blog/mttr-vs-mttar-vs-mttd-incident-management-metrics
Sciencelogic Blog - Brian Amaro Sr. Director Global Solutions, ScienceLogic
もくじ
どんな人におすすめ？
サイバーセキュリティ戦略とそのKPIを設定する責任を持っている人向けの内容です。もちろんSOC運用担当者も話題的にドンピシャではあるものの、時間を評価指標にする意義と有用性を身に染みて感じるべきなのは、現段階だと戦略家であろうと強く思います。なぜなら、経営層に報告する際の指標として重宝するからです。
加えて、特に監視サービスを提供している/提供を受けている企業にとってMTTD/MTTRは超重要指標になるため要チェックです。特に有事の際は、検知から復旧までの全プロセスにおける時間の最適化が死活問題となるため、頭に叩き込んでおく必要があるでしょう。
どんな内容？
MTTRに関わる全ての指標を正しく理解して、改善に活かそうぜっていう内容です。まずは「MTTx」一族に属する指標たちを見ていきましょう。
- MTTD（Mean Time to Detect：平均検出時間）…ある問題が注意を要するものとして特定されるまでの時間
- MTTA（Mean Time to Acknowledge：平均認識時間）…アラートがIT運用チーム側でアクションの開始（通常はサービスチケットの発行）につながるまでに必要な平均時間
- MTTR（Mean Time to Respond：平均応答時間）…サービスチケットに関連する作業を開始するために必要な平均時間
- MTTK（Mean Time to Know：平均把握時間）…障害の原因把握に必要な平均時間。
- MTTR（Mean Time to Repair：平均修復時間）…検出時点からシステムが修復されるまでに要する時間
- MTTR（Mean Time to Resolve：平均解決時間）…検出時点からシステムが修正され、関連システムが適切に動作することを確認するためにテストされるまでに要する時間
- MTTR（Mean Time to Recovery：平均復旧時間）…検出時点から関連システムが完全に稼働するまでに要する時間
…ちょっと待て。多くない？特にRが多くないか？MTTRだけでも4種類あるぞ。最後の畳みかけがすごいぞ。って思いましたよね。私もそう思いました。しかしながら、この細かさが大事なところです。乱暴にMTTRと括るだけではダメで、目的のためにはきちんと因数分解して活用すべきということです。そして上記全てのKPIに共通することは値が小さくなればなるほど良いという点です。数値が小さい＝短い時間で解決できているということなので、「MTTx一族は小さいに限る」ということです。
あと、「MTTx」一族とは別に「MTBx」一族というのもいます。
- MTBF（Mean Time Between Failure：平均故障間隔）…特定のデバイスやアプリケーションのインシデントが発生するまでの時間。
- MTBSI（Mean Time Between System Incidents：平均システム障害間隔）…システムまたはサービスの単一コンポーネントの障害ではなく、システムまたはサービスの障害間の平均時間
こいつらは「MTTx一族」とは逆で、「MTBx一族は大きくなればなるほど良い」です。これらの指標は障害が起きてから次の障害が発生するまでの期間を示しているので、大きければ大きいほどいいです。以外に追跡していない指標かもしれません。
注目ポイント
そんなこんなで「時間を制する者はサイバーリスクマネジメントを制す」と言っても過言ではないくらい重要な指標である「時間」なわけですが、それをできる限りMECEに細分化しているのがこのブログのステキなところ。図で表すとこんな感じです：
ちょっとした例で考えてみます。
「株式会社せいうち」は過去17年間で合計3回、サイバー攻撃による可用性の侵害を受けています。その対応時間の内訳は以下です。（注）完全に創作です。
最も古い発生日は2007年1月15日で、その次のインシデントは3204日後の2015年10月24日に発生しています。そしてその次のインシデント発生日は2994日後の2024年1月4日です。二回しかサンプルがないので平均でいいのかはさておき、この場合のMTBFは3099日、すなわち約8.5年です。サイバー攻撃による事業停止のリスク発生率は8.5年ごとに1回なので、年間発生確率は11.8%です。
そして、インシデント発生からの各フェーズの対応時間を見てみると、フェーズによって対応に掛かった時間に差があります。Detect, Know, Resolveフェーズは完了まで時間がかかっており、その中でもDetectとResolveは標準偏差が大きいのが特徴です。標準偏差が大きいということは平均からのばらつきが大きいということなので、平均時間よりも短く終わるときもあれば長くかかってしまうこともあるということを意味しています。つまり、完了時間の予測が立てづらいということですね。したがって、株式会社せいうちが重点的に強化すべきフェーズは「Detect」と「Resolve」で、リスクシナリオによる対応力のばらつきを少なくするような対策が有効であると思われます。
感想
ここまで見てきた通り、「時間」に関する指標は現代のサイバーリスクマネジメントの超ウルトラスーパー重要指標です。ここ数年で注目度が上がっている理由はいくつかありますが、主要なものは以下のとおりです：
- ランサムウェア攻撃の影響：法人のランサムウェア被害が一般化したことにより「可用性」の確保に注目が集まるようになりました。今まで「機密性」だけに注目が集まりがちだったところから「ああ、マジでサイバー攻撃で事業止まるじゃん」ってなったわけです。そうなると、ITインフラのSLAを脅かすリスク要因に「サイバー攻撃による破壊・停止」が入ってくるので、損失を推定・軽減するためにもMTTRやMTBFの概念がサイバーセキュリティでも重視されるようになっています。
- サイバーリスク定量化のニーズ：サイバーセキュリティはビジネスの観点で利益を生み出すものではありません。たまに記事やセミナーで「サイバーセキュリティは投資です」といった文言を聞きますが、それは事実ではなくレトリックです。しかしながら、経営層からすると「サイバーセキュリティへの資源投下の度合いの判断」をしなければならないのは確かです。そのニーズに応えられるのが「時間」という尺度です。事業停止時間と時間当たりの売上/製造量などがわかれば金額換算が容易です。
"Detect" から "Recover" までが途切れることなく繋がっていて、DetectされてからRecoverまでストップウォッチが止まらない、というところがポイントです。どのステージに時間がかかっているのか、なぜ時間がかかっているのかを振り返ることができればレジリエンス強化につながります。おそらく企業で特に差が出るところは「MTTK」です。そもそも自社でSOCを持っているいるか否かで自社がコントロールできる度合いが変化しますが、原因解明は少なくともEDRが入ってないとそりゃもう泣きたくなる作業です。MTTKの短縮は今後の伸びしろじゃないかと思います。ただし、PCがフリーズしたときのリブートと同じように、原因はよくわかんないけどまた使えるようになればいいやという判断もあり得ます。なのでその方法が良いか悪いかは場合によりますが、それとMTTKを無視してセキュリティを設計してよいわけではないので要注意です。
そして最後にコストの話。先の例だと、株式会社せいうちでのサイバー攻撃の年間発生確率は11.8%で、MTTRは65.7時間＝2.7日です。セキュリティ投資を判断する場合に、㈱せいうちの1日あたりに生み出す利益が1000万円だとすると、一回のインシデントで失う利益は2700万円。それを発生確率の11.8%と掛け合わせると318万円です。したがって、現時点で年間200万円を投資しているならば、年間100万円くらいの追加が妥当なラインだろうとみるのが、定量化の考え方です。
最後までお読みいただきありがとうございました。ではまた次回。
おわり
