Every risk management strategy should emphasise regular security testing of all critical systems: customer facing systems (e.g. mobile apps or IoT devices) as well as connected backend systems, including network components, operating systems, web applications and APIs.
This is necessary to monitor the constantly changing threat landscape and digital risks.
Modern development methodologies (e.g. agile, DevOps aim to integrate automated security testing into the CI/CD tool chain in order to maintain a baseline of security.
It is widely acknowledged that tools contribute to the security process by assisting security experts in their tasks. However, it is important to understand what tools can deliver and what they cannot deliver. And to avoid incorrect use or misinterpretation of results. (see e.g.: OWASP Web Security Testing Guide)
Orchestration of an effective and efficient security testing program, and finding the right balance between automated and manual testing requires expertise and experiences.
Manual security testing includes preventive activities like threat modelling, source code reviews, inspections and reviews, all with a focus on identification of vulnerabilities at the early stage of the development lifecycle. Contrary to this, manual penetration testing focuses on the very end of the life cycle: the release candidate and its environment to be deployed in.
Note that only the final release candidate includes all third-party libraries and components on which it depends. And, only the execution environment will contain the results of a misconfigured and erroneous tool used, which can add an exploitable vulnerability. The release candidate in its environment will be your interface to your users and the first line of defence which will be targeted by adversaries.
Therefore, penetration tests play an important role in security testing programs and management of the digital risks.
Every automated tool has its strengths but also some limitations. The tester should be well aware of what a tool does, what it does not, or what it cannot provide.
Manual penetration testing of backend systems, APIs and web applications continue where automated static, dynamic or interactive tools end: they add the human layer and allow them to think like a creative, experienced attacker.
Our penetration testing team uses its knowledge, experiences and expertise and specialised tools to identify vulnerabilities and develop attack paths that allows gaining access to the assets and data processed in the target systems, network, web application or API.
Since manual penetration testing is a time-consuming activity and requires expertise, eShard recommends performing backend, API and web application penetration tests as a complement to automated security testing.
It is good practice in various industries to perform penetration tests of critical systems regularly, e.g. once a year, and after any significant change, e.g. after major redesign, adding of new functionality or introduction of new tools.
It is the objective of the penetration test to determine the risks and resistance of the systems against real-life attacks.
For this, eShard research team keeps track of the latest attack techniques and tools which enables us to simulate state-of-the-art attackers.
First step and key to successful penetration testing is the definition of the right scope. Without, the project may ignore critical components or include non critical components so that the test results in waste of efforts, time and money, or limitation of relevance of results.
Make sure that the pentest is following a recognized procedure, and that the report is complete and consistent with the procedure.
To ensure the quality of our services, eShard delivers penetration testing projects using the recognized PMI PMBOK® project management methodology. We make sure that your pentest project meets your requirements, is delivered in time, and meets the agreed budget.
eShard provides backend, API and web application penetration testing services customised to your needs and expectations. For this, we will take any specific requirements into account like e.g.: