> On 7 Mar 2024, at 10:08 am, kekronbekron > <000002dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > >> You are making a mistake if you discount the effectiveness of >> industry-standard tools in analyzing mainframe data. > > Let me clarify... I'm not saying don't use it at all. Just saying that there > seems to be a tendency to lean too heavily on it, after it has gotten its > foot through the door (for receiving security events). > I don't expect it to be great for either real-time processing of high volume > perf data or for archival of said data efficiently, and allowing for > historical reporting/charting etc. > I have a solid background in sending metrics to analytical platforms, having focused on this for the past decade. While platforms like Splunk and Elastic are primarily designed for logs, they excel in handling metrics, especially when scaled out in a cluster with sensible retention policies. Incorporating Kafka as a broker enhances this setup, allowing for efficient stream aggregation and anomaly detection using tools like the Kafka Streams API or ksqlDB. We've seen our customers adopt this approach, as evidenced by our recent service update enabling Kafka to utilize RACF keyring for TLS connections, a case initiated by your employer, KB.
The product I'm currently engaged with streamlines seamless streaming to platforms such as Splunk, Elastic, Instana, and supports Prometheus metrics visualized through Grafana. Additionally, we're actively pursuing compatibility with Otel, driven by customer demand. Notably, the introduction of the Grafana UI in RMF for z/OS 3.1 offers a modernized experience compared to the outdated 3270 interface, earning praise even from our most seasoned and skeptical professionals. The mainframe is just one piece of a larger puzzle. Customers operate distributed systems that have long employed modern stacks for visualization and analysis, and they desire z/OS to seamlessly integrate into that ecosystem. We face an abundance of requirements that need addressing. The traditional approach of relying solely on batch reporting tools for performance analysis is becoming obsolete. Here's a compelling customer case study that illustrates how upgrading our tools supports them in their modernization journey. You can find it at https://www.ibm.com/case-studies/bankdata. > > > > On Wednesday, March 6th, 2024 at 21:32, Charles Mills <charl...@mcn.org> > wrote: > >> I of course saw first-hand a lot of mainframe -> SIEM or Splunk >> integrations, and they ran the gamut. Some were as you describe; some were >> quite effective. The worst I saw was one company that was printing an SMF >> report to spool, using a mainframe product to convert the spooled report to >> a PDF, and sending it to the SIEM, which dutifully archived it. Made the >> auditors happy: mission accomplished. On the other hand, believe me, there >> were customers doing truly amazing "production" and ad hoc analyses both of >> security and performance data, using Splunk and other tools. (Recall I have >> no financial or similar interest in BMC, Splunk, or anything similar.) >> Splunk is not my favorite product -- the company was extremely difficult to >> deal with and the product is expensive to license, but it is an AMAZING >> product and many customers and customer people absolutely LOVE it. (That of >> course is why they are able to charge what they charge.) >> >> >> I was personally on a Zoom call with a very major financial institution that >> you would recognize in a heartbeat, doing a product new-feature demo, when >> we caught an intruder in the mainframe, real time. It was a contractor who >> was authorized to be on the mainframe but who had managed to improperly >> elevate his privileges to SPECIAL. it was an amazing moment, going from >> routine vendor product demo to "what the heck is HE doing -- hey, we gotta >> go." >> >> I was not aware of all of the exact details but our processing in >> conjunction with a SIEM was instrumental in uncovering a money-laundering >> scheme at a large bank in Mexico. >> >> My main interest was the security stuff, but yes, customers are doing very >> effective analysis of RMF and similar data. You are making a mistake if you >> discount the effectiveness of industry-standard tools in analyzing mainframe >> data. >> >> Charles >> >> On Wed, 6 Mar 2024 15:26:47 +0000, kekronbekron kekronbek...@protonmail.com >> wrote: >> >>> Exactly. I have my reservations on whether we as mainframe folks are >>> choosing this (log analytics products) or are defaulting to it because no >>> one is challenging for appropriate options from the mainframe technical >>> side. >>> For an org, there is of course the valid point of correlation that Charles >>> mentions, however, if you objectively work out costs and that, I don't >>> think it works out as cost-effective. >>> >>> We may see kubernetes platforms sending auth logs, syslog, and whatever >>> else to log analytics, but they don't send system metrics. >>> Time-series data is a different beast altogether. However much >>> elastic/splunk/whoever else says they also do metrics, they're only >>> secondary features at best. >>> There's a reason time-series databases exist, and are necessary. >>> >>> On Wednesday, March 6th, 2024 at 20:48, Dave Beagle >>> 00000525eaef6620-dmarc-requ...@listserv.ua.edu wrote: >>> >>>> We used Splunk at a former employer. Well, not really used it. An auditor >>>> “suggested” we implement it to “improve” our mainframe security. The >>>> auditor knew nothing about mainframe security. Likely read about Splunk >>>> somewhere or saw a session on it at a conference. And of course the topic >>>> of “security” is at the top of the heap among executives who wouldn’t know >>>> Top Secret from ACF2 from RACF. Especially when they hear that other >>>> companies are being hacked or blackmailed in the media nearly every day. >> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
