私たちはHIPAAに準拠しているはずの組織で働いています。セキュリティは私たちにとって大きな関心事です。私たちは、ネットワークで匿名プロキシを使用しているユーザーがいないかどうかを調べる任務を負っています。
Tor が企業ネットワークドメイン内で使用されているかどうかを確認する方法はありますか?シマンテックのクライアント保護を使用しています。 VPNはシスコを使用して提供されます。
Tor(アップリンク)ノードの list を使用し、これを送信ファイアウォールに追加し、これを1日に1回更新するタスクを設定すれば、問題ありません。ただし、TorはHTTP(S)プロキシ経由でも使用できるため、プロキシも検出する必要があります。
これが何かを確保するのに役立つかどうかはわかりません。インターネットに接続されている限り、この種のセキュリティ対策を回避することは可能です。あらゆる種類のプロキシ、VPN、SSLトンネルなどを禁止するために、無限の時間とエネルギーを費やすことになります。アドバイスは、あなたのビジネスにとって重要なものを保護することにより、彼らが害を及ぼさないことを確認し、ユーザーを残すことです。たとえば、コンパートメントでネットワークを分離し、サブネット、VLAN、DMZを使用して、プライベートネットワークでの認証と承認を要求します。重要なものを1つのゾーンに保持し、別のゾーンに制限なしでネットワークを許可します。等々...
私はあなたの主な関心事はそれであると信じています:
ネットワークで匿名プロキシを使用する
悪い仮定です。私はすぐに尋ねます:
どのネットワークで?
Yorick はすでにこの点に触れましたが、私はもっと露骨になります。
HIPAAは、主に本番システムのデータのプライバシーに関するものであり、したがって、本番システムへの接続に使用されるネットワーク内のデータのプライバシーに関するものです。このネットワークに接続しているallマシンが実行できる処理を制御する必要があります。つまり、これらは会社が管理する会社のマシンであり、生産システムを処理するために必要なソフトウェアを提供する必要があります。他のマシンはこのネットワークに接続できません。これには、本番ネットワークへのVPNが含まれます(可能な場合は回避することをお勧めします)。
本番システムに接続しない従業員用のネットワーク。 開発ネットワークまたはoffice wifiは本番ネットワークから分離。ネットワークが分離していることを明示するだけで十分です(別のハードウェアを使用することをお勧めします。802.1QVLANは、構成が適切でない場合、いくつかの攻撃の対象になります)。これらのネットワーク内のマシンは、決して接続しない限り(そうすべきではありません)、本番システムに関係ありません。何かを本番環境に移行するには、コード/構成/その他の変更のセキュリティが評価されるQA/QC手順が必要です。
開発マシンを含む開発ネットワークが本番データを見ることは決してないことに注意してください。運用データを保護する場合(HIPAAのように患者のプライバシーを保護する場合など)は、開発/テストのセットアップですべてのデータを匿名化する必要があります。セキュリティで保護された本番環境を用意してから、セキュリティで保護されていないネットワークに本番データをダンプするのはばかげたことです。
Torがネットワーク上で使用されていないことを比較的確実に確認できる唯一の方法は、ネットワーク上のすべてのデバイスを検査し、Torがそれらのデバイスにインストールされていないか実行されていないことを確認することです。これは非常に多くの工数を必要とする可能性があり、それも不可能である可能性があります。とにかく見逃すかもしれません。
attemptして、すべてのTorがアクセスする ハードコードされたディレクトリ認証局 へのトラフィックを監視することにより、Torの使用を検出できますクライアントは常に接続します(例外を除き、以下を参照)。通常、これらの数は12未満です。
何千ものガードノードのいずれかへのトラフィックを検出しようとすることもできますが、IDSに大きな負担がかかる可能性があります。ディレクトリ機関のトラフィックを検出するには、いくつかのIPのみを監視する必要があり、アイドル状態のクライアントであっても、これらの機関へのトラフィックは存在します。
大きな例外は、Torがブリッジを使用するように構成されている場合です。これらは、Torが通常のTorノードまたはディレクトリ認証局と直接通信しないように明示的に設計されています。代わりに、非公開のブリッジアドレスと通信します。国家はこれらのつながりを検出するのが難しい。ネットワークで使用されている場合、ほとんどチャンスはありません。
代わりに、あなたがすべきことは、一般に、ネットワークへのアクセスとネットワークからのアクセスをより慎重に制御することです。 PHIがアクセスまたは保存される可能性のあるすべてのデバイスとの間で、実際に必要なトラフィックのみが許可されます。これは、PHIが他のネットワークから存在している場合、ネットワークを双方向方向でデフォルトで拒否し、ネットワークを分離する必要があることも意味します。現在のファイアウォールの下りポリシーはdefault-allowであり、default-allow構成でブロックすることは空に穴を開けるようなものです。
会社が承認していないソフトウェアをユーザーがインストール/使用できないようにするには、従業員のマシンにソフトウェアポリシーを適用し、ポリシーに準拠したマシンだけがネットワークにアクセスできるようにするなど、ネットワーク認証を組み合わせれば十分です。これにより、ワークステーションは単純なkiosk
マシンになります。金融およびヘルスケア業界では、運用中の従業員にキオスクモードを適用することを不適切と見なすべきではありません。
ブラウザ(例:onion.to proxying)が脅威の一部ではない場合、Torに接続する可能性のあるソフトウェアを実行できないことが、ユーザーがTorを使用できないようにする鍵です。しかし、通常は、保護された環境で利用可能なサイトのホワイトリストに登録されています。
これは、現実の世界では、ITスタッフのニーズと衝突することがよくあります。ほとんどの企業では、必ずしもソフトウェア開発者/エンジニアとは限らないITが、ソフトウェアを実行したり、カスタムスクリプトを作成したりする能力が必要です。議論のために、そうだとしましょう。
もちろん、システム管理者がTorを実行するのを防ぐことはできず、その「脅威」のためにマシンをキオスクにロックすることもできません。そうしないと、マシンやネットワークの問題の修正など、異常なアウトプロセスアクティビティを防ぐことができます。この場合、特権ソフトウェア構成のsysadminマシンは通常、機密性の低いネットワークに接続され、最終的にはインターネットに接続されるようなポリシーを採用することをお勧めします。保護された情報が保存されている機密性の高いネットワークにアクセスする必要があるシステム管理者は、ラップトップを別のプラグに物理的に接続し、イベントを監査証跡に記録します。そのような監査は、「タスクを完了するために、マシン10.100.200.10
へのアクセス権を取得しています」というサポートチケットへのコメントによっても実行できます。
要するに、誰かがTorを使用できないようにするは、厳格な要件であり、強制することは困難ですが、要件を合理的に再解釈することで、ユーザーはソフトウェアプログラムの最小最小セットのみを実行して、その職務を遂行できる(最小最小特権の原則のバリエーション)。
とにかく、Tor自体は脅威ではありません。これは、インサイダートレーダーや他の不誠実な従業員に悪用されたり、訓練を受けていない既存の従業員にリスクをもたらしたりする可能性がある媒体です。
Torは設計上、ブロックするのが困難です。ヨリックの措置は正直な従業員を正直に保つでしょう。 HIPAAがさらに要求しない限り、私はそのルートを進みます*ブロッキングメジャーに検出を追加することは、Torユーザーを識別し、管理を通過してそれらを統制できることを意味します。私見、この種の行動を禁ずることは、ビジネスポリシーの従業員の年次認証およびセキュリティトレーニングプログラムの一部である必要があります。
必須鉄の拳でルールを適用する場合、デフォルトですべてをブロックし、代行受信プロキシをインストールするのが一般的な方法です。つまり、すべてのクライアントTLSトラフィックを傍受、復号化、検査、分類、および再暗号化することになります。これは、銀行や安全な機関では一般的です...プライバシーへの影響、導入の複雑さ、パフォーマンスの問題に加えて。
*(わかりません...まだHIPAAを行っていません)
タイトルはそのようなアクティビティの検出に言及しているので、ファイアウォールルールをログだがブロックしないさまざまなタイプの既知の匿名化サービス/サーバーへの接続に設定します。これは明らかに、誰かがファイアウォールのログまたは何らかのタイプのフラグシステムを監視することを意味します。
データが流出する可能性はわずかにありますが、誰かがブロックに遭遇した場合、システムからデータを取得するために他のメソッド/サービス(ログインしていない可能性があります)を見つける可能性があります。
制限された量のデータ出力を許可すると、ネットワーク内のターゲットにアクセスして、システムアクセスを監査し、実際に何をしているかを確認できます。彼らの仕事の範囲外にある資料にアクセスしようとするように。
これにより、認証がまだ必要な機密データ(ログインなど)にアクセスできる環境でBYODの問題を回避できるため、何が危険にさらされているかを確認できます。
このアプローチの欠点は、リスクがファイアウォールの監視状況に比例し、フラグが機能するため、利用可能なリソースに実際に依存することです。