隠れチャネルでのデータ漏えいを検出するための適切なメトリックは何ですか？
攻撃者が侵害されたシステムから外部ネットワークまたはインターネットに機密データを漏出できるシナリオを考えますが、TCPに基づくアプリケーションレイヤープロトコルでの接続を許可しないように送信接続が構成されているため、これを達成する方法は限られています。攻撃者は、構成で許可されているデータをDNS経由で漏出することを決定しました（はい、これは間違いです）。
私の意見では、この種の流出を検出するには2つの方法があります。
- コンテンツベース：機密データや、ファイルの署名、ヘッダー、ファイルのプロパティなどを見つけるために、転送されたデータのコンテンツを検査する必要があります。
- ボリュームベース：データ量は、データ使用量ベースラインと比較する必要があります。現在のデータ量（ある時間内）がデータ使用量のベースラインよりも大きい場合、w00t w00t！
これらは私の質問です：
- このようなシナリオでデータの引き出しを検出する他の効果的なソリューションはありますか？
- ボリュームベースの検出について、データ使用量ベースラインを計算するための推奨事項はありますか？ 1か月の平均データ使用のみで十分ですか？
well構成では、最初からDNSおよびICMPを阻止するプロキシを使用してネットワークアクセスが制限されるため、DNSおよびICMPは良い例ではありません。
ただし、プロキシを介してまだ利用可能なHTTP（S）があります。
通常、ウェブサイトはプロキシでホワイトリストに登録されていないため、これは非常にうまく機能するはずです。
コンテンツ検査について：
一般的にそれを行うことはできません。 MITMを実行するHTTPSプロキシがある場合でも、HTTPSのトランスポート内でリクエストペイロードが暗号化されている可能性があり、キーワードをスキャンできません。
さらに、規範的な規制により、銀行サイトなどのMITMによる検査が許可されない場合があります。
ただし、暗号化されたペイロードストリームをHTTP（S）トラフィックで見つけて分析し、その間に宛先ホストをブラックリストに登録することができます。
ボリュームベースの漏洩検出はDNSおよびICMPには適切な計画のようですが、HTTPSの場合、正当なトラフィックがしきい値を超えて多数の誤検知が発生し、場合によってはビジネスが中断する可能性があるため、そうではありません。
データを安全にアップロードできるドメインのホワイトリストがあれば、組み合わせたアプローチが機能する可能性があります。大量のデータがプロキシ経由で送信されていることがわかった場合、宛先がホワイトリストにない場合は宛先をブラックリストに登録して分析できます。トラフィックを手動で。引き出したデータのサイズが小さい場合でも、取得できない可能性があります。
結局のところ、それは秘密の窃盗の問題です。それはよく隠されています。