Network Security Monitoring (NSM)

4.3 Network Security Monitoring (NSM)

  • Network security monitoring includes:

    • Visibility: Helps detect vulnerabilities and unauthorized access.

    • Asset discovery and identification.

    • Network intrusion detection (NIDS).

    • Capture/analysis traffic and metadata.

  • Alerts from NIDS provide the initial point for an investigation, but often require additional context.

  • NSM provides the additional data needed to hunt and explore.

4.3 NSM - Switch SPAN/Mirror Ports

  • Switch mirror ports can sanitize traffic by dropping malformed frames, which can be used in layer 2 attacks.

  • This sanitization can blind IDSes to these attacks.

  • Malformed frames: Packets that are not as expected and do not follow protocol specifications.

4.3 NSM - Network Taps (Test Access Point)

  • Network taps offer a more robust network sniffing option for mirroring traffic.

  • Taps send all frames to the monitoring port(s), including malformed frames.

  • Higher-end taps offer tap buffers, which can cache traffic that bursts above the interface bandwidth threshold, preventing overload of the monitoring interface.

4.3 NSM - Network Taps

  • Taps can present an additional point of failure.

  • Some taps are designed to 'fail open' in the case of a power outage: they will continue to pass traffic, but not send traffic to the monitoring interface(s).

  • Higher-end taps have two power supplies, which should be connected to separate electrical circuits.

4.3 NSM - Sensor Placement

  • Network monitoring depends on the location of network sensors.

  • The value of the data and alerts a sensor generates requires proper placement.

  • Consider placement in various network segments such as the Internet, DMZ, internal networks (IT, HR), internal servers (DCs, applications).

4.3 NSM – Security Onion

  • Security Onion is a Linux distribution by Security Onion Solutions, LLC.

  • It is an open-source Network Security Monitor with enterprise central management of sensors.

  • It can easily handle hundreds of NSM sensors.

  • Security Onion contains Zeek, Snort/Suricata, full PCAP storage, and many other features and tools.

4.3 NSM - Packet Captures

  • Network sensors listen promiscuously to network traffic.

    • Promiscuously: listens to all packets regardless of protocol type or destination

  • A small office (1 server, 1 firewall, 60 workstations) can produce approximately 8TB of pcaps in one month.

4.3 NSM - Generic Network Traffic Analysis (NTA) Architecture

  • The architecture involves:

    • Traffic collectors (may store pcap) at various points (Egress/S-N, E-W1, E-W2) to capture network traffic.

    • These collectors gather Layer 7 metadata and flow data.

    • A metadata aggregator collects the metadata.

    • Analytics and detection mechanisms process this data, using signatures, rules, and models, to generate alerts.

    • A dashboard provides visualization, and metadata storage facilitates search capabilities.

    • The architecture may be implemented in the cloud.

Case Study - No NSM

  • Lack of NSM in a network with DMZ, web/proxy servers, internal servers, and a corporate LAN (with PVLAN except for IT).

Case Study – Multiple NSM Sensors

  • Implementation of multiple NSM sensors in a network with DMZ, web/proxy servers, internal servers, and a corporate LAN (with PVLAN except for IT).

  • Sensors are placed at various points using network taps and port mirroring.

  • NGFW is also present as part of network.

  • This setup helps architect the network for detection, protection, response, and visibility.

4.3 NSM -

Network Intrusion Detection System (NIDS)

  • Network intrusion detection is primarily a "find evil" device.

  • Three main methods of detection:

    • Signature-based: Identify known bad patterns and characteristics.

    • Anomaly-based: Identify changes from baseline activity.

    • Protocol analysis: Identify non-protocol/RFC specific behaviors.

  • Signature and protocol analysis have fewer false positives (false alarms).

4.3 NSM - Signature-Based Detection

  • Signature rules are powerful for catching known:

    • Command and Control activity (C2).

    • Trojan remote control/backdoors.

    • Policy violations and unwanted applications (e.g., Dropbox use).

    • Exploitation attempts.

    • Network scanning.

    • Indicators of compromise activity.

4.3 NSM - Snort NIDS

  • Snort is the most common IDS and many commercial solutions use it.

  • Its rule and rule format work on almost every IDS solution.

  • It contains built-in protocol analysis.

  • Example signature rule:

    • alert ip any any -> any any (msg:"INDICATOR-COMPROMISE id check returned root"; content:"uid=0|28|root|29|"; metadata:ruleset community; classtype:bad-unknown; sid:498; rev:11;)

4.3 NSM - Rules, Rules and More Rules

  • Maintaining rules on an IDS or IPS is a major task.

  • Too many rules:

    • Lead to performance issues.

    • Result in false positives/denial of service.

  • Too few rules:

    • Mean lack of detection or prevention.

4.3 NSM – Alert Investigation

  • IDS/IPS solutions have investigation workflows.

  • Alerts should be analyzed.

  • Results and findings should be recorded.

  • Example: Security Onion allows pivoting from alerts to packet capture data.

4.3 NSM - Security Information Event Management (SIEM)

  • SIEM is a comprehensive solution that collects, analyzes, and correlates security data from various sources.

  • It offers integration between various solutions, e.g., NSM + Sandbox + Flow Data + NGFW + Scripts, or Security Information and Event Management (SIEM) + NAC.

4.3 NSM - SIEM - Log Inspection

  • All system and network access needs verified.

  • Ad hoc reporting is inefficient and difficult to do.

    • Requires the organization to figure out how to access and use the data in a proper fashion

  • Central log collection and scripting is low cost

  • SIEM log collection and analysis are recommended.

  • Focus on key log sources.

  • Use log enrichment to enhance analysis (to look for abnormal events).

4.3 NSM -

Inline Malware Detonation

  • Analysis systems can sit inline on network (all traffic passes through a security device or system):

    • Not Real-time

      • User downloads an EXE from the internet

      • Sandboxing occurs after the user downloads the file

    • Real-time

      • User waits for the file to be analyzed before downloading

      • Setting delay for analysis