Start from threats and past incidents
Use cases come from your threat model, your incident history and the systems that matter most. No threat model yet? Threat modeling for your most important system is a sound place to begin.
Threat detection support and SOC readiness
Spot an attack in the logs you already collect — and be ready to act.
We check which logs you collect and keep, write detections (rules that raise an alert when your logs show something suspicious) for your own risks, and tune alerts so the real ones get read. Then we prepare the people and runbooks (written first-response steps) that act on them. Your own team, or a provider you choose, handles the alerts: we help you build or choose a security operations center (SOC), but we don't operate one.
- Coverage measured against your own assets
- Detections proven with harmless test events
- Every tuning change on record
In brief
- What it is
- Four linked pieces of work: log source coverage, detection use cases (each alert rule with its trigger and owner), alert tuning and SOC readiness. The aim is that an intrusion would show up in your logs and reach someone ready to act.
- Why it matters
- Detections are only as good as the logs under them. An alert only matters if someone is ready to act on it.
- What you get
- Three documents your team keeps: a detection coverage map, a use-case catalog with its tuning log, and a SOC readiness plan.
Log analysis
Start with the logs you actually collect.
We measure coverage against your own assets (the systems and data you rely on), not against the list of tools a security product can connect to. Each important asset is matched to the logs it produces and where those logs end up, such as a SIEM (security information and event management) tool. Typical sources: the identity provider (the system your staff sign in through), endpoints (laptops, desktops and phones), servers, network devices, cloud control-plane activity (who did what in your cloud accounts, such as sign-ins and changes to resources or permissions), SaaS (software-as-a-service) admin consoles and the applications that hold sensitive data. If there is no asset list, building one is the first task.
Then we check presence and quality. Is the event recorded? Does it carry the user, the source and the time? Can someone search it when it matters? We also check how long logs are kept and whether system clocks agree, because an investigation needs both. In India, the CERT-In (Indian Computer Emergency Response Team) Directions set rules for both; the details are below.
Gaps ranked by what they would hide
A missing sign-in log on an internet-facing system hides more than a missing debug log on an internal tool, so it is closed first. Some gaps are settings rather than missing tools. Here is where each kind of gap is usually closed:
- Logging settings. Logging configuration is part of a security configuration review.
- Cloud audit logging. One of the settings a cloud security review reads.
- What an application logs. Best settled at design time or in secure code review.
Systems that can't be patched yet need closer watching in the meantime, which is where detection and risk-based patch prioritization meet.
Log retention and clock synchronization under CERT-In's Directions
We check retention periods against what an investigation needs and what your regulators and contracts require.
In India, the CERT-In (Indian Computer Emergency Response Team) Directions of 28 April 2022 ask covered entities to keep ICT (information and communication technology) system logs securely for a rolling 180 days within Indian jurisdiction. They also ask them to synchronize system clocks to the NTP (network time protocol) servers of the National Informatics Centre or the National Physical Laboratory, or to servers traceable to them.
Logs from clocks that drift are hard to line up when an investigation needs a timeline.
Detection use cases and alert tuning
Detections built from your own risks, and alerts that get read.
We start from what could hurt your organization, not from the rules a product ships with. Then we tune the alerts so they are few enough to be read and specific enough to act on: an alert nobody reads is worse than no alert, because it looks like coverage.
A trigger, a severity and an owner
Each use case states what triggers it, how severe it is, who receives it and what they do first. A detection without a named recipient is a log entry, not an alert.
Proven with harmless test events
We validate detections with benign test events or replayed log samples, so you know the alert fires and reaches a person. Blue Team detection validation exercises run the same checks with your responders taking part.
Measure the noise
We review alert volume and false positives (alerts that fire when nothing is wrong) with the people who receive them. Which alerts do they close without reading, and why?
Tune with a record
Thresholds and suppressions (the rules that decide when an alert fires or stays silent) change with a written reason, an owner and a review date, so tuning never silently hides a threat. The tuning log stays with your team.
Escalation that reaches someone
We check escalation paths end to end, including outside working hours where your plan requires cover. A test alert that lands in an inbox nobody watches is a finding.
| Field | What it records | Example |
|---|---|---|
| Trigger | The event or pattern that raises the alert | An administrator sign-in without multi-factor authentication |
| Log source | The log it depends on, and where that log is kept | Identity provider sign-in logs |
| Severity | How urgent it is, set against your own risk ranking | High |
| Owner | The person or role who receives it | The on-call IT operations lead |
| First step | What the owner does first | Confirm the sign-in with the account holder, and end the session if it is not confirmed |
| Last validated | How and when the detection was last shown to fire | A replayed log sample, with the date recorded |
SOC readiness
Get your team, or your provider, ready to act.
A SOC readiness assessment asks whether a security operations capability could work with what you have today, and what it would need. It doesn't assume a large team or a particular product.
Roles and hours of cover you decide
We help you define who watches, who triages (sorts alerts by urgency) and who decides, for the hours of cover your risk and budget support. Cover outside working hours is a decision with a cost, and the plan should say what happens when nobody is watching.
Runbooks for the first response
Runbooks set out the first steps for each detection, so the response doesn't depend on one person's memory.
Build, buy or combine
Build your own security operations capability, buy one from a provider, or combine both. We set out what each option would need, starting from what you have today, so you can choose.
Hand-off to incident response
Detection ends where incident response begins. Each high-severity detection gets a written hand-off to your incident response plan: who declares an incident, and on what criteria. Our incident response readiness work builds that plan if you don't have one.
Evidence and reporting
Runbooks say which logs and other evidence to preserve before containment (the steps that stop an attack spreading) changes them: what to copy, where to store it and who may touch it. They also hold the reporting paths to regulators such as CERT-In, customers and insurers. CERT-In's Directions require listed incidents to be reported within six hours of noticing them, which leaves no time to look up who to call.
AI systems
Bring your AI features into your detection plan.
An AI feature adds log sources, and behavior worth watching, that many detection plans don't cover yet.
Logging model and agent activity
AI features should log prompts, tool calls (actions the AI takes in your other systems) and retrieval access (which documents the AI looked up) in a way that respects personal data rules: enough to reconstruct what happened, without copying sensitive content where it doesn't belong. We agree what to record, what to mask and how long to keep it.
Signals worth alerting on
Useful alerts include unusual tool use by an agent, repeated guardrail blocks (requests your AI safety filters refused) for one user, and access to sensitive retrieval sources outside normal patterns. Guardrail design and AI posture reviews (how securely your AI features are set up) are covered by our AI security services.
What this work does not include. SecWiz does not operate a security operations center. We help you prepare, build or choose one, and your team or the provider you choose runs it. For ongoing help with monitoring set-up, governance and reporting after this work, see our managed security and compliance services.
Threat detection support is one part of our defensive cybersecurity services.
FAQ
Questions about threat detection support.
Who runs the SOC, which logs matter and how detections are tested. For anything else, ask us directly.
No. SecWiz does not operate a SOC. We help your team prepare, build or choose one: log coverage, detection use cases, alert tuning, runbooks and the roles that will act on alerts.
The state in which a security operations capability can actually work: the right logs are collected, detections exist for your main risks, alerts reach a named person, and runbooks say what to do first.
Usually identity and authentication, internet-facing systems, endpoints, cloud control-plane activity and the systems that hold your most sensitive data. The right list comes from your own assets and risks.
With benign test events and replayed log samples that match what the detection looks for. The goal is to prove the alert fires and reaches a person, not to break anything.
No. The work starts with which logs you collect and which incidents you need to see. That tells you whether your current tooling is enough or what to add.
Let's talk
Send the list of log sources you collect today.
Or tell us you're not sure. We'll map the gaps against the incidents you most need to see. We reply within one working day.