SCNET · Enterprise IT · Ankara, Türkiye

Sanal Çekirdek

The attack you want to see determines the logs you collect.

Security operations are measured by the real incidents closed, not by the alerts on screen. Sanal Çekirdek builds to that measure: which sources are collected, which rules are written, which incident reaches whom.

Collecting everything is the most expensive way to see nothing. Source selection determines detection quality directly.

Source selection and data discipline

Every log collected is both cost and noise. Sources are chosen by which detection scenario they feed; a source serving no scenario is not collected. Identity, endpoint and network layers usually take the first three places.

  • Every source maps to at least one detection scenario
  • Clock sync and time zones are fixed at the start
  • Retention follows what the scenarios require
  • Removing a source is planned as deliberately as adding one

Detection rules and tuning

Out-of-the-box rule sets are a starting point, not a destination. Rules are tuned to your own behavior; a rule with high false positives gets narrowed rather than switched off. Every rule carries an owner and a response step.

  • No rule goes live before its response step exists
  • False-positive rate is tracked per rule
  • Rules are retuned as organizational behavior changes
  • Any disabled rule is recorded with its reason

Incident flow and escalation

How an alert becomes an incident and reaches the right person is defined as a flow. Who triages, when it escalates, at what threshold your own team steps in — all written before the incident. A flow learned during a crisis is not a flow.

  • Escalation is defined by role, never by person
  • The threshold for involving your team is written down
  • Closure requires a verification step
  • Every incident ends with an outcome record

Measurement and improvement

The operation itself is measured: how many alerts arrived, how many became incidents, how many were real, how long closure took. Those four numbers show whether the setup is working.

  • A low true-incident rate means the rules need tuning
  • Recurring incidents are routed to permanent fixes
  • Blind spots are compared against scenario coverage
  • Measures use the same definition across periods

How we work

  1. Define detection scenarios and sources
  2. Establish collection and retention discipline
  3. Tune rules against your own behavior
  4. Write the incident flow and escalation
  5. Measure the four indicators and improve the rules

How success is measured

  • Every detection rule has an owner and a response step
  • The true-incident rate rises across periods
  • Recurring incidents close through permanent fixes
  • The blind-spot list keeps shrinking

Frequently asked questions

Should we build our own SOC or buy the service?

Incident volume and team continuity decide. An in-house build gives context but demands shift coverage; buying solves continuity but requires that context be transferred deliberately.

Which sources should we collect?

Work backwards from the scenario. Whatever log the sentence 'I want to see this attack' requires is what gets collected; a source with no scenario produces nothing but cost and noise.

How do false positives come down?

By narrowing rules, not disabling them. As normal behavior becomes known, a rule gains context; a disabled rule leaves an attack surface nobody is watching.

Tell us which attack scenarios you want to see; we will work out which sources that needs and how the rules should be built.

Discuss your detection scenarios