as often as it used to given the resiliency of today’s systems, but poor planning and timing can have negative consequences.
Although you’re not likely to do so, you can create DoS conditions on your systems when testing. Running too many tests too quickly can cause system lockups, data corruption, reboots, and similar problems, especially when you’re testing older servers and web applications. (I should know; I’ve done it!) Don’t assume that a network or specific host can handle the beating that network tools and vulnerability scanners can dish out.
You can even accidentally create accounts or lock users out of the network without realizing the consequences. Proceed with caution and common sense. Either way, be it you or someone else, these weaknesses likely exist on your network, and it’s better that you discover them first!
Using the Vulnerability and Penetration Testing Process
As with practically any IT or security project, you need to plan security testing. It’s been said that action without planning is the root of every failure. Strategic and tactical issues in vulnerability and penetration testing need to be determined and agreed on in advance. To ensure the success of your efforts, spend time planning for any amount of testing, from a simple OS password-cracking test against a few servers to a penetration test of a complex web environment.
Formulating your plan
Getting approval for security testing is essential. Make sure that what you’re doing is known and visible — at least to the decision-makers. Obtaining sponsorship of the project is the first step. This is how your testing objectives are defined. Sponsorship could come from your manager, an executive, your client, or even yourself if you’re the boss. You need someone to back you up and sign off on your plan. Otherwise, your testing may be called off unexpectedly if someone (including third parties such as cloud service and hosting providers) claims that you were never authorized to perform the tests. Worse, you could be fired or charged with criminal activity.
The authorization can be as simple as an internal memo or an email from your boss when you perform these tests on your own systems. If you’re testing for a client, have a signed contract stating the client’s support and authorization. Get written approval of this sponsorship before you ever start working to ensure that none of your time or effort is wasted. This documentation is your “Get Out of Jail Free” card if anyone — such as your Internet service provider (ISP), cloud service provider, or a related vendor —questions what you’re doing or if the authorities come calling. Don’t laugh — it wouldn’t be the first time it has happened.
One slip can crash your systems, which isn’t necessarily what anyone wants. You need a detailed plan, but you don’t need volumes of testing procedures that make the plan overly complex. A well-defined scope includes the following information:
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
