With the ever-increasing ability to provide online applications direct access to multiple stores of data, many companies find that they can improve customer service by providing service representatives with direct access to all available customer data online. The convenience of being able to access such services has proven popular with an ever-growing number of people, but this popularity has been shadowed by a concern over lack of security and privacy in the online world. So far, customers are expressing this concern primarily through their elected representatives, resulting in numerous state and federal privacy bills. It would appear to be only a matter of time, however, before privacy concerns start to affect customers’ decisions, and the ability to provide a privacy capability becomes a marketing feature.
It must be accepted that privacy is a separate and distinct matter from security. Security is not a new issue in the mainframe environment. Even though new issues are raised when applications are provided with direct access to multiple data sources, security is still comprised of two basic questions: who is making this request, and are they allowed to make this request? Therefore, expanding security to these new data sources becomes a simple matter of answering these two questions—that is, authenticating user IDs and maintaining data access lists.
Privacy, on the other hand, is something that has not traditionally been addressed in the mainframe world. Once a user was identified as being authorized to access a customer data source, little thought was given to ensuring that the user had a bona fide reason for calling up the specific records requested. It was simply assumed that the user would only access records he was supposed to. This assumption has resulted in the rise of two basic types of invasions of privacy: invasion for pleasure and invasion for profit.
Privacy invasion for pleasure can be considered as a product of personal curiosity. A clerk who has access to personal information about friends, neighbors, or celebrities indulges his curiosity with a few simple queries. The clerk is rewarded with a store of “insider” information. While no economic damage results directly from this type of activity, customers are unsettled when they realize, for example, that any clerk at the telephone company can tell which 900 numbers the customer has called.
By contrast, privacy invasion for profit has the potential to cause direct financial harm to a company or its customers. A clerk is either bribed to acquire information in a company’s file, or acquires the information on his own, for later sale. Since the motivating factors for this type of privacy invasion can include industrial espionage, insider trading, and blackmail, the potential economic damage is obvious. Less obvious, but with potentially greater cost, is the damage due to loss of business or personal reputation.
In either type of privacy violation, it would appear that a reasonable case could be made for court-ordered damage awards. If negligence is determined, it is also possible that punitive damages could be awarded.
Since the possibility exists of both rewards for strong privacy controls and liabilities for poor privacy controls, implementing these controls would appear to be an obvious maneuver. The problem is that because a privacy violation is defined by the intent of the user, there is no automated manner in which to ensure that a data access request is not a violation of customer privacy. Instead, assuring privacy requires three distinct processes that must be implemented independently but function together:
- Establishment of a written company policy on customer privacy, clearly defining what type of access is acceptable, and providing for specific, severe repercussions for unauthorized access to customer data
- Establishment of a data access log that maintains a record of which customer accounts have been accessed, by whom, and when
- Establishment of a method of reviewing the data access log to ensure that there was a valid reason for the query.
Although decidedly non-technical, the establishment of a written policy on customer data access is critical to providing customer privacy. First, employees must be made aware that violating customer privacy is a serious issue that can have serious economic and legal ramifications, and cannot be tolerated; second, a written policy provides justification for job reassignment or dismissal of offenders. Existence of a written policy has the additional benefit of providing proof to customers of the company’s commitment to privacy. When the policy is drafted, each of these goals must be considered equally. The published policy must be clear and concise, with no “wiggle room” for the adventurous employee.
In the same manner, reviewing the data access log is a straightforward process. Each instance of data access must be traced to ensure that it was initiated by an acceptable source. In a call center, for example, the log of incoming phone numbers can be checked to ensure that it matches the phone number on file for the customer in question; unmatched numbers can be followed up manually with the customer and the user who initiated the query. In a high transaction volume environment, only a randomly selected subset of transactions need be logged and reviewed.
It is the issue of creating the data access log that presents the problem, as it requires source code changes to the application programs. Unfortunately, many applications have been designed in an unstructured fashion, forcing the scope of the change to expand to include every module that performs file access. With the fierce competition for scarce application programming resources, the need for these changes can delay the implementation of a logging facility indefinitely.
It is possible to produce this data without application source code changes, through the use of operating system or subsystem user exits. The use of exits is well-suited to this function for a number of reasons, including:
- The exit need not be application-specific, so the same exit program can provide logging capabilities for many applications.
- The exit can capture activity by request type, so it can distinguish between update activity (which is usually covered by security controls) and inquiry activity (the primary area of concern for privacy issues).
The addition of access log functionality raises obvious performance and system overhead issues, in the same way that implementation of security packages did 20 years ago. The additional overhead must be considered as a cost of doing business, as it is when implementing any new software. However, there are methods to reduce this overhead without sacrificing functionality, including:
- Limiting the physical scope of the audit. An analysis of the application’s data structure will identify the critical files or tables that require auditing; all other resources can be ignored.
- Limiting the logical scope of the audit. An analysis of the data within an application may indicate that only certain customers have a privacy exposure.
- Limiting the number of transactions audited. Just as random sampling can monitor quality control, only a random sample of transactions need be selected for audit.
- Use of appropriate technology is essential. For example, the MVS logger can support high transaction rates with limited response time impact.
- Coding the exit programs in Assembler language rather than a high-level language.
Businesses acquire a great deal of information about their customers; some of this data is a prerequisite of doing business, while some is simply a convenience. In either case, customers provide their personal data in good faith, assuming that their privacy will be respected. It is up to each company to ensure that this assumption is met. If businesses don’t voluntarily make this commitment, it will eventually be forced on them, either through regulation or customer choice. Z