Kamis, 30 November 2006

Thoughts on Vista

To mark the launch of Microsoft Windows Vista, CSO Online asked me to write this article. The editor titled it "Security In Microsoft Vista? It Could Happen." I think I took a balanced approach. Let me know what you think. I was pleased to see my FreeBSD reference survived the editor's review!

Selasa, 28 November 2006

FreeBSD 7.0 Snapshot with SCTP

I've been busy playing with various protocols in preparation for TCP/IP Weapons School in about two weeks. Recently I saw this post by Randall Stewart indicating that Stream Control Transmission Protocol (SCTP) had been added to FreeBSD CURRENT. I poked around in src/sys/netinet/ and found various SCTP files dated 3 Nov 06.

Rather than update a FreeBSD 6.x system to 7.0, I decided to look for the latest FreeBSD snapshot. Sure enough, I found the latest 7.0 snapshot was dated 6 Nov 06. I downloaded the first .iso and installed it into a VMware Server VM. The kernel was compiled on 5 Nov 06:

$ uname -a
FreeBSD freebsd70snap.taosecurity.com 7.0-CURRENT-200611
FreeBSD 7.0-CURRENT-200611 #0: Sun Nov 5 19:31:17 UTC 2006
root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

I found the SCTP files I was looking for, too.

$ cd /usr/src/sys/netinet
$ ls -al *sctp*
-rw-r--r-- 1 root wheel 11869 Nov 3 10:23 sctp.h
-rw-r--r-- 1 root wheel 83862 Nov 3 14:48 sctp_asconf.c
-rw-r--r-- 1 root wheel 2884 Nov 3 10:23 sctp_asconf.h
-rw-r--r-- 1 root wheel 62791 Nov 3 10:23 sctp_auth.c
-rw-r--r-- 1 root wheel 9440 Nov 3 10:23 sctp_auth.h
-rw-r--r-- 1 root wheel 58467 Nov 3 10:23 sctp_bsd_addr.c
-rw-r--r-- 1 root wheel 2370 Nov 3 10:23 sctp_bsd_addr.h
-rw-r--r-- 1 root wheel 30071 Nov 3 10:23 sctp_constants.h
-rw-r--r-- 1 root wheel 39292 Nov 4 03:45 sctp_crc32.c
-rw-r--r-- 1 root wheel 2149 Nov 3 10:23 sctp_crc32.h
-rw-r--r-- 1 root wheel 14856 Nov 3 10:23 sctp_header.h
-rw-r--r-- 1 root wheel 163684 Nov 3 10:23 sctp_indata.c
-rw-r--r-- 1 root wheel 3965 Nov 3 10:23 sctp_indata.h
-rw-r--r-- 1 root wheel 140398 Nov 4 03:19 sctp_input.c
-rw-r--r-- 1 root wheel 2301 Nov 3 10:23 sctp_input.h
-rw-r--r-- 1 root wheel 12179 Nov 3 12:21 sctp_lock_bsd.h
-rw-r--r-- 1 root wheel 2474 Nov 3 12:21 sctp_os.h
-rw-r--r-- 1 root wheel 2882 Nov 3 12:21 sctp_os_bsd.h
-rw-r--r-- 1 root wheel 261210 Nov 3 10:23 sctp_output.c
-rw-r--r-- 1 root wheel 5216 Nov 3 10:23 sctp_output.h
-rw-r--r-- 1 root wheel 149450 Nov 4 00:39 sctp_pcb.c
-rw-r--r-- 1 root wheel 15352 Nov 3 10:23 sctp_pcb.h
-rw-r--r-- 1 root wheel 7221 Nov 3 10:23 sctp_peeloff.c
-rw-r--r-- 1 root wheel 2158 Nov 3 10:23 sctp_peeloff.h
-rw-r--r-- 1 root wheel 28138 Nov 3 10:23 sctp_structs.h
-rw-r--r-- 1 root wheel 48751 Nov 4 03:19 sctp_timer.c
-rw-r--r-- 1 root wheel 3311 Nov 3 10:23 sctp_timer.h
-rw-r--r-- 1 root wheel 25951 Nov 3 10:23 sctp_uio.h
-rw-r--r-- 1 root wheel 128287 Nov 3 18:04 sctp_usrreq.c
-rw-r--r-- 1 root wheel 15869 Nov 3 10:23 sctp_var.h
-rw-r--r-- 1 root wheel 146141 Nov 3 18:04 sctputil.c
-rw-r--r-- 1 root wheel 9301 Nov 3 10:23 sctputil.h

However, the GENERIC kernel does not contain support for SCTP. It must be compiled in, which I did using the following method (based on my earlier post).

freebsd70snap# pwd
/usr/src/sys/i386/conf

freebsd70snap# cat SCTP
include GENERIC
options SCTP

freebsd70snap# cd /usr/src
freebsd70snap# make buildkernel KERNCONF=SCTP INSTKERNNAME=SCTP
freebsd70snap# make installkernel KERNCONF=SCTP INSTKERNNAME=SCTP

freebsd70snap# echo "kernel=SCTP" > /boot/loader.conf
freebsd70snap# cat /boot/loader.conf
kernel=SCTP

freebsd70snap# reboot

After reboot the new kernel was running.

$ uname -a
FreeBSD freebsd70snap.taosecurity.com 7.0-CURRENT-200611
FreeBSD 7.0-CURRENT-200611 #0: Tue Nov 28 22:09:44 EST 2006
root@freebsd70snap.taosecurity.com:/usr/obj/usr/src/sys/SCTP i386

The next step is to try to get something working with SCTP. More on that later, hopefully!

Jumat, 24 November 2006

Digital Security Lessons from Ice Hockey

I'm struck by the amount of attention we seem to be paying to discovering vulnerabilities and writing exploits. I call this "offensive" work, in the sense that the fruits of such labor can be used to attack and compromise targets. This work can be justified as a defensive activity if we accept the full disclosure argument that truly bad guys already know about these and similar vulnerabilities, or that so-called responsible disclosure motivates vendors to fix their software. This post isn't about the disclosure debate, however. Instead, I'm wondering what this means for those of us who don't do offensive work, either due to lack of skills or opportunity/responsibility.

It occurred to me today that we are witnessing the sort of change that happened to the National Hockey League in the late 1960s and early 1970s. During that time the player pictured at left, Bobby Orr, changed the game of ice hockey forever. For those of you unfamiliar with hockey, teams field six players: one goalie, who guards the net; two defensemen, who try to stop opposing players; and three forwards (one center and two wings), who try to score goals.

Prior to Orr, defensemen almost never took offensive roles. (Forwards didn't pay much attention to defense, either. Only in 1978 did the Selke Trophy, for best defensive forward, start being awarded.) When Orr began playing, he wasn't satisfied to control the puck in his defensive end and then hand it off to one of his forwards. He jumped into the play, sometimes carrying the puck end-to-end, finishing by scoring himself. Twice in his ten year career he even lead the league in scoring -- scoring more goals than forwards. He didn't neglect his defensive duties, either. He was named league best defensement eight years straight.

What does this mean for digital security? It's easy to identify the forwards in our game. They discover and write exploits. Some of them can play defense, while others cannot. Many of us are traditional defensemen. We know how to impede the opposing team, and we know enough offense to understand how the enemy forwards operate. A few of us are goalies. Aside from clearing the zone or maybe making a solid pass to a forward, goalies have near-zero ability to score goals. (Yes, I remember Ron Hextall.) That's the nature of their position -- they can't skate to the other end of the ice!

Anyone who plays a sport will probably recognize the term "well-rounded." Being well-rounded means knowledge and capability in offense and defense. I think it applies very well to ice hockey and basketball, less so to soccer, somewhat well to baseball, and not at all to football. I see well-roundedness as the proper trait for the general security practitioner, i.e., the sort of person who expects to work in a variety of roles during a career. This is the ice hockey model.

I do not recommend following what might be called the [American] football model. Football players are exceptionally specialized and usually ineffective when told to play out of position. (Could you imagine the kicker playing on the defensive line, or the center as a wide receiver?)

Returning to the hockey model, remember that there are three positions, with varying degrees of offensive and defensive responsibilities. Goalies focus almost exclusively on defense, but they try to make smart plays that lead to break-outs. Defensemen concentrate on defense but should contribute offensively where possible. Forwards concentrate on offense, but help the defensemen as well. How does this model apply to my position in digital security? I consider myself a defenseman, but I'm trying to develop my offensive skills. (At the very least, better knowledge of offensive tools and techniques helps me better defend against them.) I have no interest in being a goalie. Being a forward would be exciting, but I'm not sure I'll have an opportunity or job responsibility to fully develop those skills.

I suppose it's even possible to become a coach or trainer (like skating guru Laura Stamm). You don't have to actually play the game, but you quickly become irrelevant if you lose touch with the game.

Does the extreme specialization of the football model apply? I think it may for large consultancies (or perhaps for the security market as a whole). In a large consultancy, you can be the "Web app guy" or the "incident response gal" and make a living. Outside of that environment, perhaps at a general security job for a company, you're expected to be good at almost everything.

I've written before that it's unreasonable to be good at everything, despite the unrealistic desire of CIOs to hire so-called "multitalented specialists." I recommend choosing to be a goalie, defenseman, forward, or coach/trainer. Be solid in your core responsibilities, but remember Bobby Orr's example.

How do you fit into my hockey model?

Another Prereview

Recently I posted thoughts on a few security books on my shelf. Today I received an absolutely gigantic new book called The Art of Software Security Assessment: Identifying and Avoiding Software Vulnerabilities by Mark Dowd, John McDonald, and Justin Schuh. This is a 1200-page book on discovering vulnerabilities in all sorts of software. I plan to read it along with similar books over the next month or so.

Books on how to break software in order to make it better seem to be the hottest titles on the market. This is exactly the sort of book I would expect most vendors to dislike, although titles like Hunting Security Bugs, published by shows some vendors realize that if they don't test their software first, some attacker in Bucharest will do it for them.

Rabu, 22 November 2006

Three Seven-Book Lists for Novice, Intermediate, Advanced Readers

I continue to receive feedback and questions on my No Shortcuts post. One of you prompted me to write three new Amazon.com Lists, organized thus:

For the civilians out there, that's novice, intermediate, and advanced. :) I listed seven books for each category to keep things manageable. One of the problems I encountered with the advanced list, especially, is that coding becomes a big part of the equation when one starts to consider "advanced" topics. I tried including "placeholder" books to give you the idea that you need coding background to make good use of a book like Unix Network Programming, Volume 1: The Sockets Networking API, 3rd Ed.

Please let me know if you find these lists helpful. Please remember that reading these 21 books in order will not take you from newbie to guru. Rather, these are books I think will help at each stage of your progression. I am also not claiming to be a guru by having selected seven advanced books. For example, I need to get more acquainted with coding in order to branch out into other areas of digital security.

Pre-reviews and Comments

Several publishers have sent me new books recently, and I have one comment to make about an older book. I'll start with books that look good, but which I don't plan to read. The first is Linux Administration Handbook, 2nd Ed by Evi Nemeth, Garth Snyder, Trent R. Hein. There's no doubt this is a great general-purpose system administration book for Linux. I gave the 3rd edition of the Unix version three stars almost five years ago (and I'm hoping this 4th edition comes to fruition).

The Linux book describes Red Hat Enterprise, Fedora Core, SuSE, Debian, and Ubuntu. If the book covered Slackware and Gentoo instead of SuSE, I think it would have been perfect. I'm guessing RHEL is close enough to Fedora, and Debian to Ubuntu, to allow extra coverage of more diverging distros like Slackware and Gentoo? I plan to use this book as a reference, but I don't plan to read and review it. I suggest you buy it if you're looking for a comprehensive Linux reference that doesn't waste time with installation screenshots or descriptions of how to use KDE and Gnome. Another book I like but which I don't plan to read is Network Security Tools by Nitesh Dhanjani and Justin Clarke. This is an older book (April 2005), but I only recently rediscovered it. This book reminds me of
Building Open Source Network Security Tools
by Mike Schiffman, which I liked. NST describes how to write Nessus and Nikto plug-ins, dissectors and plug-ins for Ettercap, and how to extend Hydra and Nmap. There's a chapter on Metasploit, but it is somewhat overtaken by events because the 3.x framework uses Ruby instead of Perl. NST also explains how to extend PMD, how to build your own Web, SQL, and exploit scanner, and how to write tools with Libpcap (0.8.3) and Libnet (1.1.2.1).

NST is a great book, but it requires a good knowledge of C and a desire to work with these tools in a development capability. I don't possess the requisite coding skills, but I may turn to this book in the future if I want to learn more about extending these tools. Next is Network Security Hacks, 2nd Ed by Andrew Lockhart. I liked the 1st Ed which I read and reviewed in June 2004. Since I see my review of the 1st Ed on the Amazon.com page for the 2nd Ed, I won't be able to submit a review for this book. The 2nd Ed looks about 50% longer than the 1st Ed.

I was also pleased to see the discussion of Sguil had been updated for Sguil 0.6.1. However, Sguil's integration of SANCP for session data collection was ignored. After being a Sguil advocate for almost four years, writing books and articles (some of which are freely available), I am puzzled that some people who choose to write about Sguil still don't grasp the significance of the data we collect. This recent Daily Dave thread was depressing. People really collect full content data in production on busy networks? Shocking! The first book in this post that I plan to read and review is The Art of Software Security Testing: Identifying Software Security Flaws by Chris Wysopal, Lucas Nelson, Dino Dai Zovi, and Elfriede Dustin. This book is less than 300 pages but it looks very interesting. I plan to review it with a set of books on finding bugs and vulnerabilities. It's encouraging to see these sorts of titles appearing, written for software developers and not for hacker wanna-bees. The next book is WarDriving and Wireless Penetration Testing by Chris Hurley and friends. This is another team-written book, which tend to scare me when published by Syngress. I wasn't too impressed by the earlier WarDriving book (reviewed here), but I plan to give this new one a try. I'm really looking forward to Wi-Foo II next year. The last book is Network Security Assessment by Steve Manzuik and friends. This is another "team book," but it looks good. I'm surprised anyone is talking about vulnerability management these days. That's so 2002! (Please recognize I'm joking.)

Remember, you can see books that I'm waiting to acquire by checking my Amazon.com Wish List. If you're a publisher, please keep in mind I restrict my reading to books on that list. Under extraordinary circumstances I might read something else, but I generally focus on books that address a specific interest. Thank you.

Selasa, 21 November 2006

No Shortcuts to Security Knowledge

Today I received a curious email. At first I thought it was spam, since the subject line was "RE: Help!", and I don't send emails with that subject line. Here is an excerpt:

I cannot afford nor have the time to take a full collage course on the topic of network security but I would like to be as knowlageable about it as yourself and be able to protect my computer and others regarding this matter. If I was willing to pay you would you take the time to teach me what you know and/or point me in the direction I would need to learn what you know about network security? Please advise what course I would need to take to accomplish your skill of network security?

In my opinion, it seems like this question seeks to learn some sort of "hidden truth" that I might possess, and acquire it in record time. The reality is that there are really no shortcuts to learning as complex a topic as digital security. I have been professionally involved with this topic for almost ten years, yet I consider myself halfway to the level of skill and proficiency I would prefer to possess. In another ten years I'll probably still be halfway there, since the threats and vulnerabilities and assets will have continued to evolve!

If you want to "know what I know," a good place to start is by reading one or more of my books. I recommend starting with Tao, then continuing with Extrusion and finishing with Forensics. Chapter 13 from Tao explicitly addresses the issue of security analyst training and development.

My company research page lists over a dozen documents I've written, and this blog is a record of almost four years of thoughts on digital security.

For books outside of my own, my top ten books of the last ten years contains some of the best books on digital security. My reading page shows books I recommend in five categories. I also show the books waiting to be read on my shelf, but I wouldn't consider an appearance there to be an endorsement unless I offer a favorable Amazon.com review. Please note my recommended lists do not include books from 2006 (and maybe 2005), but I plan to write a "best of" list at the end of this year. I'll update the recommendations lists if I have time.

In addition to reading, I highly recommend becoming familiar with the majority of the security tools listed by Fyodor. It also helps to specialize (at least in the beginning) in one of the five categories I show on my reading page.

I tend to split my time between Weapons and Tactics and Telecommunications, although I plan to continue developing my Scripting and Programming skills. I do some System Administration by building and operating network sensors and supporting systems (like databases), but I am not the sort of sys admin who supports users. I try to stay out of devoted Management and Policy work, although I try not to be ignorant.

I could probably say a lot more on this topic, but the bottom line is that there are no shortcuts to security knowledge. I hope this free post has been helpful.