ALL OBJect- Hey what do you think Wayne O Evans? MR. Security I know what you would say!

Let me ask everyone out there.!

Please give me your credit card number and then also you check book id.
*  I wont use it, I just need it to put into a data base so I can write
programs on how to use credit cards and what they can do for people and how
many people have credit cards and check books.
Oh! and yes, you would not mind if I shared this with an internet chat room
so they could test my program in production for me.

THINK everyone!  Our companies DATA is confidential and our business systems
run our companies.  If we are a public company then by GOD you must not have
anyone able to manipulate your data, assume authority or know your security.
That is why most of us have a Security officer
.


 -----Original Message-----
From:   Henrik Krebs [mailto:hkrebs@hkrebs.dk] 
Sent:   Thursday, September 14, 2000 6:15 AM
To:     MIDRANGE-L
Subject:        Re: Why do software companies always want ALLOBJ

Alan: In the theorie you are right. But did you notice my findings
when I want e.g. to create a user profile? The customer often do not
care what I do - beeing buzy with 'their own' problems. To limit *ALL
to testenvironment only, requires a good Change Management System
which even-so-good can be fooled anyway, intentionally or accidently.
It also requires much much more than "Infrequent Use Of" the customers
resources (man power) for testing and 'putting into production'. There
is nothing that would like more than getting a 100% guarantie from the
customer, that any system failure (production) was the responsability
of the customer. Because a limitation of the access to Production has
no meaning if you just accept my "It works - do this and that in the
production environment" without any considerations. Can we set up a
contract working for your company: a) I make the changes in test,  b)
You give me all the resources I need to test and implement and c) If
the testing and implementation steps are incomplete or incorrect, then
don't blame me? No, you will not do this. What other options? A
pseudo-secure procedure where you just do as you are told - restores
objects, runs fix-programs etc in the restricted production
environment, or base it to some extent in trust without hiding any
security exposure. Any programmer in any IT department is a security
risk (as is any user though they're smaller risks). Believe me: I'm
good. I even try to be better than you (in my specific area). But I
(as you) make mistakes - I did one seven years ago :-) 

PS: I've never asked for *ALLOBJ. But I've often got it when asking
for *SOMEOBJ

Henrik


alan shore wrote:
> 
> I completely disagree - as would many if not all internal and
external auditors to ANY company. With ALLOBJ authority, to objects in
the application you can really create havoc.
> Anything that is in a DEVELOPMENT environment (ONLY),  you should
have complete access to, that I agree with.
> Anything that is in a PRODUCTION, - or - a User Acceptance QA
environment, you should have USE authority only.
> > >>> "Henrik Krebs"  09/13 2:49 PM >>>
> Here is what I as an IT consultant need to work effectively. The
same thing probably
> apply to software companies I guess.> 
>  o All-authority to objects in the application (Directly or via
GRPPRF).
>  o A good cooperation with a person at the
>    customer for (rather infrequent use of) *ALLOBJ and *SECADM -
creating
>    userprofiles, fixing the "oops - Object changed owner when
restored" (we
>    all make mistakes sometime) etc.
>  o An answer Yes/No to the question "Want a joblog for each
job/session?").
>    Personally I've only met 'No', even when the infrequent use of
*ALLOBJ
>    was managed with the loan of QSECOFR.> 
> The sentence "We refused to give them *ALLOBJ rights, period." or
"after a specified
> time, it cancels the dial in job," really sounds like a lack of
'good cooperation' and
> more like "Do your bloody job and don't bother us". If I - in that
situation - should do
> the bloody job, I should also need *ALLOBJ!> > Henrik>
http://hkrebs.dk

---------------------------------------------------------
This mail was sent through Eoffice: http://www.eoffice.dk

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---