Many organizations issue overall information security manuals, regulations, handbooks, practices and procedures, or other similar documents. These documents are a mix of policy, standards, guidelines, and procedures because they are closely linked. While such documents serve as a useful tool, it is important to distinguish between a policy and its implementation elements. Policy requires approval of management teams, while standards, guidelines, and procedures can be modified as needed to support changing environments.
4WHAT DOES A STANDARD LOOK LIKE?
Standards have no set pattern other than they must have a verb that relays the message to the readers that what they have just read is required. The standard can be as simple as “All passwords are to be kept confidential.” Standards can also require the use of certain equipment, such as “Marketing personnel will use Mac workstations.” They can also require certain forms of software or operating system levels.
The important part of developing standards is to make certain that they meet the needs of the organization. Just as when you develop policies you keep in mind the business objectives and mission of the enterprise, you must also keep these in mind when developing standards. It will do no good to create a standard that is difficult to implement. “All data contained on company workstations must be encrypted when stored or transmitted.” This might be a great goal but it will probably slow down the business process and be abandoned by management and staff.
The standards, along with the policies, will provide the business units with a reference document that will permit them to develop local procedures to be implemented in a
consistent framework. Even if you are a multinational organization, the standards manual will provide for a consistent structure upon which to build the security program.
It will be necessary to instruct the user community as to what is expected of them when using the standards. Typically, the standards manual will have a section on how to use the standards and this is where you identify the standards on standards usage. The process might read as follows:
In implementing the standards, the following process is to be used: Review existing procedures and practices against company standard. Document business unit’s current compliance level.
Document deficiencies. Create a compliance plan. Implement compliance plan. Check compliance annually.
The remainder of this section is an Information Security Standards Manual that can be used as a template for building your own standards manual or to do a gap analysis for your existing document. I recommend that each section of the document begin with a Tier 2 policy outlining the overall objectives of the section. Examples of Tier 2 policies are also included in this book in Chapter 4.
Standards must be reviewed at least annually to ensure that they are still meeting the business needs and operating environment. Information security personnel are often looked upon as the group that puts roadblocks in the way of getting business completed. For example, one morning, my wife and I were having a discussion about her current job assignment (to implement a single sign-on solution). One of the problems she was having was that there was a requirement to change user passwords every 30 days. I asked her why they were required to do so, and she told me, “Because it is a standard.” I asked her why was that a standard to change a password every 30 days, and she told me, “Because it has always been that way.”
Well, being ten years older than my wife, I knew that it really was a standard that we began to implement when access control packages were being installed in the mid-1970s. These new packages allowed us to make it so the user could change his or her own password. Prior to that we had to run a batch job to manually change the passwords and have the employees or their supervisors sign for the new passwords (I usually did this once a quarter). Well, with ACF2, RACF, and Top-Secret, we could now have the users do this task. It also allowed us to establish the timeframe, and many of us began to establish a de facto standard of 30 days.
So here they were attempting to install a single sign-on package that was running smack-dab against an outdated standard. The mid-1970s saw the processing environment of TSO and IMS; those really advanced had CICS. There was not a terminal on every desk, but a terminal room where you signed up to use the terminals. Remote job entry meant a card reader on another floor. The environment had changed but the standard remained the same. When it was first introduced, we told employees not to write down their password. Now, because of the proliferation of accounts, we tell them not to leave the card containing their account information lying around. To be effective, standards must keep pace with the changing environment and technology.
5WHERE DO I GET THE STANDARDS?
As previously discussed, there are many places to obtain sample standards. For those working in healthcare, the HIPAA requirements are available; and for financial institutions, the GLBA requirements should be used. I suggest that you develop a document like the sample below that will help you identify what is expected by the specific requirements placed on your industry or organization. Map these requirements to your own organization and, where possible, determine your current level of compliance. The one in Table 1 uses ISO 17799 and BS 7799 as reference documents, with a partial review of GLBA requirements included.
6SAMPLE INFORMATION SECURITY MANUAL
A Sample Standards Manual is provided in Appendix 1C. It was designed to give you the feel and flavor of what you might want to include in a standards document that will support your information security program. The manual contains a series of information security standards that would be commonly implemented throughout an organization. The standards will then form a baseline against which compliance can be measured. This compliance measurement can subsequently be used to report to management on the state of information security within the organization.
It will be important to work with the subject matter experts (SMEs) to determine which standards meet the current level of technology throughout the organization. It may become necessary to establish a baseline operating environment for the organization. This might mean that in some areas of the standards document, the business units might first have to upgrade their operating environment to meet minimum compliance levels. If you encounter pockets of back-level operating environments or groups that are using non- standard equipment, it will be necessary for the business unit to create a compliance plan.