TaoSecurity Blog

My 17th Snort Report titled How to find new features in Snort 2.8.2 has been posted. It was delayed in production for a while but it still applies to Snort 2.8.2.1. From the article: Service provider takeaway: Service providers will learn about new features in Snort 2.8.2 that they can deploy at customer sites. The last time we looked at new Snort options occurred with Snort 2.8.0, released in late September 2007. Since then, Snort 2.8.0.1, 2.8.0.2 and 2.8.1 have been published. At the time of writing, Snort 2.8.2-8-rc1 is the latest version, although release candidate versions should generally not be deployed in production environments. However, RC editions do provide a look at the newest elements of Snort available to the general public. This Snort Report provides an overview of some of the new features in the latest editions of Snort while explaining how to identify these new features. I'm working on a new Snort Report now looking at the new SSP Beta 2.

As a former Air Force intelligence officer, I'm very interested in counterintelligence. I've written about counterintelligence and the cyber-threat before. I'm reading a book about counterintelligence failures, and the following occurred to me. It is seldom in the self-interest of any single individual, department, or agency to identify homegrown spies. In other words, hardly anyone in the CIA wants to find a Russian spy working at Langley. If you disagree, examine the history of any agency suffering similar breaches. It isn't pretty; the degree to which people deny reality and then seek to cover it up is incredible. In some ways this make sense. Nothing good comes from identifying a spy, other than (hopefully) a damage assessment of the spy's impact. Overall the national security of the country can be incredibly damaged, never mind the lives lost or harmed by the spy's actions. However, in case after case, the appeal to higher national security inte

Security operations can be reduced to four main tasks. A mature security operation performs all four tasks proactively. Collection is the process of acquiring the evidence necessary to identify activity of interest. Analysis is the process of investigating evidence to identify suspicious and malicious activity that could qualify as incidents. Escalation is the process of reporting incidents to responsible parties. Resolution is the process of handling incidents to recover to a desired state. The goal of every mature security operation is to reduce the mean time to resolution, i.e., accomplishing all four tasks as quickly and efficiently as possible. As has been noted elsewhere (e.g., Anton Chuvakin's Blog ), some organizations which aren't even performing collection yet view achieving that first step as their end goal. ("Whew, we got the logs. Check!") Collecting evidence is no easy task, to be sure. Increasingly the logs generated by security devices are

The following is directed at students of my TCP/IP Weapons School (TWS) at Black Hat USA 2008 on 2-3 and 4-5 August 2008, at Caesars Palace, Las Vegas, NV. Please disregard otherwise. TWS is an advanced network traffic analysis class. We expect students to have some experience looking at network traffic using tools like Wireshark. We also expect students to have some experience working in Unix-like operating systems. We want you to get the most value from TWS. Students may participate in three ways. Students may simply observe while the instructor explains the network traffic and attacks which generated the traces. Students do not need anything to enjoy this aspect of the class. Students are encouraged to review traces as the instructor explains the network traffic and attacks. Students will need a laptop running Wireshark and a DVD drive to enjoy this aspect of the class. Students are encouraged to perform hands-on exercises which demonstrate tools and techniques to create

Amazon.com just published my four star review of The New School of Information Security by Adam Shostack and Andrew Stewart. From the review : If you don't "get" Allan Schiffman's 2004 phrase "amateurs study cryptography; professionals study economics," if you don't know who Prof. Ross Anderson is, and if you think anti-virus and a firewall are required simply because they are "best practices," you need to read The New School of Information Security (TNSOIS). If you already recognize why I highlight these issues, you will not find much beyond an explanation of these central tenets in TNSOIS.

Recently Fyodor sent me a pre-publication review copy of his new self-published book Nmap Network Scanning (NNS). I had heard of Fyodor's book when I wrote my review of Nmap in the Enterprise last month, but I wasn't consciously considering what could be in Fyodor's version compared to the Syngress title. Although the copy I read was labelled "Pre-Release Beta Version," I was very impressed by this book. In short, if you are looking for the book on Nmap, the search is over: NNS is a winner. I've reviewed dedicated "tool" books before, including titles about Snort, Nessus, and Nagios. NNS dives into the internals of Nmap unlike any other title I've read. Without Nmap author Fyodor as the author, I think any competitor would need to have thoroughly read the source code of the application to have a chance at duplicating the level of detail Fyodor includes in NNS. Instead of just describing how to use Nmap, Fyodor explains how Nmap works. G

I just listened to the first edition of the Dark Visitor Podcast . You may remember my February post titled Review of The Dark Visitor , where I discussed a book by the The Dark Visitor Blog author Scott Henderson. In the podcast, fellow blogger Jumper speaks with Henderson (aka "Heike" on the blog) about various issues related to Chinese hackers. The pair make it clear that they base their posts on "open sources," meaning information available to anyone with a Web browser and an understanding of the Chinese language. Chinese hackers are a hot topic. The latest Information Security Magazine features a "face-off" between Marcus Ranum and Bruce Schneier on the subject. I think you would learn more reading the Dark Visitor Blog regularly. For example, they responded directly to Bruce Schneier's thesis. I think anyone who likes my blog will enjoy listening to this new podcast. If anyone knows of a similar English-language site covering Russian

It's been 16 days since I responded to public notification of DNS problems in Thoughts on Latest Kaminsky DNS Issue , and 4 days since Halvar Flake's post On Dan's request for "no speculation please" . Apparently the tubes are still working, since I presume you're reading this post via the Internet and not carrier pigeon. It's still been a remarkable period, characterized by the acronymn in the title of this post. I'm not referring to the TARDIS of Doctor Who, although centrality of "Time" is the reason I used the TARDIS theme. I mean Time and Relative Data in Security. Time and Relative Data were the key issues in the DNS issue. Who knew more about the problem, and when? Halvar understood this in his post, when he estimated that a savvy attacker would need 1/4 the time of a normal security person to understand the nature of the DNS problem, given the same starting point. Since Halvar's speculation, Matasano's confirmation , M

I answered a question on the Daily Dave mailing list, so now a few of you are asking "what should Dan have done?" about his DNS discovery . Keeping in mind my thoughts on keeping vulnerabilities in perspective , I have the following suggestions. Black Hat and/or Def Con should not be the place where "all is revealed." The gravity of the situation (such as it might be) is nullified by what will undoubtedly be a circus. Disclosure of additional details should have been done by a neutral party with no commercial interests. Black Hat and/or Def Con would have made great post-disclosure locations, where Dan explains how he found the vulnerability, along with "the rest of the story." That would have still made a great talk, with plenty of worthwhile attention. Personal blog posts should be avoided. The disclosure process should have been run exclusively through a group with some nominal "Internet security legitimacy," like CERT-CC and the aff

It's been nine days since Dan Kaminsky publicized his DNS discovery . Since then, we've seen a Blackberry vulnerability which can be exploited by a malicious .pdf, a Linux kernel flaw which can be remotely exploited to gain root access, Kris Kaspersky promising to present Remote Code Execution Through Intel CPU Bugs this fall, and David Litchfield reporting "a flaw that, when exploited, allows an unauthenticated attacker on the Internet to gain full control of a backend Oracle database server via the front end web server." That sounds like a pretty bad week! It's bad if you think of R only in terms of V and forget about T and A. What do I mean? Remember the simplistic risk equation, which says Risk = Vulnerability X Threat X Asset value. Those vulnerabilities are all fairly big V's, some bigger than others depending on the intruder's goal. However, R depends on the values of T and A. If there's no T, then R is zero. Verizon Business unders

I noticed a new tool on Packetstorm recently: PktAnon by Christoph P. Mayer, Thomas Gamer, and Dr. Marcus Schöller. This tool seems powerful because you can apply a variety of anonymization policies based on settings you apply in an XML configuration file. It was easy to install the tool on Debian 4.0: tws:~# cd /usr/local/src tws:/usr/local/src# wget http://www.tm.uka.de/pktanon/download/pktanon-1.2.0-dev .tar.gz ...edited... tws:/usr/local/src# tar -xzf pktanon-1.2.0-dev.tar.gz tws:/usr/local/src# http://www.tm.uka.de/pktanon/download/pktanon-1.2.0-dev.tar. gz tws:/usr/local/src# sudo apt-get install libxerces27-dev libboost-dev -su: sudo: command not found tws:/usr/local/src# apt-get install libxerces27-dev libboost-dev Reading package lists... Done Building dependency tree... Done The

I liked Robert Graham's post on CACE Technologies TurboCap . I don't necessarily think TurboCap is that exciting, but I learned a lot of tricks reading Robert's explanation of how to collect packets quickly for traffic inspection purposes. I've discussed some of them, like device polling on FreeBSD . By the way, don't forget to upgrade to Wireshark 1.0.2 .

Visibility in the cloud is one of my concerns these days. When someone else hosts and processes your data, how can you tell if it is "secure?" I found Robert Graham's post Gmail now shows IP address log to be very interesting. Robert explains how Gmail using HTTPS doesn't always use HTTPS (which is old news, as he says), but monitoring (of a sort) is now available to determine if someone else is using your account. According to the Gmail blog , Gmail will soon make available logs of IPs using your Gmail account. I agree that the technique could be applied to other Web and cloud applications. How about a record of my Amazon S3 account?

The Air Force published New cyberspace career fields, training paths, badge proposed earlier this month. I found the proposed cyber badge to be interesting. From the story: The badge features: lightning bolts to signify the cyberspace domain; center bolts taken from the navigator badge and the Air Force Seal to signify cyberspace's worldwide power and reach and its common lineage and history of electronic warfare officers; and orbits to signify cyberspace's space-related mission elements. And, like other specialty badges, it will identify skill (certification) levels. Final approval and specifics of the wear criteria is under review at the air staff. For comparison I've posted the intelligence badge I used to wear. Wikipedia's Badges of the US Air Force is a nice reference. The Air Force also published a proposed Cyberspace Training Path for Operators and Specialists . Since we're talking military cyber operations, a blog reader asked for my opinion of the new

It seems Dan Kaminsky has discovered a more effective way to poison the DNS cache of vulnerable name servers. This is not a new problem, but Dan's technique apparently makes it easier to accomplish. One problem is we do not know exactly what Dan's technique is. He is saving the details for Black Hat. Instead of publishing the vulnerability details and the patches simultaneously, Dan is just notifying the world a problem exists while announcing coordinated patch notifications. I would keep an eye on the following for details as they emerge: Rich Mogull's blog Matasano Blog I think this person figured out the server side: "Allen Baranov Jul 9 Having read the comments and checked out the site mentioned in the blog I have the following theory: 1. I connect to vulnerable DNS Server and query my very own domain. I note what the UDP source port is. 2. I connect to the DNS Server again ASAP and query another of my very own domains. I note what that UDP source port is. 3. As

Amazon.com just published my four star review of BSD UNIX Toolbox: 1000+ Commands for FreeBSD, OpenBSD and NetBSD by Christopher Negus and Francois Caen . From the review : BSD Unix Toolbox (BUT) is a straightforward system administration book that could apply to many Unix-like operating systems. The title mentions "BSD" but the BSD-specific material is FreeBSD-oriented. The non-FreeBSD sections (such as using a shell) could apply to any Unix-like OS, so in that sense other BSDs like OpenBSD or NetBSD are "covered." However, sections like Ch 2 (Installing FreeBSD and Adding Software) have no OpenBSD or NetBSD equivalents. Nevertheless, I recommend BUT for anyone looking for a rapid introduction to BSD system administration. Amazon.com also just published my three star review of Network Administration with FreeBSD 7 by Babak Farrokhi. From the review : I am always glad to see new books on FreeBSD. The best authors look at the current market, identify gaps, and f

Last month I participated in a panel hosted by the US Air Force. One of my co-panelists, Jim Stogdill , summarized some of the event in his recent post Sharing vs. Protecting, Generativity on DoD Networks . I'd like to add the following thoughts. Before the event most of the panelists met for breakfast. One of the subjects we discussed was the so-called "People's Army" China uses for conducting cyber operations. You can read about this phenomenon in the great book The Dark Visitor . In the US, our DoD relies upon professional, uniformed military members, government civilians, and an immense contracting force to defend the nation and project its military power. In China, their PLA mixes uniformed military with ordinary civilians, some of whom act at the behest of the military and government, with others acting on their own for "patriotic means." This latter model is almost unheard of in the US and completely outside any formalized mechanism offered by

I really liked this article from a recent Economist: Economics focus: Control freaks; Are “randomised evaluations” a better way of doing aid and development policy? : Laboratory scientists peer into microscopes to observe the behaviour of bugs. Epidemiologists track sickness in populations. Drug-company researchers run clinical trials. Economists have traditionally had a smaller toolkit. When studying growth, they put individual countries under the microscope or conduct cross-country macroeconomic studies (a bit like epidemiology). But they had nothing like drug trials. Economic data were based on observation and modelling, not controlled experiment. That is changing. A tribe of economists, most from Harvard University and the Massachusetts Institute of Technology (MIT), have begun to champion the latest thing in development economics: “randomised evaluations” in which different policies—to boost school attendance, say—are tested by randomly assigning them to different groups... Random

You all know how environmentally-conscience I am. Actually, I don't consider myself to be all that "green," aside from the environmental science merit badge I earned as a Scout. However, working for a global company (and especially the Air Force, in a prior life) reinforces one of my personal tenets: move data, not people . In other words, I look for ways to acquire security data remotely, and move it to me. I'd rather not fly to a location where the information resides; data centers are too distributed, cold, noisy, and cramped for me to want to spend a lot of time there. So, when Bill Brenner of CSO asked if I had thoughts on "Green IT," I think I surprised him by answering postively. You can read some of what I said in his article Cost-Cutting Through Green IT Security: Real or Myth? For Richard Bejtlich, director of incident response at General Electric, the biggest green security challenge is in how the company moves people around. Incident respo