Network security and penetration testing
What a network penetration test involves: six stages based on PTES and ISSAF, the ratio of manual to automated testing, and the role of reporting and retests.
Published 2 min read
- security
- penetration testing
- PTES
- audit
Smaller companies often treat network security as an afterthought, and neglecting it tends to get expensive. Penetration testing is the tool that shows the actual state of things.
Why it is done
The purpose of a penetration test is to identify vulnerabilities in networks, systems, hosts and network devices such as routers and switches before someone unauthorised finds them. The test shows what can genuinely be achieved: where access control ends and whether reaching sensitive data or taking over a system is possible.
The methodology involves a simulated attack carried out in order to:
- identify the vulnerabilities present in the environment,
- determine the level of risk associated with the organisation’s IT systems,
- help remove those vulnerabilities.
One detail matters: the tester should have experience operating networks and systems, not only breaking them. Knowing how environments are built tells you where to look for mistakes.
How a test runs
- Information gathering
- Threat modelling
- Vulnerability analysis
- Exploitation
- Post-exploitation
- Reporting
The scope follows PTES (Penetration Testing Execution Standard) and ISSAF (Information Systems Security Assessment Framework), and includes CDP attacks, MIME testing, DNS enumeration and AXFR attempts, SMTP relay checks, SNMP reconnaissance, port security verification, brute-force attempts and encryption testing.
Manual versus automated
The split works out at roughly 80% manual, 20% automated. Automated tooling is effective in the early phases, namely reconnaissance and initial scanning. Beyond that its usefulness drops sharply, because the vulnerabilities that matter usually stem from the logic of a specific environment rather than from a signature a scanner already knows.
Reporting and retests
The report is the deliverable, but not the end of the work. A list of findings on its own has limited value. What counts is describing how to fix them and verifying that the fixes actually worked. A retest after remediation should therefore be part of the engagement, not a separately priced extra.