Senin, 19 Desember 2005

Bringing FreeBSD to InstantNSM

Last week David Bianco announced his InstantNSM project. The purpose is to automate Sguil distribution. At the moment InstantNSM works on Red Hat Enterprise Linux 3 and 4, and geek00l has been blogging on InstantNSM using CentOS 4.2. I told David this afternoon that I plan to help him get InstantNSM working with FreeBSD. I plan to let InstantNSM be the means by which I build FreeBSD Sguil sensors. This will eliminate the need for me to test and write a separate Sguil installation guide. I hope to integrate the proposed sguil-server, sguil-sensor, and sguil-client ports, and the existing SANCP and barnyard ports. Paul has a sguil-client port waiting on acceptance of his new iwidgets port.

Sguil 0.6.0p1 was announced recently. This is the version to deploy if you're starting a new Sguil project and want to the latest and greatest.


Incidentally, this is my 1200th post. This blog will be 3 years old in 20 days. It began on 8 January 2003.

Two New Pre-Reviews

I would like to thank publisher Syngress for sending me two new books that I plan to read in 2006. They sent others, but they are outside my Wish List and therefore well beyond the reach of my reading list. First is Securing IM and P2P Applications for the Enterprise by Paul Piccard, et al, with Marcus Sachs as technical editor. I want to read this book because it addresses the sort of inside-out security problems I wrote about in Extrusion Detection. This appears to be a technical book with lots of helpful advice.

The second book is Insider Threat by Dr. Eric Cole and Sandra Ring. This appears to be a largely non-technical book, dealing more with case studies and general advice. I still think a book like this is helpful, if only to focus people's minds on what the word "threat" means. A flawed version of SSH running inside a company is not an "insider threat," but a disgruntled system administrator certainly is!

FreeBSD Release Schedule

Scott Long posted the latest FreeBSD release schedule. We will see FreeBSD 6.1 near 20 March 2006 and FreeBSD 5.5 near 3 April 2006. FreeBSD 5.5 will be the last 5.x release, with security fixes continuing through 2007 or perhaps 2008. FreeBSD 7.0 is not planned until some time in 2007.

If you follow the thread from Scott's post, some in the community have problems with the pace of releases. I think expectations were formed with the 4.x tree. FreeBSD 4.0 arrived in March 2000, and the end of the line appeared with FreeBSD 4.11 nearly five years later in January 2005.

In contrast, FreeBSD 5.0 arrived in January 2003, and by April 2006 the 5.x tree will end with 5.5. Given that FreeBSD 5.x wasn't considered STABLE until FreeBSD 5.3 in November 2004, I understand why some people are concerned. I am already using the amd64 port of 6.0 in production, but I have several systems still running 5.4.

Incidentally, within the release thread Peter Jeremy made a stunning comment when someone noted the steps required to implement a security patch:

"Speaking as a developer, I think it's trivially easy.

As an end user, I don't think this is acceptable."

Read the whole post for the context. I was impressed to see a developer put aside his coding hat and look at the world from the end user's perspective.

Defense Seldom Wins Wars

In preparation for my career as an Air Force intelligence officer, I studied history at the US Air Force Academy. Since then I have enjoyed lectures produced by The Teaching Company, like Famous Romans. One of the lessons I have taken from this course is that defense seldom (if ever) wins wars. I was reminded of this lesson when I read Tom Ptacek's post " The Only Defense Is A Good Defense."

Tom is replying to my post where I said the following:

"I also do not agree [with SANS.edu] that 'knowledge... is the only defense to the growing threat.' The best defense is a strong offense. That means hunting down and prosecuting threats. No amount of defense can sufficient protect any moderately complex enterprise against determined intruders."

Tom disagrees and says that "Firewalls", "IT and Network Security teams", and "Vulnerability Research" have "done the most to improve security over the last 5 years." If we consider the risk equation to be something like "Risk = Threat X Vulnerability X Asset value", we must realize that Tom's points all address the vulnerability side of the equation. Applying countermeasures to the vulnerability aspect of the risk equation leaves the threat component untouched.

When the attacker is allowed freedom of maneuver, the defender will lose. The side with initiative has the superior position, unless the defenses are so unsurmountable that attack is more costly than defense. Let's return to the Famous Romans lecture for a moment. Prior to the rule of the emperor Hadrian, the Roman Empire had pursued an expansionist foreign policy. Rome had lost many battles to its neighbors, but those neighbors essentially remained on the defensive. They feared Rome would invade, conquer, and eliminate them (at worse).

When Hadrian became emperor in 117 AD, he changed Rome's foreign policy. He decided to consolidate the empire's borders. His most famous action was the building of Hadrian's Wall, separating England from Scotland. The wall was the ultimate statement of defense, as is sought to keep barbarians separated from Roman cities like London.

In some respects, this ultimate defensive maneuver was a success; London flourished. However, the building of the wall signalled weakness to Rome's enemies. Instead of being seen as a statement of strength, barbarians interpreted as a sign the Romans would not seek to conquer them. Rome looked weak, not strong. Within a century Rome would come under increasing barbarian attack, and the remaining shell of the western "empire" was formally overthrown in 476 AD.

Now, you might say that defense can prove superior to offense. You might cite trench warfare of the late 19th century, and the horror of World War I. In those cases, it is true that the weapons possessed by each side were so horribly destructive that attacks were fruitless and bloody endeavors. However, the arrival of the tank and over a million US troops changed the equation. Offensive action eventually won WWI for the allies.

A particularly clever historian might say the Cold War was won by defense. Some argue the US out-spent, or had the capability to out-spend, Soviet Russia. That is true. Another factor was President Reagan's plan to build the Strategic Defense Initiative (SDI, or "Star Wars.) SDI changed the security situation for the Soviets. The security paradigm of "mutually assured destruction" held that seeking to wipe out the enemy was a worthless action. Once the enemy detected missile launches, he could reply with his own volley. Both sets of missiles would wipe out each side's weapons, leaving neither with an advantage to leverage in a post-exchange world.

SDI altered this nuclear attack outcome. With SDI deployed, the US could potentially preserve some of its weapons for a second round of attacks. This second round gave the US superiority over its Soviet opponent. Suddenly a nuclear war became "winnable," as insane as that sounds. In this case, then, defense was important, but only to preserve the weapons of offense.

In the final analysis, what makes you feel safer -- a lack of criminals on your street, or iron bars on your windows?

Thoughts on Monoculture

Tom Ptacek and friends have been blogging at a furious pace, and I noticed he recently argued against Dan Geer's latest article (.pdf) which supports software diversity as a means of "improving security." Tom also found a friend in Halvar Flake. Now, Halvar may be really smart, but it doesn't mean Halvar's argument makes sense in the context that most people share when software monoculture is debated.

Halvar writes exploits. That is his mindset and worldview. Here is the scenario he outlines:

"[T]ake a useful piece of information (for example, a source tarball) and distribute it randomly on a small subset of the computers in the organisation. In the monoculture example, I would need an exploit for the monocultureOS. In the diversity example, I need an exploit for any of the OSs on which the information that I want is stored. Joy. Please diversify!"

According to this reasoning, Halvar thinks software monoculture improves security. By operating a diverse set of operating systems, the target organization seems weaker to Halvar. He can steal that "useful piece of information" from the weakest OS operated by the organization.

That argument makes sense if the goal of "security" is to deny access to a piece of information stored on a variety of hosts. Call that a confidentiality goal.

What if the goal of "security" is not confidentiality, but accessibility? In that case, I argue monoculture is a stupid idea, and diversity is stronger. Imagine saving copies of that piece of information on systems all running the same OS. A destructive worm appears and wipes out the hard drives of all of the organization's hosts. Now what?

In the diverse world, the information on the vulnerable OS is wiped out by the worm. However, copies of the information survive on the other OS'.

If your goal is survivability, I can't see how software monoculture is a good idea. You've got to decide what balance of confidentiality, availability, and integrity are important and then see if monoculture or diversity will meet your goals.

Sabtu, 17 Desember 2005

Thoughts on Recent Microsoft Common Criteria News

Through Slashdot I hunted down this story about certain Microsoft products being awarded Common Criteria (CC) Evaluation Assurance Level (EAL) 4 Augmented with ALC_FLR.3 certification. They include:

  • Microsoft Windows Server™ 2003, Standard Edition (32-bit version) with Service Pack 1

  • Microsoft Windows Server 2003, Enterprise Edition (32-bit and 64-bit versions) with Service Pack 1

  • Microsoft Windows Server 2003, Datacenter Edition (32-bit and 64-bit versions) with Service Pack 1

  • Microsoft Windows Server 2003 Certificate Server, Certificate Issuing and Management Components (CIMC) (Security Level 3 Protection Profile, Version 1.0)

  • Microsoft Windows XP Professional with Service Pack 2

  • Microsoft Windows XP Embedded with Service Pack 2


Achieving this certification is important to Microsoft, because of certain laws:

"[E]ffective 1 July 2002... departments and agencies within the Executive Branch shall acquire, for use on national security systems, only those COTS products or cryptographic modules that have been validated with the International Common Criteria for Information Technology Security Evaluation, the National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS), or by the National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) Cryptographic Module Validation Program."

It is important to remember that "EALs refer to the level of confidence in the conclusions of the evaluation, and not to the level of secrity the product provides. In other words, you can have more confidence that a EAL4 product performs as advertised than an EAL2 product... But an EAL4 product will not necessarily provide more security."

What really matters is the Protection Profile used to evaluate the products. I read that "[t]he Microsoft products were evaluated against the Controlled Access Protection Profile," (CAPP) which is available here (.pdf). Here are a few choice excerpts from the CAPP. Where you see "TOE", think "Microsoft system".

  • The system does not have to defend itself against physical attacks: "The processing resources of the TOE will be located within controlled access facilities which will prevent unauthorized physical access."

  • Sorry, I had to highlight this statement: "There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains."

  • The following implies that the evaluated system should not be a publicly accessible server: "Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints. CAPP-conformant TOEs are applicable to networked or distributed environments only if the entire network operates under the same constraints and resides within a single management domain."


If you continue reading the document, you'll find a great deal of requirements for keeping audit records, authorizing users, vendor-provided documentation, and so forth. This is probably not what people first imagine when they think of "secure" products.

Keep these assumptions in mind when you consider the importance of Microsoft products achieving EAL-4 certification.

Update: You can download the Windows XP / Server 2003 Common Criteria Evaluation Technical Report in .zip format.

Selasa, 13 Desember 2005

Non-Technical Means Unearth Best Intrusions

Thanks again to the latest SANS NewsBites, I learned of an interesting trade secret theft case. From the CNET News story:

"John O'Neil, former CEO of Business Engine Software, pleaded guilty in a San Francisco federal court on Wednesday to conspiracy to download and steal the trade secrets of software competitor Niku over a 10-month period...

From October 2001 until July 2002, Business Engine used the passwords to gain unauthorized access to Niku's systems more than 6,000 times and downloaded over 1,000 confidential documents containing trade secrets, the complaint alleged. The stolen documents included technical specifications, product designs, prospective customers, customer proposals, client account information and pricing.

Niku discovered the break-in after a Business Engine salesman made an unsolicited call to one of Niku's prospective clients, a Nike employee who happened to be related to Niku's chief information officer, Warren Leggett. The call raised suspicion because the Nike employee was not ordinarily responsible for software purchasing decisions, had never heard of Business Engine and had no idea how the salesman had obtained his contact information, according a declaration by Leggett.

The incident prompted Leggett to examine his company's computer logs and files from his recent meeting with Nike. He quickly determined from a trail of Internet network addresses that someone from outside the company had been stealing files. Leggett was able to trace the intrusions back to Business Engine by using Internet domain registration information and publicly available Internet tools." (emphasis added)

Whoa. Niku has been 0wn3d for 10 months, and accessed "more than 6,000 times," before a freak family relation caused the right gears to mesh. What kind of security did Niku have (or not have) that would let a compromise continue undetected and unimpeded for so long?

The sad fact is that many of the most interesting intrusions (i.e., not worms, or bots, or viruses) are discovered by non-technical means. Once a company is clued in to the fact they have a breach, the question becomes one of scoping the incident. For example:

  • What happened/is happening?

  • What systems are or may be affected?

  • What information did the intruder copy, change, or destroy? (violations of confidentiality, integrity, or availability)

  • When did the intruder first gain unauthorized access?

  • When was the last time the intruder accessed victim systems?


Most organizations are not collecting the NSM data they need to answer these questions. Is yours?