When considering a site's security profile, it's important to determine not just what it does have, but also what it doesn't have.

You don't need to see much traffic, because protocols are designed to be efficient.

When profiling a site, you need to forget everything you know about it. Approach it with a clear mind.

Even if you have a detection system in place, it's difficult to do anything about alarms. Profiling a site is very easy, even for novices. The most time consuming bit is doing site research.

When profiling a site, it's helpful to be running a packet sniffer on your own machine - both to see what you send out, and also to see what's coming back.

Things like how a site presents itself publicly can be important too. DNS and whois information, that sort of thing. One can even try a DNS zone transfer.

Brad really likes using DNS and SNMP ("the forgotten protocol") to find things out. Lots of sites forget about securing SNMP.

As a security officer, think about things like "what can I lose my job for?" - webserver compromise, database corruption by hackers, etc. Should/could be a list of 5-10 things.

When designing a firewall, lots of people let much more out than they do in. This can be very very bad.

Utilities change over time (or don't), which changes their actual usefulness.

CERT seems to be doing Good Things.

A telling example of the diligence that programmers use: the number of security protocols with security issues.

The bar can be quite low - CERT top 10 lists. Can you protect against those, even?

Few IDS look at ICMP, another forgotten protocol. You can find out lots of stuff with this too. SNMP at least keeps a connection table.

If you don't need SNMP from off-site (and you shouldn't) - block it! ssh, smtp are tricky though...

ID gateways don't see the full picture of a session.

What about wireless? All about the antenna selection. Often a security issue with wireless is too much coverage. You can use tin venetian blinds (!) to cut down coverage.

Modems are back in vogue, mostly for remote management. But since they're not common as dirt, lots of people forget to protect them.

Even if you can't protect, you should at least detect.

Good applications on good operating systems with good setups isn't sufficient: how do they all behave together?

Keeping state on a server is Hard. Doing so when things are going wrong is Really Hard.

Should have at least one (preferably more) thing in each of the "major buckets" - portscan, CGI checking, etc.

Tools he or others liked/mentioned:

• scotty - protocol information tool.
• strobe - very very fast and stupid about protocols (sometimes a bonus).
• Key Ghost - keyboard capture utility. Pro version even encrypts what it sees. Boggle.
• Network Flight Recorder
• Stealth Watch - watches traffic, and you can declare a bunch of sessions as the baseline.
• ntop
• etherape
• nessus - can be problematic because it has so many options.
• Web Scarab - spiders a webapp and looks for common issues. Still somewhat immature.
• xprobe - ICMP echo, quiet OS detection tool.
• squid, squidguard - HTTP proxies, the latter will strip ASCII encoded URIs.
• Auditor Security Collection - KNOPPIX live CD.
• jizz / Zodiac
• NSTX, droute - TCP over DNS. Ick!

Brad is a quick and efficient presenter, very approachable and seems very knowledgeable.

-- MikePatterson - 26 Apr 2005