Building a High-Capability SIEM on a Cost-Optimised Architecture

Digital banking has fundamentally changed the technology environment of financial institutions.

UPI, mobile banking, API ecosystems, internet-facing applications, cloud infrastructure, distributed databases, payment systems and third-party integrations have created an operating environment in which thousands — and sometimes millions — of security-relevant events can be generated every day.

The challenge is no longer simply collecting those events.

The challenge is determining which events matter, how quickly they need to be investigated, how long they must be retained, and how the organisation can demonstrate that its monitoring and response capabilities are actually working.

This is where Security Information and Event Management (SIEM) becomes an important part of a modern cybersecurity architecture.

For banks and other financial organisations, however, SIEM implementation presents a practical problem: security visibility can become expensive when every available log is treated as equally important.

A better approach is to design the architecture around risk.

That means collecting the right telemetry, filtering unnecessary noise, prioritising high-value events, separating operational retention from real-time analytics, automating repetitive response activities and maintaining an evidence trail suitable for security investigations and applicable regulatory requirements.

Sidigiqor Technologies works with organisations on cybersecurity, IT infrastructure, network security, firewall management, VAPT, managed IT services and security monitoring architectures, helping businesses design technology environments that balance security capability, operational practicality and cost efficiency.

Why SIEM Matters in Modern Banking

A SIEM platform brings security data from multiple sources into a central environment where events can be collected, normalised, correlated, searched and investigated.

The value of SIEM does not come from the number of logs stored.

It comes from the ability to connect events that might appear insignificant individually but become meaningful when viewed together.

Consider a simplified example.

A failed login occurs.

Then another.

Then another.

A privileged account is accessed from an unusual location.

A new administrator account is created.

A firewall rule is modified.

An endpoint begins communicating with a suspicious external destination.

Individually, these events may look unrelated.

Correlated together, they could indicate a compromised privileged account.

That is the fundamental purpose of SIEM:

turning fragmented security telemetry into actionable security intelligence.

For financial institutions, this capability becomes particularly important because modern banking environments combine customer-facing applications, payment infrastructure, identity systems, databases, network infrastructure and third-party services.

RBI’s IT Governance, Risk, Controls and Assurance Practices Directions establish a broader governance and security framework covering IT services management, access controls, IT and information-security risk management, cyber incident response and recovery, business continuity and disaster recovery.

The Problem With Sending Everything to the SIEM

A common mistake during SIEM implementation is to adopt the philosophy:

“If we can collect the log, we should send it to the SIEM.”

Technically, this may be possible.

Operationally and financially, it can be a poor architecture.

Modern environments generate enormous quantities of routine telemetry:

• Firewall connection logs
• System health messages
• Application debug events
• Authentication events
• DNS queries
• Network flows
• Endpoint telemetry
• Cloud activity
• Database logs
• API transactions
• Operating-system events
• Application traces

Not every event requires immediate correlation by a security analyst.

If low-value, repetitive events are pushed indiscriminately into an expensive analytics platform, organisations can face:

• Higher ingestion costs
• Greater storage requirements
• Increased indexing requirements
• More complex searches
• Alert fatigue
• Increased infrastructure requirements
• Reduced analyst efficiency

The answer is not to collect less security information.

The answer is to architect the information flow intelligently.

A Risk-Based SIEM Architecture

A cost-optimised SIEM architecture should distinguish between different categories of security data.

One practical model is:

Collect → Filter → Classify → Correlate → Investigate → Archive

The architecture can then separate high-value security telemetry from large-volume historical data.

High-Value Security Events

These may include:

• Privileged-account activity
• Authentication failures
• Successful privileged authentication
• Multiple failed logins followed by success
• Firewall policy changes
• Security-policy violations
• Malware detections
• Endpoint isolation events
• Suspicious process execution
• Administrative changes
• Unusual API activity
• Critical application events
• Data-access anomalies
• Indicators of compromise

These events are candidates for real-time monitoring and correlation.

High-Volume Operational Data

Other logs may have significant forensic or operational value but do not necessarily require the same real-time processing treatment.

Examples may include:

• Routine system status messages
• Repetitive network telemetry
• Debug-level application logs
• Low-value informational events
• High-volume operational records

These can be routed into appropriately designed lower-cost storage or archival systems, subject to the organisation’s retention, regulatory, security and investigation requirements.

The objective is to avoid paying premium analytics costs for data that does not require premium processing.

Intelligent Log Collection at the Edge

The first optimisation opportunity exists before data reaches the central SIEM.

Organisations can deploy appropriate log collectors, forwarders or processing layers close to the source.

Technologies such as Fluent Bit, Logstash and other telemetry pipelines can help organisations parse, enrich, filter and route data before it reaches the central analytics layer.

This architecture can support:

• Log normalisation
• Duplicate reduction
• Event enrichment
• Source tagging
• Severity classification
• Routing
• Filtering
• Compression
• Secure forwarding

The important principle is that filtering should never be based simply on reducing volume.

A security event should be excluded only when the organisation has established that doing so does not create an unacceptable detection, investigation, forensic or compliance risk.

Cost optimisation should never become visibility optimisation in reverse.

Hot, Warm and Cold Data: A More Practical Retention Strategy

Not all security data needs to live in the same storage tier.

A mature architecture can use different tiers according to operational value.

Hot Data

High-value and recent security events remain immediately searchable for active threat detection and investigation.

This layer supports:

• Real-time correlation
• Alerting
• Threat hunting
• Incident investigation
• Security dashboards

Warm Data

Recent historical data can remain accessible but may not require the same performance characteristics as the active investigation layer.

Cold or Archive Data

Older data can be compressed and stored in cost-efficient storage while remaining available for investigation, audit or applicable retention requirements.

Object-storage technologies can be considered for this purpose, subject to the institution’s security architecture and regulatory requirements.

The key principle is:

Retention does not necessarily mean keeping every event inside the expensive SIEM index.

Open-Source Security Platforms Can Change the Economics

Enterprise SIEM products can provide powerful capabilities, but licensing models vary considerably.

Depending on the product, cost can be influenced by:

• Events per second
• Data ingestion
• GB/day
• Number of users
• Number of endpoints
• Data retention
• Analytics features
• Cloud consumption
• Storage
• Additional modules

For organisations with significant log volumes, architecture becomes a financial decision as well as a cybersecurity decision.

Open-source and commercially supported security platforms can provide another route.

For example, organisations may evaluate technologies such as:

• Wazuh
• OpenSearch
• Elastic-based architectures
• Sigma
• TheHive
• Shuffle
• n8n
• Other open security and automation components

The objective should not be to use open-source software simply because it is free.

Open-source still carries costs involving:

• Infrastructure
• Engineering
• Administration
• Upgrades
• Security hardening
• Integration
• Monitoring
• Support
• Operational ownership

The right question is therefore:

Which architecture delivers the required security capability at an acceptable total cost of ownership?

Sigma Rules and Portable Detection Engineering

Detection engineering is often more important than the SIEM brand.

A SIEM platform without effective detection logic can become little more than an expensive log repository.

Sigma provides a vendor-neutral format for describing detection rules, making it possible to develop and maintain detection logic across different security platforms.

This can help organisations build a more structured detection library around scenarios such as:

• Brute-force authentication
• Privilege escalation
• Suspicious PowerShell activity
• Unusual administrative activity
• Credential misuse
• Lateral movement
• Malware execution
• Persistence mechanisms
• Suspicious network activity

The detection programme should be aligned with the organisation’s threat model rather than blindly deploying hundreds of generic rules.

A smaller number of well-tuned, business-relevant detections can be more valuable than thousands of poorly tuned alerts.

The Real Cost of a SOC Is Analyst Time

SIEM costs are only one part of security operations.

The larger operational expense can be the people required to investigate the alerts generated by the platform.

If a SIEM produces thousands of low-quality alerts every day, analysts spend their time closing noise rather than investigating genuine threats.

That creates a vicious cycle:

More logs → More alerts → More noise → More analyst workload → Slower investigations

A better architecture aims for:

Better telemetry → Better correlation → Better prioritisation → Fewer false positives → Faster investigation

This is where automation becomes valuable.

SOAR and Security Automation

Security Orchestration, Automation and Response can automate repetitive activities that do not require immediate human judgement.

Depending on the organisation’s risk appetite and security architecture, automated workflows can support actions such as:

• Enriching an IP address
• Checking threat-intelligence reputation
• Collecting endpoint information
• Creating an incident ticket
• Notifying the security team
• Requesting analyst approval
• Blocking an indicator
• Disabling an account
• Isolating an endpoint
• Collecting forensic information

Tools such as TheHive, Shuffle and n8n can be evaluated as components of an automation architecture.

However, automation should be introduced carefully.

Automatically disabling a legitimate banking administrator’s account or blocking a critical production service can create its own operational incident.

For high-impact actions, human approval and clearly defined playbooks remain essential.

Building SIEM Around the Banking Threat Model

The SIEM architecture should reflect the threats the institution actually faces.

For a financial organisation, detection scenarios may include:

Account Takeover

Detect unusual authentication behaviour, credential attacks and abnormal login patterns.

Privileged Account Abuse

Monitor administrative activity across critical infrastructure and applications.

Insider Risk

Identify unusual access to sensitive systems, abnormal data activity or policy violations.

Payment-System Abuse

Correlate authentication, application, network and transaction-related security events where appropriate.

Malware and Ransomware

Correlate endpoint detections with authentication, network and process activity.

Lateral Movement

Identify suspicious internal authentication, remote administration and unusual east-west network activity.

Data Exfiltration

Look for abnormal access patterns, unusual transfers and suspicious external destinations.

The exact detections should be developed according to the institution’s architecture, threat model and risk assessment.

SIEM and RBI Cybersecurity Expectations

SIEM should not be purchased simply because a regulator mentions security monitoring.

The architecture should be mapped to the institution’s actual regulatory obligations.

RBI’s IT Governance Directions require regulated entities to establish an IT and information-security risk-management framework, identify critical information systems, maintain appropriate security controls and establish cyber incident response and recovery capabilities. They also place explicit responsibilities on the CISO and require the CISO’s office to manage and monitor the SOC and ensure effective functioning of deployed security solutions.

RBI has also issued sector-specific cyber-resilience requirements where centralised monitoring and SIEM-based correlation are explicitly referenced, including requirements for Security Operations Centres and automated mechanisms to correlate network and system alerts for certain regulated entities.

Therefore, the right SIEM question is not:

“Which SIEM is cheapest?”

It is:

“Which monitoring architecture can provide the required visibility, detection, investigation, retention and evidence for our risk and regulatory environment?”

CERT-In, Logging and Evidence

Security logs also have value beyond real-time detection.

They may become important during:

• Security investigations
• Incident response
• Forensic analysis
• Internal audits
• Regulatory examinations
• Legal proceedings
• Root-cause analysis
• Threat hunting

Organisations should therefore design logging around applicable legal and regulatory requirements rather than assuming one retention period applies universally to every system and every organisation.

The same principle applies to time synchronisation.

Accurate timestamps are fundamental to incident reconstruction.

If authentication occurred at 10:02, a firewall event occurred at 10:03 and an endpoint alert occurred at 10:04, investigators need confidence that these timestamps represent the same timeline.

Reliable time synchronisation therefore becomes an important component of security monitoring architecture.

DPDP and the Importance of Security Monitoring

The Digital Personal Data Protection Act, 2023 establishes obligations around protection of personal data and provides for significant penalties for certain breaches, including failure to take reasonable security safeguards to prevent personal-data breaches.

SIEM does not make an organisation automatically compliant with the DPDP framework.

However, effective security monitoring can contribute to a broader security-control environment by improving:

• Detection
• Incident investigation
• Security visibility
• Evidence collection
• Access monitoring
• Event correlation
• Response capability

The appropriate controls should always be determined according to the organisation’s role, processing activities, applicable law and risk profile.

A Cost-Optimised SIEM Implementation Roadmap

Sidigiqor recommends approaching SIEM implementation as an architecture and operating-model exercise rather than a software procurement project.

Phase 1 — Asset and Log-Source Discovery

Identify critical systems and their associated telemetry.

Prioritise:

• Identity infrastructure
• Firewalls
• Critical servers
• Endpoints
• Internet-facing systems
• Applications
• Databases
• Cloud platforms
• Security appliances
• Critical third parties

Phase 2 — Risk-Based Log Classification

Classify events according to:

Security value + business criticality + investigation value + retention requirement

This determines what should receive real-time treatment and what can be archived.

Phase 3 — Secure Log Collection

Deploy appropriate collection and forwarding mechanisms with encryption, authentication, integrity protection and controlled access.

Phase 4 — Detection Engineering

Develop detection use cases around actual threats instead of enabling every available rule.

Phase 5 — SIEM Deployment

Implement the selected SIEM or security analytics platform with appropriate:

• Parsing
• Normalisation
• Correlation
• Dashboards
• Alerting
• Search
• Access control
• Retention

Phase 6 — Automation

Automate repetitive enrichment and response tasks while maintaining human approval for high-impact actions.

Phase 7 — SOC Operating Model

Define:

• L1 responsibilities
• L2 investigation
• L3 escalation
• Incident ownership
• Response procedures
• Management reporting
• Evidence retention

Phase 8 — Continuous Improvement

Review:

• False-positive rates
• Detection coverage
• Mean time to detect
• Mean time to respond
• Incident trends
• Log-source health
• Storage consumption
• Unmonitored critical assets

SIEM should be treated as a continuously evolving capability.

What a Good SIEM Dashboard Should Actually Tell Management

A management dashboard should not simply display the number of alerts.

Leadership needs meaningful information.

For example:

• Number of critical incidents
• Open high-risk incidents
• Mean time to detect
• Mean time to respond
• Critical assets without telemetry
• Failed log sources
• High-risk vulnerabilities
• Privileged-account anomalies
• Repeated attack patterns
• Security-control failures
• Incident trends
• Outstanding remediation actions

The objective is to connect technical events with business risk.

Common SIEM Implementation Mistakes

Organisations should avoid several recurring mistakes.

Sending Everything Into the SIEM

High volume does not automatically equal high security.

Buying the Platform Before Designing the Architecture

Technology should follow the security and operational requirements.

Ignoring Log Quality

Poor parsing and inconsistent timestamps can make investigations difficult.

Creating Too Many Alerts

An alert that nobody investigates is not an effective control.

Failing to Monitor the SIEM Itself

A broken log collector can silently create a major visibility gap.

Treating Automation as a Replacement for Analysts

Automation should reduce repetitive work, not eliminate human judgement from high-impact decisions.

Ignoring Retention Architecture

Long-term evidence requirements can make a purely hot-storage architecture unnecessarily expensive.

Measuring the Wrong KPIs

The number of alerts processed is far less meaningful than detection quality, investigation time and incident outcomes.

The Sidigiqor Approach

Sidigiqor Technologies helps organisations design cybersecurity and IT environments around risk, resilience and operational practicality.

Our capabilities span:

• Cybersecurity Consulting
• SIEM & Security Monitoring Architecture
• Managed IT Services
• IT Infrastructure Development
• Firewall Management
• Network Security
• VAPT & Security Testing Coordination
• IT Audit & Technology Risk Assessment
• Backup & Disaster Recovery
• Endpoint Security
• Security Operations Support
• Cybersecurity Governance
• Incident Response Readiness

For organisations considering SIEM implementation, optimisation or SOC modernisation, our approach begins with the existing environment.

We assess the infrastructure, identify critical assets, understand log-generation patterns, map security use cases and then determine an architecture appropriate to the organisation’s risk and budget.

The goal is not to build the most expensive SOC.

It is to build a security monitoring capability that can actually be operated, measured and improved.

A high-capability SIEM does not have to mean an uncontrolled technology bill.

The economics improve when organisations stop treating every log as equally valuable.

A well-designed architecture can combine:

Risk-based log collection

Intelligent event filtering

Hot/warm/cold data tiers

Open and commercially supported security technologies

Portable detection engineering

Security automation

Co-managed SOC capabilities

Continuous optimisation

The objective is not simply to collect more data.

It is to create better security decisions from the data that matters.

For financial institutions, the most important question is therefore not:

“How much data can our SIEM ingest?”

It is:

“Can our security monitoring environment reliably detect, investigate, respond to and evidence the threats that matter to our business?”

That is the standard a modern security architecture should be designed to meet.

Build a Cost-Optimised Security Monitoring Architecture With Sidigiqor

If your organisation is evaluating a new SIEM, replacing an expensive security-monitoring platform, improving an existing SOC or trying to reduce log-management costs without sacrificing visibility, Sidigiqor Technologies can help assess the environment and design a practical architecture.

We work with organisations across Chandigarh, Mohali, Panchkula, Haryana, Punjab, India and international markets, supporting cybersecurity, IT infrastructure, network security and managed technology operations.

Talk to Sidigiqor Technologies

Business: Business@Sidigiqor.in
Support: Support@Sidigiqor.in
India: +91 99115 39101
UAE: +971 56 240 9703

India Office: Ramgarh, Panchkula, Haryana – 134118

Serving: Chandigarh | Mohali | Panchkula | Zirakpur | Dera Bassi | Baddi | Solan | Haryana | Punjab | Himachal Pradesh | India | GCC | USA | UK

Sidigiqor Technologies — Secure. Scalable. Strategic.