Pen Testing & Scanning for Vulnerabilities: Differences & Methodologies

Written by

The rate of hacking attacks is rising every year, and at the same time the actual number of individual businesses being attacked is going up. The question of how to protect a business and prevent attacks at a time when we are paying ever more attention to personal and confidential data protection has never been more important.

Alongside security information and event management systems for security event analysis purposes, we also have other resources to protect against IT invasion. Penetration tests and scanning for vulnerabilities are among them, and it is these on which I would focus.

The Differences between Penetration Tests and Scanning for Vulnerabilities

The two terms are often confused or used interchangeably, so we should define them at the outset.

Penetration testing (or pen testing) is a process aimed at practically assessing the current state of system security by attempts to find new vulnerabilities and the adoption of known weaknesses to verify whether they are real threats. By comparison, vulnerability scans are based only on databases of known weaknesses. Results, generally in the format of a report, present vulnerabilities grouped by their severity and proposed remedial action. It is good practice (and most often a prerequisite) to perform a vulnerability scan before a penetration test.

Another difference is that vulnerability scans can be fully automated, using only software tools and a defined scan range, whereas penetration test must be performed partly manually and require a lot more knowledge.

"Vulnerability scans can be fully automated, using only software tools and a defined scan range, whereas penetration test must be performed partly manually and require a lot more knowledge"

Pen Tests: Methods and Methodologies

There are three main methods of penetration testing. These are back-box, white-box and grey-box. Their main differences are based on the tester’s knowledge of the environment in which the controlled attack is performed. Black-box tests either deliver only superficial information about systems, infrastructure, security procedures, etc., or don’t provide these at all. This approach is very time-consuming and costly because of the need to gather all required information and analyze it.

The White-box method is implemented in cases when the tester has almost full knowledge about the systems and infrastructure on which the attack should be simulated. This approach simplifies the task greatly and reduces costs, but makes has little in common with the implications of a real attack. In conclusion, the advantages and disadvantages of both are of equal weight.

Is it possible to find a golden mean here? Probably not, but in my opinion the grey-box approach is close. The tester receives basic information about the target of the attack (unlike in the black-box approach), which reduces the time needed to gather information and narrows the scope of the test. The remaining assumptions will be reached during consultation with the client and dependent on many factors, such as whether social engineering, denial of service or destruction tests are to be used.

"When we have chosen the method matching our needs and resources, the next question to be considered is which methodology should be applied"

When we have chosen the method matching our needs and resources, the next question to be considered is which methodology should be applied. The decision can be difficult because each company, network and system is different, but the choice will depend mainly on the assumptions of the test and its objectives. Among the many methodologies available are NIST SP 800-42 (which provides guideline on network security testing), NIST SP 800-115 (for information security testing and assessment), and ISSAF (orientated towards systems security), but there are also open source methodologies.

For web applications and services testing, OWASP methodology can be a good choice, while OSSTMM can be used for tests focused on a company’s entire telecommunication and network infrastructure, including security of physical locations and employees security testing. In all cases, it should be noted that theoretical analysis contained in each methodology is helpful for procedure purposes, but does not provide tools and ready-made solutions to guarantee successful tests.

Good Practices for Pen Tests

  • Set clearly defined goals
  • Consult the customer about the scope and methodology, then adjust the time-frame to fit these precisely
  • Try to take on the role of an attacker, and think like one
  • Ideally, vulnerability scans and risk analysis should precede pen tests, and all impacted systems and applications should be updated to the latest available versions before work begins, so as to reduce the number of known weaknesses and test systems in the latest compilations
  • Use software tools for tests which require multiple attempts and repeated changes (such as query parameters). This will save time for tests that need to be performed manually
  • Seek quality, not quantity, in your testing and results

What’s hot on Infosecurity Magazine?