Securing IM and P2P Applications

Ben Rothke writes "Noted security veteran Bruce Schneier has observed that for those organizations that have incorrectly deployed cryptography, it is akin to putting a big flagpole in front of your facility and hoping that it will stop any attackers from breaking in. Of course, any attacker with intelligence will simply go around the flagpole rather than running into it." Read the rest of Ben's review. Securing IM and P2P Applications for the Enterprise author Paul Piccard pages 454 publisher Syngress rating 9 reviewer Ben Rothke ISBN 1597490172 summary How to get a handle on the increasing number of IM, P2P, and IRC applications that are found on the corporate networks

Similarly, many organizations have deployed myriad security hardware and software products in their infrastructure. But when it comes to instant messaging and peer to peer applications, these applications often execute below the radar of many security products. This is due to the fact that the security infrastructure in many organizations was not architected to deal with such applications. These applications often have so much functionality that it obviates much of the security afforded by the security hardware and software products.

Using file transfer as an example, many organizations have policies and controls in place to stop the use of protocols such as ftp and tftp. This is fine, but that will only work for the ftp protocol. File transfer can still be carried out by most instant messaging clients, and that can pose serious security risks.

With that, Securing IM and P2P Applications for the Enterprise provides an excellent overview on how to handle, manage and secure IM, P2P, and IRC applications. This book is written for security and system administrators that need specific details on how to control and secure IM, P2P and IRC applications in their organization.

The need to get a handle on IM and P2P is crucial given that IM has turned into a global communications medium with most organizations today reported that they allow it for business usage. Many marketing and technical support calls are now handled via IM and this translates in to well over 250 million IM users worldwide. P2P is great for downloading music and movies, but that that poses serious security and legal liability risks when done on most corporate networks.

But with all the benefits that IM provides, it introduces many security and privacy risks. IM viruses, identity theft issues, phishing, spyware and SPIM (SPAM over IM) are just a few of the many risks. These risks can turn into intellectual property losses and legal liability issues especially when they are combined with targeted attacks on corporate IM users. Companies that don't have an effective way in which to deal with IM and P2P are in serious danger as most IM and P2P threats fly under the radar of many traditional security solutions.

The book has a fairly straightforward approach. Chapter 1 provides an introduction to IM and the most common security issues that IM brings into an organization. The bulk of the remainder of the book details various different IM applications in Part 1 (AIM, Yahoo, MSN, ICQ, Google, Skype), P2P applications in Part 2 (Gnutella, eDonkey/eMule, BitTorrent, FastTrack) and IRC networks and applications in Part 3.

Each chapter details the specific architecture of each application, its protocols, security issues, and solutions in which to secure the application. System administrators can use many of the checklists to quickly perform the initial steps necessary to secure their organization from unauthorized IM, P2P, and IRC applications.

Each chapter also provides significant details about the internals on how each application operates. In addition, various 3rd-party tools that can be used to secure and limit the various applications are listed.

Many companies are finding that a significant amount of their bandwidth is being used by P2P applications and Part 2 describes how to secure networks from the use of P2P applications. This is not always an easy thing to carry out given that many P2P applications, such as Gnutella are designed to easily bypass many of the security control mechanisms placed against it. Administrators will find that in this case, simply blocking Gnutella ports will not block all Gnutella traffic and the application still will be able to run. What is required in this case is the use of a firewall that supports deep packet inspection. Chapter 9 helpfully lists the commands to use when using iptables to block Gnutella traffic.

Chapter 12 provides an interesting look at FastTrack, which is the P2P protocol and network used by clients such as Grokster, Morpheus and other file sharing programs. The chapter also uses Ethereal to detail the internals of FastTrack.

Part 3 deals with IRC and is the sparsest part of the book. This is due to the fact the P2P and IM are much more heavily used on enterprise networks, which this book is geared to.

The only negatives about the book are its price, and some of its formatting. At $49.95, it is on the higher-end of computer security books, with the majority of such titles being in the $25.909 - $39.99 range. The formatting uses a font size that is somewhat larger than other book. This seemingly serves to achieve a high page count.

In addition, the book often references tables of secondary information that spans a few pages (for examples see pages 72-80, 115-120 and more). Such information would be better served in a multiple-column table in a smaller font. Printing the information in such a manner can cut down on the page total, and save a few trees at the same time.

Besides those two minor issues, Securing IM and P2P Applications for the Enterprise is a most helpful guide. Security and system administrators can use the book to get a handle on the increasing number of IM, P2P, and IRC applications that are found on the corporate networks they support.

Ben Rothke, CISSP is a New York City based senior security consultant with ThruPoint, Inc. and the author of Computer Security 20 Things Every Employee Should Know (McGraw-Hill 2006) and can be reached at ben@rothke.com"

You can purchase Securing IM and P2P Applications for the Enterprise from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

IM and P2P Controls are Horrid

[MandoSKippy]

I work as a security consultant for Hospitals and Banks. In some of the audits I have done, I have found that are controls, or even considerations for IM. Even P2P, I was at one bank that the VP of the place ordered the third party vendor to open ports on his firewall for P2P stuff. I am no legal expert, but I told the 3rd part to get it in writing from the VP (if he still wants it open after our scathing report) that the VP orders the 3rd party to open those ports. That way, the Bank and the VP are the liable ones. I couldn't believe that though. PLus if you consider IM, most places don't have checks on the application layers especially regarding IM. I have seen quite a few banks with Egress filters, but those only block some IM protocols from connecting, many just default to port 80. It's a scary world out there, and the IM and P2P isn't helping anything.

Admin's problem

[CarpetShark]

Certainly, social engineering attacks come down to user education.

BUT, there is NO excuse for not having the technical side locked down. It's all too common for people to claim that you can't protect against someone clicking on a link. The fact is, you CAN. Quite simply, install a secure browser (dump IE, in other words), put it through a filtering proxy like dansguardian, and then close http ports on the firewall, except for the proxy server itself. Disable webmail at the web proxy, and disable downloads anyway at the same proxy. If you need windows update or something like that to work, you can explicitly allow certain sites. But DON'T allow any more than strictly necessary. Don't allow SSL, except to trusted sites where no uploads or downloads or conversations take place.

Likewise, install a secure email client, and have mail filtered through a company mail server, disable HTML mail and encrypted mail.

These are basic security precautions. But already, you've secured your organisation far beyond most of the windows shops out there that get virus and spyware issues every day.

It doesn't take a genius, it just takes you to choose what technology you allow on your systems, and to use it wisely.

Re:False assumption

[slim]

There's really no need for IM at work,

I work in a corporate environment with geographically diverse colleagues, and IM is an extremely useful medium for doing Real Work. You might like to argue that we could just as easily use the phone, but IM has advantages over the phone for certain applications. Especially, it's nice to be able to supplement phone conversations with IM -- we'll cut and paste email addresses, code fragments, log fragments, even screenshots rather than try to read them out or describe them.

On telephone conference calls, IM is a useful out of band medium for comparing notes with colleagues; "Should I mention x?", "Don't forget y". ... but if you really really want it, use a corporate IM solution (such as Exchange IM or Apple iChat) to keep things local. Problem solved.

I agree with this. OTOH, it's in my employer's interest to allow me access to MSN messenger. Some of my technical peers work for different companies. If I have external IM, I can go to them for technical assistance (and they can come to me: it's a two way street).

Re:The same way parents keep a handle on their kid

[Molochi]

In my experience, malicious users aren't hired. They are created by the company that employs them.

Ironically

[Orion Blastar]

most companies that try to lock down their Internet programs often use Internet Explorer and Microsoft Outlook as the default web browser and email client. Yet these two programs have the most exploits of any Internet based programs out there. So even if you do lock down the ports of the firewall and stop users from installing programs, chances are the exploits will install the malware for you when they get the wrong email or click on the wrong link.

99% of the malware infections that happened in the past four places that I worked in, were caused by management clicking on the wrong email or wrong link in Outlook or IE. They did lock down their Internet, turned off port forwarding, took away admin access, prevented the install of new programs (which screwed up Visual BASIC and MS-Access development, because they needed Admin access or else things don't work via certain controls), and other things.

I think one of the funniest momments was getting the "Love Bug" email from the Network Administrator 12 times in a row that said "I LUV YOU!" over and over again. Guess who was using MS-Outlook and McAfee Anti-Virus and got infected due to some exploit? Needless to say I was smart enough not to open up those emails, unlike my co-workers who did, and sent me their own "I LUV YOU!" emails. :)