1.3 Procedures, Policies, and Plans Whether you are an IS manager, a system administrator, or a database administrator, there are many different procedures, policies, and plans you may be called on to help develop as your organization plans its security. In this book, we use the following definitions: - Procedures
-
These map out, in a step-by-step fashion, the actions you need to take to perform a job successfully. - Policies
-
These detail your company's rules and reflect your company's standards and code of ethics. - Plans
-
These are documents that outline the approaches to be used to implement and enforce your company's policies. Within the realm of database security, you may need to construct the following: -
Security policies and an accompanying security plan -
An auditing plan and procedures -
A database backup and recovery plan and procedures  | The auditing plan and the database backup and recovery plan are sometimes included in the security plan. | | The following sections briefly examine these different entities and discuss why they are important to your organization. 1.3.1 Security Policies and Security Plan Over lunch on several days during the International Oracle User Group conference (IOUG-A Live) in the spring of 1998, we casually discussed with several groups of DBAs the topic of Oracle security and security plans. To a person, everyone agreed that security policies (which outline the company's position on security issues) and a security plan (which describes, in detail, how the policies will be implemented and enforced) are vital to an organization. However, all of the DBAs we talked with admitted that they have been fighting an uphill battle to get their company's management to allocate the funds and lend the support needed to create such security policies and to write and enforce a workable security plan. Why does your company need to take the time, effort, and expense to create and implement security policies and plans? This section touches on some of the issues you need to consider when creating security policies and a security plan. What does a stated set of security policies and plan "buy" for you and your company? Suppose that your company has no written security policies and no security plan in effect. Ima Ticdoff, an Oracle user who works in the payroll department, gets angry with her boss one day and decides to "show him a thing or two." She doesn't want to do anything really damaging ; she just wants to cause a bit of discomfort; and she doesn't want to get caught. She logs on to the database and modifies her boss's accrued vacation time from ten days to one day. Vacation accrual is posted on each employee's paycheck. When the next paychecks come out, Ima's boss notices the error in vacation accrual and begins to check into what happened . A thorough and time-consuming investigation shows that the boss's record is the only one that has been modified. Since there is no security plan in effect, there is no auditing enabled to check who made the change to the boss's records. Even if he finds out that Ima is responsible for the modification, how can he prove that she intentionally changed the record? Worse yet, if he does prove that her actions were intentional, with no stated policy on what an employee can or cannot do, and what actions will be taken if a security breach occurs, there may be little the boss can do to discipline Ima. With the current climate of labor laws and court decisions, if the boss and your company take action against Ima, they may find themselves in the middle of a very unpleasant lawsuit that they might not win. If your company has a stated policy on what actions will or will not be tolerated from employees and what steps will be taken if the policies are breached, action can more easily be taken against an employee who oversteps the stated boundaries. If policies are clear, each employee should understand what is expected of him or her and can help to implement the policies and protect the corporate data. If your company has been resisting writing and implementing security policies and a security plan, show your management the latest newspaper articles on security breaches that have cost companies millions of dollars in lost revenues from damage to databases. Next, show your management Chapter 7, which identifies the issues you must consider when forming a security policy and which maps out the steps you'll need to take to create an Oracle security plan for your company. Whether your organization decides to implement a small and informal security plan, puts resources into a more formal and in-depth security policy and plan, or chooses to do nothing at all, you will at least have taken a proactive stance in attempting to help your organization more effectively protect the databases in your care. 1.3.2 Auditing Plan and Procedures One of the problems with the Ima incident was a lack of auditing on the system. An auditing plan is a natural follow-on to a corporate security plan. Any database you oversee should be examined to determine if there are objects that need special attention, or actions or privileges that should be monitored . Once you have identified areas that are appropriate to audit, you will want to write the procedures to document the steps you'll need to take to enable and enforce auditing on your database. Oracle provides different levels of auditing that you can enable from your database as follows . - Statement-level auditing
-
Performed to capture information when a specific type of Data Definition Language (DDL) or Data Manipulation Language (DML) statement is either attempted or completed (either successfully or unsuccessfully). This type of auditing can be very broad or very specific. The statement-level audits are based on the type of SQL statement presented. - System privilege auditing
-
Performed to capture information when a specific system privilege is used. - Object auditing
-
Performed to capture information when a specific object or group of objects are accessed (either successfully or unsuccessfully). In Chapter 10, we discuss when and why you might want to create an auditing plan and how to implement one or another form of auditing within your database. We describe how auditing works, the various forms of auditing, and the ramifications of enabling auditing on your database. Let's look at some of the reasons you would implement auditing and some areas in which auditing might make sense: -
Specific tables whose data is vitally important to your company would be excellent potential candidates for auditing. -
You may want to keep track of who is creating one or more specific kinds of objects in your database to help ensure that an unauthorized person is not siphoning off information to which he or she should not have access. -
You may want to track accounts that have had failed connection attempts because you suspect that someone is attempting to guess their way into your database. If you've enabled the Oracle-supplied auditing utilities, you'll be able to implement auditing within your database, either very broadly or very narrowly (depending on your needs), to gain an overall view of actions being taken in your database. 1.3.3 A Problem with Auditingand a Solution With the various forms of auditing provided by Oracle, you can determine that a specific table was accessed and when the table was modified, but you cannot tell what action was taken or what data was inserted, modified, or deleted. Think back to the Ima incident once again. The boss knew that someone had modified his record. After investigation, he knew that his record was the only one that had been modified in error. After going through his payroll receipts and time cards, he was able to prove that he had 10 hours of vacation time accrued and was able eventually to get the time reinstated. The cost to her company from Ima's "prank" was very high in wasted time and effort. Might there be an easier way of tracking Ima's data modifications? In Chapter 11, we provide an application you can use (either completely or in part) to enable information to be captured at the column level of a table. If the audit trail application had been active in the database on the table which Ima modified, the following information would have been captured: -
What the data looked like before the change -
What the data looked like after the change -
Who had made the change -
What time the change was made There would have been no time-consuming investigation or need to provide proof of the original data. The damage Ima caused could have been repaired easily at a very low cost to the company in time and effortand Ima would have gotten caught! 1.3.4 Backup and Recovery Plan and Procedures An Oracle technical support person once told a story about the time he was manning a support line and a customer called in. The conversation went something like this: Customer: "Hi. I'm a DBA at this company and my database just crashed. What should I do?" Oracle: "When was your last database backup taken?" Customer: "Backup? Oh, we've never taken a backup." Oracle: "When did you do your last export of the database?" Customer: "Export? Oh, we've never taken an export of the database. What should I do?" The support person's reply was, "I'd recommend that you update your resume and send it out really quickly...but don't send it to us!" We've said how important backups are. But recovery is important too. You need a backup plan that outlines the various forms of backup you'll use, as well as a recovery plan that outlines the procedures you'll follow to recover your database in case of a minor data loss or a full-fledged disaster. In Chapter 12, we discuss the forms of backup available to you and the elements you should consider including in your backup and recovery plans and procedures. No matter how thorough your data protection plans and procedures are, there is always the potential for hardware failure, acts of God, and human errors. A speaker at a conference we attended once told his audience to go home, walk in to the computer room, and "pull the plug on one of your disks on your test system." He was suggesting that the attendees verify that their backup and recovery plans were, in fact, effective and usable. We wholeheartedly agree with that speaker that you need to test your backup and recovery plans to ensure that they are valid and workablebut we hesitate to advise you to physically tamper with your disks!  | 
