Security Logging & Monitoring: SIEM Basics for Indian SMBs

Security logging and monitoring is the earliest warning system a business has against a breach. For Indian SMBs, CERT-In's Information Security Practices mandate that logs must be retained for 180 days — yet the majority of small and mid-sized organisations collect logs and never review them. That single gap — logs present, analysis absent — is OWASP's A09:2021 (Security Logging and Monitoring Failures) and it turns an incident that could be caught in hours into a breach that goes undetected for months.

If you are an Indian SMB founder or CTO asking "what should we actually be logging, and do we need a SIEM?" — this post answers that question directly.

180 daysMinimum log retention required by CERT-In (CERT-In Directions under Section 70B, April 2022)

204 daysAverage time organisations take to identify a breach, highlighting the monitoring gap (IBM Cost of a Data Breach 2024)

Why Security Logging Matters: Detection, Forensics, and Compliance

Logs are the only objective record of what happened on your systems. When a breach occurs, logs answer three questions: what was accessed, by whom, and when. Without them, forensic investigation is guesswork, insurance claims are contestable, and regulatory responses are impossible to substantiate.

Three concrete reasons Indian SMBs cannot treat logging as optional:

Detection. Attackers move laterally after initial access. Logs from authentication systems and network devices expose this movement if someone is watching. A single failed login attempt is noise. Two hundred failed attempts from one IP at 3 AM is a pattern that a monitoring tool can surface in real time.

Forensics. When CERT-In issues a direction to report an incident, the evidence requirement is specific — timeline, affected systems, indicators of compromise. Logs are that evidence. Without a 180-day retention window, you cannot reconstruct events for incidents discovered weeks after they occurred.

Compliance. CERT-In's IT Security Practices (issued under Section 70B of the IT Act, 2000) require organisations to maintain logs of user activity, admin access, system events, and network traffic — and to retain them for a minimum of 180 days. The DPDP Act 2023 compounds this: a breach of personal data that was not detected or contained because of absent monitoring is a failure to safeguard data, which carries significant regulatory exposure. See our DPDP compliance page for details.

What to Log: The Four Categories Every SMB Must Cover

Most SMBs either log everything (unmanageable noise) or nothing (compliance failure). The practical starting point is four categories:

Category	What to Capture	Why It Matters
Authentication events	Login success/failure, MFA bypass, password resets, session creation/termination	Credential attacks, account takeover, insider access
Administrative actions	User creation/deletion, permission changes, config modifications, sudo/elevated access	Privilege escalation, insider threat, misconfiguration
Network events	Firewall allow/deny, DNS queries, VPN connections, outbound traffic to unusual destinations	Lateral movement, C2 communication, data exfiltration
Application events	API calls, database queries with admin parameters, file access in sensitive directories, error spikes	Injection attacks, data scraping, application-layer exploits

⚠️

WARNING

Logging authentication events without logging failed attempts is a common mistake. Successful logins from unexpected locations and times are equally important — an attacker using stolen credentials will generate successful logins, not failed ones.

The Gap Most SMBs Have: Logs Collected, Never Reviewed

OWASP A09:2021 — Security Logging and Monitoring Failures — is not about absent logs. It is about logs that exist but are never acted on. This is the most common posture in Indian SMBs: a firewall writes logs to a file on a local server, the server fills up, logs rotate, and no human has read any of them in six months.

Three failure modes that make collected logs useless:

No centralisation. Logs sit on each device — firewall on one box, web server on another, Active Directory on a third. There is no single view. Correlating an attack that touches all three requires manually pulling and comparing files after the fact.

No alerting. Even centralised logs require someone to review them. Without automated rules that trigger alerts on specific patterns, logs are post-breach evidence at best.

No retention discipline. Logs that auto-rotate off a local disk after 7 days satisfy no one — not CERT-In, not your cyber insurer, not a forensic investigator.

🚨

DANGER

If your current logging setup means you would only discover a breach when a customer or third party reports it to you — rather than from your own monitoring — you have an A09 gap. This is the scenario CERT-In directions are designed to address.

Know your vulnerabilities before attackers do

Run a free VAPT scan — takes 5 minutes, no signup required.

Book Your Free Scan

What a SIEM Does

A Security Information and Event Management (SIEM) platform solves the centralisation and correlation problem. It ingests logs from multiple sources — firewalls, servers, endpoints, cloud services, applications — and applies detection rules to surface actionable alerts.

The log flow from source to response looks like this:

graph TD
    A[Firewall Logs] --> E[Log Aggregation Layer]
    B[Auth and AD Logs] --> E
    C[Web and App Server Logs] --> E
    D[Endpoint EDR Logs] --> E
    E --> F[SIEM Correlation Engine]
    F --> G{Alert Triggered?}
    G -->|No| H[Stored for 180 days]
    G -->|Yes| I[Security Alert]
    I --> J[Analyst Review]
    J --> K{True Positive?}
    K -->|No| L[Tuned as False Positive]
    K -->|Yes| M[Incident Response]
    M --> N[CERT-In Reporting if required]

    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style D fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style F fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style G fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style H fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style I fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style J fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style K fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style L fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style M fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style N fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0

A SIEM does three things a raw log file cannot:

Correlation: It links an event on the firewall to a login on the server to a database query — all within a time window — and treats the sequence as a single story rather than isolated events.
Alerting: It fires a notification when a pattern matches a detection rule, without requiring a human to sift through log files.
Retention with search: It stores logs in a searchable index, so a forensic query like "show me all admin logins from outside India in the last 90 days" returns results in seconds rather than hours.

SIEM vs Log Management vs SOC: Knowing What You Are Buying

These three terms are often conflated in vendor conversations. They are distinct:

Tool or Service	What It Does	Requires Active Analysis?
Log management	Collects, stores, and makes logs searchable. No detection logic.	Yes — humans must query
SIEM	Log management plus correlation rules and alerting. Generates alerts automatically.	Yes — analysts review alerts
SOC (Managed)	A team of analysts who operate a SIEM on your behalf, triage alerts, and escalate incidents.	No — handled by provider

For most Indian SMBs, the decision is between deploying an open-source SIEM in-house (lower cost, higher operational burden) or subscribing to a managed SIEM or managed SOC service (higher cost, lower burden). A log management tool alone — storing logs without any detection — satisfies the CERT-In retention requirement but does not satisfy the monitoring requirement.

Open-Source vs Managed SIEM: A Practical Comparison

pie title "SIEM Deployment Preference — SMB Segment"
    "Managed SIEM or SOC" : 52
    "Open-source self-hosted" : 28
    "Cloud-native SIEM" : 14
    "No SIEM deployed" : 6

ℹ️

INFO

The pie chart above is an illustrative breakdown based on analyst estimates for the Indian SMB segment. The "no SIEM deployed" segment is likely understated in practice, as many SMBs classify basic syslog collection as active monitoring.

Open-source options worth evaluating for Indian SMBs:

Wazuh — open-source SIEM and XDR with agents for Linux, Windows, and macOS. Strong community, integrates with Elastic Stack. Suitable for SMBs with in-house Linux skills.
OpenSearch with Wazuh — the combination most commonly deployed by managed service providers in India for cost-conscious clients.
Graylog — log management platform with alerting add-ons; lower detection capability than Wazuh but simpler to operate for smaller teams.

Managed SIEM/SOC considerations for Indian SMBs:

Managed services offload the operational burden — log ingestion setup, rule tuning, alert triage — to a provider. When evaluating managed options, ask specifically: whether the provider retains logs in India (data residency), whether their retention policy meets CERT-In's 180-day floor, and whether they can produce incident timelines in a format suitable for CERT-In reporting. If a CERT-In-empanelled VAPT report is required alongside your monitoring posture (for SEBI CSCRF, RBI, or sectoral compliance), that assessment is delivered with a CERT-In empanelled partner — Dhisattva AI Pvt Ltd's platform, Bachao.AI, connects clients to those engagements.

💡

TIP

Start with Wazuh on a single VM if you have a part-time Linux administrator. Point your firewall, web server, and Active Directory at it. Configure three detection rules: brute-force authentication, admin account usage outside business hours, and outbound connections to non-whitelisted countries. That is a working monitoring baseline in under a day.

A Practical Starting Point for Indian SMBs

Most organisations overthink the start. A working logging and monitoring baseline for an Indian SMB with 20–200 users requires five steps:

Identify your log sources. List every device that generates security-relevant logs: firewall, VPN gateway, Windows AD or Entra ID, web server, cloud provider (AWS CloudTrail / GCP Cloud Audit Logs / Azure Monitor), and your primary SaaS tools if they support SIEM integration.

Centralise before you analyse. Deploy a syslog server or SIEM agent on each source. Aggregate to one place. This alone closes the single biggest gap — fragmented, unreachable logs.

Set retention to 180 days minimum. Configure log storage so that rotation does not happen before 180 days. Back up to object storage (S3 or equivalent) to survive local hardware failure.

Write three detection rules first. Brute-force authentication (50+ failed logins in 10 minutes), privileged account login outside business hours, and outbound traffic to a known-malicious IP list. These three rules catch the majority of opportunistic attacks.

Book a VAPT scan to validate your attack surface. Monitoring tells you what is happening inside. A free VAPT scan tells you what vulnerabilities attackers can exploit before they reach the logs. Both are required — monitoring without knowing your attack surface is incomplete.

🎯Key Takeaway

CERT-In requires 180-day log retention. Retaining logs without reviewing them is OWASP A09 — the gap that turns a detectable intrusion into a months-long breach. For Indian SMBs, the practical path is centralised log collection into an open-source SIEM like Wazuh, 180-day retention to object storage, and three high-signal detection rules. That baseline satisfies CERT-In, creates a forensic trail for the DPDP Act, and surfaces real attacks without requiring a dedicated security team.

Sources

CERT-In, Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 — April 28, 2022 — https://www.cert-in.org.in
IBM Security, Cost of a Data Breach Report 2024 — https://www.ibm.com/reports/data-breach
Verizon, 2024 Data Breach Investigations Report — https://www.verizon.com/business/resources/reports/dbir/
OWASP, A09:2021 – Security Logging and Monitoring Failures — https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/

Frequently Asked Questions

What is the CERT-In log retention requirement for Indian companies?

CERT-In's IT Security Practices (reinforced by the 2022 directions under Section 70B of the IT Act) require organisations to retain logs of ICT systems for a minimum of 180 days. This applies to user activity logs, system event logs, network access logs, and administrator action logs. Logs must be available for audit and incident response.

What is OWASP A09 and why does it matter for SMBs?

OWASP A09:2021 — Security Logging and Monitoring Failures — covers cases where logging is insufficient, logs are never reviewed, or monitoring is absent. It matters for SMBs because it is not a vulnerability in code; it is an operational gap. An attacker who has already gained access will continue operating undetected if no one is reviewing logs. Most Indian SMBs fall into A09 not because they have no logs, but because no one is watching.

Do I need a SIEM or is a log management tool enough?

A log management tool satisfies the CERT-In retention requirement but not the monitoring requirement. A SIEM adds correlation rules and alerting, meaning it tells you when something suspicious is happening rather than simply storing the evidence for later. For SMBs with limited staff, a managed SIEM or managed SOC is often more practical than a self-hosted open-source SIEM.

What is the difference between a SIEM and a SOC?

A SIEM is software — it aggregates logs and generates alerts based on detection rules. A SOC (Security Operations Centre) is a team of analysts who operate a SIEM and respond to its alerts. A managed SOC subscription gives you both the tooling and the human analysis, which is why it costs more but requires less internal resource than running a SIEM yourself.

What logs should an Indian SMB start collecting first?

Start with four categories: authentication events (logins, failures, password resets), administrative actions (user and permission changes), network events (firewall allow/deny, DNS queries), and application events (API calls, error spikes). These cover the most common attack paths — credential attacks, privilege escalation, lateral movement, and web application exploitation — without requiring you to collect everything.

Is open-source SIEM viable for an SMB without a dedicated security team?

Yes, with realistic expectations. Wazuh deployed on a single VM, pointed at your firewall and authentication systems, with three to five detection rules configured, is a functional monitoring baseline. The operational burden is agent maintenance, rule tuning, and alert triage — approximately two to four hours per week for a part-time Linux administrator. The alternative is a managed SIEM service, which removes that burden at a higher cost.

Security Logging & Monitoring: SIEM Basics for Indian SMBs

Get cybersecurity insights for Indian SMBs

Exposed to CVEs like this? Run a free VAPT scan — risk score in 2 hours, no credit card.