The Goals of Penetration Testing

Pen testing, although a hot topic, isn’t a new concept nor is it an incredibly difficult one. While the underlying technologies, concepts, and techniques can go very deep, conducting pen testing can be very easy if you’re trained and have the right knowledge.

Protecting assets through pen testing

This list breaks down various security scenarios by industry type:

• The banking industry: Money can be stolen, moved to other accounts, or debt added to others.
• Credit card industry: Identities are stolen and that information is used to penetrate accounts that have monetary assets or credit that can be used.
• The sales industry: Patents can be stolen and products made outside in foreign competitor companies, which causes businesses to fail and stock prices to drop (or rise) based on the intention of the hacker.
• Health industry: Electronic medical record systems can be infiltrated to change, gather, or corrupt info.
• Power industry: The power grid needs to stay online, so the government, private industry, and residents can access energy to carry on daily tasks.
• Military (and other governmental) industries: Secrets need to stay secret and information needs to be protected to prevent harm.

You can be proactive by conducting daily, weekly, monthly, quarterly, and yearly tests to find weaknesses that can be monitored or fixed.

Identifying risks with penetration testing

Risks run the gamut regarding what level of damage might be done if the risk isn’t mitigated properly although you don’t necessarily handle all risks the same:

• A small, identified risk: The risk can be small where you know there is a problem, but you accept its risk because you can’t fix it at this time. Maybe a patch is not yet available by a software vendor and you need to wait.
• An identified risk to monitor: You identify a risk and monitor it, but a penetration and exploitation would lead to very little threat. An example may be hurting the company’s reputation slightly by upsetting a few clients who rely on the systems because they temporarily weren’t available. This risk is low level. There are also other situations where some vulnerabilities can’t be exploited, and it makes sense to monitor them. Other vulnerabilities can be exploited and are of a very high priority (and risk) and, therefore, must be monitored until they’re corrected, which may take some time to accomplish.
• An identified high-risk ripe to be exploited: This risk is likely to be exploited and may cause loss to a company’s finances, high-level reputation, or worse, a loss of life.

A risk register is a list of known risks and vulnerabilities that you compile as you scan, assess, penetrate, and test. The risk register is the official document (or information stored and accessible in a database, spreadsheet, or other facility) that shows the following:

• What risks (and vulnerabilities) you’ve found
• How you may have found those risks
• The weight you’ve assigned to each risk
• A priority level in fixing or correcting each risk

A Risk Register

Testing continues throughout the year(s) — perhaps weekly, monthly or quarterly — to ensure you find all the problems that may have surfaced or been exposed.

Finding vulnerabilities with penetration testing

For example, your hardware vendor updated your firewall, inadvertently introducing a bug. You can be completely unaware of the exploit until either it’s identified by the vendor or another end user, or you run a pen test on your firewall. This doesn’t mean all bugs are exploits, but some can cause and lead to exploits.

Vulnerabilities are a type of risk that can be rated and used as a recorded artifact that can be logged, reviewed, and corrected by people who are responsible for its correction.

• A buffer overflow: Buffers are memory spaces in computers, systems, routers, switches, and many devices in your infrastructure that help to speed up things and make transferring data more efficient. For example, two devices communicating may get impacted by one sending way too much data for the other one to absorb and compute, so it may buffer it (send it into memory, essentially slowing it down for a) moment to let the internal computing of the receiving system catch up.
• Malware: Malware (malicious software) is a type of exploit created by a hacker that can take this seemingly good service and turn it into a vulnerability. If a malicious party now sends too much data to the buffer in an effort to exploit a weakness and overwhelm (or overflow) it, it could cause performance to be impacted or in the worst-case scenario, crash the system or cause it to be unresponsive.
• Password usage: Weak passwords (easily guessed or easily cracked with a password cracking tool) allow immediate entry into a system with the click of the tools button. This is a real-world example of a very common vulnerability, which can be found and prevented by a pen test.

Scanning and assessing with penetration testing

You scan for vulnerabilities on your system, network, or entire enterprise to find risks that you can either fix or acknowledge. The following image shows a scan from Nessus (scanning software).

Sample output from Nessus

Never run a pen test, assessment, scan, or security test on a live production network without permission! Many things can go wrong. For example, you could run a scan on a segment of the network configured with devices to block penetration attempts that shut services off that could impact a production system that’s servicing clients.

Securing operations with pen testing

Responding to incidents

Incident response (which is sometimes called incident handling) is the event management of an attack based on an exploitation of a known or unknown vulnerability. As a security analyst, however, you should know what an incident response team (IRT) is and why it exists.

You might wonder why you’d need a specialized team to handle security-related issues, and the answer is actually very simple: The need is based on containing the incident. Special training is required, and special procedures must be followed for an incident to be handled correctly, as these examples show:

• A need-to-know basis: You don’t want to tip off someone conducting an active attack that you know it’s happening and are watching. To prevent the attacker from knowing their movements are being monitored, who needs to know about the attack as it happens will be restricted to trained individuals who can react appropriately to the incident.
• Containing the chain of custody on evidence: You might also want to control the actual message of the day as the incident could wind up on social media platforms or the evening news. You just never know how an incident may impact you or your organization, so you have specific handling procedures and a trained team in place to handle the details.

What do you do if you have an active incident take place? The answer depends on the following:

• Where you are: Location is everything! If you’re local to the attack you can start to work the issue and can conduct all tests and other actions without fear of being disconnected from the network. If you’re working on a virtual private network (VPN) connection or remotely connected to a system over a network, it may be part of the attack vector and you could become disconnected. Being local to the system allows you console access directly from the system itself and in most cases, this can be the most reliable option.
• Who you are (that is, what role you have): To be designated an active member of an IRT, you simply need to be assigned the role. It may be a full-time role in a larger organization or consulting firms, or in smaller firms you may be assigned it as a collateral duty. Either way, the responsibility is the same and understanding your role and the procedures, processes, and plans are important.The actual team you’re assigned to needs to train together. There is value in understanding everyone’s place on the team and how to handle an active incident.
• What you believe to be happening: Most companies have an IRT that’s responsible for providing support in the case of an active incident handling request, such as a firewall breach, a virus or malware outbreak, an intrusion, or any other security-related matter. What event is actually happening dictates your course of action.