Читать книгу Hacking For Dummies - Kevin Beaver - Страница 52

After you’ve established your overall goals, decide which systems to test. You may not want — or need — to assess the security of all your systems at the same time. Assessing the security of all your systems could be quite an undertaking and might lead to problems. I’m not recommending that you don’t eventually assess every computer and application you have. I’m just suggesting that whenever possible, you should break your projects into smaller chunks to make them more manageable, especially if you’re just getting started. The Pareto principle (focusing on your highest-payoff tasks) should take precedence. You might need to answer questions such as these when deciding which systems to test based on a high-level risk analysis:

 What are your most critical systems?

 Which systems, if accessed without authorization, would cause the most trouble or suffer the greatest losses?

 Which systems appear to be most vulnerable to attack?

 Which systems are undocumented, are rarely administered, or are the ones you know the least about?

The following list includes devices, systems, and applications on which you might perform vulnerability and penetration tests:

 Routers and switches

 Firewalls, including their associated rulebases

 Wireless access points

 Web applications and APIs (hosted locally or in the cloud)

 Workstations (desktops, laptops — running locally or at users’ homes)

 Servers, including database servers, email servers, and file servers (hosted locally or in the cloud)

 Mobile devices (such as smartphones and tablets) that store confidential information

 Physical security cameras and building access control systems

 Cloud security policy configurations, such as those for Amazon Web Services (AWS)

 Supervisory control and data acquisition (SCADA) and industrial control systems

The systems you test depend on several factors. If you have a small network, you can test everything. For larger organizations, consider testing only public-facing hosts such as email and web servers and their associated applications. Assuming you meet all outside requirements, the security testing process is somewhat flexible. Based on compliance regulations or demands from business partners and customers, you should decide what makes the most business sense or what you’re required to do.

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.