Re: How important is IM? was RE: How important is the PSTN
Rizzo Frank <frank.rizzo@ghettocolo.com> wrote:
By "IM" I assume you're referring to Instant Messaging as an ideal, not any particular protocol or vendor implementation. Which begs the question, is "IM" is a risk
IM has been a risk since it was introduced as the Unix `talk` program. Responsible corporate security policy should at least address it. Many such policies, including some I wrote after this post, have forbidden IM for some time now. <http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=_jfe4.1731%24T01.55862%40nuq-read.news.verio.net> Whether blocking IM is a prudent strategy at your organization depends on the value of the data "messaged", the IM application, and routing of IM packets. In common use IM does expose many organizations to a non-trivial risk of corporate espionage. -- Roger Marquis (ex-CSO) Roble Systems Consulting http://www.roble.com/
On Thu, 27 Jun 2002, Roger Marquis wrote:
IM has been a risk since it was introduced as the Unix `talk` program. Responsible corporate security policy should at least address it. Many such policies, including some I wrote after this post, have forbidden IM for some time now.
Essentially every multi-user operating system or network had some variation of the 'talk' program. IBM had the SEND command, DEC had the PHONE command, for some reason people want to use this functionality. Of course almost all of these "risks" exist with most other types of electronic communications commonly used in corporations including e-mail, two-way pagers, html, etc. Is AIM more or less secure than Outlook 97/2000/2002? E-mail is still the largest source of malware in most organizations followed closely by the Web. But I don't hear many organizations suggesting forbidding the use of e-mail or the web. The general principal is correct. You should disable services you don't use. If you don't use Unix 'talk/ntalk' you should disable it. If your machine isn't a web server, you should disable IIS/Apache. If your machine isn't a mail server, you should disable Exchange/Sendmail. If you aren't using IM, you should disable AIM, Yahoo IM, MSN Messenger, etc. It is annoying some vendors start these products automatically when you install other products such as Netscape or MSN. Despite what security people say, if you are going to use e-mail, the web or IM, the question is how can you do it safely? Heck, I read a recent article how even the US military is starting to use a version of IM for its battlefield coordination of activity. With IRC you can set up an organizational IRC server. Local users connect to it rather than "wild servers." Set up the IRC server to implement appropriate screening for your organization. Peer-to-peer IM products are a little harder because they assume direct connectivity between users, but you could use combinations of NAT/Proxy/SOCKS/Firewall packet inspection. Encryption of IM will probably be as wide-spread as encryption of e-mail, i.e. not very. But with the existance of OpenSSL, implementing a SSL aware IM is just a small matter of code. So instead of just saying no, how about coming up with same ways to solve the how to do it securely.
On Fri, 28 Jun 2002, Sean Donelan wrote:
Encryption of IM will probably be as wide-spread as encryption of e-mail, i.e. not very. But with the existance of OpenSSL, implementing a SSL aware IM is just a small matter of code.
In case it's not a well-known project, I'll propose something I was recently introduced to (Hi Scott!), silc. http://www.silcnet.org/ "SILC has secure key exchange protocol that is used to create the session keys for each connection. SILC also provides strong authentication based on either passwords or public key authentication. All authentication data is always encrypted in the SILC network. Each connection has their own session keys, all channels have channel specific keys, and all private messages can be secured with private message specific keys." Easy to set up and use, and if you're familiar with irc, you can figure it out quickly. I'm quickly finding it to be most useful. Now back to round 500 of the peering debate. Charles
So instead of just saying no, how about coming up with same ways to solve the how to do it securely.
With IRC you can set up an organizational IRC server. Local users connect to it rather than "wild servers." Set up the IRC server to implement appropriate screening for your organization.
I've done just this for a small neighborhood wisp. There are users of varying skill levels who want to be a part of the noc team. Rather than creating on important servers, or giving access to routers, for purposes of diagnosis, I'm using the perl Net::IRC module to build a number of small bots with very specific functions... e.g. syslog messages and mrtg stats sent to a noc channel. The next level will be to write a bot some with interactive access on the network so a request to 'traceroute x' or 'sh int' can be done by anyone with channel ops (and everyone present gets the benefit of the ouput if there's a problem). Eventually I will tie this into some type of text-to-speech on the client side, so that critical conditions can be brought to our attention even if the window is out of focus or we're all afk. It's not hard to use SSH tunneling / VPN as well, ensuring that the noc console application can be used securely across untrusted networks. Mike
participants (4)
-
Charles Sprickman -
Mike Lewinski -
Roger Marquis -
Sean Donelan