web-dev-qa-db-ja.com

「ハッキング」サイトおよびツールへのアクセスを制限する

このサイトの投稿からリンクをたどってみたところ、insecure.orgがインターネットプロキシによってブロックされていることがわかりました。

そのようなサイトへのアクセスを開発者や設計者に許可することの潜在的な利点とリスクは何ですか?またこれらのリスクをどのように軽減できますか?いくつかの利点:

  • 開発者やアーキテクトが直面している問題について洞察を与える。
  • 開発者とアーキテクトにシステムの脆弱性をテストするためのツールと知識を提供する

マイナス面としては、これらのツールの一部は危険であり、悪意がなくても悪い事態が発生する可能性があります。私たちが保護しようとしている実際のシステムを開発者が構築していることを考えると、それほどリスクはありません(少なくとも軽減することはできません)。彼らはすでに悪いことをはるかに直接的かつ強力な方法で起こす能力を持っています。

ここで私が考慮していない側面はありますか?

7
JimmyJames

主な問題は、これらのツールが疑わしい動作(疑わしいネットワークアクティビティ、疑わしいファイル、疑わしいプロセス動作など)を引き起こすことです。ネットワーク監視の観点から、実際の攻撃者の活動がネットワークとシステムに影響を与える「通常の」疑わしい動作のバックグラウンドノイズと混じっている場合、どのようにして実際の攻撃者を確実に検出しますか?

適切な人々が仕事をするための適切なツールを提供することは依然として可能ですが、これには、関係するツール、人々、および仕事の明確な定義が必要です。

これはポリシーと呼ばれます。

したがって、このようなポリシーは次のようなドメインをカバーします。

  • ツール:開発者とアーキテクトがインターネットからどこからでも何かをダウンロードできるようにする必要がありますか?確かに違います。信頼できるソースからダウンロードされた承認済みのセキュリティソフトウェアのリストを構成し、その信頼性を注意深く検証し、本当に必要としている人々が内部で利用できるようにすることができます。
  • The people:企業のプロキシに穴を開ける代わりに、特定のツールセットを1つの場所から内部で共有すると、これらのツールへのアクセスをより詳細に制御できる場合があります。このポリシーは、誰かがこのリポジトリにアクセスしたいときに従うべきプロセスを説明する場合があります。連絡先、提供する情報、正当な動機と見なされる動機。
  • 仕事:許可された開発者や建築家は、いつでもどこでもスキャンまたはハッキングする機能を本当に必要としていますか?ここでも、確かにそうではありません。したがって、攻撃シナリオが発生する可能性のあるマシンを決定することができ、外部ネットワークとシステムが影響を受けないようにするために、そのような使用に特化したある種の限定ネットワークを計画することもできます。
4
WhiteWinterWolf