NISTの新ガイドライン：セキュアなソフトウェア開発にカスタマイズされたトレーニングが不可欠な理由

2019年6月11日、米国国立標準技術研究所（NIST）は、いくつかの行動計画を詳述したホワイトペーパーの改訂版を公開しました。この文書は、ソフトウェアの脆弱性とサイバーリスクを低減するためのものです。『セキュアソフトウェア開発フレームワーク（SSDF）の採用によるソフトウェア脆弱性のリスク軽減』と題されたこの文書で、NISTはデータ侵害による深刻かつ高コストな結果を回避するための確固たるガイドラインを組織に提供しています。

SSDFは意図的に汎用的なものとして設計されており、すべての組織が全く同じソフトウェアセキュリティ目標を持っているとは想定しておらず、目標達成のための具体的なメカニズムを規定するものでもないという点に留意することが重要です。主な目的は、セキュリティのベストプラクティスを実装することにあります。執筆者のドナ・ドッドソン氏は次のように述べています。「各セキュリティプロデューサーが適用可能なすべてのプラクティスに従うことが望ましい一方で、各プラクティスの実装度は、プロデューサーのセキュリティに関する前提条件に基づいて異なることが想定されています。これらのプラクティスは実装者に柔軟性を提供するものですが、同時に、解釈の余地を残しすぎないよう明確に示されています」。

もちろん、私が特に注目したのは、開発者向けのソフトウェアセキュリティトレーニングに関する具体的な記述です。開発者がソフトウェア開発プロセスの初期段階から組織を守るためには、適切なトレーニングが必要であることは以前から知られていました……しかし、何が適切なのか、正確にはどうでしょうか。世の中にはさまざまな意見があります。しかし、私は今、大きな前向きな結果をもたらす方向にようやく舵が切られつつあると考えています。

セキュリティトレーニングには、単なるトレーニングと、効果的なトレーニングの2種類があります。

私はこれまで、ソフトウェアセキュリティトレーニングをより効果的に実施し、開発者のニーズに合わせて取り組む必要性について詳しく語ってきました。現在でも多くの組織において、それはせいぜい「チェックボックスを埋める」程度の作業に過ぎません。数時間のビデオトレーニングや、貴重な時間を割いて行う座学研修がある程度かもしれません。日常的に大規模なデータ侵害が発生し、攻撃者が既知の（通常は簡単に修正できる）脆弱性を悪用しているという事実は、ソフトウェアセキュリティトレーニングが本来あるべき効果を全く発揮できていないことの証左です。そして何より重要なのは、トレーニングが実際に効果的であったかどうかを検証する仕組みがほとんど存在しないことです。脆弱性は以前より早く修正されているか？コード内の脆弱性は減少しているか？人々は実際にトレーニングを完了したのか、それとも単に「次へ」をクリックしただけなのか？

開発者は多忙であり、厳しい納期を守るために懸命に働いています。セキュリティは多くの場合、彼らにとって不便な存在であり、サイバーリスクを適切に軽減するための知識を教育課程で身につけていることは稀です。「セキュリティ」という言葉は、通常、AppSecチームのメンバーが彼らの仕事の欠陥を指摘する際に持ち出されるため、冷ややかで機能不全な関係を生み出しています。いわば「自分の子供が醜いと言われ、修正を強要される」ような状況です。

これは何を意味するのでしょうか？これは、開発者にセキュリティの重要性を理解してもらうための取り組みが不十分であるという、数十年来の警告信号です。彼らは責任を持つ意欲も、機能的かつセキュリティのベストプラクティスを考慮したソフトウェアを作成するために必要なツールを探し求める意欲も持てていません。

開発者は賢く、創造的で、問題を解決することを好みます。セキュリティの脆弱性に関する延々と続くビデオを見ることは、彼らの意欲をかき立てたり、関心を持ち続けさせたりする可能性は極めて低いでしょう。SANSのインストラクターとして、私は最高のトレーニングとは実践的なものであり、現実世界の例を用いて知的な挑戦を強いることで、脳を刺激し、既存の知識を積み上げさせるものだとすぐに学びました。ゲーミフィケーションや友好的な競争も、新しい概念を全員に浸透させるための強力なツールであり、同時に実用的で有用なものとなります。

NISTのガイドラインには次のように明記されています。「セキュアな開発に責任を持つすべての担当者に対し、役割に応じたトレーニングを提供すること。役割に応じたトレーニングを定期的に見直し、必要に応じて更新すること」。また、その後にこう続きます。「サイバーセキュリティスタッフ、セキュリティチャンピオン、上級管理職、ソフトウェア開発者、プロダクトオーナー、およびSDLCに関与するその他の人々の役割と責任を定義すること」。

この記述は、トレーニングの種類を具体的に指定しているわけではありませんが、組織の「シフトレフト」を促進し、セキュリティのベストプラクティスを常に意識させる助けとなります。これは、効果的でより具体的なトレーニングソリューションを見つける責任を企業側に突きつけるものであり、結果として開発者が成功するために必要なツールと知識を備えることにつながるはずです。

文化：欠けているピース。

組織が開発者や主要スタッフのトレーニングに時間とリソースを割き、脆弱性の防止やセキュリティリスクの低減における彼らの役割を強調していたとしても、組織のセキュリティ文化が根本的に崩壊していれば、その努力は無駄になりかねません。

個人が効果的にトレーニングを受け、目標と期待が明確に設定されていれば、セキュリティ環境における自分の立ち位置を理解し、適切な責任を負うことがはるかに容易になります。特に開発者の場合、最初からセキュアなコードを書くためのツールと知識が与えられます。しかし、これは二重作業や責任のなすりつけ合い、サイロ化されたプロジェクト作業が少ない、前向きなセキュリティ環境において最も効果的に機能します。

セキュリティは組織全体で常に意識されるべきであり、優れたセキュアなソフトウェアを提供するための協力的かつ支援的なコミットメントが必要です。そのためには、現実世界のコードの脆弱性を活用した楽しく魅力的なトレーニングを展開するための十分な予算と、勢いを維持するための組織全体の賛同が不可欠です。絶えず進化するデジタル環境において、トレーニングはデリバリーと同様に継続的でなければなりません。「一度きり」や「設定して忘れる」ようなコンプライアンス研修が十分、あるいは効果的であるという考えは誤りです。

この新しいNISTフレームワークは、前向きなセキュリティ文化を育む必要性を具体的に明文化してはいませんが、ガイドラインを成功させるためには、そのような文化が不可欠です。ただし、彼らは「組織のソフトウェアが満たすべきセキュリティ要件を規定するポリシーを定義すること。これには開発者が従うべきセキュアコーディングの実践が含まれる」と指摘しています。

上記はチーム内のセキュリティスキルを拡大・向上させるために不可欠です。独自のポリシーや現在のAppSec環境を評価する際には、以下の点を考慮すると役立つかもしれません。

• ソフトウェアセキュリティのガイドラインと期待値は明確に定義されていますか？
• 達成に向けた各自の役割を全員が理解していますか？
• トレーニングは頻繁に行われ、評価されていますか？
• 開発者は、一般的なセキュリティバグを未然に防ぐために自分たちが果たせる大きな役割を認識していますか？

さて、最後の部分については、前述の通り、組織と彼らが選択するトレーニング次第です。それは関連性があり、頻繁に行われ、魅力的でなければなりません。日々の業務に適用でき、文脈の中で知識を構築できるソリューションを見つけてください。

次に何をすべきか？

これらの新しいガイドラインを深く掘り下げるのは、かなり骨の折れる作業になるでしょう。多くの企業が必要とする堅牢で安全なソフトウェアを、可能な限りセキュアな方法で作成、検証、展開するには、組織全体での取り組みが不可欠です。それは単なるトレーニングの問題ではありません。サードパーティ製ソフトウェアを使用する際のガイドラインも考慮する必要があります（既知の脆弱性を持つコンポーネントの使用は、結局のところ今もなおOWASP Top 10に含まれています）。さらに、検証、ペネトレーションテスト、コードレビューに関する提案や、セキュリティ記録の保持、適切なツールチェーンなど、考慮すべき点は多岐にわたります。全体像を把握するための実践的な知見は、NISTの文書全体で参照されているゲイリー・マグロウ博士のBSIMMモデルで確認できます。

しかし、最も迅速な成果を得る方法は、開発者が最初からセキュアなソフトウェアを構築できるよう、適切なツールと知識を提供することです。SDLCの後半で一般的な脆弱性が繰り返し発生するのを防ぐ方が、ビジネスにとってコスト効率が高く、全体的なスピードも向上します。開発者の強みを活かし、組織のセキュリティ活動に積極的に関与するよう動機付けを行いましょう。セキュリティ対策は本来楽しいものであり、彼らは悪意ある攻撃を阻止し、データを守るための頼もしい存在となるはずです。

参考文献：

1. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (2019年6月11日)、2ページ。
2. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (2019年6月11日)、5ページ。
3. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (2019年6月11日)、4ページ。