Any contractor who elevates his/her security access should immediately be fired and possibly reported to authorities. Unless of course the security people at the shop were negligent in giving him the authority to elevate him/herself. The shop I was referring to in which I worked, had mainframe security people who weren’t mainframers telling the Systems Programmers (or installers) with 40+ years of experience, including decades of RACF/ACF2/TSS experience how they knew more about security and how critical Splunk is to insuring MF security. Utter BS.
Sent from Yahoo Mail for iPhone On Wednesday, March 6, 2024, 11:02 AM, 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