カテゴリー

Uncategorized

開発者セキュリティトレーニングの何が問題になっていますか?

  1. HOME >
  2. Uncategorized >

開発者セキュリティトレーニングの何が問題になっていますか?

「開発者をハッカーに変える」というのはよく聞かれる呼びかけです。

バグが少なく、一般的に安全なコードの書き方を開発者に表面上教えるオンラインコースやトレーニングはたくさんあります。トレーニングは、一般的なセキュリティの脆弱性、主にOWASPトップ10リストにリストされている脆弱性の検出と悪用を教えることに焦点を当てています。残念ながら、このアプローチによって、開発者がセキュリティについて考える方法が変わったり、安全なコードを積極的に作成するように促されたりすることはありません。その理由は次のとおりです。

開発者セキュリティトレーニング

ビルダーとブレーカーの考え方

セキュリティの専門家は、脆弱性の特定からシステムの侵害までの道のりが大好きです。バグを悪用可能なリモートコード実行の脆弱性に変えることは、ソフトウェアのセキュリティ評価を担当する人々に喜びをもたらします。

残念ながら、セキュリティの専門家を興奮させるものは、開発者にとって刺激的ではありません。なぜなら、結局のところ、開発者は壊れるのではなく、構築する必要があるからです。

開発者はエンジニアであり、問​​題に対処/解決するプログラムを構築して確認するのが好きです。彼らは橋を建設したいと思っており、制御された方法で橋を爆破する方法にはあまり興味がありません。

セキュリティの脆弱性を見つけて悪用するのは楽しいかもしれませんが、これは安全なコーディングトレーニングの目標ではありません。プログラムを「壊す」方法の例を示す-特定の入力を提供し、それが予期しないプログラム出力をもたらすことの証拠を示す-問題を排除するために対処しなければならない根本的な原因(つまり、セキュリティの脆弱性)を明らかにしません。

これは2番目の問題を引き起こします。

セキュリティバグを他のバグと同じように扱う

私はよく、ディフェンシブプログラミングワークショップで上級ソフトウェアエンジニアの群衆に次のコードスニペットを見せて、「このパッチは何のためにあると思いますか?」と尋ねます。

開発者セキュリティトレーニング

いくつかのヒントがありますが、彼らはそれが悪名高いHeartbleedバグのパッチであることに気づきます。

次に、別の質問を続けます。「このライブラリの他の部分には、他にHeartbleedタイプのバグ(またはバッファオーバーリードバグ)はないと思いますか?」

そして答えは「冗談ですか?」という意味の恥ずかしがり屋の笑顔です。もちろん、あるか、あるでしょう。」

ハートブリードパッチは、セキュリティバグ、すなわち、対処する上での一般的な方法の一例である「if文リリース後の最新のパッチワーク」(ISPRPを)。これは、開発者にセキュリティ攻撃(証拠)とそれをトリガーする方法(入力)を示し、それを修正する方法を理解するために開発者を放っておく例でした。これにより、トリガーを処理するためのコード変更が最も迅速かつ最小になることがよくありますが、残念ながら、根本的な原因はそのままです。

パッチが不完全であったISPRPの他の多くの公開インシデントがあり、それを修正するために多くの試みが行われ、最後に完全なリファクタリングが実行された、機能と見なされました

ISPRPは、より大きな問題の単なる兆候です。開発者は、重大なセキュリティバグを機能バグと同じように誤って扱い、症状を取り除くことでプログラムが「修復」されると信じていることがよくあります。さらに進んでコードベースを調べて同様のバグを見つけ、同じパッチを適用する人もいます。

多くのクラスのセキュリティバグの根本的な原因は、通常、ソフトウェアの設計にあります。私たちのソフトウェアは非常に大まかにモデル化されていることが多く、設計の反復はほとんど行われていません。解決しようとする問題を効果的にモデル化することはできません。したがって、それは本来よりもはるかに多くのことを行います。言い換えれば、私たちのプログラムは強力です。

開発者セキュリティトレーニング

大まかにモデル化されたプログラムには、非決定論的な動作があります。これらの動作により、予期しない実行時例外が発生し、さらに重要なことに、セキュリティの脆弱性である危険な例外が発生します。

開発者セキュリティトレーニング

1つの簡単な例を見てみましょう。

私たちのプログラムが人の年齢を保存するとします。intデータ型は、人の年齢をモデル化するために使用されるのが一般的です。文字列型よりも明らかに制限が厳しいため、これは良い選択のように思えるかもしれません。ほとんどのプログラミング言語のint(つまり、int32)は、-2,147,483,648から2,147,483,647の範囲です。技術的には、負の数または150を超える数をカバーするため、このユースケースには適したデータ型ではありません。つまり、人間の年齢の現実をモデル化していないためです。さらに、エッジケースがあります。ユーザーが2,147,483,648と入力すると、その数値は-1に折り返されます(これは数値オーバーフローの脆弱性と呼ばれます)。

ここで問題が始まります。入力を検証するためにいくつかのif-conditionステートメントを配置することにより、エッジケースに対処しようとします。

開発者セキュリティトレーニング

年齢の問題はなくなりましたか?残念ながら、プログラムは依然として悪い設計に悩まされており、脆弱です。

  • 最初の欠陥validate_ageに渡されたときに入力がすでに整数範囲を超えている場合はどうなりますか?これは、すでにラップアラウンドされた値を検証することを意味します。
  • 2番目の欠陥:これは、大規模なコードベースで、プログラムが大きくなるにつれて発生します。誰かが年齢を使用する新しい方法の前に検証を置くのを忘れています。セキュリティチェックはコーディング規約によって実施されます。つまり、開発チームは、このチェックが欠落しているケースを探すために常に注意を払う必要があります。

根本的な原因は設計上の欠陥です。intは、年齢の大まかな表現です。私たちのプログラムは、そもそもそのような表現が存在することを許すべきではありません。危険な入力をソフトウェアで表現することすらできないため、セキュリティチェックの欠落を心配する必要がないように、安全でない状態を表現できないようにする防御的な設計パターンに従う必要があります。

この例からわかるように、単純な数値オーバーフローの脆弱性でさえ、安全に対処するために再設計が必要になる場合があります。これは、開発者のセキュリティトレーニングでカバーする必要がある重要な部分です。

集中的な練習の欠如

スキルを習得するには、献身と時間が必要です。時にはそれ以上、時にはそれ以下です。スキルを非常に早く習得したいのと同じくらい、これはすぐには起こらないことがよくあります。スキルの基礎を習得するには、習得するのはもちろんのこと、数か月、場合によっては数年かかります。

開発者は、ほんの2、3日のトレーニングの後、安全なエンジニアリングを学び、適用することを期待することはできません。ソフトウェアのセキュリティは複雑であり、使用可能で安全なソフトウェアの構築はさらに複雑です。安全なソフトウェアエンジニアリングは、新しい考え方、モデリング、設計、および実装であり、多くの開発者にとって新しいものです。

私たちの開発者は、ソフトウェアが何をすべきかに集中することに慣れています。安全なソフトウェアエンジニアリングは、ほとんどの開発者が考える方法とは完全に対照的です。それは、ソフトウェアがすべきでないことについてです。セキュリティバグにつながる可能性のあるエッジケースを見つけてセキュリティテストを作成できることは、高度なスキルです。

1回限りのトレーニングを通じて、開発者は一般的なソフトウェアセキュリティのアンチパターンに関する知識を得ることができます。この知識をスキルに変えるには、実践経路を提供する必要があります。これは、セキュリティバグにつながるソフトウェアの非決定的な性質の理由を実践し、完全に理解できるようにする、数か月にわたる焦点を絞った経路です。

要約

私は、効果のない開発者セキュリティトレーニングの問題を、ビルダーとブレーカーの考え方、セキュリティバグを他のバグと同じように扱うこと、集中的な実践の欠如の3つのグループに分類しました。

安全なソフトウェアエンジニアリング文化を作りたいのであれば、まずセキュリティと開発者がプロ​​グラミングについて好きなことを結びつける必要があります。「コンプライアンスの推進」、「内部ポリシーの要件」、「恐れ」などの要因が文化を変えることはないが、開発者にショートカットを見つけるように勧めることは、長い間わかっていました。

私たちはできるの楽しみとして、安全なソフトウェアエンジニアリングを行い、当社の開発チームのためのソフトウェア工学の他の側面として従事します。良いスタートは彼らのテクニックとツールを学ぶことです。そうすれば、私たちの教えを彼らが好きでよく知っているものに合わせることができます。

セキュリティバグへの対処は複雑な作業になる可能性がありますが、幸運なことに、ソフトウェアエンジニアリング業界とコンピュータサイエンスの両方で、同様の問題を解決しようとする多くの優れたプラクティスがあります(たとえば、ドメイン駆動開発は本質的にいくつかのソフトウェアセキュリティの課題に対処します) )。その知識を活用して、セキュリティの問題をどのように解決できるかを開発者に示しながら、その利点をさらに強調することができます。

全体として、私たちが開発者に伝えたい印象は、適切に設計および設計されたソフトウェアも安全であるということです。

-Uncategorized