6 ms·

"Think port scanners, password crackers, vulnerability identification and exploitation tools. Any reasonable person would consider these to be 'hacking tools'"

"Think port scanners, password crackers, vulnerability identification and exploitation tools. Any reasonable person would consider these to be 'hacking tools'" 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!

aes256 14y ago
> 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.
- Craiggybear 14y ago
  There are no legal definitions for being a programmer. There are for being a medical practitioner or a civil engineer. Only practising doctors who are certified to practice may prescribe. Only legally certified civil engineers who after prerequisite training and certification are permitted to handle high explosives and blow things up. Having a degree alone in either of those two professions does most certainly NOT on its own qualify you to do either. Or anything much. So maybe a bad example. 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.
- mjwalshe 14y ago
  that's probably what they want
- nitrogen 14y ago
  The problem with regulating possession of specific kinds of software is that they are entirely a product of the mind. You need specific precursor materials to create explosives and controlled substances, but anybody can imagine and create a good system administration tool. 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.
munin 14y ago
port scanners, password crackers, vulnerability identification tools, all have legitimate system engineering uses. 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?
- ktizo 14y ago
  "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.
  - Splines 14y ago
    > 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.
    - ktizo 14y ago
      Huh? Same as what? We are talking about 0-day vulns. By definition if you think you have found a 0-day, you have little to compare it to. 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.
    - lawn 14y ago
      More like shooting a dummy in the foot? How is this even a valid comparison?

aes256 14y ago

> 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.

Craiggybear 14y ago
There are no legal definitions for being a programmer. There are for being a medical practitioner or a civil engineer. Only practising doctors who are certified to practice may prescribe. Only legally certified civil engineers who after prerequisite training and certification are permitted to handle high explosives and blow things up. Having a degree alone in either of those two professions does most certainly NOT on its own qualify you to do either. Or anything much. So maybe a bad example. 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.
mjwalshe 14y ago
that's probably what they want
nitrogen 14y ago
The problem with regulating possession of specific kinds of software is that they are entirely a product of the mind. You need specific precursor materials to create explosives and controlled substances, but anybody can imagine and create a good system administration tool. 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.

munin 14y ago

port scanners, password crackers, vulnerability identification tools, all have legitimate system engineering uses. 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?

ktizo 14y ago
"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.
- Splines 14y ago
  > 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.
  - ktizo 14y ago
    Huh? Same as what? We are talking about 0-day vulns. By definition if you think you have found a 0-day, you have little to compare it to. 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.
  - lawn 14y ago
    More like shooting a dummy in the foot? How is this even a valid comparison?