Read an Excerpt
The age of connectivity is definitely upon us. With information flowing freely in and from all directions and electronic commerce knocking down new doors, network security has come to include a lot more than just using a good firewall to connect to the Internet.
I've spent a lot of time auditing security on distributed networks. In many cases, I found that data could be easily modified, stolen, or destroyed without a trace that the incident ever occurred. The system administrators and other powers-that-were knew that the systems weren't configured for security. What they didn't know was just how high their level of risk was. Executive managers were equally unaware of the risks.
This book lets you learn from their mistakes. If you are an executive manager, manager, system administratoror anyone responsible for Intranet securityyou must take an active approach to security. Don't make the same mistakes these companies did. It could cost you your company.
About this Book
WHAT you are about to read is NOT a work of fiction. This is a collection of REAL security audits. Each chapter focuses on an audit that I actually conducted (in person!) for a real, live, functioning company. If I'd used the actual company names, you would probably recognize that you'd personally done business with some of them.
Of course, I didn't use the real names of the companies, employees, or other parties for obvious legal and ethical reasons. But I did use the real facts regarding risk and my audit approach in each case. Read closely, especially if you are an executive manager, line-level manager, system administrator,lawyer, or law enforcement professional. The risks described are risks that you NEED to understand.
As a side note, most of the audits I describe in this book were conducted on UNIX systems. Some people, including some security people who should know better, believe that UNIX is inherently more susceptible to security problems than newer platforms like Windows NT. Don't buy it. The truth is that UNIX security is much better understood because it has been pounded on for about 20 years. In newer operating systems, the holes haven't been fully discovered and exploited. Industry experts are now saying that NT configurations may be equally or more vulnerable.
In any case, the real risks are not only built-in to the operating systems. Serious risks lie in the way systems are installed, configured, supported, and managed. It is those factors that most determine the risk to your company.
In pointing out these risks, I'm hoping that the people responsible for data on networks start taking an active and serious approach to security.
How this Book Is Organized
Even though these audits are real, I begin each chapter with a fictional scenario written in first person. In my corporate work, I've found that a lot of people start to take security seriously only when something happens to their systems, their data, and their companyjust one of many respects in which the "Me" decade never really ended. I personalize each scenario by placing you, the reader, into the story to transfer the message that this really could happen to your data and your company.
The bulk of each chapter describes the actual security risks that I uncovered during the audit. This section also explains how those risks came to be. You don't just wake up one morning to find that your network security has gone AWOL. Security breaches usually occur by omission or poor planning executed over long periods of time. These sections explain some ways that can happen.
The last section of each chapter, "Let's Not Go There...," tells you how to avoid the problems in the first place. My hope is that you will read those sections carefully and take the guidelines to heart.
Throughout this book, I use the term "hacker" to mean someone who gains unauthorized access to systems and information. Some experts use the term "cracker" instead, noting that some programmers like to call themselves "hackers" when in fact they are really expert coders and not inclined to criminal activity. I decided to use "hacker" instead, because its use is widespread outside security circles and nearly anyone likely to pick up this book would know what I meant by it. I've also referred to "the hacker" as "he" in most cases. We all know that a hacker can be male or female, but it's annoying to read "he or she" over and over again.
Finally, this book is about hackersnot for them. If you are a wanna-be hacker, you will not learn how to break into systems from this book. You might as well put it back on the shelf now.