Security Monitoring

Practical Considerations for Selecting Targets

My Nokia smartphone drives me crazy alerting me to things that I don’t need to know, that I can’t do anything about, and that interfere with basic operations (such as making phone calls). One particularly annoying message, “Packet Data Started,” often appears just as I’m beginning to dial a number, forcing me to acknowledge the message and restart my number dialing. Nokia thoughtfully included this feature to keep users without unlimited data plans informed that their phone is about to incur data charges. In my case, I have no need to see the message, since I have an unlimited data plan.

Don’t configure your systems like my smartphone, collecting events for which you don’t intend to take action. If you’re able to fully monitor a system, but you can’t do anything about the events that are generated, why bother monitoring it? Event collection is always necessary to support investigations. Even when you’re not actively monitoring events, you must collect the events to support incident response. For targeted monitoring, however, events that you cannot mitigate are a distraction and should not be alerted. For example, Figure 4-6 shows an Oracle alert from a Security Information Manager (SIM) system.

Figure 4-6. Oracle Application Server alert

The Importance of Secondary Events

“Because of the probability that an intruder will tamper with logs on a compromised system, it is important to safely collect copies of log messages in a centralized location.”^[38]

Policy-based monitoring recommends a narrow, targeted approach to security monitoring that filters out all unrelated events. It requires deep analysis and tuning to weed out extraneous events. What should you do with the events shunned from your monitoring system? Store them in a safe place to support incident response and investigations.

When responding to a security incident, you will be focused on specific systems affected during a specific period. “Secondary” events that might normally be tuned out of a monitoring system take on new importance. These events are useful to illuminate a problem, aid in mitigation, trace activity, and attribute actions.

Collect as many events as you can store, and keep them for as long as you can. Archive all the security events you’ve collected to a server so that you can search them easily to support your incident response and investigation efforts. You can forward selected events in parallel to your security monitoring system for processing, where they will be analyzed or dropped based on the monitoring philosophy and procedures. Though policy-based monitoring recommends tuning out many events, it’s still important to store all events (monitoring and secondary events) in archival storage for as long as possible.

This event seems to detail an attack against an Oracle application server. If you know that you’re not running Oracle application software, or that no one at the company can analyze the target systems for signs of attack or mitigate the problem, you’re wasting your time alerting about the event.

Political blockades are another source of frustration for security monitoring. Although the security team may do an excellent job discovering security problems, getting the support teams to address the problems may be politically infeasible. Don’t waste your time targeting such systems, if you can avoid it. Take peer-to-peer (P2P) software, for example. It’s relatively easy to detect, and you can likely track down the individuals using it on the corporate network (e.g., to download movies). If management and human resources are unwilling to enforce policies governing its use, however, there’s no benefit to tracking them down in the first place.

---

^[38] Richard Beijtlich. Extrusion Detection (Addison-Wesley Professional, 2005).