Re: Module description

[Robert A. Rosenberg]

At 07:53 -0500 on 11/03/2005, Shmuel Metz (Seymour J.) wrote about 
Re: Module description:



In <[EMAIL PROTECTED]>, on 11/02/2005
   at 08:46 PM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:


It is not a security breach if you are using Shadow Tables (where the
Password is NOT in the /etc/passwd file).


But does the auditor know that?



I do no know the knowledge level of the auditor or know the reasoning 
behind the request. My reply was predicated on the request being to 
see if the passwords were being stored in the file or if that field 
was only a shadow table placeholder. The simplest way to tell the 
difference is to view the table and see what is in the password field 
(ie: An encrypted password or a token).


If the intent was to see which method of password storage was used, 
then access to the file FOR THAT PURPOSE is not an exposure/breach. 
OTOH, other data in there could be of value to an audit (such as what 
the user's groups are [ie: Too much access], etc.).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bad Auditor Requests (was Module description)

[Binyamin Dissen]

On Thu, 3 Nov 2005 00:00:00 GMT Ted MacNEIL <[EMAIL PROTECTED]>
wrote:

:>>Um...sort of.  There is a directory structure, and it is maintained by hand 
(by editing the source directory -- a flat file)
:>...

:>Isn't there a CMS/CP command called DIRMaint?

I remember it as a service machine which would handle requests. It would also
keep track of free space so that one could more easily create a mini-disk.

The basic CMS command (or was it an EXEC?) was DIRECT.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 11/02/2005
   at 08:46 PM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:

>It is not a security breach if you are using Shadow Tables (where the
> Password is NOT in the /etc/passwd file). 

But does the auditor know 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 11/02/2005
   at 02:15 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said:

>Unless I misunderstand what you said, I think we're saying about the
>same thing.

No.

>But if the vendor *does* require an authorized library then the
>auditor might want to approach the vendor.

If the auditor does not trust the vendor, then inspecting the AC(1)
code is a half measure. An unauthorized program can still alter and
copy user data in order to sabotage or steal them.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 11/02/2005
   at 02:06 PM, Walt Farrell <[EMAIL PROTECTED]> said:

>I'm not sure I understand how you would expect an auditor to be able
>to verify that a vendor hadn't shipped a trojan horse.  You really
>want all  the auditors visiting all the vendors and personally
>inspecting all the code?

Why not? If they're concerned enough to visit the vendors and inspect
the AC(1) code, then why shouldn't they be concerned enough to inspect
the unprivileged code?
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bad Auditor Requests (was Module description)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 11/02/2005
   at 08:59 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>What's in a name?

In an operating system? Everything.

>Doesn't VM/SP have (or was it earlier releases?) a file with similar
>function? 

Sure, but the auditor didn't ask for it and it might not have been
legal to give it to him had he asked.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bad Auditor Requests (was Module description)

[Ted MacNEIL]

>Um...sort of.  There is a directory structure, and it is maintained by hand 
>(by editing the source directory -- a flat file)
...

Isn't there a CMS/CP command called DIRMaint?

I seem to recall using that to set up my static connections to other CMS 
mini-disks.


>Invoking DIRMAINT is not called EDITING
...

Our SYSPROG called it EDITING when you invoked the DIRM command
-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Walt Farrell]

On 11/2/2005 4:30 PM, Mark Yuhas wrote:

Thanks for the suggestions.

However, like today, I was questioned about IEECB92S.  I finally found
an APAR that describe what the module does.

I do not have the luxury of saying 'Because, IBM did it that way'.   I
have to explain or we get another mark against us in the audit report.

I thought it would be nice if I could explain and show the auditor that
IBM really did this and this is the way it is supposed to be.



For showing that "IBM really did this and this is the way it is supposed 
to be" perhaps you should just run a report from SMP/E to prove that we 
delivered a module of that name, to that library, with those link-edit 
characteristics.


Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bad Auditor Requests (was Module description)

[Phil Smith III]

Ted MacNEIL <[EMAIL PROTECTED]> wrote:
>There is a directory structure and it is maintained by a 
>utility/command/service machine called DIRMAINT.
>Invoking DIRMAINT is called EDITING.

Um...sort of.  There is a directory structure, and it is maintained by hand (by 
editing the source directory -- a flat file), by a service machine called 
DIRMAINT (IBM PP), or by any of several other ISV products.  Invoking DIRMAINT 
is not called EDITING, at least not of any of the several hundred VM shops I've 
been at.  Editing is called EDITING.

In a site with no security package, the source directory does have plaintext 
passwords in it.  That's why you keep it on a secure minidisk.

...phsiii

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Robert A. Rosenberg]

At 11:11 -0700 on 11/02/2005, Paul Gilmartin wrote about Re: Module 
description:


 > IIRC on a traditional *NIX system, /etc/passwd contains the 
password in clear text.
 The act of giving the auditor a copy (hardcopy or other) would be 
an audit violation.



No.  Encrypted.  Otherwise everyone would know everyone's password.


Yes it is stored in an encrypted form in the passwd file (when you 
are not using shadow tables). Unfortunately there is CRACK and other 
programs that will parse the password field in these records and 
report out the corresponding clear text password so gaining access to 
the file contents CAN expose the password even though it is not 
stored in clear.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Robert A. Rosenberg]

At 08:53 -0700 on 11/02/2005, Paul Gilmartin wrote about Re: Module 
description:



In a recent note, Robert A. Rosenberg said:

 > Date: Wed, 2 Nov 2005 00:38:45 -0500

 > In my opinion, the Auditor has NO valid reason to be asking this

 question about ANY IBM  (or other Vendor) supplied module. It is
 their job to KNOW this information or they are not qualified to be
 doing the audit in the first place. The only modules they have any

 > justification to be asking this type of question about is your USER
 > WRITTEN Application code and exits from IBM and other Vendor Code.



What's a "Vendor"?  Does a contractor producing a one-of-a-kind
module count as a Vendor.


That is "Work for Hire" and would fall in the "USER WRITTEN 
Application code" category since there is no real difference between 
it and code written by the customer's own programmers.


I classify "Vendor" as someone who writes a generic product and sells 
it to all comers (ex: IBM, CA, BMC, Microsoft, etc.). IOW, companies 
that sell pre-written (as opposed to custom, written under user 
supplied specs) software. This type of software would/should come 
with design documentation written by the Vendor and thus available to 
anyone who purchases the software or documentation.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Robert A. Rosenberg]

At 10:06 -0700 on 11/02/2005, Howard Brazee wrote about Re: Module description:

 >IIRC on a traditional *NIX system, /etc/passwd contains the 
password in clear text.
 >The act of giving the auditor a copy (hardcopy or other) would be 
an audit violation.


I could see someone asking for this - and if given it, he reports
about your security breach.


It is not a security breach if you are using Shadow Tables (where the 
Password is NOT in the /etc/passwd file). In that case, letting the 
auditor see the file shows that the file is "safe" and not a security 
issue.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Gerhard Adam]

>Sorry, guys, but I have to take the other side.

>The vendor has *no* control over how you implement the software. Or if
you choose to remove a piece and replace it. Or if >you configure it
such that it does not behave as it is supposed to. 

>So, take some auditors trying to grapple with a really complex issue
and you get some really foggy questions. Worse, they >are bound to be
making some really, ah, interesting 'suggestions'. 

>We gotta come up with some really good answers, and fast. IBM, your
customers are hurting here!

Which is precisely why the questions being asked are just stupid.  An
auditor's job is to validate procedures and spot check individual
elements to ensure that there are no fundamental flaws in them.  To ask
questions about specific modules is just dumb.  What could he do even
with accurate information?  That's not auditing.

It's the same in financial auditing.  An auditor will check procedures,
and even individual entries.  Might even pull some receipts and
documentation to ensure that it all matches up, but you can be assured
he's not going to go back to the original person that filed an expense
report and ask them to justify a particular meal.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Gerhard Adam]

I'm sorry but your auditor is an idiot and may in fact be violating the
terms of your vendor's license agreements (at least partially).
  
Most license agreements expressly prohibit reverse engineering licensed
code and the copyright notification makes it pretty clear that you don't
have any authority or influence over what the vendor distributes.  If
that isn't sufficient for your auditor then have him sue IBM.

>However, like today, I was questioned about IEECB92S.  I finally found
an APAR that describe what the module does.

>I do not have the luxury of saying 'Because, IBM did it that way'.   I
>have to explain or we get another mark against us in the audit report.

Might as well get a mark because it's cloudy outside.  That's just
goofy.

>I thought it would be nice if I could explain and show the auditor that
IBM really did this and this is the way it is >supposed to be.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Hal Merritt]

Sorry, guys, but I have to take the other side.

The vendor has *no* control over how you implement the software. Or if
you choose to remove a piece and replace it. Or if you configure it such
that it does not behave as it is supposed to. 

So, take some auditors trying to grapple with a really complex issue and
you get some really foggy questions. Worse, they are bound to be making
some really, ah, interesting 'suggestions'. 

We gotta come up with some really good answers, and fast. IBM, your
customers are hurting here!

My $0.02.  



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, November 01, 2005 11:54 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Module description

Shouldn't any competent auditor who is asking about a vendor's programs
know
that they have to ask the vendor, not the user?  Shouldn't your only
response have to be "Ask IBM"?

  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Auditors (was Re: Module description)

[Ted MacNEIL]

>Is there an organization that rates security 
auditors?  If not, is it time to create one?
...

My first experience with an auditor was at the Ontario Government.
I asked him what he knew about IT.
He said: “I don't have to know anything about it. I'm a chartered accountant.”
I said: “OKAY! I'm not volunteering anything. You need to know? Ask”.
I got hauled up on the carpet for being uncooperative.
My response was: “I don't know anything about chartered accountants, so I don't 
know what to tell him without him asking questions”.
I had no intention of giving the hangman any rope.

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Auditors (was Re: Module description)

[Arthur T.]

On 1 Nov 2005 09:57:53 -0800, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] (McKown, John) wrote:



Reminds me of an actual request from an auditor many years ago:


List all possible exits in every piece of software 
installed on your MVS
system. Futher detail everything that could be done by 
using those

exits.



On 1 Nov 2005 09:53:16 -0800, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] (Farley, Peter x23353) wrote:


Shouldn't any competent auditor who is asking about a 
vendor's programs know
that they have to ask the vendor, not the user?  Shouldn't 
your only

response have to be "Ask IBM"?


On 2 Nov 2005 13:30:51 -0800, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] (Mark Yuhas) wrote:


I do not have the luxury of saying 'Because, IBM did it 
that way'.   I
have to explain or we get another mark against us in the 
audit report.


 And I once had an auditor ask me, "What is RACF?".

 A good auditor (whether internal or external) helps 
us by finding potential security flaws that we missed.  The 
auditors we're discussing here merely justify their 
existence by giving black marks.  Unfortunately, some 
management and some clients look only at the auditor 
reports, but not at what they really mean.


 Is there an organization that rates security 
auditors?  If not, is it time to create one?


 We can tell management that the auditors are asking 
silly questions and that the reports they're creating are 
basically bogus [1], but it does no good; the report came 
from an auditor so it must mean something (Garbage In, 
Gospel Out).  If there were a rating org for auditors, we 
could report this silliness to them, and, eventually, show 
that audit reports from company X are not reliable.  It 
should lead to better auditing (and therefore better 
security), in the long run.


===
[1] "bogus" as used in USA and hackerdom (see the Jargon 
File).  I know that in England the word means something 
different.  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Edward E. Jaffe]

Mark Yuhas wrote:


However, like today, I was questioned about IEECB92S.  I finally found
an APAR that describe what the module does.

I do not have the luxury of saying 'Because, IBM did it that way'.   I
have to explain or we get another mark against us in the audit report.
 



I wonder what C:\WINDOWS\msagent\intl\agt040b.dll does on my Windows XP 
desktop ...


--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Mark Yuhas]

Thanks for the suggestions.

However, like today, I was questioned about IEECB92S.  I finally found
an APAR that describe what the module does.

I do not have the luxury of saying 'Because, IBM did it that way'.   I
have to explain or we get another mark against us in the audit report.

I thought it would be nice if I could explain and show the auditor that
IBM really did this and this is the way it is supposed to be.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Patrick O'Keefe]

On Wed, 2 Nov 2005 14:06:40 -0500, Walt Farrell <[EMAIL PROTECTED]>
wrote:

>...
>I'm not sure I understand how you would expect an auditor to be able to
>verify that a vendor hadn't shipped a trojan horse.  You really want all
>the auditors visiting all the vendors and personally inspecting all the
>code?
>...

Sure.  All the auditors have to do is examine all the code and look for
comments saying "Trojan Horse" or "Worm" or "Virus".  In fact, I can't
think of much I'd rather see them doing.  It would be pain supplying them
with all that source, but I don't think you would need to worry about any
technology transfer happening.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Patrick O'Keefe]

On Wed, 2 Nov 2005 11:08:26 -0500, Shmuel Metz (Seymour J.)  wrote:

>>...
>>I suppose an auditor might be trained to ask "Does the vendor say
>>these modules have to be in an authorized library?" and pass the
>>question to the vendor only if the answer is "Yes".
>
>That's reasonable if the auditor is incompetent. If the auditor is
>good then I'd want him to ensure that the vendor doesn't have any
>trojan horses in the software that my users are calling.
>...

Unless I misunderstand what you said, I think we're saying about the same
thing.

If the product was installed in an authorized library when the vendor did
not require it, there's no sense aproaching the vendor; there's a local
security issue.

But if the vendor *does* require an authorized library then the auditor
might want to approach the vendor.  Might.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Walt Farrell]

On 11/2/2005 11:16 AM, Shmuel Metz , Seymour J. wrote:

In <[EMAIL PROTECTED]>, on 11/01/2005
   at 02:29 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said:


I suppose an auditor might be trained to ask "Does the vendor say
these modules have to be in an authorized library?" and pass the
question to the vendor only if the answer is "Yes".


That's reasonable if the auditor is incompetent. If the auditor is
good then I'd want him to ensure that the vendor doesn't have any
trojan horses in the software that my users are calling.
 


I'm not sure I understand how you would expect an auditor to be able to 
verify that a vendor hadn't shipped a trojan horse.  You really want all 
the auditors visiting all the vendors and personally inspecting all the 
code?


Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bad Auditor Requests (was Module description)

[Ted MacNEIL]

>Doesn't VM/SP have (or was it earlier releases?) a file with similar
function?  I've heard my sysprog speak of editing "The Directory"
to add a user.
...

There is a directory structure and it is maintained by a 
utility/command/service machine called DIRMAINT.
Invoking DIRMAINT is called EDITING.

Some, but not all, functions are superceded by your security software.
But, all your mini-disk static allocations, accounting info, initial virtual, 
start up programme (CP, CMS, MVS, etc.) are all defined there.

Sort of like the old UADS, but with more info.

If you don't have a security package, your password is also stored there.

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Ted MacNEIL]

>IIRC on a traditional *NIX system, /etc/passwd contains the password in clear 
>text.
...

The version I used in 1976 at the University of Waterloo, did not.
As a matter of fact, we cracked it by running the encryption algorithm against 
the online dictionary used for a spell check application.
(It's common practice, now.
It was considered 'inovative' 30 years ago)

 
>The act of giving the auditor a copy (hardcopy or other) would be an audit 
>violation.
...

A colleague nearly lost his job over something similar.
We had a special flag byte stored in the user area of source PDS's.
This was not well known, and was used to 'prove' the implemented programme came 
from the staging environment (primitive; worked; home-groan).

This Q/A analyst was told (by the boss) to co-operate fully with the auditor.

The auditor asked for a 'special' directory listing showing the flag byte.

This was not supposed to be distributed outside the department; the analyst 
gave the auditor the report.

The auditor reported him for 'violating security policy'.

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Ted MacNEIL]

>No. They are, alas, rare. It is a joy to be audited by someone who
actually knows enough to be useful; if there are problems, I want to
know about them.
...

I know of two SYSPROGs that moved to audit.
They both immediately shut down holes they were using when they supported the 
systems.

And, they snooped out other holes to plug.
In general, I don't have a problem with that, but I used a couple when my boss 
told me to get something done
to reduce the chances of an IPL, but don't tell him how I did it.
It was an orphaned CSA (not eCSA), block that was left behind by a test IMS 
crash & burn.
One of the new 'auditor' had had security lock out the OM/MVS command.
By the time I got it approved to be unlocked, we had IPL'd, the IMS croaked 
again, and we re-IPL'd.
Normally, I'd frown on this approach, but there was a critical front-end 
subsystem interfacing with our POS (debit system, not piece of s**t).
It was christmas eve, sigh!
We went off the air for 19 hours (so much for 5 9's).

I got the front end moved to a production system.
-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Paul Gilmartin]

In a recent note, Staller, Allan said:

> Date: Wed, 2 Nov 2005 10:25:47 -0600
> 
> 
> 
> IIRC on a traditional *NIX system, /etc/passwd contains the password in clear 
> text.
> The act of giving the auditor a copy (hardcopy or other) would be an audit 
> violation.
> 
No.  Encrypted.  Otherwise everyone would know everyone's password.
And recent UNIX systems, in response to improvements in cryptanalysis
have moved the passwords out of /etc/passwd into a protected file
or data base.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Howard Brazee]

On 2 Nov 2005 08:26:35 -0800, [EMAIL PROTECTED] (Staller,
Allan) wrote:

>
>IIRC on a traditional *NIX system, /etc/passwd contains the password in clear 
>text. 
>The act of giving the auditor a copy (hardcopy or other) would be an audit 
>violation.

I could see someone asking for this - and if given it, he reports
about your security breach.

>Of course the fact that this is a VM system (which does not have /etc/passwd) 
>is laughable.

Except this shows that the auditor didn't know what he was doing.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Bruce Black]

That response is not PC.


No, its mainframe 

--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Staller, Allan]

IIRC on a traditional *NIX system, /etc/passwd contains the password in clear 
text. 
The act of giving the auditor a copy (hardcopy or other) would be an audit 
violation.

Of course the fact that this is a VM system (which does not have /etc/passwd) 
is laughable.

Obviously this auditor did (in Seymour's vernacular) "know enough to be useful"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bad Auditor Requests (was Module description)

[Paul Gilmartin]

In a recent note, Thomas Kern said:

> Date: Tue, 1 Nov 2005 16:41:50 -0800
> 
> My favorite auditor request was when an auditor asked for a printout from my
> VM/SP system. I had to leave the meeting before my boss could finish laughing.
> 
> The auditor wanted /etc/passwd.
> 
What's in a name?

Doesn't VM/SP have (or was it earlier releases?) a file with similar
function?  I've heard my sysprog speak of editing "The Directory"
to add a user.

I'll grant the auditor was somewhat out of his element; he was
unlikely to know what a Class G user was.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bad Auditor Requests (was Module description)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
11/01/2005
   at 04:41 PM, Thomas Kern <[EMAIL PROTECTED]> said:

>My favorite auditor request was when an auditor asked for a printout
>from my VM/SP system. I had to leave the meeting before my boss could
>finish laughing. 

>The auditor wanted /etc/passwd. 

Well that might be a problem on a level of VM that doesn't[1] support
Unix, but on z/VM that would be an easy chuckle; just run "cat
/etc/passwd" and photograph his expression when he reads the output.
IAC, were you able to keep a straight face?

[1] AFAIK that includes VM/SP and HPO, but with luck he'd make the
same request for VM/ESA or z/VM.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 11/01/2005
   at 12:54 PM, "Farley, Peter x23353" <[EMAIL PROTECTED]> said:

>Shouldn't any competent auditor who is asking about a vendor's
>programs know that they have to ask the vendor, not the user?

Yes.

>Shouldn't your only response have to be "Ask IBM"?

That response is not PC.

>Oops.  Is "competent auditor" an oxymoron?

No. They are, alas, rare. It is a joy to be audited by someone who
actually knows enough to be useful; if there are problems, I want to
know about them.

-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 11/01/2005
   at 02:29 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said:

>I suppose an auditor might be trained to ask "Does the vendor say
>these modules have to be in an authorized library?" and pass the
>question to the vendor only if the answer is "Yes".

That's reasonable if the auditor is incompetent. If the auditor is
good then I'd want him to ensure that the vendor doesn't have any
trojan horses in the software that my users are calling.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Paul Gilmartin]

In a recent note, Robert A. Rosenberg said:

> Date: Wed, 2 Nov 2005 00:38:45 -0500
> 
> At 09:02 -0800 on 11/01/2005, Mark Yuhas wrote about Module description:
> 
> >We are going through a security audit and Sarbannes-Oxley compliance.  I
> >keep getting questions about obscure [IBM] modules and their functions.
> 
> In my opinion, the Auditor has NO valid reason to be asking this
> question about ANY IBM  (or other Vendor) supplied module. It is
> their job to KNOW this information or they are not qualified to be
> doing the audit in the first place. The only modules they have any
> justification to be asking this type of question about is your USER
> WRITTEN Application code and exits from IBM and other Vendor Code.
> 
What's a "Vendor"?  Does a contractor producing a one-of-a-kind
module count as a Vendor.

I suppose it's quite reasonable for the auditor to ask to see the
source code of anything that runs in an authorized state, and the
audit trail of producing the executable from that source code,
and the source code of any language translators involved.  I
understand IBM will make source code available (other vendors
may be less cooperative) under NDA and for a price.  But who
pays?

I understand some government agencies run 'way down level OS
and other software simply because it's too costly to vet the
current versions.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Robert A. Rosenberg]

At 09:02 -0800 on 11/01/2005, Mark Yuhas wrote about Module description:


We are going through a security audit and Sarbannes-Oxley compliance.  I
keep getting questions about obscure [IBM] modules and their functions.


In my opinion, the Auditor has NO valid reason to be asking this 
question about ANY IBM  (or other Vendor) supplied module. It is 
their job to KNOW this information or they are not qualified to be 
doing the audit in the first place. The only modules they have any 
justification to be asking this type of question about is your USER 
WRITTEN Application code and exits from IBM and other Vendor Code.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bad Auditor Requests (was Module description)

[Thomas Kern]

My favorite auditor request was when an auditor asked for a printout from my
VM/SP system. I had to leave the meeting before my boss could finish laughing. 

The auditor wanted /etc/passwd. 

/Tom Kern

--- "McKown, John" <[EMAIL PROTECTED]> wrote:
> > Shouldn't any competent auditor who is asking about a 
> > vendor's programs know
> > that they have to ask the vendor, not the user?  Shouldn't your only
> > response have to be "Ask IBM"?
> > 
> > Oops.  Is "competent auditor" an oxymoron?
> > 
> Reminds me of an actual request from an auditor many years ago:
> 
> 
> List all possible exits in every piece of software installed on your MVS
> system. Futher detail everything that could be done by using those
> exits.
> 
> 





__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Patrick O'Keefe]

On Tue, 1 Nov 2005 12:54:03 -0500, Farley, Peter x23353
<[EMAIL PROTECTED]> wrote:

>Shouldn't any competent auditor who is asking about a vendor's programs
know
>that they have to ask the vendor, not the user?  Shouldn't your only
>response have to be "Ask IBM"?
>...

I suppose an auditor might be trained to ask "Does the vendor say these
modules have to be in an authorized library?" and pass the question to
the vendor only if the answer is "Yes".

>..
>>
>>We are going through a security audit and Sarbannes-Oxley compliance.  I
>>keep getting questions about obscure modules and their functions.  I
usually
>>search IBMLink for APARs that describe the module.
>...

Mark, I guess you could post the questions here.

Does the auditor ever ask "Does this Unix program really have to run
under uid(0)?"?  That's a question that vendors (including IBM) really
ought to be asked.  I think the answer is often "Yes.  We were to lazy
to make the answer 'No'".

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Farley, Peter x23353
> Sent: Tuesday, November 01, 2005 11:54 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Module description
> 
> 
> Shouldn't any competent auditor who is asking about a 
> vendor's programs know
> that they have to ask the vendor, not the user?  Shouldn't your only
> response have to be "Ask IBM"?
> 
> Oops.  Is "competent auditor" an oxymoron?
> 
> Peter 

Reminds me of an actual request from an auditor many years ago:


List all possible exits in every piece of software installed on your MVS
system. Futher detail everything that could be done by using those
exits.


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[Farley, Peter x23353]

Shouldn't any competent auditor who is asking about a vendor's programs know
that they have to ask the vendor, not the user?  Shouldn't your only
response have to be "Ask IBM"?

Oops.  Is "competent auditor" an oxymoron?

Peter 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 01, 2005 12:37 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Module description

I don't know how many releases ago, but, IBM published a manual called
Module Descriptions.  The manual contained concise information about modules
and some of the attributes.

Does IBM have anything similar now?  

We are going through a security audit and Sarbannes-Oxley compliance.  I
keep getting questions about obscure modules and their functions.  I usually
search IBMLink for APARs that describe the module.

It sure would be nice if IBM had a central place, manual or Web page, that
contained this information.

_
This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Module description

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Yuhas
> Sent: Tuesday, November 01, 2005 11:02 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Module description
> 
> 
> I don't know how many releases ago, but, IBM published a manual called
> Module Descriptions.  The manual contained concise information about
> modules and some of the attributes.
> 
> Does IBM have anything similar now?  
> 
> We are going through a security audit and Sarbannes-Oxley 
> compliance.  I
> keep getting questions about obscure modules and their functions.  I
> usually search IBMLink for APARs that describe the module.
> 
> It sure would be nice if IBM had a central place, manual or Web page,
> that contained this information.

Given the death of source code and PLMs (Program Logic Manuals), you are
likely never going to find out everything that some auditor might want.
However, you might find the following manuals somewhat helpful:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2V260/CCON
TENTS

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E460/CCON
TENTS

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3160/CCON
TENTS

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB160/CCON
TENTS


But they are unlikely to help with obscure modules, such as IGDZILLA
.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Module description

[Mark Yuhas]

I don't know how many releases ago, but, IBM published a manual called
Module Descriptions.  The manual contained concise information about
modules and some of the attributes.

Does IBM have anything similar now?  

We are going through a security audit and Sarbannes-Oxley compliance.  I
keep getting questions about obscure modules and their functions.  I
usually search IBMLink for APARs that describe the module.

It sure would be nice if IBM had a central place, manual or Web page,
that contained this information.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html