Why does penetration test indicate (almost) nothing?
I often hear a lot the sentence “we will conduct penetration testing before moving to production and we will be OK”
If you hear this sentence from an IT or information security person — run for your life!
Security is an on-going process, and so is risk management.
There is a place in the lifecycle of a system, where penetration testing has its place, but it doesn’t replace any other security control.
Deploying 3rd party application
If you decided to buy a 3rd party application or a complete “black box” system, where you have almost zero control of the underline software stack, remember the following OWASP Top10 common threats:
Do not leave default settings. Always read the product documentation and try to locate well known misconfigurations such as default credentials, least privilege permissions, unnecessary opened ports, sensitive data traverse unencrypted traffic, etc.
· Using Components with Known Vulnerabilities
All software has vulnerabilities.
Do not assume that just because the software was purchased from a security vendor it is protected from vulnerabilities.
Use vulnerability assessment products, look for old and vulnerable binaries and open-source libraries and if you located such vulnerabilities, either upgrade them or contact the software vendor and ask for upgrades.
Developing your own applications
Most organizations who develop code, fail to embed security controls as part of their development lifecycle.
Almost any self-made development contains open-source libraries.
When was the last time you scanned your code, located 3rd party open-source libraries and decided to break the build process until all vulnerable components will be replaced by an up-to-date component?
Most of OWASP Top10 contains examples of threats that result of lack of security controls.
Penetration testing to the rescue?
You might be asking yourself, why shouldn’t I just wait till the end of the software development cycle or system deployment phase, conduct penetration test and get it over with?
For this you have to understand the limitations of penetration test:
· You will always have limited budget
· You will always have limited time to run a test
· You will always be limited by the knowledge of the penetration tester
· Result of penetration test are only relevant for the current point in time
My 10 cent tips
Don’t begin asking the system owner — “how many pages does the application contains”.
Instead — interview the application owner for what data the system contains, what are the interfaces between the system components or between the system and other systems in your network (or perhaps on the Internet).
Check with the IT team, what components are part of the system (operating system, database, storage, etc.), how does the end-users or system users authenticate to the system, how is the authorization done, are there any logging capabilities, etc.
Use penetration test, only after you made sure the system is deployed in a secured manor, all components are fully patched, security controls (such as firewalls, web application firewalls, IPS, storage authentication, etc.) were embedded and configured correctly and a vulnerability scan was conducted on a regular basis.
Also, there is no replacement for secure development — all patches in the world, will not replace a developer who decided to skip some security controls in-order to save development time.
Only after you have completed all the above steps, only than you can conduct penetration test, as an additional security control.
Additional reading
If you wish to have better understanding on how to embed security as part of a modern development lifecycle (DevOps), read the following article:
https://security-24-7.com/integrate-security-aspects-in-a-devops-process/
About The Author
Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7, with more than 20 years in the IT industry.
You can connect with him on Twitter and LinkedIn.
