Re: auditor request question

[Shmuel Metz (Seymour J.)]

In
<1654937378-1281569019-cardhu_decombobulator_blackberry.rim.net-19398315...@bda026.bisx.prod.on.blackberry>,
on 08/11/2010
   at 11:23 PM, Ted MacNEIL  said:

>But, there is a blood test (PSA) that will do the same thing).

By all means rely on that advise; I'll continue to rely on the medical
literature instead. Folks; this "matter of semantics" is a
life-or-death issue, so discuss it with your doctor instead of relying
on uninformed medical claims here.
 
-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: auditor request question

[Shmuel Metz (Seymour J.)]

In
<1491318961-1281558009-cardhu_decombobulator_blackberry.rim.net-4985524...@bda026.bisx.prod.on.blackberry>,
on 08/11/2010
   at 08:20 PM, Ted MacNEIL  said:

>4. Are you attempting to hijack this thread, or to belittle a valid
>concern?

No.
 
-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: auditor request question

[Peter Nuttall]

> >> <>This has been an interesting thread. It seems we all really
> >> ENJOY auditors... Can someone say prostate exam?
> >>
> >> Isn't that essentially a different kind of audit ???
>
> -
>--- Yes it is, but I'm not sure which one is more of an insult
> to a man's basic dignity. :-)


Well, I came up with a different solution  I married one  :-)  
(Admittedly, she's not an IT Auditor, but an auditor nonetheless  )
 

This e-mail message, including any attachments transmitted with it, is 
CONFIDENTIAL and may contain legally privileged information. This message is 
intended solely for the use of the individual or entity to whom it is 
addressed. If you have received this message in error, please notify us 
immediately and delete it from your system. Please visit our website to read 
the full disclaimer: http://www.euroclear.com/site/public/disclaimer

Re: auditor request question

[Bob Woodside]

On Wednesday 11 August 2010 19:58, Rick Fochtman wrote:
> ---
>---
>
> >> <>This has been an interesting thread. It seems we all really
> >> ENJOY auditors... Can someone say prostate exam?
> >>
> >> Isn't that essentially a different kind of audit ???
>
> -
>--- Yes it is, but I'm not sure which one is more of an insult
> to a man's basic dignity. :-)

Having been through the full course of the medical variety - PSA, 
digital, biopsy (I flunked), radiation, and semi-annual exams 
thereafter...I vote for the auditors that triggered this thread as the 
greater affront.  :-)


Cheers,
Bob

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

Re: auditor request question

[Rick Fochtman]

--


<>This has been an interesting thread. It seems we all really ENJOY
auditors... Can someone say prostate exam?

Isn't that essentially a different kind of audit ???




Yes it is, but I'm not sure which one is more of an insult to a man's 
basic dignity. :-)


Rick

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

Re: auditor request question

[Rick Fochtman]

-
I think the valid question here is #3 - Why would you do that? I don't 
know about everyone else on this forum, but I have too much to do to try 
and get an operator fired in this way. And if you ever got caught doing 
this, would you really want to lose your own job?


This has been an interesting thread. It seems we all really ENJOY 
auditors... Can someone say prostate exam?

--
If I wanted to get an operator fired, I'd have to come up with far 
better cause than questionable use of system commands.


In the city of Chicago, there are a number of shops where the operators 
are unionized, either Teamsters or Internation Brotherhood of Postal 
Workers. Supposedly, this is for the protection of the operators, so 
they can't be arbitrarily fired. HORSEFEATHERS! It's just because the 
union wants to collect dues money! In one shop, the unionized operators 
took some serious hits: they lost a week of vacation time and instead of 
100% Major Medical/Hospitalization coverage, their coverage dropped to 
80%. And the staff was small enough that dues were paid by payroll 
deduction.


Dumb move, folks. You didn't do your homework!

Any operator (or any other employee) that acts in a malicious fashion 
deserves to be fired.


An incompetent operator (or any other employee)  should be trained; if 
training oppurtunities are refused, let him/her go and "explore other 
challenges".


Rick

(Bob, do you remember one very oversized operator?)

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

Re: auditor request question

[Ted MacNEIL]

>This has been an interesting thread.  It seems we all really ENJOY auditors... 
> Can someone say prostate exam?

Bummer! (Sorry, couldn't resist).

But, there is a blood test (PSA) that will do the same thing).

In the last company I worked for, I convinced the powers that be to elongate 
the time-out for users, enforce them all to go through supersession (or 
whatever it's called, now), and have a 10-minute time out on supersession --- 
without logging them off.
Some were still on real 3270's, so a screensaver password wasn't an option.

This was more to save resource costs due to multiple logins, which appealed to 
the capacity analyst in me.
But, it was more convenient (aka faster) for the users.

The lock function under supersession had been disabled at the request of one 
department.
And, this same department slowed down the implementation.

Quess which department.

Give me an 'A'!
Give me a  'U'!

(You get the picture)

It was a case of they'd never heard, or thought of it, so it couldn't be a 
standard practice.

(8-{]}

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

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

Re: auditor request question

[Dave Kopischke]

On Wed, 11 Aug 2010 17:51:45 -0400, Burrell, C. Todd (CDC/OCOO/ITSO) 
(CTR) wrote:

>
>This has been an interesting thread.  It seems we all really ENJOY
>auditors...  Can someone say prostate exam?
>

Isn't that essentially a different kind of audit ???

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

Re: auditor request question

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

I think the valid question here is #3 - Why would you do that?   I don't
know about everyone else on this forum, but I have too much to do to try
and get an operator fired in this way.  And if you ever got caught doing
this, would you really want to lose your own job?  

This has been an interesting thread.  It seems we all really ENJOY
auditors...  Can someone say prostate exam?

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Wednesday, August 11, 2010 4:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

>So if I want to get an operator fired, I'll just have my privileged
task issue a $PJ1-, using that operator's console id?

1. What are you doing with a privileged task?
2. Don't sources of commands show up in SYSLOG?
3. Why would you do that?
4. Are you attempting to hijack this thread, or to belittle a valid
concern?

Most shops don't allow other types of ids to be shared, so why should
console ids be so?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

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

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

Re: auditor request question

[Ted MacNEIL]

>So if I want to get an operator fired, I'll just have my privileged task issue 
>a $PJ1-, using that operator's console id?

1. What are you doing with a privileged task?
2. Don't sources of commands show up in SYSLOG?
3. Why would you do that?
4. Are you attempting to hijack this thread, or to belittle a valid concern?

Most shops don't allow other types of ids to be shared, so why should console 
ids be so?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

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

Re: auditor request question

[Dave Kopischke]

On Tue, 10 Aug 2010 14:28:20 -0500, Pommier, Rex R. wrote:

>Quick question.  Do you require your operations staff to log onto the
>z/OS consoles?  Our auditors are claiming this is "industry standard"
>and so we need to be doing it, even though our consoles are all behind
>locked doors.
>

   We have two consoles physically located in the data center that do not 
require logon.

   We have several others defined that can be accessed remotely that do 
require logon.

   So it depends

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

Re: auditor request question

[Pommier, Rex R.]

We still do share userids between the operators.  The auditors squawk
about that one every time we are audited.  They usually quiet down when
we explain that we have a total of 4 operators covering 2.5 shifts as
well as weekend support.  These operators need to move quickly from the
machine room to the console area to the 2 different print areas and back
again.  We would either have to assign each operator 4 different IDs or
have them spend an inordinate amount of time signing off one session so
they can sign onto another one.  The auditors complain about
accountability.  As others have pointed out, we simply explain that it
is easy to figure out who did what simply by time of day.

Rex



Our main issue years ago was that operators would share userids.  The
auditors LOVED that one.

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 

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

Re: auditor request question

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

In most small shops the need for extensive operator auditing and
security is not needed for accountability (IMHO).  We normally have a
few operators on shift at one time, so if something happens on the
console we would be able to narrow it down fairly quickly.  And we push
the use of SDSF for most everything except commands that absolutely have
to come from the console.  

Our main issue years ago was that operators would share userids.  The
auditors LOVED that one.

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Gerhard Postpischil
Sent: Wednesday, August 11, 2010 1:37 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

On 8/11/2010 1:00 PM, Ted MacNEIL wrote:
>> If the consoles are in a secure room that should suffice all but the
most
> stringent security standards.
>
> Unless you want to make your operators responsible for all commands
issued from their consoles.

So if I want to get an operator fired, I'll just have my 
privileged task issue a $PJ1-, using that operator's console id?




Gerhard Postpischil
Bradford, VT

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

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

Re: auditor request question

[Gerhard Postpischil]

On 8/11/2010 1:00 PM, Ted MacNEIL wrote:

If the consoles are in a secure room that should suffice all but the most

stringent security standards.

Unless you want to make your operators responsible for all commands issued from 
their consoles.


So if I want to get an operator fired, I'll just have my 
privileged task issue a $PJ1-, using that operator's console id?





Gerhard Postpischil
Bradford, VT

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

Re: auditor request question

[Ted MacNEIL]

>If the consoles are in a secure room that should suffice all but the most
stringent security standards.   

Unless you want to make your operators responsible for all commands issued from 
their consoles.

I don't know if that would be considered stringent, but it is consistent with 
the reasoning behind one user/one userid for TSO, CICS, IMS, etc.

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

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

Re: auditor request question

[Greg Shirey]

>-Original Message-
>From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
>Sent: Wednesday, August 11, 2010 10:52 AM

>Should you allow a user simply to alternate between two?

Why not?  He or she is less likely to write them down.  

>Why should he need to remember so many?  Only the one most recent
>is useful.
>o To test that the rule is being enforced?
>o To avoid inadvertent collisions when he changes a password?

Yes.

Greg Shirey
Ben E. Keith Company 

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

Re: auditor request question

[Rick Fochtman]

---
I would definitely not call this an "industry standard"... If the 
consoles are in a secure room that should suffice all but the most 
stringent security standards.



None of you understand the basic "auditor mindset".

"If the auditor likes it, it becomes 'industry standard'"   :-)

Rick

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

Re: auditor request question

[Paul Gilmartin]

On Wed, 11 Aug 2010 09:41:50 -0500, Greg Shirey wrote:
>
>I worked at a place where the auditors suggested we should require 12
>unique passwords before we allow a user to  repeat one.  Fortunately, my
>management laughed at the idea.  And then, surprisingly, one of the

Should you allow a user simply to alternate between two?

>auditors admitted that he couldn't remember that many passwords, so he
>just used the same password each time with a two digit "counter" at the
>end which he upped each time he was forced to change.  Sheesh, talk
>about do as I say, not as I do...
>
Why should he need to remember so many?  Only the one most recent
is useful.

o To test that the rule is being enforced?

o To avoid inadvertent collisions when he changes a password?

I've dealt (perhaps too contemptuously) with a rule that required
that the new password differ from the (several) former in at least
N character positions.  It succumbed to an end-around shift of the
previous password.  How can such a rule be enforced?  If passwords
are stored encrypted by a one-way hash, the new password can be
tested for identity to any number of stored hash values, but for
similarity only to the current password entered for authentication.

-- gil

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

Re: auditor request question

[Ken Porowski]

But then you don't see the messages unless the screen saver is unlocked, 
message traffic does not count as activity for the screen saver. 

I had to get a security deviation to disable the screen saver on my console 
PC's.

-Original Message-
Mike Schwab

How about activating the System Console's PC's screen saver and putting a 
password on the PC?

On Wed, Aug 11, 2010 at 8:54 AM, Lizette Koehler  
wrote:
> Well, I might differ on the secure room part.
>
> Sometimes I have seen shops let cleaning people in to the secure room 
> that has the mainframe consoles (and other stuff) and then leave the 
> room because the cleaning materials odors are a bit strong.  In which 
> case, your secure room is no different as a lobby with mainframe consoles in 
> it.
>
> At least that is my opinion.
>
> Lizette

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

Re: auditor request question

[Mike Schwab]

How about activating the System Console's PC's screen saver and
putting a password on the PC?

On Wed, Aug 11, 2010 at 8:54 AM, Lizette Koehler
 wrote:
> Well, I might differ on the secure room part.
>
> Sometimes I have seen shops let cleaning people in to the secure room that
> has the mainframe consoles (and other stuff) and then leave the room because
> the cleaning materials odors are a bit strong.  In which case, your secure
> room is no different as a lobby with mainframe consoles in it.
>
> At least that is my opinion.
>
> Lizette

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

Re: auditor request question

[Greg Shirey]

Right, auditors always want to make suggestions.  The problem can come
if management decides to accept their suggestions at face value and
demand their implementation.

I worked at a place where the auditors suggested we should require 12
unique passwords before we allow a user to  repeat one.  Fortunately, my
management laughed at the idea.  And then, surprisingly, one of the
auditors admitted that he couldn't remember that many passwords, so he
just used the same password each time with a two digit "counter" at the
end which he upped each time he was forced to change.  Sheesh, talk
about do as I say, not as I do... 

Greg Shirey
Ben E. Keith Co. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Hal Merritt
Sent: Wednesday, August 11, 2010 9:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

Let's not give the auditors too much credit. 

I think it fair to say that we all have ways to identify what operator
did what and hold that person accountable for his/her actions. More,
most all of us protect the consoles in some way. Perhaps 'industry
standard' is a fair description. 

What many auditors are guilty of doing is identifying a potential issue,
then framing their concerns in a proposed/required solution. That is,
the auditors in question may want to see that there is some due
diligence in protecting the console resource. Something simple that they
can understand and easily test.   

What may work for some is to brush the logon requirement aside and push
the auditors for a better statement of their concerns. Then some sort of
alternate solution can be proposed. This need to happen mid way through
the process and it may be too late for the OP.   

My $0.02 
 
 

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

Re: auditor request question

[Hal Merritt]

Let's not give the auditors too much credit. 

I think it fair to say that we all have ways to identify what operator did what 
and hold that person accountable for his/her actions. More, most all of us 
protect the consoles in some way. Perhaps 'industry standard' is a fair 
description. 

What many auditors are guilty of doing is identifying a potential issue, then 
framing their concerns in a proposed/required solution. That is, the auditors 
in question may want to see that there is some due diligence in protecting the 
console resource. Something simple that they can understand and easily test.   

What may work for some is to brush the logon requirement aside and push the 
auditors for a better statement of their concerns. Then some sort of alternate 
solution can be proposed. This need to happen mid way through the process and 
it may be too late for the OP.   

My $0.02 
 
 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Joel C. Ewing
Sent: Tuesday, August 10, 2010 7:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

..snip

As others have pointed out, your auditors are all wet if they think that
practice is "standard".  Logging on to consoles that are in a restricted
access location that is always supervised is a nonsense requirement, and
if carried to its logical conclusion would require some mechanism for
enforced logoff every time an Operator's posterior left their chair --
totally impractical if you expect them to get anything useful done.

This would be a reasonable requirement only for consoles in a less
protected area that might be left unattended for an extended time.
-- 
Joel C. Ewing, Fort Smith, ARjcew...@acm.org

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

Re: auditor request question

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ken Porowski
> Sent: Wednesday, August 11, 2010 9:13 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: auditor request question
> 
> IIRC the SYSCONS (HMC Console) does not have logon capability so you
> should be able to do the reply from there in a worst case scenario 

You're right. You need to logon to the HMC itself, but you literally CANNOT do 
a LOGON from that "console". If you try, you get the message:
IEE847I LOGON NOT VALID FOR EXTENDED MCS CONSOLE

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: auditor request question

[Ken Porowski]

IIRC the SYSCONS (HMC Console) does not have logon capability so you
should be able to do the reply from there in a worst case scenario 

-Original Message-
Walt Farrell

On Tue, 10 Aug 2010 17:13:27 -0500, Pommier, Rex R.
 wrote:

>Ken,  (and any others who would like to weigh in on this),
>
>We were playing with this on our sandbox just now, and came across an 
>interesting scenario.  There are 2 of us here who are RACF SPECIAL.  As

>you know, if a SPECIAL user types in the wrong password too many times,

>instead of simply revoking their account, RACF will toss message 
>ICH301I to allow another attempt.  Unfortunately, the console and the 
>system apparently get caught in a twilight-zone type loop.  We couldn't

>log onto the console as a different ID to respond to the message 
>because all RACF logons were stacked up behind the message!  I tried to

>reply to the ICH301I message from an SDSF session and that, too, 
>locked.  Fortunately I was logged onto a different console already 
>(thanks, IBM, for not implementing console timeouts :-) ) and was able 
>to respond to the RACF message.  The affected console then rapid-fire 
>logged off and on each of the IDs that we had tried to log on to.
>
>I think that alone will probably be enough to convince management that 
>activating console logon requirements is a bad idea.
>
You might consider setting up automatic logon, and allowing the
automatic IDs the authority to issue the REPLY command.

--
Walt Farrell
IBM STSM, z/OS Security Design

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

Re: auditor request question

[Walt Farrell]

On Tue, 10 Aug 2010 17:13:27 -0500, Pommier, Rex R.
 wrote:

>Ken,  (and any others who would like to weigh in on this),
>
>We were playing with this on our sandbox just now, and came across an
>interesting scenario.  There are 2 of us here who are RACF SPECIAL.  As
>you know, if a SPECIAL user types in the wrong password too many times,
>instead of simply revoking their account, RACF will toss message ICH301I
>to allow another attempt.  Unfortunately, the console and the system
>apparently get caught in a twilight-zone type loop.  We couldn't log
>onto the console as a different ID to respond to the message because all
>RACF logons were stacked up behind the message!  I tried to reply to the
>ICH301I message from an SDSF session and that, too, locked.  Fortunately
>I was logged onto a different console already (thanks, IBM, for not
>implementing console timeouts :-) ) and was able to respond to the RACF
>message.  The affected console then rapid-fire logged off and on each of
>the IDs that we had tried to log on to.
>
>I think that alone will probably be enough to convince management that
>activating console logon requirements is a bad idea.
>
You might consider setting up automatic logon, and allowing the automatic
IDs the authority to issue the REPLY command.

-- 
Walt Farrell
IBM STSM, z/OS Security Design

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

Re: auditor request question

[Lizette Koehler]

Well, I might differ on the secure room part.

Sometimes I have seen shops let cleaning people in to the secure room that
has the mainframe consoles (and other stuff) and then leave the room because
the cleaning materials odors are a bit strong.  In which case, your secure
room is no different as a lobby with mainframe consoles in it.

At least that is my opinion.

Lizette


> C. Todd Burrell (CDC/OCOO/ITSO) (CTR) Wrote: 
> Subject: Re: auditor request question
> 
> Your auditors are wrong (as usual).  We do not require logons (except
> on
> the HMC) as all of the consoles are in a secure room requiring card key
> access.  So there has never been a need for console logons.
> 
> I would definitely not call this an "industry standard"...  If the
> consoles are in a secure room that should suffice all but the most
> stringent security standards.
> 
> C. Todd Burrell

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

Re: auditor request question

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

Your auditors are wrong (as usual).  We do not require logons (except on
the HMC) as all of the consoles are in a secure room requiring card key
access.  So there has never been a need for console logons. 

I would definitely not call this an "industry standard"...  If the
consoles are in a secure room that should suffice all but the most
stringent security standards.   

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Pommier, Rex R.
Sent: Tuesday, August 10, 2010 3:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: auditor request question

Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.

Thanks.

Rex

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

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

Re: auditor request question

[Don Imbriale]

The only shop I ever worked in that required logon for consoles did so not
for security reasons but for accountability.  Some operators had
'questionable' skills and at times dangerous commands were entered without
consulting the shift supervisor or someone on the systems staff.  This
sometimes led to serious problems.  Operators had to logon to the consoles
and they were responsible for any commands that were entered while they were
logged on, whether they entered them or not.  They got into the habit of
logging off whenever they stepped away from the console.  A real PITA, but
it satisfied management.

- Don Imbriale

On Tue, Aug 10, 2010 at 3:28 PM, Pommier, Rex R.
wrote:

> Hi List,
>
> Quick question.  Do you require your operations staff to log onto the
> z/OS consoles?  Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind
> locked doors.
>

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

Re: auditor request question

[Robert Birdsall]

All of our consoles are SMCS consoles accessed via telnet (SSL).
They all require logon.  When we had physical consoles cabled to a controller 
we did not require logon.

Our management decided that the operators should work in the new 
datacenter (before we had any production equipment there).  This did have 
the desirable side effect that we learned that there was no longer any reason 
for the operators to be physically near the machine room (printing has been 
moved to the financial center, tapes are all virtual, ...).

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

Re: auditor request question

[Rick Fochtman]

I've never seen a shop that requires operator logon to system consoles. 
All the shops I've worked in, or consulted for, have the consoles 
secured by physical security measures, including key cards and locked doors.


Rick
-
Pommier, Rex R. wrote:


Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.

Thanks.

Rex

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

 



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

Re: auditor request question

[Mike Schwab]

On Tue, Aug 10, 2010 at 7:37 PM, John McKown  wrote:
> On Tue, 2010-08-10 at 19:16 -0500, Joel C. Ewing wrote:
>>
>> As others have pointed out, your auditors are all wet if they think that
>> practice is "standard".  Logging on to consoles that are in a restricted
>> access location that is always supervised is a nonsense requirement, and
>> if carried to its logical conclusion would require some mechanism for
>> enforced logoff every time an Operator's posterior left their chair --
>> totally impractical if you expect them to get anything useful done.
>
> Ah! A way to make money! How - add on to chair which detects when the
> operator gets up and reports that to the PC which triggers software with
> talks to the 3270 to do a LOGOFF. When a person sits down, the device
> measures their weight and does a "scan" of the their posterior to
> determine who they are, sending that information to the PC software to
> perform an automatic LOGON. Brilliant!!! Or maybe scans an implanted
> microchip to do the same. Said microchip also controls doors and has
> other functionality. Big Brother Lives!
>
>>
>> This would be a reasonable requirement only for consoles in a less
>> protected area that might be left unattended for an extended time.
>
> --
> John McKown
The necessary mechanism is built into car passenger seats.  It
connects to the air bags, so that in an accident it know not to deploy
or how much gas to release.  It became required in the late 1990s when
lightweight passengers in the front seat hit air bags designed to
restrain heavier passengers.  It is also why childs seats are usually
in the rear seat anymore.
-- 
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: auditor request question

[Don Williams]

We do not. However, we do require logon for those consoles in insecure
areas.

Note: it is a bad idea to require logon on all of the consoles. There are
catch 22 situations where you can't logon, because RACF is wait for you to
reply to its request; and you can't reply because you can't logon.



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Pommier, Rex R.
> Sent: Tuesday, August 10, 2010 3:28 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: auditor request question
> 
> Hi List,
> 
> Quick question.  Do you require your operations staff to log onto the
> z/OS consoles?  Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind
> locked doors.
> 
> Thanks.
> 
> Rex
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: auditor request question

[John McKown]

On Tue, 2010-08-10 at 19:16 -0500, Joel C. Ewing wrote:
> On 08/10/2010 02:28 PM, Pommier, Rex R. wrote:
> > Hi List,
> > 
> > Quick question.  Do you require your operations staff to log onto the
> > z/OS consoles?  Our auditors are claiming this is "industry standard"
> > and so we need to be doing it, even though our consoles are all behind
> > locked doors.
> > 
> > Thanks.
> > 
> > Rex
> ...
> 
> As others have pointed out, your auditors are all wet if they think that
> practice is "standard".  Logging on to consoles that are in a restricted
> access location that is always supervised is a nonsense requirement, and
> if carried to its logical conclusion would require some mechanism for
> enforced logoff every time an Operator's posterior left their chair --
> totally impractical if you expect them to get anything useful done.

Ah! A way to make money! How - add on to chair which detects when the
operator gets up and reports that to the PC which triggers software with
talks to the 3270 to do a LOGOFF. When a person sits down, the device
measures their weight and does a "scan" of the their posterior to
determine who they are, sending that information to the PC software to
perform an automatic LOGON. Brilliant!!! Or maybe scans an implanted
microchip to do the same. Said microchip also controls doors and has
other functionality. Big Brother Lives!

> 
> This would be a reasonable requirement only for consoles in a less
> protected area that might be left unattended for an extended time.

--
John McKown

How can you tell if a balloon is a hippie?

It gets high on helium!

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

Re: auditor request question

[Joel C. Ewing]

On 08/10/2010 02:28 PM, Pommier, Rex R. wrote:
> Hi List,
> 
> Quick question.  Do you require your operations staff to log onto the
> z/OS consoles?  Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind
> locked doors.
> 
> Thanks.
> 
> Rex
...

As others have pointed out, your auditors are all wet if they think that
practice is "standard".  Logging on to consoles that are in a restricted
access location that is always supervised is a nonsense requirement, and
if carried to its logical conclusion would require some mechanism for
enforced logoff every time an Operator's posterior left their chair --
totally impractical if you expect them to get anything useful done.

This would be a reasonable requirement only for consoles in a less
protected area that might be left unattended for an extended time.
-- 
Joel C. Ewing, Fort Smith, ARjcew...@acm.org

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

Re: auditor request question

[Dale McCart]

We do not require console logon, except for the HMC. 
Access to areas that have consoles are by tracked card key.
All guests must sign in and out on a log. 
No unescorted visitors are allowed anywhere in the building.

Dale McCart 
 Senior Systems Programmer / zSeries, z/OS, z/VM, zLinux 
 Kawasaki Motors Corp., U.S.A. 
 9950 Jeronimo Rd. 
 Irvine, California 92618-2084 
Telephone: (949) 770-0400 extension 2316 
 E-mail: dale.mcc...@kmc-usa.com 




"Pommier, Rex R."  
Sent by: IBM Mainframe Discussion List 
08/10/2010 12:29 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
cc

Subject
auditor request question






Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.

Thanks.

Rex

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


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

Re: auditor request question

[Pommier, Rex R.]

Ken,  (and any others who would like to weigh in on this),

We were playing with this on our sandbox just now, and came across an
interesting scenario.  There are 2 of us here who are RACF SPECIAL.  As
you know, if a SPECIAL user types in the wrong password too many times,
instead of simply revoking their account, RACF will toss message ICH301I
to allow another attempt.  Unfortunately, the console and the system
apparently get caught in a twilight-zone type loop.  We couldn't log
onto the console as a different ID to respond to the message because all
RACF logons were stacked up behind the message!  I tried to reply to the
ICH301I message from an SDSF session and that, too, locked.  Fortunately
I was logged onto a different console already (thanks, IBM, for not
implementing console timeouts :-) ) and was able to respond to the RACF
message.  The affected console then rapid-fire logged off and on each of
the IDs that we had tried to log on to.

I think that alone will probably be enough to convince management that
activating console logon requirements is a bad idea.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ken Porowski
Sent: Tuesday, August 10, 2010 3:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

Sort of

We run LOGON=AUTO but have OPERCMDS restricted so that the only commands
that can be issued without a (user) logon are display and control
commands (K E,1 etc)

We also use automation to perform an unconditional LOGOFF 15 minutes
after a LOGON (timer reset with next LOGON).  Not exactly an inactivity
timeout (I could be actively issuing commands for 15 minutes and the
LOGOFF will still happen).  A PITA at times but that's rare. 

Even in a controlled access area there are still 'unauthorized'
personnel wandering around (cleaning crew, electricians, security
guards, distributed systems folks, maintenance crew, etc.).  Generally
trustworthy to keep their mitts off the consoles but I wouldn't bet my
job on it.

We've had no major issues with the requirement other than the expected
bit of grumbling at the start.

I only wish you could logon to more than one system in a plex at the
same time (there was a thread about this earlier).


-Original Message-
Pommier, Rex R.

Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.

Thanks.

Rex

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

Re: auditor request question

[Pommier, Rex R.]

Ted,

I'm with you on this, but I left out some details.  To specifically
answer your questions, it depends on what the definition of SME actually
means.  If it means the tech support guys at the site, that would be me,
and I say "don't do it".  Unfortunately management overrules common
sense, and since the auditors recommended we turn console logon on, and
management agreed with them.  I'm currently trying to get a gauge for
other sites, so I have additional ammunition to take back to mgmt to
reverse the ruling.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Tuesday, August 10, 2010 3:44 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

>Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind
locked doors.

At the risk of playing a tired tune, auditors don't set rules.

SME's do.
Auditors report.
Compliance officers enforce.

So, what do your SME's say?

(Subject Matter Experts)

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

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

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

Re: auditor request question

[Linda Mooney]

Hi Rex, 



We do not require logon, except for the HMC - and that because one of them is 
next to the processor , out of line of sight .  Access to areas that have 
consoles are by tracked card key.  No unescorted visitors are allowed anywhere 
in the building. 



HTH, 



Linda Mooney   
- Original Message - 
From: "Rex R. Pommier"  
To: IBM-MAIN@bama.ua.edu 
Sent: Tuesday, August 10, 2010 12:28:20 PM 
Subject: auditor request question 

Hi List, 

Quick question.  Do you require your operations staff to log onto the 
z/OS consoles?  Our auditors are claiming this is "industry standard" 
and so we need to be doing it, even though our consoles are all behind 
locked doors. 

Thanks. 

Rex 

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

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

Re: auditor request question

[Ken Porowski]

Sort of

We run LOGON=AUTO but have OPERCMDS restricted so that the only commands
that can be issued without a (user) logon are display and control
commands (K E,1 etc)

We also use automation to perform an unconditional LOGOFF 15 minutes
after a LOGON (timer reset with next LOGON).  Not exactly an inactivity
timeout (I could be actively issuing commands for 15 minutes and the
LOGOFF will still happen).  A PITA at times but that's rare. 

Even in a controlled access area there are still 'unauthorized'
personnel wandering around (cleaning crew, electricians, security
guards, distributed systems folks, maintenance crew, etc.).  Generally
trustworthy to keep their mitts off the consoles but I wouldn't bet my
job on it.

We've had no major issues with the requirement other than the expected
bit of grumbling at the start.

I only wish you could logon to more than one system in a plex at the
same time (there was a thread about this earlier).


-Original Message-
Pommier, Rex R.

Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.

Thanks.

Rex

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

Re: auditor request question

[Ted MacNEIL]

>Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind locked 
> doors.

At the risk of playing a tired tune, auditors don't set rules.

SME's do.
Auditors report.
Compliance officers enforce.

So, what do your SME's say?

(Subject Matter Experts)

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

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

Re: auditor request question

[Silvio Camplani]

We do not.

The computer room has restricted access.

Silvio Camplani
zSeries Sr. Analyst, Systems Support
Bombardier


On Tue, 10 Aug 2010 14:28 -0500, "Pommier, Rex R."
 wrote:
> Hi List,
> 
> Quick question.  Do you require your operations staff to log onto the
> z/OS consoles?  Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind
> locked doors.
> 
> Thanks.
> 
> Rex
> 

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

Re: auditor request question

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Pommier, Rex R.
Sent: Tuesday, August 10, 2010 2:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: auditor request question

Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.


I've worked in at least 9 shops where console login was possible. None
of them required this. ONLY the hardware consoles required a logon (as
opposed to the MVS consoles).

The computer rooms were limited access. So only authorized personnel
were allowed in the computer room unescorted. 

In the case of mainframe environments where the printers are in one
place, the "command center" is in another, and the tape library/ATL
equipment are in yet another, the communications equipment in yet
another, how many times would you like one person to logon to do their
work as they moved around the shop handling their duties? In all the
places where I've worked with an MVS environment, each one of those
locations had a console so that commands could be entered immediately,
if and when so needed.

I think your auditors are PAPS oriented, and not mainframe oriented.

Regards,
Steve Thompson

-- Opinions expressed by this poster do not necessarily reflect those of
poster's employer --

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

Re: auditor request question

[William Bishop]

We do not here.  Most of the sites I have been associated with did not.

However, on one occasion at a data center, an outsourcing site, we did 
require the Operators to sign-on.  This was because a specific customer's 
auditors also required it.  Also, this was at a site that had more than 
just console operator foot traffic in the data center.

The way we got around the issue of logon'ing on at IPL time and leaving it 
was to tell them that they were responsible for any commands entered on 
that session while they were logged on.  They learned real quick to make 
sure they logged off at end of shift.

Thanks

Bill Bishop

Specialist
Mainframe Support Group
Server Development & Support
Toyota Motor Engineering & Manufacturing North America, Inc.
bill.bis...@tema.toyota.com
(502) 570-6143



"McKown, John"  
Sent by: IBM Mainframe Discussion List 
08/10/2010 03:35 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Re: auditor request question






> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pommier, Rex R.
> Sent: Tuesday, August 10, 2010 2:28 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: auditor request question
> 
> Hi List,
> 
> Quick question.  Do you require your operations staff to log onto the
> z/OS consoles?  Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind
> locked doors.
> 
> Thanks.
> 
> Rex

No, we do not. Seems silly to me because there is no "inactivity timeout" 
to force a re-logon. So, if we did, the operator would LOGON at IPL and 
that would be that until the next IPL. We don't really have operators 
anyway. We have NOC people who are more PC oriented. And we have z/OS 
Production Control people who actually monitor z/OS as well. And they use 
TSO and SMCS (VTAM connected via TN3270) consoles. They do need to logon 
to the SMCS console.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


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

Re: auditor request question

[Scott Rowe]

We do not.

>>> "Pommier, Rex R."  8/10/2010 3:28 PM >>>
Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.

Thanks.

Rex

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



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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

Re: auditor request question

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pommier, Rex R.
> Sent: Tuesday, August 10, 2010 2:28 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: auditor request question
> 
> Hi List,
> 
> Quick question.  Do you require your operations staff to log onto the
> z/OS consoles?  Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind
> locked doors.
> 
> Thanks.
> 
> Rex

No, we do not. Seems silly to me because there is no "inactivity timeout" to 
force a re-logon. So, if we did, the operator would LOGON at IPL and that would 
be that until the next IPL. We don't really have operators anyway. We have NOC 
people who are more PC oriented. And we have z/OS Production Control people who 
actually monitor z/OS as well. And they use TSO and SMCS (VTAM connected via 
TN3270) consoles. They do need to logon to the SMCS console.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

auditor request question

[Pommier, Rex R.]

Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.

Thanks.

Rex

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