新しいNISTガイドライン:安全なソフトウェアを作成するためにカスタマイズされたトレーニングが不可欠な理由

2019年6月11日、米国国立標準技術研究所（ニスト）は、詳細を説明した最新のホワイトペーパーをリリースしました いくつかの行動計画 削減用 ソフトウェアの脆弱性 そしてサイバーリスク。タイトル セキュアソフトウェア開発フレームワーク (SSDF) の採用によるソフトウェア脆弱性のリスクの軽減、NISTは、データ侵害による厄介な（費用のかかることは言うまでもありません）の結果を回避するための確固たるガイドラインを組織に提供しています。

SSDFは意図的に汎用的なものであり、すべての組織がまったく同じソフトウェア・セキュリティ目標を持っていることを前提としているわけではなく、またそれを達成するための正確なメカニズムを規定しているわけでもないことに注意することが重要です。主な目的は、セキュリティのベストプラクティスを実装することです。ライターのDonna Dodson氏は次のように述べています。「各セキュリティプロデューサーが適用可能なすべてのプラクティスに従うことが望まれていますが、各プラクティスの実装の程度は、プロデューサーのセキュリティ前提によって異なることが予想されます。これらのプラクティスは実装者にとって柔軟性を提供しますが、解釈の余地があまり大きくなりすぎないようにすることも明確です。」

もちろん、私が特に興味を持ったのは、開発者向けのソフトウェア・セキュリティ・トレーニングに関する具体的な内容でした。開発者がソフトウェア開発プロセスの初期段階から組織を守るためには、十分なトレーニングが必要であることは以前からわかっていました... しかし、何がそうなのでしょうか？ 十分な、正確に?世の中にはさまざまな意見があります。しかし、ようやく大きなポジティブな結果につながる方向に限界が押し広げられていると思います。

セキュリティトレーニングと効果的なセキュリティトレーニングがあります。

これまで、ソフトウェア・セキュリティ・トレーニングをより効果的に実施し、開発者のニーズに応え、それに合わせて調整する必要性について長々と話してきました。今でも、多くの組織では、せいぜい「チェックする」だけの練習に過ぎません。おそらく、数時間のビデオトレーニングがあるかもしれませんし、授業ベースの学習のためにツールを使わない貴重な時間を費やすことさえあるかもしれません。よく知られている (通常は簡単に修正できる) 脆弱性を悪用する攻撃者による大規模なデータ侵害が 1 日おきに発生しているという事実は、ソフトウェアセキュリティトレーニングが必要以上に効果的ではないことの証拠です。そして、おそらく最も重要なのは、トレーニングがまったく効果があったかどうかを検証するための準備がほとんど整っていないことです。脆弱性はより早く修正されたのでしょうか。コードの脆弱性は減少しているのか？受講者は実際にトレーニングを完了したのか、それとも「次へ」をクリックして修了しただけなのか。

開発者は忙しい人で、厳しい締め切りに間に合うように一生懸命働いています。セキュリティはたいてい不便であり、サイバーリスクをうまく軽減するための知識を教育中に身につけていることはほとんどありません。通常、「セキュリティ」という言葉は、AppSecチームのメンバーが自分の仕事の欠点を指摘しているときに出てきます。その結果、かなり冷淡で機能不全な関係になってしまいます。「あなたの赤ちゃんは醜いです。直してください」というシナリオ。

これは何を教えてくれますか？これは数十年前の危険信号です。開発者がセキュリティに関して十分な努力をしていないということです。開発者は責任を取る意欲がなく、機能的でありながらセキュリティのベストプラクティスを念頭に置いて作られたソフトウェアを作成するために必要なツールを探す意欲もありません。

開発者は賢く、創造的で、問題を解決するのが大好きです。セキュリティの脆弱性に関する動画を延々と視聴しても、開発者がワクワクしたり、エンゲージメントを維持したりできるとは考えにくいです。私がSANSのインストラクターを務めていたとき、最高のトレーニングは実践的なものであることがすぐにわかりました。そのため、生徒は脳をテストし、事前の学習に基づいて構築する実際の例を使用して、分析し、知的に挑戦することを余儀なくされました。ゲーミフィケーションと友好的な競争は、誰もが新しい概念を理解できるようにすると同時に、応用において有用で実用的なものであり続けるための強力なツールでもあります。

NISTのガイドラインには、次のように明記されています。「安全な開発に貢献する責任を負う役割を担うすべての職員に、役割別のトレーニングを提供する。職務別の研修を定期的に見直し、必要に応じて更新する。そして後で、「サイバーセキュリティスタッフ、セキュリティチャンピオン、上級管理職、ソフトウェア開発者、製品所有者、その他SDLCに関わる人たちの役割と責任を定義する」

この声明は、トレーニングの種類については具体的に述べていませんが、依然として組織を左派にシフトさせ、セキュリティのベストプラクティスを常に念頭に置いておくのに役立ちます。これは、効果的でより具体的なトレーニングソリューションを見つけることに責任を会社に負わせることであり、その結果、開発者が成功するための適切なツールと知識を身に付けることにつながることが期待されます。

文化:ミッシングリンク.

組織が開発者やその他の主要スタッフのトレーニングに時間とリソースを費やし、脆弱性の防止とセキュリティリスクの軽減における彼らの役割に重点を置いていても、組織のセキュリティ文化が根本的に壊れたままであれば、その努力が無駄になることがよくあります。

個人が効果的にトレーニングされ、目標が設定され、期待が明確になれば、セキュリティ環境における自分の位置を理解し、必要に応じて責任を取ることがはるかに容易になります。特に開発者の場合は、最初から安全なコードを書くためのツールと知識が与えられます。ただし、これは、二重処理や責任追求、サイロ化されたプロジェクト作業が少ない、ポジティブなセキュリティ環境で調整するのが最適です。

セキュリティは組織全体の最優先事項であり、優れた安全なソフトウェアを提供するための支援と協力的な取り組みが必要です。つまり、現実世界のコードの脆弱性を利用した楽しく魅力的なトレーニングを展開するのに十分な予算を確保し、勢いを維持するために組織全体で賛同を得られるようになるということです。この絶え間なく進化するデジタル環境では、トレーニングは提供と同じくらい継続的でなければなりません。過去に、「1回限りの」または「設定したら忘れる」コンプライアンストレーニングが適切または効果的であると言われたことがありますが、これは誤りです。

この新しいNISTの枠組みには、ポジティブな安全保障文化を育むための要件が具体的に明記されているわけではありませんが、そのガイドラインをうまく遵守するには、間違いなくそれが必要です。ただし、組織は「開発者が従うべき安全なコーディング手法を含め、組織のソフトウェアが満たすべきセキュリティ要件を明記したポリシーを定義する」べきだと述べています。

上記は、チーム内のセキュリティスキルを強化し磨くために不可欠です。自社のポリシーと現在のアプリケーションセキュリティ環境を評価する際には、次の点を考慮すると役立つ場合があります。

• ソフトウェア・セキュリティのガイドラインと期待事項は明確に定義されていますか?
• 目標を達成するために自分が果たす役割について、全員が明確に理解できているか?
• トレーニングは頻繁に行われ、評価されていますか？
• 開発者は、一般的なセキュリティバグを発生前に排除するうえで、自分たちが果たせる大きな役割を認識していますか？

さて、最後の部分は、すでに述べたように、主に組織と彼らが選択するトレーニング次第です。関連性があり、頻繁に実施し、参加してもらえるものでなければなりません。日常業務に適用できるソリューションを見つけ、状況に応じて知識を深めましょう。

これからどうする？

これらの新しいガイドラインを深く掘り下げてみると、かなり圧倒されるでしょう。ほとんどの企業が必要とする強固で安全なソフトウェアを、可能な限り最も安全な方法で作成、検証、展開するには、本当に多くの人手が必要です。トレーニングだけの問題ではありません。サードパーティ製ソフトウェアを使用する際に考慮すべきガイドラインがあります (既知の脆弱性を持つコンポーネントの使用 まだ座っている OWASP トップ10結局のところ）、検証、ペネトレーションテスト、コードレビューに関する提案、セキュリティ記録管理に関するガイドライン、適切なツールチェーンなど。全体像を把握するための実用的な洞察は、Gary McGraw博士の論文にあります。 BSIMM モデルこれはNISTのドキュメント全体で参照されています。

ただし、開発者が適切なツールと知識を得て、最初から安全なソフトウェアの構築に真に成功できれば、最速で成果を上げることができます。SDLC の後の段階でよくある脆弱性が何度も出現するのを防ぐ方が、ビジネスにとってはより安価です (そして全体的に迅速です)。その強みを活かし、組織のセキュリティ面に関わるインセンティブを提供しましょう。本当に楽しいことですし、彼らは悪者を排除し、私たちのデータを安全に保つために必要なジャストインタイムのヒーローになることができます。

参考文献:

1. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 2。
2. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 5。
3. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 4。