subject:"Malicious Software Protection"

In
,
on 03/29/2012
   at 09:57 PM, jan de decker  said:

>There are zillions of ways to hack a zOS system.

Perhaps, but the ones that you describe are due to insider negligence,
not to flaws in z/OS itself.

>I think we will all agree that the cornerstone of zOS security is
>the status of the PSW key and supervisor state bits.

No, the cornerstone is resource control, and the PSW fileds are just a
small piece of that.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread Barry Merrill

One of your postings reminded me of Pat Artis' statement:

The difference between a Feature and a Benefit:
A Feature is when your wife/girlfriend has large breasts.
A Benefit is when she lets you touch them.

Barry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread jan de decker

a bHi list,

There are zillions of ways to hack a zOS system. I do agree that when
everything is secured, it is not possible by the very nature of zOS, On the
other hand, during my 25+ years as a free lance MVS systems programmer I
never worked on a mainframe site I could not hack easily, starting with a
vanilla userid.

I think we will all agree that the cornerstone of zOS security is the
status of the PSW key and supervisor state bits. We can change these
through for example SVC's, PC', what most auditors like because it is
somewhere on their list, just like the everlasting question about I/O
appendages, etc. Their question about the PPT also annoys me the most. A
program only has the attributes assigned to it from the PPT if it comes
from an APF library. If it is APF, you do not need the PPT. A simple logic
apparently impossible to explain to $millions a day auditors.

Let us focus on APF. Just some minor remarks0 if you can have it:

You can give yourself RACF SPECIAL without RACF knowing it by changing a
bit in the ACEE, same goes for OPERATIONS.
You can give yourself access to anything that is RACF protected by pointing
the RACF exits to your own coding, making an exception for your user id.
You can switch off RACF & SMF logging.
You can hide some SVC prefixing code in a SMP/E usermodification so that it
will be replicated to the next release by a systems programmer who has not
examined the assembler coding.

So, how to get there with a vanilla userid?

You loose APF it when your address space becomes dirty. This is annoying.
Lots of sides have home written authorisation SVC's hanging around.
Everybody can examine the SVC table, eliminate the genuine IBM ones, and
disassemble the others. My experience hit rate 40%.
Systems programmers have UPDATE access to APF libraries.
Execution of group logon Rexx or CLIST (SYSTEM) followed by (VANILLA) is
not exceptional. Change to a copy of your module to an APF one. My
experience hit rate 25%.

Ask a systems programmer to debug a Rexx. Ask for his wisdom. Go to his
desk and let him examine a Rexx exec with an error which he clearly
recognizes as a typical idiot symptom. He will demonstrate you that it
works now, thanks to his superior brain. Hide a copy of one of assembler
modules to an APF library somewhere in an unreadable interpret instruction
at the end.

I could go on.

Other classic: are all STC's PROTECTED? If not, you can try DOS by logon
with the STC userid.

2011 Id did a real system integrity audit and found 19176 security holes of
the nature mentioned above without looking very deeply. This was a small
mainframe.

I once started a book about this but stopped because I could not find a
publisher interested in zOS. Perhaps I will take it up again. I concluded
the draft with (joke) a beastly number of questions, 666.

Good night from Brussels (at the time of posting).

j@n

On Thu, Mar 29, 2012 at 4:54 PM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In <2417378497678577.wa.woodagozemail.com...@bama.ua.edu>, on
> 03/28/2012
>at 02:37 PM, Andy Wood  said:
>
> >The problems were usually coding errors of the nature of the R13 STM
> >as described by Ray, however there were even deliberate "backdoors".
>
> Those are defects[1] in the product, not in z/OS. As Walt and others
> have repeatedly written, your security is only as good as what you
> allow in your authorized libraries.
>
> >Such backdoors may have  included some sort of checking to try to
> >prevent misuse,
>
> They almost invariably do, and almost invariably the checking is
> inadequate :-(
>
> [1] Yes, defects, not features.
>
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In
<77142d37c0c3c34da0d7b1da7d7ca3485...@nwt-s-mbx1.rocketsoftware.com>,
on 03/29/2012
   at 04:16 PM, Bill Fairchild  said:

>I believe Shmuel meant   05F0   instead of  07F0.

Yes. Also, I didn't mention that the 05F0 is not necessary if the
0A90C is at the entry point.

>These two will result in a system wait state ABEND on any OS/360
>variant (PCP, MFT, MVT) after all SQA is gobbled up and then the
>infinite loop wants some more.

Also SVS. Fixed in OS/VS1 and in MVS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In <4f748727.1020...@bremultibank.com.pl>, on 03/29/2012
   at 06:00 PM, "R.S."  said:

>BTW: all the stories like "I could tell you if I could, but I
>couldn't"  sounds like urban legends. I'm sorry, but in such case 
>I prefer knowledge over belief.

I reported one of those, but it's been closed[1] for a long time, so
they'd no longer have to shoot me.

[1] If the sysadmin is doing his job.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In <4f736006.7070...@ix.netcom.com>, on 03/28/2012
   at 03:01 PM, Bob Rutledge  said:

>BCR  15,0? 

Typo. That should have been

BALR  R15,0
SVC   12

They say that the mind is the second thing to go.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In <2417378497678577.wa.woodagozemail.com...@bama.ua.edu>, on
03/28/2012
   at 02:37 PM, Andy Wood  said:

>The problems were usually coding errors of the nature of the R13 STM
>as described by Ray, however there were even deliberate "backdoors".

Those are defects[1] in the product, not in z/OS. As Walt and others
have repeatedly written, your security is only as good as what you
allow in your authorized libraries.

>Such backdoors may have  included some sort of checking to try to
>prevent misuse,

They almost invariably do, and almost invariably the checking is
inadequate :-(

[1] Yes, defects, not features.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In <6703125624441206.wa.paulgboulderaim@bama.ua.edu>, on
03/28/2012
   at 04:39 PM, Paul Gilmartin  said:

>It's easy.  Bribe the sysadmin.  (FSVO "access".)

After I tell my security officer[1] and he sets up the sting with the
authorities, do I get to get the bribe? If not, do I at least get a
photo of the offendor's face when they catch him?

[1] Or follow whatever alternate procedure was prescribed during
my security briefing.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread McKown, John

I'm fairly sure that z/OS keeps the TCBs in LSQA. So the address space will 
likely abend, but not the system.

John McKown 

Systems Engineer IV

IT

 

Administrative Services Group

 

HealthMarkets(r)

 

9151 Boulevard 26 * N. Richland Hills * TX 76010

(817) 255-3225 phone * 

john.mck...@healthmarkets.com * www.HealthMarkets.com

 

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Fairchild
> Sent: Thursday, March 29, 2012 11:16 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> I believe Shmuel meant   05F0   instead of  07F0.
> Disassembled, it would read
>  BALR  R15,0
>  SVC   12  [also known as the SYNCH macro]
> 
> These two will result in a system wait state ABEND on any 
> OS/360 variant (PCP, MFT, MVT) after all SQA is gobbled up 
> and then the infinite loop wants some more.  I haven't tried 
> it yet on my z/OS system.  Don't have time.
> 
> Bill
> 
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bob Rutledge
> Sent: Wednesday, March 28, 2012 2:01 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> Shmuel Metz (Seymour J.) wrote:
> > 
> > Nonsense. OS/360 was a swiss cheese.
> > 
> >  07F0
> >  0A0C
> 
> BCR  15,0?  Was serialization required?
> 
> Bob
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread Bill Fairchild

I believe Shmuel meant   05F0   instead of  07F0.
Disassembled, it would read
 BALR  R15,0
 SVC   12  [also known as the SYNCH macro]

These two will result in a system wait state ABEND on any OS/360 variant (PCP, 
MFT, MVT) after all SQA is gobbled up and then the infinite loop wants some 
more.  I haven't tried it yet on my z/OS system.  Don't have time.

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Bob Rutledge
Sent: Wednesday, March 28, 2012 2:01 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Malicious Software Protection

Shmuel Metz (Seymour J.) wrote:
> 
> Nonsense. OS/360 was a swiss cheese.
> 
>  07F0
>  0A0C

BCR  15,0?  Was serialization required?

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread Bob Rutledge


Shmuel Metz (Seymour J.) wrote:


Nonsense. OS/360 was a swiss cheese.

 07F0
 0A0C 


BCR  15,0?  Was serialization required?

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread R.S.

W dniu 2012-03-29 14:19, Chris Craddock pisze:

On Mar 28, 2012, at 4:13 PM, "R.S." wrote:

The problem is we don't believe. :-)

W dniu 2012-03-28 22:45, Ray Overby pisze:

Yes, I believe I have a way to attack a mainframe system where I don't
have access.

Then would you believe me?

No.
I would believe when I see the proof. *Documented case*.
I don't claim z/OS is bulletproof, I say there is no *known* method to
hack it. I don't preclude the holes, I also know indirect proofs the
holes do happen: "integrity" APARs. Oh, I preclude all the cases where
the hole exist because system administrator did not do his job.

BTW: all the stories like "I could tell you if I could, but I couldn't"
sounds like urban legends. I'm sorry, but in such case I prefer
knowledge over belief.

Regards
--
Radoslaw Skorupka
Lodz, Poland

P.S. Disclaimer: no offence intended, nothing personal.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread Tom Marchant

On Thu, 29 Mar 2012 07:41:20 -0500, Steve Dover wrote:

>I wish listservers had a "like" button similar to Facebook 
>and such.  I would "like" this comment.

I don't.  And I wouldn't.  Every time you visit a page with 
a Facebook "like", your movements are tracked.  For more 
information about this, see 
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1717563 

It is apt that this comment would be made in a thread about 
malicious software.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread Steve Dover

I wish listservers had a "like" button similar to Facebook and such.  I would 
"like" this comment.
Steve

On Wed, 28 Mar 2012 07:33:44 -0500, McKown, John 
 wrote:

>Of course not! Most auditors that I've had the misfortune to interact with 
>directly are like politicians. They have the "bright ideas" based on 
>"fundamental truths". But if they don't work, it's because the people who 
>implemented them (us) are idiots and incompetents.
>
>--
>John McKown
>Systems Engineer IV
>IT
>
>Administrative Services Group
>
>HealthMarkets(r)
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread Chris Craddock

On Mar 28, 2012, at 4:13 PM, "R.S."  wrote:

> The problem is we don't believe. :-)
> 
> W dniu 2012-03-28 22:45, Ray Overby pisze:
>> Yes, I believe I have a way to attack a mainframe system where I don't
>> have access.

Then would you believe me?

In the days before ubiquitous networking you would have been safe not do 
believe. Today I think you would be foolish not to believe. The proof is a 
thought experiment that I could walk you through, but I won't because I don't 
think it is wise to shout out the location of my neighbor's front door keys, 
even if he is foolish enough to leave them under the mat. It is the reason why 
I keep harping on about integrity violations.

Suffice to say that more sophisticated malware attacks in the real world like 
Stuxnet have proven conclusively that patience and a broad based approach can 
pay dividends even  in some of the most supposedly secure sites in the world. 
And if through that slow patient attack, you manage to get some code running on 
a z/OS system, THEN... even if that code is utterly non-privileged, it is quite 
easy to find and exploit integrity violations locally. And the world is your 
oyster. 

So it really isn't like on TV where the brainiac agents are always cracking 
firewall encryption in five minutes. But with the right kind of approach, they 
don't need to. And if they can do some human insider trading, then it is even 
easier. 

Bottom line: if you think your systems are really secure, you're probably nuts. 
Far more likely it's just that nobody has (yet) paid attention. Sorry. 

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread McKown, John

But, is he an honest sysadmin? I.e. does he stay bribed?

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Wednesday, March 28, 2012 4:39 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> On Wed, 28 Mar 2012 23:13:58 +0200, R.S. wrote:
> 
> >The problem is we don't believe. :-)
> >
> It's easy.  Bribe the sysadmin.  (FSVO "access".)
> 
> >W dniu 2012-03-28 22:45, Ray Overby pisze:
> >> Yes, I believe I have a way to attack a mainframe system 
> where I don't
> >> have access.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-29 Thread Elardus Engelbrecht

R.S. wrote:

>W dniu 2012-03-28 23:39, Paul Gilmartin pisze:
>> On Wed, 28 Mar 2012 23:13:58 +0200, R.S. wrote:
>>> The problem is we don't believe. :-)
>> It's easy.  Bribe the sysadmin.  (FSVO "access".)
>That's what I always mention. Bribe or blackmail. The last one is much more 
>efficient IMHO, but both used to work.

H, what did I said about *insiders*? ;-D

{ Side Note FYI: There is a thread now running on RACF-L about how long you 
should keep security logs. }

Thanks Ray Overby for your kind reply! This is what I suspected anyways. Those 
'penetration teams' need to have bread and butter on the table... :-D

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread R.S.

W dniu 2012-03-28 23:39, Paul Gilmartin pisze:

On Wed, 28 Mar 2012 23:13:58 +0200, R.S. wrote:

The problem is we don't believe. :-)

It's easy. Bribe the sysadmin. (FSVO "access".)

That's what I always mention. Bribe or blackmail. The last one is much
more efficient IMHO, but both used to work.

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread Paul Gilmartin

On Wed, 28 Mar 2012 23:13:58 +0200, R.S. wrote:

>The problem is we don't believe. :-)
>
It's easy.  Bribe the sysadmin.  (FSVO "access".)

>W dniu 2012-03-28 22:45, Ray Overby pisze:
>> Yes, I believe I have a way to attack a mainframe system where I don't
>> have access.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread Scott Ford

Walt,

May the wind be at your back...god bless enjoy your much earned retirement

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 28, 2012, at 8:28 AM, Walt Farrell  wrote:

> On Tue, 27 Mar 2012 11:09:23 -0700, Skip Robinson  
> wrote:
> 
>> The reason I brought up this 'vulnerability' is that we hired a consultant
>> a while back to look for weaknesses. Of course they were able to logon
>> with a vanilla userid that had no special authority. And this is what they
>> did.
>> 
>> We all spend a lot of time and mental energy focused on how to protect
>> ourselves from sophisticated attack. We look at APF. We look at SVC
>> screening. We look at access to sensitive libraries. But this particular
>> 'denial of service' can be accomplished by anyone with a valid userid and
>> password. And *only* because we lock up users for invalid password
>> attempts. I'm just sayin'...
> 
> It's just another form of disaster you have to plan for, Skip.
> 
> It's easy, for example, to setup an STC that runs with an ID that has 
> SPECIAL, or that is the OWNER of some IDs that have SPECIAL, and have that 
> STC run IKJEFT01 and issue ALTUSER ... RESUME for one or more other IDs that 
> have SPECIAL.
> 
> If they all get locked out, you just run the STC and that set of IDs is 
> RESUMED. 
> 
> The STC itself will be able to run, even if its ID has been revoked, and so 
> it provides protection against the issue you're suggesting.
> 
> But yes, you need to be prepared for this, just as for anything that can 
> compromise your system.
> 
> (Other alternatives exist, by the way, including emergency copies of the RACF 
> database that you can make available in such an emergency situation, but the 
> STC approach is the simplest, in my opinion. Nonetheless, I would also 
> recommend having an emergency RACF DB available, too, but that also goes 
> along with having emergency system residence volumes available.)
> 
> -- 
> Walt Farrell
> IBM STSM, z/OS Security Design (for another half-hour or so)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread McKown, John

Just remember: "The only secure computer is the one which is powered down." And 
likely smashed up by a sledge hammer. 

John McKown 

Systems Engineer IV

IT

 

Administrative Services Group

 

HealthMarkets®

 

9151 Boulevard 26 . N. Richland Hills . TX 76010

(817) 255-3225 phone . 

john.mck...@healthmarkets.com . www.HealthMarkets.com

 

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S.
> Sent: Wednesday, March 28, 2012 4:14 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> The problem is we don't believe. :-)
> 
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> W dniu 2012-03-28 22:45, Ray Overby pisze:
> > Yes, I believe I have a way to attack a mainframe system 
> where I don't
> > have access.
> >
> >
> > Ray Overby
> > Key Resources, Inc.
> > Ensuring System Integrity for z/SeriesT
> > www.zassure.com
> > (312)574-0007
> >
> >
> > On 3/28/2012 02:03 AM, Elardus Engelbrecht wrote:
> >> Ray Overby wrote:
> >>
> >>> I am a vendor so take my post with a grain of salt. For those that
> >>> don't like vendors to respond stop reading now.. (flame on)
> >> I will take your post seriously. I have reviewed you webpage. Very
> >> interesting.
> >>
> >> You confirmed what I suspected, especially after those 
> threads about
> >> [mis]use of SVC.
> >>
> >> One question if you don't mind please:
> >>
> >> Can you use or prove your point (elevating TSO, suppress SMF, etc)
> >> without being given access to a system in the first place? 
> The idea is
> >> that you could enter a system and elevate yourself and 
> place somewhere
> >> a signature to prove that you could 'white hack' the target system.
> >>
> >> Just a yes or no, please, because I realize that due to 
> the nature not
> >> too much info can be divulged.
> >>
> >>
> >>> The ESM products did not stop the TSO user from exploiting this
> >>> vulnerability.
> >> Very true. ESM is just a database.
> >>
> >> As said many times on RACF-L, it is the caller which call 
> ESM, the ESM
> >> decides on what is found in its own database and report back with
> >> RC=0/4/8 plus reason codes.
> >>
> >> It is up to the whatever caller to honour the RC from an ESM.
> >>
> >>
> >>> If you are not concerned that your users can crash your 
> z/OS system
> >>> at any time (maliciously or accidentally)
> >> As I have said, it is the INSIDER who are probably the 
> greatest threat.
> 
> 
> --
> Tre tej wiadomoci moe zawiera informacje prawnie 
> chronione Banku przeznaczone wycznie do uytku subowego 
> adresata. Odbiorc moe by jedynie jej adresat z wyczeniem 
> dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej 
> wiadomoci lub pracownikiem upowanionym do jej przekazania 
> adresatowi, informujemy, e jej rozpowszechnianie, 
> kopiowanie, rozprowadzanie lub inne dziaanie o podobnym 
> charakterze jest prawnie zabronione i moe by karalne. 
> Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
> zawiadomi nadawc wysyajc odpowied oraz trwale usun t 
> wiadomo wczajc w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the 
> Bank and is intended solely for business use of the 
> addressee. This e-mail may only be received by the addressee 
> and may not be disclosed to any third parties. If you are not 
> the intended addressee of this e-mail or the employee 
> authorised to forward it to the addressee, be advised that 
> any dissemination, copying, distribution or any other similar 
> activity is legally prohibited and may be punishable. If you 
> received this e-mail by mistake please advise the sender 
> immediately by using the reply facility in your e-mail 
> software and delete permanently this e-mail including any 
> copies of it either printe

Re: Malicious Software Protection

2012-03-28 Thread R.S.

The problem is we don't believe. :-)

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-03-28 22:45, Ray Overby pisze:

Yes, I believe I have a way to attack a mainframe system where I don't
have access.

Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series™
www.zassure.com
(312)574-0007

On 3/28/2012 02:03 AM, Elardus Engelbrecht wrote:

Ray Overby wrote:

I am a vendor so take my post with a grain of salt. For those that
don't like vendors to respond stop reading now.. (flame on)

I will take your post seriously. I have reviewed you webpage. Very
interesting.

You confirmed what I suspected, especially after those threads about
[mis]use of SVC.

One question if you don't mind please:

Can you use or prove your point (elevating TSO, suppress SMF, etc)
without being given access to a system in the first place? The idea is
that you could enter a system and elevate yourself and place somewhere
a signature to prove that you could 'white hack' the target system.

Just a yes or no, please, because I realize that due to the nature not
too much info can be divulged.

The ESM products did not stop the TSO user from exploiting this
vulnerability.

Very true. ESM is just a database.

As said many times on RACF-L, it is the caller which call ESM, the ESM
decides on what is found in its own database and report back with
RC=0/4/8 plus reason codes.

It is up to the whatever caller to honour the RC from an ESM.

If you are not concerned that your users can crash your z/OS system
at any time (maliciously or accidentally)

As I have said, it is the INSIDER who are probably the greatest threat.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread Ray Overby

Yes, I believe I have a way to attack a mainframe system where I don't 
have access.



Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series™
www.zassure.com
(312)574-0007


On 3/28/2012 02:03 AM, Elardus Engelbrecht wrote:

Ray Overby wrote:


I am a vendor so take my post with a grain of salt. For those that don't like 
vendors to respond stop reading now.. (flame on)

I will take your post seriously. I have reviewed you webpage. Very interesting.

You confirmed what I suspected, especially after those threads about [mis]use 
of SVC.

One question if you don't mind please:

Can you use or prove your point (elevating TSO, suppress SMF, etc) without 
being given access to a system in the first place? The idea is that you could 
enter a system and elevate yourself and place somewhere a signature to prove 
that you could 'white hack' the target system.

Just a yes or no, please, because I realize that due to the nature not too much 
info can be divulged.



The ESM products did not stop the TSO user from exploiting this vulnerability.

Very true. ESM is just a database.

As said many times on RACF-L, it is the caller which call ESM, the ESM decides 
on what is found in its own database and report back with RC=0/4/8 plus reason 
codes.

It is up to the whatever caller to honour the RC from an ESM.



If you are not concerned that your users can crash your z/OS system at any time 
(maliciously or accidentally)

As I have said, it is the INSIDER who are probably the greatest threat.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread Andy Wood

On Wed, 28 Mar 2012 07:29:22 -0400, Shmuel Metz (Seymour J.) 
 wrote:

. . .
>
>That's only a vulnerability if such an SVC exists. You haven't shown
>that. No SVC in z/OS that I'm aware of has such an STM. It would
>certainly violate IBM's statement of integrity.
>

I have seen such an SVC, but it would not be the one Ray is talking about as it 
was locally written. I have no doubt other SVCs with the same problem exist, 
and it would not surprise me at all if some of them were vendor-supplied.

Over a period of about twenty years I found dozens of problems like that. 
Practically all of them were in software provided by the "who's who" of 
mainframe software  the guys most of you would call "trusted vendors". 

The problems were often in SVC routines, or more specifically in the SVC 
"frontends" that could be found stacked waist-high on a typical system. 

The problems were usually coding errors of the nature of the R13 STM as 
described by Ray, however there were even deliberate "backdoors".  For example, 
"magic" SVCs that could return control to the caller in supervisor state, or 
with JSCBAUTH turned on. Such backdoors may have  included some sort of 
checking to try to prevent misuse, but more often than not the checking could 
be defeated. Trust me, telling the "good guys" from the "bad guys" is very 
difficult when the bad guys refuse to cooperate. There was a problem of that 
nature in an early version of a certain IGX... module mentioned in a recent 
thread here.

Of course, the problem is not restricted to SVC routines. I found similar 
issues all over the place.

I have not done anything like that for over ten years now. Does that mean the 
problem has gone away? I doubt it, even though the last ten years has brought 
some improvements (for example, preventing allocation of user-key CSA by 
default). 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread J R

Farewell Walt.  Thanks for the memories.  

Was this your "Last Post"?  (In the British military sense; ie. "Taps" to most 
on this list.)  

===
 > Date: Wed, 28 Mar 2012 07:28:58 -0500
> From: wfarr...@us.ibm.com
> Subject: Re: Malicious Software Protection
> To: IBM-MAIN@bama.ua.edu
> 
> On Tue, 27 Mar 2012 11:09:23 -0700, Skip Robinson  
> wrote:
> 
> >The reason I brought up this 'vulnerability' is that we hired a consultant
> >a while back to look for weaknesses. Of course they were able to logon
> >with a vanilla userid that had no special authority. And this is what they
> >did.
> >
> >We all spend a lot of time and mental energy focused on how to protect
> >ourselves from sophisticated attack. We look at APF. We look at SVC
> >screening. We look at access to sensitive libraries. But this particular
> >'denial of service' can be accomplished by anyone with a valid userid and
> >password. And *only* because we lock up users for invalid password
> >attempts. I'm just sayin'...
> 
> It's just another form of disaster you have to plan for, Skip.
> 
> It's easy, for example, to setup an STC that runs with an ID that has 
> SPECIAL, or that is the OWNER of some IDs that have SPECIAL, and have that 
> STC run IKJEFT01 and issue ALTUSER ... RESUME for one or more other IDs that 
> have SPECIAL.
> 
> If they all get locked out, you just run the STC and that set of IDs is 
> RESUMED. 
> 
> The STC itself will be able to run, even if its ID has been revoked, and so 
> it provides protection against the issue you're suggesting.
> 
> But yes, you need to be prepared for this, just as for anything that can 
> compromise your system.
> 
> (Other alternatives exist, by the way, including emergency copies of the RACF 
> database that you can make available in such an emergency situation, but the 
> STC approach is the simplest, in my opinion. Nonetheless, I would also 
> recommend having an emergency RACF DB available, too, but that also goes 
> along with having emergency system residence volumes available.)
> 
> -- 
> Walt Farrell
> IBM STSM, z/OS Security Design (for another half-hour or so)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread Bill Fairchild

Ask the auditors, and/or hire an independent research consultant specializing 
in mainframe security, to find some published accounts of mainframe penetration 
that were NOT due to insiders; e.g., viruses.  Print your own copy of all such 
accounts.  Study them closely to see where the real weakness was.  Over the 
years I have heard of several mainframe penetrations and usurpations, but they 
were all due to insider activity.  The first one I heard about, however, was an 
outsider who found program listings in a trash can outside of the data center's 
building, which had been tossed there by developers inside the building and/or 
janitors at night.  The listings were not considered worth securing or 
shredding.  The perp went to prison for a while, then after being released he 
turned into a mainframe security consultant.  There are many things to consider 
besides anti-virus detections; e.g. who has keys to the data center room, to 
any of the offices containing terminals, logon passw!
 ord protection, etc.  Maybe the auditors have already checked out all these 
other areas, are just trying to be comprehensive, and do not understand that 
one size does not fit all.

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Greg Dorner
Sent: Tuesday, March 27, 2012 11:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Malicious Software Protection

No,. I'm not serious. But the auditors at PWC are.  I'm practicing my 
belly-laugh for when they actually want to discuss the issue. You are all 
telling me what I already knew, but I just wanted to get the feedback so it 
isn't just my understanding of it. 


Thanks everyone, for all the good quotes, quips, and entertainment!

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread David Cole


At 3/27/2012 04:06 PM, Joel C. Ewing wrote:
The concept of allowing average-Joe user to be able to download data 
from arbitrary sources in arbitrary formats and being able from that 
to somehow introduce executable code into the system in ways that 
will execute with special privileges so as to introduce a virus or 
trojan is an issue that is endemic to Windows platforms but foreign to z/OS.


Hmmm, excellent point!

I guess part of the problem with Windows systems is that there are so 
many file types that in one way or another are executables, including 
many file type that you do not expect to be executable! Example: I 
was blown away when I learned only a few years ago that .PDFs could 
be an executable! Who knew? Not me. But the Chinese did... (It was 
interesting to see the flurry of fixes that Adobe published over the 
two years or so following the attack against Google...)


Not only are so many file types executable, they often are executed 
by default! So it is a lot easier to let something maliscious slip in 
on a Windows system than it is on a mainframe.


On mainframes files generally do not get executed by default. It 
generally takes an intentional and direct act to run a program. So 
worrying about random files upload to the mainframe is an unnecessary 
distraction.


Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread Sam Siegel

Walt - good luck in retirement. 

Love the final signature line.

Sam
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Walt Farrell 
Sender: IBM Mainframe Discussion List 
Date: Wed, 28 Mar 2012 07:28:58 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Malicious Software Protection

On Tue, 27 Mar 2012 11:09:23 -0700, Skip Robinson  
wrote:

>The reason I brought up this 'vulnerability' is that we hired a consultant
>a while back to look for weaknesses. Of course they were able to logon
>with a vanilla userid that had no special authority. And this is what they
>did.
>
>We all spend a lot of time and mental energy focused on how to protect
>ourselves from sophisticated attack. We look at APF. We look at SVC
>screening. We look at access to sensitive libraries. But this particular
>'denial of service' can be accomplished by anyone with a valid userid and
>password. And *only* because we lock up users for invalid password
>attempts. I'm just sayin'...

It's just another form of disaster you have to plan for, Skip.

It's easy, for example, to setup an STC that runs with an ID that has SPECIAL, 
or that is the OWNER of some IDs that have SPECIAL, and have that STC run 
IKJEFT01 and issue ALTUSER ... RESUME for one or more other IDs that have 
SPECIAL.

If they all get locked out, you just run the STC and that set of IDs is 
RESUMED. 

The STC itself will be able to run, even if its ID has been revoked, and so it 
provides protection against the issue you're suggesting.

But yes, you need to be prepared for this, just as for anything that can 
compromise your system.

(Other alternatives exist, by the way, including emergency copies of the RACF 
database that you can make available in such an emergency situation, but the 
STC approach is the simplest, in my opinion. Nonetheless, I would also 
recommend having an emergency RACF DB available, too, but that also goes along 
with having emergency system residence volumes available.)

-- 
Walt Farrell
IBM STSM, z/OS Security Design (for another half-hour or so)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread McKown, John

Of course not! Most auditors that I've had the misfortune to interact with 
directly are like politicians. They have the "bright ideas" based on 
"fundamental truths". But if they don't work, it's because the people who 
implemented them (us) are idiots and incompetents.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Tuesday, March 27, 2012 8:09 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> In <2664962449864714.wa.gdornerwpsic@bama.ua.edu>, on 03/27/2012
>at 10:06 AM, Greg Dorner  said:
> 
> >Our auditors are insisting that we install a product that protects
> >against malicious software (viruses, worms, trojans, etc.).
> 
> What are the politics? Are the auditors willing to assume liability if
> the hypothetical package is itself a security problem?
>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread Walt Farrell

On Tue, 27 Mar 2012 11:09:23 -0700, Skip Robinson  
wrote:

>The reason I brought up this 'vulnerability' is that we hired a consultant
>a while back to look for weaknesses. Of course they were able to logon
>with a vanilla userid that had no special authority. And this is what they
>did.
>
>We all spend a lot of time and mental energy focused on how to protect
>ourselves from sophisticated attack. We look at APF. We look at SVC
>screening. We look at access to sensitive libraries. But this particular
>'denial of service' can be accomplished by anyone with a valid userid and
>password. And *only* because we lock up users for invalid password
>attempts. I'm just sayin'...

It's just another form of disaster you have to plan for, Skip.

It's easy, for example, to setup an STC that runs with an ID that has SPECIAL, 
or that is the OWNER of some IDs that have SPECIAL, and have that STC run 
IKJEFT01 and issue ALTUSER ... RESUME for one or more other IDs that have 
SPECIAL.

If they all get locked out, you just run the STC and that set of IDs is 
RESUMED. 

The STC itself will be able to run, even if its ID has been revoked, and so it 
provides protection against the issue you're suggesting.

But yes, you need to be prepared for this, just as for anything that can 
compromise your system.

(Other alternatives exist, by the way, including emergency copies of the RACF 
database that you can make available in such an emergency situation, but the 
STC approach is the simplest, in my opinion. Nonetheless, I would also 
recommend having an emergency RACF DB available, too, but that also goes along 
with having emergency system residence volumes available.)

-- 
Walt Farrell
IBM STSM, z/OS Security Design (for another half-hour or so)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In <2664962449864714.wa.gdornerwpsic@bama.ua.edu>, on 03/27/2012
   at 10:06 AM, Greg Dorner  said:

>Our auditors are insisting that we install a product that protects
>against malicious software (viruses, worms, trojans, etc.).

What are the politics? Are the auditors willing to assume liability if
the hypothetical package is itself a security problem?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In <4f720628.8070...@bremultibank.com.pl>, on 03/27/2012
   at 08:25 PM, "R.S."  said:

>- there are no viruses, trojans or other malware for z/OS and it 
>have never been last 47 years.

Nonsense. OS/360 was a swiss cheese.

 07F0
 0A0C 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In <4f72714f.50...@kr-inc.com>, on 03/27/2012
   at 09:02 PM, Ray Overby  said:

>There are many reasons for these types of defects. The 
>programmer(s) in  these cases to the best of my knowledge were 
>actually very experienced z/OS developers.

Yes, but did they learn anything from their experience. I'm with
Gerhard; that code should never have gotten past code review and casts
serious doubts on the competence of the author.

>Very competent people.

Not if they write code such as you described.

>Even then it only takes a single "error"

Why the quotes? It *is* an error, and a serious one.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In
,
on 03/28/2012
   at 04:20 PM, "Mark Douglas (CITEC)" 
said:

>That Xmas EXEC story was still hot news at IBM Sydney in Christmas
>1989. They warned us not to code such inadvertent viruses (pardon,
>virii) despite the best of intentions by its author.

It was a worm rather than a virus.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

In <4f724ce6.9030...@kr-inc.com>, on 03/27/2012
   at 06:27 PM, Ray Overby  said:

>Lets say there is a SVC that when you IPL your z/OS system it is 
>installed and available for use (i.e - any one can issue the SVC).
>The  SVC either came with z/OS or your system programmers installed
>it  because of an ISV product your company purchased or its an
>in-house  written program. For this example lets assume one of your
>TSO users will  attempt to exploit this vulnerability.

You're begging the question; you haven't mentioned a vulberability
yet.

>Like any SVC when invoked it will get control in an authorized state
> (PSW Key 0). Further this SVC issues a STM instruction very early
>in the SVC code storing into where ever R13 points to.

That's only a vulnerability if such an SVC exists. You haven't shown
that. No SVC in z/OS that I'm aware of has such an STM. It would
certainly violate IBM's statement of integrity.

>This type of defect is easily exploited

Only if it exists.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-28 Thread Elardus Engelbrecht

Ray Overby wrote:

>I am a vendor so take my post with a grain of salt. For those that don't like 
>vendors to respond stop reading now.. (flame on)

I will take your post seriously. I have reviewed you webpage. Very interesting.

You confirmed what I suspected, especially after those threads about [mis]use 
of SVC.

One question if you don't mind please:

Can you use or prove your point (elevating TSO, suppress SMF, etc) without 
being given access to a system in the first place? The idea is that you could 
enter a system and elevate yourself and place somewhere a signature to prove 
that you could 'white hack' the target system.

Just a yes or no, please, because I realize that due to the nature not too much 
info can be divulged.

>The ESM products did not stop the TSO user from exploiting this vulnerability. 

Very true. ESM is just a database.

As said many times on RACF-L, it is the caller which call ESM, the ESM decides 
on what is found in its own database and report back with RC=0/4/8 plus reason 
codes.

It is up to the whatever caller to honour the RC from an ESM.

>If you are not concerned that your users can crash your z/OS system at any 
>time (maliciously or accidentally)

As I have said, it is the INSIDER who are probably the greatest threat.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Elardus Engelbrecht

Russell Witt wrote:

>To the list of 11 items that Elardus supplied earlier in the day, I would add 
>one more. 

[... snipped ...]

Thanks for correcting + adjusting my item. Much appreciated.

I have added it to my list of things to remember.

Please keep up with your valuable posts. :-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread R.S.

Yes, we know, you're a vendor.
Please name few the most popular viruses for z/OS and two-three AV
programs for z/OS. ;-)))

"Intergrity vulnerability" - also, please name few popular, please omit
those which stem from administrator mistakes.

The integrity vulnerabilities *could* lead to viruses which would
exploit such vulnerabilities. In other words no vulnerabilities - no
malware, but existence of the hole does not imply existence of virus
exploiting that hole.
Last but not least: AV software is for virus finding, not for hole
clogging. Yes, today AV suites do contain additional modules, even
"parent control filters" or firewalls, but we don't talk about such
software.

I sustain my opinion: it is not mainframe problem. People who demand
non-existent software to be present are not mainframe problem.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-03-28 00:11, Ray Overby pisze:

Every z/os system today has integrity vulnerabilities on it that if
exploited would allow users with access to that system to crash that
system or bypass installation controls and access any protected resource
on that system regardless of the installed ESM. They would be able to do
so with little to no audit trail.

What part of this is not a mainframe problem?

Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007

On 3/27/2012 13:25 PM, R.S. wrote:

W dniu 2012-03-27 17:06, Greg Dorner pisze:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects
against malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is
coming out with a z/OS product "later this year", but I called them
and they had no idea what I was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!)
should not have to worry about such things, at least that's what I've
always heard.

Any input on this topic would be GREATLY appreciated!!

This is NOT mainframe problem.

Indeed, you have problem with uneducated auditors. Maybe stupid ones.
Your problem is how to prove that requirement is both stupid and
impossible to fulfill.

We can provide you some arguments, like
- there are no such products
- there are no viruses, trojans or other malware for z/OS and it have
never been last 47 years. (I said 'z/OS', so the only VM worm does not
count)
- no mainframe installation use such product
- you have RACF *SECURITY SERVER* (or TS or ACF2)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Mark Douglas (CITEC)

That Xmas EXEC story was still hot news at IBM Sydney in Christmas 1989. They 
warned us not to code such inadvertent viruses (pardon, virii) despite the best 
of intentions by its author.

Cheers,
MARK DOUGLAS 
Senior IT Support Consultant
Mainframe

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Anne & Lynn Wheeler
Sent: Wednesday, 28 March 2012 2:21 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Malicious Software Protection

scott_j_f...@yahoo.com (Scott Ford) writes:
> You can't be serious...never never heard of anyone developing a virus
> for mainframes, I understand the fear, but firewalls, network apps do
> rat in front of the mainframe

this discussion group, mailing list originated on BITNET ... recent
discussion (with wiki references)
http://www.garlic.com/~lynn/2012e.html#19 Inventor of e-mail honored by 
Smithsonian

really long winded recent post in linkedin MainframeZone group
http://www.garlic.com/~lynn/2012d.html#49 Do you know where all your sensitive 
data is located?

mentions the "xmas" exec nov1987 ... reference from vmshare archive
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB

was almost exactly a year before the morris worm on the internet.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

* Disclaimer *

The contents of this electronic message and any attachments are intended only 
for the addressee and may contain privileged or confidential information. They 
may only be used for the purposes for which they were supplied. If you are not 
the addressee, you are notified that any transmission, distribution, 
downloading, printing or photocopying of the contents of this message or 
attachments is strictly prohibited. The privilege of confidentiality attached 
to this message and attachments is not waived, lost or destroyed by reason of 
mistaken delivery to you. If you receive this message in error please notify 
the sender by return e-mail or telephone.

Please note: the Department of Public Works carries out automatic software 
scanning, filtering and blocking of E-mails and attachments (including emails 
of a personal nature) for detection of viruses, malicious code, SPAM, 
executable programs or content it deems unacceptable. All reasonable 
precautions will be taken to respect the privacy of individuals in accordance 
with the Information Privacy Act 2009 (Qld). Personal information will only be 
used for official purposes, e.g. monitoring Departmental Personnel's compliance 
with Departmental Policies. Personal information will not be divulged or 
disclosed to others, unless authorised or required by Departmental Policy 
and/or law.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Blaicher, Christopher Y.

When writing an SVC one must be very careful.  The SVC you describe was poorly 
constructed and did not follow guidelines, admittedly not clearly stated as 
such, in the Authorized Assembler Services Manual.  Yes, R13 is the same as 
when the SVC was called, but from the manual:

When a type 2, 3, or 4 SVC routine receives control, register 5 contains the 
address of the SVRB.
This SVRB contains a 48-byte "extended save area," RBEXSAVE, for use by the SVC 
routine.

To use the caller's save area is not good programming.  After all, for most, if 
not all, system SVC's there is no requirement that R13 points at a save area.  
Most callable services do require a save area pointed to by R13 but then they 
are still in the user's key when they do the STM.

I never store into anything passed without verifying its validity and being in 
the key of the caller. I prefer to pass back information in registers.

Yes, there are probably a lot of shops out there that have a 'give me God-like 
powers' SVC, and they deserve what they get.

Is anything bullet-proof?  Probably not, but with the layers of control and 
with good coding, it is very tough to break through, especially from the 
outside.  There is little you can do to protect yourself from a disgruntled 
systems programmer.  After all, they have the keys to the kingdom.

This represents my personal opinion.

Chris Blaicher
Senior Software Engineer, Software Services
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

Check out our Knowledge Base at www.syncsort.com/support

Syncsort aims for the best product and service experience.
We welcome your feedback.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ray Overby
Sent: Tuesday, March 27, 2012 6:28 PM
To: MVS List Server 1
Subject: Re: Malicious Software Protection

I am a vendor so take my post with a grain of salt. For those that don't like 
vendors to respond stop reading now.. (flame on)

In my opinion there are some misconceptions about the ability of an ESM product 
to mitigate integrity based vulnerabilities and why this should be a concern 
for you. In general, your ESM product will not be able to help you much when 
dealing with these types of vulnerabilities. I will try and explain by example 
based on several real world integrity vulnerabilities what I mean.

Lets say there is a SVC that when you IPL your z/OS system it is installed and 
available for use (i.e - any one can issue the SVC). The SVC either came with 
z/OS or your system programmers installed it because of an ISV product your 
company purchased or its an in-house written program. For this example lets 
assume one of your TSO users will attempt to exploit this vulnerability. The 
TSO user has no extra-ordinary security privileges.

Like any SVC when invoked it will get control in an authorized state (PSW Key 
0). Further this SVC issues a STM instruction very early in the SVC code 
storing into where ever R13 points to. This type of defect is easily exploited 
writing a simple program (could have been posted on the
web) that would issue the SVC and:

-Just before the SVC is issued point the unauthorized program's R13
to some critical memory location. When the SVC code executes it will modify the 
storage pointed to by unauthorized program's R13. If the system does not crash 
right away then put it into a loop and reissue the svc with R13 pointing at 
different areas. Eventually you will crash the system.

-Just before the SVC is issued point the unauthorized program's R13
to your security credentials, preload your registers with appropriate values, 
and have the SVC update your security credentials for you.

Note that it does not matter if the SVC "worked" or not. As long as the STM 
instruction was executed (it always was) then whatever went on later did not 
matter.

On a RACF system you could exploit this integrity vulnerability by dynamically 
elevating your security authority by enabling RACF privileged attribute for 
your ACEE. You would be able to do similar actions on a TSS or ACF2 protected 
system as well. According to IBM documentation RACF privileged users have 
access to any RACF protected resource without logging. Even if there are 
exceptions to this you could suppress WTO's and any SMF records as well (with a 
little more work).
Once the TSO user has dynamically elevated their security authority they can 
then access whatever ESM protected resource they want. With no audit trail. Or 
you could modify your security credentials to be the high powered system's 
programmer or security officer and let the logging occur. This may get you 
through any system exits you have in place that check for those users.;-)

Based on these real world examples I was able to write that program:

Re: Malicious Software Protection

2012-03-27 Thread Rob Schramm

If everyone were as concerned with system integrity, Ray would be out
of a job and I would sleep better.  That presentation still wakes me
up at night.

Rob Schramm



On Tue, Mar 27, 2012 at 11:06 PM, Russell Witt  wrote:
> Greg,
>
> Others have given you more information than you probably wanted, but I am
> going to add one more. To the list of 11 items that Elardus supplied earlier
> in the day, I would add one more. His number 10 - Give them IBM's Statement
> of Integrity. APAR reasons for security are hidden and you are usually asked
> to apply them because of some 'vulnurability' which IBM usually declines to
> divulge. - should be enhanced to say "Give them a IBM's Statement Of
> Integrity as well as the Statement of Integrity for every other OEM software
> product you have installed as well as every in-house written application you
> have installed." While such a Statement does not 100% guarantee that no
> exposure exits; it does give the guarantee that if an exposure is found it
> will be corrected just as soon as possible. Any vendor that does not have
> such a Statement on file that they can readily supply indicates that they
> haven't given this subject much thought.
>
> Russell Witt
> CA 1 Support Manager
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
> Of Greg Dorner
> Sent: Tuesday, March 27, 2012 10:07 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Malicious Software Protection
>
> Dear IBM-MAINers,
>
> Our auditors are insisting that we install a product that protects against
> malicious software (viruses, worms, trojans, etc.).
>
> Does anyone know of a product that does this? I heard that McAfee is coming
> out with a z/OS product "later this year", but I called them and they had no
> idea what I was talking about.
>
> z/OS, with proper security controls (and believe me - we have LOTS!) should
> not have to worry about such things, at least that's what I've always heard.
>
> Any input on this topic would be GREATLY appreciated!!
>
> Thanks,
> Greg Dorner, WPS Insurance Corp.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Russell Witt

Greg,

Others have given you more information than you probably wanted, but I am
going to add one more. To the list of 11 items that Elardus supplied earlier
in the day, I would add one more. His number 10 - Give them IBM's Statement
of Integrity. APAR reasons for security are hidden and you are usually asked
to apply them because of some 'vulnurability' which IBM usually declines to
divulge. - should be enhanced to say "Give them a IBM's Statement Of
Integrity as well as the Statement of Integrity for every other OEM software
product you have installed as well as every in-house written application you
have installed." While such a Statement does not 100% guarantee that no
exposure exits; it does give the guarantee that if an exposure is found it
will be corrected just as soon as possible. Any vendor that does not have
such a Statement on file that they can readily supply indicates that they
haven't given this subject much thought.

Russell Witt
CA 1 Support Manager

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Greg Dorner
Sent: Tuesday, March 27, 2012 10:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Malicious Software Protection

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects against
malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is coming
out with a z/OS product "later this year", but I called them and they had no
idea what I was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!) should
not have to worry about such things, at least that's what I've always heard.

Any input on this topic would be GREATLY appreciated!!

Thanks, 
Greg Dorner, WPS Insurance Corp.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Ray Overby

There are many reasons for these types of defects. The programmer(s) in 
these cases to the best of my knowledge were actually very experienced 
z/OS developers. Very competent people. In my experience it is a matter 
of when not if these type of issues occur when you are responsible for 
developing and maintaining this type of code. It requires a constant 
vigilance to make sure these types of errors don't get out into the 
field. Even then it only takes a single "error" that could compromise 
the system integrity. It is a difficult job.




Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007


On 3/27/2012 19:30 PM, Gerhard Postpischil wrote:

On 3/27/2012 7:27 PM, Ray Overby wrote:

Like any SVC when invoked it will get control in an authorized
state (PSW Key 0). Further this SVC issues a STM instruction
very early in the SVC code storing into where ever R13 points
to. This type of defect is easily exploited writing a simple
program (could have been posted on the web) that would issue the
SVC and:


Defect is the correct description; your SVC sounds as though written 
by an incompetent programmer. User's registers are preserved in the RB 
(PRB, SVRB), where they are protected, rather than the save area. 
Off-hand I can't recall any SVC that needs R13 to point to a save 
area, rather there are cases where R13 is destroyed.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Gerhard Postpischil


On 3/27/2012 7:27 PM, Ray Overby wrote:

Like any SVC when invoked it will get control in an authorized
state (PSW Key 0). Further this SVC issues a STM instruction
very early in the SVC code storing into where ever R13 points
to. This type of defect is easily exploited writing a simple
program (could have been posted on the web) that would issue the
SVC and:


Defect is the correct description; your SVC sounds as though 
written by an incompetent programmer. User's registers are 
preserved in the RB (PRB, SVRB), where they are protected, 
rather than the save area. Off-hand I can't recall any SVC that 
needs R13 to point to a save area, rather there are cases where 
R13 is destroyed.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Ray Overby

I am a vendor so take my post with a grain of salt. For those that don't 
like vendors to respond stop reading now.. (flame on)


In my opinion there are some misconceptions about the ability of an ESM 
product to mitigate integrity based vulnerabilities and why this should 
be a concern for you. In general, your ESM product will not be able to 
help you much when dealing with these types of vulnerabilities. I will 
try and explain by example based on several real world integrity 
vulnerabilities what I mean.


Lets say there is a SVC that when you IPL your z/OS system it is 
installed and available for use (i.e - any one can issue the SVC). The 
SVC either came with z/OS or your system programmers installed it 
because of an ISV product your company purchased or its an in-house 
written program. For this example lets assume one of your TSO users will 
attempt to exploit this vulnerability. The TSO user has no 
extra-ordinary security privileges.


Like any SVC when invoked it will get control in an authorized state 
(PSW Key 0). Further this SVC issues a STM instruction very early in the 
SVC code storing into where ever R13 points to. This type of defect is 
easily exploited writing a simple program (could have been posted on the 
web) that would issue the SVC and:


-Just before the SVC is issued point the unauthorized program's R13 
to some critical memory location. When the SVC code executes it will 
modify the storage pointed to by unauthorized program's R13. If the 
system does not crash right away then put it into a loop and reissue the 
svc with R13 pointing at different areas. Eventually you will crash the 
system.


-Just before the SVC is issued point the unauthorized program's R13 
to your security credentials, preload your registers with appropriate 
values, and have the SVC update your security credentials for you.


Note that it does not matter if the SVC "worked" or not. As long as the 
STM instruction was executed (it always was) then whatever went on later 
did not matter.


On a RACF system you could exploit this integrity vulnerability by 
dynamically elevating your security authority by enabling RACF 
privileged attribute for your ACEE. You would be able to do similar 
actions on a TSS or ACF2 protected system as well. According to IBM 
documentation RACF privileged users have access to any RACF protected 
resource without logging. Even if there are exceptions to this you could 
suppress WTO's and any SMF records as well (with a little more work). 
Once the TSO user has dynamically elevated their security authority they 
can then access whatever ESM protected resource they want. With no audit 
trail. Or you could modify your security credentials to be the high 
powered system's programmer or security officer and let the logging 
occur. This may get you through any system exits you have in place that 
check for those users.;-)


Based on these real world examples I was able to write that program:

-Dynamically elevated TSO users ESM security authority
-Access ESM protected resources the TSO user was not specifically 
authorized to by the installation

-Suppress any WTO's or SMF about the activity for the TSO user.

The ESM products did not stop the TSO user from exploiting this 
vulnerability. Nor did they provide any audit trail for accessing the 
protected resource the TSO user was not authorized for. No system data 
sets were updated. No APF authorized library were updated. The program 
does not require link edit with AC(1). In this case there was nothing 
the ESM's could do.


The places where this work was done had stringent security requirements, 
internal/external auditors, periodic security reviews, and were very 
diligent in implementing their computer security. Yet with the exploit 
of this vulnerabliit the TSO user bypassed all of the installations 
controls and left no audit trail for later analysis. With this program 
the TSO user was able to compromise all data on that system as well we 
the system itself. What if that data was secret government or military 
data, or was credit card or insurance company customer data? That would 
violate ever compliance standard there is!


Unfortunately, there are integrity based vulnerabilities similar to this 
that are on your z/OS system today. Your ESM controls will not help you 
if they are exploited. If you are not concerned that your users can 
crash your z/OS system at any time (maliciously or accidentally) OR your 
users can access any ESM protect resources regardless of installation 
controls with no logging or auditing then by all means ignore the issue. 
It does not mean it is not true.


Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007


On 3/27/2012 15:06 PM, Joel C. Ewing wrote:
Yes, it is true that if you could introduce a trojan into an APF 
library you could compromise z/OS, and that this might be possible:


If you don't have RACF or equiva

Re: Malicious Software Protection

2012-03-27 Thread R.S.

Yes, and no.
Yes, any virus scanner provide some security (at least neutral, usually
positive).
No, because such virus cannot occur (pop up) on the mainframe, mainframe
cannot be infected (I think we agree with that). So, some other system
had to send it to mainframe previously; mainframe only forwarded it
further. DON'T KILL MESSENGER ;-)
So, the sending (to mainframe) system should be responsible for virus
scanning, otherwise ...mainframe is also not responsible ;-)

And, IHMO, sending data outside has no meaning here. All data should be
virus-free, otherwise we talk about toys, not serious business systems.
Does it mean that everything and everywhere should be virus-scanned? NO,
it would be senseless.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-03-27 21:46, Thomas Kern pisze:

I must disagree with your second argument. If your mainframe does not provide
data to
anyone outside of your control, then okay. But if you deliver data to outsider,
the public
in particular, I feel you have a duty to make sure that the data you provide
does not
include a virus that might affect their system even if it cannot affect your
mainframe. A
mainframe webserver delivering windows viruses (virusi?) to the public does not
help our
reputations.

Even though we have an anti-virus program running on every workstation in our
agency, I
still do not trust all of the files these people upload to my mainframe (or
linux/x86)
server for distribution to outsiders. I want to scan all of these files ONE
MORE TIME
before making them available. I would prefer to do this on an x86 server than
spend
mainframe cycles.

Similar precautions should be applied to files received from the outside world.
No one
should get to them before they get scanned. All failures in the scan need to be
further
quarantined until a security (anti-virus) expert looks at the files.

/Thomas Kern
/on contract to
/U.S. Dept of Energy
/301-903-2211 (Office)
/301-905-6427 (Mobile)

On 3/27/2012 14:25, R.S. wrote:

W dniu 2012-03-27 17:06, Greg Dorner pisze:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects against
malicious
software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is coming out
with a
z/OS product "later this year", but I called them and they had no idea what I
was
talking about.

z/OS, with proper security controls (and believe me - we have LOTS!) should not
have to
worry about such things, at least that's what I've always heard.

Any input on this topic would be GREATLY appreciated!!

This is NOT mainframe problem.

Indeed, you have problem with uneducated auditors. Maybe stupid ones.
Your problem is how to prove that requirement is both stupid and impossible to
fulfill.

We can provide you some arguments, like
- there are no such products
- there are no viruses, trojans or other malware for z/OS and it have never
been last 47
years. (I said 'z/OS', so the only VM worm does not count)
- no mainframe installation use such product
- you have RACF *SECURITY SERVER* (or TS or ACF2)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Ray Overby

Every z/os system today has integrity vulnerabilities on it that if 
exploited would allow users with access to that system to crash that 
system or bypass installation controls and access any protected resource 
on that system regardless of the installed ESM. They would be able to do 
so with little to no audit trail.


What part of this is not a mainframe problem?

Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007


On 3/27/2012 13:25 PM, R.S. wrote:

W dniu 2012-03-27 17:06, Greg Dorner pisze:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects 
against malicious software (viruses, worms, trojans, etc.).


Does anyone know of a product that does this? I heard that McAfee is 
coming out with a z/OS product "later this year", but I called them 
and they had no idea what I was talking about.


z/OS, with proper security controls (and believe me - we have LOTS!) 
should not have to worry about such things, at least that's what I've 
always heard.


Any input on this topic would be GREATLY appreciated!!


This is NOT mainframe problem.

Indeed, you have problem with uneducated auditors. Maybe stupid ones.
Your problem is how to prove that requirement is both stupid and 
impossible to fulfill.



We can provide you some arguments, like
- there are no such products
- there are no viruses, trojans or other malware for z/OS and it have 
never been last 47 years. (I said 'z/OS', so the only VM worm does not 
count)

- no mainframe installation use such product
- you have RACF *SECURITY SERVER* (or TS or ACF2)




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Killian, Gregory

There is an antivirus product for the mainframe which I have used in the
past. While it does not check the mainframe for viruses, per se, it does
scan mainframe email and filter viruses out. Check out:

http://www.thefreelibrary.com/Trend+Micro+First+to+Announce+Mainframe+Vi
rus+Protection%3B+Leading...-a020770290
http://www.trendmicro.com/us/boxes/lightboxes/20111202082421.html



Greg Killian @ work 
Washington State Department of Transportation
310 Maple Park Ave SE
P.O. Box 47427
Olympia, WA 98504-7427
360-705-7670 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of McKown, John
Sent: Tuesday, March 27, 2012 11:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Malicious Software Protection

True. For users which have RACF SPECIAL, a WTOR is written to the z/OS
console. Of course, in our shop, nobody monitors the z/OS consoles. And
the shop is totally "dark" on the weekends.

Naturally, I have a very weird way to do something about this. Which I
will not document or tell to anyone.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the
original message. HealthMarkets(r) is the brand name for products
underwritten and issued by the insurance subsidiaries of HealthMarkets,
Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life
Insurance Company of TennesseeSM and The MEGA Life and Health Insurance
Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

Hal,

Me too

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 4:30 PM, Hal Merritt  wrote:

> Actually, Greg's point number 2 is spot on.  
> 
> Upon close inspection, they actually be asking for some change control / 
> management approval to protect sensitive load and source libraries. 
> 
> Over the years, I've found it helpful to not jump to conclusions when 
> presented with such. Rather, press for details, and keep pressing until you 
> get something understandable. Often as not, it turns out to be something 
> completely different. 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Elardus Engelbrecht
> Sent: Tuesday, March 27, 2012 11:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> Greg Dorner wrote:
> 
>> Our auditors are insisting that we install a product that protects against 
>> malicious software (viruses, worms, trojans, etc.).
> 
> Groan, you can replace/fire those auditors as mentioned earlier in this 
> thread, but ... ;-D
> 
> You have several choices.
> 
> 1. Ask them to give reasons, examples and recommended vendors of such 
> software. 
> 
> 2. Ask them to define malicious software, despite your description above. 
> Seriously.
> 
> 3. For native z/OS, they will have a hard way to get any vendors at all which 
> can supply such software. Tell me if you can catch these vendors.
> 
> 4. Despite point 3, there are 'scanners' which can search z/OS on various 
> areas to look for 'holes'. They cost $$$ and is vendor specific. 
> 
> 5. Get 'penetration teams' or 'white hat hackers'. You have lots of $$$, do 
> you? :-)
> 
> 6. z/OS has very good security measures provided you have your controls in 
> place. APF, parmlib settings, RACF, SMF, etc. are examples. See other's 
> replies on this fact.
> 
> 7. Speaking of RACF, there are third party RACF [or other ESM] administration 
> and audit tools which could ease your work.
> 
> 8. Weakest links are usually 'insiders'. They are the greatest threats unless 
> I'm mistaken. They are usually after your 'live and sensitive production' 
> data.
> 
> 9. For z/Linux, USS, etc, there MAY be commercial or open-source antivirus 
> software available, AFAIK.
> (USS - Unix System Service(s) - for those TLA haters... :-D )
> 
> 10. Give them IBM's Statement of Integrity. APAR reasons for security are 
> hidden and you are usually asked to apply them because of some 
> 'vulnurability' which IBM usually declines to divulge.
> 
> 11. Ask those auditors if they have any tools to do the checks for such tools 
> against malicous software THEMSELVES! This will silence them properly!
> 
>> z/OS, with proper security controls (and believe me - we have LOTS!) should 
>> not have to worry about such things, at least that's what I've always heard.
> 
> Of course, but see above.
> 
>> Any input on this topic would be GREATLY appreciated!!
> 
> As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management 
> who can APPLY those recommendations.
> 
> HTH!
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@bama.ua.edu with the message: INFO IBM-MAIN
> NOTICE: This electronic mail message and any files transmitted with it are 
> intended
> exclusively for the individual or entity to which it is addressed. The 
> message, 
> together with any attachment, may contain confidential and/or privileged 
> information.
> Any unauthorized review, use, printing, saving, copying, disclosure or 
> distribution 
> is strictly prohibited. If you have received this message in error, please 
> immediately advise the sender by reply email and delete all copies.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Hal Merritt

Actually, Greg's point number 2 is spot on.  

Upon close inspection, they actually be asking for some change control / 
management approval to protect sensitive load and source libraries. 

Over the years, I've found it helpful to not jump to conclusions when presented 
with such. Rather, press for details, and keep pressing until you get something 
understandable. Often as not, it turns out to be something completely 
different. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Elardus Engelbrecht
Sent: Tuesday, March 27, 2012 11:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Malicious Software Protection

Greg Dorner wrote:

>Our auditors are insisting that we install a product that protects against 
>malicious software (viruses, worms, trojans, etc.).

Groan, you can replace/fire those auditors as mentioned earlier in this 
thread, but ... ;-D

You have several choices.

1. Ask them to give reasons, examples and recommended vendors of such software. 

2. Ask them to define malicious software, despite your description above. 
Seriously.

3. For native z/OS, they will have a hard way to get any vendors at all which 
can supply such software. Tell me if you can catch these vendors.

4. Despite point 3, there are 'scanners' which can search z/OS on various areas 
to look for 'holes'. They cost $$$ and is vendor specific. 

5. Get 'penetration teams' or 'white hat hackers'. You have lots of $$$, do 
you? :-)

6. z/OS has very good security measures provided you have your controls in 
place. APF, parmlib settings, RACF, SMF, etc. are examples. See other's replies 
on this fact.

7. Speaking of RACF, there are third party RACF [or other ESM] administration 
and audit tools which could ease your work.

8. Weakest links are usually 'insiders'. They are the greatest threats unless 
I'm mistaken. They are usually after your 'live and sensitive production' data.

9. For z/Linux, USS, etc, there MAY be commercial or open-source antivirus 
software available, AFAIK.
(USS - Unix System Service(s) - for those TLA haters... :-D )

10. Give them IBM's Statement of Integrity. APAR reasons for security are 
hidden and you are usually asked to apply them because of some 'vulnurability' 
which IBM usually declines to divulge.

11. Ask those auditors if they have any tools to do the checks for such tools 
against malicous software THEMSELVES! This will silence them properly!

>z/OS, with proper security controls (and believe me - we have LOTS!) should 
>not have to worry about such things, at least that's what I've always heard.

Of course, but see above.

>Any input on this topic would be GREATLY appreciated!!

As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management who 
can APPLY those recommendations.

HTH!

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Joel C. Ewing

Yes, it is true that if you could introduce a trojan into an APF library
you could compromise z/OS, and that this might be possible:

If you don't have RACF or equivalent properly configured to protect all
system data sets;
If you allow update authority to APF libraries or PARMLIB to people
other than those which require it for system-level maintenance;
If you install modules into APF libraries from any sources other than
trusted vendors;
If you add installation hooks deliberately designed to circumvent
security that might be exploited, or tolerate vendor products with such
exposures;
If you don't have some sort of change management, oversight, and
monitoring in place to catch violations of installation security policies.

In a very real sense RACF and system maintenance policies and the
mindset and training of z/OS SysProgs are the anti-virus software on
z/OS and this combination has worked quite well over the decades -- much
more reliably than even the best anti-virus software on MS platforms,
and no periodic database or detection program refresh ever required.

The concept of allowing average-Joe user to be able to download data
from arbitrary sources in arbitrary formats and being able from that to
somehow introduce executable code into the system in ways that will
execute with special privileges so as to introduce a virus or trojan is
an issue that is endemic to Windows platforms but foreign to z/OS.

Thus it makes excellent sense for auditors to examine and question
installation RACF conventions, access to critical system data sets, and
change management procedures. It makes zero sense to ask what is your
z/OS anti-virus software.

JC Ewing

On 03/27/2012 01:49 PM, David Cole wrote:

I'm sorry Tom. I did not intend my remarks to be personal. I deeply
regret that you feel hurt by them. Please don't let my words deter you
from future contributions. Your thoughts generally are more valuable
than most.

I just wanted to emphasize the APF Trojan horse vulnerability. It is
real, it is serious, yet for decades everyone seems to want to pretend
that it does not exist... It mystifies me.

...

www.zassure.com is the closest thing I've seen to an MVS anti-virus
program. After seeing a demo, I would have bought it, or recommended
it to a client. Check it out, you will be surprised, if not shocked.

Thank you for this. I will check it out.

[Regarding SAF] I do take issue with your last sentence. SAF and an
ESM have everything to do with anti-virus protection, provided they
are configured to correctly protect APF-authorized resources.

Perhaps. However, all an APF authorized program has to do is flip a bit
or two in certain RACF control blocks, and voilà! He's suddenly a
supervisory program and, as such, is given a pass on all RACF calls...
Alternatively, a malicious APF program can simply dynamically front-end
certain supervisory programs, and again voilà! (As I'm sure you know,
APF programs can fairly easily defeat all hardware storage protections.)

Yes, SAF is still called even for APF programs, but an APF program can
still subvert those calls.

I've never forgotten this [APF libraries]. That's why my
APF-authorized libraries are severely limited in scope, and audited
for any and all updates.

Enforcing trust is a technical issue. RACF is very good at that.
Deciding who to trust is a management issue. Even at shops that allow
only trusted vendor software into APF authorized libraries is implicitly
trusting the hundreds or even thousands of people involved in the
development of that software.

Again, I go into more detail about this in my prior post:
"https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
".

Again, please accept my apology, Tom. It was not intended to be
personal. I'm sorry it came out that way.

Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658

At 3/27/2012 02:21 PM, Pinnacle wrote:

Replies like this are why I seldom post to IBM-Main anymore. The fact
that it comes from someone who I respect and consider a friend hurts
all the more. Bottom line is that I work for a living, and I often
don't have time to respond in gory detail to everything posted. My
primary objective here was to stress that the z/OS architecture is
inherently hardened against viruses. The fact that I did not go into
explicit protections for APF-authorized programs appears to have been
my fatal flaw, according to Mr. Cole. Regardless of what comes back,
this will be my last post on the subject. My comments below.

Regards,
Tom Conley

On 3/27/2012 1:06 PM, David Cole wrote:

At 3/27/2012 11:19 AM, Pinnacle wrote:

There is a mainf

Re: Malicious Software Protection

Mike, 

Interesting ...didn't know it existed..I knew about ibm's hod product...
Used it in several shops

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 3:52 PM, Mike Schwab  wrote:

> Netscape came out with a 3270 compatible version (3.10) then they got
> rid of it (I assume due to pressure from IBM)
> http://jisemu.courts.state.md.us/Help.htm
> I think it came with a list of sites that users had provided.
> 
> On Tue, Mar 27, 2012 at 12:49 PM, Scott Ford  wrote:
>> Lets step through this logically:
>> 
>> TN3270 
>> 
>> 1. Must have RACF/ACF2/TSS  userid/lid/acid
>> 2. Must have a valid password
>> 3. Must have valid IP address
>> 4. Must have valid port
>> 5. Must have Firewall rule for #3 and #4 ...
>> 
>> Other issues:  How many firewalls ?  How is the network architected ?
>> 
>> This is just a favor ..FTP the same
>> 
>> Scott J Ford
>> Software Engineer
>> http://www.identityforge.com
> 
> -- 
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Mike Schwab

Netscape came out with a 3270 compatible version (3.10) then they got
rid of it (I assume due to pressure from IBM)
http://jisemu.courts.state.md.us/Help.htm
I think it came with a list of sites that users had provided.

On Tue, Mar 27, 2012 at 12:49 PM, Scott Ford  wrote:
> Lets step through this logically:
>
> TN3270 
>
> 1. Must have RACF/ACF2/TSS  userid/lid/acid
> 2. Must have a valid password
> 3. Must have valid IP address
> 4. Must have valid port
> 5. Must have Firewall rule for #3 and #4 ...
>
> Other issues:  How many firewalls ?  How is the network architected ?
>
> This is just a favor ..FTP the same
>
> Scott J Ford
> Software Engineer
> http://www.identityforge.com

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Thomas Kern

I must disagree with your second argument. If your mainframe does not provide 
data to
anyone outside of your control, then okay. But if you deliver data to outsider, 
the public
in particular, I feel you have a duty to make sure that the data you provide 
does not
include a virus that might affect their system even if it cannot affect your 
mainframe. A
mainframe webserver delivering windows viruses (virusi?) to the public does not 
help our
reputations.

Even though we have an anti-virus program running on every workstation in our 
agency, I
still do not trust all of the files these people upload to my mainframe (or 
linux/x86)
server for distribution to outsiders. I want to scan all of these files ONE 
MORE TIME
before making them available. I would prefer to do this on an x86 server than 
spend
mainframe cycles.

Similar precautions should be applied to files received from the outside world. 
No one
should get to them before they get scanned. All failures in the scan need to be 
further
quarantined until a security (anti-virus) expert looks at the files.

/Thomas Kern
/on contract to
/U.S. Dept of Energy
/301-903-2211 (Office)
/301-905-6427 (Mobile)

On 3/27/2012 14:25, R.S. wrote:
> W dniu 2012-03-27 17:06, Greg Dorner pisze:
>> Dear IBM-MAINers,
>>
>> Our auditors are insisting that we install a product that protects against 
>> malicious
>> software (viruses, worms, trojans, etc.).
>>
>> Does anyone know of a product that does this? I heard that McAfee is coming 
>> out with a
>> z/OS product "later this year", but I called them and they had no idea what 
>> I was
>> talking about.
>>
>> z/OS, with proper security controls (and believe me - we have LOTS!) should 
>> not have to
>> worry about such things, at least that's what I've always heard.
>>
>> Any input on this topic would be GREATLY appreciated!!
> 
> This is NOT mainframe problem.
> 
> Indeed, you have problem with uneducated auditors. Maybe stupid ones.
> Your problem is how to prove that requirement is both stupid and impossible 
> to fulfill.
> 
> 
> We can provide you some arguments, like
> - there are no such products
> - there are no viruses, trojans or other malware for z/OS and it have never 
> been last 47
> years. (I said 'z/OS', so the only VM worm does not count)
> - no mainframe installation use such product
> - you have RACF *SECURITY SERVER* (or TS or ACF2)
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Aled Hughes

I have to agree with Tony and many of the others, especially Radislaw's 
comments about auditors needing to be taught. One has to accept, of course, 
that many of them are MBAs (!) who work for the Big Auditors, but sadly have 
never even seen an IBM mainframe system. I first came across these 'specimens' 
back in the early 80s at a bank, who insited that our mainframes could be 
vulnerable. I tried to explain that without a password etc, they could not be. 
'Blue in the face' came to mind. 

I've just thought of something Greg - I'll hire myself as a 'Virus Guru' to 
come into your company and certify that you cannot be attacked. Should only 
take about six months. $2K a day alright? Would that satisfy them? :-)

All joking aside, it's sad that we have to put up with these uneducated 
'auditors' - we have enough to do! 

ALH

-Original Message-
From: Tony Harminc 
To: IBM-MAIN 
Sent: Tue, Mar 27, 2012 5:49 pm
Subject: Re: Malicious Software Protection

On 27 March 2012 11:06, Greg Dorner  wrote:
> Our auditors are insisting that we install a product that protects against 
alicious software (viruses, worms, trojans, etc.).
But have they asked you about the powerful and dangerous AMASPZAP yet?
hey aren't Real Auditors until they confront you about that.
> Does anyone know of a product that does this? I heard that McAfee is coming 
ut with a z/OS product "later this year", but I called them and they had no 
dea what I was talking about.
One approach is to play stupid the whole way.
Malicious software - what is that? Virus? Worm? Trojan? No, I am not
ware of any such thing. Could you please give an example of what you
re talking about? Ah - you suggest general protection against not yet
dentified threats? In your wide experience of auditing other
ompanies, what product(s) to do this have you found most commonly in
se on z/OS? What is the performance impact of these products? Could
ou direct me to some vendor-independent studies of their
rice/performance? Etc, etc.
Tony H.
--
or IBM-MAIN subscribe / signoff / archive access instructions,
end email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

I see a much bigger issue, knowledge, once we old timers cash it in, like Walt 
was lucky enough to do, then who will 'carry the touch'the newer 'kids' 
don't want the responsibility or know how, just the cash, sorry not trying to 
mean or negative, I am second generation IT

Hopefully, schools like Steve and others will have an influx to train the 
youngsters..

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 3:23 PM, Scott Ford  wrote:

> All,
> 
> I think we all agree that every system has vulnerabilities, where Windows, 
> Unix,VM, or Z/OS,
> the methods make it difficult for hackers to get into the systems, ,no 
> different than protecting a home from robbers. By using a big dog and a 12 
> gauge ..or electronic security system..many of us 
> firewalls,routers,RACF,acf2, TSS, pass-phrases, encryption to slow down the 
> intruder.
> 
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On Mar 27, 2012, at 2:49 PM, David Cole  wrote:
> 
>> I'm sorry Tom. I did not intend my remarks to be personal. I deeply regret 
>> that you feel hurt by them. Please don't let my words deter you from future 
>> contributions. Your thoughts generally are more valuable than most.
>> 
>> I just wanted to emphasize the APF Trojan horse vulnerability. It is real, 
>> it is serious, yet for decades everyone seems to want to pretend that it 
>> does not exist... It mystifies me.
>> 
>> 
>> 
>> 
>> 
>> 
>>> www.zassure.com is the closest thing I've seen to an MVS anti-virus 
>>> program.  After seeing a demo, I would have bought it, or recommended it to 
>>> a client.  Check it out, you will be surprised, if not shocked.
>> 
>> Thank you for this. I will check it out.
>> 
>> 
>> 
>> 
>> 
>> 
>>> [Regarding SAF] I do take issue with your last sentence.  SAF and an ESM 
>>> have everything to do with anti-virus protection, provided they are 
>>> configured to correctly protect APF-authorized resources.
>> 
>> Perhaps. However, all an APF authorized program has to do is flip a bit or 
>> two in certain RACF control blocks, and voilà! He's suddenly a supervisory 
>> program and, as such, is given a pass on all RACF calls... Alternatively, a 
>> malicious APF program can simply dynamically front-end certain supervisory 
>> programs, and again voilà! (As I'm sure you know, APF programs can fairly 
>> easily defeat all hardware storage protections.)
>> 
>> Yes, SAF is still called even for APF programs, but an APF program can still 
>> subvert those calls.
>> 
>> 
>> 
>> 
>> 
>> 
>>> I've never forgotten this [APF libraries]. That's why my APF-authorized 
>>> libraries are severely limited in scope, and audited for any and all 
>>> updates.
>> 
>> Enforcing trust is a technical issue. RACF is very good at that. Deciding 
>> who to trust is a management issue. Even at shops that allow only trusted 
>> vendor software into APF authorized libraries is implicitly trusting the 
>> hundreds or even thousands of people involved in the development of that 
>> software.
>> 
>> Again, I go into more detail about this in my prior post: 
>> "https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
>>  ".
>> 
>> 
>> 
>> 
>> 
>> 
>> Again, please accept my apology, Tom. It was not intended to be personal. 
>> I'm sorry it came out that way.
>> 
>> Dave Cole  REPLY TO: dbc...@colesoft.com
>> ColeSoft Marketing WEB PAGE: http://www.colesoft.com
>> 736 Fox Hollow RoadVOICE:540-456-8536
>> Afton, VA 22920FAX:  540-456-6658
>> 
>> 
>> 
>> 
>> 
>> 
>> At 3/27/2012 02:21 PM, Pinnacle wrote:
>>> Replies like this are why I seldom post to IBM-Main anymore.  The fact that 
>>> it comes from someone who I respect and consider a friend hurts all the 
>>> more.  Bottom line is that I work for a living, and I often don't have time 
>>> to respond in gory detail to everything posted.  My primary objective here 
>>> was to stress that the z/OS architecture is inherently hardened against 
>>> viruses.  The fact that I did not go into explicit protections for 
>>> APF-authorized programs appears to have been my fatal flaw, according to 
>>> Mr. Cole.  Regardless of what comes back, this will be my last post on the 
>>> subject.  My comments below.
>>> 
>>> Regards,
>>> Tom Conley
>>> 
>>> 
>>> 
>>> 
>>> On 3/27/2012 1:06 PM, David Cole wrote:
 At 3/27/2012 11:19 AM, Pinnacle wrote:
> There is a mainframe product that protects against malicious software. 
> It's called SAF, and it interfaces with ESM's like RACF, or ACF2, or 
> TopSecret.
 
 "SAF" is not a product. It stands for "System Access Facility" and it is 
 nothing more than an interface within z/OS into which a security syste

Re: Malicious Software Protection

All,

I think we all agree that every system has vulnerabilities, where Windows, 
Unix,VM, or Z/OS,
the methods make it difficult for hackers to get into the systems, ,no 
different than protecting a home from robbers. By using a big dog and a 12 
gauge ..or electronic security system..many of us firewalls,routers,RACF,acf2, 
TSS, pass-phrases, encryption to slow down the intruder.

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 2:49 PM, David Cole  wrote:

> I'm sorry Tom. I did not intend my remarks to be personal. I deeply regret 
> that you feel hurt by them. Please don't let my words deter you from future 
> contributions. Your thoughts generally are more valuable than most.
> 
> I just wanted to emphasize the APF Trojan horse vulnerability. It is real, it 
> is serious, yet for decades everyone seems to want to pretend that it does 
> not exist... It mystifies me.
> 
> 
> 
> 
> 
> 
>> www.zassure.com is the closest thing I've seen to an MVS anti-virus program. 
>>  After seeing a demo, I would have bought it, or recommended it to a client. 
>>  Check it out, you will be surprised, if not shocked.
> 
> Thank you for this. I will check it out.
> 
> 
> 
> 
> 
> 
>> [Regarding SAF] I do take issue with your last sentence.  SAF and an ESM 
>> have everything to do with anti-virus protection, provided they are 
>> configured to correctly protect APF-authorized resources.
> 
> Perhaps. However, all an APF authorized program has to do is flip a bit or 
> two in certain RACF control blocks, and voilà! He's suddenly a supervisory 
> program and, as such, is given a pass on all RACF calls... Alternatively, a 
> malicious APF program can simply dynamically front-end certain supervisory 
> programs, and again voilà! (As I'm sure you know, APF programs can fairly 
> easily defeat all hardware storage protections.)
> 
> Yes, SAF is still called even for APF programs, but an APF program can still 
> subvert those calls.
> 
> 
> 
> 
> 
> 
>> I've never forgotten this [APF libraries]. That's why my APF-authorized 
>> libraries are severely limited in scope, and audited for any and all updates.
> 
> Enforcing trust is a technical issue. RACF is very good at that. Deciding who 
> to trust is a management issue. Even at shops that allow only trusted vendor 
> software into APF authorized libraries is implicitly trusting the hundreds or 
> even thousands of people involved in the development of that software.
> 
> Again, I go into more detail about this in my prior post: 
> "https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
>  ".
> 
> 
> 
> 
> 
> 
> Again, please accept my apology, Tom. It was not intended to be personal. I'm 
> sorry it came out that way.
> 
> Dave Cole  REPLY TO: dbc...@colesoft.com
> ColeSoft Marketing WEB PAGE: http://www.colesoft.com
> 736 Fox Hollow RoadVOICE:540-456-8536
> Afton, VA 22920FAX:  540-456-6658
> 
> 
> 
> 
> 
> 
> At 3/27/2012 02:21 PM, Pinnacle wrote:
>> Replies like this are why I seldom post to IBM-Main anymore.  The fact that 
>> it comes from someone who I respect and consider a friend hurts all the 
>> more.  Bottom line is that I work for a living, and I often don't have time 
>> to respond in gory detail to everything posted.  My primary objective here 
>> was to stress that the z/OS architecture is inherently hardened against 
>> viruses.  The fact that I did not go into explicit protections for 
>> APF-authorized programs appears to have been my fatal flaw, according to Mr. 
>> Cole.  Regardless of what comes back, this will be my last post on the 
>> subject.  My comments below.
>> 
>> Regards,
>> Tom Conley
>> 
>> 
>> 
>> 
>> On 3/27/2012 1:06 PM, David Cole wrote:
>>> At 3/27/2012 11:19 AM, Pinnacle wrote:
 There is a mainframe product that protects against malicious software. 
 It's called SAF, and it interfaces with ESM's like RACF, or ACF2, or 
 TopSecret.
>>> 
>>> "SAF" is not a product. It stands for "System Access Facility" and it is 
>>> nothing more than an interface within z/OS into which a security system 
>>> (such as ACF2, TopSecret and any ryo security system) can plug into to 
>>> receive and respond to security calls. It really has nothing to do with 
>>> anti-virus protection.
>> 
>> SAF is not a product, you're right.  Please forgive my use of the term 
>> "product", I should have said "feature".  I do take issue with your last 
>> sentence.  SAF and an ESM have everything to do with anti-virus protection, 
>> provided they are configured to correctly protect APF-authorized resources.
>> 
 It [z/OS] is the only operating system out there with built-in anti-virus 
 protection. On top of that, the hardware itself actively pro

Re: Malicious Software Protection

2012-03-27 Thread David Cole

I'm sorry Tom. I did not intend my remarks to be
personal. I deeply regret that you feel hurt by
them. Please don't let my words deter you from
future contributions. Your thoughts generally are more valuable than most.

I just wanted to emphasize the APF Trojan horse
vulnerability. It is real, it is serious, yet for
decades everyone seems to want to pretend that it
does not exist... It mystifies me.

www.zassure.com is the closest thing I've seen
to an MVS anti-virus program. After seeing a
demo, I would have bought it, or recommended it
to a client. Check it out, you will be surprised, if not shocked.

Thank you for this. I will check it out.

[Regarding SAF] I do take issue with your last
sentence. SAF and an ESM have everything to do
with anti-virus protection, provided they are
configured to correctly protect APF-authorized resources.

Perhaps. However, all an APF authorized program
has to do is flip a bit or two in certain RACF
control blocks, and voilà! He's suddenly a
supervisory program and, as such, is given a pass
on all RACF calls... Alternatively, a malicious
APF program can simply dynamically front-end
certain supervisory programs, and again voilà!
(As I'm sure you know, APF programs can fairly
easily defeat all hardware storage protections.)

Yes, SAF is still called even for APF programs,
but an APF program can still subvert those calls.

I've never forgotten this [APF libraries].
That's why my APF-authorized libraries are
severely limited in scope, and audited for any and all updates.

Enforcing trust is a technical issue. RACF is
very good at that. Deciding who to trust is a
management issue. Even at shops that allow only
trusted vendor software into APF authorized
libraries is implicitly trusting the hundreds or
even thousands of people involved in the development of that software.

Again, I go into more detail about this in my
prior post:
"https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
".

Again, please accept my apology, Tom. It was not
intended to be personal. I'm sorry it came out that way.

Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX: 540-456-6658

At 3/27/2012 02:21 PM, Pinnacle wrote:
Replies like this are why I seldom post to
IBM-Main anymore. The fact that it comes from
someone who I respect and consider a friend
hurts all the more. Bottom line is that I work
for a living, and I often don't have time to
respond in gory detail to everything posted. My
primary objective here was to stress that the
z/OS architecture is inherently hardened against
viruses. The fact that I did not go into
explicit protections for APF-authorized programs
appears to have been my fatal flaw, according to
Mr. Cole. Regardless of what comes back, this
will be my last post on the subject. My comments below.

Regards,
Tom Conley

On 3/27/2012 1:06 PM, David Cole wrote:

At 3/27/2012 11:19 AM, Pinnacle wrote:
There is a mainframe product that protects
against malicious software. It's called SAF,
and it interfaces with ESM's like RACF, or ACF2, or TopSecret.

SAF is not a product, you're right. Please
forgive my use of the term "product", I should
have said "feature". I do take issue with your
last sentence. SAF and an ESM have everything
to do with anti-virus protection, provided they
are configured to correctly protect APF-authorized resources.

It [z/OS] is the only operating system out
there with built-in anti-virus protection. On
top of that, the hardware itself actively
protects against damage through storage keys, protected memory, etc.
You have to explain to the auditors that
anti-virus software is not needed on z/OS,
because it's intrinsic to the operating system and the hardware.

I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and
integrity and reliability) features for
protecting against non-authorized programs. But
I must emphasize... -->NON<--authorized programs!

When it comes to AUTHORIZED programs, z/OS's
integrity (which is what you are talking about
with "storage keys" and such) is very good, but
of course not bulletproof. Worse though, when
it comes to SECURITY, there are some real
problems! Because with the proper knowledge, it
is TRIVIALLY EA

Re: Malicious Software Protection

2012-03-27 Thread McKown, John

True. For users which have RACF SPECIAL, a WTOR is written to the z/OS console. 
Of course, in our shop, nobody monitors the z/OS consoles. And the shop is 
totally "dark" on the weekends.

Naturally, I have a very weird way to do something about this. Which I will not 
document or tell to anyone.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Skip Robinson
> Sent: Tuesday, March 27, 2012 12:38 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> We're all pretty sanguine about our mainframe invulnerability. But we 
> should not overlook how one of our most valuable protections 
> can be turned 
> against us. We all have some limit set for logon attempts. If 
> an invalid 
> password is entered too many times, the userid gets 
> suspended--or referred 
> to the OS console for verification. A malicious rascal (any 
> other kind?) 
> can disable a really important userid in this way. Of course 
> the person 
> has to get into the network first and must know the userid to 
> target, but 
> beyond that no special authority is required. Even console 
> referral would 
> be disruptive to normal production. 
> 
> .
> .
> JO.Skip Robinson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Ed Finnell

What is it, anonymous is threatening to shut down the Internet this Sat. by 
 doing DOS on all the major DNS nodes.
 
 
In a message dated 3/27/2012 1:32:45 P.M. Central Daylight Time,  
scott_j_f...@yahoo.com writes:

We had  to setup ftps etc, it wasn't easy and very very time consuming. If 
the want in  bad enough, yeah your right they can get in for sure, if I 
understand   your posting.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

RS,

You are correct a big part of this is the auditors being 
educated...understanding the installation FULLY and also management ppl who 
chartered them to do the work...

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 2:25 PM, "R.S."  wrote:

> W dniu 2012-03-27 17:06, Greg Dorner pisze:
>> Dear IBM-MAINers,
>> 
>> Our auditors are insisting that we install a product that protects against 
>> malicious software (viruses, worms, trojans, etc.).
>> 
>> Does anyone know of a product that does this? I heard that McAfee is coming 
>> out with a z/OS product "later this year", but I called them and they had no 
>> idea what I was talking about.
>> 
>> z/OS, with proper security controls (and believe me - we have LOTS!) should 
>> not have to worry about such things, at least that's what I've always heard.
>> 
>> Any input on this topic would be GREATLY appreciated!!
> 
> This is NOT mainframe problem.
> 
> Indeed, you have problem with uneducated auditors. Maybe stupid ones.
> Your problem is how to prove that requirement is both stupid and impossible 
> to fulfill.
> 
> 
> We can provide you some arguments, like
> - there are no such products
> - there are no viruses, trojans or other malware for z/OS and it have never 
> been last 47 years. (I said 'z/OS', so the only VM worm does not count)
> - no mainframe installation use such product
> - you have RACF *SECURITY SERVER* (or TS or ACF2)
> 
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> --
> Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
> przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by 
> jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste 
> adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej 
> przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, 
> rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie 
> zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, 
> prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale 
> usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the Bank and is 
> intended solely for business use of the addressee. This e-mail may only be 
> received by the addressee and may not be disclosed to any third parties. If 
> you are not the intended addressee of this e-mail or the employee authorised 
> to forward it to the addressee, be advised that any dissemination, copying, 
> distribution or any other similar activity is legally prohibited and may be 
> punishable. If you received this e-mail by mistake please advise the sender 
> immediately by using the reply facility in your e-mail software and delete 
> permanently this e-mail including any copies of it either printed or saved to 
> hard drive. 
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
> +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
> Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
> Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci 
> wpacony) wynosi 168.410.984 zotych.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

Skip,

I agree but spent a lot of time on Wall Street, I can tell you several of the 
brokerage houses had three plus firewalls between the mainframes and outside 
world. We had to setup ftps etc, it wasn't easy and very very time consuming. 
If the want in bad enough, yeah your right they can get in for sure, if I 
understand  your posting.

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 2:09 PM, Skip Robinson  wrote:

> The reason I brought up this 'vulnerability' is that we hired a consultant 
> a while back to look for weaknesses. Of course they were able to logon 
> with a vanilla userid that had no special authority. And this is what they 
> did. 
> 
> We all spend a lot of time and mental energy focused on how to protect 
> ourselves from sophisticated attack. We look at APF. We look at SVC 
> screening. We look at access to sensitive libraries. But this particular 
> 'denial of service' can be accomplished by anyone with a valid userid and 
> password. And *only* because we lock up users for invalid password 
> attempts. I'm just sayin'... 
> 
> .
> .
> JO.Skip Robinson
> SCE Infrastructure Technology Services
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   Scott Ford 
> To: IBM-MAIN@bama.ua.edu
> Date:   03/27/2012 10:51 AM
> Subject:Re: Malicious Software Protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Lets step through this logically:
> 
> TN3270 
> 
> 1. Must have RACF/ACF2/TSS  userid/lid/acid
> 2. Must have a valid password
> 3. Must have valid IP address
> 4. Must have valid port
> 5. Must have Firewall rule for #3 and #4 ...
> 
> Other issues:  How many firewalls ?  How is the network architected ?
> 
> This is just a favor ..FTP the same
> 
> Scott J Ford
> Software Engineer
> http://www.identityforge.com
> 
> 
> 
> 
> From: Skip Robinson 
> To: IBM-MAIN@bama.ua.edu 
> Sent: Tuesday, March 27, 2012 1:37 PM
> Subject: Re: Malicious Software Protection
> 
> We're all pretty sanguine about our mainframe invulnerability. But we 
> should not overlook how one of our most valuable protections can be turned 
> 
> against us. We all have some limit set for logon attempts. If an invalid 
> password is entered too many times, the userid gets suspended--or referred 
> 
> to the OS console for verification. A malicious rascal (any other kind?) 
> can disable a really important userid in this way. Of course the person 
> has to get into the network first and must know the userid to target, but 
> beyond that no special authority is required. Even console referral would 
> be disruptive to normal production. 
> 
> .
> .
> JO.Skip Robinson
> SCE Infrastructure Technology Services
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   Steve Comstock 
> To:IBM-MAIN@bama.ua.edu
> Date:   03/27/2012 10:22 AM
> Subject:Re: Malicious Software Protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> On 3/27/2012 10:46 AM, Greg Dorner wrote:
>> Thank you, Elardus for your verbosity.
>> 
>> 
>> - you can replace/fire those auditors as mentioned earlier in this 
> thread
>> 
>> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
>> management
> who can APPLY those recommendations.
>> 
>> Unfortunately, we have no say with these auditors. They are working on
>> behalf
> of the Feds, and if we don't comply we can lose billions of $$ in federal 
> contracts.
>> 
>> The beauty of this is, someone from my company contacted the person at 
> PWC
> that made this claim that MCAFEE is coming out with a product, and he
> backtracked, saying he may have been thinking of Mac OS. MAC OS???
>> 
>> They just took a big chuck of our company offline for several hours to
> research this phantom.
> 
> Wow. And did they reprimand this doofus in any way? Slap on
> the wrist? Letter in his personnel file?
> 
> More likely he got commended for being concerned about company
> security, even though he had no idea what he was talking about.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread R.S.

W dniu 2012-03-27 17:06, Greg Dorner pisze:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects against
malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is coming out with a
z/OS product "later this year", but I called them and they had no idea what I
was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!) should not
have to worry about such things, at least that's what I've always heard.

Any input on this topic would be GREATLY appreciated!!

This is NOT mainframe problem.

Indeed, you have problem with uneducated auditors. Maybe stupid ones.
Your problem is how to prove that requirement is both stupid and
impossible to fulfill.

- no mainframe installation use such product
- you have RACF *SECURITY SERVER* (or TS or ACF2)

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Pinnacle

Replies like this are why I seldom post to IBM-Main anymore.  The fact 
that it comes from someone who I respect and consider a friend hurts all 
the more.  Bottom line is that I work for a living, and I often don't 
have time to respond in gory detail to everything posted.  My primary 
objective here was to stress that the z/OS architecture is inherently 
hardened against viruses.  The fact that I did not go into explicit 
protections for APF-authorized programs appears to have been my fatal 
flaw, according to Mr. Cole.  Regardless of what comes back, this will 
be my last post on the subject.  My comments below.


Regards,
Tom Conley

On 3/27/2012 1:06 PM, David Cole wrote:

At 3/27/2012 11:19 AM, Pinnacle wrote:
There is a mainframe product that protects against malicious 
software. It's called SAF, and it interfaces with ESM's like RACF, or 
ACF2, or TopSecret.


"SAF" is not a product. It stands for "System Access Facility" and it 
is nothing more than an interface within z/OS into which a security 
system (such as ACF2, TopSecret and any ryo security system) can plug 
into to receive and respond to security calls. It really has nothing 
to do with anti-virus protection.




SAF is not a product, you're right.  Please forgive my use of the term 
"product", I should have said "feature".  I do take issue with your last 
sentence.  SAF and an ESM have everything to do with anti-virus 
protection, provided they are configured to correctly protect 
APF-authorized resources.


It [z/OS] is the only operating system out there with built-in 
anti-virus protection. On top of that, the hardware itself actively 
protects against damage through storage keys, protected memory, etc.
You have to explain to the auditors that anti-virus software is not 
needed on z/OS, because it's intrinsic to the operating system and 
the hardware.


I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and integrity and reliability) 
features for protecting against non-authorized programs. But I must 
emphasize... -->NON<--authorized programs!


When it comes to AUTHORIZED programs, z/OS's integrity (which is what 
you are talking about with "storage keys" and such) is very good, but 
of course not bulletproof. Worse though, when it comes to SECURITY, 
there are some real problems! Because with the proper knowledge, it is 
TRIVIALLY EASY FOR AN AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY!


This is what mainframers constantly forget regarding security. For 
authorized programs there is no security. All that is necessary for a 
malicious program to do is to Trojan-horse its way (with the AC(1) 
attribute) into an authorized library, and you're done for!


I've never forgotten this.  That's why my APF-authorized libraries are 
severely limited in scope, and audited for any and all updates.




As far as I know there is no serious anti-virus program for 
mainframes. I believe strongly that there needs to be one, but I don't 
know of one. And at this stage of the mainframe culture, I would be 
seriously suspicious of the efficacy of any program that claimed to be 
anti-virus. I don't think that a serious mainframe anti-virus program 
can exist unless and until IBM itself makes a commitment to support an 
effort to make the mainframe anti-virus proof.





www.zassure.com is the closest thing I've seen to an MVS anti-virus 
program.  After seeing a demo, I would have bought it, or recommended it 
to a client.  Check it out, you will be surprised, if not shocked.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Paul Gilmartin

On Tue, 27 Mar 2012 11:09:23 -0700, Skip Robinson wrote:

>The reason I brought up this 'vulnerability' is that we hired a consultant
>a while back to look for weaknesses. Of course they were able to logon
>with a vanilla userid that had no special authority. And this is what they
>did.
>
>We all spend a lot of time and mental energy focused on how to protect
>ourselves from sophisticated attack. We look at APF. We look at SVC
>screening. We look at access to sensitive libraries. But this particular
>'denial of service' can be accomplished by anyone with a valid userid and
>password. And *only* because we lock up users for invalid password
>attempts. I'm just sayin'...
> 
Would you and the auditors feel better if users logged on without
typing passwords, via SSH with certificates stored on their desktops?

Does SSH/SSL lock accounts on detected intrusion?

There is an SSL flavor of tn3270, isn't there?  And that would
encrypt even LAN traffic.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Skip Robinson

The reason I brought up this 'vulnerability' is that we hired a consultant 
a while back to look for weaknesses. Of course they were able to logon 
with a vanilla userid that had no special authority. And this is what they 
did. 

We all spend a lot of time and mental energy focused on how to protect 
ourselves from sophisticated attack. We look at APF. We look at SVC 
screening. We look at access to sensitive libraries. But this particular 
'denial of service' can be accomplished by anyone with a valid userid and 
password. And *only* because we lock up users for invalid password 
attempts. I'm just sayin'... 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Scott Ford 
To: IBM-MAIN@bama.ua.edu
Date:   03/27/2012 10:51 AM
Subject:    Re: Malicious Software Protection
Sent by:IBM Mainframe Discussion List 

Lets step through this logically:

TN3270 

1. Must have RACF/ACF2/TSS  userid/lid/acid
2. Must have a valid password
3. Must have valid IP address
4. Must have valid port
5. Must have Firewall rule for #3 and #4 ...

Other issues:  How many firewalls ?  How is the network architected ?

This is just a favor ..FTP the same

Scott J Ford
Software Engineer
http://www.identityforge.com

 From: Skip Robinson 
To: IBM-MAIN@bama.ua.edu 
Sent: Tuesday, March 27, 2012 1:37 PM
Subject: Re: Malicious Software Protection

We're all pretty sanguine about our mainframe invulnerability. But we 
should not overlook how one of our most valuable protections can be turned 

against us. We all have some limit set for logon attempts. If an invalid 
password is entered too many times, the userid gets suspended--or referred 

to the OS console for verification. A malicious rascal (any other kind?) 
can disable a really important userid in this way. Of course the person 
has to get into the network first and must know the userid to target, but 
beyond that no special authority is required. Even console referral would 
be disruptive to normal production. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Steve Comstock 
To:IBM-MAIN@bama.ua.edu
Date:   03/27/2012 10:22 AM
Subject:    Re: Malicious Software Protection
Sent by:IBM Mainframe Discussion List 

On 3/27/2012 10:46 AM, Greg Dorner wrote:
> Thank you, Elardus for your verbosity.
>
>
> - you can replace/fire those auditors as mentioned earlier in this 
thread
>
> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
> management
who can APPLY those recommendations.
>
> Unfortunately, we have no say with these auditors. They are working on
> behalf
of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts.
>
> The beauty of this is, someone from my company contacted the person at 
PWC
that made this claim that MCAFEE is coming out with a product, and he
backtracked, saying he may have been thinking of Mac OS. MAC OS???
>
> They just took a big chuck of our company offline for several hours to
research this phantom.

Wow. And did they reprimand this doofus in any way? Slap on
the wrist? Letter in his personnel file?

More likely he got commended for being concerned about company
security, even though he had no idea what he was talking about.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

Sorry should be flavor

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 1:49 PM, Scott Ford  wrote:

> Lets step through this logically:
>  
> TN3270 
>  
> 1. Must have RACF/ACF2/TSS  userid/lid/acid
> 2. Must have a valid password
> 3. Must have valid IP address
> 4. Must have valid port
> 5. Must have Firewall rule for #3 and #4 ...
>  
> Other issues:  How many firewalls ?  How is the network architected ?
>  
> This is just a favor ..FTP the same
> 
> Scott J Ford
> Software Engineer
> http://www.identityforge.com
>  
> 
> 
> 
> From: Skip Robinson 
> To: IBM-MAIN@bama.ua.edu 
> Sent: Tuesday, March 27, 2012 1:37 PM
> Subject: Re: Malicious Software Protection
> 
> We're all pretty sanguine about our mainframe invulnerability. But we 
> should not overlook how one of our most valuable protections can be turned 
> against us. We all have some limit set for logon attempts. If an invalid 
> password is entered too many times, the userid gets suspended--or referred 
> to the OS console for verification. A malicious rascal (any other kind?) 
> can disable a really important userid in this way. Of course the person 
> has to get into the network first and must know the userid to target, but 
> beyond that no special authority is required. Even console referral would 
> be disruptive to normal production. 
> 
> .
> .
> JO.Skip Robinson
> SCE Infrastructure Technology Services
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   Steve Comstock 
> To:IBM-MAIN@bama.ua.edu
> Date:   03/27/2012 10:22 AM
> Subject:Re: Malicious Software Protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> On 3/27/2012 10:46 AM, Greg Dorner wrote:
>> Thank you, Elardus for your verbosity.
>> 
>> 
>> - you can replace/fire those auditors as mentioned earlier in this 
> thread
>> 
>> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
>> management
> who can APPLY those recommendations.
>> 
>> Unfortunately, we have no say with these auditors. They are working on
>> behalf
> of the Feds, and if we don't comply we can lose billions of $$ in federal 
> contracts.
>> 
>> The beauty of this is, someone from my company contacted the person at 
> PWC
> that made this claim that MCAFEE is coming out with a product, and he
> backtracked, saying he may have been thinking of Mac OS. MAC OS???
>> 
>> They just took a big chuck of our company offline for several hours to
> research this phantom.
> 
> Wow. And did they reprimand this doofus in any way? Slap on
> the wrist? Letter in his personnel file?
> 
> More likely he got commended for being concerned about company
> security, even though he had no idea what he was talking about.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

Lets step through this logically:

TN3270 

1. Must have RACF/ACF2/TSS  userid/lid/acid
2. Must have a valid password
3. Must have valid IP address
4. Must have valid port
5. Must have Firewall rule for #3 and #4 ...

Other issues:  How many firewalls ?  How is the network architected ?

This is just a favor ..FTP the same

Scott J Ford
Software Engineer
http://www.identityforge.com

 From: Skip Robinson 
To: IBM-MAIN@bama.ua.edu 
Sent: Tuesday, March 27, 2012 1:37 PM
Subject: Re: Malicious Software Protection

We're all pretty sanguine about our mainframe invulnerability. But we 
should not overlook how one of our most valuable protections can be turned 
against us. We all have some limit set for logon attempts. If an invalid 
password is entered too many times, the userid gets suspended--or referred 
to the OS console for verification. A malicious rascal (any other kind?) 
can disable a really important userid in this way. Of course the person 
has to get into the network first and must know the userid to target, but 
beyond that no special authority is required. Even console referral would 
be disruptive to normal production. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Steve Comstock 
To:    IBM-MAIN@bama.ua.edu
Date:   03/27/2012 10:22 AM
Subject:        Re: Malicious Software Protection
Sent by:        IBM Mainframe Discussion List 

On 3/27/2012 10:46 AM, Greg Dorner wrote:
> Thank you, Elardus for your verbosity.
>
>
> - you can replace/fire those auditors as mentioned earlier in this 
thread
>
> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
> management
who can APPLY those recommendations.
>
> Unfortunately, we have no say with these auditors. They are working on
> behalf
of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts.
>
> The beauty of this is, someone from my company contacted the person at 
PWC
that made this claim that MCAFEE is coming out with a product, and he
backtracked, saying he may have been thinking of Mac OS. MAC OS???
>
> They just took a big chuck of our company offline for several hours to
research this phantom.

Wow. And did they reprimand this doofus in any way? Slap on
the wrist? Letter in his personnel file?

More likely he got commended for being concerned about company
security, even though he had no idea what he was talking about.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Skip Robinson

We're all pretty sanguine about our mainframe invulnerability. But we 
should not overlook how one of our most valuable protections can be turned 
against us. We all have some limit set for logon attempts. If an invalid 
password is entered too many times, the userid gets suspended--or referred 
to the OS console for verification. A malicious rascal (any other kind?) 
can disable a really important userid in this way. Of course the person 
has to get into the network first and must know the userid to target, but 
beyond that no special authority is required. Even console referral would 
be disruptive to normal production. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Steve Comstock 
To: IBM-MAIN@bama.ua.edu
Date:   03/27/2012 10:22 AM
Subject:    Re: Malicious Software Protection
Sent by:IBM Mainframe Discussion List 

On 3/27/2012 10:46 AM, Greg Dorner wrote:
> Thank you, Elardus for your verbosity.
>
>
> - you can replace/fire those auditors as mentioned earlier in this 
thread
>
> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
> management
who can APPLY those recommendations.
>
> Unfortunately, we have no say with these auditors. They are working on
> behalf
of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts.
>
> The beauty of this is, someone from my company contacted the person at 
PWC
that made this claim that MCAFEE is coming out with a product, and he
backtracked, saying he may have been thinking of Mac OS. MAC OS???
>
> They just took a big chuck of our company offline for several hours to
research this phantom.

Wow. And did they reprimand this doofus in any way? Slap on
the wrist? Letter in his personnel file?

More likely he got commended for being concerned about company
security, even though he had no idea what he was talking about.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Lloyd Fuller

And, if someone builds an anti-virus program for z/OS, please tell me before 
you 
announce it publicly.  I know some out-source companies I would like to buy 
stock in because MIPS are going way up.

Lloyd

- Original Message 
From: David Cole 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, March 27, 2012 1:01:34 PM
Subject: Re: Malicious Software Protection

At 3/27/2012 11:19 AM, Pinnacle wrote:
> There is a mainframe product that protects against malicious software. It's 
>called SAF, and it interfaces with ESM's like RACF, or ACF2, or TopSecret.

"SAF" is not a product. It stands for "System Access Facility" and it is 
nothing 
more than an interface within z/OS into which a security system (such as ACF2, 
TopSecret and any ryo security system) can plug into to receive and respond to 
security calls. It really has nothing to do with anti-virus protection. For 
more 
information, see 
"<http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsecurity/zsecc_030.htm>http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsecurity/zsecc_030.htm
 "

> It [z/OS] is the only operating system out there with built-in anti-virus 
>protection. On top of that, the hardware itself actively protects against 
>damage 
>through storage keys, protected memory, etc.
> You have to explain to the auditors that anti-virus software is not needed on 
>z/OS, because it's intrinsic to the operating system and the hardware.

I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and integrity and reliability) features for 
protecting against non-authorized programs. But I must emphasize... 
-->NON<--authorized programs!

When it comes to AUTHORIZED programs, z/OS's integrity (which is what you are 
talking about with "storage keys" and such) is very good, but of course not 
bulletproof. Worse though, when it comes to SECURITY, there are some real 
problems! Because with the proper knowledge, it is TRIVIALLY EASY FOR AN 
AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY!

This is what mainframers constantly forget regarding security. For authorized 
programs there is no security. All that is necessary for a malicious program to 
do is to Trojan-horse its way (with the AC(1) attribute) into an authorized 
library, and you're done for!

This is something I've brought up on this listserv from time to time before. In 
particular, for more information, please read a prior post of mine at 
"<https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches>https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
 ".

And please... stop confusing security with integrity. They are not the same. 
The 
"hardware protections" that so many people mention are not security 
protections, 
they are integrity protections. They help to keep careless programs from 
accidentally breaking things. When it comes to authorized programs, these 
"hardware protections" offer no protection at all!

As far as I know there is no serious anti-virus program for mainframes. I 
believe strongly that there needs to be one, but I don't know of one. And at 
this stage of the mainframe culture, I would be seriously suspicious of the 
efficacy of any program that claimed to be anti-virus. I don't think that a 
serious mainframe anti-virus program can exist unless and until IBM itself 
makes 
a commitment to support an effort to make the mainframe anti-virus proof.

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Steve Comstock


On 3/27/2012 10:46 AM, Greg Dorner wrote:

Thank you, Elardus for your verbosity.


- you can replace/fire those auditors as mentioned earlier in this thread

- As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
management

who can APPLY those recommendations.


Unfortunately, we have no say with these auditors. They are working on
behalf

of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts.


The beauty of this is, someone from my company contacted the person at PWC

that made this claim that MCAFEE is coming out with a product, and he
backtracked, saying he may have been thinking of Mac OS. MAC OS???


They just took a big chuck of our company offline for several hours to

research this phantom.

Wow. And did they reprimand this doofus in any way? Slap on
the wrist? Letter in his personnel file?

More likely he got commended for being concerned about company
security, even though he had no idea what he was talking about.




Thank you all for your input!



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread retired mainframer

Since you have one of the security products installed and heavily
configured, why not identify that as your protection tool.  Maybe even
demonstrate that controls prevent unauthorized updates to system and APF
datasets and the IPL text.  Given z/OS's statement of integrity, if the
malicious software cannot execute privileged it can't do any real damage.

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>: Behalf Of Greg Dorner
:>: Sent: Tuesday, March 27, 2012 8:07 AM
:>: To: IBM-MAIN@bama.ua.edu
:>: Subject: Malicious Software Protection
:>:
:>: Dear IBM-MAINers,
:>:
:>: Our auditors are insisting that we install a product that protects
:>: against malicious software (viruses, worms, trojans, etc.).
:>:
:>: Does anyone know of a product that does this? I heard that McAfee is
:>: coming out with a z/OS product "later this year", but I called them and
:>: they had no idea what I was talking about.
:>:
:>: z/OS, with proper security controls (and believe me - we have LOTS!)
:>: should not have to worry about such things, at least that's what I've
:>: always heard.
:>:
:>: Any input on this topic would be GREATLY appreciated!!
:>:
:>: Thanks,
:>: Greg Dorner, WPS Insurance Corp.
:>:
:>: --
:>: For IBM-MAIN subscribe / signoff / archive access instructions,
:>: send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread David Cole

At 3/27/2012 11:19 AM, Pinnacle wrote:
There is a mainframe product that protects against malicious
software. It's called SAF, and it interfaces with ESM's like RACF,
or ACF2, or TopSecret.

"SAF" is not a product. It stands for "System Access Facility" and it
is nothing more than an interface within z/OS into which a security
system (such as ACF2, TopSecret and any ryo security system) can plug
into to receive and respond to security calls. It really has nothing
to do with anti-virus protection. For more information, see
"http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsecurity/zsecc_030.htm
"

It [z/OS] is the only operating system out there with built-in
anti-virus protection. On top of that, the hardware itself actively
protects against damage through storage keys, protected memory, etc.
You have to explain to the auditors that anti-virus software is not
needed on z/OS, because it's intrinsic to the operating system and
the hardware.

I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and integrity and reliability)
features for protecting against non-authorized programs. But I must
emphasize... -->NON<--authorized programs!

When it comes to AUTHORIZED programs, z/OS's integrity (which is what
you are talking about with "storage keys" and such) is very good, but
of course not bulletproof. Worse though, when it comes to SECURITY,
there are some real problems! Because with the proper knowledge, it
is TRIVIALLY EASY FOR AN AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY!

This is what mainframers constantly forget regarding security. For
authorized programs there is no security. All that is necessary for a
malicious program to do is to Trojan-horse its way (with the AC(1)
attribute) into an authorized library, and you're done for!

This is something I've brought up on this listserv from time to time
before. In particular, for more information, please read a prior post
of mine at
"https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
".

And please... stop confusing security with integrity. They are not
the same. The "hardware protections" that so many people mention are
not security protections, they are integrity protections. They help
to keep careless programs from accidentally breaking things. When it
comes to authorized programs, these "hardware protections" offer no
protection at all!

As far as I know there is no serious anti-virus program for
mainframes. I believe strongly that there needs to be one, but I
don't know of one. And at this stage of the mainframe culture, I
would be seriously suspicious of the efficacy of any program that
claimed to be anti-virus. I don't think that a serious mainframe
anti-virus program can exist unless and until IBM itself makes a
commitment to support an effort to make the mainframe anti-virus proof.

Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX: 540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

Greg,

Gil's points were excellent also as well as the other folks talking about 
RACF..etc...


Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 12:46 PM, Greg Dorner  wrote:

> Thank you, Elardus for your verbosity. 
> 
> 
> - you can replace/fire those auditors as mentioned earlier in this thread
> 
> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management 
> who can APPLY those recommendations.
> 
> Unfortunately, we have no say with these auditors. They are working on behalf 
> of the Feds, and if we don't comply we can lose billions of $$ in federal 
> contracts. 
> 
> The beauty of this is, someone from my company contacted the person at PWC 
> that made this claim that MCAFEE is coming out with a product, and he 
> backtracked, saying he may have been thinking of Mac OS. MAC OS??? 
> 
> They just took a big chuck of our company offline for several hours to 
> research this phantom.
> 
> Thank you all for your input! 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Tony Harminc

On 27 March 2012 11:06, Greg Dorner  wrote:

> Our auditors are insisting that we install a product that protects against 
> malicious software (viruses, worms, trojans, etc.).

But have they asked you about the powerful and dangerous AMASPZAP yet?
They aren't Real Auditors until they confront you about that.

> Does anyone know of a product that does this? I heard that McAfee is coming 
> out with a z/OS product "later this year", but I called them and they had no 
> idea what I was talking about.

One approach is to play stupid the whole way.

Malicious software - what is that? Virus? Worm? Trojan? No, I am not
aware of any such thing. Could you please give an example of what you
are talking about? Ah - you suggest general protection against not yet
identified threats? In your wide experience of auditing other
companies, what product(s) to do this have you found most commonly in
use on z/OS? What is the performance impact of these products? Could
you direct me to some vendor-independent studies of their
price/performance? Etc, etc.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Greg Dorner

Thank you, Elardus for your verbosity. 


- you can replace/fire those auditors as mentioned earlier in this thread

- As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management 
who can APPLY those recommendations.

Unfortunately, we have no say with these auditors. They are working on behalf 
of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts. 

The beauty of this is, someone from my company contacted the person at PWC that 
made this claim that MCAFEE is coming out with a product, and he backtracked, 
saying he may have been thinking of Mac OS. MAC OS??? 

They just took a big chuck of our company offline for several hours to research 
this phantom.

Thank you all for your input! 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Greg Dorner

No,. I'm not serious. But the auditors at PWC are.  I'm practicing my 
belly-laugh for when they actually want to discuss the issue. You are all 
telling me what I already knew, but I just wanted to get the feedback so it 
isn't just my understanding of it. 

Thanks everyone, for all the good quotes, quips, and entertainment!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Elardus Engelbrecht

Greg Dorner wrote:

>Our auditors are insisting that we install a product that protects against 
>malicious software (viruses, worms, trojans, etc.).

Groan, you can replace/fire those auditors as mentioned earlier in this 
thread, but ... ;-D

You have several choices.

1. Ask them to give reasons, examples and recommended vendors of such software. 

2. Ask them to define malicious software, despite your description above. 
Seriously.

3. For native z/OS, they will have a hard way to get any vendors at all which 
can supply such software. Tell me if you can catch these vendors.

4. Despite point 3, there are 'scanners' which can search z/OS on various areas 
to look for 'holes'. They cost $$$ and is vendor specific. 

5. Get 'penetration teams' or 'white hat hackers'. You have lots of $$$, do 
you? :-)

6. z/OS has very good security measures provided you have your controls in 
place. APF, parmlib settings, RACF, SMF, etc. are examples. See other's replies 
on this fact.

7. Speaking of RACF, there are third party RACF [or other ESM] administration 
and audit tools which could ease your work.

8. Weakest links are usually 'insiders'. They are the greatest threats unless 
I'm mistaken. They are usually after your 'live and sensitive production' data.

9. For z/Linux, USS, etc, there MAY be commercial or open-source antivirus 
software available, AFAIK.
(USS - Unix System Service(s) - for those TLA haters... :-D )

10. Give them IBM's Statement of Integrity. APAR reasons for security are 
hidden and you are usually asked to apply them because of some 'vulnurability' 
which IBM usually declines to divulge.

11. Ask those auditors if they have any tools to do the checks for such tools 
against malicous software THEMSELVES! This will silence them properly!

>z/OS, with proper security controls (and believe me - we have LOTS!) should 
>not have to worry about such things, at least that's what I've always heard.

Of course, but see above.

>Any input on this topic would be GREATLY appreciated!!

As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management who 
can APPLY those recommendations.

HTH!

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Anne & Lynn Wheeler

scott_j_f...@yahoo.com (Scott Ford) writes:
> You can't be serious...never never heard of anyone developing a virus
> for mainframes, I understand the fear, but firewalls, network apps do
> rat in front of the mainframe

this discussion group, mailing list originated on BITNET ... recent
discussion (with wiki references)
http://www.garlic.com/~lynn/2012e.html#19 Inventor of e-mail honored by 
Smithsonian

really long winded recent post in linkedin MainframeZone group
http://www.garlic.com/~lynn/2012d.html#49 Do you know where all your sensitive 
data is located?

mentions the "xmas" exec nov1987 ... reference from vmshare archive
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB

was almost exactly a year before the morris worm on the internet.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

2012-03-27 Thread Paul Gilmartin

On Tue, 27 Mar 2012 11:15:52 -0400, Gross, Randall [GCG-PFS] wrote:

>Ask your auditor to recommend one for the mainframe ;-)
> 
That's likely not the auditor's job.  But if he knows of none, it is
his prerogative to assign a failing grade.

However, what body certifies the available commercial AV
products for PCs?  Would RACF pass that certification?  Would
someone have to pay for it?

How about penetration tests?  Install a known virus in files
on both PC and z.  Run PC virus scanners.  They'll report it.
Is there anything that will scan (all!) z/OS data sets and
report the virus?  That z/OS itself is not infected may be of
no import; the criterion may be that the latent presence of
an agent infectious to other systems must not be tolerated.
In this spirit, ClamAV for Linux scans Linux mail folders and
reports (eliminates?) malware that is harmless to Linux
but infectious to Windows.

It's a shame that the insecurities of Windows impel such
mickeymouse on better OSes.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection

Sorry should be 'do that in front of the mainframe'

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Mar 27, 2012, at 12:07 PM, Scott Ford  wrote:

> You can't be serious...never never heard of anyone developing a virus for 
> mainframes, I understand the fear, but firewalls, network apps do rat in 
> front of the mainframe
> 
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On Mar 27, 2012, at 11:06 AM, Greg Dorner  wrote:
> 
>> Dear IBM-MAINers,
>> 
>> Our auditors are insisting that we install a product that protects against 
>> malicious software (viruses, worms, trojans, etc.).
>> 
>> Does anyone know of a product that does this? I heard that McAfee is coming 
>> out with a z/OS product "later this year", but I called them and they had no 
>> idea what I was talking about.
>> 
>> z/OS, with proper security controls (and believe me - we have LOTS!) should 
>> not have to worry about such things, at least that's what I've always heard.
>> 
>> Any input on this topic would be GREATLY appreciated!!
>> 
>> Thanks, 
>> Greg Dorner, WPS Insurance Corp.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Malicious Software Protection