Radiation Detection Mirrors Intrusion Detection

Yesterday I heard part of the NPR story Auditors, DHS Disagree on Radiation Detectors. I found two Internet sources, namely DHS fudged test results, watchdog agency says and DHS 'Dry Run' Support Cited, and I looked at COMBATING NUCLEAR
SMUGGLING: Additional Actions Needed to Ensure Adequate Testing of Next Generation Radiation Detection Equipment (.pdf), a GAO report.

The report begins by explaining why it was written:

The Department of Homeland Security’s (DHS) Domestic Nuclear Detection Office (DNDO) is responsible for addressing the threat of nuclear smuggling. Radiation detection portal monitors are key elements in our national defenses against such threats. DHS has sponsored testing to develop new monitors, known as advanced spectroscopic portal (ASP) monitors.

In March 2006, GAO recommended that DNDO conduct a cost-benefit analysis to determine whether the new portal monitors were worth the additional cost. In June 2006, DNDO issued its analysis. In October 2006, GAO concluded that DNDO did not provide a sound analytical basis for its decision to purchase and deploy ASP technology and recommended further testing of ASPs. DNDO conducted this ASP testing at the Nevada Test Site (NTS) between February and March 2007.

GAO's statement addresses the test methods DNDO used to demonstrate the performance capabilities of the ASPs and whether the NTS test results should be relied upon to make a full-scale production decision.

GAO recommends that, among other things, the Secretary of Homeland Security delay a full-scale production decision of ASPs until all relevant studies and tests have been completed, and determine in cooperation with U.S. Customs and Border Protection(CBP), the Department of Energy (DOE), and independent reviewers, whether additional testing is needed. (emphasis added)

Notice that a risk analysis was not done. Rather, a cost-benefit analysis was done. This is consistent with the approach I liked in the book Managing Cybersecurity Resources, although in that book the practicalities of assigning certain values made the exercise fruitless. Here the cost-benefit approach has a better chance of working.

Next the report summarizes the findings:

Based on our analysis of DNDO’s test plan, the test results, and discussions with experts from four national laboratories, we are concerned that DNDO’s tests were not an objective and rigorous assessment of the ASPs’ capabilities. Our concerns with the DNDO’s test methods include the following:

• DNDO used biased test methods that enhanced the performance of the ASPs. Specifically, DNDO conducted numerous preliminary runs of almost all of the materials, and combinations of materials, that were used in the formal tests and then allowed ASP contractors to collect test data and adjust their systems to identify these materials.
  
  It is highly unlikely that such favorable circumstances would present themselves under real world conditions.


• DNDO’s NTS tests were not designed to test the limitations of the ASPs’ detection capabilities -- a critical oversight in DNDO’s original test plan. DNDO did not use a sufficient amount of the type of materials that would mask or hide dangerous sources and that ASPs would likely encounter at ports of entry.
  
  DOE and national laboratory officials raised these concerns to DNDO in November 2006. However, DNDO officials rejected their suggestion of including additional and more challenging masking materials because, according to DNDO, there would not be sufficient time to obtain them based on the deadline imposed by obtaining Secretarial Certification by June 26. 2007.
  
  By not collaborating with DOE until late in the test planning process, DNDO missed an important opportunity to procure a broader, more representative set of well-vetted and characterized masking materials.


• DNDO did not objectively test the performance of handheld detectors because they did not use a critical CBP standard operating procedure that is fundamental to this equipment’s performance in the field.

(emphasis added)
Let's summarize.

• DNDO helped the vendor tune the detector.


• DNDO did not test how the detectors could fail.


• DNDO did not test the detectors' resistance to evasion.


• DNDO failed to follow an important standard operating procedure.

I found all of this interesting and relevant to discussions of detecting security events.

Read More

Experts: IDS is here to stay

Imagine my surprise when I read Experts: IDS is here to stay:

Conventional wisdom once had it that intrusion prevention systems (IPS) would eliminate the need for intrusion defense systems (IDS). But with threats getting worse by the day and IT pros needing every weapon they can find, the IDS is alive and well.

"IPS threatened to hurt the IDS market but IDS is better equipped to inspect malware," said Chris Liebert, a security analyst with Boston-based Yankee Group Research Inc. "IPS specializes in blocking, so each still have their own uses, and that's why IDS is still around."

IDS is now part of a larger intrusion defense arsenal that includes vulnerability management and access control technology. In fact, one analyst believes standalone IDS products will still be in demand five years from now while IPS technology will likely be folded in firewall products.

"In the long term, I do not think IPS devices will remain as separate products," said Eric Maiwald, a senior security analyst for Midvale, Utah-based Burton Group. "We see this happening already. All of the major firewall vendors offer some amount of IPS functionality in their products. At the same time, there is much firewall-like capability in the IPS products."

IDS products will probably remain as separate devices because of the need to monitor happenings on a network and monitor actions of other policy enforcement points, he said. (emphasis added)

Wow, imagine that. Anyone who's read my books or this blog for any amount of time knows I've advocated this position for years. What's an "IPS" anyway? It's a filtering device, aka "firewall." What's an "IDS"? It's an attack or incident indication system. The two functions are completely different and should be separate. It's too late for me to say any more now, but I wanted to note this article before I forget I read it.

Read More

No Undetectable Breaches

PaulM left an interesting comment on my post NORAD-Inspired Security Metrics:

...what if the enemy has a stealth plane that we cannot detect via radar, satellite, wind-speed variance, or any other deployed means? And what if your intel doesn't tell us that such a vehicle exists? Then we have potentially millions of airspace breaches every year and our outcome metrics are not helping.

I'm not disagreeing with you that outcome metrics are ideally better data than compliance metrics. However, outcome metrics are difficult to identify and collect data on, and it can be difficult to discern how accurate your metrics actually are.

At least with compliance metrics, we can determine how good we are at doing what it is we say that we do. It has little relevance to operational security, but it's easy and the auditors seem to like it.

For the case of a single breach, or even several breaches, it may be possible for them to happen and be completely undetectable. However, I categorically reject the notion that it is possible to suffer sustained, completely undetectable breaches and remain unaware of the damage. If you are not suffering any damage due to these breaches, then why are you even trying to deter, detect, and respond to them in the first place?

Let me put this in perspective by considering labels attached to classified information as designated by Executive Order 12356:

(a) National security information (hereinafter "classified information") shall be classified at one of the following three levels:

1. "Top Secret" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause exceptionally grave damage to the national security.


2. "Secret" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause serious damage to the national security.


3. "Confidential" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause damage to the national security.

We want to protect the confidentiality of classified information to avoid the losses described above. What happens if we suffered sustained breaches (thefts) of Top Secret data? Are we not going to detect that our national security concerns are being hammered, since we are suffering "exceptionally grave damage"?

This is one way spies are unearthed. If your missions are constantly failing because the enemy seems to know your plans, then your suffering a breach you haven't detected it.

Finally, if you are suffering breaches and your input-based metrics aren't detecting them either, what good are they? Talk about a real waste of money. "It's easy and auditors seem to like it?" Good grief.

Read More

Training an IDS

Thanks to the newly named Threat Level I read Women at Love Field 'Acting Suspiciously' and Airport Watch Figure Confirms Terrorist Tie. You can obviously make up your own mind about these two, but I'm glad the police were alert enough to grab them. Here's a few choice quotes. I promise to tie this to digital security.

"I'm a trained sniper and proud of it," Ms. Al-Homsi said in an interview Thursday after first refusing to comment on whether she has any terrorism ties. She then said no.

Unless this is a lie, I doubt this lady received training in the US military. So where else would she be trained to be a sniper?

She said that she practices her rifle skills at the Alpine Shooting Range in Fort Worth. An employee confirmed that she's been going there for years.

"In all the Muslim garb, shooting an assault weapon, it seemed at first like she was trying to draw attention," said Dave Rodgers. "But then she came out so much, it became normal."

Hmm, like that back door installed before you started looking for it? Assuming the "sniper" really is a threat, it sounds like she trained shooting range employees to accept her as normal simply by being a frequent customer -- like that regular 2 am data transfer out of your site. It must be an authorized backup activity, right? It's always happening. That makes it normal... I hope?

Read More

Bro Basics Follow-Up

In my post Bro Basics I outlined the steps I took to install Bro. Since Friday I've taken a few more steps to get reports working.

First, I re-ran make brolite-install as root.

Next, I noticed errors in mail from bro:

Date: Sat, 7 Apr 2007 00:10:01 -0400 (EDT)
From: analyst@cel433.taosecurity.com (Cron Daemon)
To: analyst@cel433.taosecurity.com
Subject: Cron <analyst@cel433> ( nice -n 19
+/usr/local/bro-1.2.1/scripts/site-report.pl )
X-Cron-Env: <BROHOME=/usr/local/bro-1.2.1>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/home/analyst>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=analyst>
X-Cron-Env: <USER=analyst>
  
Can't locate Bro/Config.pm in @INC (@INC contains:
+/usr/local/bro/perl/lib/perl5/site_perl /usr/local/lib/perl5/5.8.8/BSDPAN
+/usr/local/lib/perl5/site_perl/5.8.8/mach /usr/local/lib/perl5/site_perl/5.8.8
+/usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.8/mach
+/usr/local/lib/perl5/5.8.8 .) at /usr/local/bro-1.2.1/scripts/site-report.pl
+line 25.
BEGIN failed--compilation aborted at /usr/local/bro-1.2.1/scripts/site-report.pl
+line 25.

I looked around and found Bro/Config.pm in /usr/local/bro-1.2.1/perl/lib/perl5/site_perl/5.8.8/Bro/Config.pm.

I looked at site-report.pl and saw this:

# look for our modules first
use lib '/usr/local/bro/perl/lib/perl5/site_perl';

Since I installed Bro in /usr/local/bro-1.2.1 I thought making a symlink from /usr/local/bro to /usr/local/bro-1.2.1 was the best approach.

The next time the report script tried to run I got a new error.

/libexec/ld-elf.so.1: /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so:
 Undefined +symbol "__h_errno"

Weird. I compared libperl.so on cel433 (the Bro sensor) with the same file on poweredge, another FreeBSD box.

cel433:/home/analyst$ file /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
/usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so: ELF 32-bit LSB shared object,
 Intel 80386, version 1 (FreeBSD), not stripped
cel433:/home/analyst$ md5 /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
MD5 (/usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so) =
 a5d4a3b0bbc9b4b9e0cf136e35546651

cel433:/home/analyst$ ls -al /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
-r-xr-xr-x  1 root  wheel  1143233 Sep  2  2006
 /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so

poweredge:/home/richard$ file /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so 
/usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so: ELF 32-bit LSB shared object,
 Intel 80386, version 1 (FreeBSD), not stripped
poweredge:/home/richard$ md5 /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
MD5 (/usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so) = 
 061ee20f36b76dc5a2fb22de37caa987

poweredge:/home/richard$ ls -al /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
-r-xr-xr-x  1 root  wheel  1143233 Jun 21  2006
 /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so

The files appear the same but the MD5 hashes don't match. I fixed that by copying what I presumed was the good copy from poweredge:

cel433:/root# scp richard@poweredge:/usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
 /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
Password:
libperl.so                                    100% 1116KB   1.1MB/s   00:00    
cel433:/root# md5 /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
MD5 (/usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so) =
 061ee20f36b76dc5a2fb22de37caa987

That was the last fix. I got an email with the following report, saved at /usr/local/bro-1.2.1/reports/taosecuritycom.1176091803.24141.rpt.

Site Report for taosecuritycom, from 2007/04/08 00:00:30 to 2007/04/09 00:00:30
generated on Mon Apr  9 00:11:27 2007
========================================================================
Summary
========================================================================
  Incident Count: 0

========================================================================
Incident Details
========================================================================
     No data to report
========================================================================
Signature Distributions
========================================================================
  No data to report

========================================================================
Scans
========================================================================
     No data to report

========================================================================
Connection Log Summary
========================================================================
Site-wide connection statistics

    Successful:   7506
    Unsuccessful: 19341
    Ratio: 1:2.576


Top 20 Sources

               Host                      IP         Bytes   Conn. Count
  -------------------------------  ---------------  ------  ------------
  ...3-202-28.hsd1.va.comcast.net  69.143.202.28      17 M          7504
               sd-6260.dedibox.fr  88.191.38.164         0             1
  ...46.static.newcomamericas.net  200.30.136.146        0             1


Top 20 Destinations

               Host                      IP         Bytes   Conn. Count
  -------------------------------  ---------------  ------  ------------
            eh-in-f191.google.com  72.14.207.191      52 M          2103
         vhost.identityvector.com  209.40.96.212     175 M           660
                  207.159.120.151  207.159.120.151   141 K           501
        208-45-133-152.excite.com  208.45.133.152    222 K           373
                  207.159.120.146  207.159.120.146   72528           258
                    64.147.181.34  64.147.181.34     1.8 M           258
                      ad.turn.com  70.42.138.14      1.6 M           146
         208-45-133-13.excite.com  208.45.133.13     1.7 M           138
        208-45-133-134.excite.com  208.45.133.134    91943           131
                    38.96.134.241  38.96.134.241     85585           127
         208-45-133-23.excite.com  208.45.133.23     2.2 M           127
  ...9.142.97.available.above.net  209.249.142.97    66912           106
                     204.176.49.2  204.176.49.2      15182           101
     lib1.store.vip.mud.yahoo.net  68.142.205.139    175 K            85
                    64.147.181.44  64.147.181.44     1.2 M            84
                    64.147.181.32  64.147.181.32     3.3 M            80
  ...49.142.8.available.above.net  209.249.142.8     23520            73
                  wzus.wc.ask.com  65.214.37.120     25009            65
  ...eploy.akamaitechnologies.com  72.247.28.57      518 K            55
                    38.96.134.245  38.96.134.245     17459            54


Top 20 Local Email Senders

                 Hostname                        IP          Conn. Count
  ---------------------------------------  ---------------  ------------
      c-69-143-202-28.hsd1.va.comcast.net  69.143.202.28               7


Top 20 Services

  Service        Conn. Count  % of Total   Bytes In  Bytes Out
  ------------  ------------  ----------  ---------  ---------
  http                  7003       93.30      275 M       12 M
  https                  254        3.38      3.1 M      1.0 M
  other                  193        2.57      1.2 M      3.9 M
  pop-3                   23        0.31      46361       1187
  whois                   19        0.25      16646        309
  smtp                     7        0.09       1536       7542
  spop                     5        0.07      35772       3283
  ssh                      2        0.03          0         82

========================================================================
Byte Transfer Pairs
========================================================================
Hot Report - Top 20
                                                    Local      Remote    Conn.
     Local Host               Remote Host           Bytes      Bytes     Count
-----------------------  -----------------------  ---------  ---------  -------
...hsd1.va.comcast.net   ....identityvector.com      153296      175 M  1276
...hsd1.va.comcast.net   eh-in-f191.google.com       812404     52.5 M  6320
...hsd1.va.comcast.net   ...maitechnologies.com       12997     12.2 M  4
...hsd1.va.comcast.net   64.147.181.31               4503 K      15328  32
...hsd1.va.comcast.net   64.147.181.32               142095     3414 K  164
...hsd1.va.comcast.net   ...-70.mc.videotron.ca      2492 K       4261  1
...hsd1.va.comcast.net   194.117.143.76                6885     2360 K  6
...hsd1.va.comcast.net   ...5-133-23.excite.com      212442     2213 K  254
...hsd1.va.comcast.net   64.147.181.34               1145 K     1867 K  516
...hsd1.va.comcast.net   66.11.53.136                  1084     1811 K  4
...hsd1.va.comcast.net   ...5-133-13.excite.com      340294     1751 K  276
...hsd1.va.comcast.net   ad.turn.com                 136361     1665 K  292
...hsd1.va.comcast.net   38.99.76.85                  12127     1648 K  42
...hsd1.va.comcast.net   ntserver-4d41.4dv.net          673     1478 K  5
...hsd1.va.comcast.net   81.216.125.158              1409 K       2932  1
...hsd1.va.comcast.net   64.147.181.44               574291     1250 K  198
...hsd1.va.comcast.net   ...ices.brightcove.com       36951     1073 K  92
...hsd1.va.comcast.net   194.117.143.77                4037     1042 K  6
...hsd1.va.comcast.net   gfo-cm.nexcess.net           43809     725792  86
...hsd1.va.comcast.net   ...-133-152.excite.com      674704     227462  746

It's basically connection logging information, since I'm running a default brolite installation. As I enable other components I expect to see other details.

Read More

Bro Basics

When I wrote The Tao of Network Security Monitoring I discussed Bro, another open source intrusion detection system frequently ignored by other authors (at least back when I wrote Tao). I haven't used Bro in production but blogging by my friend Geek00l about Bro convinced me I needed to take a second look at Bro. In this post I'd like to document what I needed to do to get Bro running on a test sensor.

I made a directory called /usr/local/bro-1.2.1 owned by user analyst. Then I acted as follows:

cel433:/usr/local/src$ fetch ftp://bro-ids.org/bro-1.2.1-devel.tar.gz
...edited...
cel433:/usr/local/src$ tar -xzvf bro-1.2.1-devel.tar.gz
...edited...
cel433:/usr/local/src/bro-1.2.1$ which flex
/usr/bin/flex
cel433:/usr/local/src/bro-1.2.1$ which bison
/usr/local/bin/bison
cel433:/usr/local/src/bro-1.2.1$ ls -ald /usr/local/bro-1.2.1
drwxr-xr-x  2 analyst  analyst  512 Apr  6 19:42 /usr/local/bro-1.2.1
cel433:/usr/local/src/bro-1.2.1$ ./configure --prefix=/usr/local/bro-1.2.1
...edited...
                 Bro Configuration Summary
==========================================================

  - Debugging enabled:      no
  - OpenSSL support:        yes 
  - Non-blocking main loop: yes
  - Non-blocking resolver:  yes
  - Installation prefix:    /usr/local/bro-1.2.1
  - Perl interpreter:       /usr/local/bin/perl5
  - Using basic_string:     yes
  - Using libmagic:         Yes
  - Using libclamav:        No
  - Pcap used:              system-provided

cel433:/usr/local/src/bro-1.2.1$ make
...edited...
cel433:/usr/local/src/bro-1.2.1$ make install
...truncated...

Pretty simple so far. According to the Quick Start Guide the easiest way to get going is to use the brolite configuration script, so I used that next. I did not run this as root, so as a result a few of the operations failed (my fault). I note them below. None were fatal.

cel433:/usr/local/src/bro-1.2.1$ make install-brolite
...edited...
/usr/bin/install -c -d /usr/local/etc/rc.d/
install: chmod 755 /usr/local/etc/rc.d/: Operation not permitted
...edited...
Running Bro Configuration Utility

Configure settings in bro.cfg? (YES/no)  [YES] 
Values enclosed in '[ ]'s are the default value set if you hit return.

Using defaults from bro.cfg.example
You need to be root when you run this script for it to
be fully effective. Please login as root and rerun this
script (or the make install that called this script).

This script will run as a non-root user,  but it will not
be able to tune the system or install system files. 
It will only be able to create a bro.cfg file.
Checking interfaces ....Done.
 Log archive directory [/usr/local/bro-1.2.1/archive] 
 User id to install and run Bro under [analyst] 
 Interface name to listen on.  The default is to use the busiest one found. [dc0] 
 Site name for reports (i.e. LBNL, FOO.COM, BAZ.ORG) [taosecuritycom] 
 Starting time for a report run (0001 is 12:01 am and 1201 is 12:01pm) [0010] 
 How often (in hours) to generate an activity report [24] 
 Email reports? (YES/no)  [YES] 
 Email address for local reports to be mailed to [bro@localhost] analyst@localhost
 Do you want to encrypt email reports (YES/NO) [NO] 
*** You need to hand edit your local networks in the file
*** /usr/local/bro-1.2.1/site/local.site.bro. Please read the file for an
*** example of what it should look like

Bro Configuration Finished. 
Press any key to now to continue.  
...edited...
/usr/bin/install -c bro.rc /usr/local/etc/rc.d/bro.sh
install: /usr/local/etc/rc.d/bro.sh: Permission denied
*** Error code 71 (ignored)
(cd s2b ; make install)
Making install in bro-include
...edited...
FreeBSD: Registering installation in the package database
Cannot create directory /var/db/pkg/bsdpan-Config-General-2.27: Permission denied
...edited...
Writing /usr/local/bro-1.2.1/perl/lib/perl5/site_perl/5.8.8/mach/auto/Bro/
 .packlist
FreeBSD: Registering installation in the package database
FreeBSD: Cannot determine short module description
FreeBSD: Cannot determine module description
Cannot create directory /var/db/pkg/bsdpan-Bro-Utilities-1.2: Permission denied
Appending installation info to /usr/local/bro-1.2.1/perl/lib/perl5/5.8.8/mach/
 perllocal.pod
/usr/sbin/chown -R `cat scripts/bro_user_id` /usr/local/bro-1.2.1/
*********************************************************
Please run "/usr/local/bro-1.2.1/etc/bro.rc --start" to start bro
*********************************************************

I made the following changes to account for the IP I would have Bro monitor.

cel433:/usr/local/bro-1.2.1/site$ diff local.site.bro.orig  local.site.bro
12c12
<     192.168.1.0/24,
---
>     #192.168.1.0/24,
14c14,15
<     10.1.0.0/16
---
>     #10.1.0.0/16
>     69.143.202.28/32

I tried to start Bro.

cel433:/root# /usr/local/bro-1.2.1/etc/bro.rc --start
bro.rc: Running as non-root user analyst
bro.rc: Starting ..........bro.rc: Failed to start Bro
/usr/local/bro-1.2.1/policy/scan.bro, line 92: warning: no such host: j5004.inktomisearch.com
/usr/local/bro-1.2.1/policy/scan.bro, line 92: warning: no such host: j5005.inktomisearch.com
/usr/local/bro-1.2.1/policy/scan.bro, line 93: warning: no such host: j5006.inktomisearch.com
/usr/local/bro-1.2.1/policy/scan.bro, line 93: warning: no such host: j100.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 93: warning: no such host: j101.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 94: warning: no such host: j3002.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 94: warning: no such host: si3000.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 94: warning: no such host: si3001.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 95: warning: no such host: si3002.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 95: warning: no such host: si3003.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 95: warning: no such host: si4000.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 96: warning: no such host: si4001.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 96: warning: no such host: si4002.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 96: warning: no such host: wm3018.inktomi.com
/usr/local/bro-1.2.1/bin/bro: problem with interface dc0
 - pcap_open_live: (no devices found) /dev/bpf0: Permission denied
... FAILED

Hmm. Let's change permissions on /dev/bpf0:

cel433:/root# ls -al /dev/bpf0
crw-------  1 root  wheel    0, 104 Mar  6 21:42 /dev/bpf0
cel433:/root# chmod 644 /dev/bpf0
cel433:/root# /usr/local/bro-1.2.1/etc/bro.rc --start
bro.rc: Running as non-root user analyst
bro.rc: Starting ..........bro.rc: Failed to start Bro
/usr/local/bro-1.2.1/policy/scan.bro, line 92: warning: no such host: j5004.inktomisearch.com
/usr/local/bro-1.2.1/policy/scan.bro, line 92: warning: no such host: j5005.inktomisearch.com
/usr/local/bro-1.2.1/policy/scan.bro, line 93: warning: no such host: j5006.inktomisearch.com
/usr/local/bro-1.2.1/policy/scan.bro, line 93: warning: no such host: j100.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 93: warning: no such host: j101.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 94: warning: no such host: j3002.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 94: warning: no such host: si3000.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 94: warning: no such host: si3001.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 95: warning: no such host: si3002.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 95: warning: no such host: si3003.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 95: warning: no such host: si4000.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 96: warning: no such host: si4001.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 96: warning: no such host: si4002.inktomi.com
/usr/local/bro-1.2.1/policy/scan.bro, line 96: warning: no such host: wm3018.inktomi.com
/usr/local/bro-1.2.1/bin/bro: problem with interface dc0
 - pcap_open_live: (no devices found) /dev/bpf1: Permission denied
... FAILED

Weird. Now it's trying to use /dev/bpf1. Let me change all /dev/bpf*:

cel433:/root# /usr/local/bro-1.2.1/etc/bro.rc --start
bro.rc: Running as non-root user analyst
bro.rc: Starting ............. SUCCESS

Cool, it's running:

cel433:/root# ps -auxww | grep bro
analyst 11237  3.9 11.1 14560 13472  p4  R     9:23PM   0:05.45 
 /usr/local/bro-1.2.1/bin/bro -W -i dc0 cel433.taosecurity.com.bro
analyst 11232  0.0  1.0  1724  1188  p4  I     9:23PM   0:00.03 /bin/sh 
 /usr/local/bro-1.2.1/etc/bro.rc --start
root    11455  0.0  0.2   348   208  p4  R+    9:25PM   0:00.00 grep bro

As you can tell from user analyst's crontab, Bro will be sending some reports periodically.

cel433:/root# exit
cel433:/usr/local/src/bro-1.2.1$ crontab -l
BROHOME=/usr/local/bro-1.2.1
# checkpoint Bro once a week
0 0 * * 1 /usr/local/bro-1.2.1/etc/bro.rc --checkpoint
10 00 * * * ( nice -n 19 /usr/local/bro-1.2.1/scripts/site-report.pl )
10 3 * * * (/usr/local/bro-1.2.1/scripts/mail_reports.sh 
 /usr/local/bro-1.2.1/etc/bro.cfg)
0 3 * * * (/usr/local/bro-1.2.1/scripts/bro_log_compress.sh)
# If you are process logs on a front end host, add this: 
#10 3 * * * (/usr/local/bro-1.2.1/scripts/push_logs.sh FrontendHost)

A look in the logs directory shows what Bro is doing:

cel433:/usr/local/bro-1.2.1/logs$
active_log
alarm.cel433.07-04-06_21.23.15
conn.cel433.07-04-06_21.23.15
ftp.cel433.07-04-06_21.23.15
http.cel433.07-04-06_21.23.15
info.cel433.07-04-06_21.23.15
irc.cel433.07-04-06_21.23.15
notice.cel433.07-04-06_21.23.15
signatures.cel433.07-04-06_21.23.15
smtp.cel433.07-04-06_21.23.15
software.cel433.07-04-06_21.23.15
step.cel433.07-04-06_21.23.15
weird.cel433.07-04-06_21.23.15

For one example, here is what Bro thought of an IRC session it saw:

cel433:/usr/local/bro-1.2.1/logs$ cat irc.cel433.07-04-06_21.17.44-07-04-06_21.17.44
1175908697.639398 #1 new connection 69.143.202.28/32819 > 140.211.166.3/IRC
1175908750.810028 #1 user 'deviousz' leaving

Here's an example of Bro's connection tracking output.

cel433:/usr/local/bro-1.2.1/logs$ tail conn.cel433.07-04-06_21.23.15 
1175911505.255911 ? 69.143.202.28 72.14.219.191 http 42774 80 tcp ? ? OTH L
1175911814.254729 10.202526 69.143.202.28 72.14.247.83 https 42793 443 tcp 1855 2167 SF L
1175911554.973023 ? 69.143.202.28 66.102.15.100 http 42717 80 tcp ? ? OTH L
1175911556.929263 ? 69.143.202.28 66.249.81.147 http 42733 80 tcp ? ? OTH L
1175911561.989633 ? 69.143.202.28 66.150.96.119 http 42740 80 tcp ? ? OTH L
1175911561.997082 ? 69.143.202.28 66.150.96.119 http 42741 80 tcp ? ? OTH L
1175911610.239664 ? 69.143.202.28 216.239.37.104 http 42758 80 tcp ? ? OTH L
1175911611.042594 ? 69.143.202.28 66.102.1.147 http 42764 80 tcp ? ? OTH L
1175911611.057809 ? 69.143.202.28 66.102.1.147 http 42765 80 tcp ? ? OTH L

The brolite script made this process much easier than the installation I did several years ago!

There is a lot of information available, and I'm only using the default brolite configuration. If you look at the Bro documentation, mailing list, Wiki, or Geek00l's blog, you'll see a ton of other capabilities. For now I'm going to try to make sense of what I have, and then enable other features as I learn more.

Read More

NSM and Intrusion Detection Differences

We had a good discussion this morning in the #snort-gui channel on irc.freenode.net. I was on my usual soap box complaining that no commercial tools provide all of the data I need to implement Network Security Monitoring, while developers and employees of a certain well-known intrusion detection system didn't understand why their product didn't meet my needs.

Sguil author Bamm Visscher cut through the argument with a very astute summary. He basically said that IDS developers want "Immaculate Detection" while NSM practitioners want "Immaculate Collection." Bamm is exactly right. From my experience I know that no detection product is 100% accurate, and that even good alerts require investigation to see what is happening and what else might be happening. IDS developers are rightly trying to improve the quality of their products, but many people interpret their avoidance of NSM collection as a sign it isn't necessary. In other words, detection can be so good that you never need to investigate. I know some IDS developers don't agree with this misplaced notion but they argue it's too expensive to collect the sorts of data I advocate. I argue that it's too expensive (in terms of damage to the enterprise) not to collect that NSM data.

I think we will see commercial solutions during the next 1-3 years that will give me the NSM data I need to detect and respond to intrusions. Already network forensic appliance vendors are publishing APIs that can be called by IDS/IPS/SIM/SEM/SIEM/etc. products for access to network traffic collected independently of any alerting mechanism. This is a great development and I can't wait to see this sort of arrangement in production.

Read More

Intrusion Detection RFCs

It's been three years since I think I blogged on this topic, but I noticed three RFCs on intrusion detection were published this month:

• RFC 4765: The Intrusion Detection Message Exchange Format (IDMEF)


• RFC 4766: Intrusion Detection Message Exchange Requirements


• RFC 4767: The Intrusion Detection Exchange Protocol (IDXP)

Is anyone using these? I think Prelude does, but how about commercial products?

Read More

Way to Go Joanna

I briefly met Joanna Rutkowska at Black Hat Federal 2006 when she spoke about rootkits. Today I saw she was interviewed by Dark Reading and said the following:

Still, she worries that security technology and research is too prevention-oriented and doesn't emphasize detection enough. "The whole industry is focusing on prevention, and we have all those anti-exploitation technologies, which are very helpful indeed. But I'm so surprised that no one cares about detection," she says. "Every time there's prevention, there is some bypass method" created.

Without detection, there's no way to know if an attacker has grabbed administrative access to a machine, she says. And if you can't see that an attacker has infiltrated the system, nothing in that system will be "reliable" anymore. "The scary part is that once an attacker [gets] into the system, we can't reliably read system memory, neither using software-based, nor hardware-based, methods. That means we can't answer the question of whether the system is clean or not," she says. (emphasis added)

Wow. I am so pleased to read someone of Johanna's caliber stressing the need for detection. I have been working on slides for ShmooCon and I plan to talk about this very subject, and you probably know I've been saying for years that prevention eventually fails. Her comment about reliability of evidence relates to my TaoSecurity Pyramid of Trust, where I mentioned Johanna with respect to her techniques to defeat memory capture.

Read More

Why Prevention Can Never Completely Replace Detection

So-called intrusion prevention systems (IPS) are all the rage. Since the 2003 Gartner report declaring intrusion detection systems (IDS) dead, the IPS has been seen as the "natural evolution" of IDS technology. If you can detect an attack, goes a popular line of reasoning, why can't (or shouldn't) you stop it? Here are a few thoughts on this issue.

People who make this argument assume that prevention is an activity with zero cost or down side. The reality is that the prevention action might just as easily stop legitimate traffic. Someone has to decide what level of interruption is acceptible. For many enterprises -- especially those where interruption equals lost revenue -- IPS is a non-starter. (Shoot, I've dealt with companies that tolerated known intrusions for years because they didn't want to "impact" the network!)

If you're not allowed to interrupt traffic, what is the remaining course of action? The answer is inspection, followed by manual analysis and response. If a human decides the problem is severe enough to warrant interruption, then a preventative measure is deployed.

In some places, prevention is too difficult or costly. I would like to know how one could use a network-based control mechanism to stop a host A on switch X from exploiting host B on switch X. Unless the switch itself enforces security controls, there is no way to prevent this activity. However, a sensor on switch X's SPAN port could detect and report this malicious activity.

Note that I think we will see this sort of access control move into switches. It's another question whether anyone will activate these features.

I think traffic inspection is best used at boundaries between trusted systems. Enforcement systems make sense at boundaries between trusted and untrusted systems. Note that if you don't trust individual hosts inside your organization (for whatever reason), you should enforce control on a per-host basis within the access switch.

Read More

Pool IDS

By now you've probably heard the story about the 10-year-old girl in Wales who was saved by the Poseidon computer-aided drowning detection system. According to the vendor:

"[Poseidon] uses advanced computer vision technology to analyze activity in the pool, captured by a network of cameras mounted both above and below the surface of the pool. Poseidon helps lifeguards monitor swimmers' trajectories, and can alert them in seconds to a swimmer in trouble."

While reading comments at Slashdot, several of them reminded me of the value of digital intrusion detection systems. This one by a Poseidon user is very helpful if you want to know more about how Poseidon works.

For example, some critics complain about "false positives," meaning Poseidon sounds the alarm although no one is drowning. Poseidon alarms when a swimmer stops moving below the water for more than a few seconds. If the Poseidon programmers tell the device to alert when people appear to be drowning (i.e., motionless below water for a while), then it is not the device's fault when it alerts lifeguards of this fact.

It should not be Poseidon's fault if someone decides to "play dead" at the bottom of the pool!

If Poseidon alarms when everyone is moving, then that is an example of a real false positive. A false negative means no alarm when someone is drowning and motionless below the water.

Beyond the false positive debate, someone proposed a "drowning prevention system" based on the Poseidon alert. The idea was to raise a portion of the pool (!) under the motionless person, thereby elevating them above the water (!) to safety. This is an example of "prevention" being difficult or too costly. Wherever prevention is impossible, detection should be applied.

Finally, the Poseidon system demonstrates another feature of digital detection: human involvement. Poseidon sounds an alarm, to which human "analysts" (aka lifeguards) must respond. Time is of the essence. Here, "real time" does matter. However, a person could thrash underwater while drowning, and only become motionless after their lungs have filled with water. Still, an alert a few seconds later is better than no alert at all.

On a related note, consider the T.J. Hooper v. Northern Barge Corp. effect. This was the case where Judge Learned Hand (I am not making that up) essentially found tugboat owners negligent for not installing a newfangled "radio" technology (in 1932) that could have warned the boats of an impending storm. Radios were not mandatory at that time on boats, but Judge Hand "legislated from the bench" and essentially made them mandatory because they were so helpful. The previous link uses the same argument to advocate installing DDoS defenses, but one could extend the argument to hold pool owners negligent if they do not deploy Poseidon-like systems.

Read More

Comments on Network Anomaly Detection System Article

I was asked to comment on Paul Proctor's new article in the August 2005 Information Security magzine, titled A Safe Bet?. Paul is an analyst at Gartner now, but years ago he wrote an excellent book -- The Practical Intrusion Detection Handbook, which I reviewed five years ago.

Paul's article introduces network anomaly detection systems, shorted by the wonderful acronym NADS. Paul describes NADS thus:

"NADS are designed to analyze network traffic with data gathered from protocols like Cisco Systems's NetFlow, Juniper's cFlow or sources that support the sFlow standard. Data is correlated directly from packet analysis; and the systems use a combination of anomaly and signature detection to alert network and security managers of suspicious activity, and present a picture of network activity for analysis and response."

I find Paul's opinions to be sound:

"Despite vendor claims to the contrary, NAD is primarily an investigative technology. While it has the potential to detect zero-day and other stealthy attacks, confidence in its results remains a problem in enabling automated response mechanisms.

This isn't unlike the early versions of IDS/IPS products, which weren't reliable enough to enable automated responses. In this light, NAD is best used to detect, investigate and manually address suspected incidents and problems...

NADS may not be able to automatically detect and block with the confidence of an IPS signature, but neither can an IDS/IPS help an organization if the enabled signature set misses something."

I am glad to see someone defending a product for its investigative value and not for its preventative value. It appears someone else realizes that prevention eventually fails, anyway.

Paul also says:

"NAD devices are powerful knowledge tools for expert network operations people with enterprise-specific contextual knowledge. These systems can help enterprises learn about the traffic and behavior of their network."

That's exactly right. NADS improve network situational awareness. However:

"Even though they can catch detailed events, such as a new service opening up, a new protocol appearing or a new machine connecting to the network, these events are too common to have value in larger enterprises.

NADS shine where obvious behaviors — like when a worm-infected machine spewing attack traffic or a DoS attack — are under way."

Here is the true root of the problem. If one cannot define normal network behavior, perhaps due to the size of the network or an inherently dynamic nature, then a NADS won't be much help. In those cases, it will only detect "obvious behaviors," for which existing detection and prevention systems may be adequate.

Paul concludes the article by recognizing the importance of skilled operators:

"The value these systems offer for addressing more subtle behavior is dependent upon the knowledge and experience of the operator. Under the right circumstances, NADS provide a wealth of network behavior information (protocols, ports, services, throughput, latency, etc.) that can be used to understand what's really going on in your network."

This is another reason why network security analysts are not going to lose their jobs. Networks are only becoming more complex. There is no chance that an expert network or security administrator can be coded into a software appliance. If IPv6 is widely deployed, the need for skilled operators will only grow.

Read More

Credit Card Intrusion Detection

I just received a call from a computer at Citicards, the company that issued one of my credit cards. Twice in the past few years that card was stolen by credit card number thieves. I found the exchange with the computer interesting.

First it announced that it was calling from the Citicards fraud department. Next it asked if I was "Richard Bejtlich," using the best pronounciation of my last name a computer could muster. (It's "bate-lik", by the way.) Then it asked me to verify the zip code of the billing address for the credit card. At this point I figured providing a zip code was a low-risk activity, in the event this was a sophisticated social engineering attempt.

Once I "authenticated" via zip code, the computer asked if I had made a purchase of $6.37 yesterday at "fast food" something-or-other. I recognized this as the dinner I bought at the incredibly high-brow Chick-fil-A drive-thru window at 9 pm last night. I pressed "one" to validate the transaction. Next the computer asked if I had spent money at an automated data which I recognized as the gas I bought prior to driving to Columbia, MD. I validated that transaction. At that point the computer was satisfied. It told me to call 1-800-950-5114 if I had any concerns.

I believe Citicards alerted to my two recent transactions because I hardly use that card. It's also possible they are edgy after the recent CardSystems Solutions heist. It's even possible my card is on a watch list of some sort. Thanks to John Ward for pointing out I was probably working with the Citicards Fraud Early Warning program.

Read More

Will Compromises at Universities Aid Security Research?

Last year I reported my experiences attending the 2003 International Symposium on Recent Advances in Intrusion Detection, also known as RAID. Many briefers complained that their security research suffered due to lack of good data. For example, intrusion detection analysts usually relied on the 1999 DARPA Intrusion Detection Evaluation data. Data like this may be sanitized for analysis by researchers but it pales in comparison to watching live traffic from production networks.

Several recent events may give security researchers the data they need. For example, UC Berekely suffered an intrusion on 1 Aug 04 which jeopardized a database containing names, addresses, telephone and Social Security numbers collected by the California Department of Social Services (CDSS). According to Carlos Ramos, assistant secretary at CDSS, the compromise "was discovered on Aug. 30 by Berkeley IT staff using intrusion detection software." I wonder if the IDS was Vern Paxson's Bro, developed in the International Computer Science Institute and featured in chapter 9 of The Tao of Network Security Monitoring? As I mention in the book, Vern previously used Bro to track intruders at UC Berkeley.

A second security powerhouse was just the victim of an intrusion. An intruder gained access to systems at Purdue's West Lafayette campus, according to published reports. The Center for Education and Research in Information Assurance and Security (CERIAS), where Gene Spafford is Executive Director, features Brian Carrier of Sleuthkit fame as a student. Might he be doing an incident response and forensic analysis on the affected systems?

Finally, while browsing Web site defacements at zone-h, I noticed a mirror for ournet.tamu.edu. Texas A&M University is the home of the famous Drawbridge bridging firewall. Might the researchers there be preparing to study the compromise of "OurNet, the TAMU Career Center Intranet"? It looks like intruders defaced the TAMU Web site by exploiting a PHP application, as the defacement mirror prominently features PHP-Nuke.

Keep an eye open for papers on "real world intrusions" from these and other academic sources suffering compromises.

Read More

Improving Windows Baselining with Tlist.exe

Several people provided feedback on my Simple Post-Installation Baselines on Windows Blog entry. First, Beau Monday reminded me of his FirstOnScene incident response scripts. I haven't tried these out but you might want to see if they make life easier for your first responders.

Second, Harlan Carvey pointed out the program tlist.exe shipped with the Debugging Tools for Windows. This is apparently not the same tlist.exe found on some Windows systems. You can obtain tlist.exe by downloading and installing the debugging tools, and then copying the tlist.exe binary elsewhere.

I tested the independence of tlist.exe by running it on a system where no special debugging tools were installed, and where I did not have administrator privileges.

Here is an excerpt of tlist.exe output. This tool is especially helpful because it shows the full path for executables. This allows you to differentiate between a 'svchost.exe' started from "C:\WINDOWS\system32" (where it belongs) and "C:\WINDOWS\system32\temp" (where it doesn't):

c:\>tlist.exe -v



 0    0 System Process  

     Command Line: 

 0    4 System          

     Command Line: 

 0  376 smss.exe        

     Command Line: \SystemRoot\System32\smss.exe

     Process StartTime: 10/18/2004 6:54:42 AM

 0  652 csrss.exe       Title: 

     Command Line: C:\WINDOWS\system32\csrss.exe 

 ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On

 SubSystemType=Windows ServerDll=basesrv,1

 ServerDll=winsrv:UserServerDllInitialization,3

 ServerDll=winsrv:ConServerDllInitialization,2

 ProfileControl=Off MaxRequestThreads=16

     Process StartTime: 10/18/2004 6:54:46 AM

 0  676 winlogon.exe    

     Command Line: winlogon.exe

     Process StartTime: 10/18/2004 6:54:48 AM

 0  720 services.exe    Svcs:  Eventlog,PlugPlay

     Command Line: C:\WINDOWS\system32\services.exe

     Process StartTime: 10/18/2004 6:54:49 AM

 0  732 lsass.exe       Svcs:  PolicyAgent,ProtectedStorage,SamSs

     Command Line: C:\WINDOWS\system32\lsass.exe

     Process StartTime: 10/18/2004 6:54:49 AM

 0  888 svchost.exe     Svcs:  DcomLaunch,TermService

     Command Line: C:\WINDOWS\system32\svchost -k DcomLaunch

     Process StartTime: 10/18/2004 6:54:50 AM

 0  952 svchost.exe     Svcs:  RpcSs

     Command Line: C:\WINDOWS\system32\svchost -k rpcss

     Process StartTime: 10/18/2004 6:54:51 AM

 0 1040 svchost.exe     Svcs:

 AudioSrv,BITS,Browser,CryptSvc,Dhcp,dmserver,ERSvc,

 EventSystem,FastUserSwitchingCompatibility,helpsvc,

 lanmanserver,lanmanworkstation,Netman,Nla,RasMan,

 Schedule,seclogon,SENS,SharedAccess,ShellHWDetection,

 srservice,TapiSrv,Themes,TrkWks,W32Time,winmgmt,wscsvc,

 wuauserv,WZCSVC

     Command Line: C:\WINDOWS\System32\svchost.exe -k netsvcs

     Process StartTime: 10/18/2004 6:54:51 AM

 0 1124 svchost.exe     Svcs:  Dnscache

     Command Line: C:\WINDOWS\system32\svchost.exe -k NetworkService

     Process StartTime: 10/18/2004 6:54:51 AM

 0 1228 svchost.exe     Svcs:  LmHosts,RemoteRegistry,SSDPSRV,WebClient

     Command Line: C:\WINDOWS\system32\svchost.exe -k LocalService

     Process StartTime: 10/18/2004 6:54:52 AM

 0 1364 CCSETMGR.EXE    Svcs:  ccSetMgr

     Command Line: "C:\Program Files\Common Files\Symantec Shared\ccSetMgr.exe"

     Process StartTime: 10/18/2004 6:54:54 AM

 0 1392 CCEVTMGR.EXE    Svcs:  ccEvtMgr

     Command Line: "C:\Program Files\Common Files\Symantec Shared\ccEvtMgr.exe"

     Process StartTime: 10/18/2004 6:54:54 AM

 0 1556 spoolsv.exe     Svcs:  Spooler

     Command Line: C:\WINDOWS\system32\spoolsv.exe

     Process StartTime: 10/18/2004 6:54:55 AM

 0 1940 NAVAPSVC.EXE    Svcs:  navapsvc

     Command Line: "C:\Program Files\Norton AntiVirus\navapsvc.exe"

     Process StartTime: 10/18/2004 6:55:02 AM

 0 1972 NeTmSvNT.exe    Svcs:  NetTimeSvc

     Command Line: "C:\Program Files\NetTime\NeTmSvNT.exe"

     Process StartTime: 10/18/2004 6:55:03 AM

 0  324 NMSSvc.Exe      Svcs:  NMSSvc

     Command Line: C:\WINDOWS\system32\NMSSvc.exe

     Process StartTime: 10/18/2004 6:55:06 AM

 0  480 SAVSCAN.EXE     Svcs:  SAVScan

     Command Line: "C:\Program Files\Norton AntiVirus\SAVScan.exe"

     Process StartTime: 10/18/2004 6:55:07 AM

 0  896 svchost.exe     Svcs:  stisvc

     Command Line: C:\WINDOWS\system32\svchost.exe -k imgsvc

     Process StartTime: 10/18/2004 6:55:09 AM

 0 1024 symlcsvc.exe    Svcs:  Symantec Core LC

     Command Line: "C:\Program Files\Common Files\Symantec Shared\CCPD-LC\symlcsvc.exe"

     Process StartTime: 10/18/2004 6:55:10 AM

 0  768 SymWSC.exe      Svcs:  SymWSC

     Command Line: "C:\Program Files\Common Files\Symantec Shared\Security Center\SymWSC.exe"

     Process StartTime: 10/18/2004 6:55:11 AM

...

 0 1844 msmsgs.exe      Title: 

     Command Line: "C:\Program Files\Messenger\msmsgs.exe" -Embedding

     Process StartTime: 10/20/2004 8:52:04 AM

 0 3504 msiexec.exe     Svcs:  MSIServer

     Command Line: C:\WINDOWS\system32\msiexec.exe /V

     Process StartTime: 10/20/2004 8:52:35 AM

 0 2156 cmd.exe         Title: Command Prompt - tlist.exe -v 

     Command Line: "C:\WINDOWS\system32\cmd.exe" 

     Process StartTime: 10/20/2004 8:53:26 AM

 0  172 dllhost.exe     Svcs:  COMSysApp  Mts:   System Application

     Command Line: C:\WINDOWS\system32\dllhost.exe

 /Processid:{02D4B3F1-FD88-11D1-960D-00805FC79235}

     Process StartTime: 10/20/2004 8:54:09 AM

 0 2412 tlist.exe       

     Command Line: tlist.exe -v 

     Process StartTime: 10/20/2004 8:54:37 AM

There is a lot you can do with this data. I'm pointing it out because a small amount of work done prior to a compromise when a system is in a trusted post-installation state can make identifying and responding to compromise quicker, cheaper, and easier.

Read More

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.

Read More