Happy birthday SQL injection, the bug that can't be squashed
この記事の一部は、以下のサイトに掲載されています。 ヘルプネットセキュリティ.この記事は更新され、ここでシンジケートされています。
もしあなたがサイバーセキュリティの仕事に就いていて、コードに精通している必要があるならば、SQLインジェクションについて何度も何度も考えなければならない可能性があります。SQLインジェクションは一般的な脆弱性であり、最初に発見されてから数週間で簡単な対処法がわかったにもかかわらず、我々のソフトウェアを悩ませ続け、導入前に検出されないままでいると、自称攻撃者にわずかなチャンスを与えることになります。
2020年12月13日、SQLインジェクションの22回目の誕生日を迎えました。この脆弱性はお酒が飲めるほど古いものであるにもかかわらず、私たちはこの脆弱性を永久につぶすことなく、そのままにしています。今年の8月、Freepik社は、830万人のユーザーのアカウントを危険にさらすSQLインジェクションの失態の被害に遭ったことを公表しました。ユーザーの中には、GoogleやFacebookなどの第三者によるログインを利用していた人もいましたが、数百万人のユーザーは、暗号化されていないパスワードがユーザー名とともに流出していました。彼らや他の多くのユーザーにとっては残念なことに、これらの事件の影響は大きな頭痛の種であり、ユーザーベースの信頼を回復するには長期的なプロセスが必要です。
この節目をレガシーとされる問題で「祝う」一方で、この問題を少し分析してみましょう。なぜこのような問題が後を絶たないのか、なぜOWASPトップ10の上位から何年も抜け出せないほど危険なのか、そしてなぜ比較的簡単な修正方法がソフトウェア開発の一般的なベンチマーク基準に入っていないのか。
なぜSQLインジェクションは2021年になっても有効なのか？
最近話題になったFireEye社への壊滅的なサイバー攻撃を見てみると、その巧妙さに驚かされます。この攻撃は、FireEye社の強盗用にカスタマイズされたと思われる高度な技術を駆使した、高度に組織化された国家的な攻撃でした。
"攻撃者 たちは、 ファイア・アイを標的にして 攻撃するために、その世界レベルの能力を特別に調整しまし た。 彼らはオペレーション・セキュリティの高度な訓練を受けており、規律と集中力を持って実行しました。彼らは、当社や当社のパートナーが過去に目撃したことのない斬新な技術の組み合わせを使用しました。”
CISOにとっては悪夢のような話ですが、もしFireEye社にこのようなことが起きれば、多くの企業がいかに脆弱であるかがわかるでしょう。
しかし、一般の企業にとっては、さらに悪いニュースです。FireEyeは、世界で最も有名なサイバーセキュリティ企業の1つですが、今回の攻撃では、黒幕レベルの悪人たちが全力を挙げて組織的に大規模な攻撃を行いました。しかし、多くの企業にとっては、単純なバグを利用して、素早く、しかも首謀者を必要とせずに、莫大な額のデータを流出させることができるかもしれません。SQLインジェクションはその典型的な例であり、ダークウェブで一儲けしようとするスクリプト・キディたちがいまだに利用しています。
2020年5月、ある男性が、数十万件の有効なクレジットカード番号を保存したデジタルメディアを持っていたことが発覚し、クレジットカードの不正利用とハッキングの罪で起訴されました。彼はSQLインジェクション技術を用いてこれらの情報を収集し、多くの企業とその顧客数百万人を危険にさらしました。
業界として、私たちは常に改善を続けていますが、SQLインジェクションは依然として重大な脅威であり、レガシーシステムやパッチが適用されていないシステムよりもはるかに多くのものに影響を与えます。
なぜ開発者はそれを維持しているのか（そしてそれが彼らの責任ではないことも
私たちは、SQLインジェクションは簡単に修正でき、コードはSQLインジェクションが全く発生しないように書くべきだと言い続けています。ほとんどのことがそうであるように、正しいやり方を教わっていれば簡単なのです。
ここで、ソフトウェア開発プロセスの歯車がぐらつき始めます。開発者は同じ間違いを繰り返し、SQLインジェクションのような脆弱性が繰り返しコードベースに侵入することになります。しかし、これは驚くべきことではありません。ほとんどのエンジニアは、安全なコーディングについてほとんど何も学ばずに学位を取得します。特に、自分の役割においてセキュリティがビジネス上の優先事項とみなされていない環境では、ほとんどのオン・ザ・ジョブ・トレーニングは不十分なものになります。
開発者がセキュリティに関心を持つ理由や、セキュリティ意識を高めるための強力なプラットフォームが提供されていないのです。劣悪なコーディングパターンがSQLインジェクションのようなバグを存続させています。私たちは、開発者のセキュリティ意識にもっと重点を置き、より高い水準の安全で質の高いコードを書くための時間を与える必要があります。安全なコーディングパターンを書くには時間がかかりますが、そのために費やした時間は、後の工程で非常に重要な効率性を生み出します。
SQLインジェクションの葬儀は行われないのか？
お葬式の例えは少し病的ですが、実際、SQLインジェクションが永久に眠りにつくことができれば、私たちの機密データはより安全になります。なぜなら、予防的なセキュリティの文化や、安全なコーディングの重要性が、棺桶に釘を打ち始めるのに十分なほど進化していないからです。
Rustのようにセキュリティに強い新しい言語は、より安全な関数を利用することで、長い間対処してきたバグを根絶するのに役立っていますが、膨大な量のレガシーソフトウェア、古いシステム、ライブラリは、今後も使用され続け、潜在的な脆弱性を持っています。
簡単な」エクスプロイトを永久に封じ込めるためには、開発プロセスにおけるセキュリティの責任分担（DevSecOps）が重要になります。開発者は最初から参加し、より安全で優れたコードを作成するために自分の役割に責任を持てるようにサポートされなければなりません。
開発者は自分のコードにあるSQLインジェクションのバグをどのように修正すべきでしょうか？
SQLインジェクションの識別と修正方法を学びたい開発者のために、包括的なガイドを用意しました。選択したプログラミング言語（COBOLも可）を使ったゲーム性のある課題が含まれており、すべての開発者がより安全で高品質なコードを作成するのに役立つ基礎的な学習ができます。
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はゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
この記事の一部は、以下のサイトに掲載されています。 ヘルプネットセキュリティ.この記事は更新され、ここでシンジケートされています。
もしあなたがサイバーセキュリティの仕事に就いていて、コードに精通している必要があるならば、SQLインジェクションについて何度も何度も考えなければならない可能性があります。SQLインジェクションは一般的な脆弱性であり、最初に発見されてから数週間で簡単な対処法がわかったにもかかわらず、我々のソフトウェアを悩ませ続け、導入前に検出されないままでいると、自称攻撃者にわずかなチャンスを与えることになります。
2020年12月13日、SQLインジェクションの22回目の誕生日を迎えました。この脆弱性はお酒が飲めるほど古いものであるにもかかわらず、私たちはこの脆弱性を永久につぶすことなく、そのままにしています。今年の8月、Freepik社は、830万人のユーザーのアカウントを危険にさらすSQLインジェクションの失態の被害に遭ったことを公表しました。ユーザーの中には、GoogleやFacebookなどの第三者によるログインを利用していた人もいましたが、数百万人のユーザーは、暗号化されていないパスワードがユーザー名とともに流出していました。彼らや他の多くのユーザーにとっては残念なことに、これらの事件の影響は大きな頭痛の種であり、ユーザーベースの信頼を回復するには長期的なプロセスが必要です。
この節目をレガシーとされる問題で「祝う」一方で、この問題を少し分析してみましょう。なぜこのような問題が後を絶たないのか、なぜOWASPトップ10の上位から何年も抜け出せないほど危険なのか、そしてなぜ比較的簡単な修正方法がソフトウェア開発の一般的なベンチマーク基準に入っていないのか。
なぜSQLインジェクションは2021年になっても有効なのか？
最近話題になったFireEye社への壊滅的なサイバー攻撃を見てみると、その巧妙さに驚かされます。この攻撃は、FireEye社の強盗用にカスタマイズされたと思われる高度な技術を駆使した、高度に組織化された国家的な攻撃でした。
"攻撃者 たちは、 ファイア・アイを標的にして 攻撃するために、その世界レベルの能力を特別に調整しまし た。 彼らはオペレーション・セキュリティの高度な訓練を受けており、規律と集中力を持って実行しました。彼らは、当社や当社のパートナーが過去に目撃したことのない斬新な技術の組み合わせを使用しました。”
CISOにとっては悪夢のような話ですが、もしFireEye社にこのようなことが起きれば、多くの企業がいかに脆弱であるかがわかるでしょう。
しかし、一般の企業にとっては、さらに悪いニュースです。FireEyeは、世界で最も有名なサイバーセキュリティ企業の1つですが、今回の攻撃では、黒幕レベルの悪人たちが全力を挙げて組織的に大規模な攻撃を行いました。しかし、多くの企業にとっては、単純なバグを利用して、素早く、しかも首謀者を必要とせずに、莫大な額のデータを流出させることができるかもしれません。SQLインジェクションはその典型的な例であり、ダークウェブで一儲けしようとするスクリプト・キディたちがいまだに利用しています。
2020年5月、ある男性が、数十万件の有効なクレジットカード番号を保存したデジタルメディアを持っていたことが発覚し、クレジットカードの不正利用とハッキングの罪で起訴されました。彼はSQLインジェクション技術を用いてこれらの情報を収集し、多くの企業とその顧客数百万人を危険にさらしました。
業界として、私たちは常に改善を続けていますが、SQLインジェクションは依然として重大な脅威であり、レガシーシステムやパッチが適用されていないシステムよりもはるかに多くのものに影響を与えます。
なぜ開発者はそれを維持しているのか（そしてそれが彼らの責任ではないことも
私たちは、SQLインジェクションは簡単に修正でき、コードはSQLインジェクションが全く発生しないように書くべきだと言い続けています。ほとんどのことがそうであるように、正しいやり方を教わっていれば簡単なのです。
ここで、ソフトウェア開発プロセスの歯車がぐらつき始めます。開発者は同じ間違いを繰り返し、SQLインジェクションのような脆弱性が繰り返しコードベースに侵入することになります。しかし、これは驚くべきことではありません。ほとんどのエンジニアは、安全なコーディングについてほとんど何も学ばずに学位を取得します。特に、自分の役割においてセキュリティがビジネス上の優先事項とみなされていない環境では、ほとんどのオン・ザ・ジョブ・トレーニングは不十分なものになります。
開発者がセキュリティに関心を持つ理由や、セキュリティ意識を高めるための強力なプラットフォームが提供されていないのです。劣悪なコーディングパターンがSQLインジェクションのようなバグを存続させています。私たちは、開発者のセキュリティ意識にもっと重点を置き、より高い水準の安全で質の高いコードを書くための時間を与える必要があります。安全なコーディングパターンを書くには時間がかかりますが、そのために費やした時間は、後の工程で非常に重要な効率性を生み出します。
SQLインジェクションの葬儀は行われないのか？
お葬式の例えは少し病的ですが、実際、SQLインジェクションが永久に眠りにつくことができれば、私たちの機密データはより安全になります。なぜなら、予防的なセキュリティの文化や、安全なコーディングの重要性が、棺桶に釘を打ち始めるのに十分なほど進化していないからです。
Rustのようにセキュリティに強い新しい言語は、より安全な関数を利用することで、長い間対処してきたバグを根絶するのに役立っていますが、膨大な量のレガシーソフトウェア、古いシステム、ライブラリは、今後も使用され続け、潜在的な脆弱性を持っています。
簡単な」エクスプロイトを永久に封じ込めるためには、開発プロセスにおけるセキュリティの責任分担（DevSecOps）が重要になります。開発者は最初から参加し、より安全で優れたコードを作成するために自分の役割に責任を持てるようにサポートされなければなりません。
開発者は自分のコードにあるSQLインジェクションのバグをどのように修正すべきでしょうか？
SQLインジェクションの識別と修正方法を学びたい開発者のために、包括的なガイドを用意しました。選択したプログラミング言語（COBOLも可）を使ったゲーム性のある課題が含まれており、すべての開発者がより安全で高品質なコードを作成するのに役立つ基礎的な学習ができます。
この記事の一部は、以下のサイトに掲載されています。 ヘルプネットセキュリティ.この記事は更新され、ここでシンジケートされています。
もしあなたがサイバーセキュリティの仕事に就いていて、コードに精通している必要があるならば、SQLインジェクションについて何度も何度も考えなければならない可能性があります。SQLインジェクションは一般的な脆弱性であり、最初に発見されてから数週間で簡単な対処法がわかったにもかかわらず、我々のソフトウェアを悩ませ続け、導入前に検出されないままでいると、自称攻撃者にわずかなチャンスを与えることになります。
2020年12月13日、SQLインジェクションの22回目の誕生日を迎えました。この脆弱性はお酒が飲めるほど古いものであるにもかかわらず、私たちはこの脆弱性を永久につぶすことなく、そのままにしています。今年の8月、Freepik社は、830万人のユーザーのアカウントを危険にさらすSQLインジェクションの失態の被害に遭ったことを公表しました。ユーザーの中には、GoogleやFacebookなどの第三者によるログインを利用していた人もいましたが、数百万人のユーザーは、暗号化されていないパスワードがユーザー名とともに流出していました。彼らや他の多くのユーザーにとっては残念なことに、これらの事件の影響は大きな頭痛の種であり、ユーザーベースの信頼を回復するには長期的なプロセスが必要です。
この節目をレガシーとされる問題で「祝う」一方で、この問題を少し分析してみましょう。なぜこのような問題が後を絶たないのか、なぜOWASPトップ10の上位から何年も抜け出せないほど危険なのか、そしてなぜ比較的簡単な修正方法がソフトウェア開発の一般的なベンチマーク基準に入っていないのか。
なぜSQLインジェクションは2021年になっても有効なのか？
最近話題になったFireEye社への壊滅的なサイバー攻撃を見てみると、その巧妙さに驚かされます。この攻撃は、FireEye社の強盗用にカスタマイズされたと思われる高度な技術を駆使した、高度に組織化された国家的な攻撃でした。
"攻撃者 たちは、 ファイア・アイを標的にして 攻撃するために、その世界レベルの能力を特別に調整しまし た。 彼らはオペレーション・セキュリティの高度な訓練を受けており、規律と集中力を持って実行しました。彼らは、当社や当社のパートナーが過去に目撃したことのない斬新な技術の組み合わせを使用しました。”
CISOにとっては悪夢のような話ですが、もしFireEye社にこのようなことが起きれば、多くの企業がいかに脆弱であるかがわかるでしょう。
しかし、一般の企業にとっては、さらに悪いニュースです。FireEyeは、世界で最も有名なサイバーセキュリティ企業の1つですが、今回の攻撃では、黒幕レベルの悪人たちが全力を挙げて組織的に大規模な攻撃を行いました。しかし、多くの企業にとっては、単純なバグを利用して、素早く、しかも首謀者を必要とせずに、莫大な額のデータを流出させることができるかもしれません。SQLインジェクションはその典型的な例であり、ダークウェブで一儲けしようとするスクリプト・キディたちがいまだに利用しています。
2020年5月、ある男性が、数十万件の有効なクレジットカード番号を保存したデジタルメディアを持っていたことが発覚し、クレジットカードの不正利用とハッキングの罪で起訴されました。彼はSQLインジェクション技術を用いてこれらの情報を収集し、多くの企業とその顧客数百万人を危険にさらしました。
業界として、私たちは常に改善を続けていますが、SQLインジェクションは依然として重大な脅威であり、レガシーシステムやパッチが適用されていないシステムよりもはるかに多くのものに影響を与えます。
なぜ開発者はそれを維持しているのか（そしてそれが彼らの責任ではないことも
私たちは、SQLインジェクションは簡単に修正でき、コードはSQLインジェクションが全く発生しないように書くべきだと言い続けています。ほとんどのことがそうであるように、正しいやり方を教わっていれば簡単なのです。
ここで、ソフトウェア開発プロセスの歯車がぐらつき始めます。開発者は同じ間違いを繰り返し、SQLインジェクションのような脆弱性が繰り返しコードベースに侵入することになります。しかし、これは驚くべきことではありません。ほとんどのエンジニアは、安全なコーディングについてほとんど何も学ばずに学位を取得します。特に、自分の役割においてセキュリティがビジネス上の優先事項とみなされていない環境では、ほとんどのオン・ザ・ジョブ・トレーニングは不十分なものになります。
開発者がセキュリティに関心を持つ理由や、セキュリティ意識を高めるための強力なプラットフォームが提供されていないのです。劣悪なコーディングパターンがSQLインジェクションのようなバグを存続させています。私たちは、開発者のセキュリティ意識にもっと重点を置き、より高い水準の安全で質の高いコードを書くための時間を与える必要があります。安全なコーディングパターンを書くには時間がかかりますが、そのために費やした時間は、後の工程で非常に重要な効率性を生み出します。
SQLインジェクションの葬儀は行われないのか？
お葬式の例えは少し病的ですが、実際、SQLインジェクションが永久に眠りにつくことができれば、私たちの機密データはより安全になります。なぜなら、予防的なセキュリティの文化や、安全なコーディングの重要性が、棺桶に釘を打ち始めるのに十分なほど進化していないからです。
Rustのようにセキュリティに強い新しい言語は、より安全な関数を利用することで、長い間対処してきたバグを根絶するのに役立っていますが、膨大な量のレガシーソフトウェア、古いシステム、ライブラリは、今後も使用され続け、潜在的な脆弱性を持っています。
簡単な」エクスプロイトを永久に封じ込めるためには、開発プロセスにおけるセキュリティの責任分担（DevSecOps）が重要になります。開発者は最初から参加し、より安全で優れたコードを作成するために自分の役割に責任を持てるようにサポートされなければなりません。
開発者は自分のコードにあるSQLインジェクションのバグをどのように修正すべきでしょうか？
SQLインジェクションの識別と修正方法を学びたい開発者のために、包括的なガイドを用意しました。選択したプログラミング言語（COBOLも可）を使ったゲーム性のある課題が含まれており、すべての開発者がより安全で高品質なコードを作成するのに役立つ基礎的な学習ができます。
以下のリンクをクリックし、この資料の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はゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
この記事の一部は、以下のサイトに掲載されています。 ヘルプネットセキュリティ.この記事は更新され、ここでシンジケートされています。
もしあなたがサイバーセキュリティの仕事に就いていて、コードに精通している必要があるならば、SQLインジェクションについて何度も何度も考えなければならない可能性があります。SQLインジェクションは一般的な脆弱性であり、最初に発見されてから数週間で簡単な対処法がわかったにもかかわらず、我々のソフトウェアを悩ませ続け、導入前に検出されないままでいると、自称攻撃者にわずかなチャンスを与えることになります。
2020年12月13日、SQLインジェクションの22回目の誕生日を迎えました。この脆弱性はお酒が飲めるほど古いものであるにもかかわらず、私たちはこの脆弱性を永久につぶすことなく、そのままにしています。今年の8月、Freepik社は、830万人のユーザーのアカウントを危険にさらすSQLインジェクションの失態の被害に遭ったことを公表しました。ユーザーの中には、GoogleやFacebookなどの第三者によるログインを利用していた人もいましたが、数百万人のユーザーは、暗号化されていないパスワードがユーザー名とともに流出していました。彼らや他の多くのユーザーにとっては残念なことに、これらの事件の影響は大きな頭痛の種であり、ユーザーベースの信頼を回復するには長期的なプロセスが必要です。
この節目をレガシーとされる問題で「祝う」一方で、この問題を少し分析してみましょう。なぜこのような問題が後を絶たないのか、なぜOWASPトップ10の上位から何年も抜け出せないほど危険なのか、そしてなぜ比較的簡単な修正方法がソフトウェア開発の一般的なベンチマーク基準に入っていないのか。
なぜSQLインジェクションは2021年になっても有効なのか？
最近話題になったFireEye社への壊滅的なサイバー攻撃を見てみると、その巧妙さに驚かされます。この攻撃は、FireEye社の強盗用にカスタマイズされたと思われる高度な技術を駆使した、高度に組織化された国家的な攻撃でした。
"攻撃者 たちは、 ファイア・アイを標的にして 攻撃するために、その世界レベルの能力を特別に調整しまし た。 彼らはオペレーション・セキュリティの高度な訓練を受けており、規律と集中力を持って実行しました。彼らは、当社や当社のパートナーが過去に目撃したことのない斬新な技術の組み合わせを使用しました。”
CISOにとっては悪夢のような話ですが、もしFireEye社にこのようなことが起きれば、多くの企業がいかに脆弱であるかがわかるでしょう。
しかし、一般の企業にとっては、さらに悪いニュースです。FireEyeは、世界で最も有名なサイバーセキュリティ企業の1つですが、今回の攻撃では、黒幕レベルの悪人たちが全力を挙げて組織的に大規模な攻撃を行いました。しかし、多くの企業にとっては、単純なバグを利用して、素早く、しかも首謀者を必要とせずに、莫大な額のデータを流出させることができるかもしれません。SQLインジェクションはその典型的な例であり、ダークウェブで一儲けしようとするスクリプト・キディたちがいまだに利用しています。
2020年5月、ある男性が、数十万件の有効なクレジットカード番号を保存したデジタルメディアを持っていたことが発覚し、クレジットカードの不正利用とハッキングの罪で起訴されました。彼はSQLインジェクション技術を用いてこれらの情報を収集し、多くの企業とその顧客数百万人を危険にさらしました。
業界として、私たちは常に改善を続けていますが、SQLインジェクションは依然として重大な脅威であり、レガシーシステムやパッチが適用されていないシステムよりもはるかに多くのものに影響を与えます。
なぜ開発者はそれを維持しているのか（そしてそれが彼らの責任ではないことも
私たちは、SQLインジェクションは簡単に修正でき、コードはSQLインジェクションが全く発生しないように書くべきだと言い続けています。ほとんどのことがそうであるように、正しいやり方を教わっていれば簡単なのです。
ここで、ソフトウェア開発プロセスの歯車がぐらつき始めます。開発者は同じ間違いを繰り返し、SQLインジェクションのような脆弱性が繰り返しコードベースに侵入することになります。しかし、これは驚くべきことではありません。ほとんどのエンジニアは、安全なコーディングについてほとんど何も学ばずに学位を取得します。特に、自分の役割においてセキュリティがビジネス上の優先事項とみなされていない環境では、ほとんどのオン・ザ・ジョブ・トレーニングは不十分なものになります。
開発者がセキュリティに関心を持つ理由や、セキュリティ意識を高めるための強力なプラットフォームが提供されていないのです。劣悪なコーディングパターンがSQLインジェクションのようなバグを存続させています。私たちは、開発者のセキュリティ意識にもっと重点を置き、より高い水準の安全で質の高いコードを書くための時間を与える必要があります。安全なコーディングパターンを書くには時間がかかりますが、そのために費やした時間は、後の工程で非常に重要な効率性を生み出します。
SQLインジェクションの葬儀は行われないのか？
お葬式の例えは少し病的ですが、実際、SQLインジェクションが永久に眠りにつくことができれば、私たちの機密データはより安全になります。なぜなら、予防的なセキュリティの文化や、安全なコーディングの重要性が、棺桶に釘を打ち始めるのに十分なほど進化していないからです。
Rustのようにセキュリティに強い新しい言語は、より安全な関数を利用することで、長い間対処してきたバグを根絶するのに役立っていますが、膨大な量のレガシーソフトウェア、古いシステム、ライブラリは、今後も使用され続け、潜在的な脆弱性を持っています。
簡単な」エクスプロイトを永久に封じ込めるためには、開発プロセスにおけるセキュリティの責任分担（DevSecOps）が重要になります。開発者は最初から参加し、より安全で優れたコードを作成するために自分の役割に責任を持てるようにサポートされなければなりません。
開発者は自分のコードにあるSQLインジェクションのバグをどのように修正すべきでしょうか？
SQLインジェクションの識別と修正方法を学びたい開発者のために、包括的なガイドを用意しました。選択したプログラミング言語（COBOLも可）を使ったゲーム性のある課題が含まれており、すべての開発者がより安全で高品質なコードを作成するのに役立つ基礎的な学習ができます。
目次
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運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
