Coders Conquer Security:シェア＆ラーンシリーズ - 既知の脆弱性を持つコンポーネントの使用
すべてのアプリケーションに共通するものは何でしょうか？それはコンポーネントであり、依存関係やライブラリとも呼ばれます。世の中には、どこかの時点で他のコードに依存していないコードはほとんどありません。アプリケーションを作成した時点で、依存関係が山のようにあるのです。
すべてのアプリケーションはコンポーネントを使用しており、そのほとんどはあなたが書いたものではありませんので、使用しているコンポーネント内の脆弱性が負債となる可能性があります。ここでは、既知の脆弱性を持つコンポーネントを使用することの意味、その危険性、解決方法について説明します。
既知の脆弱性を持つコンポーネントの使用に関する理解
複雑なソフトウェアには必ず脆弱性があります。それが獣の性質なのです。ですから、あなたのコンポーネントが100％安全であることはありません。しかし、コンポーネントに脆弱性が見つかったとき、あなたはそれを知っていますか？そのための準備はできていますか？
問題が発生するのは、コンポーネントが耐用年数を超えて使用された場合や、脆弱性が発見された後であることがほとんどです。ほとんどのコンポーネントやライブラリは、セキュリティ上の脆弱性が発表されるのと同時に、またはそれ以前に、その脆弱性に対するパッチをリリースしています。したがって、コンポーネントの脆弱性が発見・公表された場合には、できるだけ早くコンポーネントを更新することが何よりも重要です。脆弱なソフトウェアを本番環境に放置しないでください。
コンポーネントにはいくつかの供給元があります。サードパーティのベンダー製品を購入して、自分のカスタムコードと直接統合することもあります。これらのコンポーネントは、あなたのコードの一部となり、同じレベルの権限で動作します。もう一つのソースは、GitHubのようなサイトでホストされているオープンソースプロジェクトです。すべてのオープンソース・ライブラリが慎重に吟味されているわけではなく、また脆弱性がないか監査されているわけでもないので、オープンソースは危険です。
攻撃者は、コンポーネントの脆弱性情報を利用しています。脆弱性は公開されているので、攻撃者はあなたと同じタイミングで脆弱性を知っています。また、攻撃者は、あなたが使用しているコンポーネントを見つけるために使用できる技術を持っています。これらの情報が分かれば、アプリケーションにパッチが適用されていない場合の攻撃方法が分かります。
脆弱な部品がなぜ危険なのかを知る
脆弱性が知られているコンポーネントを使用することがどれほど危険かを示す証拠を探しているなら、2017年のEquifax社の情報漏えいを見れば一目瞭然でしょう。
2017年7月、米国の信用調査機関であるEquifax社が、1億4700万人以上の個人を特定できる情報を流出させる大規模なデータ流出を発見しました。このデータ侵害の範囲と影響は前例のないものです。最近では、Equifaxのセキュリティ対策の甘さを指摘するニュースが出ています。
その1つがパッチ管理です。Equifaxではパッチ管理が十分ではなかったため、コンポーネントにパッチが適用されないまま長期間が経過していました。これが今回の侵害の直接の原因です。
Equifax社のWebサイトでは、Webフレームワーク「Apache Struts」が使用されていました。攻撃者がネットワークに侵入する数カ月前に、Strutsフレームワークに脆弱性「Apache Struts CVE-2017-5638」が発見されました。しかし、Equifax社はこの脆弱性にパッチを当てていませんでした。攻撃者はこの脆弱性を利用して、Equifax社のネットワークにアクセスしました。そこから、個人情報の宝庫にアクセスしたのです。
多くのWebサイトは、自社で作成したものではないWebフレームワークをベースにしています。これは、必要な機能をすべて一から構築するのは大変な作業なので、標準的な方法です。しかし、フレームワークへの依存度が高いと、脆弱性が発生する可能性があります。次のEquifaxにならないために。
脆弱なコンポーネントからの保護方法
脆弱なコンポーネントの使用を防ぐための特効薬はありません。しかし、システムを危険にさらすために脆弱なコンポーネントが使用されるリスクを軽減するために使用できるポリシーとコントロールがあります。
アプリケーションを構築するためには、どのコンポーネントを、どのバージョンで使用しているかを知る必要があります。OWASP の Dependency Checkのような依存性管理ツールは、あなたが使用している依存性を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントの中に、一般に公開されている脆弱性があるかどうかも教えてくれます。
また、パッチマネジメントの手法も不可欠です。脆弱性が発見された場合、パッチがダウンロードされ、テストされ、本番にスムーズにリリースされるようなシステムが必要です。ソフトウェアにパッチを当て続けることで、数ヶ月前の脆弱性が攻撃者に利用されることを防ぎます。
最後に、オープンソースやサードパーティ製コンポーネントの使用を管理するためのポリシーを用意します。開発者はお役所仕事を嫌うものです。しかし、自組織が作成したものではないコードについては、審査プロセスを設ける必要があります。それは重荷である必要はありませんが、未知のコンポーネントが使用されるのを防ぐためには必須です。少なくとも、使用されているコンポーネントのインベントリーは最新の状態に保たれていなければなりません。
サードパーティ・バグに巻き込まれないために
コンポーネントには脆弱性があります。あなたのビジネス・アプリケーションは、ベンダーのものであれ、オープンソース・ライブラリのものであれ、コンポーネントを使用します。だからといって、あなたの組織が攻撃されやすいとは限りません。
攻撃者はあなたと同じ時期にどのような脆弱性が存在するかを知っているにもかかわらず、通常、パッチは一般の発表と同時に提供されます。ですから、自分のアプリケーションが何を使用しているのか、必ず教育してください。何が脆弱なのかを知る。コンポーネントには常にパッチを当てておきましょう。
脆弱な部品を発見して（倒して）いく準備はできていますか？アリーナに行ってバトルしてみましょう。 [Start Here]をクリックしてください。
すべてのアプリケーションはコンポーネントを使用しており、そのほとんどはあなたが書いたものではありませんので、使用しているコンポーネント内の脆弱性が負債となる可能性があります。ここでは、既知の脆弱性を持つコンポーネントを使用することの意味、その危険性、解決方法について説明します。
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 の共同設立者です。
すべてのアプリケーションに共通するものは何でしょうか？それはコンポーネントであり、依存関係やライブラリとも呼ばれます。世の中には、どこかの時点で他のコードに依存していないコードはほとんどありません。アプリケーションを作成した時点で、依存関係が山のようにあるのです。
すべてのアプリケーションはコンポーネントを使用しており、そのほとんどはあなたが書いたものではありませんので、使用しているコンポーネント内の脆弱性が負債となる可能性があります。ここでは、既知の脆弱性を持つコンポーネントを使用することの意味、その危険性、解決方法について説明します。
既知の脆弱性を持つコンポーネントの使用に関する理解
複雑なソフトウェアには必ず脆弱性があります。それが獣の性質なのです。ですから、あなたのコンポーネントが100％安全であることはありません。しかし、コンポーネントに脆弱性が見つかったとき、あなたはそれを知っていますか？そのための準備はできていますか？
問題が発生するのは、コンポーネントが耐用年数を超えて使用された場合や、脆弱性が発見された後であることがほとんどです。ほとんどのコンポーネントやライブラリは、セキュリティ上の脆弱性が発表されるのと同時に、またはそれ以前に、その脆弱性に対するパッチをリリースしています。したがって、コンポーネントの脆弱性が発見・公表された場合には、できるだけ早くコンポーネントを更新することが何よりも重要です。脆弱なソフトウェアを本番環境に放置しないでください。
コンポーネントにはいくつかの供給元があります。サードパーティのベンダー製品を購入して、自分のカスタムコードと直接統合することもあります。これらのコンポーネントは、あなたのコードの一部となり、同じレベルの権限で動作します。もう一つのソースは、GitHubのようなサイトでホストされているオープンソースプロジェクトです。すべてのオープンソース・ライブラリが慎重に吟味されているわけではなく、また脆弱性がないか監査されているわけでもないので、オープンソースは危険です。
攻撃者は、コンポーネントの脆弱性情報を利用しています。脆弱性は公開されているので、攻撃者はあなたと同じタイミングで脆弱性を知っています。また、攻撃者は、あなたが使用しているコンポーネントを見つけるために使用できる技術を持っています。これらの情報が分かれば、アプリケーションにパッチが適用されていない場合の攻撃方法が分かります。
脆弱な部品がなぜ危険なのかを知る
脆弱性が知られているコンポーネントを使用することがどれほど危険かを示す証拠を探しているなら、2017年のEquifax社の情報漏えいを見れば一目瞭然でしょう。
2017年7月、米国の信用調査機関であるEquifax社が、1億4700万人以上の個人を特定できる情報を流出させる大規模なデータ流出を発見しました。このデータ侵害の範囲と影響は前例のないものです。最近では、Equifaxのセキュリティ対策の甘さを指摘するニュースが出ています。
その1つがパッチ管理です。Equifaxではパッチ管理が十分ではなかったため、コンポーネントにパッチが適用されないまま長期間が経過していました。これが今回の侵害の直接の原因です。
Equifax社のWebサイトでは、Webフレームワーク「Apache Struts」が使用されていました。攻撃者がネットワークに侵入する数カ月前に、Strutsフレームワークに脆弱性「Apache Struts CVE-2017-5638」が発見されました。しかし、Equifax社はこの脆弱性にパッチを当てていませんでした。攻撃者はこの脆弱性を利用して、Equifax社のネットワークにアクセスしました。そこから、個人情報の宝庫にアクセスしたのです。
多くのWebサイトは、自社で作成したものではないWebフレームワークをベースにしています。これは、必要な機能をすべて一から構築するのは大変な作業なので、標準的な方法です。しかし、フレームワークへの依存度が高いと、脆弱性が発生する可能性があります。次のEquifaxにならないために。
脆弱なコンポーネントからの保護方法
脆弱なコンポーネントの使用を防ぐための特効薬はありません。しかし、システムを危険にさらすために脆弱なコンポーネントが使用されるリスクを軽減するために使用できるポリシーとコントロールがあります。
アプリケーションを構築するためには、どのコンポーネントを、どのバージョンで使用しているかを知る必要があります。OWASP の Dependency Checkのような依存性管理ツールは、あなたが使用している依存性を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントの中に、一般に公開されている脆弱性があるかどうかも教えてくれます。
また、パッチマネジメントの手法も不可欠です。脆弱性が発見された場合、パッチがダウンロードされ、テストされ、本番にスムーズにリリースされるようなシステムが必要です。ソフトウェアにパッチを当て続けることで、数ヶ月前の脆弱性が攻撃者に利用されることを防ぎます。
最後に、オープンソースやサードパーティ製コンポーネントの使用を管理するためのポリシーを用意します。開発者はお役所仕事を嫌うものです。しかし、自組織が作成したものではないコードについては、審査プロセスを設ける必要があります。それは重荷である必要はありませんが、未知のコンポーネントが使用されるのを防ぐためには必須です。少なくとも、使用されているコンポーネントのインベントリーは最新の状態に保たれていなければなりません。
サードパーティ・バグに巻き込まれないために
コンポーネントには脆弱性があります。あなたのビジネス・アプリケーションは、ベンダーのものであれ、オープンソース・ライブラリのものであれ、コンポーネントを使用します。だからといって、あなたの組織が攻撃されやすいとは限りません。
攻撃者はあなたと同じ時期にどのような脆弱性が存在するかを知っているにもかかわらず、通常、パッチは一般の発表と同時に提供されます。ですから、自分のアプリケーションが何を使用しているのか、必ず教育してください。何が脆弱なのかを知る。コンポーネントには常にパッチを当てておきましょう。
脆弱な部品を発見して（倒して）いく準備はできていますか？アリーナに行ってバトルしてみましょう。 [Start Here]をクリックしてください。
すべてのアプリケーションに共通するものは何でしょうか？それはコンポーネントであり、依存関係やライブラリとも呼ばれます。世の中には、どこかの時点で他のコードに依存していないコードはほとんどありません。アプリケーションを作成した時点で、依存関係が山のようにあるのです。
すべてのアプリケーションはコンポーネントを使用しており、そのほとんどはあなたが書いたものではありませんので、使用しているコンポーネント内の脆弱性が負債となる可能性があります。ここでは、既知の脆弱性を持つコンポーネントを使用することの意味、その危険性、解決方法について説明します。
既知の脆弱性を持つコンポーネントの使用に関する理解
複雑なソフトウェアには必ず脆弱性があります。それが獣の性質なのです。ですから、あなたのコンポーネントが100％安全であることはありません。しかし、コンポーネントに脆弱性が見つかったとき、あなたはそれを知っていますか？そのための準備はできていますか？
問題が発生するのは、コンポーネントが耐用年数を超えて使用された場合や、脆弱性が発見された後であることがほとんどです。ほとんどのコンポーネントやライブラリは、セキュリティ上の脆弱性が発表されるのと同時に、またはそれ以前に、その脆弱性に対するパッチをリリースしています。したがって、コンポーネントの脆弱性が発見・公表された場合には、できるだけ早くコンポーネントを更新することが何よりも重要です。脆弱なソフトウェアを本番環境に放置しないでください。
コンポーネントにはいくつかの供給元があります。サードパーティのベンダー製品を購入して、自分のカスタムコードと直接統合することもあります。これらのコンポーネントは、あなたのコードの一部となり、同じレベルの権限で動作します。もう一つのソースは、GitHubのようなサイトでホストされているオープンソースプロジェクトです。すべてのオープンソース・ライブラリが慎重に吟味されているわけではなく、また脆弱性がないか監査されているわけでもないので、オープンソースは危険です。
攻撃者は、コンポーネントの脆弱性情報を利用しています。脆弱性は公開されているので、攻撃者はあなたと同じタイミングで脆弱性を知っています。また、攻撃者は、あなたが使用しているコンポーネントを見つけるために使用できる技術を持っています。これらの情報が分かれば、アプリケーションにパッチが適用されていない場合の攻撃方法が分かります。
脆弱な部品がなぜ危険なのかを知る
脆弱性が知られているコンポーネントを使用することがどれほど危険かを示す証拠を探しているなら、2017年のEquifax社の情報漏えいを見れば一目瞭然でしょう。
2017年7月、米国の信用調査機関であるEquifax社が、1億4700万人以上の個人を特定できる情報を流出させる大規模なデータ流出を発見しました。このデータ侵害の範囲と影響は前例のないものです。最近では、Equifaxのセキュリティ対策の甘さを指摘するニュースが出ています。
その1つがパッチ管理です。Equifaxではパッチ管理が十分ではなかったため、コンポーネントにパッチが適用されないまま長期間が経過していました。これが今回の侵害の直接の原因です。
Equifax社のWebサイトでは、Webフレームワーク「Apache Struts」が使用されていました。攻撃者がネットワークに侵入する数カ月前に、Strutsフレームワークに脆弱性「Apache Struts CVE-2017-5638」が発見されました。しかし、Equifax社はこの脆弱性にパッチを当てていませんでした。攻撃者はこの脆弱性を利用して、Equifax社のネットワークにアクセスしました。そこから、個人情報の宝庫にアクセスしたのです。
多くのWebサイトは、自社で作成したものではないWebフレームワークをベースにしています。これは、必要な機能をすべて一から構築するのは大変な作業なので、標準的な方法です。しかし、フレームワークへの依存度が高いと、脆弱性が発生する可能性があります。次のEquifaxにならないために。
脆弱なコンポーネントからの保護方法
脆弱なコンポーネントの使用を防ぐための特効薬はありません。しかし、システムを危険にさらすために脆弱なコンポーネントが使用されるリスクを軽減するために使用できるポリシーとコントロールがあります。
アプリケーションを構築するためには、どのコンポーネントを、どのバージョンで使用しているかを知る必要があります。OWASP の Dependency Checkのような依存性管理ツールは、あなたが使用している依存性を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントの中に、一般に公開されている脆弱性があるかどうかも教えてくれます。
また、パッチマネジメントの手法も不可欠です。脆弱性が発見された場合、パッチがダウンロードされ、テストされ、本番にスムーズにリリースされるようなシステムが必要です。ソフトウェアにパッチを当て続けることで、数ヶ月前の脆弱性が攻撃者に利用されることを防ぎます。
最後に、オープンソースやサードパーティ製コンポーネントの使用を管理するためのポリシーを用意します。開発者はお役所仕事を嫌うものです。しかし、自組織が作成したものではないコードについては、審査プロセスを設ける必要があります。それは重荷である必要はありませんが、未知のコンポーネントが使用されるのを防ぐためには必須です。少なくとも、使用されているコンポーネントのインベントリーは最新の状態に保たれていなければなりません。
サードパーティ・バグに巻き込まれないために
コンポーネントには脆弱性があります。あなたのビジネス・アプリケーションは、ベンダーのものであれ、オープンソース・ライブラリのものであれ、コンポーネントを使用します。だからといって、あなたの組織が攻撃されやすいとは限りません。
攻撃者はあなたと同じ時期にどのような脆弱性が存在するかを知っているにもかかわらず、通常、パッチは一般の発表と同時に提供されます。ですから、自分のアプリケーションが何を使用しているのか、必ず教育してください。何が脆弱なのかを知る。コンポーネントには常にパッチを当てておきましょう。
脆弱な部品を発見して（倒して）いく準備はできていますか？アリーナに行ってバトルしてみましょう。 [Start Here]をクリックしてください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
すべてのアプリケーションに共通するものは何でしょうか？それはコンポーネントであり、依存関係やライブラリとも呼ばれます。世の中には、どこかの時点で他のコードに依存していないコードはほとんどありません。アプリケーションを作成した時点で、依存関係が山のようにあるのです。
すべてのアプリケーションはコンポーネントを使用しており、そのほとんどはあなたが書いたものではありませんので、使用しているコンポーネント内の脆弱性が負債となる可能性があります。ここでは、既知の脆弱性を持つコンポーネントを使用することの意味、その危険性、解決方法について説明します。
既知の脆弱性を持つコンポーネントの使用に関する理解
複雑なソフトウェアには必ず脆弱性があります。それが獣の性質なのです。ですから、あなたのコンポーネントが100％安全であることはありません。しかし、コンポーネントに脆弱性が見つかったとき、あなたはそれを知っていますか？そのための準備はできていますか？
問題が発生するのは、コンポーネントが耐用年数を超えて使用された場合や、脆弱性が発見された後であることがほとんどです。ほとんどのコンポーネントやライブラリは、セキュリティ上の脆弱性が発表されるのと同時に、またはそれ以前に、その脆弱性に対するパッチをリリースしています。したがって、コンポーネントの脆弱性が発見・公表された場合には、できるだけ早くコンポーネントを更新することが何よりも重要です。脆弱なソフトウェアを本番環境に放置しないでください。
コンポーネントにはいくつかの供給元があります。サードパーティのベンダー製品を購入して、自分のカスタムコードと直接統合することもあります。これらのコンポーネントは、あなたのコードの一部となり、同じレベルの権限で動作します。もう一つのソースは、GitHubのようなサイトでホストされているオープンソースプロジェクトです。すべてのオープンソース・ライブラリが慎重に吟味されているわけではなく、また脆弱性がないか監査されているわけでもないので、オープンソースは危険です。
攻撃者は、コンポーネントの脆弱性情報を利用しています。脆弱性は公開されているので、攻撃者はあなたと同じタイミングで脆弱性を知っています。また、攻撃者は、あなたが使用しているコンポーネントを見つけるために使用できる技術を持っています。これらの情報が分かれば、アプリケーションにパッチが適用されていない場合の攻撃方法が分かります。
脆弱な部品がなぜ危険なのかを知る
脆弱性が知られているコンポーネントを使用することがどれほど危険かを示す証拠を探しているなら、2017年のEquifax社の情報漏えいを見れば一目瞭然でしょう。
2017年7月、米国の信用調査機関であるEquifax社が、1億4700万人以上の個人を特定できる情報を流出させる大規模なデータ流出を発見しました。このデータ侵害の範囲と影響は前例のないものです。最近では、Equifaxのセキュリティ対策の甘さを指摘するニュースが出ています。
その1つがパッチ管理です。Equifaxではパッチ管理が十分ではなかったため、コンポーネントにパッチが適用されないまま長期間が経過していました。これが今回の侵害の直接の原因です。
Equifax社のWebサイトでは、Webフレームワーク「Apache Struts」が使用されていました。攻撃者がネットワークに侵入する数カ月前に、Strutsフレームワークに脆弱性「Apache Struts CVE-2017-5638」が発見されました。しかし、Equifax社はこの脆弱性にパッチを当てていませんでした。攻撃者はこの脆弱性を利用して、Equifax社のネットワークにアクセスしました。そこから、個人情報の宝庫にアクセスしたのです。
多くのWebサイトは、自社で作成したものではないWebフレームワークをベースにしています。これは、必要な機能をすべて一から構築するのは大変な作業なので、標準的な方法です。しかし、フレームワークへの依存度が高いと、脆弱性が発生する可能性があります。次のEquifaxにならないために。
脆弱なコンポーネントからの保護方法
脆弱なコンポーネントの使用を防ぐための特効薬はありません。しかし、システムを危険にさらすために脆弱なコンポーネントが使用されるリスクを軽減するために使用できるポリシーとコントロールがあります。
アプリケーションを構築するためには、どのコンポーネントを、どのバージョンで使用しているかを知る必要があります。OWASP の Dependency Checkのような依存性管理ツールは、あなたが使用している依存性を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントの中に、一般に公開されている脆弱性があるかどうかも教えてくれます。
また、パッチマネジメントの手法も不可欠です。脆弱性が発見された場合、パッチがダウンロードされ、テストされ、本番にスムーズにリリースされるようなシステムが必要です。ソフトウェアにパッチを当て続けることで、数ヶ月前の脆弱性が攻撃者に利用されることを防ぎます。
最後に、オープンソースやサードパーティ製コンポーネントの使用を管理するためのポリシーを用意します。開発者はお役所仕事を嫌うものです。しかし、自組織が作成したものではないコードについては、審査プロセスを設ける必要があります。それは重荷である必要はありませんが、未知のコンポーネントが使用されるのを防ぐためには必須です。少なくとも、使用されているコンポーネントのインベントリーは最新の状態に保たれていなければなりません。
サードパーティ・バグに巻き込まれないために
コンポーネントには脆弱性があります。あなたのビジネス・アプリケーションは、ベンダーのものであれ、オープンソース・ライブラリのものであれ、コンポーネントを使用します。だからといって、あなたの組織が攻撃されやすいとは限りません。
攻撃者はあなたと同じ時期にどのような脆弱性が存在するかを知っているにもかかわらず、通常、パッチは一般の発表と同時に提供されます。ですから、自分のアプリケーションが何を使用しているのか、必ず教育してください。何が脆弱なのかを知る。コンポーネントには常にパッチを当てておきましょう。
脆弱な部品を発見して（倒して）いく準備はできていますか？アリーナに行ってバトルしてみましょう。 [Start Here]をクリックしてください。
.png)
