Creating Testing Standrard: Specific Tests

hack meaning

Specific Tests

You may have been charged with performing a general penetration test, or you may want to perform specific tests, such as cracking password or war-dialing into a network. Or you might be performing a social-engineering test or assessing the Windows Operating System on the network. However you're testing, you may want to conceal the specific of the testing to keep what you're doing covert or to protect your methodologies. In fact, your manager or customer may not want the details. Either way, document and make known at a high level what you're doing. This can help eliminate any potential miscommunication and keep you out of hot water.

A good way to provide evidence of what was tested, when it was tested, and more is to enable logging on the system you're testing.

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

 I have experienced surprising vulnerability updates in the past. I was performing an automated assessment on a customer's web site - the same test i had just performed the previous week. The customer and i had scheduled the test date and time in advance. What I didn't know is that the software vendor made some changes to its Web form submission tests, and i flooded the customer's Web application, creating a DoS condition.

 Luckily, this DoS condition occurred after business hours and didn't affect the customer's operations. However, the customer's Web application was coded to generate an alert e-mail for every form submission. The application developer and company's president received 4,000 e-mails in their inboxes within about 10 minutes- ouch! I was lucky that the president was techsavvy and understood the situation. It's important to have contingency plan in case a situation like this occurs.

Blind Versus Knowledge Assessment

It may be good to have some knowledge of the systems you're testing, but it's not required. However, a basic understanding of the systems you're hacking can protect you and others. Obtaining this knowledge shouldn't be difficult if you're hacking your own-in-house systems. If you're hacking a customer's systems, you may have to dig a little deeper into how the systems work so you know what's what. that's how I've always done it. In fact, I've never had customer ask for a fully Blind Assessment. Most people are scared of these assessments. This doesn't mean that Blind Assessments aren't valuable. The type of assessment you carry out depend on your specific needs.

The best approach is to plan on unlimited attacks, wherein any test is possible. The bad guys aren't hacking your systems within a limited scope, why should you?

Consider whether the tests should be undetected. This isn't required but should be considered, especially for social-engineering and physical security tests.

A false sense of vigilance can be created if too many insider know about your testing which can end up negating the hard work you're putting into this. This doesn't mean you shouldn't tell anyone. Always have a main point of contact within the organization - preferably someone with decision-making authority-that both you and all employees can contact if and when something goes wrong.

Location

The tests you're performing dictate where you must run them from. Your goal is to hack your systems from locations where malicious hackers can access the systems. You can't predict whether you'll be attacked by a hacker from outside or inside your network, so cover all your bases. Combine external (public internet) tests and internal (private network) tests.

You can perform some tests, such as password cracking and network-infrastructures assessments, from the comfort of your office-inside the network. But it may be better to have a true outsider perform other tests on routers, firewalls, and public applications.

For your external hacks that required network connectivity, you may have to go off-site (a good excuse to work from home) or use an external proxy server. Better yet, if you can assign an available public IP address to your computer, plug into the network on the outside of the firewall for a hacker's-eye view of your systems. Internal tests are easy because you need only physical access to the building and the network.

Reacting to major exploit that you find

Determine ahead of time whether you'll stop or keep going when you find a critical security hole. Your managers or your customer may not ask you to, but I think it's best to keep going to see what else you can discover. I'm not saying to keep hacking until you crash all your systems. Simply pursue the path you're going down until you can't hack it any longer (pun intended).

Silly Assumptions

You've heard what you make of yourself when you assume things. Even so, you must make assumptions when you hack your systems. Here are some examples of those assumptions:

• Computers, networks, and people are available when you're testing.
• You have all the proper hacking tools.
• The hacking tools you're using won't crash your systems.
• Your hacking tools actually work.
• You know all the risks of your tests.

You should document assumptions and have management of your customer sign off on them as part of your overall approval process.