Chapter 2
IN THIS CHAPTER
Exploring why pen testing is important
Understanding that pen testing is an ongoing endeavor
Learning who’s bad and who’s good
Pen testers are the cops of the network. They make sure people aren’t breaking rules and getting themselves or others into trouble. Hackers — be they white, grey, or black — are always out there actively trying to thwart security systems and access systems that they shouldn’t be accessing.
In this chapter, I give you the knowledge you need to become the cop of your network: the goals of good pen testers, the importance of ongoing scanning, and how tell the good hackers from the bad.
The ultimate goal to penetration testing is to test your technology assets for their security, their safeguards, and controls by trying to penetrate through any configured defenses. But pen testing can be broken down into individual smaller goals.
Your goal as a security analyst (one of the good guys) should be to keep the bad guys (hackers) out of things that they should not be in. It’s important to protect assets so that they can’t be damaged or corrupted (rendering them unusable), altered (changed), infected (with a virus), stolen, hijacked, or the myriad of other security threats that could happen.
This list breaks down various security scenarios by industry type:
Risk is another important word to define prior to discussing vulnerabilities. What is at risk is the technology that runs much of our world today and the data that resides on that technology. By testing that technology, pen testers can reduce the risk of it being exploited and causing harm. What is at risk is simple… security itself is at risk.
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:
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.
You record all these risks in a risk register and log the results of most security assessments (your pen test results) with a marker denoting the level of risk and the priority in which it should be addressed.
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:
Table 2-1 shows what a typical risk register looks like.
TABLE 2-1 A Risk Register
Risk Register Entry # |
Risk Category |
Risk Sub-category |
1 |
Security |
Virus |
2 |
Network |
Wireless |
3 |
Power |
UPS |
4 |
Environmental |
Fire Suppression |
5 |
Datacenter |
Space |
6 |
Environmental |
Fire Suppression |
7 |
Environmental |
HVAC |
8 |
Security |
Physical |
9 |
Server |
Operating System |
10 |
Datacenter |
Consolidation |
11 |
Storage |
Capacity |
12 |
Storage |
Capacity |
13 |
Security |
HIPPA And PHI |
14 |
Database |
Backup |
15 |
Database |
Corruption |
16 |
Database |
Network |
17 |
Datacenter |
Space |
The risk register is a great tool to help you identify problems, but it would be hard to guess what changes could cause problems, which is why companies have pen testing conducted: to test their systems for weaknesses. A company might have an in-house team doing the testing or outsource to a security firm or individual consultant.
A risk register is a living document that you’re constantly updating. I talk more about it in Chapter 11.
A vulnerability is simply a weakness that can be exploited in your technology or something as simple as information disclosure. The technology weakness can be through misconfiguration of an asset, a bug, or code problem in the software installed, or any anomaly in your enterprise.
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.
Two examples of vulnerabilities are:
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 (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.
A good corporate password policy (with a system that secures and enforces it) is the best chance to protect against this vulnerability. Unfortunately, it’s still common in many places around the world, and I’m sure during your own pen testing, you will find instances of it during your own pen testing.
Chapter 6 covers other vulnerabilities.
The successful pen tester uses tools (both hardware and software) to run penetration tests (sometimes also called penetration assessments) to find vulnerabilities and exploit them.
You scan for vulnerabilities on your system, network, or entire enterprise to find risks that you can either fix or acknowledge. Figure 2-1 shows a scan from Nessus (scanning software), which I cover (along with other tools) more in depth in Chapter 3.
Typical security operations conducted in an enterprise range from simple to complex. It all depends on many factors, including size of the company, importance of the assets, available budget, leadership’s interest in any (or all) of these factors, and the knowledge and skills of those entrusted to secure and keep secure the assets of the enterprise. To do this, you can either conduct your own security assessments, outsource them, and in some cases even crowdsource them.
What if you can see an active attack taking place because of issues you identified through pen testing and which you are now monitoring as part of your ongoing risk assessment? The answer lies in a process or workflow called incident response.
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. In this book, I’m primarily focused on conducting pen tests and how to prevent attacks, so I don’t spend much time explaining incident response or incident handling. As a security analyst, however, you should know what an incident response team (IRT) is and why it exists. That’s what I briefly explain in this section.
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:
Note that one part of containing the event is to provide tangible evidence in a court of law. Should the company decide to take legal action against the perpetrator, documented evidence will be needed.
What do you do if you have an active incident take place? The answer depends on the following:
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.
Obviously, you don’t ever want to have to respond to an active attack. Hopefully, you might be able to prevent it in the first place, and that is why pen testing is so valuable in the entire security framework and defense in depth. If you’re able to secure everything properly or identify any weaknesses and fix them (or accept and monitor them), you solve half the exploit battle.
I want to shift focus now to what pen testing and constantly scanning for exploits looks like in a real-world scenario or in a corporate security plan. The truth is that what pen testing actually looks like depends on the organization and the value and budget it puts into the actual security team’s ability to test, assess, and fix.
Regardless, you can’t just scan all day long and scan whenever you want. Most times, you need to gain approvals to run scans. But you need to know what those scans are and what they’re scanning for. I discuss a few in this section.
You need to test systems, and you might have to create exclusions, which are systems you can’t scan. Knowing which systems you can’t scan is very important. For example, you may have very old and antiquated systems; scanning them may cause an outage to the system. You may have older systems that run critical functions that you’re aware need to be replaced or upgraded, but the software vendor may not have released patches or current software for your older hardware. Maybe they won’t ever release updates because they no longer support these platforms. Whatever the case, you may have to exclude these systems from your scan and test them in a different way.
Additionally, you may have to tune certain scans on specific systems so that they don’t trip defenses on that system. A great example of that is a firewall. Firewalls don’t like ping sweeps (which is the repeat testing with ICMP using the ping tool to see what systems respond). There may be access control lists (ACLs) in place or firewall rules that block these requests. You may not be able to reach certain segments because the routing won’t allow for a return path and you won’t be able to get the results of your scan. These are just a few reasons why you must understand scan maintenance moving forward if you want to implement a professional pen testing program in your organization.
Open ports indicate services that may be running and listening on a device that may be susceptible to an attack. Open ports can provide an entry point. Ping sweeps use ICMP to touch the hosts on the network and a tool such as Nmap (shown in Figure 2-2 and which I cover in more detail in Chapter 8) can be used to attempt IP and port combinations to find what the ping is answering to.
Port scanners scan only for open ports. A vulnerability scanner can do much more than that, and it can then conduct other probes to find out-of-date software, misconfigurations, and more. This is where a tool such as Nessus (which I introduce in Chapter 3) becomes more valuable to the pen tester.
System patching is one of the main outcomes of at least half the items on your risk register. Because software is often so buggy (even upon release — see the nearby sidebar), over half of the results and solutions provided by your software vendors and almost all of your “bugs” found in code results in an exploit. Service packs, hotfixes, firmware updates, upgrades, and hardening by patching can solve many of your problems.
For example, you might have a bulletproof Linux server but by adding a web server such as Apache to it, you might have opened some ports or exposed something that puts the server at risk.
Again, if you do some pen testing and scan the server (and the web server), you can find those open ports or access points and then identify, secure, and/or configure them so that there are no further issues to worry about.
When considering how pen testing works, it’s helpful to understand the basics of heuristical scanning, which is very much like vulnerability assessment. An AV program sits on a system and is fed information to run a baseline and look for anomalies. If anything comes up and is a match for a known piece of malware, for example, or just looks weird in general, the AV quarantines it for inspection. Figure 2-3 highlights commonly used AV software.
Other similar technologies such as intrusion detection software (IDS) and intrusion prevention software (IPS) actively scan traffic for exploits, malware, intrusion attempts, and other anomalies. They work similarly to how AV programs and pen test tools such as Nessus do. Although I don’t cover AV/IDS and IPS in this book because they’re not traditional toolsets used by pen testers, the truth is that you will need to use them to understand the scope of any attacks.
Another consideration is, what if you hardened everything and used all of the security architecture possible to secure your systems? If you designed and implemented your systems and networks correctly, understood and tested for every change before making any, and only installed and used stable, well-tested, and non-problematic code, you would really never have any security-related issues. If you added a secure perimeter defense system with firewalls, IPS/IDS units, and active monitoring, you would be worry free!
The fact is, this is just not reality. You make changes. You connect to other companies and vendors to do business. You install code that isn’t ready for prime time. You do work and function in these infrastructures and dynamically build them as you go, so you can anticipate that there will be some issues. Because of that you would absolutely need to pen test!
Another consideration in your pen testing activities is whether your company needs to meet a compliance level. I cover compliance, reporting, and legal matters in an upcoming chapter, but I bring this up now because pen testing isn’t only to secure systems and networks. Your company might be legally obligated to ensure (and prove) they’re doing everything possible to protect information that anyone entrusts to their organization. This means you must have a way to determine and prove that compliance is met.
Here are just two (although common) standards of compliance:
Other industries have other standards of compliance. Always be sure you’re aware of any compliance issues and what it takes to maintain compliance.
An integral piece of this chapter is to talk about who you’re fighting: the bad guys, otherwise known as hackers. The problem with calling them hackers is that, technically, the good guys are hackers, too. The whole culture is confusing, so I attempt to demystify it with simple explanations of a myriad of definitions.
First, forget the good and bad of it. Think neutral — a hacker is someone who likes to pull apart computers, systems, code, or applications to further investigate, test, probe, or learn from them because they’re intrigued. That’s it! That’s how simple it really is. Your typical hacker is someone who likes to noodle with technology.
Now, I consider motives. I cover bad guys, so you can better understand your enemy. In some situations, however, the bad guys might become your allies. Some elite hackers have joined forces with law enforcement as part of their plea bargains and have shown them their skills!
I also cover the most commonly used terms in the hacker community today to denote and identify who’s a good guy (white hat), a bad guy (black hat), or somewhere in the middle (grey hat).
A hacktivist (someone who promotes hacktivism) wants to use technology in a way to promote their agendas, which are generally centered around a political movement or social effort. One of the best examples of modern hacktivism is the group Anonymous. Although they’re not the first (some, like the Cult of the Dead Cow, have been around for many, many years), they have proven to be one of the most widely seen on social media platforms and even in pop culture.
The motive is to use technology assets to get something they want. So, if a hacktivist wants to enact a change in a political agenda, they may penetrate a series of web servers and deface them in hopes to embarrass or motivate others in a particular way against their political adversary.
With pen testing, you would have been able to scan those web servers, find that they could be exploited and protected. Unfortunately, hacktivists run their own secure scanners to find the weakness to exploit them.
There are two ends of the spectrum, and you need to understand the type and volume of both sides.
Elite hackers in the world intimately understand not only the systems and structures but also how to program them, make tools that can penetrate systems, and exploit them. These elite hackers are few and far between but are highly dangerous. They only get caught when they make a big mistake that exposes them because most times they spoof where they originate from and are very hard to identify.
On the other side of the spectrum are script kiddies. Script kiddies have basic skills and just enough knowledge to be dangerous. They download and gain access to the tools the elite hackers create and follow their blueprints to gain access to systems and cause problems. Although they’re nowhere near as skilled or dangerous as the elite hackers, they can become a threat if they’re able to pull off an attack successfully.
White hat hackers are you and I: Those who practice security are security analysts and do pen testing to protect technology assets. White hats are those who can legitimately duplicate hacks but to test for vulnerabilities and exploits and secure them. White hats are responsible for conducting hack attacks in secure labs to study the outcomes so they’re understood and what risks they impose.
Grey hat hackers are those who border on the white and the black. They may not be as malicious as a black hat hacker, but they cross the lines at times and break laws, steal corporate code, or even share information they shouldn’t. The grey hat is usually someone who doesn’t work as a security analyst or in another security role in an organization but isn’t a criminal looking to break laws and risk imprisonment.
Black hat hackers are hackers who want to exploit systems and technology for personal gain. They either want to seek revenge, get a financial payment, or gain another benefit from conducting attacks on systems. If a black hat hacker finds something they can exploit, they do so without question — especially if it fits their motives. They also go on social channels (such as the dark web) and share this information openly, sometimes creating a multi-prong attack against others (or entities) in the form of distributed attacks, such as a distributed denial of service (DDoS) attack. Black hat hackers are indeed criminals and are generally found or caught and penalized (and sometimes imprisoned) for their actions.
Like you have many tools for pen testing, hackers have many tools to probe systems, applications, networks, and more to find security vulnerabilities. An experienced and advanced hacker knows there are many more paths to enter by and is familiar with various ways to gather information and bypass security:
Passive reconnaissance (which is somewhat like the active version) is also important to know about. Active reconnaissance testing is much like a port scan that shows you what ports may be open and what you can compromise. Passive reconnaissance is learning about and gaining knowledge through observation without actively engaging the systems you want to know about. Think of active like I’m probing a system and it’s answering me; whereas with passive, I’m doing an eavesdropping attack and recording the information I’m learning about.
3.137.188.11