Coders Conquer Security:シェア＆ラーンシリーズ - 情報公開
"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。
ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。
この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。
情報露出の把握
情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。
多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。
機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。
一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。
情報漏洩の危険性を理解する
アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。
攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。
OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。
情報露出をなくす
情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。
アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。
ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。
ウェブアプリを沈めないために
第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。
同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。
アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。
今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。
ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。
この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。
情報露出の把握
情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。
多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。
機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。
一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。
情報漏洩の危険性を理解する
アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。
攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。
OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。
情報露出をなくす
情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。
アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。
ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。
ウェブアプリを沈めないために
第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。
同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。
アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。
今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]
"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。
ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。
この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。
情報露出の把握
情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。
多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。
機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。
一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。
情報漏洩の危険性を理解する
アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。
攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。
OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。
情報露出をなくす
情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。
アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。
ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。
ウェブアプリを沈めないために
第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。
同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。
アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。
今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。
ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。
この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。
情報露出の把握
情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。
多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。
機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。
一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。
情報漏洩の危険性を理解する
アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。
攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。
OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。
情報露出をなくす
情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。
アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。
ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。
ウェブアプリを沈めないために
第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。
同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。
アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。
今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
