7.1 About the Security Policy and Security Plan Why does a company need a security policy and plan? What's the point of having them? A security policy, included within a security plan, helps to ensure that everyone is in sync with the company's needs and requirements. With a firm policy in place, every employee knows what is expected what the rules areand how the requirements are to be implemented. The limits are clearly defined and consistent guidance is provided for everyone. Statements within a security plan can help to ensure that each employee knows the boundaries and what the penalties of overstepping those boundaries will be. For example, here are clear, concise rules employees can easily understand and follow: -
Always log off the system before going to lunch . -
Never share a password with anyone else. -
Never bring software from home to put on your machine at work. In order to have a truly solid and meaningful policy defined, the highest level of management needs to be committed to ensuring that the security policy will be enforceable. The security policy might state: -
Any employee leaving a computer unsecured will be formally reprimanded. -
Any employee found sharing a password will be suspended for one day. -
Unlicensed software found on a personal computer will be removed and the personal computer user will be shot at sunrise . Survivors will be prosecuted. Under certain circumstances, the requirement to have and enforce a security policy may come from an agency outside the company. In the case of banks, external agencies control and define what constitutes security for the databases within the bank. The company, however, might decide that even more rigid standards are necessary or that further definitions are required to ensure that no financial transactions become compromised and that confidentiality is maintained. The bank may implement a security plan that further defines exactly how the standards will be implemented, maintained , and audited . 7.1.1 Management Considerations Once you've determined that a security plan is required for a company, a person or team of people will be needed to begin to define the policy. This chapter assumes a team of people. 7.1.1.1 Who's on the team? Members of the team might include the person or people who will be administering the system, one or more application owners , and at least one management person who is high enough in the corporate structure to ensure that the policyas writtenwill be enforceable. The system administrator may have a different perspective from the database administrator on what comprises security on a system, but the goals of both should be the sameto ensure that the system cannot be compromised. If the policy is to be in effect across divisions within a company, representatives from each division might be included to ensure "buy-in" across the entire corporate structure. The goal is to include enough people to ensure that all areas of corporate need are met, but to keep the group small enough that the team will be able to create an effective, workable policy. 7.1.1.2 Establishing overall requirements After the team is assembled , you'll first need to identify the overall requirements of the organization in regard to system and database security. The requirements might include (but are not limited to) the following: -
A uniform approach to security across computer systems and databases -
Identification of the form and style of authorization required to initiate the creation of an account -
A determination of who will create user accounts on the operating system, within each application if necessary, and within the databases -
How those accounts will be created -
Whether a standard convention for usernames and passwords should be imposed and what it should be -
Whether password aging will be enabled and in what time frame -
A determination of access requirements on an application-by-application basis -
Identification of how users will be tracked to ensure that as an employee's job description or location changes, the access to applications remains correct -
Identification of sensitive information and an outline of steps to take for data protection -
A determination of penalties to be enforced as a result of different levels of security breaches 7.1.2 Operating System Security Mechanisms In implementing a requirement for a uniform security approach across platforms, you need to take into consideration the native security mechanisms available on each platform. For example, most operating systems require each user who will be interacting with that system to have a unique username and password. Access by a user on a UNIX or OpenVMS system can be further restricted by placing users in specific groups. Group membership might enable a user to interact with specific directories on the system. The security plan could detail each of these requirements. We don't describe the details of operating system security in this book, but see Appendix A, for references to books and other sources of information. 7.1.3 Identifying Key Components We recommend that you use a spreadsheet approach to identify the components within your company that the security plan must encompassfor example: -
Each division within the corporation to be included in the policy -
Each platform within the division -
Each database housed on each platform along with its function (development, test, pre-production, or production) -
Each application supported within each database -
The "owner" of the application, or person responsible for authorization of users within the application -
Required security controls for each application, such as roles or grants required -
Username and password composition -
Type(s) of accessibility (Telnet, client server, external identification) -
What form of authorization will be accepted for that application (electronic authorization, verbal, email, hard-copy form, World Wide Web) -
Person authorized to create accounts for each application -
Forms of backup to be implemented -
Recovery procedures to be used -
Database availability -
Type of auditing required -
Who will perform the auditing -
How auditing will be performed A possible spreadsheet might look like the one shown in Table 7.1. Table 7.1. Sample Security Plan Spreadsheet | Component | Database A | Database B | Database C | | Platform/Division | Windows NT (Div. X) | Digital UNIX (Div. Y) | OpenVMS (Div. Z) | | Database/SID Name | larry /lar1 | curly /cur2 | moe /moe1 | | Database Function | Development/test | Production | Pre-production | | Application(s) | Accounts Payable | Human Resources | Office Equipment Locations | | Application Owner | H. Brown | Personnel Manager | Facilities Manager | | Username | User-defined | First initial/last name | Three letters , two numbers | | Password | User-defined | 2 letters, 1 number, 1 punctuation mark, 3 letters (e.g., XX#(!)XXX) | Any combination of letters, numbers, and punctuation, up to 8 total | | Access Type | Client Server | Log on to application and application connect to database | Telnet to platform and connect directly to database | | Authorization Mode | Email | Paper form signed by head of HR | Phone call | | Person to Create Account | Application DBA | HR Security Clerk | Database DBA | | Auditing Type | Connections to database | Connections to database SELECT FROM salary table | None | | Form(s) of Backup | Exports nightly No archivelog mode | File-level backups weekly Archivelog mode enabled Exports nightly | Exports nightly No archivelog mode | | Recovery Procedure | Rebuild database and import | Recover per procedures in the System Recovery Document | Rebuild database and import | | Database Availability | Mon-Fri 7:30-18:00 | 7 days a week, 24 hours a day | Mon-Fri 7:30-18:00 | | Auditor | Accounts Payable Manager | HR Security Clerk | N/A | | Roles Required | ap_clerk ap_manager | hr_clerk hr_developer hr_manager | None | | Grants Required | CREATE SESSION, SELECT FROM ap tables, INSERT/UPDATE ON ap tables (clerk, manager) DELETE FROM ap tables (mgr only) | CREATE SESSION, SELECT on specific tables (clerk) INSERT/UPDATE specific tables (clerk) SELECT, INSERT, UPDATE, DELETE on all tables (manager) CREATE TABLEs, TRIGGERs, PROCEDUREs, etc. (developer) | CREATE SESSION, SELECT, INSERT, UPDATE, DELETE ON ANY TABLE | As you can see from this table, many different security requirements may be present in one environment. |
