These days, running cybersecurity operations is challenging. There are too many security tools, each with its own dashboards and logs to take care of, while also keeping the entire cost at manageable levels.  

Gartner, in one of its articles, “Simplify Cybersecurity With a Platform Consolidation Framework,” shared that an average business works with 10 to 15 security vendors and uses over 60 to 70 security tools.

This is creating two problems for businesses:

• All these security tools operate in silos. The telemetries they generate come in different standards, schemas, and data structures. Trying to form a correlation amongst them is akin to pulling your hair out. It’s frustrating.
  
• Ingesting and storing telemetries generated from 60-70 security tools in SIEM spikes up the bill, which negatively impacts the overall security budget.

Both of these issues are leaving organizations more vulnerable to cyberattacks in the future.  

How Different Standards, Schemas, and Data Structures of Security Tools Hinder Decision Making

Security logs are generated in Syslog, CEF, LEEF, JSON, XML, STIX, CSV, or proprietary console logs. Their translation and interpretation to form a complete picture of the security risks not only becomes difficult, but also wastes a lot of time. 

Here is a short scenario to help you readers understand this better. 

Your email security detects and flags a phishing attempt in the CEF format.  

CEF:0|Proofpoint|Email Security|8.14|malware|Phishing

Email|10|suser=Rahul.doe@company.com src=mail.evil.com

As you can see, since these security
‍
The identity access management tool shows that an employee has clicked on the link and logged in from a different location in the JSON (API log). 

{
  "timestamp": "2025-08-26T06:30:00Z",
  "eventType": "LOGIN_SUCCESS",
  "user": "Rahul.doe",
  "ip": "203.0.113.25",
  "location": "Moscow, RU"
}

Also, the EDR flashes a malware alert in JSON, but in a different schema.

{"event": "MALWARE_DETECTED", "host": "LAPTOP-123", "process": "ransomware.exe", "user": "Rahul.doe", "ip": "203.0.113.25"}

Your firewall sees the outbound connection, in which the infected endpoint connects with the adversary’s server and logs it in the Syslog (key-value-pairs) format. 

<134>Aug 26 12:32:10 firewall01 TRAFFIC: src=10.1.1.25 dst=203.0.113.25 proto=TCP sport=443 dport=8080 action=ALLOW

As you can see, since these security tools are communicating in different languages, it becomes challenging for the security team to form the correlation between the email —> login —> malware chain. They need more time in making the right call.  

Also, since they are already dealing with too many alerts, it may take them between 8 — 24 hours to detect this specific cyberthreat, which is too late, as speed is everything in cybersecurity.
‍

The Ballooning Costs of Managing Security Telemetries 

Due to so many tools at their disposal, the security teams are drowning in data.

It is flowing from authentication & identity, endpoints, networks, email security, cloud & SaaS, vulnerability & patching, threat intelligence feeds, data protection logs, application & API logs, compliance & audit logs.

Ingesting and storing all of these security telemetries into SIEM has become a costly affair. 

If we go by Gartner’s estimates, 60–70 security tools can easily generate 200–500 GB/day of raw security telemetry. Depending on the licensing model and vendor, ingesting this volume into a traditional SIEM can cost anywhere from hundreds of thousands to several million dollars per year, which is unsustainable for many mid-size organizations.

It becomes a game of security v/s budget, in which the security team is forced to let go of some data to save costs, which creates security blind spots, making the business more vulnerable to data breaches as it has an incomplete picture of the risks that loom over its head.

Also, many compliances require businesses to retain their event logs and audit data for a set period of time—storing it on SIEM will further shoot up the price as vendors charge based on the data volume ingested and stored in it.   

Organizations are stuck paying more while seeing less.

Both the OCSF and security data lake can solve these two issues that are proving to be troublesome for the majority of businesses.

OCSF Standardizes Your Security Logs, Making It Easier to Form Correlation and Make the Right Decision

OCSF (Open Cybersecurity Schema Framework) is open source, and a vendor neutral standard, which unifies all the security logs like, Syslog, CEF, LEEF, JSON, XML, STIX, CSV, and proprietary console logs under a common schema. The latest version, OCSF 1.7.0, is released. 

Here is how it works. This is just an example to help you readers give an idea. 

In case there is a phishing attack, the OCSF normalization will make the detection and response easier for the security team.

Here is a live example. As we demonstrated in the earlier section, your email security tool detects a suspicious email and logs it in the CEF format.

CEF:0|Proofpoint|Email Security|8.14|malware|Phishing Email|10|suser=rahul.doe@

Your EDR detects the employee clicking on the phishing link and logs the entire output in the JSON format.

{"event":"malware_detected","user":"rahul.doe","severity":"high"}

The Firewall sees the traffic from the user’s system to a malicious domain and logs it in a Syslog. 

Aug 28 10:15:32 firewall1 proxy[456]: connection to badsite.com from 192.168.1.10

 The OCSF converter will take all these raw inputs and translate them into the same schema. In the case of this phishing attack, it will be:

• SecurityFinding 
• AuthenticationActivity
• NetworkActivity 

The normalized OCSF output will look like this: 
‍

Email Security log will be under SecurityFinding 

{
  "class_name": "SecurityFinding",
  "category": "Phishing",
  "severity": "High",
  "actor": { "user": "rahul.doe" },
  "tool": "Email Security"
}

EDR logs will be under MalwareDetection 

{
  "class_name": "MalwareDetection",
  "actor": { "user": "rahul.doe" },
  "severity": "High",
  "threat": { "type": "Phishing Payload" }
}

Firewall logs will be under NetworkActivity

{
  "class_name": "NetworkActivity",
 "actor": { "user": "rahul.doe" }
  "src_endpoint": { "ip": "192.168.1.10" },
  "dst_domain": "badsite.com",
  "outcome": "connection_attempt"
}

‍

Generating the security logs in the same schema is going to be immensely helpful in forming the correlation between the phishing mail, malware payload, and the connection attempt to the adversary’s server.

This will also eliminate the need for custom parsers for each format.  

Your security team will be able to see the entire chain of events instead of seeing three siloed logs.

While the OCSF standardizes all the security telemetry in the same schema, instead of storing these logs in SIEM, which spikes up the bill, a security data lake is a much more cost-effective option compared to SIEM. 

It’s More Cost-Effective to Store All Your Structured, Semi-Structured, and Unstructured Data Into a Security Data Lake

Infopercept recently hosted an event on securing the Fintech core, cybersecurity for platform-driven BFSI. One of the customer insights we got from that event was that the person had been using a separate SIEM for on-premise and cloud.

They were looking for a security data lake. ​

Their business was facing data fragmentation issues as the security logs were split between on-premise SIEM and Cloud SIEM. Since there was no single pane of glass, it was taking more time for them to investigate as they would have to constantly juggle between two tools. ​

Furthermore, having two separate SIEMs meant paying for double licensing fees, as legacy SIEM charges either on events per second or GB per day, and cloud scale ingestion was proving to be expensive, ultimately forcing the business to get a separate SIEM for on-premise. But this was also incurring high costs as the organization had to store long-term event logs and audit data in two SIEMs to stay compliant with SEBI/RBI guidelines for the BFSI industry.

A security data lake can solve these issues, but you shouldn’t completely ditch your SIEM for it. 

Instead, what you can do is ingest and store all your structured, unstructured, and semistructured logs into your security data lake and then transfer only the most essential and useful telemetry into your SIEM.

Depending on your cloud provider and storage tier, keeping 500 GB/day of logs in a security data lake often lands in the tens of thousands to low six figures per year, compared to hundreds of thousands to multiple millions for traditional SIEM ingestion.

Also, your security team will not feel the pressure to choose which data sources to collect and which ones to let go of for the sake of maintaining the budget. For compliance purposes, your business will be able to retain all its event logs and audit data for a longer period without having to worry about the bill.

Lastly, by retaining all your security telemetry, there will be no blind spots,as your security team will get the full picture of the attack surface and identify risks that can soon become the cause of a breach in the future. 

This will strengthen the security posture of your organization in the long run. 

With Invinsense, You Get Security Consolidation, Standardized Security Logs, and a Security Data Lake

Cybersecurity isn’t just about getting more tools; it also involves making the right decisions at the right time. Invinsense will help you make the right call by consolidating most of your security tools into one place, standardizing all the logs they generate through OCSF, and storing all your telemetry on the data lake at a fraction of the cost compared to SIEMs.

• Platform consolidation will solve most of the integration issues between different security tools that your business uses.  
• OCSF enables your security team for quicker incident response to detect, manage, and mitigate cyberattacks.
• The data lake will store all your structured, semi-structured, and unstructured logs at a cheaper rate compared to SIEMs. 

Additionally, with Invinsense, your business won’t have to change most of its security tools. You can simply consolidate most of your existing security tools into our platform. In case you are missing any security stack, you can integrate it from Invinsense, which has consolidated 23 cybersecurity solutions.

‍