Jumat, 07 Juli 2006

Control-Compliant vs Field-Assessed Security

Last month's ISSA-NoVA meeting featured Dennis Heretick, CISO of the US Department of Justice. Mr. Heretick seemed like a sincere, devoted government employee, so I hope no one interprets the following remarks as a personal attack. Instead, I'd like to comment on the security mindset prevalent in the US government. Mr. Heretick's talk sharpened my thoughts on this matter.

Imagine a football (American-style) team that wants to measure their success during a particular season. Team management decides to measure the height and weight of each player. They time how fast the player runs the 40 yard dash. They note the college from which each player graduated. They collect many other statistics as well, then spend time debating which ones best indicate how successful the football team is. Should the center weigh over 300 pounds? Should the wide receivers have a shoe size of 11 or greater? Should players from the north-west be on the starting line-up? All of this seems perfectly rational to this team.

An outsider looks at the situation and says: "Check the scoreboard! You're down 42-7 and you have a 1-6 record. You guys are losers!"

In my opinion, this summarizes the mindset of US government information security managers.

Here are some examples from Mr. Heretick's talk. He showed a "dashboard" with various "metrics" that supposedly indicate improved DoJ security. The dashboard listed items like:

  • IRP Reporting: meaning Incident Response Plan reporting, i.e., does the DoJ unit have an incident response plan? This says nothing about the quality of the IRP.

  • IRP Exercised: has the DoJ unit exercised its IRP? This says nothing about the effectiveness of the IRT in the exercise.

  • CP Developed: meaning Contingency Plan developed, i.e, does the DoJ unit have a contingency plan should disaster strike? This also says nothing about the quality of the CP.

  • CP Exercised: has the DoJ unit exercised its CP? Same story as the IRP.


Imagine a dashboard, then, with all "green" for these items. They say absolutely nothing about the "score of the game."

How should the score be measured then? Here are a few ideas, which are neither mutually exclusive nor exceedingly well-thought-out:

  • Days since last compromise of type X: This is similar to a manufacturing plant's "days since an accident" report or a highway's "days since a fatality" report. For some sites this number may stay zero if the organization is always compromised. The higher the number, the better.

  • System-days compromised: This looks at the number of systems compromised, and for how many days, during a specified period. The lower, the better.

  • Time for a pen testing team of [low/high] skill with [internal/external] access to obtain unauthorized [unstealthy/stealthy] access to a specified asset using [public/custom] tools and [complete/zero] target knowledge: This is from my earlier penetration testing story.


These are just a few ideas, but the common theme is they relate to the actual question management should care about: are we compromised, and how easy is it for us to be compromised?

I explained my football analogy to Mr. Heretick and asked if he would adopt it. He replied that my metrics would discourage DoJ units from reporting incidents, and that reporting incidents was more important to him than anything else. This is ridiculous, and it indicates to me that organizations like this (and probably the whole government) need independent, Inspector General-style units that roam freely to assess networks and discover intruders.

In short, the style of "security" advocated by government managers seems to be "control-compliant." I prefer "field-assessed" security, although I would be happy to replace that term with something more descriptive. In the latest SANS NewsBites (link will work shortly) Alan Paller used the term "attack-based metrics," saying the following about the VA laptop fiasco: "if the VA security policies are imprecise and untestable, if the VA doesn't monitor attack-based metrics, and if there are no repercussions for employees who ignore the important policies, then this move [giving authority to CISOs] will have no impact at all."

PS: Mr. Heretick shared an interesting risk equation model. He uses the following to measure risk.

  • Vulnerability is measured by assessing exploitability (0-5), along with countermeasure effectiveness (0-2). Total vulnerability is exploitability minus countermeasures.

  • Threat is measured by assessing capability (1-2), history (1-2), gain (1-2), attributability (1-2), and detectability (1-2). Total threat is capability plus history plus gain minus attributability minus detectability.

  • Significance (i.e., impact or cost) is measured by assessing loss of life (0 or 4), sensitivity (0 or 4), operational impact (0 or 2), and equipment loss (0 or 2). Total significance is loss plus op impact plus sensitivity plus equipment loss.

  • Total risk is vulnerability times threat times significance, with < 6 very low, 6-18 low, 19-54 medium, 55-75 high, and >75 very high.

Kamis, 06 Juli 2006

Tao Is One of Information Security's Top Ten Books

The July 2006 issue of Information Security magazine features my first book The Tao of Network Security Monitoring as one of their Top Ten Books. That's pretty cool. I see some overlap with my Top Ten Books, published last year.

Rabu, 05 Juli 2006

The One-Minute Wireless Bridge

I am aware of the several fake access point projects available, like Rfakeap. Since one of the main purposes of my blog is to document how I configure applications for my personal future reference, I am listing the steps I performed to set up a wireless access point on FreeBSD.

The FreeBSD WAP laptop will receive its Internet connectivity via DHCP and a WEP-protected wireless network, from, say a conference. The laptop WAP will provide an encryption-free wireless connection to anyone who cares to connect.

I use two wireless NICs for this project.

First I connect the laptop to the local wireless network.

orr:/root# ifconfig wi0
wi0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
ether 00:02:2d:4c:ae:de
media: IEEE 802.11 Wireless Ethernet autoselect (none)
status: no carrier
ssid "" channel 1
stationname "FreeBSD WaveLAN/IEEE node"
authmode OPEN privacy OFF txpowmax 100
orr:/root# kldload wlan_wep
orr:/root# ifconfig wi0 ssid shaolin wepkey 0x[WEP key here] deftxkey 1 wepmode on up
orr:/root# dhclient wi0
DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 192.168.2.1
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPACK from 192.168.2.1
bound to 192.168.2.102 -- renewal in 43200 seconds.
orr:/root# ifconfig wi0
wi0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::202:2dff:fe4c:aede%wi0 prefixlen 64 scopeid 0x4
inet 192.168.2.102 netmask 0xffffff00 broadcast 192.168.2.255
ether 00:02:2d:4c:ae:de
media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
status: associated
ssid shaolin channel 6 bssid 00:13:10:65:2f:ad
stationname "FreeBSD WaveLAN/IEEE node"
authmode OPEN privacy MIXED deftxkey 1 wepkey 1:104-bit txpowmax 100
bintval 100
orr:/root# ping -c 1 www.google.com
PING www.l.google.com (64.233.161.104): 56 data bytes
64 bytes from 64.233.161.104: icmp_seq=0 ttl=229 time=61.857 ms

--- www.l.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 61.857/61.857/61.857/0.000 ms

The laptop wi0 wireless NIC has been assigned 192.168.2.102 via DHCP and it can reach the outside world.

Next I set up wi1 to be the wireless NIC for the WAP.

orr:/root# ifconfig wi1
wi1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
ether 00:04:e2:29:3b:ba
media: IEEE 802.11 Wireless Ethernet autoselect (none)
status: no carrier
ssid "" channel 1
stationname "FreeBSD WaveLAN/IEEE node"
authmode OPEN privacy OFF txpowmax 100
orr:/root# kldload bridge
orr:/root# sysctl net.link.ether.bridge.enable=1
net.link.ether.bridge.enable: 0 -> 1
orr:/root# sysctl net.link.ether.bridge.config="wi0 wi1"
net.link.ether.bridge.config: -> wi0 wi1
orr:/root# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
orr:/root# ifconfig wi1 ssid bejnet channel 11 media DS/11Mbps mediaopt hostap up stationname "BejNet AP"
orr:/root# ifconfig wi1 inet 10.10.10.1 netmask 255.255.255.0 up
orr:/root# ifconfig wi1
wi1: flags=8943 mtu 1500
inet6 fe80::204:e2ff:fe29:3bba%wi1 prefixlen 64 scopeid 0x5
inet 10.10.10.1 netmask 0xffffff00 broadcast 10.10.10.255
ether 00:04:e2:29:3b:ba
media: IEEE 802.11 Wireless Ethernet DS/11Mbps (DS/2Mbps )
status: associated
ssid bejnet channel 11 bssid 00:04:e2:29:3b:ba
stationname "BejNet AP"
authmode OPEN privacy OFF txpowmax 100 dtimperiod 1 bintval 100

At this point the WAP can transmit packets from wi1 to wi0 and vice-versa. However, it would be a good idea for the clients that associate with the WAP to get addresses via DHCP, preferably from a range not in use (e.g., not 192.168.2.0/24). This requires DHCP, which I set up in /etc/rc.conf:

dhcpd_enable="YES" # dhcpd enabled?
dhcpd_flags="-q" # command option(s)
dhcpd_conf="/usr/local/etc/dhcpd.conf" # configuration file
dhcpd_ifaces="wi1" # ethernet interface(s)

and /usr/local/etc/dhcpd.conf:

option domain-name "taosecurity.com";
option domain-name-servers 192.168.2.1;

default-lease-time 6000;
max-lease-time 72000;

ddns-update-style ad-hoc;
log-facility local7;

subnet 10.10.10.0 netmask 255.255.255.0 {
range 10.10.10.128 10.10.10.192;
option routers 10.10.10.1;
}

I'm being a little lazy here. I should replace the "legitimate" name server, 192.168.2.1, with 10.10.10.1 (my WAP), and configure a caching name server on my WAP. I'm going to avoid that step here, but I would probably do it elsewhere.

At this point you might think I am good to go. I have a rogue WAP on wi1 with IP 10.10.10.1 ready to serve IP addresses once I start dhcpd. The problem is I doubt the legitimate conference WAP knows how to reach my 10.10.10.0/24 network. Clients who associate with my laptop WAP will send traffic with source IPs like 10.10.10.192, but the conference WAP gateway at 192.168.2.1 will not know how to reach the 10.10.10.0/24 network.

The answer is to set up NAT on the laptop WAP.

orr:/root# kldload ipfw
orr:/root# kldload ipdivert
orr:/root# natd -dynamic -n wi0
orr:/root# ipfw add divert natd ip from any to any via wi0
00100 divert 8668 ip from any to any via wi0
orr:/root# ipfw add allow ip from any to any
00200 allow ip from any to any

Now the laptop WAP will NAT for connections on the wi1 network. Remember wi0 is closer to the "Internet" so the 192.168.2.0/24 network will see hosts on the 10.10.10.0/24 network coming from 192.168.2.102.

Last I start dhcpd.

orr:/root# /usr/local/etc/rc.d/isc-dhcpd.sh start
Starting dhcpd.
orr:/root# sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
dhcpd dhcpd 1047 5 udp4 *:67 *:*
root natd 976 3 div4 *:8668 *:*
root sendmail 474 4 tcp4 127.0.0.1:25 *:*
root sshd 468 4 tcp4 *:22 *:*
root syslogd 320 7 udp4 *:514 *:*

That's it. Now I can watch the wi1 interface for traffic from anyone who associates with my laptop WAP. I check /var/db/dhcpd/dhcpd.leases and see the following:

lease 10.10.10.192 {
starts 3 2006/07/05 15:56:21;
ends 3 2006/07/05 17:36:21;
binding state active;
next binding state free;
hardware ethernet 00:13:02:4c:30:2d;
uid "\001\000\023\002L0-";
client-hostname "neely";
}

I got someone using host neely to associate with my BejNet laptop WAP. Now I watch for traffic.

orr:/root# tcpdump -n -i wi1 -s 1515
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wi1, link-type EN10MB (Ethernet), capture size 1515 bytes
11:55:21.201914 arp who-has 10.10.10.1 tell 10.10.10.192
11:55:21.202170 arp who-has 10.10.10.1 tell 10.10.10.192
11:55:21.202372 arp reply 10.10.10.1 is-at 00:04:e2:29:3b:ba
11:55:21.204930 IP 10.10.10.192.1025 > 192.168.2.1.53: 9367+ A? www.google.com. (32)
11:55:21.484230 IP 192.168.2.1.53 > 10.10.10.192.1025:
9367 3/0/0 CNAME www.l.google.com., A 216.239.37.99, A 216.239.37.104 (84)
11:55:22.195205 IP 10.10.10.192.1025 > 192.168.2.1.53: 9367+ A? www.google.com. (32)
11:55:22.198575 IP 192.168.2.1.53 > 10.10.10.192.1025:
9367 2/0/0 A 216.239.37.99, A 216.239.37.104 (64)
11:55:22.203729 IP 10.10.10.192 > 216.239.37.99: ICMP echo request, id 1024, seq 2304, length 40
11:55:22.246182 IP 216.239.37.99 > 10.10.10.192: ICMP echo reply, id 1024, seq 2304, length 40

There we are. 10.10.10.192 is pinging Google. Here is the view from the other side of the NAT.

orr:/root# tcpdump -n -i wi0 -s 1515
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wi0, link-type EN10MB (Ethernet), capture size 1515 bytes
11:55:21.202186 arp who-has 10.10.10.1 tell 10.10.10.192
11:55:21.205067 IP 192.168.2.102.1025 > 192.168.2.1.53: 9367+ A? www.google.com. (32)
11:55:21.484044 IP 192.168.2.1.53 > 192.168.2.102.1025:
9367 3/0/0 CNAME www.l.google.com., A 216.239.37.99, A 216.239.37.104 (84)
11:55:22.195388 IP 192.168.2.102.1025 > 192.168.2.1.53: 9367+ A? www.google.com. (32)
11:55:22.198491 IP 192.168.2.1.53 > 192.168.2.102.1025:
9367 2/0/0 A 216.239.37.99, A 216.239.37.104 (64)
11:55:22.203809 IP 192.168.2.102 > 216.239.37.99: ICMP echo request, id 1024, seq 2304, length 40
11:55:22.246099 IP 216.239.37.99 > 192.168.2.102: ICMP echo reply, id 1024, seq 2304, length 40

As far as the 192.168.2.0/24 network is concerned, 192.168.2.102 is making the request -- not 10.10.10.192.

That's it. Obviously this is exactly how to set up your own wireless access point for legitimate purposes. It's also how anyone could set up a WAP to watch traffic from anyone who decides to associate with my laptop WAP. This is the reason 802.11i and other systems are needed, although arbitrarily trusting wireless access points is more of a social problem than a technical problem.

Update: There appear to be some problems with comments, so I'll post additional thoughts here.

Chris asked about dispensing with DHCP and NAT.

I tried two approaches along those lines, but neither worked.

First I tried simply removing DHCP and NAT, but leaving wi0 with an IP address and assigning no IP address to wi1. In this scenario, I could see ARP traffic from an associated client for the DHCP server on the "conference" WAP (who has 192.168.2.1?) but the DHCP server on the conference WAP did not respond.

Next I tried doing nothing but setting up wi0 and wi1 as a pure bridge. wi0 associated with the conference WAP, and wi1 set up as an access point. Again, I could not get the DHCP server on the conference WAP to respond.

By the way, when I say "conference" I really mean the Linksys WRT54G WAP in my lab.

Remember that NAT is not strictly necessary if the conference WAP gateway knows how to reach the wi1 segment. This is not realistic, however, because it requires setting a static route for the wi1 segment on the conference WAP.

I also just renamed this article to be "The One Minute Wireless Bridge," since that is more in the spirit of what I'm doing -- providing one WAP to access another WAP.

Selasa, 04 Juli 2006

VMWare Switch Is a Hub

While preparing materials for my new class TCP/IP Weapons School I needed to test how the virtual switch in VMware Server behaves. I started three VMs. All had lnc0 interfaces bridged to the host's physical NIC. Two VMs had IPs 192.168.2.51 and 192.168.2.52 assigned. The third VM had no IP assigned. When 192.168.2.51 pinged 192.168.2.52, the third VM was able to see the ICMP traffic. This means the virtual switch in VMware Server appears to behave like a hub. This makes monitoring traffic easier.

Senin, 03 Juli 2006

Bejtlich Cited in Patch Management Thesis

Dominic White cited me in his master's thesis: Limiting Vulnerability Exposure through effective Patch Management. My blog post Cool Site Unfortunately Miscategorizes Threats influenced his thinking on the terms threat, vulnerability, and risk.

Jumat, 30 Juni 2006

Ten Days Left for Cheaper USENIX Security Registration

Those of you who read the Atom or RSS feeds for this blog have been missing my personalized USENIX Security 2006 banner ad, visible to my Blogger readers. In fact, some of you might have no idea that I, Richard Bejtlich, write these words, thanks to the various people who copy and reproduce my blog postings without regard to my authorship!

In any case, there are ten days left for early registration for USENIX Security in Vancouver, BC. I will teach a brand new, two day course called TCP/IP Weapons School (TWS) on 31 July and 1 August 2006.

This will be a fun course. Let me make your expectations perfectly clear, however: the primary purpose of this course is to teach TCP/IP and packet-level analysis. The intended audience is junior and intermediate security personnel. We will work our way up the TCP/IP stack over the two day course, using security tools at each layer to provide sample traffic for analysis.

If you walk up to me in class and say "I know all of these tools. This isn't cool," I will boot you from class! This is not an "uber-l33t-h@x0r-t00lz" course. Still, I am trying to add tools from off the beaten path to keep things interesting.

I will probably create a FreeBSD VM with all or most of the tools I use in the slides. Students will be free to try those tools, although I may omit the layer 2 attacks. I do not wish to see MAC spoofing, flooding, and so forth disrupting the USENIX network. I plan to provide all of the traces analyzed in class, however. You will want to be sure your laptop is running Ethereal/Wireshark so you can follow along.

Assuming the class goes well, I hope to offer it elsewhere -- including to private groups.

Signs of Desperation from Duronio Defense Team

It sounds to me like the Duronio defense team has nothing left in its tank, so it's attacking Keith Jones directly. The latest reporting, UBS Trial: Defense Suggests Witness Altered Evidence, shows how ridiculous the defense team sounds:

"So when you talked about putting pieces of the puzzle together, you were missing three-quarters of the pieces for the [central file server] alone?"" [defense attorney] Adams asked.

"The puzzle pieces I had to put together formed the picture I needed," Jones replied. "If the puzzle was of a boat, then I had enough pieces to form the picture of the boat."

Adams countered, "But you might not see all the other boats around it."

Jones replied, "But the second boat won't get rid of the first boat. It's simple mathematics that when you add data, you don't subtract data. There was nothing in that data set that could remove the data I already had."


It sounds like Keith has more testifying in store for next week. Stay tuned.