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.
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
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.
Creating Testing Standards
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.
Timing your tests
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.
