First of all, welcome to EH-Net.

Secondly, here are a few things to go on:

1. Cain & Abel for man-in-the-middle attacks to be able to grab switched traffic. See video from our very own Brian Wilson.

2. One could always get in through a wireless AP, and therefore then be on the same network segment as others in your company. This would also allow sniffing directly or via MITM.

3. Client-side attacks are the biggest thing right now. Get someone to click on a "bad" link in a browser, install some kind of malware, capture local traffic with a sniffer or keylogger, send passwords back to the bad guy.

Hope this helps,
Don

There are two things that I think you need to impress on your employers.

1) Someone can eventually find a way in.  An attacker only needs one misconfiguration or unpatched vulnerability to get access to some system.  Even if you have good security practices and are patched up-to-date, a new exploit could be released tomorrow that leaves you vulnerable to every script kiddie who decides to take a poke at you.

2) Once an attacker gets in, he usually wants to keep his access and move to other systems within the network.  The primary means of expanding his access are cracking passwords, or otherwise stealing credentials from the first machine, and sniffing the network to get other credentials.  Many people don't believe that it's possible to sniff switched networks, but many also think the Earth is flat.  Tools such as Cain and Abel, and Dsniff have made sniffing on switched networks relatively easy.

Good security isn't only about keeping the bad guys out, it's also about containing the damage once they get in.  If an attacker gets into one machine and can then sniff FTP, telnet, POP, LM/NTLM, you're wide open.  If he gets in but has limited network access (due to firewalls, VLANs), is unable to crack the passwords on the system, and can't sniff any useful traffic, he has a much more difficult task ahead of him.  That's not to say that he can't still own the whole network, but it raises the bar significantly in terms of skill and time.  Increased time is increased risk for the attacker; the longer he is logged in and putzing around on your systems, the more likely he is to get caught (especially if you have good logging and some IDS in place.)

Cheers.

Very nicely said indeed,

I will just add -

The key to security these days is the buzz word "Defense in Depth", layered security. It is all about protecting your crown jewel "the data" with multiple layers of protection and having some good ways to monitor yr defenses for breaches. Its not the question of "if" your network will be breached but "when" it will be breached. Patching, Anti virus, good password policies are great start but there is a zero day for something everyday, mostly with the client and application softwares and i guess there are no protections for "zero days" yet. In that case the layered enclaves are only way to slow down the attacker and protecting your most precious day.

Ummm .. I guess thats what we all need to emphasize to our employers

We test systems all the time and always find FTP or telnet in use. The good thing for us is that the systems are on a closed system, but because telnet and ftp transmit user names and passwords in the clear, any one on the network with a sniffer can get them. So even on the inside, don't discount the threat posed by another insider. They already have physical access to your network, it is just a matter of gaining greater access. Most people are lazy about user names and passwords and often use the same for multiple accounts.
Lets say you have a sysadmin with user name jdoe and a password of passwd for his system. Lets then say he uses it for and ftp session and that gets picked up by some one else on the network with a sniffer that does not have complete admin rights. That person could then try jdoe's credentials to gain greater access to the system. The moral here is that whether a person is on the outside or inside, clear text protocols like ftp and telnet are a bad idea.

FTP itself may or may not be a threat, depending on the contents of the FTP files and exploitability of the FTP app from within.  You can also set up FTP to be anonymous, in which case this argument is dead.

Telnet itself isn't necessarily a threat - it's the use of telnet to log into a system (ok, technically, it's the transmittal of username and password in cleartext, but you get the idea).  If you intend to allow remote logins, you might as well dictate in the corporate policy that ssh be used.  And if you go that route, you might as well require putty to be used for file transfers.

FTP and telnet (for logging in) are obsolete protocols in 90% of the cases today, and the alternatives are certainly not difficult to implement.  Also, on a tangent, I am baffled why people continue to use telnet in the first place - netcat is much more powerful, and doesn't have the problem of data manipulation that telnet has (...steps off soap box).

I'm curious what you see as the advantages telnet have over netcat.

If you were using Netcat as an administrative tool this wouldn't be a problem because you could exclude Netcat from the AV.