SOC / SOC-04
Detection engineering and rule improvement
Design and maintain detection rules tied to customer risks, with testing and investigation procedures. The aim is useful, explainable alerts rather than an uncontrolled catalogue of enabled rules.
WHEN IT HELPS
A focused response
to a defined need.
Excessive false positives, known blind spots, changing threats or a need to verify that claimed controls actually produce actionable alerts.
SCOPE & OUTCOMES
What the engagement covers.
Scope
- Priority scenarios
- data availability
- queries and correlations
- enrichment
- testing
- analyst documentation
- exceptions
- versioning
- maintenance through changes
Deliverables
- Detection specifications
- versioned rules
- test cases
- investigation playbooks
- coverage map
- backlog
- quality metrics and operational feedback
Acceptance evidence
Each priority rule has a test, owner and procedure; expected results are observed; false positives are documented; coverage limitations are explicit.
DELIVERY
How the work is structured.
Approach
Scope service and roles; connect and validate data; test scenarios; start operations; measure and improve.
Prerequisites & responsibilities
Customer: assets, logs, contacts and response authority. Provider: collection/analysis as contracted. Business decisions and recovery are explicitly allocated.
Scope factors
Assets, sources, events, volume, retention, integrations, hours and response level. Separate onboarding, licenses, consumption and recurring service.
Questions to clarify
Which business scenarios matter most? Does required data exist? How are alert relevance and analysis effort measured?
IMPORTANT BOUNDARIES
A MITRE ATT&CK mapping does not prove exhaustive detection. Collection quality, behavioural variations and version changes must be considered.
Hours and response times only after contractual approval. No guaranteed detection rate or resolution; collection gaps and failed sources remain visible in reporting.
IN PRACTICE
Illustrative situations.
These examples describe possible engagements and target outcomes. They are not customer references or achieved results.
Scenario 01
A SOC receives thousands of sign-in alerts. Project: add context, privileges and legitimate exceptions. Target outcome: better-targeted alerts, measuring noise before and after instead of inventing a reduction figure.
Scenario 02
A company wants to detect sensitive permission changes. Project: define events and tests with administrators. Target outcome: test changes are detected; applications lacking adequate logs are recorded as technical gaps.
Technology and reference context
References: MITRE ATT&CK; search, correlation and testing capabilities of the selected SIEM/EDR.
The final technology set is agreed during scoping, based on interoperability, licensing, access rights and operating requirements.
CONNECTED SERVICES
Build the next step.
These services can complement the engagement. They are not automatically included.
START A CONVERSATION
Make the scope clear.
We will clarify the objective, dependencies and responsibilities of this service before proposing delivery.