UC Berkeley security policy mandates compliance with Minimum Security Standard for Electronic Information for devices handling covered data. The recommendations below are provided as optional guidance to meet continuous vulnerability assessment and remediation requirements.
Requirement
Resource Custodians must continuously monitor for signs of attack and compromise on all covered devices.
Description of Risk
Attackers can discover and compromise covered data on devices that are not secured against vulnerabilities.
Recommendations
Intrusion Detection Systems (IDS) are automated systems that monitor and analyze network traffic and generate "alerts" in response to activity that either match known patterns of malicious activities or is unusual. In some cases, alerts trigger further automated processes such as recording the suspect activity and/or scanning the computer(s) involved for signs of compromise. IDS allows resource proprietors and custodians to respond timely to covered devices that are compromised or imminently in danger of being compromised.
IDS can be either network or host-based. A network-based IDS monitors network traffic for particular network segments or devices and analyzes network, transport, and application protocols to identify suspicious activity. A host-based IDS (HIDS) monitors the characteristics of a single host and the events occurring within that host for suspicious activity. For more discussion on HIDS, please see the relevant section in Additional Resources.
The Information Security Office (ISO) provides a centralized, MSSEI compliant, network-based intrusion detection program that monitors systems on the campus network. By registering as directed in MSSEI “Annual Registration” requirement, covered devices are enrolled in additional monitoring services. ISO alerts from the IDS program on covered devices should be responded to in a timely fashion, as defined in your system’s Incident Response Plan (see MSSEI 16).
Off-campus Networks
In cases where covered devices are hosted outside of campus networks, such as collaborating research labs and agencies, ensure non-campus networks also maintain equivalent intrusion detection controls that follow the recommended practices below:
- Use industry-standard network intrusion detection system (IDS) tools to analyze signatures and network behavior for signs of attack or compromise. See Additional Resources for examples of common IDS tools.
- Secure IDS components appropriately. See Additional Resources section for additional guidance.
- Schedule automated regular updates to detection signatures such that new and emerging threats can be detected.
- Capture at least packet headers of traffic and retain for at least 7 days, to be used as forensic data in case of a possible compromise.
- Develop processes to send suspicious activities alerts to the appropriate resource custodians and proprietors.
- Integrate incident response procedures to investigate and escalate confirmed incidents detected by IDS.
Additional Resources
Securing IDS
Securing IDS components is very important because IDSs are often targeted by attackers who want to prevent the IDSs from detecting attacks or want to gain access to sensitive information in the IDSs, such as host configurations and known vulnerabilities. IDSs are composed of several types of components, including sensors or agents, management servers, database servers, user and administrator consoles, and management networks. All components’ operating systems and applications should be kept fully up-to-date, and all software-based IDS components should be hardened against threats. Specific protective actions of particular importance include
- keeping operating systems and applications fully up-to-date with latest versions from the software vendor
- creating separate accounts for each IDS user and administrator
- restricting network access to IDS components, and
- ensuring that IDS management communications are protected appropriately, such as encrypting them or transmitting them over a physically or logically separate network
- back up configuration settings periodically and before applying updates to ensure that existing settings are not inadvertently lost.
Administrators should maintain the security of the IDS components on an ongoing basis, including verifying that the components are functioning as desired, monitoring the components for security issues, performing regular vulnerability assessments, responding appropriately to vulnerabilities in the IDS components, and testing and deploying IDS updates.
Source: NIST Guide to Intrusion Detection and Prevention Systems
Host Based IDS
HIDS can be a good complementary solution to ISO's network-based IDS program, as it provides additional detection capabilities as a result of its access to the local operating system and file structure. HIDS can provide additional detection is by installing agents on monitored systems. A central management server typically controls the agent software over the network, which maintains agent configuration as defined by the HIDS administrator and collects events from the agent software. From the collected events, the central HIDS server is able to correlate activities from all of its monitored hosts based on predefined signatures and customized rules to produce alerts on suspicious or malicious behaviors. The collected events can also be sent to log correlation software (e.g. ISO Log Correlation program) for further analysis.
Some of the additional detection capabilities include:
- File-level detection
- File integrity checking involves periodically generating message digests or other cryptographic checksums for critical files, comparing them to reference values, and identifying differences. File integrity checking can only determine after-the-fact that a file has already been changed, such as a system binary being replaced by a Trojan horse or a rootkit.
- File attribute checking is periodically checking the attributes of important files, such as ownership and permissions, for changes. Like file integrity checking, it can only determine after-the-fact that a change has occurred.
- File access attempts. An agent with a filesystem shim can monitor all attempts to access critical files, such as system binaries, and stop suspicious efforts. The agent has a set of policies regarding file access, so the agent compares those policies to the characteristics of the current attempt, including which user or application is trying to access each file, and what type of access has been requested (read, write, execute). This could be used to prevent some forms of malware from being installed, such as rootkits and Trojan horses, as well as preventing many other types of malicious activity involving file access, modification, replacement, or deletion.
- Code Analysis
- System call monitoring. The agent knows which applications and processes should be calling which other applications and processes or performing specific actions. For example, an agent could recognize a process attempting to intercept keystrokes, such as a keylogger. Agents can also restrict which drivers can be loaded, which can prevent the installation of rootkits and other attacks.
- Application and library lists. An agent might monitor each application and library (e.g., dynamic link library [DLL]) that a user or process attempts to load and compare that information to lists of authorized and unauthorized applications and libraries. This can be used not only to restrict which applications and libraries can be used, but which versions of them can be used.
- Configuration monitoring
- Some agents can monitor a host’s current network configuration and detect changes to it. Typically all network interfaces on the host are monitored, including wired, wireless, a virtual private network (VPN), and modem. Examples of significant network configuration changes are network interfaces being placed in promiscuous mode, additional TCP or UDP ports being used on the host, or additional network protocols being used, such as non-IP protocols. These changes could indicate that the host has already been compromised and is being configured for use in future attacks or for transferring data.
Source: NIST Guide to Intrusion Detection and Prevention Systems
Common IDS Tools
- Snort - Snort is an open source network intrusion prevention and detection system (IDS/IPS) developed by Sourcefire. Combining the benefits of signature, protocol, and anomaly-based inspection, Snort is one of the most widely deployed IDS/IPS technology worldwide.
- Bro - Bro is an open-source, Unix-based Network Intrusion Detection System (NIDS) that passively monitors network traffic and looks for suspicious activity. Bro detects intrusions by first parsing network traffic to extract its application-level semantics and then executing event-oriented analyzers that compare the activity with patterns deemed troublesome.
- OSSEC - OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.