Think port scanners, password crackers, vulnerability identification and exploitation tools. Any reasonable person would consider these to be 'hacking tools', and that's all a legal system needs for a definition.
But, once again, these are all perfectly legitimate system engineering tools and are essential for hardening commercial or government or military sites, for example. You can't make something secure unless you know how easy or hard it will be to get past that.
It is like making dynamite illegal for civil engineers or morphine forbidden to medical practitioners or hammers and chisels denied to cabinet makers because they might hurt themselves. Ridiculous!
Described in those terms, what would you say to an exception that permitted possession by authorised information security personnel?
That's akin to the legislation we have in the UK with regards to explosives and controlled substances.
But that's a whole different argument. At present it is "programmers" (self-taught or academic or industrially trained) who make things and routinely test them for hardness. You can't suddenly invent rules that say only certain types of programmer may use and deploy "hacking" tools. That won't work because there is no defined path to test suitability or career fitness in the majority of people who define themselves as "programmers". Too broad a church. Too many disciplines and areas of specialisation. And too few people qualified to legitimately or meaningfully assess that either way. Or are we going to say, for example, only Microsoft Certified Pros are allowed to test? God in heaven forbid!
Reputation (from both peers and clients) and demonstrated output that works is the only test for whether someone is a good or bad (read, fit or unfit) programmer.
And no, in answer to your question, we don't allow only certain government regulated individuals to have legal access to perfectly ordinary systems analysis tools. They are probably the last people you want doing it.
There should never be a legal concept of an "authorized" information security person. It's about like defining a concept of an "authorized" painter or musician, since all are talents that can be developed in isolation.
consider the black hole exploit kit, or the poison ivy RAT, or zeus. these are tools that have one purpose: exploit specific vulnerabilities, some of them unreported, and install monitoring software that allows a third party to take control of a system without that systems user or owners knowledge or consent.
surely the number of times that activity is going to be part of perfectly legitimate system engineering would be vanishingly small? when would you need to exploit a 0day vulnerability as part of legitimate system engineering?
When you think you have just found a 0-day in your systems and want to check if you are right or not.
That's like shooting yourself in the foot to see if the bullet hole is the same.
Exploiting a bug on your system to verify that it is a bug that can be exploited would seem to be one of the very first things to do after verifying your backups, if you think you have found a 0-day vuln.
Otherwise, how would you know that it is what you think it is?
There is no general procedure you can run on code to check this for you other than actually checking it and seeing what it does.
If I was running a massive company, I would want my network security team to be buying up the latest cracking tech and checking it against as much of the corporate systems as possible.
Any corporation with any sense and lots of stuff they need to secure pays people to attack their corporate networks with anything and everything available, and then report back.
My first intuition would be all for it, actually. Though there might be some consequences I haven't considered.
For all I know that could already be illegal? Anyone?
Anyone with software affected by a 0-day is effectively a legitimate buyer of that bug.