1. Role Of Network IDS in Network Perimeter Defense

2.  Identifying attacks and suspicious activity,  IDS data to can be used to identify security weaknesses and vulnerabilities, including policy violations.  IDS data is also an invaluable part of network forensics and incident- handling efforts.  Network IDS complements other perimeter defense components by performing functions that they cannot, such as full protocol and payload analysis.  IDS sensors can also work with other defense components to halt active attacks.  Network IDS is valuable in most environments for creating and maintaining a strong overall security solution.

3. Role Of Network IDS in Network Perimeter Defense 1.Identifying Weaknesses 2.Security Auditing 3.Policy Violations 4.Detecting Attacks from Your Own Hosts 5.Incident Handling and Forensics 6.Complementing Other Defense Components

4. 1. Identifying Weaknesses  IDS can be used proactively to find vulnerabilities and weaknesses and identify early stages of attacks  IDS can be used to reactively detect attacks against hosts and log what occurs.

5. 2. Security Auditing  Network IDS can assist in security auditing. You can use the IDS logs and alerts to identify weaknesses in network defenses.  For example, if a sensor sends alerts about suspicious Telnet activity from an Internet-based host and your firewall is supposed to be blocking all incoming Telnet activity, either your firewall is not blocking the traffic properly or your network has an additional connection to the Internet that is not secured properly.

6. 3. Policy Violations  Some IDSs enable you to receive alerts when certain protocols or well- known port numbers are used.  For example, if your users are not permitted to use the Internet Relay Chat (IRC) protocol, you could tune your IDS to alert you whenever it sees IRC traffic on the network.  Many Trojans, such as Sdbot, and other malicious code use IRC for communication, IRC traffic on your network could indicate that an incident has occurred. It could also indicate a user who is violating your security policy. Either way, it's activity you're likely to want to know about.

7. 3. Policy Violations  Along the same lines, IDS sensors can be useful in finding misconfigured systems on your own networks, such as a host that isn't using your web proxy server and is reducing the overall security level of your environment.  Sensors can also help you find rogue systems that unauthorized personnel are running.  for example, a user might set up a web server for her consulting business on her corporate workstation. When reviewing your IDS logs, you would see port 80 traffic directed to this box. Identifying improperly configured hosts and addressing their problems is a key part of reducing the vulnerabilities in your environment.

8. 4. Detecting Attacks from Your Own Hosts  IDS sensors can be used to identify outgoing attacks.  This use is particularly valuable in environments where outbound access is largely unrestricted. You certainly want to be aware of attacks that your internal hosts are performing on external entities.  In an environment where firewalls and packet filters are configured to let almost any activity out of your organization, an IDS is probably the only method you have of identifying such attacks.

9. 4. Detecting Attacks from Your Own Hosts  If your border devices place some restrictions on outbound activity, you might identify an attack by reviewing your firewall logs, but this is far less likely to happen because most firewalls have no signature capabilities and can't identify most attacks.  Moreover reviewing firewall logs is much more resource-intensive than reviewing the logs of an IDS sensor that checks outgoing traffic.

10. 5. Incident Handling and Forensics  In an ideal world, your organization would have staff monitoring your IDS logs and alerts 24 hours a day and reacting immediately to suspicious activity. Although organizations are increasingly implementing 24-hour monitoring, it's more likely than not that yours has not.  You probably receive a page when the most serious alerts occur, and you review your IDS alerts and logs as often as you can, given all your other duties. It's important that you review alerts as often as possible so that you can quickly identify serious attacks and react appropriately to them.

11. 5. Incident Handling and Forensics  Even if you don't notice that an attack is occurring until the damage has been done, the IDS data can still be invaluable to you.  IDS can show you which hosts were attacked and what attacks were used against them.  This critical information can help you recover from incidents much more quickly and identify the likely source of an attack.  It gives you the basic information you need when starting to handle an incident, and it indicates other hosts that might have related data, such as firewalls that the traffic passed through or other hosts that were attacked.

12. 5. Incident Handling and Forensics  IDS can be used for forensics.  You can use IDS logs to investigate an incident. Also, some IDS products enable you to monitor and log specified types of traffic.  For example, if you don't permit IRC to be used on your network, you might want to set your IDS to log all IRC traffic, which could then capture IRC communications between malware on one of your machines and a remote IRC server.  Of course, you need to consider the privacy rights of your users before configuring your IDS this way; legitimate users might be chatting with each other using IRC, and the IDS might record their conversations.

13. 6. Complementing Other Defense Components  Part of the purpose of network IDS is to correlate the activity that individual hosts might see.  If 100 hosts each record one failed Telnet attempt, no one might notice;  But if an IDS sensor records 100 failed Telnet attempts, it's much more likely to trigger an alert.  IDS sensors may work with perimeter defense components to stop attacks in progress.  IDS sensors can also perform functions that other perimeter defense components generally can't.

14. 6. Complementing Other Defense Components  For example, firewalls and packet filters have limited capabilities to examine traffic. Typically, they do not look at the contents of packet payloads, although some might do some basic protocol analysis.  Firewalls generally look at some of the most basic characteristics of traffic and accept, deny, or reject it accordingly.  A firewall might try to stop certain services from passing through by blocking certain port numbers, but it generally does little or nothing to evaluate traffic that uses allowed port numbers.  IDS sensors are designed to examine the contents of packets; some IDS sensors are even capable of doing full protocol analysis.

15. 6. Complementing Other Defense Components  A simple example of this is the identification of applications that run on unexpected ports. For example, a Trojan that is installed on a host might use TCP port 21 (usually associated with FTP control connections) for all communications with its Trojan master.  If your firewall is configured to let internal users FTP to external sites, the Trojan could initiate a connection to its master, and your firewall would respond as though it were an FTP connection and permit it.  However, the IDS sensor would actually analyze the content of the packets and alert you that the traffic was not FTP. You could then review the IDS logs for more information and investigate the host in question.

16. 6. Complementing Other Defense Components  A more complex example of the value of protocol analysis is the identification of various known and unknown attacks.  One of the most commonly used attack techniques is the buffer overflow, in which the attacker sets various fields or arguments to overly large or long values to attempt to overwrite memory locations.  By performing protocol analysis for example, validating the header and payload values in a DNS query the IDS can identify anomalous values that are possible signs of buffer overflow attempts.  Although stateful firewalls might do some protocol analysis, they are usually poor logging tools and have no signature capabilities.