TaoSecurity Blog

I am an historian . I practice digital security, but I earned a bachelor's of science degree in history from the United States Air Force Academy. (1) Historians create products by analyzing artifacts, among which the most significant is the written word. In my last post , I talked about IOCs, or indicators of compromise. Do you know the origin of the term? I thought I did, but I wanted to rely on my historian's methodology to invalidate or confirm my understanding. I became aware of the term "indicator" as an element of indications and warning (I&W), when I attended Air Force Intelligence Officer's school in 1996-1997. I will return to this shortly, but I did not encounter the term "indicator" in a digital security context until I encountered the work of Kevin Mandia. In August 2001, shortly after its publication, I read Incident Response: Investigating Computer Crime , by Kevin Mandia, Chris Prosise, and Matt Pepe (Osborne/McGraw-Hill). I ...

In response to my post More on Threat Hunting , Rob Lee asked : [D]o you consider detection through ID’ing/“matching” TTPs not hunting? To answer this question, we must begin by clarifying "TTPs." Most readers know TTPs to mean tactics, techniques and procedures, defined by David Bianco in his Pyramid of Pain post as: How the adversary goes about accomplishing their mission, from reconnaissance all the way through data exfiltration and at every step in between. In case you've forgotten David's pyramid, it looks like this. It's important to recognize that the pyramid consists of indicators of compromise (IOCs). David uses the term "indicator" in his original post, but his follow-up post from his time at Sqrrl makes this clear: There are a wide variety of IoCs ranging from basic file hashes to hacking Tactics, Techniques and Procedures (TTPs). Sqrrl Security Architect, David Bianco, uses a concept called the Pyramid of Pain to categorize...

I just read a post by Symantec titled Linux Back Door Uses Covert Communication Protocol . It describes a new covert channel on Linux systems. A relevant excerpt follows: [T]he attackers devised their own stealthy Linux back door to camouflage itself within the Secure Shell (SSH) and other server processes. This back door allowed an attacker to perform the usual functionality—such as executing remote commands—however, the back door did not open a network socket or attempt to connect to a command-and-control server (C&C). Rather, the back door code was injected into the SSH process to monitor network traffic and look for the following sequence of characters: colon, exclamation mark, semi-colon, period (“:!;.”). After seeing this pattern, the back door would parse the rest of the traffic and then extract commands which had been encrypted with Blowfish and Base64 encoded. :!;.UKJP9NP2PAO4 Figure. Example of injected command The attacker could then make normal connection re...

Two weeks ago today our team at Mandiant was feverishly preparing the release of our APT1 report . In the twelve days that followed publication on the evening of Monday the 18th, I've been very pleased by the amount of constructive commentary and related research published online. In this post I'd like to list those contributions that I believe merit attention, in the event you missed them the first time around. These sorts of posts are examples of what the security community can do to advance our collective capability to counter digital threats. Please note I avoided mass media accounts, interviews with Mandiant team members, and most general commentary. They are listed in no particular order. Seth Hall (Bro): Watching for the APT1 Intelligence Jason Wood (SecureIdeas): Reading the Mandiant APT1 Report Chris Sanders: Making the Mandiant APT1 Report Actionable Symantec: APT1: Q&A on Attacks by the Comment Crew Tekdefense (NoVA Infosec): MASTIFF Analysis of APT...

In a recent Tweet I recommended reading Joe Stewart's insightful analysis of malware involved in Google v China . Joe's work is stellar as always, but I am reading more and more commentary that shows many people don't have the right frame of reference to understand this problem. In brief, too many people are focusing on the malware alone. This is probably due to the fact that the people making these comments have little to no experience with the broader problems caused by advanced persistent threat. It's enough for them to look at the malware and then move to the next sample, or devise their next exploit, and so on. Those of us responsible for defending an enterprise can't just look at the problem from a malware, or even a technical, perspective. I was reminded of this imperative when I read Waziristan: The Last Frontier in a recent Economist magazine. [I]t is tempting to think Waziristan has hardly changed since those colonial days... Mostly, [the Pakista...

This is the second in a series of "mindset" posts where I'd like to outline how I've been thinking of various aspects of incident detection and response. My primary focus for these discussions will be intrusions. I'd like to discuss incident detection paradigms . These are ways that security people tend to think when they are trying to identify intrusions. I'm going to list the three attitudes I've encountered. Detection is futile. This school of thought says that some intruders are so crafty that it is not possible to detect them. I consider this paradigm short-sighted and defeatist. If you read the intruder's dilemma you'll know that it is generally not possible for intruders to hide themselves perfectly, continuously, perpetually. True, as the intruder's persistence time decreases, and as the amount of data exfiltrated decreases, it becomes more difficult to detect the intruder. However, both conditions are good for the defense. The...

This is a follow-up to my post Response for Daily Dave . I realized I had a similar exchange three years ago, summarized in my post Response to Daily Dave Thread . Since I don't seem to be making much progress in this debate, I decided to render it in two slides. First, I think everyone is familiar with the Defender's Dilemma. The intruder only needs to exploit one of the victims in order to compromise the enterprise. You might argue that this isn't true for some networks, but in most places if you gain a foothold it's quickly game over elsewhere. What Dave and company don't seem to appreciate is that there is a similar problem for attackers. I call it the Intruder's Dilemma. The defender only needs to detect one of the indicators of the intruder’s presence in order to initiate incident response within the enterprise. What's interesting about this reality is that it applies to a single system or to a collection of systems. Even if the intruder only compr...

A blog reader posted the following comment to my post Network Security Monitoring Lives : How do you use NSM to monitor the growing population of remote, intermittently connect mobile computing devices? What happens when those same computers access corporate resource hosted by a 3rd party such as corporate SaaS applications or storage in the cloud? This is a great question. The good news is we are already facing this problem today. The answer to the question can be found in a few old principles I will describe below. Something is better than nothing. I've written about this elsewhere: computer professionals tend to think in binary terms, i.e., all or nothing. A large number of people I encounter think 'if I can't get it all, I don't want anything." That thinking flies in the face of reality. There are no absolutes in digital security, or analog security for that matter. I already own multiple assets that do not strictly reside on any single network that I ...

One of the tenets of Network Security Monitoring, as repeated in Network Monitoring: How Far? , is collect as much data as you can, given legal, political, and technical means (and constraints) because that approach gives you the best chance to detect and respond to intrusions. The Black Hat Briefings always remind me that such an approach makes sense. Having left the talks, I have a set of techniques for which I can now mine my logs and related data sources for evidence of past attacks. Consider these examples: Given a set of memory dumps from compromised machines, search them using the Snorting Memory techniques for activity missed when those dumps were first collected. Review Web proxy logs for the presence of IDN in URIs. Query old BGP announcements for signs of past MITM attacks. You get the idea. The key concept is that none of us are smart enough to know how a certain set of advanced threats are exploiting us right now, or how they exploited us in the past. Once we get a ...

A regular blog reader and Network Security Monitoring practitioner sent me these questions last month, so I'd like to answer them here. 1. Are all alert data created equal? This question originates with my employment at an MSSP where we process many types of alert data from Dragon IDS, Cisco IPS and ISS. Snort and Sourcefire strangely are underrepresented. My question is if Dragon IDS, Cisco IPS, ISS, Snort and Sourcefire all looked at the same full-content data, would they all produce the same results? I think not and would like to empirically verify this theory. Testing detection systems is a complicated topic. I am not sure what methodology a place like NSS Labs uses. I bet they get varying results depending on the product. If you read A Tool for Offline and Live Testing of Evasion Resilience. in Network Intrusion Detection Systems you will see big differences between Snort and Bro, for example. 2. When is an analyst no longer an analyzer of data but an analyzer of dashboar...

Last week I attended at spoke at the 2008 SANS WhatWorks in Incident Response and Forensic Solutions Summit organized by Rob Lee. The last SANS event I attended was the 2006 SANS Log Management Summit . I found this IR and forensics event much more valuable, and I'll share a few key points from several of the talks. Steve Shirley from the DoD Cyber Crime Center (DC3) said "Security dollars are not fun dollars." In other words, what CIO/CTO wants to spend money on security when he/she could buy iPhones? Rob Lee noted than an Incident Response Team (IRT) needs the independence to take actions during an emergency. I've called this authority the ability to declare a "Network State of Emergency" (NSOE). When certain preconditions are met, the IRT can ask a business owner to declare a NSOE, just like a state governor can declare a state of emergency during a forest fire or other natural disaster. The IRT can then exercise predefined powers (like host...

I was asked to write an article for an upcoming issue of Information Security Magazine based on my Engineering Disasters blog post. I had the following thought after writing that article. When an engineering catastrophe befalls the "real" or "analog" world, it's often very visible. Failed bridges collapse, levees break, sink holes swallow buildings, and so on. If you look closely enough, prior to ultimate failure you see indications of pending doom. Cracks appear in concrete, materials swell or contract, groaning noises abound, etc. This is generally not the case in the digital world. It is possible for an enterprise to be completely owned by unauthorized parties, without any overt signs. If one knows where to look of course, indicators can be seen, and evidence of compromise can be gathered, analyzed, and escalated. This is the reason I advocate network security monitoring (NSM) and conducting traffic threat assessments (TTAs).

I've been performing a network security monitoring assessment for a client this week. I use interviews, observations, and documentation review to provide findings, discussion, and recommendations for improving your incident detection and response operations. During this process I was asked if I knew ways to measure packet loss on open source sensors. (This client uses FreeBSD, which is helpful!) Today I remembered work by Christian SJ Peron on bpfstat , available only on FreeBSD 6.0. bpfstat provides statistics like the following. Here I am running Tcpdump and Trafshow, and bpfstat is reporting packet collection information on interface sf0 every 1 second. bpfstat -i 1 -I sf0 pid netif flags recv drop match sblen hblen command 1682 sf0 p--s- 6337 0 6337 3844 0 trafshow 780 sf0 p--s- 38405 0 38405 11380 0 tcpdump 1682 sf0 p--s- 7142 0 7142 22046 0 trafshow 780 sf0 p--s- 39210 0 39210 14588 0 tcpdump 1682 sf0 p--...

I found this ad in Network Computing magazine. It did not address a security concern, but I thought the image was priceless. I see the goalie as representing most preventative security countermeasures. Player 9 is the threat. The soccer ball is an exploit. They are attacking an enterprise, represented by the soccer net. The goalie is addressing the threat he expects, namely someone trying to score from the side of the net he is defending. In many cases the goalie is "fighting the last war;" perhaps the last time he was scored upon came from the side he now defends? The threat is smart and unpredictable, attacking a different part of the net. The net itself (the enterprise) is huge. Not only is the front of the net open, the net itself is riddled with holes. A particularly clever attacker might see his objective as getting the ball in the net using any means necessary. That might include cutting the ball into smaller pieces and sending the fragments through holes ...

I was dismayed to see the following thread in the bleeding-sigs mailing list recently. Essentially someone suggested using PCRE to look for this content on Web pages and email: (jihad |al Qaida|allah|destroy|kill americans|death|attack|infidels) (washington|london|new york) Here is part of my reply to the Bleeding-Sigs thread. These rules are completely inappropriate. First, there is no digital security aspect of these rules, so the " provider exception " of the wiretap act is likely nullified. Without obtaining consent from the end users (and thereby protection under the "consent exception"), that means the IDS is conducting a wiretap. The administrator could go to jail, or at least expose himself and his organization to a lawsuit from an intercepted party. Second, the manner in which most people deploy Snort would not yield much insight regarding why these rules triggered. At best a normal Snort user would get a packet containing content that caused Snort to ...

If you're in Myrtle Beach, SC for the 2005 Techno Security Conference , stop by and say hello. I should be at the 3:00 pm Monday book signing, and I will be speaking on behalf of Tenable Security at 7:00 pm Monday. I hope to squeeze in a Monday afternoon visit to managed security vendor LURHQ while I am here as well. This is my first Techno Security Conference, but I don't plan to see any talks other than those by Ron Gula and Marcus Ranum tomorrow morning. The conference organizers told me this is the 7th such event, and they have over 1,000 attendees. The vendor exhibits and program seems very host-based forensics-centric. It seems that every associates the word "forensics" with host-based evidence, with few exceptions. I am sensitive to this situation as I devote several chapters in my new book Extrusion Detection to network-centric incident response and forensics. I intend for these chapters to supplement existing excellent works that take a traditional...

Today I skimmed the latest report from the President's Information Technology Advisory Committee (PITAC) titled Cyber Security: A Crisis of Prioritization ( .pdf ). This Government Computer News Story summarizes the reports findings. Briefly, they are the nation's critical infrastructures remain vulnerable to attack, and federal security research and development funding is misallocated. PITAC estimates "there are fewer than 250 active cyber security or cyber assurance specialists, many of whom lack either formal training or extensive professional experience in the field." I agree with this claim; it is very difficult to find anyone with deep and broad security degrees and experience I would trust to teach future practitioners. I was pleased to see the report list the following as some of its ten research priorities, as they are near to my own interests: - Monitoring and Detection . Regardless of progress made in the preceding research areas, unanticipated ev...

I read in the latest SANS NewsBites that UC San Diego suffered another intrusion in November 2004, jeopardizing the personal information of about 3,500 people who had taken courses at UCSD Extension. This incident follows a well-publicized intrusion in April 2004 putting at risk personal data on 380,000 people . In both cases UC appears to have caught unstructured threats, as each intruder used the systems as warez depositories for pirated movies and music. I was shocked by this claim concerning the latest intrusion: "Officials said it took two months to notify those who were affected because officials first needed to determine the extent of the breach." This is exactly why I promote network security monitoring as a means to rapidly scope the extent of intrusions. First, generating indicators and warnings in the form of alert data (usually from IDSs) and statistical data gives security professionals a good chance of identifying an intrusion as it happens or shortly th...

One of the regulars in the #snort-gui IRC channel of irc.freenode.net asked me the following question via email. This is an excerpt, and my response follows: "I am very interested to hear your insight on the topic of 'incident containment' via TCP resets... I am concerned about whether or not incident containment should even be used. From a purely technical standpoint it seems like 'Sure, it's better than just leaving the connection live. It's helping to interfere, after-all.' But when I think about it in a real-world application, it seems like many malicious hackers will notice TCP resets as a clear sign they have been spotted. It seems like this understanding on their part will cause them to attempt to shoot in again even if only for the brief seconds required to 'rm -rf /'. The alternative, no TCP resets, it seems the intruder will most likely think their presence is yet unknown and they may be content with their backdoor... I guess the overall ...

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