プロセスまたはユーザーには、作業の実行に必要な最小限の権限のみを付与する必要があります。 ユーザーの権限は、ユーザーのロールに応じて割り当てるべきであり、他の方法で割り当てるべきではありません。 最小保護ドメインを作成するには、プロセスやスレッドで必要とするときに権限を割り当て、その後権限を削除します。 この原則により、攻撃およびユーザー・エラーによって発生する可能性のある損害を限度内にとどめることができます。

設計はシンプルなものにします。 間違いが少なくなり、不整合が減少し、コードの理解とデバッグが容易になります。

リソースへの最初のアクセス試行だけでなく、すべてのアクセス試行をチェックします。 たとえば、Linuxではプロセスでファイルを開いた後ではなく、開くときにアクセス権をチェックします。 プロセスでファイルを開いている間にファイルの権限が変更された場合は、不正なアクセスが発生する可能性があります。 開いているファイルにアクセスされた場合は、必ず権限をチェックすることが理想的です。 実際には、アクセス権が最初に取得された状況では、このようなチェックは不要なオーバーヘッドであると見なされます。

セキュリティは、隠蔽によるセキュリティなどと呼ばれる、コードの設計や実装の秘密性に依存すべきではありません。 たとえば、システムのバックドアが開いていることの安全性は、その存在を知っていることの安全性と同じにすぎません。 むろん、この原則はパスワードや暗号化キーなどの情報には適用されません。これらの情報は、できるだけ少数の人々の間で共有すべきものです。 このため、多くのセキュアな認証スキーマでは、PINコードやパスワードの情報のほかに、生体認証またはハードウェア・トークンやスマート・カードなどの物理的なアーティファクトの所持にも依拠しています。

コードを、各モジュールで特定タスクを実行するための特定の限定された権限セットを必要とする、複数のモジュールに分割します。 一般に、注意を要する操作へのアクセス権を付与するには、複数の権限が要求される必要があります。 この原則により、職務が確実に分離され、徹底的な防御が可能になります。 たとえば、権限のないメイン・スレッドは、タスクを実行するために特権スレッドを生成できます。 このため、メイン・スレッドへの攻撃に成功しても、システムへの最小限のアクセス権しか取得できません。

システムでは、ユーザーとそのアクティビティを互いに分離する必要があります。 ユーザーはプロセスやスレッドを共有すべきではなく、ユーザー間で情報チャネルを共有すべきではありません。

デフォルト・アクションでは、操作へのアクセスを拒否する必要があります。 操作を実行する試みが拒否されれば、操作を開始する前と同じセキュリティが確保されます。

ユーザーが実行を試みたアクションごとに、ユーザーとユーザーの権限を記録します。 ファイル・システムが一杯になるのを防ぐために、すべてのログはローテーションおよびアーカイブできる必要があります。

セキュリティ・メカニズムはインストール、構成、使用が容易で、ユーザーが回避したいと思わないものにする必要があります。