web-dev-qa-db-ja.com

*すべての*あいまいさは議論の対象になりますか?

私は初心者で、「隠すことによるセキュリティ」に対する態度について読んでいます。あいまいさの使用に反対することにはさまざまな程度の猛威があることを私は理解していますが、私はこれがどれほど絶対的であるかを自分自身で明らかにしようとしています。

あいまいさだけに頼ることはかなり満場一致で眉をひそめることを私は理解しています。私は、詳細な防御戦略に追加できる不明瞭なタイプについてのみ説明しています。

たとえば、ICMPエコー要求に応答しないようにホストを構成したり(それが理にかなっている場合)、ネットワークのトポロジやソフトウェアを隠すためにバナー情報をサニタイズしたりすることは、コストのかからない方法のように思えます。私のネットワークを標的とする未決定の攻撃者。

あいまいさは良い考えであると誰もが同意する描写の線がありますか、またはこれらのタイプのあいまいさでさえ落胆するであろう何かが欠けていますか?これらのタイプのあいまいさには、おそらく別の用語またはカテゴリがありますか?

1

理解すべき基本的なことは ケルクホフスの原理 ;敵はシステムを知っています。これは、あいまいさが失敗し、攻撃者がシステムの動作方法についてすべてを知っていることに基づいて作業する必要があることを意味します。したがって、結論として、あいまいさへの依存があってはなりません。

ただし、敵があなたのシステムを知っているのを助ける義務はありません。確かに、あなたが言及する低コストの方法は行う価値があります。あなたはそれらに頼っていませんが、彼らは傷つけず、助けになるかもしれません。

3
Graham Hill

あなたがそれを定義していないので、原則はあなたには不明確です。

良い定義の1つは、NISTによる 少し時代遅れの出版物 ですが:「システムセキュリティは実装またはそのコンポーネントの機密性に依存すべきではありません」。ここでの2つの主要なポイントは、 "depend" "implementation"です。あなた自身の例を見てください:ネットワークのセキュリティがどういうわけかトップシークレットであるすべてのネットワークトポロジに依存している場合、それは悪い設計です。ただし、他の依存関係(ファイアウォール、パッチ管理、暗号化など)があり、トポロジの機密性が要件ではない限り、単にsuggestionを使用すると、強度が向上します。これで問題ありません。

さらに、そのルールでも例外がある場合があります。私が簡単に思い付くことができる1つの例は CAPTCHAチャレンジ これは今日安全です 攻撃者がチャレンジジェネレータ実装のソースコードにアクセスできない場合のみ 。もちろん、これを悪い設計と呼ぶこともできますが、現在のところ、問題の長いリストに対してCAPTCHAよりも優れたソリューションはありません。それにもかかわらず、それはあなたが単に原則を無視するかもしれないという意味ではありません。それとの不一致は完全に正当化されなければなりません。

0
ximaera