Fred Avolio’s Musings

Happy Anniversary Firewall ToolKit!

The TIS FWTK was delivered via FTP to DARPA 15 years ago today. The next day we delivered it to DUNSnet. We did change the firewall industry with its delivery. And then we changed firewall pricing as Steve Walker and I, doing a "back of the envelope" SWAG decided on $15K for software only, $18K with hardware. Other vendors, with pricing at over $50K dropped their prices within a week.

Best wishes to its daddy, Marcus Ranum.

It’s still the most fun I had in a job, my own consulting gig a close second. Read something historic at Firewall TookKit.

As early as v1.0, the firewall toolkit had "application intelligence," also known as "application awareness," and "deep packet inspection." We just weren’t marketing guys.

Data Classification

I provided some input into an article by writer Mathew Schwartz, who quotes me in the article Classify This! 10 Best Practices to Jumpstart Your Data Classification Program.

I’ve often pointed out, here and elsewhere, that there is, as the writer of Ecclesiates says, "nothing new under the sun." Mr. Schwartz wrote about this last week (and it is timely and too few of us are doing it). And I wrote these words in February 1999 (almost 10 years ago).

Security policy planning entails starting with the mission needs. Identify the crown jewels through data classification. Classifications might include "dont care," sensitive, financial, competitive, legal, privacy-related, etc.

Re-read my old article at Foundations of Enterprise Network Security.

It’s not just who you are, it’s who your friends are

I’ve saved this clipping in my "BlogMe" mailbox since February. How to Hack Into a Boeing 787. In a nutshell (in case the article is gone or you don’t want to bother) all variants of the jetliner "have three on-board computer networks. One network is for flight safety and navigation, a second is for administrative functions and the third handles passenger entertainment and Internet access." You know the punch-line, right? All three are linked. (Probably, were, as Boeing says the design has been fixed.)

It reminds me of a story.

It takes place in 1992 or so, DARPA was funding a small computer security company to securely connect The White House (really the Executive Office Building) to the Internet. They came to this security company and asked "Do you know anything about ‘Internet firewalls?’" People at the company did.

After lots of talking and planning someone with a clue said, "We need to do a network survey."

"Why?"

"We need to see what else is connected to your network."

Now remember, this was 1993, before everyone including your Aunt Tilly was on the Internet.

Long story short, the company did the network survey and found that the White House network was already on the Internet. They were connected via NASA Goddard, which, at the time, was well-known in the local IP community for poor network security. They would have had a firewall in their front door with an unlocked back door.

Back to the jetliner. People tend to make these mistakes. Why, or why in the world are—sorry, were—the networks interconnected? I don’t know but experience tells me it was probably to save some copper (or fiber). No matter how smart you are (and the Boeing engineers are smart), always, always, always bring someone else in to look at your plans. And make sure some of those people know something about security and risks.

I heard from someone "in the know," who shall remain nameless.

"How to hack into a 787" was erroneous from the very beginning. It was a scare story launched by someone with no actual knowledge of the systems in question. While there are connections between the sub-networks on the B787, the interactions between the passenger-accessible network and the rest is strictly firewalled and sandboxed. The only data connection between the cabin network and the flight network is a very limited one that allows the cabin crew to talk to the flight crew over the IP-based interphone system. Having actually read the Specification Control Documents (SCDs) which control the design of the system, I can tell you that they were designed with data security issues very much in mind.

Well, certainly good news, but my point remains. These are the times when you don’t just bring in application experts, or networking experts, but also security experts.

Conventional Wisdom vs. Wisdom

In February, Dark Reading published, The Myth of Conventional Wisdom. I posted a comment. A rebuttal really. It is no longer on the website. (No comments or discussions are for the article.) I think the discussion—what Tim wrote and my opinions—might be useful to present here. So, read his piece (let me know if the link no longer works; I saved a copy). And then read what I suggest, below.

I believe you’ve misused the term "conventional wisdom." Conventional wisdom are things that are generally accepted as true by most people, not by experts in the field. I suggest that if you ask experts in the field—and for grins, let’s stick with people who have been in the business for more than 2 years—you will find that none of the things you mention came as surprises. In fact, they could have been, and have been, predicted. But, using the correct definition of conventional wisdom, I agree with your assessment of conventional wisdom in the info security realm.
You write, "The problem with IT security is that it’s not a conventional discipline. It changes with the nature of the business and the nature of the threat." No. Particulars change, but fundamentally there is nothing new in the attack space, and has not been in years.
Neither of the examples you give of zero-day attacks (are we really surprised that attackers go for the low-hanging fruit?) and identity fraud surprised experts in the field. The public believes that because loss of 100,000 credit card names and numbers will lead to more people exploiting more cards. The expert knows that you are still more likely to have you card number taken and used by the young waiter who served you last night.
And what network or security expert said that "DNS systems were unassailable"? Steve Bellovin discovered flaws in DNS almost 20 years ago and security extensions to DNS started in the late 90s. But, yes, "conventional wisdom"&mdashwhich we see is no wisdom at all—would say otherwise.
"IT security ‘wisdom’" is far from "fleeting." We just continue to forget the past, and believe that everything is new and needing new solutions. "The security pro" who forgets the basics and neglects what has worked before "will surely be the first one attacked tomorrow."

The More Things Change…

I was interviewd for Access Control and Security Systems Magazine. The article makes me sound smart and old. Okay, I guess I’d like to think I am smart, and I am, after all, getting on in years. (I am only 10 years old in "dog years!") The article is The More Things Change….