Jumat, 30 September 2005

Last Days to Register for ShmooCon 2006 for $75

Today and tomorrow (1 October) are the last days to register for ShmooCon 2006 for $75. The conference will be held in Washington, DC on 13-15 January 2006. Starting 2 October the price doubles to $150. This is a very innovative conference that you simply cannot beat for the price. I will attend.

Excellent Article on FreeBSD ACLs

Dru Lavigne wrote an excellent article called Using FreeBSD's ACLs. She describes how to use File System Access Control Lists in a reader-friendly manner, complete with screen shots of the Eiciel GUI tool (in the ports tree). Great work Dru!

Kamis, 29 September 2005

Open Source Security in the Enterprise

This morning I briefed a client on the results of a Network Security Monitoring Assessment I performed for them. I model my NSM Assessment on the NSA-IAM, which uses interviews, observation, and documentation review to assess security postures. My NSM Assessment uses the same techniques to identify problems and provide recommendations for improving intrusion detection and NSM operations.

During one of the briefings the top manager asked for my opinion on using open source security tools. He wanted to know the guidelines I use to determine if an open source tool is appropriate for use in the enterprise. I told him I am more likely to trust open source products that are developed by companies with whom I have a relationship of some sort (like Snort and Sourcefire, Nessus and Tenable, or Argus and Qosient).

I was wondering what sorts of suggestions you might have governing open source security tools. The intent of the manager's question was to assess how I end up "trusting" open source tools. I believe the commercial tools should not be trusted simply because they are commercial, in an age where programming can be outsourced to parties ultimately unknown. What are your thoughts?

Rabu, 28 September 2005

Rootkits Make NSM More Relevant Than Ever



Federico Biancuzzi conducted an excellent interview with Greg Hoglund and Jamie Butler, authors of Rootkits: Subverting the Windows Kernel. I reviewed this book during publication for Addison-Wesley, but I don't plan to read it for personal education until I get deep into the programming part of my reading list. This is the sort of book that looks K-RAD on your bookshelf, telling those passing your cube that you've got m@d 31337 sk1llz. Doing something useful with the contents take some real mastery of Windows programming, especially device driver development and thorough knowledge of material in Microsoft® Windows® Internals, Fourth Edition.

The interview reminded me that network security monitoring is needed now more than ever. It is easy for host-centric security types to concentrate on defending the desktop. In reality the battle for the desktop PC has been lost. When intruders can completely control all aspects of a running system, there is almost no where else for defenders to go. The only places left are found in CPU microcode or outside the CPU itself, monitoring it via a hardware JTAG port as described in a recent Dr Dobbs Journal article.

If the desktop cannot be trusted then detection and prevention must be performed elsewhere, on a trusted platform outside of the intruder's, and more importantly, user's reaches. This can only be done at the network infrastructure. While the network will not yield as rich a collection of evidence about host exploitation, the data collected via network platforms bears a higher degree of trust.

I foresee a few roads ahead for corporate PC users, some of which may be taken simultaneously. We may see this at .mil or .gov earlier. One day arbitrary Web browsing and email communication with non-business-related parties will be forbidden. Alternatively (or simultaneously) PCs will be replaced by true non-Windows thin clients like Sun Ray 170s. Organizations adopting these practices will realize that they must do something to reduce the overall threat level (first option) and/or vulnerability level (second option).

Thoughts on EAL7 Rating

I read in the story Network appliance to get highest-ever security rating by Michael Arnone about the EAL7 Evaluation Assurance Rating achieved by the Tenix Datagate. An EAL7 system bears these qualities:

"Formally Verified Design and Tested. The formal model is supplemented by a formal presentation of the functional specification and high level design showing correspondence. Evidence of developer "white box" testing and complete independent confirmation of developer test results are required. Complexity of the design must be minimised."

My last post mentioned an introductory article on the Common Criteria, and I found an exceptional quote in that piece about EALs. Write Alex Ragen says:

"EAL is the level of confidence achieved by the TOE [Target of Evaluation, a product], and is a function of the SARs [Security Assurance Requirements] with which the TOE complies...

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."

This is an incredible insight. I guarantee I will encounter government managers who hunt for high EAL products because they think they provide "more security."

This is what the Tenix product does:

"Placed at each connection between unclassified and classified servers, Data Diode permits only one-way transmission of data from unclassified to classified networks."

According to Michael Arnone's article: "A senior technical consultant at Tenix said 'it’s physically impossible for data to go back the other way,' which ensures unparalleled security."

Oh boy, that sounds like a challenge! The main barrier to breaking that claim is getting equipment into the right hands.

I found the Tenix product listed on the NIAP in evaluation page and on the validated product page. The lab which tested the product is COACT. Here is the Tenix press release.

Senin, 26 September 2005

Common Criteria

I received the September issue of the ISSA Journal. It contains several useful articles, with the most helpful to me being a humanly readable summary of the Common Criteria by Alex Ragen. I don't think Mr. Ragen clearly states who needs to purchase Common Criteria-validated products however.

His article's first sentence states:

"On July 1, 2002, the US Department of Defense began to enforce National Security Telecommunications and Information Systems Security Policy (NSTISSP) #11 (issued in January 2000), which mandates that US government agencies purchase only those IT security products which have been validated in accordance with Common Criteria and/or FIPS 140-1 or FIPS 140-2 as appropriate."

He also says:

"As mentioned earlier, US government agencies now require Common Criteria certification."

This is not true. According to the Committee on National Security Systems FAQ:

"The policy mandates, effective 1 July 2002, that 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.

Additionally, subject to policy and guidance for non-national security systems, NSTISSP # 11 notes that departments and agencies may wish to consider the acquisition of validated COTS products for use in information systems that may be associated with the operation of critical infrastructures as defined in the Presidential Decision Directive on Critical Infrastructure Protection (PDD-63)." [emphasis added]

Those bold sections make all the difference. This means that systems operated by the Department of Commerce, for example, that are not "national security systems," do not have to be validated by the Common Criteria. While some people discuss the possibility that Common Criteria would be extended beyong NSS, there is definitely no mandate to do so.

Webroot State of Spyware Report

On a flight from San Franciso to Washington Dulles I managed to read the latest State of Spyware report from Webroot Software. I'm not sure how I got the heavy printed version. Maybe it was sent courtesy of Richard Stiennon, who is Vice President of Threat Research. (That's an interesting title.)

I thought the report was useful. It provides a broad look at spyware, and specifics on several examples. It contains an excellent section on spyware-related legislation. The report provides plenty of background for management who need justification to spend money on spyware defenses. I even bought into the idea that automated spyware defenses are required.

>On a related note, the Symantec Internet Security Threat Report Volume VIII is available for download. I have not read this one yet. It is a huge .pdf though. I believe a report like that complements material from organizations like Webroot. Symantec takes a broader look at Internet threats. It also examines vulnerabilities (which we know are not threats).