With many new innovative and exciting application developments under way, both to support the current pandemic and the broader picture, that has been a significant increase in the number of security breaches and attacks.

This week, we’ll focus on ways to reduce the risk of these, while also providing some valuable insight into the security of your development lifecycle.

Penetration Testing is gradually receiving more traction, with businesses of all sizes comprehending their benefit and gaining a realistic understanding of their application security weaknesses, and how to remedy these issues to produce a more resilient product.

READ MORE: Botnets and credential stuffing

When a business thinks of a penetration test for the first time, the first thoughts are often:

Is it necessary? How can I be sure?

Cost – Is it likely to be expensive?

However, this is not always the case. The team performing your penetration test should discuss directly with you to fully understand the necessity and price of your test. Each of these variables will change for each engagement, and it is important to establish these at the beginning.

For a small-scale application test, where customer data is not a concern, the test may be more aimed at the logistics of your application, and how vulnerabilities can be chained together to cause potential harm.

Similarly, if your application boasts a large dataset designed for functionality, the tester(s) will likely focus on attacking your application to retrieve this, simulating a traditional security breach.

In terms of necessity, if your application, service or infrastructure is your core business asset in terms of revenue, resilience or performance, we recommend a penetration test on an annual basis for continual improvement. This remains to be the case for compliance and regulatory needs, especially if your risk-based approach indicates a need for security testing as part of ISO27001.