ポリシー委任のジレンマ
セキュリティポリシーを作成する場合、ユーザー（ベンダーの可能性もある）の能力/能力を考慮に入れて、ポリシーの特定の義務を果たしますか、それとも厳密に強制することを望みますか？
私がこの質問をするのは、作成されたステートメントの一部が少し厳しい（たとえば、最小パスワード長を12以上に設定するなど）ので、このジレンマに見舞われており、ポリシーステートメントを適用する人がこの時点では達成できない（非常に優れたセキュリティ設定をしていない小規模なベンダー/ユーザーの可能性がある）。
更新：
混乱してごめんなさい。私の方針には、ドラフトにすぎないため、現時点ではアウトソーシングの一部が含まれる場合と含まれない場合があります。私が尋ねた質問は、ユーザー/ベンダーが達成できることに基づいてポリシーを作成するのか、基本的にフートを与えずに厳格なポリシーにするのかということです。そして、それが重要なシステムであるなら、それでもなお例外なく認めるべきです。実質的には、「全員がしなければならない、私は気にしない」という考え方です。物事が起こったときに誰が非難されるのですか？セキュリティチームですね。
これについて AviD を引用するには：
使いやすさを犠牲にしてセキュリティはセキュリティを犠牲にして来ます
セキュリティポリシーを達成するのが難しいと、人々はそれを無視するか、または精神にではなく手紙にそれを果たす抜け穴と回避策を探します。したがって、意図したものとは逆に到達し、セキュリティを弱めることになります。
そのためのセキュリティポリシーは次のとおりです。
- 解決策を強制するのではなく、問題に対して人々を敏感にすることを目標にします。
- 盲目的に指示に従うのではなく、優れたセキュリティを維持する責任を負うように人々を励ましてください。
- ほとんどのポリシーはSHOULDポリシーであり、MUSTポリシーではないので、正当な理由がある場合に人々は分岐できます。
- セキュリティとユーザビリティの間の妥当な妥協点を見つけてください。
Anecdote：私の友人は、非常に厳しいパスワードポリシーでシステムを管理するチームで働いていました。定期的なパスワードの変更、最小の長さ、数字、小文字、大文字、特殊文字の使用を義務付けただけでなく、パスワードが以前と似すぎないようにする意図を持った長いルールのセットも備えていました。パスワード。その結果、人々はこれらの厳しいポリシーに適合するようにパスワードを作成しようとしたオフィスの周りにゴミ箱やゴミ箱に紙を見つけることがよくありました。パスワードポリシーのおかげで、ごみ箱ダイビングでパスワードを取得するのは途方もなく簡単だったでしょう。
多くのポリシーを書いた人からのアドバイス：
ルール＃1
これは最も重要なルールです。実際には、他のプロセスを開始するための要件です。あなたの経営チームがポリシーを支持するつもりがないなら、それはあなたの時間、会社の時間、さらにはユーザーが何かを制定する時間の価値はありません。私はあなたのCレベルについて話している、彼らがボード上にない場合は、ここで停止します。あなたの精神的な苦痛を保存します。
ポリシー、標準、手順、ガイドライン
それらの間には劇的な違いがあり、あなたはそれについて読むべきですが、要するに：
- ポリシー-なぜこれが必要なのですか？
- 標準-これには何が必要ですか？
- 手順-これをどのように実行しますか？
- ガイドライン-ベストプラクティス、重要な脚注など.
ポリシーは目標です
ポリシーは、会社で目指していることです。ただし、常にポリシーの目標を達成できない場合があります。これらを例外と呼び、通常、要件を満たさないリスクを分析するチームが存在します。一部のビジネスは、無意味なセキュリティポリシー（非常に悪い）に例外を設けることができます。他の企業は非常に厳しく規制されており（バンキングを考える）、ポリシーを満たさない場合、企業の運用に大きな影響を与える可能性があります。
ユーザーは重要です............ ish
組織が大きくなるほど、ユーザーが増え、意見が増えるほど、変更が難しくなります。あるレベルでは、従業員の助けを借りて経営陣が変更を行います。小規模な組織では、従業員が経営者の承認を得て制定する場合があります。これは同じように聞こえますが、相互作用によっては非常に異なる場合があります。
情報セキュリティは、通常、他のグループに義務を順守するよう強制しているという単純な事実のためのポリシーにかなり厳しい時間を費やしています。大企業では、パスワード要件などのポリシーを強制することは何かではありませんISは実装を担当します。通常、これはOPSチームまたはアプリケーションの所有者です。
誰もがポリシーを必要とするわけではありませんが、ポリシーに影響します
アカウンティングのジェニーは、サーバーがTLSを実行していることを確認したり、アカウンティングアプリケーションに最小パスワードを実装したりするために、ITのフランクが情報セキュリティのポールによって要求されることを気にしません。ジェニーは、ポリシーがなく、魔法のような1日のジェニーのパスワード1234が8桁の英数字である必要があるかどうかを気にします。これはポリシーではありません。これはインパクトであり、あなたはそれへの対処の一部であってもなくてもかまいません。簡単なメモ、HRはあなたの友達です。
ここでは基本的に2つの選択肢があります。1）機能を考慮して例外のプロセスがあるか、2）ポリシーを実装できない人との作業を拒否します。
1）を実行せず、2）を実行できない場合は、ポリシーが紙にのみ存在することを意味します。 2）を実行する力がない場合は、機能を検討する必要があります。しかし、あなたは必要を厳格にする能力を持っていると言うでしょう。ベンダーが最低12文字を実行できない場合は、他の緩和策を考えればそれを受け入れることができるかもしれませんが、非常に深刻な問題に対応したくありません。ハードコードされた管理者パスワード。
目的のポリシーに応じて実行できることの1つは、ポリシーを相互に補完し合うことです。別のポリシーも実装すると、1つのポリシーの実装がより簡単になり、安全性が高まります。
例：パスワード要件のポリシー例を示します。安全な方法で適切なパスワードを作成して保存できるパスワードマネージャーを使用するようにユーザーに要求するポリシーもある場合、ユーザーはシステムをゲームしないので、システムをゲームする傾向が少なくなります。簡単です。
別の例：ユーザーがフロントエンドサーバーでTLSを使用する必要がある場合、一部のユーザーは、有効期限が切れた証明書や安全でない証明書を使用してお粗末な実装を行うことがあります。補足的なポリシーは、Let's Encryptを使用して証明書の処理を簡単にすることです。
同時に使用できるものの1つは、金銭的インセンティブを通じて適切にポリシーを実装するように人々を促すことです。私は、貧弱な仕事をしている人に手数料や罰金を渡すことについて話しているのではなく、特定の数量化可能で公正な目標に基づいて、ライセンスやサポート料金などに小さな割引（1％など）を与えることについてもっと話します。例：TLSが必要な製品を実行しているWebサイトがQualysでAになっている場合（これは簡単に確認できます）、次のライセンスの更新で1％割引になります（あなたがWebサイトを管理している場合を除きます）。もちろん）。
したがって、セグメントは互いに補強し、義務の要求を超えたものに報酬を与えるような方法でポリシーを記述します。
答えは、12文字の制限を設定することを考えている理由によって異なります。
これは、システムが11文字のパスワードで攻撃するのは簡単であり、12文字のパスワードと予測可能な惑星のコンピューティングリソースで攻撃するのが計算上不可能であることがわかっているためである場合は、それを絶対的な要件にします。その制限を実装できない、または実装しない人は、単にあなたのセキュリティポリシーを満たしていません。それだけです。それらの結果は本当に悪いかもしれません（彼らは彼らの製品を売ることができません）、それらは管理可能であるか、またはまったく取るに足らないかもしれません（彼らは12文字の制限以外の何かにセキュリティに依存する異なるシステムを使用しているため、異なるポリシーを持っています） ）、しかしそれらの結果は正当化されるです。
設定する必要がある制限がわからないために12文字の制限を設定し、6はまあまあですが、永久に十分ではないため、2倍にした場合、実際に実装するのに何が実用的であるかを考慮する必要があります。おそらくあなたは人々にあなたのポリシーを使用して欲しいのです（彼らは：不可能な要求で彼らを狂気にさせない従業員である場合;彼らがそれを無視して何の役にも立たない何かを買うCEOである場合）あなたの方針の;それらが別の顧客を見つけるか、または追加の努力をカバーするために彼らの価格を倍増するベンダーである場合）。そのため、ポリシーに恣意的で面倒な要件が含まれている場合、それらのことを不必要に危険にさらしています。
実際には、これらの2つの両極端の間のどこかにいます。しかし、要件を作成する理由がわかったら、次のことを決定できます。
- それは難しい要件です。それを満たさないものはポリシーに適合しません。
- 達成可能であると信じ、それを満たさないことの結果を説明することが推奨されます。
- 半分焼きました。ポリシーを設定する前に、要件を明確にするためにより多くの作業を行う必要があります。
ポリシーの目標も考慮してください。演習の目的が、セキュリティ設定が不十分または平均的なベンダーを使用しないようにすることである場合、サイズが小さいかどうかに関係なく、適切なセキュリティ設定がないベンダーを除外することは利点セキュリティが良好な人のみが満たすことができる要件。ポリシーは人々を導くためのものであり、それを満たすことができない人々を除外するためのものでもあります。
物事が起こったときに誰が非難されるのですか？セキュリティチームですね。
はい、そしてtwoポリシーが失敗する可能性があり、非難される方法があります。これには、後から考えて除外すべきであると気づき、セキュリティ違反で非難される人を含めることができます。それは、後から考えて、それが含まれているべきだと気づき、会社のビジネスを妨害したことで非難される人を除外することができます。重要なシステムは両方の方法を削減します-あなたはそれが安全ではないことを望まないで、そしてあなたはalsoポリシーを満たすのが難しすぎるので決して構築されたくないです。あなたの仕事は、適切で達成可能なものを見つけることです（または、それができない場合は、少なくとも、誰かが作業している制約の変更に関与できるように、なぜそうしないのかを説明することです）。
大規模なセキュリティ侵害は悪いことですが、それが破産よりも本質的に悪い場合、企業は（たとえば）そもそもインターネットに何も接続しないことで「安全にプレー」し、すべてが破綻します。明らかな理由により、これは彼らがすることを選択したものではありません。そのため、ポリシーの規定を正当化する必要があり、正当化は後で確認できるようにする必要があります。これにより、何かがうまくいかなくても、その時点でわかっていたことがわかっていれば、合理的に適切な決定のように見えます。