Imagine if software developers didn't use a basic plan/design/develop/test/deploy/maintain methodology (okay, some don't, but that's another discussion) -- or, think about what would happen if bridge engineers or building architects just threw their stuff together in a hurry. Think they'd be effective? Think they'd stay in business!? Well, the same goes for security vulnerability testing. You've got to have a plan if you're going to be successful. You can't just wing it and hope that you will catch everything and any security problems will go away. Here are 8 reasons why:
- You'll inevitably forget one or more systems or applications to test (i.e. old file servers, random Web apps and databases, etc.) or not know how to approach a specific system (with authentication, without authentication, etc.) and then You'll have to go back and plan things out easily wasting double the time it would've taken otherwise.
- Not getting proper approval from management or the project sponsor can backfire -- big time -- making everyone involved look bad.
- The time management
- and achievement experts have found that for every one minute we plan, we can save five minutes in execution -- what more needs to be said?
- Everyone won't be on the same page and everyone's expectations won't be set. When this happens, the impact of any problems you come across (system crashes is a common one that comes to mind) will be much greater. You'll also have a lot more explaining to do.
- There can be delays in your ability to use the commercial tools you're expecting to use. This has happened to me on more than one occasion where I think my license is current or I know I've got to update it and think it'll only take a short period of time to renew. Waiting until the last minute has delayed my testing -- by days on a couple of occasions -- because the vendors have not always been responsive in getting me updated licenses. Those vendor client acquisition/accounts receivable shortcomings now become your problems.
- You'll undoubtedly run your tests at the wrong time. There's never a really ideal time to test for security vulnerabilities, but if you don't plan out your time and dates, you'll likely run into conflicts with batch jobs, high traffic volume, backups running, etc. which can not only delay your tests but also cause systems to crash.
- Vital resources you often need in IT, project management, product management, executive sponsors, etc. may not be there to help answer questions, explain how systems work, and help in other capacities you'll undoubtedly need when rooting through your systems.
- A part of the planning process is to actually have a set testing methodology (i.e. reconnaissance, enumeration, finding vulnerabilities, exploiting any weaknesses, reporting on your findings, and following up to ensure the holes are plugged. You can use, in part, something as high-level as the ISO/IEC 17799:2005 framework. I recommend you check out two other resources as well – 1) the OCTAVE methodology and 2) the Open Source Security Testing Methodology Manual (OSSTMM).
If you ask yourself what is it you're going to do, how you're going to go about doing it and then prioritize your tasks to make sure you're focusing on the urgent and important areas, you'll use your time wisely and really start seeing positive results in your security testing.
This tip originally appeared on SearchWindowsSecurity.com.
About the author:
Kevin Beaver is an independent information security consultant, author, and speaker with Atlanta-based Principle Logic, LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments. Kevin has written five books including Hacking For Dummies (Wiley), Hacking Wireless Networks For Dummies, and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He can be reached at firstname.lastname@example.org.
This was first published in March 2006