oh come now, you just posted that so that I would continue to read this site even though I see no content day after day...
Dr. Neal Krawetz
· 1 year ago
"Seven Deadly Pen Test Sins"? You have a good list, but what about:
- Get it in writing. If you don't have a written agreement to do the testing, signed by someone with the authority to grant permission, then don't start. (Don't do the crime if you can't do the time.)
- Scope and Target. You brushed this topic in 1, 2, and 7. Basically, you need to know what to look at and what to look for. It's great to identify that they are using an F5 load balancer and showing that there is an inherent vulnerability in them. But unless the customer is F5, there is no point in doing a deep pen-test of the load balancer.
- No plan. A good pen-test should end with a map of the system, dependencies, etc. If you're testing a network, then there should be a detailed map of the network discovered by the pen-tester. If you're testing an application then you should have a design architecture as seen by the pen-tester. Without this, the customer will know that the tester was just bouncing around from random exploit to random exploit.
vitaly
· 1 year ago
bobdole: Well, that's what RSS feeds are for ;)
Great post, though I think because I try not to be guilty of #5 I become guilty of #1.
sigsegv
· 1 year ago
Dr. Neal Krawetz: I'm going to have to disagree with you here. I've had more success with semi-randomly going through a network letting my intuition guide me rather than following some overly "structured" approach.
For me, hacking is a creative process rather than a 9 to 5 day job.
vitaly
· 1 year ago
sigsegv: I think you're right, but there are also multiple approaches to pen-testing. Some people spend months at one client, meticulously mapping a network. Others, due to various factors, spend a week and have to take a less formal approach. I think as long you do your due-diligence in scanning and documenting the network in the beginning (at least as far as IPs/ports), you can responsibly sample and creatively assess it without being too structured.
Tyler Shields
· 1 year ago
This is a fantastic post. I've written before about some of the qualities that make a penetration tester a good one, but over time even an expert can fall prey to the problems you listed out. Even the best can get lazy.
Sven Weizenegger
· 1 year ago
@sigsegv
in term of QA is the pure hacking (more chaos related ;)) the wrong approach. a good pentester should work with prepared checklist (testcase description., passed/failed criteria) and a well defined method and more structured (reusability and repeatability ). no one says that a pentester with a QA background cant hack with creativity...
to point number 7: a pentest should understand and explain the BUSINESS IMPACT of a vuln.
;)
Swage Machine
· 4 months ago
Nice post Dave.. Even a professionals are having a hard time to this..
All Comments
- Get it in writing. If you don't have a written agreement to do the testing, signed by someone with the authority to grant permission, then don't start. (Don't do the crime if you can't do the time.)
- Scope and Target. You brushed this topic in 1, 2, and 7. Basically, you need to know what to look at and what to look for. It's great to identify that they are using an F5 load balancer and showing that there is an inherent vulnerability in them. But unless the customer is F5, there is no point in doing a deep pen-test of the load balancer.
- No plan. A good pen-test should end with a map of the system, dependencies, etc. If you're testing a network, then there should be a detailed map of the network discovered by the pen-tester. If you're testing an application then you should have a design architecture as seen by the pen-tester. Without this, the customer will know that the tester was just bouncing around from random exploit to random exploit.
Great post, though I think because I try not to be guilty of #5 I become guilty of #1.
For me, hacking is a creative process rather than a 9 to 5 day job.
in term of QA is the pure hacking (more chaos related ;)) the wrong approach. a good pentester should work with prepared checklist (testcase description., passed/failed criteria) and a well defined method and more structured (reusability and repeatability ). no one says that a pentester with a QA background cant hack with creativity...
to point number 7: a pentest should understand and explain the BUSINESS IMPACT of a vuln.
;)