Selasa, 31 Agustus 2004

Review of The Design and Implementation of the FreeBSD Operating System Posted

Amazon.com just posted my five star review of The Design and Implementation of the FreeBSD Operating System. I was excited to see this update of the 1996 classic The Design and Implementation of the 4.4BSD Operating System finally published. From the review:

"I have been administering FreeBSD systems for four years, and I read 'The Design' to get a better understanding of the system 'under the hood.' This book is definitely not for beginners, and intermediate users like myself can become quickly overwhelmed. Nevertheless, I am very glad FreeBSD developers like McKusick and Neville-Neil took the time to document the kernel in this book."

You can access the authors' works at Addison-Wesley or at McKusick.com and Neville-Neil.com.

Senin, 30 Agustus 2004

What is the Ultimate Security Solution?

I received an email asking certain questions about digital security. Since the author said I could post my reply in my Blog, here is an excerpt from his email:

"I have read of many ways that hackers obtain access. But, I am uncertain what is comprehensive protection. Clearly, there are firewalls, anti-virus, anti-spyware, IDS, IPS, and many other three letter acronym tools available. I have read of your use/support for Sguil. Do you feel that is the ultimate solution?

There are other tools out there like eEye Blink, Pivx Qwikfix, and Securecore type products. I like them, but am uncertain if they do an adequate job at providing security. And I really don't know which would be considered the best of these.

So, I appeal to you for your insight. Would really appreciate any feedback - here or on your blog."


This is an interesting question, because at least one reader of my recent Focus-IDS post thought I was a "detection-only" advocate. Since I believe protection eventually fails (I do believe that, and it's true), did I not also believe protection was worthless?

Chapter 1 of my book lays out my philosophy on security, and Chapter 2 explains how I believe Network Security Monitoring meets the needs of my security philosophy. Anton Chuvakin's recent Slashdot review summarizes some of my thoughts. I recommend anyone interested in knowing how I define terms like security, risk, vulnerability, threat, and so forth thumb through the first two chapters of my book in your local Borders or Barnes and Noble store.

Regarding "ultimate solutions," I don't believe there is such a concept. I agree with Dr. Mitch Kabay that "security is a process, not an end state," and with Bruce Schneier who says security is a process, not a product." On p. 4 of my book I define security as "the process of maintaining an acceptable level of perceived risk." No organization can be considered "secure" for any time beyond the last verification of adherence to its security policy.

How does one best adhere to one's security policy? I believe the answer lies in following the security process, which consists of assessment, protection (prevention), detection, and response. Chapter 11 of my book presents best practices for each as they relate to implementing NSM.

This means none of the products you mentioned (yes, even Sguil) can provide ultimate security. Even all of the best of breed products in the world deployed simultaneously cannot perfectly secure an organization. Focus on products ignores people and processes. All three elements must be brought to bear on the security problem.

I clearly believe that network awareness is one of the keys to security. "Situational awareness" was drilled into my brain as a cadet at the US Air Force Academy, and for good reason. When one is ignorant of one's surroundings, it is impossible to discern the defensive landscape as well as any threats. I advocate NSM as a means to get real threat intelligence. I avoid taking a vulnerability-focused approach to security where possible. Remember that one of the best ways to prevent intrusions is to help put criminals behind bars by collecting evidence and supporting the prosecution of offenders. The only way to ensure a specific Internet-based threat never bothers your organization is to separate him from his keyboard!

I recommend you and other others define your requirements before speaking to any vendor or researching any products. Decide what you believe is lacking in your security posture, and determine what combination of products, people, and processes could best meet your needs. Hire a professional security consultant to perform an assessment if you feel you lack the necessary expertise. Avoid consultants who run Nessus and drop a vulnerability report on your desk. Consult those who can offer solutions to problems or who can supervise the implementation of solutions by third parties. For your personal education you might find reading one or more of my recommended books helpful.

Minggu, 29 Agustus 2004

Showing the FreeBSD Release Engineering Team is on schedule, FreeBSD 5.3-BETA2 is now available. Relating to my earlier post on GIANT, the announcement states "debug.mpsafenet (multi-processor safe network stack) is still turned off by default for BETA2 but will be turned on for BETA3."

Sabtu, 28 Agustus 2004

GIANT-free Networking in FreeBSD 6.0 CURRENT and Upcoming 5.3 STABLE

I've been watching Robert Watson's work on removing the GIANT lock from the FreeBSD kernel. This is an aspect of the FreeBSD SMP project (aka SMPng). Robert's posts on 24 Aug 04 and 28 Aug 04 explain what is affected by these developments. The aspects I care about include the following:

- Those using KAME IPSec will not be able to disable the GIANT lock, and least not yet.
- FAST IPSEC does work with GIANT removed.
- The ath (802.11g), bge, dc, em (Intel gigabit), ep, fxp (Intel 10/100), rl, sis (Soekris Net4801), xl, and wi (802.11b Prism2) network interface drivers work with GIANT disabled.

You can see how the GIANT lock appears when enabled in the dmesg output from a Dell PowerEdge 750 running FreeBSD 5.3-BETA1.

John Baldwin's Locking in the Multithreaded FreeBSD Kernel explains what the GIANT lock does.

Jumat, 27 Agustus 2004

My Book on Slashdot

My book made Slashdot. Let's see how well this site and TaoSecurity.com hold up! Thank you to Anton Chuvakin for a positive review.

Update: Here's how the Slashdot effect looked to TaoSecurity.com:




Here's how the Slashdot effect looked to this Blog:




My Barnes and Nobles sales rank has dropped from the 40,000 range to 20 -- I've passed Bill Clinton and Harry Potter. :)




My Amazon.com sales rank has dropped from the 20,000 range to 119. Slashdot is absolutely amazing. If you find the Amazon price too high, remember Bookpool has the best deal going -- $27.25 plus shipping.




I'd been tracking the Amazon rank to see if I could make any sense of it. You can watch the Slashdot effect kick in between 5 and 6 pm EDT:


Fri Aug 27 17:00:02 EDT 2004
Amazon.com Sales Rank: 20,998

Fri Aug 27 18:00:01 EDT 2004
Amazon.com Sales Rank: 9,363

Fri Aug 27 19:00:02 EDT 2004
Amazon.com Sales Rank: 1,256

Fri Aug 27 20:00:02 EDT 2004
Amazon.com Sales Rank: 614

Fri Aug 27 21:00:01 EDT 2004
Amazon.com Sales Rank: 348
...
Fri Aug 27 23:00:01 EDT 2004
Amazon.com Sales Rank: 313

Sat Aug 28 00:00:01 EDT 2004
Amazon.com Sales Rank: 275

Sat Aug 28 01:00:01 EDT 2004
Amazon.com Sales Rank: 212

Sat Aug 28 03:00:02 EDT 2004
Amazon.com Sales Rank: 188
...
Sat Aug 28 06:00:01 EDT 2004
Amazon.com Sales Rank: 163

Note: These rankings represent the best-case scenario. Now that the Slashdot effect has ended, I've dropped at both Amazon.com and Barnes and Noble. It was fun while it lasted!

Kamis, 26 Agustus 2004

Senator Kennedy No-Fly Watch List and IDS "False Positives"

It struck me today that Senator Kennedy's no-fly watch list troubles are very similar to our digital security woes. Recently Kennedy said "he was stopped and questioned at airports on the East Coast five times in March because his name appeared on the government's secret 'no-fly' list." The Washington Post reported "a senior administration official, who spoke on condition he not be identified, said Kennedy was stopped because the name 'T. Kennedy' has been used as an alias by someone on the list of terrorist suspects."

"T. Kennedy" reminds me of a content matching IDS rule. Is this a "false positive"? If you consider that airline personnel were making decisions based on the rules they were given -- stop anyone using the name "T. [Ted, in the senator's case] Kennedy," this is not a false positive. Perhaps with more context, like personal recognition that the individual at hand is one of the most famous members of the US Senate, the airline "IDS" would meet more of the "spirit" of its mission and less its "letter."

How did Senator Kennedy handle being flagged when he checked into the airport? According to the Post, "When the senator checked in at the counter, airline employees told him they could not issue him a boarding pass because he appeared on the list. Kennedy was delayed until a supervisor could be summoned to identify him and give approval for him to board the plane." That process reminds me of an investigation by a human analyst. Luckily the analyst had the information he or she needed to make a decision. The "full content data" in the person of Senator Kennedy allowed the decision maker to realize the senator was not a terrorist. Without that data, say only knowing someone named "T. Kennedy" was on board a flight, the decision maker might not be able to take proper defensive actions.

What is better: (1) removing a "bad signature" ("T. Kennedy"), or (2) relying on a scrap of imprecise information that could potentially identify a serious threat? With all of this case's publicity, it's doubtful any terrorist will use that alias again. Whatever your decision, this case reminds security professionals to collect the information analysts need to transform indicators into warnings. Also, don't blame the identification system for making poor decisions if you feed it imprecise signatures.

Rabu, 25 Agustus 2004

Fascinating .gov and .mil Docs

Perhaps "fascinating" is too strong a word, but I've come across several intriguing government reports and documents which security professionals might find interesting. First, the CERT/CC and the Secret Service released a joint report titled Insider Threat Study. It's based on "23 incidents carried out by 26 insiders in the banking and finance sector between 1996 and 2002. Organizations affected by insider activity in this sector include credit unions, banks, investment firms, credit bureaus, and other companies whose activities fall within this sector. Of the 23 incidents, 15 involved fraud, four involved theft of intellectual property, and four involved sabotage to the information system/network." One of the incidents, mentioned in the beginning of the report, was the case prosecuted by the DoJ on behalf of UBS.

The major findings include:

"- Most of the incidents in the banking and finance sector were not technically sophisticated or complex. They typically involved the exploitation of non-technical vulnerabilities such as business rules or organization policies (rather than vulnerabilities in an information system or network) by individuals who had little or no technical expertise. In 87% of the cases the insiders employed simple, legitimate user commands to carry out the incidents, and in 78% of the incidents, the insiders were authorized users with active computer accounts.

- The majority of the incidents (81%) were devised and planned in advance. Furthermore, in most cases, others had knowledge of the insider's intentions, plans, and/or activities. Those who knew were often directly involved in the planning or stood to benefit from the activity.

- Most insiders (81%) were motivated by financial gain, rather than a desire to harm the company or information system.

- Insiders in this report fit no common profile. Only 23% held a technical position, 13% had a demonstrated interest in hacking and 27% had come to the attention of a supervisor or co-worker prior to the incident.

- Insider incidents were detected by internal, as well as external, individuals including customers.

- The impact of nearly all insider incidents in the banking and finance sector was financial loss for the victim organization: in 30% of the cases the financial loss exceeded $500,000. Many victim organizations incurred harm to multiple aspects of the organization.

- Most of the incidents (83%) were executed physically from within the insider's organization and took place during normal business hours."

The report also cites a 2000 study titled "DoD Insider Threat Mitigation," available in .doc format. I like reading these sorts of studies because they focus on threats, not vulnerabilities. I am always pleased when I see organizations working with law enforcement to prosecute intruders. A new firewall is not going to stop future intrusions; putting criminals in jail will. Don't focus on the vulnerability and forget about the threat!

On the .mil side, I came across fairly new documents from the Air Force describing their new network operations and security posture. It seems after four years of debate the dust is settling around a hierarchical structure led by the Air Force Network Operations and Security Center (AFNOSC). Several Air Force Instructions (AFIs), led by AFI33-115V1 "Network Operations (NETOPS)" (3 May 04) and other 33 series AFIs have redefined the relationship between the AFNOSC and the Air Force network. While the new structure looks good, I was sad to see the name "AFCERT" officially be replaced by "AFNOSC Network Security Division." I understand the desire to give the AFCERT the authority of being AFNOSC-NSD, but the AFCERT name has twelve years of history behind it. My friends still in the AFCERT report they still use the old name and plan to do so.