Implement switch security on your network
Takeaway: Switch security involves challenges. Take a look at how you can ensure switch security in your organization.
When it comes to securing internal networks, one area that organizations often overlook is switch security. Most companies tend to focus on their borders and end users, forgetting the devices that connect the two.
Ensuring switch security in your organization basically comes down to two steps: Defining what users can see, and defining what they can connect.
What you see
Every business-grade switch allows you to define virtual local area networks (VLANs). Organizations typically implement VLANs for the following reasons:
Broadcasts: A VLAN doesn't pass broadcast traffic to nodes that aren't part of the VLAN.
Performance: A VLAN can reduce the number of router hops and extend your local topology between user workstations and resource servers, increasing the apparent bandwidth for network users.
Departments: A VLAN can segment departments that use bandwidth-intense applications. You can also dedicate a VLAN to specific types of job roles (e.g., executives, kiosk workstations, etc.).
Security: A VLAN allows organizations to separate sensitive clusters of systems from the rest of the network, decreasing the likelihood that users will gain access to information on these clients and servers.
What you connect
Port security is also available on every business-class switch. Some switches allow very in-depth settings; others just provide some of the basics. Here's a look at some of your options:
MAC Locking: This involves tying a Media Access Control (MAC) address of one or more connected devices to a physical port on a switch. If you lock a switch port to a particular MAC address, you don't have to worry about superusers or internal black hats creating backdoors into your network with rogue access points.
MAC Lockout: This disables a specified MAC address from ever connecting to a switch.
MAC Learning: Using knowledge about each switch port's direct connections, the switch can set security based on current connections.
Remote Configuration: Limit remote configuration to specific IP addresses, using SSH instead of Telnet. Telnet passes usernames and passwords in clear text, potentially allowing everyone on the LAN segment to see login credentials.
Final thoughts
Switch security does involve challenges, particularly when it comes to setting up and deploying new workstations in your help desk area. This is definitely an issue you should consider when implementing a switch security policy.
Network administrators who balk at port security because it's labor-intensive and requires constant management should consider this: Port security stops people from attaching wireless access points and bypassing your site security. That alone should be a good enough reason to implement switch security on your network today.
By Michael
When it comes to securing internal networks, one area that organizations often overlook is switch security. Most companies tend to focus on their borders and end users, forgetting the devices that connect the two.
Ensuring switch security in your organization basically comes down to two steps: Defining what users can see, and defining what they can connect.
What you see
Every business-grade switch allows you to define virtual local area networks (VLANs). Organizations typically implement VLANs for the following reasons:
Broadcasts: A VLAN doesn't pass broadcast traffic to nodes that aren't part of the VLAN.
Performance: A VLAN can reduce the number of router hops and extend your local topology between user workstations and resource servers, increasing the apparent bandwidth for network users.
Departments: A VLAN can segment departments that use bandwidth-intense applications. You can also dedicate a VLAN to specific types of job roles (e.g., executives, kiosk workstations, etc.).
Security: A VLAN allows organizations to separate sensitive clusters of systems from the rest of the network, decreasing the likelihood that users will gain access to information on these clients and servers.
What you connect
Port security is also available on every business-class switch. Some switches allow very in-depth settings; others just provide some of the basics. Here's a look at some of your options:
MAC Locking: This involves tying a Media Access Control (MAC) address of one or more connected devices to a physical port on a switch. If you lock a switch port to a particular MAC address, you don't have to worry about superusers or internal black hats creating backdoors into your network with rogue access points.
MAC Lockout: This disables a specified MAC address from ever connecting to a switch.
MAC Learning: Using knowledge about each switch port's direct connections, the switch can set security based on current connections.
Remote Configuration: Limit remote configuration to specific IP addresses, using SSH instead of Telnet. Telnet passes usernames and passwords in clear text, potentially allowing everyone on the LAN segment to see login credentials.
Final thoughts
Switch security does involve challenges, particularly when it comes to setting up and deploying new workstations in your help desk area. This is definitely an issue you should consider when implementing a switch security policy.
Network administrators who balk at port security because it's labor-intensive and requires constant management should consider this: Port security stops people from attaching wireless access points and bypassing your site security. That alone should be a good enough reason to implement switch security on your network today.
By Michael
Security Of Instant Messaging Cannot Be Ignored
Instant messaging (IM) platforms, such as AIM, Yahoo! Messenger and Google Talk, have moved beyond the world of high school chatter and into the world of corporate communications. Yet, in many cases, security policies and processes haven't caught up to this technology. It's now time to consider how instant messaging is, and should be, used in your organisation, and how to protect against IM threats.
Instant messaging policies
The first step is to clearly state your organisation's policy on instant messaging. Can users install and use IM software on systems owned by the organisation? If you have a strict "no outside software" policy, you may think you're covered, but keep in mind that Windows XP SP2 ships with Windows Messenger installed, creating a policy loophole.
Here's a set of questions you should consider when defining your organisation's IM policy:
Is IM use permissible on your network?
May users run IM software on systems owned by your organisation?
Does the organisation endorse/require a specific IM platform?
Is encryption mandatory?
Is IM acceptable for corporate use or for personal communications only?
Are there restrictions on the sensitivity of data that may be communicated via IM?
Is there a requirement to retain records of IM communication for any period of time?
Once you have a clear policy on IM use, educate your users on policy requirements and their responsibilities.
Instant messaging security measures
If you decide to allow instant messaging, blanket it with layers of protection to ensure you're organisation is protected against the viruses, worms and other malicious code that's become prevalent on IM networks. Run a modern antivirus program that includes IM scanning on all workstations, and consider a using network-based content filter that scans IM traffic for malware.
You also want to prevent the threat of eavesdropping on your traffic as it traverses public networks. Out of the box, IM software uses public servers hosted by the IM provider, which means all messaging must traverse the public Internet on its way to and from the server. If you think your users might send sensitive messages through IM (accidentally or intentionally), you should strongly consider encrypting that traffic. Unfortunately, encrypted IM is a relatively immature technology that typically requires a specialized client. One standout in this field is the free Trillian client by Cerulean Studios, which supports multiple IM networks and allows encrypted communications with other Trillian users.
The ultimate option in secure instant messaging is to run your own managed IM server or gateway. This eliminates the threat of outsiders intercepting internal messages as they cross the Internet by keeping the traffic on the local network, and it's actually easier than you might think. Many of these products allow you fine-grained control over the types and destinations of IM traffic on your network. In addition to the commercial products available, you may wish to consider the open-source Jabber IM server project.
Instant messaging is here for the foreseeable future and poses a significant challenge to information security professionals. If you're not able to block IM completely due to business requirements, you should certainly consider implementing strong controls to limit the risk this technology poses to your organisation.
Recommanding a program, Colasoft Capsa, to check if your IM is communicating safely.
By Mike Chapple From SearchSecurity
Instant messaging policies
The first step is to clearly state your organisation's policy on instant messaging. Can users install and use IM software on systems owned by the organisation? If you have a strict "no outside software" policy, you may think you're covered, but keep in mind that Windows XP SP2 ships with Windows Messenger installed, creating a policy loophole.
Here's a set of questions you should consider when defining your organisation's IM policy:
Is IM use permissible on your network?
May users run IM software on systems owned by your organisation?
Does the organisation endorse/require a specific IM platform?
Is encryption mandatory?
Is IM acceptable for corporate use or for personal communications only?
Are there restrictions on the sensitivity of data that may be communicated via IM?
Is there a requirement to retain records of IM communication for any period of time?
Once you have a clear policy on IM use, educate your users on policy requirements and their responsibilities.
Instant messaging security measures
If you decide to allow instant messaging, blanket it with layers of protection to ensure you're organisation is protected against the viruses, worms and other malicious code that's become prevalent on IM networks. Run a modern antivirus program that includes IM scanning on all workstations, and consider a using network-based content filter that scans IM traffic for malware.
You also want to prevent the threat of eavesdropping on your traffic as it traverses public networks. Out of the box, IM software uses public servers hosted by the IM provider, which means all messaging must traverse the public Internet on its way to and from the server. If you think your users might send sensitive messages through IM (accidentally or intentionally), you should strongly consider encrypting that traffic. Unfortunately, encrypted IM is a relatively immature technology that typically requires a specialized client. One standout in this field is the free Trillian client by Cerulean Studios, which supports multiple IM networks and allows encrypted communications with other Trillian users.
The ultimate option in secure instant messaging is to run your own managed IM server or gateway. This eliminates the threat of outsiders intercepting internal messages as they cross the Internet by keeping the traffic on the local network, and it's actually easier than you might think. Many of these products allow you fine-grained control over the types and destinations of IM traffic on your network. In addition to the commercial products available, you may wish to consider the open-source Jabber IM server project.
Instant messaging is here for the foreseeable future and poses a significant challenge to information security professionals. If you're not able to block IM completely due to business requirements, you should certainly consider implementing strong controls to limit the risk this technology poses to your organisation.
Recommanding a program, Colasoft Capsa, to check if your IM is communicating safely.
By Mike Chapple From SearchSecurity
