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.
Sent from Yahoo Mail for iPhone On Wednesday, March 6, 2024, 10:02 AM, kekronbekron <000002dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I guess you might say that the whole point of products such as these is > converting dense "strings & numbers" into logs. I agree, except that I think the goal is not to squirrel metrics into logs, but to get metrics and/or logs (actual SYSLOG) to tooling used outside of mainframe. > no, we want to manage mainframe security 100% on the mainframe" and that may > be valid, but not every enterprise feels that way. Not saying this, I certainly see the value in common tools, especially if it means adopting good tech from distributed. I just don't see how high volume metrics (even if we filter down to just a few 100, from all SMF types) can be equated to more or less logs, and handle them like that, except because it's already in use elsewhere in the org. Instead of chosing the right tool for the job. On Wednesday, March 6th, 2024 at 20:20, Charles Mills <charl...@mcn.org> wrote: > I guess you might say that the whole point of products such as these is > converting dense "strings & numbers" into logs. A mainframe security "event" > is surely as significant to the enterprise as a Linux server security event > -- it makes sense to many enterprises to get it into their enterprise > security analysis solution (Splunk, Sumo Logic, or a "SIEM"). You may say > "no, we want to manage mainframe security 100% on the mainframe" and that may > be valid, but not every enterprise feels that way. I feel that there is a > benefit to correlating the two worlds, and correlation is what SIEMs and > Splunk are good at. In other words, it may be relevant that the mainframe is > seeing hundreds of invalid password attempts at the same time that a Linux > server is seeing DoS attacks. > > When you think of SMF you may primarily think in terms of job accounting and > resource management, but the first record type that customers usually want to > export to Splunk or a SIEM is RACF's type 80. > > Yes, SMF is very "dense" and Syslog -- the industry standard logging "thing" > -- too loosely defined to be called a standard, and not to be confused with > what we mainframers call SYSLOG -- is basically human-readable ASCII text and > not very dense at all. The most common format is some variant of tag = value, > so one binary byte at offset 20 into an SMF 80 record might become EventCode > = 1 or perhaps Event = RACINIT. > > It's a big job. I just looked. At the point I turned the product over to BMC > it consisted of about 100,000 lines of C++, 26,000 lines of assembler, and > 60,000 lines of a proprietary schema that mapped, for example, a binary byte > at offset 20 in an SMF 80 record, to EventCode = nn. > > Charles > > On Wed, 6 Mar 2024 02:15:14 +0000, kekronbekron kekronbek...@protonmail.com > wrote: > > > I don't understand this at all... we all know that SMF is not a log, it's a > > whole bunch of strings & mostly numbers... metrics. > > Why has it become acceptable to send metrics to a log search tool, knowing > > full well that these are different categories with different solutions. > > Splunk etc. are meant to collect and search through things like http web > > server log, not metrics. > > The information density in a log is low. In SMF, it's very high (there are > > no fluff words, just metrics which may or may not be of use during a given > > activity). > > > ---------------------------------------------------------------------- > 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
