Kevin Beaver - Hacking For Dummies

Start with the most seemingly vulnerable or highest-value systems, and consider these factors:

Whether the computer or application resides on the network or in the cloud and what compensating security controls might already exist

Which operating system (OS) and application(s) the system runs

The amount or type of critical information stored on the system

A previous information risk assessment, vulnerability scan, or business impact analysis may have generated answers to the preceding questions. If so, that documentation can help you identify systems for further testing. Bow Tie and Failure Modes and Effects Analysis (FMEA) are additional approaches for determining what to test.

Vulnerability and penetration testing goes deeper than basic vulnerability scans and higher-level information risk assessments. With proper testing, you might start by gleaning information on all systems — including the organization as a whole — and then further assess the most vulnerable systems. I discuss the vulnerability and penetration testing methodology in Chapter 4.

Another factor that helps you decide where to start is your assessment of the systems that have the greatest visibility. It may make more sense (at least initially) to focus on a database or file server that stores critical client information than to concentrate on a firewall or web server that hosts marketing information, for example.

Attack-tree analysis , also known as threat modeling, is the process of creating a flow-chart-type mapping of how malicious attackers would attack a system. Attack trees are used in higher-level information risk analyses; they’re also used by security-savvy development teams for planning new software projects. If you want to take your security testing to the next level by thoroughly planning your attacks, working methodically, and being more professional, attack-tree analysis is the tool you need.

The only drawback is that attack trees can take considerable time to create and require a fair amount of expertise. Why sweat the process, though, when a computer can do a lot of the work for you? A commercial tool called SecurITree, by Amenaza Technologies Ltd. ( www.amenaza.com ), specializes in attack-tree analysis. You could also use Microsoft Visio ( www.microsoft.com/en-us/microsoft-365/visio/flowchart-software )) or SmartDraw ( www.smartdraw.com ). The following figure shows a sample SecurITree attack-tree analysis.

One miscommunication or slip-up can send systems crashing during your security testing. No one wants that to happen. To prevent mishaps, develop and document testing standards. These standards should include

When the tests are performed, along with the overall timeline

Which tests are performed

How much knowledge of the systems you require in advance

How the tests are performed and from what source IP addresses (if performed via an external source via the Internet)

What to do when a major vulnerability is discovered

This list is general best practices; you can apply more standards for your situation. The following sections describe these best practices in more detail.

They say that “it’s all in the timing,” especially when performing security tests. Make sure to perform tests that minimize disruption to business processes, information systems, and people. You want to avoid harmful situations such as miscommunicating the timing of tests and causing a denial of service (DoS) attack against a high-traffic e-commerce site in the middle of the day or performing password-cracking tests in the middle of the night that end up locking accounts and keeping people from logging in the next morning. It’s amazing what a 12-hour time difference (2 p.m. during major production versus 2 a.m. during a slower period) can make when testing your systems. Even having people in different time zones can create issues. Everyone on the project needs to agree on a detailed timeline before you begin. Having team members’ agreement puts everyone on the same page and sets correct expectations.

If required, notify your cloud service providers and hosting co-location providers of your testing. Many companies require such notification — and often approval— in advance before they allow testing. These companies have firewalls or intrusion prevention systems (IPSes) in place to detect malicious behavior. If your provider knows that you’re conducting tests, it may be less likely that they block your traffic, and you’ll get better results. They might even preapprove your source IP addresses, which is recommended.

Your testing timeline should include specific short-term dates and any specific milestones. You can enter your timeline in a simple spreadsheet program, a project-focused Gantt chart, or in a larger project plan. Often, when testing client networks, I will list these dates and time frames in my statement of work or in a simple email. That’s often all that’s needed.

A timeline such as the following keeps things simple and provides a reference during testing:

You may have been charged with performing some general vulnerability scans, or you may want to perform specific tests such as cracking passwords or trying to gain access to a web application. You may even be performing a social engineering test or assessing Windows systems on the network. However you test, you don’t necessarily need to reveal the specifics of the testing. Just high-level information should suffice. Even when your manager or client doesn’t require detailed records of your tests, document what you’re doing at a high level. Documenting your testing can eliminate potential miscommunication and keep you out of hot water. Also, you may need documentation as evidence if you uncover malfeasance.

Enabling logging on the systems you test along with the tools you use can provide evidence of what and when you test. Such logging may be overkill, but you could even record screen actions by using a tool such as TechSmith’s Camtasia Studio ( www.techsmith.com/video-editor.html ).

Sometimes, you know the general tests that you perform, but if you use automated tools, it may be impossible to understand every test completely. This situation is especially true when the software you’re using receives real-time vulnerability updates and patches from the vendor each time you run it. The potential for frequent updates underscores the importance of reading the documentation and readme files that come with the tools you use.