Interview with Jason Reid, author of “Secure Shell in the Enterprise”

Jason Reid is a Member of Technical Staff with Sun Microsystems. There he tests software and writes for the Sun BluePrints program. His start in security began as a Unix system administrator at the Purdue University Computing Center.

How did you get interested in computer security?

It started while I was attending Purdue University. I was introduced to the COAST (Computer Operations, Audit, and Security Technology) group (now known as CERIAS – The Center for Education and Research in Information Assurance and Security) run by Professor Eugene Spafford. I started attending the security lecture seminar and later did some work for the professor.

I transitioned from student to practitioner when I became a Unix sysadmin. I was responsible for a shell account and NFS server. Among the problems of keeping the machine running smoothly were people who pointed out various security problems by exploiting them, students misbehaving towards each other, and students causing trouble for other Internet connected systems.

Do you have any favourite security tools? Which are they?

My single favourite security tool is a whiteboard. Whether its looking for weak points in data flow or explaining public key cryptography, nothing seems to beat quick impromptu multi-colored diagrams. I have seen everything from stack smashing to entire ISP security architectures explained on its glossy surface. A picture can save you a thousand words of typing.

How long did it take you to write “Secure Shell in the Enterprise” and what was it like? Any major difficulties?

The writing for the first draft took about six months. The entire project from proposal to delivery to the publisher took about nine months. Publishing took another month.

The two major problems encountered were time and the act of writing itself. I was required to fulfill my normal job duties while writing. Mostly late nights and weekends were spent writing the book. Writing is the hardest thing that I have done. I generally wrote each paragraph at least three times before having something that I felt I could build on. My technical writer, Daniel Barnett, deserved much credit for keeping me motivated and on track.

Why did you choose to write this book?

I was asked. Based on the response to the articles Keith Watson and I wrote for the Sun BluePrints OnLine program, the blueprints group approached me to expand the material into a book. Having no actual idea how much work a book took, I agreed.

In your opinion, what are the most important things an administrator has to do in order to keep a network secure?

I would like to say that diligently reading every post on every vulnerability mailing list and applying every vendor patch will secure your network. Alas, I cannot since you cannot keep up with the data flow and vendors take time to produce patches. I recommend two things: relax and manage your risk.

Managing your risks sounds rather cryptic and to many it is. It is about recognizing the value of what you have, the costs to protect it, and the risks of bad things happening. Examine the insurance industry. They manage to stay in business despite the constant onslaught of floods, hurricanes, tornadoes, earthquakes, and other disasters.

Based on your experiences, do you find proprietary software or open source software to be more secure?

Neither. The vulnerability mailing lists are filled with reports for both open source and proprietary software. The problems of poor design, unsafe coding practices, and complexity are not limited to any one philosophy of software production. The philosophy gives no information on the diligence of either the product design, coding practices, or general quality levels.

The risk or security of software is measured by the amount of peer review that software has had. An unknown piece of software is deemed suspect until proven innocent by usage. I believe that open source software has the advantage here by its community at large vetting process versus private audits that the proprietary software is limited to.

What do you think about the full disclosure of vulnerabilities?

I am in favor of it. Only by studing past failures can we mitigate future ones. Of course, this requires an environment where people may learn and apply the past lessons. I do think that the discovers of a vulnerability should notify vendors discretely before posting details. The key point should be getting the vulnerability fixed and systems patched not about giving script kiddies another exploit.

What are your plans for the future? Any exciting new projects?

I am currently enjoying the celebrity lifestyle of a security author. 🙂 My current project is to spend time with those close to me.