I started writing the first edition of "Halting the Hacker" in the early nineties when the criminal hacking was a new phenomenon. At that time, it was difficult for a small-to medium-sized company to get any information from the information security industry about the threat from hacking and the processes required to secure the systems. There were some security books, but most of them were cookbooks listing specific steps to secure a system without any detail on why the steps were necessary. My goal with this book is to give administrators an understanding of what hackers do and how they think, so that they can understand why they need to take specific security steps. This new edition updates the tools and processes and goes into detail on securing HP-UX and Linux. I thought it was time to remind people that security requires more understanding than just a checklist.

What operating systems and security tools do you use?

I try to use the right tool for the job. Sometimes that tool is an out-of-the-box tool, other times it is a group of tools scripted together. I'll use "hacker tools" if they perform the function I need and I'll write it myself if I need to. I use the operating system which best supports the tools I need to use and makes my job easiest. I have a long history with Unix, so I prefer it, when I have a choice.

What are the most important things an administrator has to do in order to keep his network secure?

Always keep the basic security principles in mind.

• Least Privileges - Provide only the minimum permissions and privileges, for the minimum amount of time necessary, to allow proper operation of the required processes.
• Compartmentalization - Isolate users, processes, and data to minimize the probability of accidental corruption and provide containment of malicious attacks.
• Separation of Duties - Segment process so that no one individual has the ability to initiate and authorize a transaction, so that it takes collusion to commit fraud.
• Defense in Depth - Multiple layers of security provide overlapping defenses which will compliment each other so that no single vulnerability can compromise the entire security architecture.

What do you think about the full disclosure of vulnerabilities?


I see the issues about disclosing vulnerabilities focused around the appropriate timing of the disclosure and the level of details in the disclosure.

The disclosure should not be so soon that the affected vendors do not have an adequate opportunity to issue a patch or a work-around. However, it does have to be soon enough that the public can implement the fix before it becomes widely exploited. This, of course, requires that the fix has been identified.

I do not see a reason to release specific details about the exploit to the public. Vendors, researchers and those who deal with verifying and repairing vulnerabilities will receive the specifics of the vulnerability. It is sufficient for the general public notification to include what systems are affected, a description of the vulnerability and the specifics of the patch or work-around needed to repair the problem.

Security analysts say that downloadable exploits pose severe danger since script kiddies can use them without any knowledge. Should exploit archives be banned?