開発者はセキュリティポリシーの設計にどの程度関与すべきですか？
私は20年以上にわたってソフトウェアを開発してきました。その間、私は専任のセキュリティ専門家によって開発された非常に具体的なセキュリティ要件を持つセキュリティ企業や、セキュリティ要件の概念がまったくない小規模企業で働いていたFortune 100企業で働いていました。
たいていの場合、ほとんどの場合でさえ、事実上のセキュリティポリシーはほとんどプログラマーによって偶然に作成され、最終製品に緊密に統合されるように思えます。ほとんどの企業は、何かを購入し、デフォルト/ハードコーディングされたルールが何であれ、それ以上考慮せずに使用しているようです。
私の質問は、完璧な世界では、エンタープライズアプリケーション開発者のソフトウェアのセキュリティポリシーを決定する上での役割は何であるべきかということです。製品は鉄壁の「ベストプラクティス」を実装するか、構成可能であることに焦点を当て、消費企業/組織が独自のポリシーを決定できるようにする必要がありますか？
（ここでは、2要素認証が必要かどうか、パスワードの複雑さの要件、タイムアウトの期間、ロックアウト前に入力できる不正なパスワードの数などについて話しています。）
編集：
繰り返しますが、私はXSSやSQLインジェクションのような実際の脆弱性についてではなく、ポリシーについて話しているのです。たとえば、自分のコンテキストに対して十分な安全性を確保するために必要なパスワードの長さがわからず、パスワードの最小長のコードを処理するのに数時間しか許可されていない場合を考えてみましょう。十分な長さを調査して、自分の決定をハードコーディングしたり、管理者が自分でカスタマイズできるようにコードを記述したりした方がいいですか？
私は開発者でもあります。セキュリティへの情熱があるため、セキュリティに重点を置いていない他の開発者を扱う場合、ダイナミックが少し変わっていることがよくあります。
セキュリティポリシーに関しては、主に3つの制約事項があります。
- 使いやすさ：ユーザーが実際にソフトウェアを使用できること、およびセキュリティ対策によって過度にいらいらしたり遅延したりしないことを確認します。
- 技術：セキュリティメカニズムが適切に実装されていることを確認し、それらが稼働時間、保守性、またはその他の重要な技術的要因に影響を与えないようにします。
- 財務：直接の財務コスト（点滅するライトが付いたブラックボックスの購入など）や追加の工数など、セキュリティ対策のコストが高すぎないことを確認します。
あなたの仕事は、技術的な要素についてのアドバイスと、ユーザビリティへの影響を軽減するための提案方法を含む必要があります。ただし、ほとんど常に有能なセキュリティコンサルタント（有能な運用担当者）が技術的なセキュリティについて同意しない場合は、技術的な判断に委ねる必要があります。案件。困難なハードルを克服しながら、必需品を最適な方法で製品に統合するのはあなたの仕事です。
ソフトウェア開発のセキュリティポリシーへのdirectの関与に関しては、次の要素に大きく依存します。
- 専任のセキュリティ担当者またはチームがあるかどうか。
- 担当しているセクター（PIIまたはHIPAAデータを処理する必要があることを意味します）
- 組織内のどこにいて、変化を起こす立場にあるかどうか。
- 会社がセキュリティにどの程度重点を置いているか。
この質問の興味深い部分は、ほとんどのソフトウェア組織には専任のセキュリティ担当者がいないこと、そして部門がいないことを考えたときに起こります。あなたの会社がそうであるかどうかにかかわらず、あなたはあなたの仕事に適用されるセキュリティ問題とメカニズムの種類について学ぶ義務があります。会社に「セキュリティ担当者」がいない場合、その責任はさらに大きくなります。あなたの仕事の一部は、セキュリティを含む実用的で信頼性の高いソフトウェアを実装することですが、別の部分は、技術情報を管理者に理解できる方法で中継することを含みます。目の前の問題を理解しない限り、効果的にそれを行うことはできません。
つまり、簡単な答えはありません。セキュリティの決定を行い、特定のメカニズムをジョブの一部として実装する必要があります。これは、開発者が行うためです。 どこまで行くかは、個人としてのあなたとあなたが働く組織に完全に依存します。合理的な判断をするためにwhenオーバーライドディレクティブが提供されていない場合は、問題を理解するために作業を行う必要があります。
私は人々をより良いセキュリティ基準に押し上げることに賛成ですが、私は自分の運命をコントロールしたいのです。私の好みは、管理者が自分で選択できる柔軟性を提供するオプションを開発することですが、デフォルトを高いセキュリティレベルに設定します。そうすれば、誰かが興味を持った場合、独自の内部セキュリティポリシーに準拠させることができ、そのまま使用する場合は、高い基準が適用されます。
IMO、「完璧な世界」であっても、プログラマーが関与する必要があります。プログラマーは、ビジネス要件とセキュリティの専門用語を開発者の話に、またはその逆に変換するのに十分な知識が必要です。
簡単に言うと、ソフトウェアがどのように機能するかを正確に理解しているのは開発者だけであり、何かが「翻訳で失われた」可能性があります。少なくとも、開発者（またはコードレビュアー-実際のコードに詳しい人）は、その場で何かがどのように実装されるかについての誤解から、ポリシーを作成する人々がそうしていないことを確認する必要があります。
チームの他のメンバーが間違いを確実に理解して回避できるようにするだけでなく、そのようなポリシー/戦略を導入することで、プログラマーがシステムのセキュリティに完全に専念できるようになります。彼らは、安全なコーディングのやり方を、本来あるべき方法で教えていないだけです。学校、またはオンラインチュートリアルはすべて、物事の方法を示すことから始まります。学習方法がわからないことはあまりないため、not物事を行う。
ITの世界におけるセキュリティの欠陥はすべて、どこかにソフトウェアが存在することによるものです。オペレーティングシステムレベルでは、呼び出すAPI、独自のコードのどこかに、不正な動作の発生を可能にする欠陥があります。それはコードのバグまたは愚かな要件である可能性がありますが、不十分な要件でさえ、それらの要件の仕様に基づいて構築されたコードの欠陥です。
したがって、開発者が関与していることを確認することは理にかなっています-セキュリティについて考えさせるには、andが存在しないことを確認します問題につながる誤解。
開発者として、製品のセキュリティ要件を定義するのはエンドユーザー次第だと思います。彼らは、彼らが直面する脅威の状況と、彼らが対処しなければならないリスクを理解するための最良の場所であるべきです。
つまり、セキュリティ要件をすぐに把握できる完璧な顧客を見つけることはほとんどありません。その時点で、ビジネスアナリスト（開発者、特に製品を深く理解しているアーキテクトを含む）を探しています。これらの要件を導き出すのに役立ちます。
開発者の観点からは、これらの要件を実装するための最良の方法を知ることが鍵となります。安全性の高いソフトウェアの書き方を知っているのと同じくらい重要なことですが、最後に必要なのは、これらすべての素晴らしい要件と設計を破るバッファオーバーフロー/ SQLインジェクションです。
セキュリティ構成可能性に関しては、必要に応じてこれらのセキュリティ制御を緩和するオプションを使用して、可能な限り安全に展開されるように、デフォルトで安全な考え方にサブスクライブします。
ソフトウェアアーキテクトおよびセキュリティの専門家としての私の考えは、開発者が高品質の安全なソフトウェアを設計するためにセキュリティ重視の考え方を持つことが重要である一方で、構成は最終的にエンド企業またはユーザーのビジネスニーズに合わせる必要があるということです。ソフトウェアは、悪意のある振る舞いから保護し、必要であると予想される厳格なセキュリティシステムをサポートするように設計する必要がありますが、セキュリティは、ユーザビリティの必要性とセキュリティの必要性のバランスをとる行為でもあります。開発者は、最終的に製品を使用する企業やユーザーのニーズに最適な正確な構成の詳細について、最善の決定を下すことができない場合がよくあります。
社内で使用するソフトウェアを設計していて、もちろんソフトウェアを実装する前に必要なセキュリティレベルがわかっている場合、この回答は変わります。過度の複雑さにより、さらなるセキュリティホールのリスクを引き起こします。
私はクライアントのためにいくつかのベースラインを書きました。最も重要なことの1つは、それを実装する人々が作成にも関与するようにすることです。彼らが開発者であるか管理者であるかにかかわらず、特にパスワードに関しては、（部分的な）同様のセキュリティポリシーが必要です。
あなたが彼らを巻き込むとき、あなたはそうするでしょう：
- 彼らが定期的に直面する入力と問題を取得します。これにより、簡単に範囲を定義し、新しい洞察を与え、セキュリティの観点から問題を解決するのに役立ちます。
- 彼らはそれを自分たちのプロジェクトと少し考えており、彼らはポリシーをより簡単に採用して受け入れるでしょう
- 彼らは質問がある場合、彼らははるかに速く彼らに尋ねるでしょう、そしてあなたは彼らにアドバイスを与えることができます
- 彼らはあなたがセキュリティポリシーを作成している理由を受け入れて理解しているので、彼らは同様のセキュリティプロジェクトをより簡単に促進または要求するかもしれません
完璧な世界では、チーム/会社は、安全な開発ライフサイクルなどのガイドラインに従い、仕事の分野に応じたさらなる制限（法律/コンプライアンスの制限などの影響を受ける）と組み合わされます。
ここを見ると： http://www.Microsoft.com/security/sdl/discover/implementation.aspx 非常に技術的に、すべての人が関わっていることがわかります。
通常、これらのガイドラインの実装を監督し、開発者からフィードバックを収集するスクラムマスターがいます。しかし、それはおそらく「完璧な世界の解決策」ではありません。
パスワードの例に沿って説明します。セキュリティポリシーの実装を監督する責任者は、あなた/チームリーダー/製品所有者に、パスワードには16桁の英数字が必要であり、実装されているかどうか確認する必要があることを伝えます。 。これについて研究するのはあなたの仕事ではありません（完璧な世界）。彼はこれらのもののひどい長いリストを持っているでしょう、実際には:)