With all the technical and software security solutions available to security professionals today, there is a tendency to forget what is possibly the single most important factor in any security program, the user. The user s cooperation and support of a security program can mean the difference between a successful security program and one that fails miserably. If the users do not know what is expected of them, a security program will be ineffective and can lead to misinterpreted security intent. In this chapter, we will discuss what steps you should take to gain user support and establish a security campaign.
Before you can get user acceptance, you have to know what your security efforts will be. This rather obvious sounding statement seems intuitive, but one issue new security campaigns face is the fact that they are often unfocused and lack the documentation necessary to effectively convey the security strategy. A security campaign is the coordinated, focused effort of the security practitioner to communicate the security requirements to the users. This includes educating users on social engineering, proper password creation, laptop security, and so on. The security campaign can use many methods to accomplish the goals of communicating the security objectives. This can range from the traditional policy-only program to one that uses multiple forms of educational materials such as posters , e- mails , internal websites with whitepapers and tutorials, screensavers, and security events.
Regardless of the delivery method of the security program, you must determine what the goals of the security program will be. If no security program was previously in place, your job will require more investigation on the needs of the company, otherwise you will need to build upon the previous program. The first step is to determine the needs of the company and how to align the security program to those needs. There will be major differences in the scope of the security program for those working in regulated industries from those in retail sales for instance. Your risk assessment conducted in Chapter 15 will assist you in determining what you are required to do by regulation or law (federal, local, or company). The risk assessment can show you your weak areas and allow you to focus on creating policies for the deficient areas first. By viewing policy creation as a step-by-step process, you can tackle the most urgent issues in a piecemeal fashion first, rather than try to create an all-encompassing security policy that covers all aspects of information security in your company.
If your company is looking to be in compliance with an information security standard, such as ISO 17799 (BS 7799-2) standards, there is a standard set of clauses that you will use as a guideline for your policies. For instance, there are specific subsections on most major aspects of information security within companies outlined. These clauses do not necessarily have policies accompanying them; rather, they set out a basic, high-level statement of need, giving you the framework to build your policies on. Using a well-established set of internationally recognized guidelines will make the creation of your security program more methodical and focused, as well as lend more credibility to your policy efforts. Some of the guidelines that are widely known, which you can use as a basis for your security program, are shown in Table 16-1.
ISO 17799/BS 7799-2
Code of Practice for Information Security Management (costs around $250)
Generally Accepted System Security Principles
Still in development
In very early stages of development
The Internet Engineering Task Force's (IETF) guide for security policies
IT control standard that can be beneficial to security professionals (costs between $150 and $300)
Using these standards as the foundation of your security program, you can begin the next stage, the creation of policies and standards for your organization.
Now that you have determined your goals, you need to decide what steps you will take to distribute the message to the users, management, and others affected by your policy. Most security programs consist of a security policy and occasional security awareness presentations. You should create your policies before creating your security awareness program, as your awareness program should be based on your policies and industry best standards. This is great if your users remember your program throughout the year or if they read your policy often. In the real world, users must be reminded of what is expected of them in both traditional and nontraditional ways. Most innovative security programs consist of alternative ways of delivering your security message, including but not limited to:
Internal websites Create an internal website with current security information and trends.
Security posters Provide visual reminders of the security policy.
Security screensavers Use your choice of screensaver creation programs and come up with interesting slogans.
Computer-based training Use multimedia to provide consistent, perpetual training.
Security trinkets (such as keychains or cubicle toys) There are a multitude of branding companies with trinkets for sale.
Lunch presentations Have the company purchase lunch as an enticement to attend frequent security awareness presentations.
S ecurity contests Give away prizes for remembering some part of a newsletter, for example.
Newsletters Create a paper or e-mail newsletter with the latest security information.
Anything you can do that will keep your users attention and get them to think about security is a great part of the security program, and offers more than plain security policies. Determining what alternative materials to use in your security program is largely dependent on your company s culture and your budget for security. The solutions above allow you to create an interesting program whether or not you have a security budget. After determining the components for delivering your security program s message, you must begin creating the actual guidelines for users to follow in the form of security policies.
Before embarking on policy creation, we should make note of some oddities in the information security field. A policy is a document that specifies actions to be taken or rules to be followed to be in compliance with the directive. Note that some in the information security industry will call a policy as defined above a standard, guideline, or directive. For the purposes of this book, we will refer to the policy as the document that outlines rules or actions to be followed, while a standard will be referred to as a document that offers step-by-step instructions for complying with a policy.
Concise , easy-to-understand policies are very important in communicating your security requirements and objects to management and users. Policies are the framework for the users and management to follow allowing for the systematic and uniform application of security principles throughout the organization. Well-written policies can make the security administrator s job easier as well as getting user and management support by informing them of the requirements and meanings behind the security program.
Before embarking on your policy creation, you should determine what resources you will need to create the policy. This will primarily be staff that can assist in the creation of your security policy. The policy development team is a different group than the user forum discussed in Chapter 15. The user forum is primarily consultative in nature, while the policy development team will actually formulate the policy that is followed. You should choose a team based on the expertise of the individual and how well they can write concise, instructional policies for the staff. You will want to have an expert on each of the major policy areas you will be outlining, as the experts will usually know their areas best and what the security requirements should be.
There are different ways to approach the creation of security policies. You can create a comprehensive single document security policy that covers all aspects of security in your organization, or you can choose to write a policy for the major sections that need to be covered. The type of policy you choose is completely dependent on your organization s situation and culture. If a large corporation or government entity employs you, an all-encompassing policy might be well within normal expectations. If you are in a smaller company, there may be an expectation that you keep all documents very concise and create separate documents for every situation (or the reverse may be true). For most security professionals, an all-inclusive document that references other policies and standards is the easiest route to take. This is because you can create your policy in a way that you can cover the major aspects of information security needs in your organization quickly and then link to more specific and time-consuming policies for specialized areas. An added benefit of this technique is that all the users can view the main document for security guidance, and those who need specifics can refer to the more comprehensive policies as needed. Most comprehensive security documents have the following security elements at a minimum:
Acceptable use provisions Outline what is allowed and disallowed on organizational resources
E-mail provision Outlines all aspects of e-mail, including retention periods, proper use, and other factors
Information classification Specifies the protection levels afforded different sensitivity levels of corporate assets
Password and antivirus provision Provide guidance on proper password selection and use of anti-virus tools
Remote access How access to the organization s resources will be handled when originating from outside the organization s infrastructure
The items listed here are only the core set of provisions outlined in security policies and aren t necessarily required, but in general are included in most policies. You should also outline other specific provisions in your policy, such as third-party access guidelines and physical access guidelines.
As you begin to work on defining policies, the first step you should take is to try to refer to policies created by others in your industry. If this is not possible, you will need to rely on your own knowledge of business needs and management expectations. Talk to management and human resources to see what is expected of a security policy. You can also research online as a starting point to get a general idea of how other companies use security policies in their organization.
You are now ready to write your security policy. The basic requirements of a security policy are that it includes the following information:
Scope This identifies what the policy covers in terms of physical location, staff, procedures, or process. This sometimes identifies what the penalties are for noncompliance with the policy.
Overview This describes why the policy is being put in place, what is being protected, or any other amplifying information.
Policy This is actually where policy is being defined.
Most policies usually include the following highly recommended sections as well:
Revision history This shows the revision history of the document (when it was last updated).
Definitions Any words or acronyms that may not be readily known to readers are defined here.
Effective dates This is for special-purpose policies that are only in effect for a certain time frame, such as during a transition to a new technology.
Management signature This shows that management is behind the policy and lends credibility to the policy.
The first step in the creation of your security policy is to determine the scope of your policy. The scope or coverage of your security policy should be within your area of responsibility. Basically, you should not create a scope for your policy that is inappropriate or too broad. For example, if you are a subordinate organization or business group to a larger group, you usually must defer to the higher organization s authority and rules. This is not always the case, and most companies won t restrict you from being more aggressive in your implementation of security policies, but this is something that needs to be determined by contacting your higher-level security staff. Regardless of whether you have autonomy or not, the scope should be realistic and within your realm of influence.
We use a fictitious company named Example Company and create a sample scope statement (we will continue to use this example throughout the policy creation). The company has no dedicated security staff and after a recent risk assessment conducted by the system administration group, it is discovered that the use of unencrypted telnet was their biggest risk. Karen, who is in charge of the system administration group, decided to implement a policy of requiring SSH throughout the company. Karen determines that she is responsible for all system administration functions and that she has the sphere of influence for the entire enterprise, which is confirmed by management. Karen creates the following scope statement for her SSH policy: This policy applies to all users and computers using Example Company corporate resources. This simple scope statement conveys in a clear and concise manner who and what the policy applies to.
The overview should include a brief statement of what the policy is about. You should also explain why the policy is being put in place and what is being protected in the overview in order to gain users acceptance and support of the policy. An overview should be concise and provide a quick glance of the more in-depth policy that follows . For example, if you need to create a policy on the requirement for encrypted protocols on the network, a simple overview statement for this could be
This policy defines the requirement for the use of Secure Shell (SSH), Secure File Transfer Protocol (SFTP), and Secure Copy (SCP) on the corporate network. These protocols use encryption during the transfer of the information, including usernames and passwords, and prevent interception of sensitive company information.
The basic overview above meets the requirements of identifying what the policy will be about, and then provides the user with some background information on why the policy is needed. Your overview shouldn t be too long or it distracts the user away from the actual policy and will tend to discourage the reader from reading the actual content of your policy.
The policy section is where actual rules or guidance is provided to the reader. This is the hardest part to write as it is the most in-depth and requires specific instructions. Before trying to create a policy from scratch, try to determine if there is a template for a policy similar in nature to the one you are trying to create. Depending on your organization s specific industry, you may want to try to locate policies from the same industry. For example, if you are in the utility industry, you would want to see if there are other utility companies with publicly available policies for use as a base for your policy. This is because some industries have special requirements not met by completely generic template policies. If you can t find policies specific to your industry or they are not required, here are some resources for good baseline policies:
The SANS Security Policy Project:
SecurityFocus.com s Introduction to Security Policies:
When creating a security policy, keep it as concise and brief as possible. This doesn t mean you should keep it so brief that you don t offer precise information on what is expected of the user. There shouldn t be any gray area or any segment of your policy that is left to too much interpretation. If you have to be vague on any points, make sure to note who the reader can contact for further clarification .
Now that you have the basics of what a policy consists of, let s create a sample policy using the SSH example used previously. Here is a basic policy statement:
All users of network resources are required to use encrypted protocols when accessing network resources. For users requiring shell access, SSH must be used and specifically OpenSSH, which is included on all system administration managed servers. SFTP or SCP must be used for file transfers or remote copies, respectively, using the toolset included with OpenSSH. Telnet, FTP, RCP, TFTP, Rlogin, or any other non-secure protocols are not authorized. Exceptions to this policy must be requested in writing with business case documentation and approved by the vice president of network operations.
The preceding policy statement is concise and provides a way for users to request exceptions to the policy based on business need. This particular policy could have been included in a larger, unified policy document for easier reading. For our purposes we will keep it as a single document that outlines a single security requirement.
Now that you have the basic policy statement, it is time to pull it all together. Figure 16-1 shows a completed sample policy with extra items added.
This sample policy is not the most aesthetically pleasing, but it conveys the point. You will want to use your company s document templates to make it more visually appealing and easier to read.
Review your policies with those who will be impacted and those who understand company policies on legal and human resource issues as well as management and users. If a policy is released before the input of the staff who have a vested interest in the security policies, you may end up having to do many public revisions before a finalized policy is released. This can create confusion on what the most up-to-date policy is and generally creates confusion among all involved.
Query Interested Parties To ensure that your policy meets the needs of the company and follows already established guidelines, you will need to contact different groups to determine the policy s overall viability in the organization.
Some questions you will need to ask are shown in Table 16-2.
Whom to Ask
Does the policy make sense?
Users and management
Is the policy within organizational and legal requirements?
Legal and human resources
Is the policy enforceable?
Legal and human resources
Is management behind the policy?
Are the users behind the policy?
Table 16-2 shows only a sampling of the questions you should ask. You should take notes when asking the different groups questions about your policy and modify your policy as needed. If legal, human resources, or management disagrees with or questions your policy, you should seriously reconsider the policy as it may be ineffective from the start or, even worse , violate some legal regulations. There will always be some users who don t agree with a policy, and you should note their concerns before implementing the policy. Remember that you can t please everyone, so be prepared for some disagreement and interesting discussion.
Create a Security Forum Another way to involve your users and management is to create a user security forum. In this forum, you can gather a select group of representative users. You can present your policies and other aspects of your security program to determine what impact, if any, the program will have. This is a step that many security professionals skip, because there is a perception that user input is not needed and an unnecessary burden . One of the major problems with not consulting the users is that they are a crucial part of the security program, and if they don t agree with the policy or at least understand the reason for the program, they might rebel against it. For example, a security officer at a company proposed installing a retina scanner on the computer room doors to control access. The users found out about the proposal and began to complain to their direct management and upper management. These complaints weren t based on any facts; the users were just uncomfortable with having a device read their eyes. There was the perception that a laser would be reading their eye, and if they moved there was potential for blindness or other unfortunate results. There were other issues, but the crux of the problem was that the users hadn t been given the proper information prior to the proposal, and they were uncomfortable with the technology. The proposal was denied and an alternative technology had to be implemented because management hesitated to implement a device that so many users disagreed with. This problem could have been prevented if there had been a user forum, where the security officer could have given the facts to the users, who could then dispel the rumors before they got out of hand. This example applies to policies as well. If you wanted to implement a policy requiring users to have their bags inspected before leaving the building, there might be serious user backlash , but if the program is explained beforehand and users are consulted, the policy will have less of a shock impact on the users.
As stated throughout this chapter, users are a very important part of the security program. If the users do not support or are openly hostile to the policy, it will have a diminished impact and eventually fail. You want to give the users a sense of ownership of the program, allowing them to feel like they are part of the security process.
Most people do not like to have rules dictated to them, and prefer to have some say about things that affect their day. Some things must be dictated, such as policies on prohibiting illegal downloads of copyrighted material on organization assets or requiring people to wear a badge when on company premises. Other times there is leeway to allow the users to effect some type of change in order to gain broad acceptance of the program and minimize the impact. If at all possible, ask the users to assist in developing the security policy because it will make it easier for them to accept.
If your security program is being put in place where there were no security policies or very lax ones, your users sensitivity to the policy is amplified. Change is difficult for users, and the changes that are put into place as part of a security program are sometimes stressful. Frequently your security program will be seen as an impediment to normal working processes. For instance, if you implement a requirement for the use of sudo (which limits the commands that users can run based on preconfigured permissions) in an environment where everyone previously had access to the root account, you will be seen as someone who is preventing work from being done. The users may resist your changes and complain to management or they may become hostile toward you. This is not because you personally are trying to create an obstacle to their work, but because the status quo has been disrupted and there is a feeling of losing control. As the security professional you become the target because you are the face of security. You must learn to not take the user s frustrations personally . Instead, you should use the opportunity to explain the reasons behind your security policy and try to enlist the user as an ally.
Gaining user support at the beginning of the security program is important, as they can offer advice on implementation of the program in a way that will be accepted by their peers. A user security forum is an excellent way to give users ownership of the security program. Even if the user does not like the policy, having their input and listening to it can be the catalyst needed to gain support. For example, let s imagine that you are working on a password policy for your organization. Nobody likes hard passwords; in fact, most users would prefer to use much easier passwords and be done with it. Most people understand the need for strong passwords because it has been explained many times, from many different sources. Having a user security forum would allow you to explain the reason for the policy, and to put into context the overall security architecture and how the different pieces of the security puzzle create the security program. The users involved in the security forum will often take the information you have passed to the other users, creating an understanding of the policy s intent. This allows your security program to start off on the right foot .
Another way to gain user acceptance of the security program is to show how security applies to them. A good way to do this is to show them through newsletters, e-mails, or security awareness training how to secure their home computers or other things that affect them outside of work. Also explain how attacks occur and why attackers target home computers, and then show the parallel to the organization. For instance, most users wonder why they should bother securing their home computer. Most think that if there is no personal information on their computer, an attacker wouldn t try to target them. When users hear that attackers don t necessarily want to read their e-mail or steal the information on their drive, but would rather use their computer as a launching pad to attack other higher profile targets, they take notice. They begin to understand the risks to the organization as they draw parallels to their own systems. There are many ways to explain the parallels from their home computer to the organization s computers, as shown in Table 16-3.
Home User Risk
Corporate User Risk
Insecure computer could be used to attack other computer or host programs that open up mail relays for spam.
Insecure computers could be used to attack other networks, host mail relays, or steal corporate information.
Social engineers could attempt to gain access to personal information such as credit card information for later use.
Social engineers could attempt to gain access to corporate information such as usernames and passwords for later use.
Poor passwords could allow access to private information such as banking records.
Poor passwords could allow access to corporate financial data.
Getting management to openly support your security program is another way to gain user acceptance. If you have to implement an unpopular policy, having management support your initiative openly can provide the needed prop to encourage users to follow the program, even begrudgingly. Open support by line management and upper management is critical for the program to be supported by the end user, as they often take their lead on the myriad of corporate programs from their management s willingness to enforce the provisions.
Not all portions of your security program will be popular with users, but allowing users to voice their complaints and provide input into the program will lessen the resistance to the program and make the program much more effective than it would be without user support.
You have created the security program, explained the program, and gained user support. Now what? You have to evaluate the program to ensure it is working as expected.
Evaluating your security program through tools described in Chapter 14 is a good start for evaluating your program from a technical point of view. To evaluate your users, there are other ways to determine the impact of your security program. The most obvious way is to ask them. Do they understand the security strategy? If so, do they support the goals of the security program? Ask these types of questions in an informal forum to avoid canned, meaningless responses. Getting raw feedback from users will serve two purposes, the first being that you can really gauge if you got your message across. The second purpose is that it can allow you to further explain the reasons behind the program and possibly convert the user to an ally. Either way, you are showing the user that you care about their input and are genuinely concerned about the impact security has on their job.
Other ways to determine the effectiveness of your security program are to conduct penetration testing or live evaluation testing. This involves hiring a consultant or disguising yourself to determine if your users comply with policies, such as methods of authenticating users who call the help desk for a password change or checking identification of users before entering the building. These types of programs are complicated to run because they require multiple layers of management approval and often do not test the true readiness of your users. If done incorrectly, penetration testing can cause more problems than it is worth, as it can open the initiator to punitive action. If you decide to take this route, ensure that all levels of management are aware of your plans and consult with a company who is knowledgeable on penetration testing.
Do not rest on your laurels after implementing your security program, even if it is initially successful. Many highly regarded organizational security programs that started strongly failed in the long run because of apathy. You must continue to engage your users to think about security and maintain their security vigilance . Periodic security awareness training, at a minimum yearly, is important but not always possible because of monetary limitations. Having security awareness training, even in web-based or printed form, allows you to refresh the security program with the users and gets them thinking about how security impacts them. Do not depend on one method of delivery for your program, either. Security posters throughout your organization are useless if they are not rotated , as users begin to disregard them. The same applies to other facets of your security program, as you should provide variety in delivery methods to keep the users interest in security piqued. You must also keep your policies up to date to make the information relevant to the current business climate. Review your policy every quarter at a minimum to ensure that the policy makes sense.
By including your users in all phases of your security program, you are providing them with a sense of ownership of the process. This sense of ownership translates to user acceptance of the program and ensures that your security program starts off in a successful environment.