Securitylab•August 4, 2026•🇷🇺Translated from Russian

Security Vision SIEM Tackles Alert Overload with Data Quality Monitoring and MITRE ATT&CK Coverage

In November 2013, a FireEye system costing 1.6 million dollars performed exactly as promised. It detected malware on Target point-of-sale terminals, generated multiple consecutive alerts, and even revealed intermediate servers receiving stolen data. The Bangalore shift noticed the signal and escalated it to Minneapolis, yet nothing further happened.

One month later the company disclosed the theft of 40 million payment cards and personal data of another 70 million people, with direct costs exceeding 200 million dollars. The automatic malware removal function had been manually disabled. Technology worked; process did not.

Since then much has changed, except the core issue. According to Vectra AI data for 2026, organizations receive an average of 2,992 alerts per day, and 63 percent of them remain uninvestigated. The Microsoft and Omdia SOC report adds further detail: 46 percent of alerts prove false positives. In the SANS 2025 survey, 73 percent of teams named false positives the primary detection problem. Analysts simultaneously juggle an average of 10.9 consoles.

Collecting logs is inexpensive and straightforward. Turning those logs into a managed process that reveals data quality, detection quality, and the full incident path is considerably harder.

What Security Vision SIEM Can Do

The product, built on the Russian Security Vision 5 Low-Code/No-Code platform, combines event collection and normalization, data quality control, attack detection, investigation, and basic response actions. Customers receive not an empty box with a promise to configure it themselves, but ready SOC expertise: more than 1,200 correlation rules, coverage of over 70 percent of MITRE ATT&CK techniques, mapping to FSTEC BDU threat implementation methods, and incident handling recommendations.

The July 2026 update introduced monitoring of collection stability and rule performance, SOC analyst SLA control, statistical anomaly detection, rule testing, Sigma rule exchange, and retrospective process chain reconstruction inside incidents.

Three Levels Where Everything Can Break

SIEM effectiveness rests on data completeness, detection quality, and response speed. Failure at any level nullifies the other two.

  • Level one: The SOC must be confident that required events actually arrive. Agents stop, administrators change logging settings for unrelated reasons, or hosts behind WEC or syslog aggregators silently drop out while the aggregator reports healthy status.
  • Level two: Detection rules must reflect real attack scenarios, infrastructure specifics, and temporal event relationships. Simple signatures rarely catch multi-stage attacks when events from different sources arrive delayed and interleaved.
  • Level three: Detection is only the start. Analysts must assess asset criticality, examine processes, accounts, network connections, lateral movement, confirm the incident, and act. Each manual tool switch adds minutes that accumulate into the 200 million dollar losses seen at Target.

Security Vision SIEM unites the entire chain: connect sources, verify data quality, detect suspicious activity, reconstruct attack context, and move to response.

Related articles

Habr•Other

How to Prepare Your Website for Data Center Outages: Business Resilience Checklist

Following strikes on Yandex data centers, many businesses discovered that their sites and all backups were stored in a single location, leading to complete outages. The article provides a detailed checklist to mitigate such risks by separating critical components across different providers. Key recommendations include moving DNS to an independent provider, lowering TTL values, maintaining a live mirror site on separate hosting, and isolating corporate email. Additional steps cover local backups, monitoring, access management, and CDN usage. The guidance differentiates between virtual hosting, VPS or dedicated servers, and website builders like Tilda, while emphasizing compliance with Russian data localization laws such as 152-FZ.

Securitylab•Other

How to Properly Compare CDNs: TTFB, p95 Latency, Caching, DDoS Protection and True Pricing

Selecting a CDN based solely on the number of points of presence is as unreliable as choosing a car by dashboard buttons. Networks with dozens of global PoPs may underperform for audiences concentrated in Novosibirsk or Yekaterinburg, while smaller regional providers often deliver superior peering with Russian operators. The article evaluates CDNVideo, EdgeCenter, Curator, NGENIX and Yandex Cloud CDN across verifiable features, network design, caching behavior, security controls, operations and commercial models. Performance data is separated because marketing claims cannot substitute for independent measurements from services such as CDNMON. Emphasis is placed on p95 metrics, cache hit ratios, origin shielding, raw logs and API limits rather than marketing scores. The analysis shows that no single universal ranking exists; optimal choice depends on traffic profile, audience geography, security requirements and operational workflows.

Habr•Other

Innostage Lab Benchmarks PT NGFW 1.10.3 Performance in Eight Load Scenarios

Innostage researchers conducted extensive performance testing of PT NGFW version 1.10.3, the certified release at the time of trials. The evaluation covered TCP connection setup rates, concurrent session capacity, and throughput on a custom EMIX traffic profile with varying security modules enabled. Tests used Cisco TRex generators and a high-rule-count policy of 100,000 entries to simulate realistic enterprise conditions. Results showed the device sustaining 700,000 CPS and 6.4 million concurrent connections, matching or approaching vendor claims under HA-cluster configuration. Throughput remained above 27 Gbps even with IPS, application control, antivirus, NAT, URL filtering, and logging active. The report highlights differences in test methodology compared with vendor figures, including packet sizes and clustering setup.

Habr•Other

Java Card Tutorial: Implementing Supplementary Security Domain to Limit ISD Privileges

A detailed technical guide demonstrates how to create a Supplementary Security Domain (SSD) on Java Card platforms to isolate applet management from the Issuer Security Domain (ISD). The approach prevents full card compromise if ISD keys are exposed by restricting SSD privileges to specific functions such as accepting extradition only from the ISD. Using the FunGP library and SCP02 protocol, the tutorial walks through installation, personalization with encrypted keys, and extradition of applets under the new domain. GlobalPlatform specifications including GP CS v2.3 and GP CIC v2.0 are followed for install parameters, privileges, and STORE DATA commands. After personalization the SSD reaches the PERSONALIZED lifecycle state, allowing secure delegation of applet control while the ISD retains overall card management rights. The method eliminates the need for custom operating systems and provides a standards-compliant way to enforce least-privilege access on smart cards.