Integrate mainframe security events into your SIEM with VSA (formerly SMA_RT).
Fill the mainframe gap in your SIEM
For years, mainframe security and auditing stayed isolated inside the mainframes, available via batch jobs running hours after the events they reported. But isolated silos of data simply won’t stand up to today’s security threats and rigorous auditing requirements.
VSA agents acquire messages from the z/OS system console and z/OS SMF (System Management Facility), and pass critical security information to the central enterprise SIEM (Security Information and Event Management).
The VSA Security Monitor brings your z/OS mainframes into the center of your enterprise security infrastructure.
VSA Improves Threat Detection and Incident Response Capabilities
- Use VSA as part of a Central Log Management (CLM) initiative to maximize your SIEM investments.
- Use VSA as a tool to better manage your existing SIEM investment if your organization has an existing SIEM solution that cannot scale its collection and analysis capabilities due to budget constraints.
- Some SIEM tool licensing approaches cause organizations to restrict the collection of vital data because of licensing capacity and budget considerations, not VSA.
- Compliance requires multiple sources of events to quickly determine if a suspected security incident is valid. VSA is not only a tool; it is an important part of the solution!
There is no Substitute for 17 Years of Experience
- The US Department of State used this software for the monitoring of activity on a passport database while migrating from mainframe to server technology.
- The z/OS SIEM Agent DB2 database monitoring facility was designed in conjunction with the Australian Customs Service to monitor all import and export shipments.
- By deploying the z/OS SIEM Agent on the mainframe, within days the hospital was able to consolidate mainframe security events with other events from the network. They leveraged previously purchased software, converted a manual procedure into a fully automated one, and surpassed the auditor’s requirements.
- The auditors of an insurance provider using the z/OS SIEM Agent determined they must report on all DB2 SYSADMIN and DBADMIN activity. This requirement was mandated regardless of the internal DB2 filters being set within the z/OS SIEM Agent and regardless if SMF 102 audit class 11 records were even being collected. The auditors requested this requirement to be in place before the next audit in July of 2017. The change was made to the software, tested and implemented at the customer site six months before the required deadline.
- The z/OS SIEM Agent was provided to a potential banking customer on a trial basis. The customer agreed to purchase the software at the end of the trial period if it could provide a method to process CICS application data on the mainframe. The CICS API was designed, developed, tested, accepted by the customer, and the product was purchased within a two-week period. The CICS API has been incorporated into the base of the z/OS SIEM Agent as a result of a potential customer expressing their needs.
- Chargeback and billing reports were produced for one of the z/OS SIEM Agent customers, however, CPU consumption reports for the agent were not appearing on the report. After investigation, it was determined the CPU performance was not showing up in the reporting system because the CPU usage reporting parameter for charge-back report to the customer was set too high. The z/OS SIEM agent used less CPU time across 27 LPAR’s than the bank had previously experienced with any other software product.