The Security Skeptic

Kevin Beaver's cynical column from August 2002 is in the spotlight again at SecurityFocus. I thought of some corollaries to his list:

To #3, don't patch your software, add, "but if you must, patch immediately on production systems, there's little point testing a patch - after all, how often do vendors botch the patch itself?".

To #10, rely solely on technology, add, "never read the manuals or help files, they can't possibly assist you in configuring your system correctly".

To #12, don't monitor your systems, add, "but if you must, don't bother reviewing log and event data, most of it's 'noise' anyway..."

To #13, don't back up your data add, "and while you're at it, don't back up your configuration data as well".

If you think of any to add, let me know...

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID149 by Dave Piscitello  

Matthew Tanase's article discusses the merits of transparent or bridging firewalls. When a device bridges rather than routes, it's not identifiable in the IP level packet stream (no TTL decrement, for example). Bridging is also helpful in topologies where addressing is a problem. A good read.

Matthew also hosts The Security Blog. I found some interesting reading there as well.

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID150 by Dave Piscitello  

After reading Fred Avolio's NetSec Letter #29 and blog on A Linux Desktop, I sent the following in an email to Fred, and copied Marcus Ranum:

IMO, too much attention and emphasis are being placed on the terrible consequences of homogeneity and too little on improving (secure) coding practices. Last time I looked, which is *recently*, exploits continue to be disclosed for every *NIX operating system, at a pace arguably close to Windows exploit disclosures. The notion that we'll somehow insulate society from massive computing meltdown by diversifying across dozens of exploitable operating systems doesn't hold water. If I were an organization motivated enough to attack a cyber-infrastructure, and that infrastructure was heterogeneous, I'd simply through more cycles at developing an attack that would succeed on multiple platforms. The fact that this hasn't been done yet isn't enough to convince me it can't be done. Windows happens to be perceived to be the low-hanging fruit, the 90-lb. weakling, and the target of amateurs.

I can make the same or stronger argument for user-introduced consequences. Windows or *NIX, we are simply awful at securely configuring systems. We're lazy. We don't RTFM. And it's been my experience (which I'll claim is extensive, since I have evaluated dozens of appliances and software products) that often as not, when we do RTFM we discover features are documented incorrectly, or not documented at all. If everyone took 30 minutes and exerted the modest effort required to install and configure a PFW and AV software, exploit frequency would fall dramatically.

I'm also tired of hearing about *Nix superiority w/r/t security. I run a Win2k server and desktops. I invest a considerable effort to see it is secured, but no more so than anyone must to secure Linux. I've run a Linux server, and after running both, I will tell you that I feel more confident with Win2K than I did with Linux. I had better access to resources, documentation, assessment tools, security templates, etc. Your results will probably vary, but I believe this is so because you were weaned on Linux and I on Windows (well, Mac, then Windows). The largest financial firms run windows servers and they are tight as a drum. They could make Linux servers tight as a drum as well, because they have time, talent, approval, and motivation to develop and implement secure operations and practices.

The sad fact is that all commercial operating systems fail to meet secure computing criteria. Even if any *one* OS met the criteria, I believe it will be a long time before the general population would be able to maintain them securely *and* be productive. Being secure and productive takes time and thoughtful action. We don't want to invest either.

As expected, nay, anticipated, Marcus offered yet another example of why I love email threads of this sort:

It's a complex problem in many variables - worrying about any one of

them preferentially is going to just leave you open someplace else.

The problem is about:

bad code

bad defaults

bad policies

bad administration

bad documentation

bad users

bad marketing

... etc.

If we apply pressure to any one, two, or three of those, we won't

make any actual progress. But we'll have some limited and

transient success. (viz: M$ secure coding initiative. firewalls, etc)

The question I am now mulling over isn't whether limited and transient success puts us in a better place than we are now (strongly agree) but whether it's the best we can expect...

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID147 by Dave Piscitello  

Messages broadcast over LANs are useful to you, and a would-be attacker. Some broadcast traffic may not be useful to you at all, and only serves to inhibit network performance. This article illustrates what broadcast Ethernet traffic reveals, and recommends measures eliminate unnecessary traffic to better protect yourself and tweak performance.

This column was originally published as a WatchGuard LiveSecurity Editorial, 14 August 2003.

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID146 by Dave Piscitello  

Many users don't know how to harden Windows 2000/XP desktop and laptop computers. In this column for WatchGuard, I explain how to improve your security policy without having to contend with registry editing.

This column was originally published as a WatchGuard LiveSecurity Editorial, 25 July 2003.

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID145 by Dave Piscitello  

Compiled, updated and improved over time, this "form" lists the security considerations small and medium businesses should consider when deploying wireless LANs. We distinguish SMB from large enterprise by an assumption of security budget: SMBs have stricter budgets and satisfy security requirements with smaller staff and less expensive equipment. Small office budgets in particular tend to make consumer WLAN products tempting substitutes for more expensive but more secure APs and firewalls.

Our checklist identifies features that should help SMBs make an informed decision.

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID143 by Dave Piscitello  

Provided as a handout at the ISSA South Carolina Chapter meeting (October 13), this article explains the IEEE 802.1x features, services, and message flow.

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID144 by Dave Piscitello  

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID141 by Dave Piscitello  

In my role as track chairman, I will be moderating three security sessions at ComDex 2003 in Las Vegas:

• Intrusion Prevention Systems, with Abhishek Chauhan and Conrad Herrmann,

• Dealing with SPAM, with Michael Ostermann and Dr. Paul Judge, and

• Security for Handheld PDAs, with Caleb Sima and Tom Goodman.

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID142 by Dave Piscitello  

I recently purchased a Coolmax Gemini CD-309 Series External Enclosure for 3.5" IDE drives. This is one of those under $40 purchases I can't help but recommend.

If you have a spare hard drive - perhaps you've cannibalized a dead or time-to-retire PC, or found one for cheap on eBay - you can create an enormous and reliable removable/portable storage device.

Installation is so simple it's printed on the back of the packaging: remove back panel, slide out HDD tray, connect IDE cable to HDD, connect power cable, and close the case. Plug the USB into a computer and power up the drive. Windows 2000/XP PnP recognizes it as removable storage. Yes, there are screws involved, but you don't have to fret about Evil Static Electricity, and there's really nothing you can break.

I found myself wondering why I'm buying 128 and 256 MByte Compact Flash and Secure Digital cards when I can have 10 Gigabytes for under $100 (including case and hard drive).

Then I remember I have a digital camera and MP3 player... O.K., so I use many removable media.

But with the portable HDD, I can back up reams of information on spare hard drives, or create and store system partition images for all my systems, a bootable forensics partition, or just back up the hundreds of music files I've ripped (from my CDs, emusic.com, and other authorized music distributors, thank you...).

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID140 by Dave Piscitello  

Afred Huger posts lists of articles at SecurityFocus as they become available. Recently, he noted the publication of the first of thre articles entitled Exploiting Cisco Routers.

The column is very interesting, as it reveals several exploits and vulnerabilities that are not particularly new, but troublesome still.

In my opinion, this column would have been so much more valuable to the security community if written in a constructive manner.

The title itself disheartens me: "Exploiting cisco routers" is an "I'm sooo kewl look how easily I can crack your box" perspective that only encourages people that this is the true merit of pen-testing. Further into the column, I read the section entitled "Brute-Forcing Services: SNMP is always fun". Fun? How many networks can you probe and discover the same missing patch, or configuration error before you think, "this is sad..." rather than "oh, what fun!"? (Perseveration is symptomatic of psychological and language disorders, but now I stray from the topic...)

If I wanted to make a case for distinguishing pen-testing from security auditing, I can't help but feel columns like this reinforce the attitude that pen-testing is an amateur's activity. This is sad, too.

If SecurityFocus wants its portals and lists to continue to be a resource for people interested in securing systems, its editors might want to consider exerting some influence and encourage authors to write in terms of identifying and eliminating vulnerabilities than exploiting them.

Imagine how positive and more widespread an influence these same columns might make if they were titled "Identifying and Mitigating Cisco Router Vulnerabilities".

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID139 by Dave Piscitello  

Matthew Liotine's new book, Mission Critical Planning will be released shortly.

My Foreword is available here, and now.

This is an excellent book, and provides very practical and useful advise for anyone involved in business, network, and services continuity planning. I reviewed every chapter, and refer to the pre-production manuscript still. I'm looking forward to receiving my copy soon.