For Dummies 978-0-470-55093-9 Fiche technique télécharger pdf (Page 4)

Part I: Building the Foundation for Ethical Hacking

If you perform ethical hacking tests for clients or simply want to add another

certification to your credentials, you might want to consider becoming a

Certified Ethical Hacker (C|EH), through a certification program sponsored by

EC-Council. See www.eccouncil.org/CEH.htm for more information.

Ethical hacking versus auditing

Many people confuse ethical hacking with security auditing but there are

big differences. Security auditing involves comparing a company’s security

policies to what’s actually taking place. The intent of security auditing is to

validate that security controls exist — typically using a risk-based approach.

Auditing often involves reviewing business processes and might not be very

technical. I often refer to security audits as “security checklists” because

they’re usually based off (you guessed it) checklists.

Conversely, ethical hacking focuses on vulnerabilities that can be exploited.

It validates that security controls do not exist. Ethical hacking can be both

highly technical and nontechnical and, although you do use a formal meth-

odology, it tends to be a bit less structured than formal auditing. If auditing

continues to take place in your organization, you might consider integrating

the ethical hacking techniques I outline into your auditing process.

Policy considerations

If you choose to make ethical hacking an important part of your business’s

risk management program, you really need to have a documented security

testing policy. Such a policy outlines the type of ethical hacking that is done,

which systems (such as servers, Web applications, laptops, and so on) are

tested, and how often the testing is performed. Specific procedures for car-

rying out your security tests could outline the ethical hacking methodology

I cover in this book. You might also consider creating a security standards

document that outlines the specific security testing tools that are used and

specific dates your systems are tested each year. You might list standard

testing dates, such as once per quarter for external systems and biannual

tests for internal systems.

Compliance and regulatory concerns

Your own internal policies might dictate how company management views

security testing, but you also need to consider the state, federal, and global

laws and regulations that affect your business. Many of the federal laws and

regulations, such as the Health Insurance Portability and Accountability Act

1 2 3 4 5 6 7 8 9 ... 15 16

Pas de commentaire

For Dummies 978-0-470-55093-9 Fiche technique Page 4