> But with BPCS security, you cannot do that ... people are either
> to be doing a wide range of transactions to the data in any city, or they
> inquiry users, so under many methods of BPCS implementation, you have to
> trust your people, you cannot rely exclusively on security to impose
> rules.  Of course we can also run histories to see who has been doing what
> kinds of transactions in which divisions, so that after the fact we see if
> anyone breaking the rules.

There are really two kinds of "trust" that you are inflicting upon yourself
here.  The first is a trust that people will not intentionally steal from or
try to hurt the company.  The second "trust", and frankly the trust that is
more likely to be disappointed, is where you are trusting your employees to
not make accidental errors.

Because the majority of people are honest and well meaning, the day to day
benefit of security tends to be that it prevents good people from
accidentally shooting their own toes off.  In the real world, a good
security implementation more often prevents someone from accidentally
dragging an important file into the Windows trashcan as opposed to stopping
embezzlers and hackers.   You don't here much about that because it's not
sexy or news worthy, it's just the truth.

> In the BPCS reality, all the objects are the property of the SSA owner of
> environment.  All users of that environment are members of the group SSA.
> All objects created by members of the group belong to the group.  All
> in the group may access any of the objects that belong to the group.
> is some additional security within BPCS to control what programs people
> use to do what with the objects.

The all too common design flaws that you have listed here are the strongest
reason that I can think of for implementing security, and especially exit
point security.  Under the scenario listed above, Everybody who belongs to
the SSA group (and that sounds like it is Everybody in the company) has
complete access to everything in the SSA application.  There may be some
restrictions within the applications menu system, but in a world full of
PC's equipped with data access and data transfer tools, the menu system is
all but irrelevant.  The first user that goes exploring with FTP or ODBC
could cause a complete disaster.

In this situation I would take a timeout worrying about hackers and
embezzlers and instead pay some serious attention to the accidental damage
that my freindly users could do.  In the process of securing against
catastrophic accidents you will inevitably close holes that wrong doers
might exploit.


John Earl
The Powertech Group Inc. Seattle, Washington
Where the Security Experts Live!

Phone: +1-253-872-7788 (optional)
Fax:   +1-253-872-7904 (optional)

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 by 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.