News Stay informed about the latest enterprise technology news and product updates.

Hacking for Dummies: Ethical hacking to expose security vulnerabilities

'Hacking for Dummies,' by Kevin Beaver gives detailed information about how to ethically hack into your systems to expose security vulnerabilities. In this interview with SearchSoftwareQuality, Beaver discusses the book, methods of security testing, how to get started and advice for security testers.

Read chapter 4.

Kevin, first let me ask you about the title of the book, "Hacking for Dummies." It appears you are suggesting that by ethically hacking into your systems, you will find your systems' vulnerabilities. Are there methods outside of "hacking" to do security test and are these covered in the book or are you using "ethically hacking" as a synonym to "security testing"?

Ethical hacking is often overlooked and misunderstood yet it can be one of the most beneficial tools any organization can have in the quest for information security and regulatory compliance. Simply speaking, ethical hacking is an information security testing methodology. It's about using a malicious mindset and hacking tools to find the security flaws in your systems so you can plug the holes before the bad guys exploit them. It involves looking at your network devices, operating systems, Web applications, databases, wireless systems, mobile devices and so on. If it has an on/off switch, an IP address, or can store data then it probably needs to be looked at. And like I cover in Hacking For Dummies there are physical and human (social engineering) components to ethical hacking as well. Ethical hacking can and should be done from both inside and outside the network so you can find the security flaws that are often overlooked when performing basic security scans or higher-level audits. 

You define "hacking" in your book as traditionally being malicious and having a negative connotation. Do you think with a title like "Hacking for Dummies" some people may pick it up specifically to learn how to maliciously hack into systems and take advantage of gaining access to unprotected data?

Yeah, there's a bit of irony in the title. Interestingly the original title of the book was going to be "Ethical Hacking For Dummies" but for reasons unbeknownst to me it was decided that "Hacking For Dummies" was best. Looking back, I have to agree. Now, when it comes to people using the book's content for malicious purposes, that's their choice. The reality is you can use practically anything on this earth for malicious purposes – how-to book or not. My approach in Hacking For Dummies is in the context of enterprise security so perhaps that'll turn off those with ill intent. In the end, choices have consequences and it's up to the reader on how things to turn out. 

You say that ethical hacking encompasses formal and methodical penetration testing, white hat hacking, and vulnerability assessments. Can you spend explain what each of these means?

Penetration testing and white hat hacking are often used interchangeably. The reality is white hat hacking is the same as ethical hacking. It's semantics. The problem with penetration testing in its purest form is that it's highly focused – typically on one application, one database, one network segment – so it won't always provide the full security picture. Vulnerability assessments dig deeper on technical issues and typically look at everything soup to nuts. The thing is if you just look at one application or one set of servers and ignore the bigger picture (especially workstations, smartphones, and even IT operations) you won't be able to say that you truly know where everything stands regarding security. Finally, there's one more term that often (incorrectly) gets used in conjunction with these other terms: security audit. A security audit is comparing what you're actually doing to what you say you're doing (via policies) or what you're supposed to be doing (regulations, contracts, etc.). However, by "security audit" most people mean vulnerability assessment. The reality is many audits only hit the technical and operational high points often overlooking the technical details – the things that'll bite you if you ignore them. So I try to stay away from that term altogether. That's not what this stuff is about. 

In Chapter 2, you talk about different types of hackers and their motivations. One thing you say is that "the main reason hackers hack is because they can." You describe it as a hobby for some hackers. Do these hobbyists report their findings back to organizations? In such cases, could this obsession that some hackers have be used to do crowdsource security testing?

A colleague of mine strapped for cash recently asked me about posting his Web URL out on some hacker forums and telling people to have at it. I told him that's probably not the best approach. No matter how good they are technically and how much time they have on their hands, you give some of these people with malicious intent and they're going to take a mile and you'll never get rid of them. I think the crowdsourcing model may work if you have a set of trusted professionals working for you in this capacity. Even then I suspect it'd be hard to pull off and get the deliverables you need in a timely fashion. 

There are so many tools and areas to be tested. How do you suggest someone new to security testing get started?

It's pretty simple: pick up a copy of Hacking For Dummies (or check it out from your local library) and start digging in. I lay out the entire methodology for approaching your security tests. That said, I don't cover every possible tool or every possible test scenario. There's just too much to cover – too many systems, vulnerabilities and other variables. However, I do outline how to plan your testing, which tools to use, what to look for, how to report on your findings and even how to fix many of the issues you come across. Ethical hacking and security testing is just like any other business function. You have to plan ahead and manage it well, but if you do you can't fail. 

Any other parting thoughts or advice?

There's often some confusion over who should perform these tests and/or manage the process. The truth is that many different people need to be involved. From IT Directors to system administrators to compliance officers to security managers - basically anyone responsible for information security, compliance, and risk management in their business needs to have their hands in this. Most importantly, you have to know that the tests you perform are a snapshot that must be repeated periodically and consistently over time.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.