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
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
>>
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
> >
> 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
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
> 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
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
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,
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
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
> 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
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
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
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,
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
.
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
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
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
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.
19 matches
Mail list logo
