Think logically — like a programmer, a radiologist, or a home inspector — to dissect and interact with all the system components to see how they work. You gather information, often in many small pieces, and assemble the pieces of the puzzle. You start at point A with several goals in mind, run your tests (repeating many steps along the way), and move closer until you discover security vulnerabilities at point B.
The process used for such testing is the same as the one that a malicious attacker would use. The primary differences lie in the goals and how you achieve them. Today’s attacks can come from any angle against any system — not just from the perimeter of your network and the Internet as you may have been taught in the past. Eventually, you’ll want to test every possible entry point, including partner, vendor, and customer networks, as well as home users, wireless networks, and mobile devices. Any human being, computer system, or physical component that protects your computer systems — both local and in the cloud — is fair game for attack, and it needs to be tested eventually.
When you start rolling with your testing, you may want to keep a log of the tests you perform, the tools you use, the systems you test, and your results. This information can help you do the following:
Track what worked in previous tests and why.
Prove what you did.
Correlate your testing with firewalls, intrusion prevention systems (IPSes), and other log files if trouble or questions arise.
Document your findings.
In addition to general notes, taking screen captures of your results (using Snagit, Snip & Sketch, or a similar tool) whenever possible is very helpful. These shots will come in handy later if you need to show proof of what occurred, and they’ll also be useful as you generate your final report. Also, depending on the tools you use, these screen captures may be your only evidence of vulnerabilities or exploits when the time comes to write your final report. Chapter 3 lists the general steps involved in creating and documenting a security testing plan.
Your main tasks are to find the vulnerabilities and to simulate the information gathering and system compromises carried out by someone with malicious intent — a partial attack on one computer, perhaps, or a comprehensive attack against the entire network. Generally, you look for weaknesses that malicious users and external attackers might exploit. Assess both external and internal systems (including processes and procedures that involve computers, networks, people, and physical infrastructures). Look for vulnerabilities. Check how all your systems interconnect and how private systems and information are (or aren’t) protected from untrusted elements.
These steps don’t include specific information on the methods that you use for social engineering and assessing physical security, but the techniques are the same. I cover social engineering and physical security in more detail in chapters 6 and 7, respectively.
If you’re performing a security assessment for a client, you may go the blind assessment route, which means that you start with just the company name and no other information. This blind assessment approach allows you to start from the ground up and gives you a better sense of the information and systems that malicious attackers can access publicly. Whether you choose to assess blindly (covertly) or overtly, keep in mind that the blind way of testing can take longer, and you may have an increased chance of missing some (or many) security vulnerabilities. Blind assessment isn’t the ideal testing method, but some people may want it.
As a security professional, you may not have to worry about covering your tracks or evading IPSes or related security controls because everything you do is legitimate, but you may want to test systems stealthily. In this book, I discuss techniques that hackers use to conceal their actions and outline some countermeasures for concealment techniques.
Seeing What Others See
Getting an outside look can turn up a ton of information about your organization and systems that others can see, and you do so through a process often called footprinting. Here’s how to gather the information:
Use a web browser to search for information about your organization. Search engines, such as Google and Bing, are great places to start.
Run network scans, probe open ports, and seek out vulnerabilities to determine specific information about your systems. As an insider, you can use port scanners, network discovery tools, and vulnerability scanners (such as Nmap, SoftPerfect Network Scanner, and GFI LanGuard) to see what’s accessible and to whom.
Whether you search generally or probe more technically, limit the amount of information you gather based on what’s reasonable for you. You might spend an hour, a day, or a week gathering this information. How much time you spend depends on the size of your organization and the complexity of the information systems you’re testing.
The amount of information you can gather about an organization’s business and information systems can be staggering and often widely available. Your job is to find out what’s out there. This process is often referred to as open-source intelligence (OSINT). From social media to search engines to dedicated intelligence-gathering tools, quite a bit of information is available on network and information vulnerabilities if you look in the right places. This information potentially allows malicious attackers and employees to access sensitive information and target specific areas of the organization, including systems, departments, and key people. I cover information gathering in detail in Chapter 5.
Scanning Systems
Active information gathering produces more details about your network and helps you see your systems from an attacker’s perspective. You can do the following things:
Use the information provided by WHOIS searches to test other closely related IP addresses and host names. When you map and gather information about a network, you see how its systems are laid out. This information includes determining IP addresses, host names (typically external but occasionally internal), running protocols, open ports, available shares, and running services and applications.
Scan internal hosts when they’re within the scope of your testing. (They really ought to be because that’s where the large majority of vulnerabilities exist.) These hosts may not be visible to outsiders (you hope they’re not), but you absolutely need to test them to see what rogue (or even curious or misguided) employees, other insiders, and even malware controlled by outside parties can access. A worst-case situation is that the intruder has set up shop on the inside. Just to be safe, examine your internal systems for weaknesses.
If you’re not completely comfortable scanning your systems, consider using a lab with test systems or a system running virtual machine software, such as the following: