NISTの新ガイドライン。安全なソフトウェアを作るためにカスタマイズされたトレーニングが必要な理由

2019年12月02日掲載
ピーテル・ダンヒョウ著
ケーススタディ

NISTの新ガイドライン。安全なソフトウェアを作るためにカスタマイズされたトレーニングが必要な理由

2019年12月02日掲載
ピーテル・ダンヒョウ著
リソースを見る
リソースを見る

2019年6月11日、米国国立標準技術研究所(NIST)は最新のホワイトペーパーを発表し、ソフトウェアの脆弱性とサイバーリスクを低減するためのいくつかのアクションプランを詳細に説明しました。NISTは、「Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)」と題し、データ侵害による厄介な--言うまでもなく高価な--結果を回避するための確かなガイドラインを組織に提供しています。

SSDF は意図的に一般的なものとしており、すべての組織がまったく同じソフトウェア・セキュリティ目標を持っているとは想定しておらず、目標達成のための正確なメカニズムを規定していないことに留意する必要がある。主な目的は、セキュリティのベスト・プラクティスを実施することです。執筆者である Donna Dodson は次のように述べている。「各セキュリティ製作者は、適用可能なすべての実施事項に従うことを望んでいるが、各実施事項をどの程度実施するかは、製作者のセキュリティに関する仮定に基づいて異なることを期待している。このプラクティスは、実装者に柔軟性を提供していますが、解釈の余地が大きくなりすぎないように明確になっています」。

私が特に興味を持ったのは、開発者向けのソフトウェア・セキュリティ・トレーニングに関する具体的な項目でした。ソフトウェア開発プロセスの初期段階から組織を守るためには、開発者に適切なトレーニングが必要であることは以前から知られていましたが、そもそも適切とは何でしょうか。世の中には様々な意見があります。しかし、私は、この問題がようやく大きな成果を生む方向に向かっていると考えています。

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

私はこれまで、ソフトウェア・セキュリティ・トレーニングをより効果的に実施し、開発者のニーズに合わせて実施する必要があることを訴えてきました。現在でも、多くの組織では、せいぜい「チェックボックスにチェックを入れる」程度のトレーニングしか行われていません。おそらく、数時間のビデオトレーニングや、ツールを使わずに教室で学習する貴重な時間もあるでしょう。よく知られた(そしてたいていは簡単に修正できる)脆弱性を悪用した攻撃者による大規模なデータ漏洩が毎日のように発生しているという事実は、ソフトウェア・セキュリティ・トレーニングが必要とされるほど効果的ではないことを証明しています。そして、おそらく最も重要なことは、トレーニングが効果的であったかどうかを検証する仕組みがほとんどないということです。例えば、脆弱性の修正が早くなったのか、脆弱性のコードが減ったのか。脆弱性の修正が早くなったのか、脆弱性のコードが減ったのか、実際にトレーニングを完了したのか、それとも「次へ」をクリックして完了したのか。

開発者は、厳しい納期の中で懸命に仕事をしている忙しい人たちです。多くの場合、セキュリティは不便なものであり、サイバーリスクをうまく軽減するための知識を教育の中で身につけることはほとんどありません。セキュリティ」という言葉が出てくるのは、たいていAppSecチームのメンバーが自分たちの仕事の欠陥を指摘するときで、どちらかというと冷たくて機能しない関係になっています。あなたの赤ちゃんは醜いから直しなさい」というシナリオですね。

これは何を意味するのでしょうか?

開発者は、賢く、創造的で、問題を解決するのが好きです。セキュリティの脆弱性に関するビデオを延々と見ても、彼らが興奮したり、興味を持ち続けたりすることはまずないでしょう。SANSのインストラクターとしての経験から、最高のトレーニングは実践的なものであり、脳をテストし、事前の学習を基にした実例を用いて、分析し、知的な挑戦をさせるものであることをすぐに学びました。また、ゲーミフィケーションや切磋琢磨は、新しいコンセプトを皆に理解してもらうための強力なツールであると同時に、有用で実用的なアプリケーションでもあります。

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

この発言は、トレーニングの種類を特定するものではありませんが、組織を左遷し、セキュリティのベストプラクティスを最重要視することに貢献しています。これにより、効果的でより具体的なトレーニングソリューションを見つける責任が企業に戻り、その結果、開発者が成功するための適切なツールと知識を身につけることが期待されます。

文化:ミッシングリンク

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

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

優れた安全なソフトウェアを提供するためには、組織全体でセキュリティを最優先に考え、協力的に取り組んでいかなければなりません。そのためには、実際のコードの脆弱性を利用した楽しく魅力的なトレーニングを展開するための十分な予算が必要であり、その勢いを維持するために組織全体の賛同を得る必要があります。常に進化し続けるデジタル社会では、トレーニングもデリバリーと同様に継続的でなければなりません。これまで、「1回限りのトレーニング」や「設定したら終わり」のコンプライアンストレーニングが適切で効果的であると言われてきましたが、それは間違いです。

この新しいNISTのフレームワークでは、積極的なセキュリティ文化を育むための要件は特に明示されていませんが、ガイドラインをうまく順守するためには、確実にセキュリティ文化が必要になります。ただし、「開発者が従うべき安全なコーディング方法を含め、組織のソフトウェアが満たすべきセキュリティ要件を規定したポリシーを定義する」べきであるとしています。

以上のことは、チーム内のセキュリティスキルを向上させるために不可欠であり、自社のポリシーや現在のAppSecの状況を評価する際には、以下のことを考慮するとよいでしょう。

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

さて、最後の部分は、先に述べたように、組織とその選択するトレーニングに大きく依存しています。関連性があり、頻度が高く、魅力的なものでなければなりません。日々の仕事に応用できるソリューションを見つけ、文脈に沿って知識を身につけていく。

どうする?

ほとんどの企業が必要としている鉄壁のセキュリティを備えたソフトウェアを、可能な限り安全な方法で作成、検証、導入するには、本当に多くの人が必要なのです。また、トレーニングだけではありません。サードパーティ製ソフトウェアを使用する際に考慮すべきガイドライン(既知の脆弱性を持つコンポーネントを使用することは、OWASPのトップ10に依然として入っています)、検証、侵入テスト、コードレビューに関する提案、さらにはセキュリティの記録管理や適切なツールチェーンなどのガイドラインがあります。全体像を把握するための実用的な洞察は、NISTの文書の中で参照されているGary McGraw博士のBSIMMモデルにあります。

しかし、開発者に正しいツールと知識を与え、最初から安全なソフトウェアを構築することに成功すれば、最も早い勝利を得ることができます。一般的な脆弱性がSDLCの後の段階で何度も出てくるのを防ぐことは、ビジネスにとってより安く(そして全体的に早く)なります。彼らの強みを活かして、組織のセキュリティ面に関与するインセンティブを提供しましょう。彼らは、悪者を排除し、私たちのデータを安全に保つために必要なヒーローになることができるのです。

リファレンス

  1. SSDFを採用することでソフトウェア脆弱性のリスクを軽減する(2019年6月11日),ページ 2.
  2. SSDFを採用することでソフトウェア脆弱性のリスクを軽減する(2019年6月11日)」、5ページ
  3. SSDFを採用することでソフトウェア脆弱性のリスクを軽減する(2019年6月11日)」、4ページ
リソースを見る
リソースを見る

著者

ピーテル・ダンヒユー

Pieter Danhieuxは、セキュリティコンサルタントとして12年以上の経験を持ち、SANSの主席講師として8年間、組織、システム、個人をターゲットにしてセキュリティの弱点を評価する方法に関する攻撃的なテクニックを教えている、世界的に有名なセキュリティエキスパートです。2016年には、オーストラリアで最もクールな技術者の一人として認められ(Business Insider)、Cyber Security Professional of the Yearを受賞(AISA - Australian Information Security Association)、GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA認定を保有している。

もっと知りたい?

セキュアコーディングに関する最新の知見をブログでご紹介しています。

当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。

ブログを見る
もっと知りたい?

開発者主導のセキュリティに関する最新の研究成果を入手する

ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。

リソース・ハブ

NISTの新ガイドライン。安全なソフトウェアを作るためにカスタマイズされたトレーニングが必要な理由

2019年12月02日掲載
Pieter Danhieux著

2019年6月11日、米国国立標準技術研究所(NIST)は最新のホワイトペーパーを発表し、ソフトウェアの脆弱性とサイバーリスクを低減するためのいくつかのアクションプランを詳細に説明しました。NISTは、「Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)」と題し、データ侵害による厄介な--言うまでもなく高価な--結果を回避するための確かなガイドラインを組織に提供しています。

SSDF は意図的に一般的なものとしており、すべての組織がまったく同じソフトウェア・セキュリティ目標を持っているとは想定しておらず、目標達成のための正確なメカニズムを規定していないことに留意する必要がある。主な目的は、セキュリティのベスト・プラクティスを実施することです。執筆者である Donna Dodson は次のように述べている。「各セキュリティ製作者は、適用可能なすべての実施事項に従うことを望んでいるが、各実施事項をどの程度実施するかは、製作者のセキュリティに関する仮定に基づいて異なることを期待している。このプラクティスは、実装者に柔軟性を提供していますが、解釈の余地が大きくなりすぎないように明確になっています」。

私が特に興味を持ったのは、開発者向けのソフトウェア・セキュリティ・トレーニングに関する具体的な項目でした。ソフトウェア開発プロセスの初期段階から組織を守るためには、開発者に適切なトレーニングが必要であることは以前から知られていましたが、そもそも適切とは何でしょうか。世の中には様々な意見があります。しかし、私は、この問題がようやく大きな成果を生む方向に向かっていると考えています。

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

私はこれまで、ソフトウェア・セキュリティ・トレーニングをより効果的に実施し、開発者のニーズに合わせて実施する必要があることを訴えてきました。現在でも、多くの組織では、せいぜい「チェックボックスにチェックを入れる」程度のトレーニングしか行われていません。おそらく、数時間のビデオトレーニングや、ツールを使わずに教室で学習する貴重な時間もあるでしょう。よく知られた(そしてたいていは簡単に修正できる)脆弱性を悪用した攻撃者による大規模なデータ漏洩が毎日のように発生しているという事実は、ソフトウェア・セキュリティ・トレーニングが必要とされるほど効果的ではないことを証明しています。そして、おそらく最も重要なことは、トレーニングが効果的であったかどうかを検証する仕組みがほとんどないということです。例えば、脆弱性の修正が早くなったのか、脆弱性のコードが減ったのか。脆弱性の修正が早くなったのか、脆弱性のコードが減ったのか、実際にトレーニングを完了したのか、それとも「次へ」をクリックして完了したのか。

開発者は、厳しい納期の中で懸命に仕事をしている忙しい人たちです。多くの場合、セキュリティは不便なものであり、サイバーリスクをうまく軽減するための知識を教育の中で身につけることはほとんどありません。セキュリティ」という言葉が出てくるのは、たいていAppSecチームのメンバーが自分たちの仕事の欠陥を指摘するときで、どちらかというと冷たくて機能しない関係になっています。あなたの赤ちゃんは醜いから直しなさい」というシナリオですね。

これは何を意味するのでしょうか?

開発者は、賢く、創造的で、問題を解決するのが好きです。セキュリティの脆弱性に関するビデオを延々と見ても、彼らが興奮したり、興味を持ち続けたりすることはまずないでしょう。SANSのインストラクターとしての経験から、最高のトレーニングは実践的なものであり、脳をテストし、事前の学習を基にした実例を用いて、分析し、知的な挑戦をさせるものであることをすぐに学びました。また、ゲーミフィケーションや切磋琢磨は、新しいコンセプトを皆に理解してもらうための強力なツールであると同時に、有用で実用的なアプリケーションでもあります。

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

この発言は、トレーニングの種類を特定するものではありませんが、組織を左遷し、セキュリティのベストプラクティスを最重要視することに貢献しています。これにより、効果的でより具体的なトレーニングソリューションを見つける責任が企業に戻り、その結果、開発者が成功するための適切なツールと知識を身につけることが期待されます。

文化:ミッシングリンク

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

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

優れた安全なソフトウェアを提供するためには、組織全体でセキュリティを最優先に考え、協力的に取り組んでいかなければなりません。そのためには、実際のコードの脆弱性を利用した楽しく魅力的なトレーニングを展開するための十分な予算が必要であり、その勢いを維持するために組織全体の賛同を得る必要があります。常に進化し続けるデジタル社会では、トレーニングもデリバリーと同様に継続的でなければなりません。これまで、「1回限りのトレーニング」や「設定したら終わり」のコンプライアンストレーニングが適切で効果的であると言われてきましたが、それは間違いです。

この新しいNISTのフレームワークでは、積極的なセキュリティ文化を育むための要件は特に明示されていませんが、ガイドラインをうまく順守するためには、確実にセキュリティ文化が必要になります。ただし、「開発者が従うべき安全なコーディング方法を含め、組織のソフトウェアが満たすべきセキュリティ要件を規定したポリシーを定義する」べきであるとしています。

以上のことは、チーム内のセキュリティスキルを向上させるために不可欠であり、自社のポリシーや現在のAppSecの状況を評価する際には、以下のことを考慮するとよいでしょう。

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

さて、最後の部分は、先に述べたように、組織とその選択するトレーニングに大きく依存しています。関連性があり、頻度が高く、魅力的なものでなければなりません。日々の仕事に応用できるソリューションを見つけ、文脈に沿って知識を身につけていく。

どうする?

ほとんどの企業が必要としている鉄壁のセキュリティを備えたソフトウェアを、可能な限り安全な方法で作成、検証、導入するには、本当に多くの人が必要なのです。また、トレーニングだけではありません。サードパーティ製ソフトウェアを使用する際に考慮すべきガイドライン(既知の脆弱性を持つコンポーネントを使用することは、OWASPのトップ10に依然として入っています)、検証、侵入テスト、コードレビューに関する提案、さらにはセキュリティの記録管理や適切なツールチェーンなどのガイドラインがあります。全体像を把握するための実用的な洞察は、NISTの文書の中で参照されているGary McGraw博士のBSIMMモデルにあります。

しかし、開発者に正しいツールと知識を与え、最初から安全なソフトウェアを構築することに成功すれば、最も早い勝利を得ることができます。一般的な脆弱性がSDLCの後の段階で何度も出てくるのを防ぐことは、ビジネスにとってより安く(そして全体的に早く)なります。彼らの強みを活かして、組織のセキュリティ面に関与するインセンティブを提供しましょう。彼らは、悪者を排除し、私たちのデータを安全に保つために必要なヒーローになることができるのです。

リファレンス

  1. SSDFを採用することでソフトウェア脆弱性のリスクを軽減する(2019年6月11日),ページ 2.
  2. SSDFを採用することでソフトウェア脆弱性のリスクを軽減する(2019年6月11日)」、5ページ
  3. SSDFを採用することでソフトウェア脆弱性のリスクを軽減する(2019年6月11日)」、4ページ

弊社製品や関連するセキュアコーディングのトピックに関する情報をお送りする許可をお願いします。当社は、お客様の個人情報を細心の注意を払って取り扱い、マーケティング目的で他社に販売することは決してありません。

送信
フォームを送信するには、「Analytics」のCookieを有効にしてください。完了したら、再度無効にしてください。