Consider your home, you would like to feel that there is some security there. You can use deadbolt locks, you can install an alarm system, you can dig a moat around your home, your can build a 3 foot thick concrete wall 10 feet tall with razor wire on the top, you can do all sorts of things to secure your home. But how far should you go? The moat and wall may be overkill, but why?
The answer to these questions can be found by doing a security analysis. This analysis is the subject of this presentation.
If a system has no potential threat then nothing can violate security so why bother building it. Conversely, if a system has no potential loss then there is no cost justification for providing security because there is no loss to prevent.
Potential Threat
What kinds of potential threats can there be against a database application? The types of threats can range from unauthorized changes to data to confidentiality violations. These threats can come form inside the organization or form external sources.
Who is it that poses the threat? The source of the threat can be from employees, hackers, or professional corporate espionage agents. It is important to assay the source of the threat because the measures you take for protecting from amateurs will vary greatly from the measures you would take to protect from professional espionage agents.
Potential Loss
As well as assaying what the potential threat is you need to now what the potential loss can be. The potential of the loss will aid greatly is deciding what cost for security can be justified. First determine what the loss might be.
Losses can be a violation of privacy, the entry of invalid data, or a business disruption. Any one of these can result in a financial loss. You need to quantify the potential financial loss in order to evaluate the cost justification of the security measures you will undertake.
You then need to determine the cost of protection. Cost of protection is not a simple issue, there are many factors involved including the cost of development, the lost efficiency due to the protection's interference with using the of application as well as reduction in productivity due to a reduction in performance of the application as a result of the overhead of the security layer.
Computer or Network
The physical securing of the computer or network is outside the realm of our application. Most networks provide a level of security built into the network operating system and there are third party solutions that can be purchased to enhance the security provided by the network system. It may become necessary to retain a computer security consultant to provide the level of security needed for the network or the computer system itself.
Application Access
The first level of protection we can provide within our application is to secure access to the application entirely. This can be provided in one of two ways, we can either set security access within the network system to prevent unauthorized users from even seeing the application on the network or we can secure the application with a login process that verifies the identity of the user when they try to launch the application.
Often we will use both of these approaches, providing what security we can at the network level and requiring the user to log into the application with some method of identity verification. The method of identity validation can range from a simple password to some very sophisticated third party systems of identification.
Menu Security
Menus can be secured in one of two ways, either by having unauthorized menu options visible but disabled or by removing the unauthorized menu options from the menu system completely. Visual FoxPro is able to handle either method or even a combination of both approaches simultaneously.
You can use the SKIP FOR option of the menu options to control the enabling and disabling of the menu items. To provide for the presence or absence of menu items you can either modify Genmenu.prg or you can use GenMenuX (a public domain utility) to provide IF/ENDIF statements around the DEFINE commands in the menu program.
Form Security
In some cases it is required that an entire form be made unavailable to a particular user. This can be accomplished by either disabling or removing the menu item for that form or by having the form check its availability in the security system during the form's Init and then returning either .T. or .F. according to the rights of the user.
Functionality in Forms
Even though a particular user has rights to access a certain form, that user's security rights may require that certain functionality be made unavailable. Perhaps the user is allowed to view the information in the form but is not allowed to edit or add records. The provision of this level of form security is dependent on how the functionality is made available in the form. If the interface uses toolbars then the toolbar buttons can be enabled/disabled appropriately. If the form is using buttons contained inside the form then those buttons must be enabled or disabled to restrict or allow access to the functionality.
Tables and Fields
If it is necessary to grant and/or restrict rights on a field level you will need to provide this security in the control classes. Since it is the controls that manage access to fields it make sense that the control would be used to control security to the fields. The control's Init can access the security system to determine the access level allowed for the user and then set the appropriate properties of itself to provide that level of security.
In order for a security manager object to be able to provide the information that other objects may request it would be necessary to provide a data structure to store that information. The figure below is an example of a possible security data structure.
In addition to providing the structure to store this information you would also need to provide the forms that would allowed the system administrator to enter the information.
On starting the application the user would interact with a login form identifying themselves and entering a password for verification. The current user would be recorded by the application framework somewhere for future reference.
The framework would create a security manager object to provide the various security services to the application.
Menus, forms, toolbars, and data controls would all check with the security manager to determine their security levels. The security manager would investigate the object requesting security information and the then current user and mask the information on the security data to see what the security level is. This security level information is then sent back to the object inquiring and that object does what it needs to do in order to comply with the security level.
A menu might eliminate an item form itself or set the skip for setting. A form may refuse to instantiate. Toolbars would enable or disable their buttons according to the user's rights. Data controls would set their properties to provide the required securing of the data.
The exact code required to accomplish these goals would vary according to the overall structure of the framework and the security features required in the design of the application.
