Excellent suggestions for vulnerability categories.
If an exploit uses anonymous FTP wouldn't Anonymous FTP be considered
vulnerable in its current configuration? If not what would you consider
the vulnerability to be? Anonymous FTP + ESM? or ESM? or?
The remediation might be to remove the option of Anonymous FTP OR it
might be to tighten down the security for the files that are available
to the FTP id. Would it be prudent to review or re-evaluate the choice
of Anonymous FTP as part of the remediation process? Maybe? Probably?
Also, what happens if this type of vulnerability keeps happening over
time? Once is just a mistake, but an on-going re-occurring problem may
prompt a re-evaluation of Anonymous FTP.
On 5/28/2019 10:52 AM, Seymour J Metz wrote:
What about personnel-based vulnerabilities, e.g.,
Social engineering
Writing down passwords
insider attacks
Anonymous FTP is not a vulnerability per se; what is a vulnerability is giving
an FTP more access than is appropriate for its role. An anonymous FTP server
should run under a userid that only has access to those datasets that should be
publicly readable.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Ray
Overby <[email protected]>
Sent: Tuesday, May 28, 2019 11:44 AM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.
For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down. For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:
-Configuration based vulnerabilities
* APF authorized data sets not adequately protected
* SMP/E data sets not adequately protected
* FTP anonymous allowed
* FTP JES option allowed
* Outgoing TCPIP traffic not protected
-Code based vulnerabilities
* Storage alteration
* Trap door
* System Instability
To better focus the discussion perhaps the following questions should be
discussed:
Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?
Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?
Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?
On 5/28/2019 9:23 AM, Bill Johnson wrote:
And you sell security services. What do I expect you to say?
Not everything I provided was IBM.
Sent from Yahoo Mail for iPhone
On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach <[email protected]> wrote:
These Are IBM docs. What you expect them to say?
ITschak
בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant <
[email protected]>:
On Tue, 28 May 2019 13:32:35 +0000, Bill Johnson wrote:
If you either didn’t read or didn’t comprehend the posts I provided, I
cannot help you.
As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.
--
Tom Marchant
Sent from Yahoo Mail for iPhone
On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
[email protected]> wrote:
On Mon, 27 May 2019 16:05:33 +0000, Bill Johnson wrote:
Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely
and
stay on it and spend tens of millions for it. I’ve already provided
numerous
links referencing it.
You have provided pitifully little to support your claim that the
security of
mainframes is the reason banks and others stay with them. I have read
all of the references that you posted, and most of them list the
POTENTIAL
to secure them as ONE of the reasons why people use mainframes for
mission-critical data, but not the main reason.
You have over-stated your case.
Add in my criminal justice knowledge along with my computer science
degree and 40 years of experience in IT and security. But don’t let me
dispel your beliefs.
So I shoulodn't question you because you are the expert?
I call BS.
--
Tom Marchant
Sent from Yahoo Mail for iPhone
On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
[email protected]> wrote:
At the risk of re-kicking the already dead horse: Bill, you're
comparing apples and spiders.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
