Hacking For Dummies. Kevin Beaver

magazine (www.helpnetsecurity.com/insecuremag-archive)

       Hackin9 (https://hakin9.org)

       PHRACK (www.phrack.org/archives)

Malicious attackers usually learn from their mistakes. Every mistake moves them one step closer to breaking into someone’s system. They use this knowledge when carrying out future attacks. As a security professional responsible for testing the security of your environment, you need to do the same.

Maintaining Anonymity

      Smart attackers want to remain as low-key as possible. Covering their tracks is a priority, and their success often depends on remaining unnoticed. They want to avoid raising suspicion so that they can come back and access the systems in the future.

      Hackers often remain anonymous by using one of the following resources:

       Borrowed or stolen remote desktop and virtual private network (VPN) accounts of friends or previous employers

       Public computers at libraries, schools, or hotel business centers

       Open wireless networks

       VPN software or open proxy servers on the Internet

       Anonymous or disposable email accounts

       Open email relays

       Infected computers (also called zombies or bots) at other organizations

       Workstations or servers on the victim’s own network

      If hackers use enough stepping stones for their attacks, they’re practically impossible to trace. Luckily, one of your biggest concerns — the malicious user — generally isn’t quite as savvy unless the hacker is a network or security administrator. In that case, you’ve got a serious situation on your hands. Without strong oversight, there’s nothing you can do to stop hackers from wreaking havoc on your network.

Chapter 3

      Developing Your Security Testing Plan

      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