2022年3月11日

※For the English version, please refer to here.

今回のブログではNIST SP800-218 Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities（以下、SSDF）[1]を参考に、セキュア開発とはどういう考え方で取り組めばよいのかを考えていきたいと思います。

セキュア開発は、ソフトウェア開発のライフサイクルにおける早い段階でセキュリティ対策を行う方が、様々な面でコストを低減できるというシフトレフト[2]の考え方に基づいて行われることが多いと思います。しかし、実際のセキュア開発の現場では「とりあえずこれをやっておけば大丈夫だろう」のようなその場しのぎな対応になっていることが少なからずあるのではないかと感じています。

そこで、あらためてセキュア開発とはどう取り組むべきものなのかSSDFを参考にしながら考えていきたいと思います。

SSDFとは

SSDFはSecure Software Development Frameworkという名前からわかる通りセキュアなソフトウェアの開発に焦点を当てたフレームワークです。実際には図1、2に示すような形でセキュアなソフトウェアの開発に必要な取り組みをPracticesとしてまとめています。このPracticesはReferencesにあるようなドキュメントを参考にしてまとめられています。さらにPracticesをより具体化したTasks、Notional Implementation Examplesが整理されています。
例えば、Practicesの一つに「ソフトウェア開発のためにセキュリティ要件を定義する」というものがあり、それについてNotional Implementation Examplesで「少なくとも年に一回はセキュリティ要件のレビューと更新を行う」と実施例が書かれています。
このように、セキュア開発を実践する人はSSDFのPracticesやそれを掘り下げたTasks、Notional Implementation Examplesを参考にして自身のセキュアなソフトウェアの開発の要件を検討・作成できます。

セキュア開発の考え方の前提

筆者がSSDFを読み解く中で、セキュア開発のあるべき考え方を検討するためのポイントと感じた部分を引用します。

リスクベースアプローチとは、リスクに基づいてセキュリティ対策のアプローチを決めることです。これは図3に示すようなリスクの発生可能性と発生の際の損害の大きさの二軸で対応方法を決めることを指しています。あるソフトウェア開発のプロジェクトについて、図3に示すリスクの対応方法が決まれば、そのプロジェクトにおけるセキュアなソフトウェア開発手法が決定されるということと考えます。このようにセキュア開発の考え方の前提にはリスクベースアプローチがあると考えています。

次に、チェックリストの作成の助けがSSDFの目的ではないことをどう解釈するかについて考えます。仮に組織がSSDFを参考にして最低限取り組むべきセキュリティ対策（ベースライン）という形でチェックリストを作成したとします。この場合、それはリスクベースアプローチの計画と実行の結果と言えるのではないかと思いました。したがって、上述した引用文の内容は矛盾しているのではないかと当初考えました。しかし、微妙な違いではありますが、SSDFの目的はあくまでもセキュアなソフトウェアの開発を行うためのリスクベースアプローチの基礎になることにあります。その下でセキュア開発の取り組みの過程としてチェックリストを作成することはあるかもしれませんが、それ自体は必須ではないし目的でもないということを示しているのではないかと思いました。つまり、手段と目的をはき違えないでほしいという注意・主張と、リスクベースアプローチという前提の重要性をこの一文は伝えているのではないかという考えに思い至りました。

セキュア開発の取り組み方

ここで、このリスクベースアプローチという前提の下でどのようにセキュア開発に取り組むべきかを考えていきたいと思います。開発プロジェクトが発生する都度、思想やベースラインが何もない状態からリスクベースアプローチに実務者が取り組むことは、現実的に難しいです。そのため実際には、組織がベースラインとなるセキュア開発の考え方や方針・ルールといったツールを用意することが多いでしょう。そして、現場の実務者は、開発プロジェクトに必要なセキュア開発のアプローチをリスクに基づいて決めて進めていくことになると思います。例えば、上記のようなツールは社内のセキュリティ部門が作成します。そして、実務者は開発プロジェクトの特性（リスク）に従ってセキュリティ対策を調整・最適化するというイメージです。

ベースラインは、SSDFのようなフレームワークにあるセキュリティ要件から自組織にとって必要な部分を切り取り（スコーピング）、それを組織の環境に合わせて内容を調整（テーラリング）することで作成できます。ただし、ベースラインは汎用性を高めてある程度どの開発プロジェクトにも適用可能な状態にすることが望ましいため、記載内容の抽象度が高くなる場合があります。これを開発プロジェクトの特性に合わせて具体的な要件に落とし込み、実行するのが実務者の役目であるといえます。

まとめ

SSDFを参考として示した通り、セキュアなソフトウェア開発とは、開発プロジェクトについてのリスクを洗い出し、アプローチを決定し、その決定を履行することが基本的な考え方と思います。しかし、開発プロジェクトの現場において、セキュア開発は得てしてセキュリティ対策自体（手段）の検討や実行が先行しがちになり、本来のセキュア開発の目的である適切なリスク対応の決定と履行がおざなりになる場面が少なくないのではないかと感じています。

セキュア開発に取り組む際、リスクを洗い出し、リスクへの対応方法を決定するというプロセスを経ることなしになんらかのセキュリティ対策（手段）を実行するという取り組み方は、本ブログの冒頭で述べた“その場しのぎな対応”であり、リスクベースアプローチの考え方としては適切とは言えません。しかし、現実にはそのようなケースもあると思います。その背景には様々な理由が考えられますが、本ブログで示したような本来あるべき考え方の理解が広まっていないことも一因としてあるのではないかと感じています。

本ブログでは、SSDFを参考にしてセキュア開発への取り組みの考え方を示しました。リスクベースアプローチやベースライン、スコーピング・テーラリングなどは、セキュア開発に限らずセキュリティが関わるあらゆる場面に適用できるものです。このブログを通じて今回示したようなセキュリティの考え方への関心が増えることにつながれば嬉しく思います。

本ブログが少しでもみなさんの役に立ち、安全・安心な社会に少しでも寄与することを願っています。

参考文献

執筆者の他の記事を読む