First of all, we would like to highlight that penetration testing is not the only thing that you need to perform in order to keep your website secure. A penetration test is not designed to protect you from all possible risks that your website faces, so you should always combine it with daily vulnerability and malware scanning, data integrity and threat monitoring.
A good example of a risk that a penetration test is not designed to prevent, and cannot prevent, is compromised webmaster’s PC with stored credentials that will open the door to hackers. This is especially true in large companies, where many different people and teams, including external parties and consultants, have access to certain parts of their website, and it is almost impossible to build 2Factor authentication (2FA) or One-Time-Passwords (OTP) to minimize those risks. Therefore, a compromise of any privileged third party that has access to the website means a compromise of the website as well. Your hosting or cloud provider can also fall victim of hackers, providing them with access to your website. Companies that rent dedicated servers or even racks are not free from these risks either – quite often data centers have web control panels from which servers, routers, and virtual machines can be re-configured. Remote access, blocked from the outside, is usually authorized for the IPs of the datacenter support, opening one more door in case of its compromise.
As you can see, besides your own web application, with its internal vulnerabilities and weaknesses, there are other risk factors to think about. However, by implementing file integrity, proper event and anomalies monitoring you can significantly minimize those third-parties’ risks. Daily vulnerability scanning is also useful to get notifications about the most recent vulnerabilities in your CMS, framework, web server, or any new SSL weaknesses – something that is not yet discovered at the moment of your last penetration test. Therefore, vulnerability scanning, file integrity and anomalies monitoring, and malware scanning should be conducted daily, especially nowadays, when there are lot of free tools and open source applications to do all these tasks in-house to reduce the operational costs.
Another important component of risk remediation is source code review that shall be conducted before web application launch, or after any significant update of the application functionality. Source code review is an essential part of White Box penetration testing, however in this blog post we speak about more budget-friendly Black Box penetration testing. If you can integrate secure coding and regular code review into your SDLC (System Development Life Cycle) – you can almost avoid your spending on source code review by performing this task by internal resources.
We are arriving at the main question of this article: How often one should conduct web penetration testing in order to keep his or her web application secure? If you have to meet compliance, such as PCI DSS requirement 11.3, then you must conduct a penetration test at least once a year. Here is what PCI DSS 3.1 says about penetration testing frequency (section 11.3.1.a):
“Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed as follows:
- Per the defined methodology
- At least annually
- After any significant changes to the environment.”
And here is how PCI SSC defines “significant changes”:
“The determination of what constitutes a significant upgrade or modification is highly dependent on the configuration of a given environment. If an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment, then it could be considered significant.”
At High-Tech Bridge, we recommend conducting web penetration tests before launch of your web application, after its update, and at least once per year in order to test it for new vulnerabilities or attacking techniques that appear publicly almost every month. Of course, each web application and its related business needs are unique, however this timing model can be taken as a basic.