The main issue is that these tools induce suspicious behaviors (suspicious network activity, suspicious files, suspicious process behavior, etc.). From a network monitoring perspective, how would you then reliably detect an actual attacker if its activity is just blending in background noise of "normal" suspicious behavior affecting your network and systems?
Providing the right tool for the right people to do their job remains still possible, but this requires a clear definition of the involved tools, people and job so everyone can agree on what a normal and expected behavior is.
This is called a policy.
Such policy would therefore cover domains like:
- The tools: Do you really need to allow your developer and architect to download anything from anywhere from the Internet? Certainly not. You may constitute a list of approved security software downloaded from a trusted source, whose authenticity has been carefully verified, and made available internally to the people really needing them.
- The people: Instead of opening holes in the corporate proxy, having a specific set of tools shared internally from a single location may allow a greater control over the access to these tools. The policy may describe the process which should be followed when someone want to access this repository: who he should contact, what information he should provide, what motive would be considered legitimate.
- The job: Do your allowed developers and architects really need the ability to scan or hack anything anywhere at any time? Here again, certainly not. You will therefore be able to decide from and against which machines the attack scenarios can occur, you may even plan some kind of confined network dedicated to such usage to ensure that the outer network and system will not be affected.
