Hacking For Dummies. Kevin Beaver
Чтение книги онлайн.
Читать онлайн книгу Hacking For Dummies - Kevin Beaver страница 20
IN THIS CHAPTER
Setting security testing goals
Selecting which systems to test
Developing your testing standards
Examining hacking tools
As an IT or information security professional, you must plan your security assessment efforts before you start. Making a detailed plan doesn’t mean that your testing must be elaborate — just that you’re clear and concise about what to do. Given the seriousness of vulnerability and penetration testing, you should make this process as structured as possible.
Even if you test only a single web application or workgroup of computers, be sure to take the critical steps of establishing your goals, defining and documenting the scope of what you’ll be testing, determining your testing standards, and gathering and familiarizing yourself with the proper tools for the task. This chapter covers these steps to help you create a positive environment to set yourself up for success.
Establishing Your Goals
You can’t hit a target you can’t see. Your testing plan needs goals. The main goal of vulnerability and penetration testing is to find the flaws in your systems from the perspective of the bad guys so that you can make your environment more secure. Then you can take this a step further:
Define more specific goals. Align these goals with your business objectives. Specify what you and management are trying to get from this process and what performance criteria you’ll use to ensure that you’re getting the most out of your testing.
Create a specific schedule with start and end dates and the times your testing is to take place. These dates and times are critical components of your overall plan.
Before you begin any testing, you need everything in writing and approved. Document everything, and involve management in this process. Your best ally in your testing efforts is an executive who supports what you’re doing.
The following questions can start the ball rolling when you define the goals for your security testing plan:
Does your testing support the mission of the business and its IT and security departments?
What business goals are met by performing this testing? These goals may include the following:Working through Service Organization Control (SOC) 2 audit requirementsMeeting federal regulations, such as the Health Insurance Portability and Accountability Act (HIPAA) and the Payment Card Industry Data Security Standard (PCI DSS)Meeting contractual requirements of clients or business partnersMaintaining the company’s imagePrepping for the internationally accepted security standard of ISO/IEC 27001:2013
How will this testing improve security, IT, and the business as a whole?
What information are you protecting (such as personal health information, intellectual property, confidential client information, or employees’ private information)?
How much money, time, and effort are you and your organization willing to spend on vulnerability and penetration testing?
What specific deliverables will there be? Deliverables can include anything from high-level executive reports to detailed technical reports and write-ups on what you tested, along with specific findings and recommendations. You may also want to include your tested data, such as screenshots and other information gathered to help demonstrate the findings.
What specific outcomes do you want? Desired outcomes include the justification for hiring or outsourcing security personnel, increasing your security budget, meeting compliance requirements, or installing new security technologies.
After you know your goals, document the steps you’ll take to get there. If one goal is for the business to develop a competitive advantage to keep existing customers and attract new ones, determine the answers to these questions:
When will you start your testing?
Will your testing approach be blind (aka covert testing in which you know nothing about the systems you’re testing) or knowledge-based (aka overt testing in which you’re given specific information about the systems you’re testing, such as IP addresses, hostnames, usernames, and passwords)? I recommend the latter approach. If you’re testing your own systems, this approach likely makes the most sense anyway.
Will your testing be technical in nature, involve physical security assessments, or use social engineering?
Will you be part of a larger security testing team (sometimes called a tiger team or red team)?
Will you notify the affected parties of what you’re doing and when you’re doing it? If so, how? Customer notification is a critical issue. Many customers appreciate that you’re taking steps to protect their information. Just make sure that you set everyone’s expectations properly.
How will you know whether customers care about what you’re doing?
How will you notify customers that the organization is taking steps to enhance the security of their information?
What measurements can ensure that these efforts are paying off?
Establishing your goals takes time, but you won’t regret setting them. These goals are your road map. If you have any concerns, refer to these goals to make sure that you stay on track. You can find additional resources on goal setting and management in the appendix.
DO YOU NEED INSURANCE?
If you’re an independent consultant or have a business with a team of security assessment professionals, consider getting professional liability insurance (also known as errors and omissions insurance) from an agent who specializes in business insurance coverage. This kind of insurance can be expensive if something goes awry during your work, and you need protection. Many clients require insurance before they will hire you to do the work.
Determining Which Systems to Test
After you’ve established your overall goals, decide which systems to test. You may not want — or need — to assess the security of all your systems at the same time. Assessing the security of all your systems could be quite an undertaking and might lead to problems. I’m not recommending that you don’t eventually assess every computer and application you have. I’m just suggesting that whenever possible, you should break your projects into smaller chunks to make them more manageable, especially if you’re just getting started. The Pareto principle (focusing on your highest-payoff tasks) should take precedence. You might need to answer questions