Bryan Burns - Security Power Tools

Copyright 2008 O'Reilly Media, Inc.

When I first started working in information security more than 15 years ago, it was a very different field than the one we are in today. Back then, the emphasis was security primarily through network-based access lists, strong passwords, and hardened hosts. The concept of distributed systems had just started emerging, and user-based networks were made of either dumb terminals or very rudimentary network operating systems. The home environment was not network-orientedcertainly not nearly as much as it is today. There was only so much you could do as an attacker (or victim) at 1,200 or 2,400 baud.

Attack tools and defense tools were also very rudimentary. The most advanced security-related industry wasand to a certain extent, still isthe Virus/Anti-Virus industry. Can you remember the DOS Ping Pong virus from 1988? Forensics was also in its infancy and was really only limited to the high-end companies and government agencies.

In a very simple sense, security was defined primarily in a silo-like approach and achieved through air-gaps. Network connectivity, limited as it was, had tight access controls. Consequently, the network was not considered as the primary vector for attack.

Now, in what seems to be a blink of an eye, the security landscape is completely different. The change was gradual at first and increased at a rate similar to that of the growth of the Internet. The adoption of the Internet and TCP/IP as its common protocol had undoubtedly served as the primary catalyst for the creation and propagation of more and more attack vectors. This in turn created the demand, and consequently the supply, of better and more robust defense mechanisms. As was the case with the Anti-Virus industry, this cat-and-mouse process helped boost the sophistication level of both attack and defense tools. The pervasive nature of the Internet had also made it a target-rich environment, and it provided attackers multiple locations from which to launch their attacks.

At the same time that the security landscape changed, the discussion around security had changed as well. To borrow an expression from the cryptology field, security was largely accomplished through obscurity. I still recall with some fondness a comment made on one of the firewall mailing lists that NT, by virtue of being new and unknown, is much more secure than Unix, which has source code out in the open. As time has shown, while "security by obscurity" may be a valid tactic to take in some fields, it does not work well in most areas related to information security.

As the industry matures, we are seeing the evolution of such concepts as full and responsible disclosure. Companies are stepping up in terms of awareness and response to security issues. Microsoft, once ridiculed for their security posture, is now, in my opinion, one of the true pioneers in security response. When you factor-in the amount of code they support, and their immense user base, I would challenge you to find any other software vendor who takes such extraordinary steps to provide security response to their customers.

At the same time, it is this awareness and response that also fuels and drives the attackers to act. A vendor announcing the availability of a patch to address a security issue is also providing the attackers with notification that the vulnerability exists in the unpatched systems, and (through the patch) with a roadmap as to how to exploit that vulnerability. The sad reality of our industry is that once a patch is available, it does not mean that the security administrators can immediately apply it. If the patch applies to a server, the administrator typically has to wait for an outage window, which assumes that they can certify that the patch will not affect any of the business systems. If the patch applies to a client machine, many organizations have the challenge of enforcing that end users actually apply the patchesagain, once they have been certified to work with the different business systems in use. Additionally, the tools the attackers have at their disposal to analyze these patches are so advanced that the "Time to Exploit" is dramatically reduced.

When we were approached to write this book, I have to admit to some mixed feelings about it. My group is composed of security experts from many different fields and disciplines. They know all these tools and have used all of them in the course of their work. So why should we write a book about it? Even more sowhy would you, as a security professional, want to pick up a book like this? Another obvious question is, aren't there already other books on this topic? This is forgetting for the moment that I need my group to actually work and not just spend their time writing books.

So, aside from the glory that is associated with writing a book for O'Reilly, what were the reasons to write about stuff we already know, for a group of people who probably know at least some of the stuff we write about, when there might be other books about different security tools, and when there is so much work to be done? Well, the answer is fairly simple. My group's knowledge of these tools came through years of working with them and applying them. The information they have to present to you goes beyond the simple two-page summary of what the tool does. This is not a simpleton's instruction manual. We also assume that you, as a security professional, know the basics, and that you really want to get some deeper understanding of how these tools are used. Or, perhaps you're too busy concentrating on just one side of the security equation and need to catch up on the other side. While it is true that there are many fine books about security, it is also true that most of them concentrate on one product, one tool, or just one side of the equation. There are also many fine books that talk about theory and concept, but then never really get down to the practical. On the flip side, there are books that are full of practical advice, without any kind of theoretical context. As for the distressing fact that my group has a lot of work to do, I determined that not only would we be doing the security community a service by writing this book, but also that our job will become significantly easier if we help raise the level of knowledge out there. Also, by soliciting the help of a couple of key people to contribute sections to this book, I was able to dampen the impact this book had on my group. I would like to use this opportunity thank Jennifer Granick and Philippe Biondi for their help in this aspect.

And so I urge you, the security professional, to take some time and read this. Written by authors with more than a century of combined experience in this field, I think you will find that this book contains valuable information for you to use.

Avishai Avivi

Director, Security Engineering & Research

Juniper Networks, Inc. May 2007