Will it be Secure?
By Russ Finney
A critical consideration of business system development is the security access safeguards which are designed and constructed into the completed system. No matter which technical platform is chosen, whether it is mainframe, mid-range, client/server, or personal computer, an examination of the proper level of security is in order.
Obviously, the comprehensiveness of the security levels which are employed, relate directly to the confidentiality, sensitivity, and value of the information which is being protected. For example, a database which contains employee payroll information must be much more closely guarded than a database containing employee telephone extensions. Common sense and practicality should be relied upon when making these vital security decisions.
Levels of Security:
Environment
The first line of defense is the physical safeguards in place to protect either the actual terminal or computer. Proper office or departmental door locks, computer locks, and after-hours office access procedures can prevent unauthorized misuse. In many cases, this is the only security in place around a personal computer.
System
Once the computer system is up and running, access to logging on to the system itself, as well as the various available applications, can also be controlled. This may be through the use of unique User IDs and related secret passwords.
Database
Many commercial database products provide facilities for specifying through a User ID who has access to a specific database. This provides additional security beyond just controlling access to an application.
File/Table
The files or tables within a specific database can also usually protected with access measures similar to those employed for the database. Each file is associated with a list of authorized users. Many times, a company will also purchase a stand-alone security package to protect individual data files. In the mainframe environment two of the more popular of these are ACF2 and RACF.
Field/Column
Another database provided security level is protection at the data field level. Although this is highly effective, it can also require a large amount of administrator time to maintain. A better alternative is to utilize a user view, if it is available, to protect a collection of data fields.
Screen/Form
Screen products or security packages often provide access controls for each individual screen/form. If not, the team may consider building their own facility for maintaining screen/form authorizations. Each screen/form would then need to be designed and coded with a security access check built in based on User ID.
Action
Similar to screen level authorizations, screen actions (such as inquire, add, change, delete, etc.) may also require security checking to control their use. Again, if this is not provided within the selected technical environment, the project team may want to consider creating their own screen action security facility.
Considerations
Listed below are some of the primary considerations both the business clients and the project team should focus on when developing the overall security infrastructure:
- Data Access
- Action Authorization
- Accountability
- Auditability
- Data Encryption
Copyright © 1999, Russ Finney, All Rights Reserved