|
Al, > But with BPCS security, you cannot do that ... people are either authorized > to be doing a wide range of transactions to the data in any city, or they are > inquiry users, so under many methods of BPCS implementation, you have to > trust your people, you cannot rely exclusively on security to impose company > 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 the > 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 users > in the group may access any of the objects that belong to the group. There > is some additional security within BPCS to control what programs people may > 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. jte -- John Earl www.powertechgroup.com johnearl@powertechgroup.com 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 mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.