はじめに
皆様、こんにちは。h12oです。情報システムオフィスに所属して、プロダクトセキュリティの第二線を担当しています。
当社はSPIDERPLUSをより良いプロダクトにするため、新規開発、機能拡張、不具合修正など様々な変更を日々加えています。SPIDERPLUSは、常に変化するプロダクトともいえます。
変化は進歩のために必要不可欠ですが、同時に新たなセキュリティリスクを生み出すおそれもあります。
プロダクトの小さな変更が、予期せぬ大きな脆弱性に繋がる可能性も否定できません。
インシデントを予防し、プロダクトのセキュリティを担保することを目的として、脆弱性診断を実施している会社は多いと思います。
脆弱性診断は、インシデントを防ぎ、プロダクトのセキュリティを維持するために重要ですが、それだけに頼ると、トータルコストの増大や、他のセキュリティ対策の不備につながるおそれがあります。
セキュリティをより強固にするためには、より前段階でのセキュリティ確保が重要になります。
そこで、スパイダープラスでは、開発プロセスの比較的初期段階で行う「脅威分析」を、早期に組み込む取り組みを始めました。
本記事では、その背景や具体的な取り組みについてご紹介します。
なぜ開発の初期に脅威分析が重要なのか?
脅威分析とは、システムなどに対するセキュリティ上の脅威と影響、そしてリスクを把握し、講じるべき適切な対策と優先順位を決定するプロセスです。
脅威分析を行うことで、以下の効果が期待できます。
-
潜在的なリスクの明確化
-
効果的な対策の実施
リスクに基づいて、影響度の大きい脆弱性から優先的に修正を行うなど、優先度をつけて対策を講じることができます。
-
セキュリティ意識の向上
開発者全体が脅威分析を通じてセキュリティの重要性を理解し、よりセキュアなコーディングを心がけることができます。
SPIDERPLUSにおける脅威分析の取り組み
今回の脅威分析は、以下のステップで進めていきました。
-
対象範囲の明確化
まずは、脅威分析の対象範囲を明確にします。スパイダープラスには多くのプロダクトがあり、また、ひとつひとつのプロダクトもかなり複雑なものなので、いきなりすべての脅威分析をすることは現実的ではありません。
そこで、少しずつ、開発の文化として脅威分析を実施できるよう、分析対象のコンポーネントを絞り込むことにし、今回はログイン機能に焦点を当て、ログイン画面まわりを対象としました。
-
コンポーネントの明確化
次に、実際に分析対象のコンポーネントを明確にします。
ログイン画面に対する脅威を具体的に分析するためには、ログイン画面を構成するコンポーネントを分解する必要があります。今回は、開発部門からアーキテクチャに関する情報の共有を受け、大きくフロントエンド・バックエンド・データベース・アセットにコンポーネントを分けることにしました。
-
脅威の洗い出し
フロントエンド、バックエンド、データベース、アセットの各コンポーネントにおいて、どのような脅威が存在するかを洗い出します。
脅威の洗い出しでは、いわゆる「STRIDE」を使うことにしました。・「STRIDE」は、脅威をなりすまし（Spoofing）・改ざん（Tampering）・否認（Repudiation）・情報漏洩（Information Disclosure）・サービス拒否（Denial of Service）・特権昇格（Elevation of Privilege）の各カテゴリに分類する考え方です。
-
リスクの評価
洗い出した脅威ごとに、発生する確率と影響の大きさを評価します。
この段階で、発生する確率が低いもの、影響が軽微で許容できるもの、既に対策済みのものについては評価対象から除外し、残った脅威について詳細なリスク評価を行いました。リスクの評価に基づいて、対策の優先度を決定します。
-
対策の検討
リスクの高い脅威については、具体的な対策を検討します。
対策の検討においては、実現可能性やコストなども考慮します。 -
対策の実施と効果測定
検討した対策を実施し、その効果を測定します。
効果測定の結果に基づいて、対策を改善していくことも重要です。
素早く脅威分析を行うための工夫
一般的に、脅威分析には時間がかかります。
理由はいくつかあります。
まずは脅威分析対象の特定で、網羅性を高めるべく厳密に洗い出そうとすると、時間がかかってしまうことがあります。
また、考えられる限りの脅威を網羅的に洗い出し、個々の脅威の影響の見積もりやリスク評価、対策の立案といったプロセスに時間がかかることがあります。
以上のような、脅威分析における時間がかかる要因を解消して、素早く脅威分析を実施するために、当社では、以下のような工夫をしています。
-
対象範囲を限定する
攻撃者は「穴を突く」ものなので、セキュリティ対策を行う側として、網羅性を担保することは重要でありますが、前述の通り、脅威分析対象の特定や考えられる限りの脅威を網羅的に洗い出すといったことは時間がかかるものです。
また、アジャイル的に開発を進めているSPIDERPLUSにとって、対象範囲を限定した脅威分析は、アジリティの高さという意味で相性がいいともいえます。
-
厳密さにこだわらない
脅威分析に関する書籍やオンラインのドキュメントを見ると、DFD（Data Flow Diagram、システムのデータの流れを視覚的に表現した図）を使うことが一般的ではあります。
しかし、実際には優先順位をつけて対策を立案することがゴールであるならば、脅威分析の手法を厳密に踏襲することによる効果は薄く、「とりあえず脅威分析対象を理解しやすく可視化する」ことを優先しても大きな問題にはならないと判断できます。
-
完成度を高める前に意見を求めにいく
「厳密さにこだわらない」ことにもつながりますが、脅威分析結果の完成度を高める前に積極的に社内に共有して、意見を求めに行くことも有効です。
関係者全員を巻き込むことで共通理解の促進やセキュリティ意識の向上につながったり、初期の段階でフィードバックを得ることで分析の方向性を早期に修正して無駄を省いたり、といったことが期待できます。
-
脅威を洗い出す際にAIを利用する
AIは、必ずしも脅威分析の対象を正確に理解しているわけではありませんが、人間では困難なスピードで脅威を網羅的に洗い出すことができるので、脅威分析の効率を飛躍的に向上させます。
これらの工夫により、脅威分析に対する「特殊な作業」というイメージを払拭し、日々の企画や開発業務、または運用構築の一部として、自然に行われるようにすることを目指しています。
脅威分析をしてみて
脅威分析をすることで開発組織が得るものは、まずは安心感でしょう。
脅威分析を実施することで潜在的なセキュリティリスクを事前に把握し、適切な対策を講じることができます。
また、対策の抜け・漏れを発見することも容易になります。
「未知の脅威に突然襲われるのではないか」という漠然とした不安から解放され、安心してサービス開発に集中できるようになります。
脆弱性診断だけではなく、より上流からセキュリティを考慮する「シフトレフト」に関する開発者の意識を底上げすることにもつながっているといえます。
開発組織の拡大期にある弊社では、このことも見過ごせない効果だといえます。
今後の展望
今回の取り組みはまだ始まったばかりですが、今後はさらに脅威分析の対象範囲を広げ、より高度な分析手法も取り入れていきたいと考えています。
また、脅威分析の結果を開発チーム全体で共有し、フィードバックを反映させる仕組みも構築していく予定です。
おわりに
スパイダープラスでは、脅威分析を通じて、より安全で信頼性の高いプロダクトを提供できるよう、継続的に改善に取り組んでいきます。
本記事が、皆様の開発現場におけるセキュリティ向上の参考になれば幸いです。
最後までお読みいただき、ありがとうございました。
