Intrusion Detection versus Intrusion Prevention

French | Spanish | Portuguese | Italian | German | Japanese | Chinese | Korean | Russian | Arabic

- The company does not have an incident response policy An IDS is pretty worthless if you don’t also have an incident response policy in place. Develop an incident response policy so there are clear lines of responsibility and reporting. Also clearly delineate how, where, and to whom to report suspicious activity.

- Unauthorized traffic is not logged Audit logs are necessary to provide a trail of evidence in case the network is compromised.With this information, the network administrator can devise ways to block the attack and possibly identify and prosecute the attacker. Information supplied by an IDS can be used for forensic analysis in support of an incident as well as to aid in normal traffic analysis.

- No established weekly backup procedures IDS data needs to be backed up to ensure that it is preserved in the event of a hardware failure of the IDS or in the event the IDS is breached.

- IDS antivirus updates procedures not in the standard operating procedure IDS systems require antivirus updates. Be sure that these updates are in the standard operating procedures for IT staff. Sometimes it’s the little things we overlook that bite us the hardest; this one’s a no-brainer but easy to overlook.

- Switches and cross-connects are not secure Since the intrusion detection and prevention system includes all hardware required to connect horizontal wiring to the backbone wiring, it’s important that all switches and associated cross-connect hardware are kept in a secured location, a locked room or an enclosed cabinet that is locked.This will also prevent an attacker from gaining privilege mode access to the switch. Several switch products require only a reboot of the switch to reset or recover the password.

Remote Access

- The management VLAN is not secured In a VLAN-based network, switches use VLAN1 as the default VLAN for in-band management and to communicate with other networking devices using Spanning-Tree Protocol (STP), Cisco Discovery Protocol (CDP), Dynamic Trunking Protocol (DTP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP) all untagged traffic. As a consequence, VLAN1 may unwisely span the entire network if it’s not appropriately pruned. If its scope is large enough, the risk of compromise can increase significantly.

- Remote Access Servers do not require encryption for end-user access You should ensure that only users who require remote access are granted it and that all remote access traffic is encrypted to the fullest extent possible.

- RAS does not use two-factor authentication Without strong twofactor authorization, unauthorized users may gain access to network services, devices, and data. Clearly, if an intruder gains control of network infrastructure devices, he or she could inflict damage to either the data or the network, causing loss of confidentiality, integrity, or availability.

- Remote Access Server connectivity isn’t logged Logging is your friend; keeping a log file of RAS connectivity is critical to keep track of who is attempting to log in, who did log in and when, and how long they were logged in. Reviewing log files daily will help you notice patterns and problems earlier in the cycle than reviewing log files infrequently (or never).

- RAS session exceeds 30-minute inactivity An RAS session that is inactive should be terminated to prevent session hijacking.Terminate idle connections after no more than 30 minutes of inactivity.

- RAS log retentions do not meet requirements Depending on organizational, legal, or regulatory requirements, you should keep log files for 30 days and archive them for one year.

- The logs are not viewed on a weekly basis Reviewing log files daily will help you notice patterns and problems earlier in the cycle than reviewing log files infrequently (or never).

- Modems are not physically protected Limiting the access to infrastructure modems and keeping accurate records of the deployed modems will limit the chance that unauthorized modems will be placed into the infrastructure. If an unauthorized person has physical access to a site’s modems, the switch or software settings can be changed to affect the security of a system.

- An accurate list of all modems isn’t maintained Keeping accurate records of the deployed modems will limit the chance that unauthorized modems will be placed into the infrastructure. It will also help you keep track of modems that are no longer used so they can be physically removed or disabled.

- Modems are not restricted to single-line operation Modems should be connected to phone lines that have very basic capabilities. If a phone line has advanced features such as call forwarding, it’s possible an intruder could take control of a modem, computer, or network. Keep it simple for better security.

- Proper call logs are not being maintained Logs of all in-bound and out-bound calls for modems and phone lines should be logged and reviewed on a regular basis. Hijacked modems could conceivably allow an attacker to steal phone time and incur long-distance charges on your company’s dime. Make sure you know what’s going on with modems and phone lines to avoid big phone bills or network intrusion.

- Callback procedures are not configured correctly One way to increase security is to implement a callback feature on the modem so that a caller’s call disconnects and the modem calls back a preprogrammed number. Ensure that if callback procedures are used, on establishment of the callback connection the communications device requires the user to authenticate to the system.

- RAS/NAS server is not located in a screened subnet Allowing a remote connection to the private network unchecked by the firewall enables a mobile user to violate the security policy and put the network infrastructure in a vulnerable position.The risk would be magnified if a remote access session were hijacked.

- The RAS/NAS is not configured to use PPP To securely protect the network, Network Access Servers (NAS) and access to them must be controlled to guard against outside or unauthorized intrusion, which could result in system or network compromise. If the NAS is accessed remotely, the risk of compromising a password or user ID increases.The authentication of the remote nodes must be controlled by encryption such as CHAP with MD5 or MS-CHAP with MD4.

- VPN gateway is located behind the firewall Allowing a remote connection to the private network unchecked by the firewall enables a mobile user to violate the security policy and put the network infrastructure in a vulnerable position.The risk would be magnified if the VPN connection were hijacked.

- The VPN connection is not using IPSec’s ESP tunnel Ensure that remote access via VPN uses IPSec ESP in tunnel mode. For legacy support, L2TP may be used if IPSec provides encryption or another technology that provides security such as AES, 3DES, SSH, or SSL.

- VPN is not configured as a tunnel type VPN Be sure that VPNs are established as tunnel type VPNs, which terminate outside the firewall (in other words, between the router and the firewall, or connected to an outside interface of the router). If VPNs terminate inside the firewall, you basically have taken the firewall out of the security mix and reduced your line of defense by one. Improperly deployed VPNs take away a firewall’s ability to audit useful information. We’ve walked through a lot of very specific security information in this section, some of which might be relevant to your organization, some of which might not be. What is highly likely, though, is that if you even scanned this section, you thought of a few things you might otherwise have overlooked, or it sparked you to make a note to check one thing or another.The key is to be thorough, and to that end, this list should have helped you make sure you covered some of the nitty-gritty details of network infrastructure security.