「Secure by Design」を教える
私はセキュリティアーキテクトであり、プロジェクトのセキュリティを他の人が実行する仕様として定義することに慣れています。私は最近、 "Secure by Design"（および近い将来には "Privacy by Design"）の原理を使用して設計およびプログラミングする方法を新しいコーダーに教えることを任されています。私は30〜45分（ええ、わかっています）で、話は言語にとらわれないものである必要があります。つまり、Web開発者、アプリケーション開発者、インフラストラクチャ開発者が適用できるよりも、実用的なルールを提示する必要があります。
私は5つの基本ルールと補足を思いつきました：
- 内部/外部入力を信頼しない（衛生、バッファーオーバーフローなどをカバーする）
- エンティティ、オブジェクト、またはユーザーの最小権限
- 「特権なし」に失敗
- 設計が既知/公開されていても安全
- システムに不慣れな人がすべてのアクションを監査できるようにログを記録する
補足：ルールに違反した場合は、緩和策が機能を追加する将来のプログラマーを乗り越えられることを証明してください。
これらの各ルールは、特定のガイダンスのために、任意の言語またはアプリケーションの例で補強できます。これは、「Secure by Design」の一般的な原則の大部分を高レベルの観点から処理すると信じています。何か逃したことがありますか？
Secure-by-designの概念の標準的なリソースは、SaltzerおよびSchroederによる "The Protection of Information in Computer Systems" です。本質は、安全な設計の8つの原則に蒸留されています。
- メカニズムの経済
- フェイルセーフのデフォルト
- 完全な調停
- オープンデザイン
- 特権の分離
- 最小限の特権
- 最小共通メカニズム
- 心理的受容性
1974年に制定されたこれらの原則は、今日でも完全に適用されます。
30分でデザインの原則を教えるのは難しいでしょう。あなたは彼らを何らかの方法で興奮させる必要があると言う他の人に同意します。脅威のモデリングについて人々を興奮させるために「Elevation of Privilege」カードゲームを開発しました。 （ https://blogs.Microsoft.com/cybertrust/2010/03/02/announcing-elevation-of-privilege-the-threat-modeling-game/ ）
攻撃者のように考える方法を人々に教えることは非常に困難です。SQLインジェクションやクロスサイトスクリプティングのようないくつかの攻撃について教えるのは簡単です。
最後に、原則を教えたい場合は、スターウォーズのシーンを使用してソルツァーとシュローダーを説明する一連のブログ投稿を作成しました： http://emergentchaos.com/the-security-principles-of-saltzer -and-schroeder
ルールに焦点を合わせて「これらの5つのルールを守れば安全です」ではなく、攻撃者とその考え方について開発者に教えることに焦点を当てます。 5つの異なるものを実際にカバーすることはできません。それぞれを実際に適切に実装するにはいくつかの詳細な知識が必要です。
私が話し合った開発者たちは、ハッキングは「本当に難しい」と思っているようで、それがどれほど簡単にできるのか本当に理解していません。したがって、セキュリティを阻止するために人々が実際に何をしているのかを説明することは、目を見張るようなものになる可能性があります。
例：
数年前、私はサードパーティのWebベースのレポート製品をレビューしていました。この製品を使用していくつかのレポートを作成するベンダーの開発者がいました。私はセキュリティと、それが彼らの製品でどのように機能するかについて尋ねました。彼はレポートWebページで「ソースの表示」を行い、すべてが動的HTMLであり、ハッキングされなかった方法を示しました。私は少し戸惑いながら座っていましたが、これは実際に機能するセキュリティではなく、クライアントエンドを信頼できないと言ったのです。
彼は私を信じていなかったので、誰でもこの製品をハッキングする方法を尋ねました。私は少し考えて、ブラウザーをプロキシー・サーバーに接続して、要求/応答が何であるかを調べようと言った。 （今日は改ざんデータプラグインを使用するだけです）。 彼はこれが「世紀のハックだ！」）だと言ったこの時点で、彼の製品は「安全」であるとすでに決定していたので、私はただ敗北に手を挙げた。彼を説得する唯一の方法は、実際に彼の製品をハックすることでしたが、それでも私は製品を購入するつもりはなかったので、私の時間にはあまり価値がありませんでした。
重要なのは、セキュリティの必要性から始めて、私たち全員が何に反対しているかということです。彼らがそれを理解しなければ、それはゲームオーバーです。少なくとも、あなたは彼らに少し恐れを植え付けるでしょう、それは良い動機です。私が見たところ、多くの開発者は実際に「理解する」わけではなく、彼らは最初に何に直面しているかを理解する必要があります。主に、安全なアプリケーションを開発する必要がある理由を理解できるようにするためです。
人々に実際にセキュリティに興味を持ってもらい、それから何かを得るかもしれません。それ以外の場合、35分以内にあなたが提示するものはすべて耳が聞こえなくなるのではないかと恐れています。
最初に彼らの注意を引きたいと思うかもしれません。 SQLインジェクション攻撃のデモはシンプルで理解しやすく、トピックの重要性を強調するかもしれません。あなたがポイントを作るとき、あなたは話を通してずっとそれを参照することができます。
私はあなたが信頼の境界に入るのが好きです。入力検証を使用して、さらに詳しく説明します。最初に長さの検証を行ってから、ホワイトリストとブラックリストについて説明します。不正なデータを自動的に修正しようとすることをお勧めしますか、それとも不正な入力を拒否する必要がありますか？あなたがお勧めする戦略に触れてください。
最小特権に関しては、これは、役割ベースのアクセス制御のアイデアと、ユーザーベースのシステムよりも優れている点を紹介する好機かもしれません。
防御の原則について詳しく説明する機会があると思います。入力のサニタイズは重要ですが、パラメーター化されたSQLを要求することによってコードでそれをフォローアップすると、誰かが入力でボートに乗り遅れた場合でも役立ちます。
ロギングに関しては、ユーザーに表示されるエラーメッセージとログファイルの内容の違いを理解していることを確認してください。また、機密情報を記録していないことを確認してください。
彼らが安全な軌道に留まることを保証するのに役立つ開発プロセスについて議論することも検討してください。ピアコードレビュー、静的コードアナライザー、動的アナライザーの使用が開発プロセスの一部であることを確認してください。これはトレーニングの範囲外ですが、レビューとツールがコードの改善にどのように役立つかを彼らに教えることができます。
30〜45分...痛い。主催者に戻って2〜3日間リクエストして、どのような反応が得られるかを確認できます。または多分10学期プログラム...とにかく、頑張ってください！
あなたは明らかに困難な仕事を抱えており、あなたが言及したことについて話すためのすべての考慮事項はあなたに非常に充実したプレートを与えます。しかし、皆さんの最も人気のある流行語である、頻度が低い実装の多層防御の包括的な戦略に言及またはそれを結びつけることは、できれば、取り組む上で非常に価値があると思います。あるいは、「まともなセキュリティ設計における特定の主要な脅威ベクトルに対するセキュリティ対策の冗長性を評価し、作成する必要性」と別の言い方で言います。
あなたはWebアプリを構築していて、入力からのコードインジェクションの取り組みをすべてサニタイズするための堅牢なメカニズムがあることを確信していますか？それはすばらしい。ここで、創造的な攻撃者が、あなたが考えたこともない実装上の欠陥、本当に厄介で強力なコードが実際のアプリケーションの前に出ることを許す欠陥を見つけたとします。そのシナリオに直面する必要があるかもしれないという考えでアプリロジックを設計して強化していますか、それとも、アプリケーションの前にコードを取得することに対する強力で信頼できる単一の防御メカニズムと見なすものがあるので、それを前提としていますか？あなたは他のことに焦点を移すことができますか？これら2つの選択肢の違いは、多くの場合、堅牢なセキュリティ設計である可能性があるものに到達することと、本質的に脆弱なセキュリティ設計であると思われるものを思い付くこととの違いになるためです。
（注：これを書いているとき、完全な防御として入力サニタイズに依存する例は最良のものではないことに気付いています。現実の世界に今日住んでいるので、有能な開発者はほとんどいないので、堅固で不可解な防御線として、入力のサニタイズとして知られている非常に不完全なものを採用してください。うまくいけば、しかし、あなたは私のより広い要点をとります...）