The Security Skeptic

Most midrange enterprise firewalls have some IPS. Some have this as well as antivirus, antispam, and antispyware. Others offer HTTP proxies that provide considerable content control features. Don't expect to see many "pure play" Internet firewalls in future product offerings. Firewall/IPS vendors can't compete in the Global 2000 plus SMB market if they don't offer an expanded suite of security services in their appliances.

A recent thread on the Firewall Wizards email list asks whether this is a good or bad trend, and it made me think of the number of times that people ask me whether you sacrifice defense in depth by deploying multi-purpose security appliances.

You can still have defense in depth. You achieve it by deploying multiple and diverse security services where they are most effective in enforcing policy. This is a separate issue from whether the security appliance you choose has one or more security services, whether you use all the services in each location where you deploy the appliance, and of course, where you deploy security services in your topology to achieve defense in depth.

I think it's quite possible to use a multi-purpose security appliance, for different purposes, in multiple locations in your topology. For example, one might configure an Internet-facing security appliance to handle DDoS and network threats. Behind this, on a trusted segment where web and application servers, you might put a security appliance that examines HTTP streams and protects my servers from input validation, SQL injection and other application level attacks. On a separate trusted segment for client endpoints, you might put a security appliance that that performs user authentication, proxies HTTP and handles URL filtering and strips content that is disallowed by an AUP. The security appliance protecting the client endpoint segment might also providegateway antispyware, antispam and antivirus services.

Several security appliances support all these security services. Could I use the same appliance in different locations in the configuration I describe? Sure. IMO, the benefits of having a common management platform, common logging format and common configuration and log archival facilities (if present) outweigh any misgivings you might have about putting an appliance in your network and not taking advantage of every feature at every opportunity. Some people may argue that this violates a "best of breed" philosophy. I'd argue that sometimes, you may be just as well served buying the best of a multi-purposed breed. And if you find that no security appliance meets every security service need, well, then you might still consider the multi-purpose appliance that meets the majority of purposes, and complement this with single-purposed systems that meet the rest.

But the fact that all the security services your organization might require are bundled into a single security appliance shouldn't lead you to conclude that you can satisfy all your security policy objectives at a single location, using a single device.

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID530 by Dave Piscitello  

One of the topic areas I study as a member of the ICANN SSAC is the administration of the domain name registration record databases by TLD registries. This information is commonly (though incorrectly) called WHOIS data, in deference to the protocol popularly used to access contact information for domain name registrants. Privacy is a very sensitive issue in this study area. Most stake holders in the WHOIS privacy debate appreciate the need for some form of control to prevent misuse of contact information by spammers, domain name hijackers, and other more serious criminal actors. Many stake holders are not willing to concede "unfettered access to WHOIS data" because it might delay or interfere with their abilities to investigate criminal activities and violations of intellectual property rights, to resolve technical problems associated with name service or web presence, and to explore new revenue opportunities.

Bruce Schneier's essay of May 19, The Value of Privacy, ought to be "must reading" for anyone involved in the WHOIS privacy debate. Although Bruce is responding to revelations of NSA surveillance, his observations and conclusions are spot on target for the WHOIS debate as well: instead of arguing "security versus privacy", we should be seeking "security plus privacy".

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID529 by Dave Piscitello  

I recently ran into a situation where I needed to use the passive form of FTP to test a security appliance. Passive (PASV) allows the client to initiate the FTP DATA connections rather than the FTP server. PASV It has been described as a more secure way of for client PCs behind firewalls to transfer files because all the data connections are initiated from the trusted network (we know this is not a sufficient trust model but we also know that security is 10% clue and 90% denial...).

I am still a command line kinda guy, and the FTP client available from the MS DOS command line doesn't support PASV. I really didn't want to download a FTP client I'd only use once, so I decided I'd use a browser. Googling, I read that Internet Explorer was enhanced to support both PASV and standard FTP. I proceeded to configure my rarely used IE browser as per KBA 323446 :

How to change the Internet Explorer FTP Client mode
1. Start Internet Explorer.
2. On the Tools menu, click Internet Options.
3. Click the Advanced tab.
4. Under Browsing, click to clear the Enable folder view for FTP sites check box.
5. Click to select the Use Passive FTP (for firewall and DSL modem compatibility) check box.
6. Click OK.

Internet Explorer behaves as a Standard mode FTP client if you select the Enable folder view for FTP sites check box, even if you also select the Use Passive FTP check box. If you clear the Enable folder view for FTP sites check box and then select the Use Passive FTP check box, Internet Explorer behaves as a Passive mode FTP client.

Turns out that this KBA was correct if I only wanted to GET files in PASV mode. I wanted to PUT files, and after fussing, fuming and discussion with my partner Lisa, we concluded that you must skip step 4, Enable folder view for FTP sites.

Gee, and I was so convinced everything I read on the Web was true.

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID528 by Dave Piscitello  

Mike Andrews and James Whittaker have chosen an unfortunate title for what is a very good book describing the lamentable state of web application development and the plethora of security problems web applications pose.

I find the title disappointing because How to Break Web Software suggests this is another book by media darling attackers who seize every opportunity to show they are clever and everyone else is not. While the subtitle clearly has less shelf appeal, Functional and Security Testing of Web Applications and Web Services more clearly identifies what you'll learn should you read this book.

The authors begin by explaining the the problem space (web applications and emerging web services) and why this space is problematic (the distributed nature of the web, the extensive and extensible nature of the application development languages and protocols). They then describe web attack methodologies, and explain how each component of a web application (client, server, and the underlying network) can be attacked. The authors present a series of attacks, for each describing the attacker's objective, opportunity (when to apply the attack), how to conduct the attack, and most importantly, how to protect against the attack. The book concludes with discussions of authentication and privacy issues for the web.

This book is much more than a lame dissertation by a lame-oh clever enough to write a script that takes advantage of someone else's poorly written script. It is also written largely in "plain speak": if you know something about networking and web applications, you will be able to try many of the security tests the authors describe by simply reading the chapter and using the tools provided in an accompanying CD.

If I haven't convinced you to spend the twenty-odd dollars on a copy, at least read Fifty Years of Software: Key Principles for Quality, by James Whittacker and Jeffrey Voas. Reprinted as an appendix to the book, this article offers many insights into how software has evolved - or devolved - to the state we see today.

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID527 by Dave Piscitello  

VoIP has finally arrived as a mainstream application. IP PBX equipment sales topped $1 billion in 2005, for the first time outpacing traditional TDM PBXs, according to Dell' Oro Group. In fact, analysts predict that IP PBXs will account for more than 90% of the market by 2009. Before you deploy VoIP, however, you need to be aware of the security risks and the countermeasures that you can take.

Security is important in every context, but especially when you're replacing the world's oldest, largest and most resilient and available communications network. While no individual security measure will eliminate attacks against VoIP deployments entirely, a layered approach can meaningfully reduce the probability that attacks will succeed.

Read the rest of my feature article at Network World.

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID526 by Dave Piscitello  

David Strom's recent Web Informant column considers whether Cisco, like past industry giants IBM, DEC, and ATT, is now ripe to be challenged and dethroned by a leaner, meaner, and hungrier upstart. The column can be found at http://strom.wordpress.com/2006/05/11/is-cisco-vulnerable/.

I found myself mulling over related questions: has Cisco reached the point where it acquires rather than innovates to stay competitive, and is it acquiring in reaction rather than anticipation of market opportunities and needs?

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID525 by Dave Piscitello  

I've been invited to participate in the Closing Panel of Experts at The Eighth Annual International Techno Security Conferenceon June 7^th in Myrtle Beach, SC. The agenda has some interesting topics and I'm looking forward to hearing some of the invited speakers. According to conference host Jack Wiles, each expert will be given the opportunity to answer the following question:

"In your area of expertise, what do you see as the most pressing issue that our attendees (and the rest of the world) need to be aware of or prepared for prior to Techno Security 2007?"

It should be interesting. I suppose "world peace" won't be adequate...

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID524 by Dave Piscitello  

I've been experimenting with using content inspection at an http proxy as an added layer of defense against different forms of malware for a while now. Because certain spyware use archives and executables to install ActiveX controls, I added a proxy action to block CAB. ZIP, Java byte encoded strings, EXE and DLL file types. I applied this policy to content offered from all external servers, as a test for an article. I kept the policy in place to see what affect it would have on blocking malware at my perimeter.

Examining my logs for nearly a month, I confirmed that my policy was effectively blocking unintentional downloads. However, my blanket policy is too aggressive and blocks a few legitimate - and important - downloads. I've had to create exception policies for external sites I must trust. For example, I now have an exception policy to accommodate Windows updates (CAB files) and select open source sites (compressed archive files). Troubleshooting was easy for the open source problem: these were obvious because they were initiated from browsers. Troubleshooting Windows Update was not as obvious since I rely on Automated Updates.

Heidegger would be proud: I only realized Windows Update was not operating correctly by the "obtrusive" absence of silent installations and popups demanding I restart my PC;-)

Over the same period, I've configured my http proxy with a white list of approved http headers. My initial policy white listed header fields defined in the http standards. Adjusting this white list requires more attention, but it's not a huge burden. In most cases, browsers and http applications work even when header fields that do not comply with my policy are stripped. Again, Windows Update required an addition to the white list for the header X-AspNet-Version.

The biggest problem I've encountered thus far are sites that do not list content types in http headers. This is simply poor programming and it creates problem scenarios for security administrators who are trying to keep their trusted networks free of malware. A recent example I've encountered is the Stamps.com online store. I can use every other feature bundled in the Stamps.com client except the store, because my firewall blocks server responses where content type is missing.

An admin should ask, "what could be more suspicious than an http header that doesn't identify the content-types in the message?" But should admins create exception rules each time a web application developer elects or forgets to identify content type?

I don't think so.

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID523 by Dave Piscitello