Coders Conquer Security OWASP Top 10 API Series - Disabled Security Features/Debug Features Enabled/Improper Permissions
このリストのほとんどの脆弱性は、APIにかなり特化したものですが、セキュリティ機能の無効化／デバッグ機能の有効化／不適切なパーミッションの問題は、どこでも起こりうる問題です。APIではやや多いと思われますが、攻撃者は、パッチが適用されていない欠陥や保護されていないファイルやディレクトリをネットワーク上のどこかで見つけようとすることがよくあります。デバッグが有効になっていたり、セキュリティ機能が無効になっていたりするAPIに出くわすと、彼らの悪事が少しだけ楽になります。さらに悪いことに、セキュリティの設定ミスを検出して悪用するための自動化されたツールが用意されているため、あなたの環境にそれらがあれば、悪用される可能性が高く、それがこの脆弱性がOWASPの危険なAPI欠陥リストに入った理由です。
お楽しみの前に、このデバッグの課題を解決できるかどうか見てみましょう。
セキュリティ機能の無効化/デバッグ機能の有効化/不適切なパーミッションの欠陥は、どのようにしてAPIに忍び込むのでしょうか？
この多次元的なAPIの欠陥がどのようにしてネットワークに追加されていくのかを知るためには、その構成要素に分解する必要があります。まず、デバッグ機能の有効化の問題から始めましょう。デバッグは、アプリケーションが正しく動作しなかったり、エラーが発生したりする原因を開発者が把握するのに役立つ便利なツールです。デバッグ機能を有効にすると、エラーや例外発生時に詳細なエラーページが生成されるため、開発者は何が悪かったのかを確認し、問題を修正することができます。アプリケーションがまだ開発中の場合は、この機能を有効にしても問題ありません。
しかし、ほとんどのフレームワークでは、本番環境でのデバッグモードの実行に関する警告が表示されるのには理由があり、おそらくデバッグを有効にするコードの中に表示されています。例えば、以下のようなものです。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください
DEBUG = True
この例では、デバッグを有効にしています。Django アプリケーションは、例外が発生すると詳細なエラーページを生成します。これが本番環境で行われた場合、敵対者はこのエラーページにアクセスすることができ、その中には環境に関するメタデータ情報が含まれています。ほとんどのフレームワークでは、デフォルトでデバッグ機能がオフになっていますが、長い開発期間中に有効になっていると、元に戻すのを忘れてしまいがちです。その後、アプリケーションが本番環境に移行すると、アプリケーション、あるいはサーバやネットワーク全体を危険にさらす方法について、攻撃者に多くの情報を提供してしまいます。
デバッグモードを有効にすることは、ほとんどが単独の問題ですが、不適切なパーミッションと無効なセキュリティ機能の脆弱性は、しばしば連動します。例えば、OWASP が提供している実際のシナリオでは、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されているデータベースを見つけました。人気のあるデータベース管理システムは、デフォルトの設定を使用していたため、認証が無効になっていました。このように、不適切なパーミッションと無効化されたセキュリティ機能の脆弱性を組み合わせることで、攻撃者はPII、個人の好み、認証データを含む数百万件の記録にアクセスすることができました。
無効化されたセキュリティ機能/デバッグ機能の有効化/不適切なパーミッションの脆弱性の解消
この脆弱性を排除するためには、おそらく2つのアプローチが必要です。問題のうち、デバッグが有効になっている部分を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するためのチェック機能を開発プロセスに追加するだけです。今回の例から、そのための適切なコマンドは次のようになります。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください。
DEBUG = False
現在、Django アプリケーションのデバッグ機能は、DEBUG フラグを False に設定すると無効になります。エラーに対応したエラーページは生成されません。もし敵がエラーページにアクセスできたとしても、有用なメタデータは含まれておらず、アプリケーションにリスクをもたらすことはありません。
無効化されたセキュリティ機能や不適切なパーミッションの脆弱性を排除することは、広範囲の特定の脆弱性を包含することができるため、少し困難です。これらを阻止する最善の方法は、ロックダウンされた資産を本番環境に迅速かつ容易に展開できるよう、標準的で反復可能なプロセスを開発することです。
その場合でも、オーケストレーション・ファイル、APIコンポーネント、Amazon S3バケットのパーミッションのようなクラウド・サービスが常にレビューされ、更新されるプロセスを作成する必要があります。このレビューでは、組織が常にAPIセキュリティを改善していることを確認するために、環境全体のセキュリティ設定の全体的な有効性を長期的に評価する必要があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
APIの場合はもう少し多いと思いますが、攻撃者はネットワーク上のあらゆる場所で、パッチが適用されていない欠陥や保護されていないファイルやディレクトリを見つけようとします。デバッグが有効になっていたり、セキュリティ機能が無効になっているAPIに出くわすと、彼らの悪事が少しだけ楽になります。
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
このリストのほとんどの脆弱性は、APIにかなり特化したものですが、セキュリティ機能の無効化／デバッグ機能の有効化／不適切なパーミッションの問題は、どこでも起こりうる問題です。APIではやや多いと思われますが、攻撃者は、パッチが適用されていない欠陥や保護されていないファイルやディレクトリをネットワーク上のどこかで見つけようとすることがよくあります。デバッグが有効になっていたり、セキュリティ機能が無効になっていたりするAPIに出くわすと、彼らの悪事が少しだけ楽になります。さらに悪いことに、セキュリティの設定ミスを検出して悪用するための自動化されたツールが用意されているため、あなたの環境にそれらがあれば、悪用される可能性が高く、それがこの脆弱性がOWASPの危険なAPI欠陥リストに入った理由です。
お楽しみの前に、このデバッグの課題を解決できるかどうか見てみましょう。
セキュリティ機能の無効化/デバッグ機能の有効化/不適切なパーミッションの欠陥は、どのようにしてAPIに忍び込むのでしょうか？
この多次元的なAPIの欠陥がどのようにしてネットワークに追加されていくのかを知るためには、その構成要素に分解する必要があります。まず、デバッグ機能の有効化の問題から始めましょう。デバッグは、アプリケーションが正しく動作しなかったり、エラーが発生したりする原因を開発者が把握するのに役立つ便利なツールです。デバッグ機能を有効にすると、エラーや例外発生時に詳細なエラーページが生成されるため、開発者は何が悪かったのかを確認し、問題を修正することができます。アプリケーションがまだ開発中の場合は、この機能を有効にしても問題ありません。
しかし、ほとんどのフレームワークでは、本番環境でのデバッグモードの実行に関する警告が表示されるのには理由があり、おそらくデバッグを有効にするコードの中に表示されています。例えば、以下のようなものです。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください
DEBUG = True
この例では、デバッグを有効にしています。Django アプリケーションは、例外が発生すると詳細なエラーページを生成します。これが本番環境で行われた場合、敵対者はこのエラーページにアクセスすることができ、その中には環境に関するメタデータ情報が含まれています。ほとんどのフレームワークでは、デフォルトでデバッグ機能がオフになっていますが、長い開発期間中に有効になっていると、元に戻すのを忘れてしまいがちです。その後、アプリケーションが本番環境に移行すると、アプリケーション、あるいはサーバやネットワーク全体を危険にさらす方法について、攻撃者に多くの情報を提供してしまいます。
デバッグモードを有効にすることは、ほとんどが単独の問題ですが、不適切なパーミッションと無効なセキュリティ機能の脆弱性は、しばしば連動します。例えば、OWASP が提供している実際のシナリオでは、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されているデータベースを見つけました。人気のあるデータベース管理システムは、デフォルトの設定を使用していたため、認証が無効になっていました。このように、不適切なパーミッションと無効化されたセキュリティ機能の脆弱性を組み合わせることで、攻撃者はPII、個人の好み、認証データを含む数百万件の記録にアクセスすることができました。
無効化されたセキュリティ機能/デバッグ機能の有効化/不適切なパーミッションの脆弱性の解消
この脆弱性を排除するためには、おそらく2つのアプローチが必要です。問題のうち、デバッグが有効になっている部分を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するためのチェック機能を開発プロセスに追加するだけです。今回の例から、そのための適切なコマンドは次のようになります。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください。
DEBUG = False
現在、Django アプリケーションのデバッグ機能は、DEBUG フラグを False に設定すると無効になります。エラーに対応したエラーページは生成されません。もし敵がエラーページにアクセスできたとしても、有用なメタデータは含まれておらず、アプリケーションにリスクをもたらすことはありません。
無効化されたセキュリティ機能や不適切なパーミッションの脆弱性を排除することは、広範囲の特定の脆弱性を包含することができるため、少し困難です。これらを阻止する最善の方法は、ロックダウンされた資産を本番環境に迅速かつ容易に展開できるよう、標準的で反復可能なプロセスを開発することです。
その場合でも、オーケストレーション・ファイル、APIコンポーネント、Amazon S3バケットのパーミッションのようなクラウド・サービスが常にレビューされ、更新されるプロセスを作成する必要があります。このレビューでは、組織が常にAPIセキュリティを改善していることを確認するために、環境全体のセキュリティ設定の全体的な有効性を長期的に評価する必要があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
このリストのほとんどの脆弱性は、APIにかなり特化したものですが、セキュリティ機能の無効化／デバッグ機能の有効化／不適切なパーミッションの問題は、どこでも起こりうる問題です。APIではやや多いと思われますが、攻撃者は、パッチが適用されていない欠陥や保護されていないファイルやディレクトリをネットワーク上のどこかで見つけようとすることがよくあります。デバッグが有効になっていたり、セキュリティ機能が無効になっていたりするAPIに出くわすと、彼らの悪事が少しだけ楽になります。さらに悪いことに、セキュリティの設定ミスを検出して悪用するための自動化されたツールが用意されているため、あなたの環境にそれらがあれば、悪用される可能性が高く、それがこの脆弱性がOWASPの危険なAPI欠陥リストに入った理由です。
お楽しみの前に、このデバッグの課題を解決できるかどうか見てみましょう。
セキュリティ機能の無効化/デバッグ機能の有効化/不適切なパーミッションの欠陥は、どのようにしてAPIに忍び込むのでしょうか？
この多次元的なAPIの欠陥がどのようにしてネットワークに追加されていくのかを知るためには、その構成要素に分解する必要があります。まず、デバッグ機能の有効化の問題から始めましょう。デバッグは、アプリケーションが正しく動作しなかったり、エラーが発生したりする原因を開発者が把握するのに役立つ便利なツールです。デバッグ機能を有効にすると、エラーや例外発生時に詳細なエラーページが生成されるため、開発者は何が悪かったのかを確認し、問題を修正することができます。アプリケーションがまだ開発中の場合は、この機能を有効にしても問題ありません。
しかし、ほとんどのフレームワークでは、本番環境でのデバッグモードの実行に関する警告が表示されるのには理由があり、おそらくデバッグを有効にするコードの中に表示されています。例えば、以下のようなものです。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください
DEBUG = True
この例では、デバッグを有効にしています。Django アプリケーションは、例外が発生すると詳細なエラーページを生成します。これが本番環境で行われた場合、敵対者はこのエラーページにアクセスすることができ、その中には環境に関するメタデータ情報が含まれています。ほとんどのフレームワークでは、デフォルトでデバッグ機能がオフになっていますが、長い開発期間中に有効になっていると、元に戻すのを忘れてしまいがちです。その後、アプリケーションが本番環境に移行すると、アプリケーション、あるいはサーバやネットワーク全体を危険にさらす方法について、攻撃者に多くの情報を提供してしまいます。
デバッグモードを有効にすることは、ほとんどが単独の問題ですが、不適切なパーミッションと無効なセキュリティ機能の脆弱性は、しばしば連動します。例えば、OWASP が提供している実際のシナリオでは、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されているデータベースを見つけました。人気のあるデータベース管理システムは、デフォルトの設定を使用していたため、認証が無効になっていました。このように、不適切なパーミッションと無効化されたセキュリティ機能の脆弱性を組み合わせることで、攻撃者はPII、個人の好み、認証データを含む数百万件の記録にアクセスすることができました。
無効化されたセキュリティ機能/デバッグ機能の有効化/不適切なパーミッションの脆弱性の解消
この脆弱性を排除するためには、おそらく2つのアプローチが必要です。問題のうち、デバッグが有効になっている部分を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するためのチェック機能を開発プロセスに追加するだけです。今回の例から、そのための適切なコマンドは次のようになります。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください。
DEBUG = False
現在、Django アプリケーションのデバッグ機能は、DEBUG フラグを False に設定すると無効になります。エラーに対応したエラーページは生成されません。もし敵がエラーページにアクセスできたとしても、有用なメタデータは含まれておらず、アプリケーションにリスクをもたらすことはありません。
無効化されたセキュリティ機能や不適切なパーミッションの脆弱性を排除することは、広範囲の特定の脆弱性を包含することができるため、少し困難です。これらを阻止する最善の方法は、ロックダウンされた資産を本番環境に迅速かつ容易に展開できるよう、標準的で反復可能なプロセスを開発することです。
その場合でも、オーケストレーション・ファイル、APIコンポーネント、Amazon S3バケットのパーミッションのようなクラウド・サービスが常にレビューされ、更新されるプロセスを作成する必要があります。このレビューでは、組織が常にAPIセキュリティを改善していることを確認するために、環境全体のセキュリティ設定の全体的な有効性を長期的に評価する必要があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
このリストのほとんどの脆弱性は、APIにかなり特化したものですが、セキュリティ機能の無効化／デバッグ機能の有効化／不適切なパーミッションの問題は、どこでも起こりうる問題です。APIではやや多いと思われますが、攻撃者は、パッチが適用されていない欠陥や保護されていないファイルやディレクトリをネットワーク上のどこかで見つけようとすることがよくあります。デバッグが有効になっていたり、セキュリティ機能が無効になっていたりするAPIに出くわすと、彼らの悪事が少しだけ楽になります。さらに悪いことに、セキュリティの設定ミスを検出して悪用するための自動化されたツールが用意されているため、あなたの環境にそれらがあれば、悪用される可能性が高く、それがこの脆弱性がOWASPの危険なAPI欠陥リストに入った理由です。
お楽しみの前に、このデバッグの課題を解決できるかどうか見てみましょう。
セキュリティ機能の無効化/デバッグ機能の有効化/不適切なパーミッションの欠陥は、どのようにしてAPIに忍び込むのでしょうか？
この多次元的なAPIの欠陥がどのようにしてネットワークに追加されていくのかを知るためには、その構成要素に分解する必要があります。まず、デバッグ機能の有効化の問題から始めましょう。デバッグは、アプリケーションが正しく動作しなかったり、エラーが発生したりする原因を開発者が把握するのに役立つ便利なツールです。デバッグ機能を有効にすると、エラーや例外発生時に詳細なエラーページが生成されるため、開発者は何が悪かったのかを確認し、問題を修正することができます。アプリケーションがまだ開発中の場合は、この機能を有効にしても問題ありません。
しかし、ほとんどのフレームワークでは、本番環境でのデバッグモードの実行に関する警告が表示されるのには理由があり、おそらくデバッグを有効にするコードの中に表示されています。例えば、以下のようなものです。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください
DEBUG = True
この例では、デバッグを有効にしています。Django アプリケーションは、例外が発生すると詳細なエラーページを生成します。これが本番環境で行われた場合、敵対者はこのエラーページにアクセスすることができ、その中には環境に関するメタデータ情報が含まれています。ほとんどのフレームワークでは、デフォルトでデバッグ機能がオフになっていますが、長い開発期間中に有効になっていると、元に戻すのを忘れてしまいがちです。その後、アプリケーションが本番環境に移行すると、アプリケーション、あるいはサーバやネットワーク全体を危険にさらす方法について、攻撃者に多くの情報を提供してしまいます。
デバッグモードを有効にすることは、ほとんどが単独の問題ですが、不適切なパーミッションと無効なセキュリティ機能の脆弱性は、しばしば連動します。例えば、OWASP が提供している実際のシナリオでは、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されているデータベースを見つけました。人気のあるデータベース管理システムは、デフォルトの設定を使用していたため、認証が無効になっていました。このように、不適切なパーミッションと無効化されたセキュリティ機能の脆弱性を組み合わせることで、攻撃者はPII、個人の好み、認証データを含む数百万件の記録にアクセスすることができました。
無効化されたセキュリティ機能/デバッグ機能の有効化/不適切なパーミッションの脆弱性の解消
この脆弱性を排除するためには、おそらく2つのアプローチが必要です。問題のうち、デバッグが有効になっている部分を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するためのチェック機能を開発プロセスに追加するだけです。今回の例から、そのための適切なコマンドは次のようになります。
# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください。
DEBUG = False
現在、Django アプリケーションのデバッグ機能は、DEBUG フラグを False に設定すると無効になります。エラーに対応したエラーページは生成されません。もし敵がエラーページにアクセスできたとしても、有用なメタデータは含まれておらず、アプリケーションにリスクをもたらすことはありません。
無効化されたセキュリティ機能や不適切なパーミッションの脆弱性を排除することは、広範囲の特定の脆弱性を包含することができるため、少し困難です。これらを阻止する最善の方法は、ロックダウンされた資産を本番環境に迅速かつ容易に展開できるよう、標準的で反復可能なプロセスを開発することです。
その場合でも、オーケストレーション・ファイル、APIコンポーネント、Amazon S3バケットのパーミッションのようなクラウド・サービスが常にレビューされ、更新されるプロセスを作成する必要があります。このレビューでは、組織が常にAPIセキュリティを改善していることを確認するために、環境全体のセキュリティ設定の全体的な有効性を長期的に評価する必要があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
目次
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約するダウンロード始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、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運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
