The EDR solution shall provide a comprehensive Threat Investigation and Incident Response module that enables security analysts to visualize, investigate, trace, and respond to suspicious activities across endpoints and the network. The solution shall provide interactive tree views, process relationships, activity timelines, event filtering, detailed process and activity information, and endpoint response capabilities.
1. Network Activity Map
The EDR solution shall provide an interactive Network Activity Map in Tree View to assist analysts in understanding activities occurring across multiple machines.
The network map shall enable analysts to identify relationships between endpoints involved in an alert or attack. For example, when suspicious activity originates on one endpoint and subsequently communicates with or affects other machines, the analyst can visually trace the complete activity across the network.
2. Process Activity Map
The solution shall provide a Process Activity Map in Tree View for individual endpoints.
The process tree shall display the relationship between parent and child processes, allowing analysts to identify how an alert was generated and understand the sequence of process execution.
For example:
Email → File1.exe → File2.exe → System Process Injection
This view shall help analysts quickly identify suspicious process creation and execution relationships.
3. Attack Chain Visualization
The solution shall provide an Attack Chain / Activity Flow View to visualize the complete sequence of activities associated with an alert.
For example:
File received through email → File1 executed → File2 dropped → File2 injected code into a system process → Network communication
This capability shall help analysts understand the origin, progression, and impact of an attack.
4. Process Details
Analysts shall be able to view detailed information about any process involved in an alert, including, where available:
- Process name
- Process ID
- Parent process
- Child processes
- File path
- SHA-2/SHA-256 hash
- Digital signature information
- Publisher information
- File creation/modification information
- Command-line parameters
- User associated with the process
- Process execution time
- Network activity associated with the process
This information shall assist analysts in determining whether a process is legitimate, suspicious, or malicious.
5. Activity Details
The solution shall allow analysts to select an individual activity and view its detailed information.
Activity details may include:
- Activity type
- Timestamp
- Process responsible for the activity
- File involved
- Registry key/value involved
- Network connection details
- Source and destination information
- User/session information
- Action performed
- Result/status of the activity
This enables analysts to investigate individual events contributing to an alert.
6. Interactive Zoom and Navigation
The investigation interface shall support Zoom In and Zoom Out functionality.
Analysts shall be able to zoom into a specific section of a network, process, or activity map for detailed investigation and zoom out to obtain a broader view of the complete attack.
For example, an analyst investigating an alert involving multiple machines shall be able to focus on one affected endpoint and examine its detailed process and activity flow.
7. Complete Process Activity View
The solution shall provide an option to view all activities performed by a selected process.
This may include:
- Process creation
- File creation
- File modification
- File deletion
- Registry creation/modification
- Child process creation
- Network connections
- Download/upload activities
- Code injection activities
- Other monitored endpoint activities
This provides analysts with a complete behavioral profile of the process.
8. Parent and Child Process Investigation
The solution shall provide an option to view activities associated with both parent and child processes.
Analysts shall be able to expand the process hierarchy and investigate activities performed by the complete process tree, enabling deeper investigation of multi-stage attacks.
9. Event Type Filtering
The process and activity tree shall provide filtering based on event type, such as:
- Process
- File
- Registry
- Network
- Service
- Memory
- User activity
- Other supported event types
This shall allow analysts to focus the investigation on specific categories of activity.
10. Alert Process Default View
When an alert is opened, the solution shall provide the alerted process along with its immediate parent and child processes in the default view.
This shall allow analysts to immediately understand the process context without manually navigating through the entire process hierarchy.
11. Backward Attack Investigation
The solution shall allow analysts to trace an attack backward in time to identify its originating point.
For example:
Alerted Process → Parent Process → Parent of Parent → Initial Process → Originating Activity
The analyst shall be able to continue tracing the process and activity chain until the earliest available originating event is identified.
12. Event Colour Coding
The investigation interface shall provide colour coding for different event types to improve visual identification.
For example, different visual indicators may be used for:
- Process activities
- File activities
- Registry activities
- Network activities
- System activities
- User activities
- Alerts
The interface shall also visually highlight the alerted process and critical/interesting events to ensure that analysts can quickly identify important activities.
13. Alert Event Table
The solution shall provide an Event Table containing all events associated with the selected alert.
The event table shall provide relevant information such as:
- Event type
- Timestamp
- Process
- Action
- Source
- Target
- Status
- Severity/criticality
- Additional event details
Analysts shall be able to use this table as an alternative to the graphical investigation view.
14. Timeline-Based Attack Investigation
The solution shall provide a Timeline View displaying critical events in chronological order.
The timeline shall help analysts understand how an attack progressed over time.
For example:
10:01 — Process Started → 10:02 — File Created → 10:03 — Registry Modified → 10:04 — Network Connection → 10:05 — File Downloaded → 10:06 — Remote Machine Connection
15. Activity Type Identification in Timeline
The timeline shall provide clear visual indicators to distinguish different types of activities.
For example:
- Process creation
- File creation/modification/deletion
- Registry modification
- Network connection
- Download/upload
- Process injection
- Service activity
This shall enable analysts to understand the nature of each event without opening every event individually.
16. Timeline Activity Filtering
The solution shall provide filtering options within the timeline.
Analysts shall be able to select specific activity types and display only the required events.
For example, an analyst investigating command-and-control activity shall be able to select Network Activities Only and view only network-related events associated with the alerted process.
17. Same-Time Activity Identification
The timeline shall support scenarios where multiple activities occur at the same timestamp.
Separate activities occurring at the same or substantially similar times shall remain individually identifiable so that analysts can distinguish between concurrent activities.
18. Timeline Zoom and Time-Range Selection
The timeline shall provide Zoom In and Zoom Out functionality.
Analysts shall also be able to focus on a specific time range to investigate activities occurring during a particular period.
This shall allow analysts to move between a high-level attack overview and a detailed view of individual activities.
19. Activity Detail Investigation
Analysts shall be able to select any activity associated with an alerted process and view its detailed information.
The detailed view shall provide sufficient contextual information to understand why the activity occurred and how it relates to the alert.
20. Endpoint Response Actions
The EDR solution shall provide response actions that can be executed directly on the affected endpoint based on the nature of the detected activity.
Supported response actions shall include, where applicable:
- Kill Process
- Delete File
- Quarantine File
- Whitelist Process
- Isolate Endpoint
- Other supported remediation actions
The available actions shall vary according to the selected activity and applicable security policy.
21. Response Actions on Alerted Flow
Analysts shall be able to initiate appropriate response actions directly from the Alert/Attack Flow.
This shall allow an analyst to investigate a suspicious activity and take remediation action without navigating away from the incident investigation interface.
22. Response Action Status
After an action is executed on an endpoint, the solution shall display the response status/result to the analyst.
The response information shall indicate whether the requested action was:
- Successfully executed
- Failed
- Pending
- Not executed
- Partially completed, where applicable
This provides confirmation that the requested remediation action was received and processed by the endpoint.
23. Alert Description and Detection Conditions
The alert investigation interface shall provide a brief description of the generated alert, including the security conditions or detection criteria that triggered the alert.
This information shall help analysts understand why the activity was classified as suspicious or malicious.
24. Complete Process Activity Sequence
The solution shall provide a chronological sequence of activities performed by the process associated with an alert.
For example:
Process Started → Created File → Deleted Existing File → Modified File → Connected to Internet → Downloaded File → Connected to Another Machine → Created File on Target Machine
This complete activity sequence shall provide analysts with a detailed understanding of the process behaviour and potential attack progression.
25. Alert Activity Logs
The solution shall maintain an Activity Log for each alert to provide an audit trail of actions and changes made during the investigation.
The activity log shall record relevant alert-related activities, including:
- Alert status changes
- Assignment/assignee changes
- Criticality/severity changes
- Analyst comments
- Response actions
- Other supported investigation activities
The activity log shall provide historical visibility into how an alert was investigated and managed.
26. Read-Only Activity Logs
The Activity Log shall not provide an edit option.
Once an activity is recorded, analysts shall be able to view the historical record without modifying the recorded activity. This helps maintain the integrity and auditability of the incident investigation history.
27. Analyst-Specific Alert Activity History
The solution shall allow an analyst to view the activities associated with alerts that they are currently working on or have previously worked on.
This shall provide analysts with historical visibility into their investigation activities and enable them to review previous actions, comments, status changes, and other relevant alert events.
28. Unified Investigation Experience
The combination of Network Map, Process Tree, Attack Chain, Event Table, Timeline, Activity Details, and Response Actions shall provide a unified investigation experience.
This enables security analysts to:
Detect → Visualize → Trace → Investigate → Understand → Respond → Verify → Audit
The solution shall therefore support complete incident investigation and response from the initial alert through remediation and final audit tracking.
