A policy is a high-level statement of enterprise beliefs, goals, and objectives and the general means for their attainment for a specified subject area. When we hear discussions on intrusion detection systems (IDS) monitoring compliance to company policies, these are not the policies we are dis- cussing. The IDS is actually monitoring standards, which we will discuss in more detail later, or rule sets or proxies. We will be creating policies such as the policy on information security shown in Table 4.1.
Later in this chapter we will examine a number of information security policies and then critique them based on an established policy template.
TABLE 4.1 Sample Information Security Policy
Information Security Policy
Business information is an essential asset of the Company. This is true of all business information within the Company, regardless of how it is created, distributed, or stored and whether it is typed, handwritten, printed, filmed, computer-generated, or spoken.
All employees are responsible for protecting corporate information from unauthorized access, modification, duplication, destruction, or disclosure, whether accidental or intentional. This responsibility is essential to Company business. When information is not well protected, the Company can be harmed in various ways, such as significant loss to market share and a damaged reputation. Details of each employee’s responsibilities for protecting Company informa- tion are documented in the Information Protection Policies and Standards Manual. Management is responsible for ensuring that all employees under- stand and adhere to these policies and standards. Management is also respon- sible for noting variances from established security practices and for initiating corrective actions.
Internal auditors will perform periodic reviews to ensure ongoing compliance with the Company information protection policy. Violations of this policy will be addressed as prescribed in the Human Resource Policy Guide for Management.
4.8.2
Standards
Standards are mandatory requirements that support individual policies. Standards can range from what software or hardware can be used, to what remote access protocol is to be implemented, to who is responsible for approving what. We examine standards in more detail later in this book. When developing an information security policy, it will be necessary to establish a set of supporting standards. Table 4.2 shows an example of what the standards for a specific topic might look like.
4.8.3
Procedures
Procedures are mandatory, step-by-step, detailed actions required to suc- cessfully complete a task. Procedures can be very detailed. Recently I was reviewing change management procedures, like the one shown in
Table 4.3, and found one that consisted of 42 pages. It was very thorough, but I find it difficult to believe that anyone had ever read the entire document. We discuss procedures in more detail later in this book.
TABLE 4.2 Example of Standards
Information Systems Manager/Team Leader
Managers with responsibility for Information Systems must carry out all the appropriate responsibilities as a Manager for their area. In addition, they will
act as Custodian of information used by those systems but owned by other
managers. They must ensure that these owners are identified, appointed, and made aware of their responsibilities.
All managers, supervisors, directors, and other management-level people also have an advisory and assisting role to IS and non-IS managers with respect to:
Identifying and assessing threats
Identifying and implementing protective measures (including compli-
ance with these practices)
Maintaining a satisfactory level of security awareness
Monitoring the proper operation of security measures within the unit
Investigating weaknesses and occurrences
Raising any new issues or circumstances of which they become aware
through their specialist role
Liaising with internal and external audit
TABLE 4.3 Sample Application Change Management Procedure General
The System Service Request (SSR) is used to initiate and document all program- ming activity. It is used to communicate customer needs to Application De- velopment (AD) personnel. An SSR may be initiated and prepared by a customer, a member of the AD staff, or any other individual who has identified a need or requirement, a problem, or an enhancement to an application. No tasks are to be undertaken without a completed SSR.
System Service Request General
This form, specifying the desired results to be achieved, is completed by the customer and sent, together with supporting documentation, to AD. The re- quest may include the identification of a problem or the documentation of a new request. Customers are encouraged to submit their request in sufficient detail to permit the AD project leader to accurately estimate the effort needed to satisfy the request, but it may be necessary for the project leader to contact the customer and obtain supplementary information. This information should be attached to a copy of the SSR.
After the requested programs have been completed, the agreed-upon Ac- ceptance tests will be conducted. After the customer has verified that the request has been satisfied, the customer will indicate approval on the SSR. This form will also be used to document that the completed project has been placed into production status.
Processing
This section describes the processing of a System Service Request:
1. The customer initiates the process by completing the SSR and forwarding it to the appropriate Project Manager (PM) or the Director of Application Development.
2. The SSR is received in the AD department. Regardless of who in AD actually receives the SSR, it must be delivered to the appropriate PM. 3. If the PM finds the description of requirements on the SSR inadequate
or unclear, the PM will directly contact the customer for clarification. When the PM fully understands the requirements, the PM will prepare an analysis and an estimate of the effort required to satisfy the request. In some cases, the PM may feel that it is either impossible or impractical to satisfy the request. In this case, the PM will discuss with the customer the reasons why the request should not be implemented. If the customer reaffirms the request, the PM and Director of AD will jointly determine whether to appeal the customer’s decision to the Information Systems Steering Committee for a final ruling on the SSR.
4. If the project estimate is forty (40) hours or less, the detailed design should be reviewed with the customer. After design concurrence has been reviewed, the PM will project the tentative target date (TTD) for completion of the SSR. In setting the TTD, the PM will take into consid- eration the resources available and other project commitments. The TTD will be promptly communicated to the requesting customer.
5. If the project estimate exceeds forty (40) hours, the SSR and any supple- mental project documentation will be forwarded to the ISSC for review, priority determination, and authorization to proceed.
The committee will determine whether the requested change is to be scheduled for immediate implementation, scheduled for future imple- mentation, or disapproved. If the request is disapproved, it is immediately returned to the customer, together with an explanation of the reason(s) for disapproval. If it is approved for implementation, a priority designation is made and the SSR is returned to AD for implementation scheduling.
After implementation authorization has been received, the detailed design should be reviewed with the customer. After design concurrence has been received, the PM will project a TTD for completion of the project. In setting a TTD, the PM will take into consideration the resources available and other project commitments. The TTD will be promptly com- municated to the customer.
6. The PM will coordinate with AD personnel and other IT management and staff personnel (such as Database Administration, User Support Services, Network Administration, etc.) if their resources will be required to satisfy this request, or if there will be an operational or procedural impact in the other areas.
7. The PM will contact the customer to discuss, in detail, the test(s) that are to be conducted.
8. When Acceptance Testing (AT) has been completed and the customer has verified the accuracy of the results obtained, the customer will indi- cate their approval to place the project into production by signing the SSR.
9. The Production Control Group (PCG) will place the project into produc- tion status. The PM will complete the bottom portion of the SSR, docu- menting that the project has been placed into production. The PM will log the status of the request as “completed” and file a copy of the SSR. The PM will promptly notify the customer that the project has been completed and placed into production.
Retention of Forms and Documentation
All documentation associated with the processing of each SSR will be retained for at least twelve (12) months.
TABLE 4.3 (continued) Sample Application Change Management Procedure
4.8.4
Guidelines
Guidelines are more general statements designed to achieve the policy’s objectives by providing a framework within which to implement proce- dures. Whereas standards are mandatory, guidelines are recommendations. An everyday example of the difference between a standard and a guideline would be a stop sign, which is a standard, and a “Please Keep Off the Grass” sign, which would be nice but it is not a law.
Some organizations issue overall information security policies and standards documents. These can be a mix of Tier 1, Tier 2, and Tier 3 policies and their supporting standards and guidelines (see Figure 4.3).
While it is appropriate to include policies in a document such as this, it is considered impractical to include standards, procedures, or guidelines in Tier 1 policies.