penetration testing_

A lot of organisations are told that they need a penetration test, but unfortunately, not everyone knows what one is.

But more importantly, not everyone knows how to communicate with management or pen test providers in an effective way, nor do they necessarily understand what it is they’re paying for, and the true value of penetration testing.

What is a network penetration test?

Put simply, a network penetration test is an assessment that focuses on the design implementation and maintenance of a network, and the services hosted on it.

A network penetration test will help you and your organisation to identify misconfigured software, firewalls or operating systems, outdated software and operating systems, insecure protocols, unnecessary exposures, and so on.

The difference between a network pen test, and an application pen test.

An application pen test focuses on the security of any custom code developed and any supporting software (such as third party APIs, SDKs, or imported code for instance), while a network pen test focuses on software that wasn’t written for the organisation, i.e. Microsoft, Apache, and Linux.

In other words, software that’s generic and is available for all users.

So how do we compare the two?
  • A network pen test focuses on the network services on a given IP host or network,
  • An application pen test focuses on coding flaws that introduces vulnerabilities into an application the organisation has written.

On a network pen test, in order to fix issues, you’ll have to install a patch, reconfigure the software, or remove a legacy protocol. Whereas on an application pen test, you’ll have to re-code the application.

Why get a network pen test?

Most IT professionals aren’t security experts. A network pen test will help an organisation to avoid a compromising loss of sensitive data. However, most pen tests are used to achieve a compliance standard, i.e. PCI DSS or HIPAA.

Anything that is storing, processing, or transmitting personal identifiable information (PII) should be tested and maintained.

The best way to do this is to look at the services that support the servers that store, process, and transmit data, i.e. DNS, JavaScript libraries, and anything that provides support to the CDE, or a secure server.

The difference between an automated and manual pentest.

There are typically five steps associated with an assessment:

  • A high-level overview after the automated scans have been completed,
  • Validating the automated scan results,
  • Checking to make sure that the scan results were accurate,
  • Identifying issues,
  • And documenting the findings.

An automated only pen test typically ONLY performs the automated scans. Then there’s the manual element, so there ends up being a hybrid element, regardless.

Application Pen Tests

In an application pen test, people most commonly associate this with web applications. This would involve hitting that web application to look for coding flaws. If you’ve heard the terms SQL injection, cross-site scripting, or privilege escalation, all of these actions are typically associated with a web application assessment that is performed.

But the application doesn’t have to be a web application, it could be a web API, or it could be a custom protocol, or a custom application that they’ve written.

How Long Does It Take?

The average pen test takes roughly two to three days. For bigger organisations, you’re looking at a week or two, weeks or more.

Best Practices

When shopping around for a network pen test, there are four things to consider:

  • Automated versus manual,
  • Comprehensive versus targeted,
  • Evaluating pentest providers,
  • And evaluating deliverables.

Automated is typically cheaper, however a manual will yield more accurate results.

Using Internal Resources For A Pen Test

Pen testing your own software is really difficult, because you’ll have a list of assumptions in your head about the environment.

You built it. You configured it. And whilst that can provide you an advantage, it can also provide some blind spots that analysts aren’t often aware of. So ideally, the tester(s) need(s) to be organisationally separate from what they’re assessing. In other words, using a system administrator that built the environment can be a bad idea.