Re: ZOS Sending Logs to Sumologic Experience?
Here’s the problem. When you “secure” the mainframe with LESS SECURE platforms, you actually open yourself up to hacks. Splunk has been hacked quite frequently. https://www.securityweek.com/high-severity-vulnerability-patched-in-splunk-enterprise/amp/ Sent from Yahoo Mail for iPhone On Thursday, March 7, 2024, 11:07 AM, Charles Mills wrote: Well sure, over-reliance on any one "solution" as a panacea is foolish. I had prospects tell me "we don't have any security issues -- we have RACF." CM On Thu, 7 Mar 2024 02:08:26 +, kekronbekron 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). -- 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
Re: ZOS Sending Logs to Sumologic Experience?
Well sure, over-reliance on any one "solution" as a panacea is foolish. I had prospects tell me "we don't have any security issues -- we have RACF." CM On Thu, 7 Mar 2024 02:08:26 +, kekronbekron 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). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOS Sending Logs to Sumologic Experience?
Awesome, I know & do tell you directly that you're doing excellent & needed work like zOS-ifying distributed tools. On Thursday, March 7th, 2024 at 15:08, David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu> wrote: > > On 7 Mar 2024, at 10:08 am, kekronbekron > > 02dee3fcae33-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 +, kekronbekron > > > kekronbek...@protonmail.com wrote: > > > > > > > Exactly. I have my reservations on whether we as mainframe folks are
Re: ZOS Sending Logs to Sumologic Experience?
> On 7 Mar 2024, at 10:08 am, kekronbekron > <02dee3fcae33-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 > 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 +, 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
Re: ZOS Sending Logs to Sumologic Experience?
I think that SMF itself is not sufficient for security alerts. Only part of the activity is recorded and the event is not understood by the auditors. A good example is adding a dataset to APF by a sysprog. He got a call the first time, saying this is his day job, second call, but as the wolf and the shepherd, they will white list the event. However, such change has side effects on security. For example, the dataset is not properly protected and can be used by others. Many MVS commands allow change of system configuration on the fly and, again, are not visible to SMF. In general, I think SIEM is nice to have, but you need to have a more accurate solution that goes directly to SOC telling the event and how it affects security by creating new attack vectors. ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Wed, Mar 6, 2024 at 6:02 PM Charles Mills 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 +, 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 < > 0525eaef6620-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
Re: ZOS Sending Logs to Sumologic Experience?
> 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. On Wednesday, March 6th, 2024 at 21:32, Charles Mills 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 +, 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 > > 0525eaef6620-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
Re: ZOS Sending Logs to Sumologic Experience?
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 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 +, kekronbekron 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 ><0525eaef6620-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
Re: ZOS Sending Logs to Sumologic Experience?
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 +, kekronbekron 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 ><0525eaef6620-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
Re: ZOS Sending Logs to Sumologic Experience?
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 <0525eaef6620-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. > > > Sent from Yahoo Mail for iPhone > > > On Wednesday, March 6, 2024, 10:02 AM, kekronbekron > 02dee3fcae33-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 +, 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
Re: ZOS Sending Logs to Sumologic Experience?
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 <02dee3fcae33-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 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 +, 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
Re: ZOS Sending Logs to Sumologic Experience?
> 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 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 +, 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
Re: ZOS Sending Logs to Sumologic Experience?
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 +, kekronbekron 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
Re: ZOS Sending Logs to Sumologic Experience?
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). On Tuesday, March 5th, 2024 at 00:13, Steve Estle <05dcac13570d-dmarc-requ...@listserv.ua.edu> wrote: > All, > > We are embarking on an endeavor to explore sending logics to a tool called > Sumologic(sumologic.com). For those who are unaware, Sumologic is a > competitor to Splunk and contains a very powerful real time log parsing > analytics engine which can be used to build dashboards, alerts, and more. My > basic question is has anyone heard of or actually been involved in devising > ways to send ZOS logs into Sumalogic - our initial efforts will be security > related, but for now am just asking if anyone has any experience in this > realm at all? Or maybe you are doing something similar to Splunk? If so, you > can post in forum or feel free to reach directly out to me: > > Thanks much, > > Steve Estle > sest...@gmail.com > 303-817-9954 > > -- > 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
Re: ZOS Sending Logs to Sumologic Experience?
Steve Estle wrote: >We are embarking on an endeavor to explore sending logics to a >tool called Sumologic(sumologic.com). For those who are unaware, >Sumologic is a competitor to Splunk and contains a very powerful real >time log parsing analytics engine which can be used to build dashboards, >alerts, and more. My basic question is has anyone heard of or actually >been involved in devising ways to send ZOS logs into Sumalogic – our >initial efforts will be security related, but for now am just asking if >anyone has any experience in this realm at all? Or maybe you are >doing something similar to Splunk? I’m not too familiar with Sumo Logic, but they say they can ingest several different log/event feeds, notably LEEF (Log Event Enhanced Format). zSecure Alert and zSecure Audit do a great job providing LEEF (and other format) feeds to the likes of Splunk, QRadar, ArcSight, and others. Here’s an entry point into the zSecure documentation to explain more: https://www.ibm.com/docs/en/szs/3.1.0?topic=deployment-data-preparation-siem To set expectations a bit, even the best z/OS event feed(er), with lots of customization and enrichment options, can only partially help Sumo Logic and its users interpret, correlate, and understand z/OS-specific events. There’s a lot of work that goes into QRadar’s Device Support Modules (DSMs) and AI to understand what’s really happening in z/OS in context, and to display meaningful information to users who don’t necessarily know much about z/OS specifically. So just be prepared to do at least some work to make the feed(s) from z/OS more useful within Sumo Logic — work on both ends. In other words, most of the value in this class of dashboarding and analysis tools is in, well, how much useful analysis they provide. Feeding the tool (even with the best feed) is only part of the story. Metaphorically speaking you could feed hospital-related events to a control center at a steel manufacturer. And that hospital event feed could be the world’s best feed, with lots of enriched data and everything you could ever want to know about what’s happening at the hospital. But a steel manufacturer that understands steel-related events — and maybe also nickel-related, copper-related, and car manufacturing-related events in a pinch — could be bewildered when it receives hospital-related events. True, it’s all English (or some other common language), but what does it mean when there’s a gray alert followed by a pink alert? Are those two events related? And what is a gray alert anyway? Or a pink alert? Answering my own questions, these events could be related. “Gray” means a combative person, and “pink” means an infant abduction. But I didn’t know that until 5 minutes ago. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience?
Steve, to add to what Jerry and Charles have said. I don't have any experience with Sumologic, but I'm going to guess it will need data sent to it in a format it will understand. The place that I retired from was using the BMC product to send data to Splunk. The BMC product allowed us to pick which SMF records to look at and which fields in those records to format and send to Splunk. We ran an agent on several lpars to capture data. One of the SMF record types we looked at was related to RACF information. We also looked at SMF record types related to CICS activity and batch processes. As a side note to Charles. We started out with the product when it was called Correlog. We had looked to several products and went with Correlog. My impression is that it is a nice product. Paul -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Monday, March 4, 2024 7:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience? Thanks for the shout-out, Jerry! (I was the principal developer of said product.) I think BMC now calls the product AMI Defender. (I have no financial interest in BMC or the product.) I am pretty much of an expert on this topic. Feel free to reach out to me off-line if you have any questions. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Monday, March 4, 2024 12:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience? We used a product to send syslog/smf data to splunk called Correlog - since acquired by BMC and I don't know its new same. I don't think you will have any success in doing this without some agent on the mainframe that can extract and then send the data. Jerry Whitteridge Sr Manager Managed Services jerry.whitteri...@albertsons.com 480 578 7889 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Estle Sent: Monday, March 4, 2024 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience? All, We are embarking on an endeavor to explore sending logics to a tool called Sumologic(sumologic.com). For those who are unaware, Sumologic is a competitor to Splunk and contains a very powerful real time log parsing analytics engine which can be used to build dashboards, alerts, and more. My basic question is has anyone heard of or actually been involved in devising ways to send ZOS logs into Sumalogic - our initial efforts will be security related, but for now am just asking if anyone has any experience in this realm at all? Or maybe you are doing something similar to Splunk? If so, you can post in forum or feel free to reach directly out to me: Thanks much, Steve Estle sest...@gmail.com 303-817-9954 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- 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
Re: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience?
Thanks for the shout-out, Jerry! (I was the principal developer of said product.) I think BMC now calls the product AMI Defender. (I have no financial interest in BMC or the product.) I am pretty much of an expert on this topic. Feel free to reach out to me off-line if you have any questions. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Monday, March 4, 2024 12:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience? We used a product to send syslog/smf data to splunk called Correlog - since acquired by BMC and I don't know its new same. I don't think you will have any success in doing this without some agent on the mainframe that can extract and then send the data. Jerry Whitteridge Sr Manager Managed Services jerry.whitteri...@albertsons.com 480 578 7889 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Estle Sent: Monday, March 4, 2024 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience? All, We are embarking on an endeavor to explore sending logics to a tool called Sumologic(sumologic.com). For those who are unaware, Sumologic is a competitor to Splunk and contains a very powerful real time log parsing analytics engine which can be used to build dashboards, alerts, and more. My basic question is has anyone heard of or actually been involved in devising ways to send ZOS logs into Sumalogic - our initial efforts will be security related, but for now am just asking if anyone has any experience in this realm at all? Or maybe you are doing something similar to Splunk? If so, you can post in forum or feel free to reach directly out to me: Thanks much, Steve Estle sest...@gmail.com 303-817-9954 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- 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
Re: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience?
We used a product to send syslog/smf data to splunk called Correlog - since acquired by BMC and I don't know its new same. I don't think you will have any success in doing this without some agent on the mainframe that can extract and then send the data. Jerry Whitteridge Sr Manager Managed Services jerry.whitteri...@albertsons.com 480 578 7889 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Estle Sent: Monday, March 4, 2024 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: ZOS Sending Logs to Sumologic Experience? All, We are embarking on an endeavor to explore sending logics to a tool called Sumologic(sumologic.com). For those who are unaware, Sumologic is a competitor to Splunk and contains a very powerful real time log parsing analytics engine which can be used to build dashboards, alerts, and more. My basic question is has anyone heard of or actually been involved in devising ways to send ZOS logs into Sumalogic - our initial efforts will be security related, but for now am just asking if anyone has any experience in this realm at all? Or maybe you are doing something similar to Splunk? If so, you can post in forum or feel free to reach directly out to me: Thanks much, Steve Estle sest...@gmail.com 303-817-9954 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOS Sending Logs to Sumologic Experience?
Technically, it is not an issue. You can send everything using Rexx (I can supply a sample for syslog). The main issue is converting the input to a format familiar to the syslog parser. In my code I use CEF. So, what are your input sources? ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך יום ב׳, 4 במרץ 2024 ב-20:43 מאת Steve Estle < 05dcac13570d-dmarc-requ...@listserv.ua.edu>: > All, > > We are embarking on an endeavor to explore sending logics to a tool called > Sumologic(sumologic.com). For those who are unaware, Sumologic is a > competitor to Splunk and contains a very powerful real time log parsing > analytics engine which can be used to build dashboards, alerts, and more. > My basic question is has anyone heard of or actually been involved in > devising ways to send ZOS logs into Sumalogic - our initial efforts will be > security related, but for now am just asking if anyone has any experience > in this realm at all? Or maybe you are doing something similar to Splunk? > If so, you can post in forum or feel free to reach directly out to me: > > Thanks much, > > Steve Estle > sest...@gmail.com > 303-817-9954 > > -- > 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
ZOS Sending Logs to Sumologic Experience?
All, We are embarking on an endeavor to explore sending logics to a tool called Sumologic(sumologic.com). For those who are unaware, Sumologic is a competitor to Splunk and contains a very powerful real time log parsing analytics engine which can be used to build dashboards, alerts, and more. My basic question is has anyone heard of or actually been involved in devising ways to send ZOS logs into Sumalogic - our initial efforts will be security related, but for now am just asking if anyone has any experience in this realm at all? Or maybe you are doing something similar to Splunk? If so, you can post in forum or feel free to reach directly out to me: Thanks much, Steve Estle sest...@gmail.com 303-817-9954 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
