7.9 Standards for Employees Within your organization, there will be many different interactions with employees. You need to determine how to deal with these interactions and add your organization's policies to the security plan. The driving force behind any security policy should be what an employee needs to know to perform his or her job effectively. 7.9.1 Employee Procedures What privileges do particular employees need? What limitations should you place on these privileges? A major problem with trying to determine how employees will be able to access a database or application is the need to balance giving enough privilege to enable the employee to get the job done against the risk of allowing too much access to sensitive information. If a security plan becomes too rigid, employees may feel they are not trusted or may not be able to perform their jobs effectively. 7.9.1.1 Pre-employment tracking Before an employee is ever hired , an employment application, resum, or both, is usually submitted for consideration to a company. Many companies track their candidate submittals using computer programs that interact with a database. The information presented in a job application or resume is private and must be handled with care. Your security plan should include procedures for employment application and resum handling. 7.9.1.2 New hires Once an employee is hired for a position, the security plan should clearly state the steps to be followed for giving a new employee access to platforms and databases needed to perform his or her job effectively. If you've already determined the possible functions for an employee using a specific application, the task of knowing what accesses (roles and grants) are needed by that employee will be made much more easily. 7.9.1.3 Changing positions Over a period of time, the employee will learn and (you hope) grow within your organization. He may find that the job he was hired for is no longer challenging enough, or he may receive one or more promotions. With promotions, the employee may require different privileges to perform his new duties . Or, an employee may take courses or receive in-house training and become proficient enough to apply for and obtain a position in another department or branch or division of the company. In each of these cases, the security plan should cover what actions should be taken as an employee changes positions within the company. 7.9.1.4 The disgruntled employee No one likes to think about the possibility that a coworker may become so upset that he might take action to intentionally damage part or all of a database or system. Unfortunately, this possibility does exist and you must address it. Many years ago at a company in which Marlene Theriault worked, there was a Christmas office party where an employee enjoyed a little too much wine, went back to his office to do a little work before the holiday break, was unable to log on to his account because he mistyped his password repeatedly, decided that his boss had modified his account to deny him access, and relocated some of his boss's data files to another directory location as "payback" for the assumed insult. The good news is that the action was easily corrected and the boss was understanding enough to let the employee off with a mild reprimand. Under less amicable circumstances, however, major damage could have been done to the system since the employee involved had enough privileges to potentially cause real harm. You need to periodically review employee privileges. Be sure such issues are addressed as policies in the security plan. 7.9.2 When an Employee Leaves Another threat to a system is the employee who either gives notice or is being terminated . Although there are many different philosophies on how to best handle a terminating employee, the security plan should outline exactly what actions are to be taken. 7.9.2.1 Termination types The following are a few of the possible termination types to be addressed in a security plan: -
Immediate dismissal, including escorting the employee out of the building with or without severance pay in hand, because the employee has been involved in a major breach of conduct or ethics -
Giving the employee the option of working for a period of timeusually two weeksbefore departing the organization; this is usually done in cases where an employee has voluntarily given notice to pursue other interests -
Giving the employee an extended amount of time to continue working and possibly even providing company assistance in a job search; this may be done when a large number of employees have been laid off (downsizing) The policy should have clear directions on what steps are to be taken in each situation. For example, if an employee is being escorted out of the building immediately and both management and HR are in agreement about the dismissal, the policy might state that the company should revoke all access to all computer accounts and all databases before confronting the employee. 7.9.2.2 When an employee gives notice When an employee gives notice, many different approaches may be appropriate. If the employee works directly with the systems or databases in a support capacity, the company might choose to offer two weeks severance pay and have the employee leave immediately rather than take the chance that the employee will do any of the following: -
Work himself to excess trying to clean up every possible task before departing and make careless, costly errors due to fatigue -
Develop a "short-timer" attitude and do little or nothing for the two weeks, which can be very demoralizing to those employees who are not leaving -
Cause damage to the system by inserting a time bomb or Trojan horse set to go off after his departure to sabotage the system or a specific manager's data area On the other hand, in the situation where an employee has proven his trustworthiness , you might consider maintaining his accounts even after he has leftfor a specified amount of time. If there is a chance that the employee might someday return to the company, access to accounts might be locked instead of explicitly revoked or deleted from the system. This approach is particularly useful for workers such as consultants , resident contractors, or temporary hires who may work sporadically with the databases or systems. 7.9.2.3 The curious employee Many people are curious. Some have a desire to know as much as they can about their surroundings, while others just love to poke around and see how much information they can access that they are not supposed to know. The curious employee poses a difficult type of security challenge; there may be absolutely no malicious intent involved, but such an employee might nevertheless violate the privacy rights of others. The decision about what penalties should be imposed on an employee who stumbles into data areas to which he should not have access should be considered and clearly defined in the policy. 7.9.3 User Tracking In the last several sections, we've shown that an employee does not necessarily spend his entire professional life in the same job or the same area of the company. There is, therefore, a need to keep track of each employee's location and current job requirements to ensure that the employee's system and database access rights remain appropriate as he moves around or changes jobs. Let's follow a bit of the employment history of our old friend, Ima Ticdoff. When Ima came to work for her company, she started as a clerk in the mailroom. Initially, Ima needed access to only one database application to be able to look up employee locations. Ima was bright and learned quickly. Over a period of time, Ima attended night school, obtained other skills, and was eventually brought into the payroll area. At that point in time, Ima's computer access needs changed. She now required access to three different databases to perform her varied tasks . As we mentioned in Chapter 1, Ima became unhappy with her boss. Her unhappiness grew to a point where she finally requested a transfer to the billing department. When she moved to her new department, it was no longer appropriate for her to have access to any payroll information but she now required access to the billing applications. What mechanism was used to ensure that Ima's access to payroll information stopped and her access to billing information began ? How was a user tracked in Ima's company? How are users tracked in your company? What vehicle ensures that an employee does not have inappropriate access to sensitive data? You can use your organization's security plan as the vehicle for specifying how users and their privileges and accesses will be tracked within your company. In one organization, a user tracking application was written to populate a database nightly with current employee information. The application includes each operating system and identifies the databases on each system. Each application manager, DBA, and all developers associated with each database are recorded within the user tracking application, as well as everyone who has an account on each system and database. All privileges and roles for each database are housed within the user tracking application, and each user who has been granted each role and/or privilege is recorded with the associated role or privilege information. Once each quarter, a report is generated and emailed to each manager showing who has access to their applications and what privileges are held. Before the user tracking application was written, the requirements for this application were carefully outlined in the company's security plan. Once the requirements were defined, the creation of the user tracking application became a simple task of implementing the requirements as specified. By basing the application on the security plan details, the finished user tracking application was both easy to create and completely in sync with the security plan.  | 
