Author: Richard Curteis
What is Penetration Testing?
- What is penetration testing?
- What are the benefits of penetration testing?
- Who conducts penetration testing?
- What risks are involved with penetration testing?
- How is risk managed during penetration testing?
- Where should penetration testing be conducted?
- How often should penetration testing be conducted?
- How to plan and prepare for a penetration test?
These are all questions that I have been asked many times. In this post we will discuss what a penetration test is, what is involved and how to go about arranging a test.
So first things first...
This by no means an exhaustive or complete description of all elements of a penetration test. Rather, it is intended to server as a guide for those unsure of the general elements and requirements for testing, or even for those who looking to ascertain if their organisation requires testing and to what extent.
What is penetration testing?
First of all, penetration testing should be considered a key tool in risk management toolbox. It and information security functions in general exist to support and enable the safe and continued operation of the business and it's mission.
Penetration testing is the assessment of an information system using the same tools and techniques employed by attackers in order to assess security posture and effectiveness of existing controls against attack.
Some definitions of penetration testing will vary but the essence is the same, taking an information system, which could be a web server or even a physical location, and assess its vulnerability to attack using the same tools and techniques a would-be attacker would use. In the case of the server, checking for open ports with tools such as nmap or in the case of a physical location, wandering in dressed as the janitor and trying to sneak into the server room.
What are the benefits of penetration testing?
Penetration testing provides assurance that the security controls protecting a system are effective. It is a verification tool in the risk management toolbox which allows the Chief Information Security Officer (CISO) or information security manager to report, with confidence that configurations or architectures which have been implemented are operating within the acceptable levels of risk.
Where penetration tests do uncover shortcomings or design flaws, the reporting of these issues allows for technical personnel and management to assess the risk posed by the vulnerability as it related to their data and business processes.
Finally, penetration tests and the subsequent reports provide actionable next steps which can be carried out to further enhance the security posture of affected systems.
Who conducts penetration testing?
As the above definition and description may suggest, penetration testing can involve the assessment of systems containing sensitive data, whether that is Personally Identifiable Information (PII) stored in a public sector database or that of a health insurance company; or it may contain sensitive commercial data.
The loss, corruption or exposure of this or other such data could have potentially disastrous consequences for the organisation tasked with it's safeguarding which may range far beyond immediate tangible financial loss and vulnerability to litigation or regulatory body action. For example, Loss of trust by customers could take many years to gain back and is diffcult to quantify with certainty.
Because of this sensitivity, it is essential that penetration testing is carried out by formally trained, qualified and highly experienced IT security professionals who are able to undertake assessments whilst exposing the target system to the minimal levels of risk.
What risks are involved with penetration testing?
Penetration tests, at least in part, involve 'stressing' the controls which have been implemented.
Note: it is standard practice by Realize Security to never conduct denial of service testing unless explicitly requested by the client.
Testing may however involve running a vulnerability scanner or network mapping tool for example. These tools generate high volumes of network traffic and have been known to cause issues with legacy or badly patched systems or systems with limited CPU or RAM resources and may cause downgrades in performance.
Another potential risk encountered may be the locking out of users from their accounts. This can occur when, for example, during an internal network assessment, the consultant performs a password spraying to identify instances where a password has been re-used on different machines.
The risk which is most often queried by our clients, especially in production or other mission-critical systems, is that of corruption of data. This could occur as the result of an issue arising from the above risks or it may occur when a consultant updates data or runs automated tooling that repeatedly does the same.
How is risk managed during penetration testing?
During scoping, first of all it is important for the consultant to receive an accurate description of the system, its function and risks associated with its operation, and criticality to the business.
This will aid them in developing a more informed picture of the assessment within the context of business requirements and effective risk management. This combined with a consultant familiar with the same or similar technologies or scenarios, should allow a professional tester to suggest approaches which provide the required assurance from the client as well as ensuring business critical functions remain active.
This leads us, in part, onto the next question...
Where should penetration testing be conducted?
In general terms, this is a question of risk management. Where possible, we tend to recommend that testing occurs in non-production, non-critical testing or pre-production environments where any updates to data or slowdown of systems will not have an adverse effect on operations.
Of course this is not always possible, for example within corporate networks or perhaps for applications where no staging environment exists. In these instances, a conversation should be had between client and tester to ensure business operations are unduly hindered. This can potentially be achieved by minimising certain types of testing, setting certain domains, subnets or endpoints out of scope or conducting testing out of hours.
How often should penetration testing be conducted?
This will depend on a number of factors but will primarily be driven by your organisation's security policy as well as factors such as budget and risk profile. We tend to argue though, that a system should be subject to penetration testing at minimum annually or to validate integrity following any significant updates or changes.
The frequency could of course be higher, for example bi-annually or quarterly.
Note: This frequency does not take into consideration 'shift left' and DevSecOps practices that integrate security early and continuously into the development, release and operations lifecycle.
How to plan and prepare for a penetration test?
As with anything, the first question should be, what are you trying to achieve? What is the reason for requiring a penetration test? This could be driven by internal policies, compliance requirements or legal or contractual obligations. An example of the latter could be if you provide services for local government.
Once you know this you can start thinking about what you are intending to test. Servers, APIs, web applications, IP ranges etc. BeThe below points are typically the critical success factors in
The above will help you to define what is in and out of scope. I.e., what you want and do not want to test.
How will testers access the target? Is it on the internal LAN and therefor requiring VPN access or an on-site visit?
Accounts and Authentication
- How will the testers log in to the application?
- Do accounts need to be provisioned for them and what is the lead time for this from your IT team?
- Will the testers accounts need specific permissions?
- Is Multi-Factor Authentication (MFA) required?
A common hold-up when carrying out penetration tests, especially for APIs, is a lack of example requests (ask your team about Postman and Swagger files) and examples of valid data that applications will accept in order to test the functionality.
Hopefully that has shed some light on what penetration testing and the purposes for its inclusion within your risk management activities and the benefits available. If you have any further question or would like to enquire about Realize Security's services, please get in touch for a chat and to see how we can support your business.
Thanks for reading.
The Realize Security Team