It's prudent to periodically review and re-evaluate everything. If the access for a server is consistently wrong then there is a serious problem with the process and I would expect it to surface on other servers. If *any* type of configuration error keeps happening over time then management is asleep at the switch. Once is happenstance, twice is coincidence but three times is enemy action.
-- 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 12:18 PM To: [email protected] Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
