The Situation
The organisation was a large private equity group with a central security operations function supporting hundreds of portfolio companies across the United States and Europe. The portfolio included manufacturers, healthcare suppliers, professional services firms, logistics businesses, and software companies. Each company had its own history, geography, identity environment, cloud footprint, and endpoint estate.
SentinelOne provided the common endpoint detection layer. The model was sensible: give portfolio companies a shared EDR baseline, centralise monitoring, and use the SOC to identify serious threats before they became business interruptions. In practice, the operating burden was far heavier than expected.
The SOC was triaging roughly 1,600 endpoint alerts every week. Alert volumes varied by portfolio company and by region. Some businesses had mature IT teams and clean endpoint hygiene. Others had legacy servers, local administrators, unmanaged remote access tools, and incomplete documentation. Every alert arrived with context, but not enough truth.
Analysts were forced into the pattern familiar to many SOCs: triage quickly, suppress noise, and cherry-pick the alerts that looked most likely to justify deeper investigation. That meant investigative effort was being allocated by analyst intuition, available time, and how obvious the alert appeared in the console. Lower-confidence alerts were frequently closed without forensic collection because there simply were not enough hours in the week.
The cost of that model became visible after a ransomware incident at one portfolio company. SentinelOne had generated detections during the intrusion, but the early alerts did not look exceptional when viewed in isolation. By the time the activity was fully investigated, the threat actor had already moved laterally, staged tooling, and deployed ransomware. Their dwell time was shorter than the SOC's mean time to investigate.
The Challenge
The SOC did not have a detection problem. SentinelOne was raising alerts. The gap was what happened next. Each meaningful investigation still required evidence collection, endpoint artifact review, command-line reconstruction, lateral movement analysis, persistence checks, and a decision about whether the activity was isolated or part of a wider intrusion.
Manual enrichment did not scale across hundreds of companies. A single suspicious script alert could require an analyst to collect files, review process lineage, check scheduled tasks, inspect browser downloads, confirm network connections, and decide whether credentials or data had been exposed. Multiply that by 1,600 weekly alerts and the team had no realistic path to full investigative coverage.
The SOC's best analysts were spending too much time on repetitive evidence gathering and too little time making decisions. Junior analysts were under pressure to close alerts quickly. Escalations were inconsistent. Burnout and churn increased because the work felt both high-stakes and incomplete: analysts knew important things might be missed, even when they were working hard.
The private equity leadership team needed confidence at portfolio scale. They did not just need another alert queue. They needed a way to know, across the portfolio, whether a detection represented benign activity, commodity malware, hands-on-keyboard intrusion, precursor ransomware activity, or a threat that required immediate containment.
The Investigation
Strand was deployed as the automated forensic layer behind SentinelOne. The integration took one day. The SOC provided API access, mapped portfolio companies to Strand workspaces, and enabled an automation policy: when SentinelOne raised qualifying endpoint detections, Strand would deploy its forensic collector, acquire the relevant artifacts, reconstruct what happened, and return an investigation summary rather than another alert record.
SentinelOne remained the detection layer
The team did not replace their EDR or redesign the SOC. SentinelOne continued to detect suspicious endpoint activity across the portfolio. Strand started at the point of escalation: the moment an alert needed to be understood rather than merely acknowledged.
The integration used scoped SentinelOne API credentials per management scope. Strand pulled alert metadata, endpoint identity, process lineage, severity, file hashes, command lines, and tenant context. For alerts that matched the SOC's policy, Strand automatically initiated forensic collection from the affected endpoint and created an investigation record tied back to the original SentinelOne alert.
Every alert received the same forensic baseline
Before Strand, deeper investigation depended on analyst availability. After Strand, every qualifying alert received a consistent forensic baseline: process execution, persistence locations, recently downloaded files, suspicious archives, script contents, browser artifacts, scheduled tasks, services, network connections, user context, and nearby security-relevant events.
The Strand collector acquired targeted endpoint artifacts rather than full disk images. Collection typically focused on event logs, SRUM, Prefetch, AmCache, ShimCache, scheduled tasks, services, Run keys, browser downloads, PowerShell history, recent files, suspicious binaries, and network artifacts. This gave analysts the evidence they would normally gather manually, without waiting for remote triage.
Alerts became investigation outcomes
The SOC stopped receiving only "here is an alert." They started receiving "here is what happened, and why it happened." Strand performed root cause analysis on each case, separating alerts caused by a user downloading and executing a suspicious file from alerts that followed hands-on-keyboard activity, such as an RDP connection from a VPN IP pool before tool execution.
Investigation summaries included a defensible narrative, evidence citations, affected hosts, user accounts, suspicious command lines, file paths, hashes, persistence checks, MITRE-aligned technique labels, and recommended next steps. Root cause explanations were tied to the preceding evidence chain: browser download and archive extraction, removable media execution, remote logon and RDP source, parent process lineage, scheduled task creation, or lateral movement from another host. Analysts could open the underlying artifacts when they needed to validate a conclusion or escalate to incident response.
Ransomware precursor activity was no longer hidden in the queue
The previous ransomware incident had shown the danger of alert-by-alert review. Strand changed the operating model by connecting related activity across time. A suspicious script, credential dumping indicator, remote access tool installation, and file staging behavior could be analysed together even when the initial alert looked routine.
Strand correlated SentinelOne detections with endpoint artifacts and temporal proximity. A suspicious scheduled task could be linked to a downloaded ZIP file, extracted script, subsequent PowerShell execution, new service creation, remote access tooling, and outbound connections. This moved analysts from isolated alert disposition to attack-path reconstruction.
The SOC changed from cherry-picking to exception handling
Analysts no longer needed to manually investigate only the alerts that looked most severe. Strand performed the first forensic pass automatically, allowing analysts to focus on exceptions: confirmed malicious activity, ambiguous findings, containment decisions, and communication with portfolio companies.
The triage workflow shifted from manual enrichment to review of Strand outputs. Benign or explainable activity could be closed with evidence. Suspicious activity arrived with root cause, scope, and recommended containment steps. Confirmed incidents were promoted into investigation workflows with artifacts already attached.
Portfolio visibility improved without standardising every company first
The organisation did not need every portfolio company to have the same SIEM, ticketing system, identity architecture, or cloud logging maturity. SentinelOne detections provided the trigger, and Strand's collector provided the evidence layer required to investigate consistently across varied environments.
Portfolio companies were grouped by tenant, geography, and operating company. Strand maintained separation of investigation data while giving the central SOC a consistent view of alert outcomes, affected endpoints, evidence collected, containment status, and open escalations.
Deployment Timeline
Operating model agreed
- ›SOC identified which SentinelOne detections should trigger Strand
- ›Portfolio companies mapped to investigation workspaces
Alert policy and tenant mapping defined
SentinelOne integration live
- ›Scoped API credentials connected
- ›Alert ingestion tested against historical detections
SentinelOne API integration completed in one business day
Automatic forensic collection enabled
- ›Strand collector deployed on qualifying endpoint alerts
- ›Evidence collection initiated without analyst handoff
Targeted artifact collection policy enabled
First 300 alerts investigated
- ›Analysts reviewed investigation outcomes instead of manually collecting evidence
- ›Benign, suspicious, and confirmed malicious activity separated with evidence
Initial automation window across priority portfolio companies
Portfolio rollout completed
- ›Coverage expanded across US and European portfolio companies
- ›SOC queue shifted from manual triage to exception review
Investigation coverage normalised across different tech stacks
Operating metrics stabilised
- ›100% of qualifying SentinelOne alerts received a forensic investigation
- ›Analyst time shifted toward containment and communication
Central reporting showed root cause, scope, and investigation status by portfolio company
Before and After
Before Strand
- SentinelOne generated endpoint detections across the portfolio
- Only a subset of alerts received deeper forensic investigation
- Analysts manually collected artifacts and reconstructed process activity
- Early ransomware precursor activity could be missed in alert volume
- SOC burnout increased because triage felt fast but incomplete
After Strand
- SentinelOne detections automatically triggered Strand investigations
- 100% of qualifying alerts received a consistent forensic baseline
- Analysts received root cause, scope, persistence checks, and next steps
- Ransomware precursor activity was correlated into attack-path context
- SOC effort moved from manual evidence gathering to decision-making
Integration and Automation Model
- •SentinelOne remained the source of endpoint detection and alert generation
- •Strand connected using scoped SentinelOne API credentials and portfolio-company mappings
- •Qualifying alerts triggered targeted Strand forensic collection from the affected endpoint
- •Collected artifacts included process lineage, persistence locations, script contents, recent downloads, event logs, SRUM, Prefetch, AmCache, ShimCache, services, scheduled tasks, and suspicious binaries
- •Investigation records linked back to the original SentinelOne alert for auditability
- •SOC analysts reviewed Strand outputs: root cause, affected host, user context, scope, containment recommendations, and evidence citations
- •Confirmed or ambiguous cases were escalated to incident response with evidence already attached
- •Portfolio reporting separated operating companies while giving the central SOC portfolio-wide visibility
Key Takeaways
- 1Detection and investigation are different problems. EDR can identify suspicious behavior, but responders still need evidence-backed answers about origin, scope, persistence, lateral movement, and impact.
- 2A central SOC supporting many portfolio companies cannot rely on manual alert enrichment. Different tech stacks, geographies, and maturity levels make consistent investigation coverage impossible without automation.
- 3Cherry-picking alerts is a rational response to overload, but it creates systemic risk. The alerts that look ordinary in isolation may become serious when connected to nearby forensic evidence.
- 4Ransomware dwell time can be shorter than the mean time to investigate. The first forensic pass must happen immediately after detection, not after an analyst has spare capacity.
- 5The strongest operating model kept SentinelOne as the detection layer and used Strand as the automated DFIR layer. The SOC did not need another alert queue; it needed answers.
- 6Automating forensic collection reduced analyst burnout because analysts spent less time gathering repetitive evidence and more time making decisions, escalating true incidents, and helping portfolio companies recover.