• Subject: Re: Security (was Inventory history)
  • From: "Charlie Massoglia" <cmassoglia@xxxxxxxxxxx>
  • Date: Mon, 13 Aug 2001 11:25:59 -0400

From sunny Malaysia:

With the proper use of object security, allowing users access to QUERY can
be easily controlled.  Many of our users use QUERY extensively to perform
their own data analysis.  Prohibiting them from using QUERY would add to an
already overburdened IT department.

While I agree unrestricted access to commands should be prevented, I fail to
see why you would not want to encourage your users to use query.  Note you
can also control how users use QUERY to prevent them from hogging the
machine.


Charles L.Massoglia, President
Massoglia Technical Consulting, Inc.
cmassoglia@voyager.net
In MI 517-676-9700 or in NC 919-363-9395


----- Original Message -----
From: "Lacelle, Marc" <LACELLE@rcmint.ca>
To: <BPCS-L@midrange.com>
Sent: Sunday, 08 July, 2001 11:34
Subject: RE: Security (was Inventory history)


> Hi Ho.
>
> Nice weather, black flies and mosquitoes have moved in by the
> millions. I'm already down one quart of blood this week.  F e e l ,  w   e
> a    k ,      m    u   s     t,           s        t      o
p,
> w   r         i           t           t         i         n             g.
>
>
> We went to full ERP V61.01 this January. Are approach was no command
> line access. At first some of our BPCS users found it hard not to use such
> commands as WRKSPLF, WRKSBMJOB, CPYSPLF, DLTSPLF, WRKOUTQ, WRKJOBQ.
>
> The positive note to this decision. I don't need to worry about our
> users ever stumbling on to STRDFU, STRSQL, CPYF, CLRPFM, DLTF.
>
> I have written asset programs to replace those commands required by
> our users. Such as CPYSPLF, CPYTOPCD.......
>
> There are so many nice security features to BPCS / AS400 to limit
> users in what they can do. It is there for you to use, yet most companies
> have a laid back approach to security. What would your company do if
someone
> would start using DFU or SQL to update certain fields in the ECH and ECL
or
> even the ITH files. It is easy to do this when users have command line
> access.
>
> Data integrity is the most important aspect of your data base.
> Without security or limited access you may be leaving yourselves open for
> possible problems.
>
> Our users have no command line access. They are categorized by Group
> ID. They are all "U" types. Custom reports monitor object and group
> authority by user or users.
>
> This is just my two cents worth.
>
> Marc "I Need a Mosquito Net" Lacelle
> Royal Canadian Mint
>
>
> > ----------
> > From: MacWheel99@AOL.COM[SMTP:MacWheel99@AOL.COM]
> > Reply To: BPCS-L@midrange.com
> > Sent: Monday, July 02, 2001 1:17 PM
> > To: BPCS-L@midrange.com
> > Subject: Re: Security (was Inventory history)
> >
> > Lisa.Abney@sensient-tech.com writes:
> >
> > > Do you really give all your users command line access?  What happens
in
> > >  BPCS security, if users call things from the command line?  Aside
from
> > >  that, doesn't opening up your command line to users make you a little
> > >  nervous?  AS400 security is definitely not my area, but doesn't this
> > give
> > >  them access to an awful lot of VERY powerful commands
> >
> > A lot of people have taken me to task for this kind of topic.
> >
> > The time I was most nervous was duinng pilot conversion to our current
> > version & the project team was exploring AS/400 menus & I KNEW that
> > anything
> > that got changed impacted ALL the stuff on AS/400 not just the pilot,
and
> > I
> > also knew that there was more stuff that I did not know than I did know,
> > and
> > our coinsultants had an attitude that if there was any problem with
> > security,
> > instead of documenting what the problem was so that we could fix it,
just
> > turn off security so they could do their thing without impediment.  We
> > finally had to have a confrontation at a management level ... I
recognize
> > that these consultants are very expensive & that we do not want to add
to
> > that cost by something blocking their access, but we need to have a
pilot
> > test that includes security, to make sure this is going to work live
with
> > security the way we think it should be setup.
> >
> > Most BPCS programs bomb if you try to run them from the command line.
> > I have tested this concept to find out ... I know what causes the bombs
&
> > which types of programs do not bomb.
> >
> > Our company is comfortable with a curious mix of almost no security over
> > trusted employees & limited access for people who have not yet had
> > relevant
> > training in how to use some very powerful tools.  Security makes it
> > practical
> > to have different rules for different people & I have had lots of
> > arguements
> > with co-workers over some security setups, like password rules for
> > example.
> > Ultimately my department's job is to SERVE the desires of my customers &
> > the
> > customers are always right, even if I would make a different decision if
I
> >
> > was in their shoes.  So I argue, giving reasons why this perhaps is not
a
> > good idea, then relent & do what they asked for, after I have done my
duty
> > to
> > point out some risks.
> >
> > The bottom line is that in security breaches, the PC area is a never
> > ending
> > battleground of discoveries of Microsoft Security Holes that child
hackers
> >
> > are exploring, while in the 400 area even with occasional klutzes about
> > the
> > worst thing that ever happens is that person-A launches 2,000 shop
orders,
> >
> > and person-B accidentally deletes them off the spool files (yes we have
> > given
> > all our users access to each other spool files), and our modifications
> > environment is such that reprints are not currently available.
> >
> > For every one instance of a real security problem on BPCS (someone
reading
> >
> > accounting records & TALKING about the contents, which I think was the
> > real
> > sin, or a few years ago when we had a bitter strike & someone leaked
> > payroll
> > data on top executives to the union), we have scores of what turn out to
> > be
> > false alarms (a piece of hardware going flaky on its addressing makes it
> > appear to the system error messages like we have a pirate station on our
> > network).
> >
> > There are people who are hyper about security.
> > Do not let anyone have a key to the building because they might steal
from
> >
> > you.
> >
> > Do not leave men & women in the building alone after hours because one
> > might
> > accuse the other of hanky panky & to protect your people you always need
> > to
> > have at least 2 men & 2 women together, as witnesses, if all you worried
> > about is accusations of straight sexual harrassment, make it 3 of each
for
> >
> > protection against accusations of gay stuff.
> >
> > Then there are companies that trust their work force to behave in a
> > responsible fashion & provide the tools to help us be productive.
> >
> > We have locks on our gates to protect our assets from communities of
> > people
> > outside of our company, but inside the atmosphere is a bit more relaxed.
> >
> > I guess it comes down to a corporate culture topic.
> >
> > MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
> >
> > +---
> > | This is the BPCS Users Mailing List!
> > | To submit a new message, send your mail to BPCS-L@midrange.com.
> > | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner: dasmussen@aol.com
> > +---
> >
> >
> >
> __________________________________________________
>
> The Royal Canadian Mint is proud to be among the "35 Best Companies to
Work
> For in Canada" in 2001, according to the Globe and Mail's Report On
Business
> Magazine.
>
> La Monnaie royale canadienne est fière de se retrouver, pour l'an 2001,
> parmi les «35 meilleures entreprises où travailler au Canada», selon la
> revue Report On Business du Globe and Mail.
>
> +---
> | This is the BPCS Users Mailing List!
> | To submit a new message, send your mail to BPCS-L@midrange.com.
> | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
> | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: dasmussen@aol.com
> +---
>


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].