Specific systems to be tested: When selecting systems to test, start with the most critical systems and processes or the ones that you suspect are the most vulnerable. You could test server OS passwords, test an Internet-facing web application, or attempt social engineering via phishing before drilling down into all your systems. Another consideration is whether to test computer systems that are being used by employees who are working from home. Unless they are connected to the corporate environment over a VPN or are otherwise remotely accessible, you might not even be able to reach them. Furthermore, what are the ramifications of testing computers — especially personal systems — that are running on a home network? Are there medical devices, specific software, or Internet of Things systems that might be disrupted? Thinking all of this through with all the right people is imperative.

       Risks involved: Have a contingency plan for your security testing process in case something goes awry. Suppose that you’re assessing your firewall or a web application, and you take it down. This situation can cause system unavailability, which can reduce system performance or employee productivity. Worse, it might cause data integrity loss, loss of data itself, and even bad publicity. It’ll most certainly tick off a person or two and make you look bad. All of these can create business risks.Handle social engineering and DoS attacks carefully. Determine how they might affect the people and systems you test.

       Dates when the tests will be performed and overall timeline: Determining when the tests are to be performed is something you must think long and hard about. Decide whether to perform tests during normal business hours, or late at night or early in the morning so that production systems aren’t affected. Involve others to make sure that they approve of your timing.You may get pushback and suffer DoS-related consequences, but the best approach is an unlimited attack, in which any type of test is possible at any time of day. The bad guys aren’t breaking into your systems within a limited scope so why should you? Some exceptions to this approach are performing all-out DoS attacks, social engineering, and physical security tests.

        Whether you intend to be detected: One of your goals may be to perform the tests without being detected. You might perform your tests on remote systems or on a remote office and don’t want the users to be aware of what you’re doing. Otherwise, the users or IT staff may catch on to you and be on their best behavior instead of their normal behavior.

       Whether to leave security controls enabled: An important, yet often overlooked, issue is whether to leave enabled security controls such as firewalls, intrusion prevention systems (IPSes), and web application firewalls (WAFs) so that they block scans and exploit attempts. Leaving these controls enabled provides a real-world picture of where things stand. But I’ve found much more value in disabling these controls (in the form of whitelisting your source IP addresses) so that you can pull back the curtains and find the greatest number of vulnerabilities.Many people want to leave their security controls enabled. After all, that approach can make them look better, because many security checks will likely be blocked. To me, this defense-in-depth approach is great, but it can create a serious false sense of security and doesn’t paint the entire picture of an organization’s overall security posture. There’s no right or wrong answer. Just make sure that everyone is on board with what is being tested and what the final outcomes and report represent.

       Knowledge of the systems before testing: You don’t need extensive knowledge of the systems you’re testing — just basic understanding, which protects both you and the tested systems. Understanding the systems you’re testing shouldn’t be difficult if you’re testing your own in-house systems. If you’re testing a client’s systems, you may have to dig deeper. Only one or two clients have asked me for a fully blind assessment.Most IT managers and others who are responsible for security may be scared of blind assessments, which can take more time, cost more, and be less effective. Base the type of test you perform on the organization’s or client’s needs.

       Actions to take when a major vulnerability is discovered: Don’t stop after you find one or two security holes; keep going to see what else you can discover. I’m not saying that you should keep testing until the end of time or until you crash all your systems; ain’t nobody got time for that! Instead, simply pursue the path you’re going down until you can’t hack it any longer (pun intended). If you haven’t found any vulnerabilities, you haven’t looked hard enough. Vulnerabilities are there. If you uncover something big such as a weak password or SQL injection on an external system, you need to share that information with the key players (developers, database administrators, IT managers, and so on) as soon as possible to plug the hole before it’s exploited.

       The specific deliverables: Deliverables may include vulnerability scanner reports and your own distilled report outlining important vulnerabilities to address, along with recommendations and countermeasures to implement.

       To crack passwords, you need cracking tools such as Ophcrack and Proactive Password Auditor.

       For an in-depth analysis of a web application, a web vulnerability scanner (such as Acunetix Web Vulnerability Scanner or Probely) is more appropriate than a network analyzer (such as Wireshark or OmniPeek).

       Read the readme and/or online help files and FAQs (frequently asked questions).

       Study the user guides.

       Use the tools in a lab or test environment.

       Watch tutorial