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

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.

If required, notify your cloud service providers and hosting co-location providers of your testing. Many companies require such notification — and often approval— in advance before they allow testing. These companies have firewalls or intrusion prevention systems (IPSes) in place to detect malicious behavior. If your provider knows that you’re conducting tests, it may be less likely that they block your traffic, and you’ll get better results. They might even preapprove your source IP addresses, which is recommended.

Your testing timeline should include specific short-term dates and any specific milestones. You can enter your timeline in a simple spreadsheet program, a project-focused Gantt chart, or in a larger project plan. Often, when testing client networks, I will list these dates and time frames in my statement of work or in a simple email. That’s often all that’s needed.

A timeline such as the following keeps things simple and provides a reference during testing:

Test Performed	Start Time	Projected End Time
Web application vulnerability scanning	June 1, 21:00 EST	June 2, 07:00
Network host vulnerability scanning	June 2, 10:00 EST	June 3, 02:00
Network host vulnerability analysis/exploitation	June 3, 08:00 EST	June 6, 17:00