Incident response

Plixer One Enterprise combines Scrutinizer’s deep, environment-wide visibility and intuitive UI-driven workflows with advanced detection techniques for security events to enhance a team’s ability to respond to threats.

Overview

Scrutinizer’s “single-pane-of-glass” feature set is designed around providing maximum network observability via synergistic web interface functions and views that streamline monitoring and investigative activities.

Full visibility supporting incident response and other security processes

As part of an incident response plan, Scrutinizer ensures that SecOps teams have access to all the traffic and device information they need for investigation and remediation:

• Get comprehensive, contextualized details for intrusion detection system (IDS) and intrustion prevention system (IPS) events

• Access full network traffic forensics to watch for and investigate security information management (SIM) events

• View full IP to MAC address mapping history for all connected devices and endpoints

• See real-time and historical endpoint context and location

• Assess endpoint risk through layer 2 historical location tracing

• Glean additional insights from detection details via MITRE ATT&CK, STIX/TAXII, and other integrations

Web interface functions that promote more efficient response strategies and procedures

Scrutinizer enables more efficient general security and incident response workflows through multiple functions/features, including:

• Highly configurable UI views (alarm monitor, dashboards, network maps, etc.)

• Customizable data aggregation from any observation point(s) on the network

• Detections and alerts driven by by AI/ML and Flow Analytics

• Customizable notification options for alarm/event details

• Deep visibility for both on-prem devices and assets in the cloud

• Collaborative features that promote sharing investigation results/insights between members and/or teams

Workflows

The following workflows show how the additional visibility and workflow enhancements enabled by Scrutinizer can be leveraged by SecOps teams for monitoring and incident response:

Responding to Alarm Monitor security alerts

Scrutinizer leverages a range of technologies to alert users to anomalous and potentially malicious network activity through its library of alarm policies. Once policy violations are reported via the Alarm Monitor views, security teams can drill into individual event details to evaluate whether further investigation is necessary.

Workflow

To investigate an alarm policy (e.g., Data Exfiltration, Data Accumulation, etc.) violation reported in the Alarm Monitor:

1. Click on the alarm policy to open the summary view.

2. Review the activity timeline and hosts involved.

3. If further investigation is warranted, drill into individual event artifacts for more details.

4. Click the icon next to an IP address or hostname to run an automatically filtered report and examine additional activity/hosts associated with the event.

Hint

For additional context and/or details related to how and why the host was compromised, review all alarms leading up to the policy violation.

Scrutinizing an infected host

After a user is infected with a virus, the security team must identify what other hosts on the network may have communicated with the infected host.

Workflow

After the infected host is discovered/reported, the following steps can be used to identify other hosts it has interacted with:

Note

This workflow relies on usernames acquired from a network device (router, firewall, etc.) or through enabled integrations (e.g., Active Directory LDAP). If usernames are not available, host IP addresses can be used as identifiers instead.

1. Under Explore > Exporters > Entities > Usernames, search for the infected host/username and click on it. A new view will open.

2. Review the alarms/events associated with the host, which may include the following violations:

• P2P and Lateral Movement (infected host may be attempting to extend access further into the network)

• TCP, UCP, XMAS Port Scan (infected host may be pinging the network for reconnaissance)

3. Create/run a report with the username applied as a filter to identify all activity where the infected host was either the source or the destination of traffic. Ensure that the time range includes a period before the infection was reported or discovered.

Hint

When viewing information associated with a username, click the graph icon to run a report with the username applied as a filter. The filter will be retained even when pivoting to other report types.

4. Review the output or pivot to different report types for insight related to who, what, when, where, why, and how the infected host communicated on the network:

• Protocols the host was seen using

• Countries the host communicated with

• Firewall events (through vendor-specific report types, e.g., ACL rules, NAT translations, etc.)

• Destination FQDN reports

• Activity associated with the host before and after the infection (for additional insight into the techniques used in the initial attack)

5. If the Host Indexing FA algorithm is enabled, navigate to Explore > Search to look up historical data associated with the IP address of the infected host. This information may provide additional insight based on typical communication patterns and reduce mean time to know (MTTK) during the investigation.

Note

If the Use Host Index option under Admin > Settings > Reporting is enabled, Group and All Device reports will use the host index to limit the scope of exporters checked when a host filter is applied.