Policy Document Outline In addition to the policy statements that will form the main body of your policy documents see Appendices 1-2 for sample policy outlines, each policy should incl
Trang 1© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
9 Policy Document Outline
In addition to the policy statements that will form the main body of your policy documents (see Appendices 1-2 for sample policy outlines), each policy should include the following sections
9.1 Introduction
This section should introduce the policy by name and locate it within the
hierarchy of other existing information security and company policy documents
9.2 Purpose
State the main goals of the policy; this will explain the reason for the policy and will help readers understand how the policy should be used Legal and
compliance issues should also be mentioned in here Include statements on any specific legislation the policy is designed to adhere to
9.3 Scope
The scope is a statement of the infrastructure and information systems to which the policy applies, and the people who are stakeholders in it Stakeholders would typically include anyone who is a user of the information or systems covered by the policy
9.4 Roles and Responsibilities
This is a statement of the structures through which the responsibilities for policy implementation are delegated throughout the company Job roles may be specified in this section, e.g., Database Administrators (DBAs), Technical Custodians, Field Office employees, etc
9.5 Sanctions and Violations
This section details to what extent breaking policy is considered a violation (e.g.,
it is HR-related and therefore related to an employee’s contract, or is it an information security department matter?) This section should also detail how violations should be reported, who to and what actions should be taken in the event of a violation It should also include information on what sanctions will be carried out resulting from a violation (for example, verbal or written warnings, etc)
9.6 Revisions and Updating Schedule
This section defines who is responsible for making updates and revisions to the policy and how often these will take place It may be useful to include a
reference to the document as a “living document” which can be updated as determined by those responsible for updates and revisions This will ensure that any ad hoc revisions are accounted for as well as scheduled updates
Information should also be included detailing where the policy will be published
and how employees can access it
Trang 2© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
9.7 Contact information
Detail who should be contacted in connection with policy A group or mailbox rather than an individual is preferable here as these are less likely to change
9.8 Definitions/Glossary
Define any terms that may be unfamiliar to the reader The necessity for this will depend on the audience, e.g., the readership of a Technical Policy for Linux are likely to already be familiar with the Linux technical terms, therefore it will not be necessary to spell these out The cryptography section of the user policy
however may include terms with which readers are not familiar and these should
be defined in footnotes or a glossary to aid comprehension
9.9 Acronyms
A separate section spelling out acronyms may be required where there are a large number or where the document is long or complex For shorter documents, acronyms may instead be spelt out in the body of the document
Trang 3© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
10 Troubleshooting
This section details some of the things that go wrong during policy development and some ideas to remedy these problems
10.1 Policies Lack Weight
It is a big concern when policies that have taken time and effort to develop are not taken seriously This is common when starting to develop information security policies and for those whose development process isn’t yet mature
Don’t worry too much at these early stages Weight is likely to come with time and increasing numbers of policies, backed up and promoted by a combination of management backing and a good awareness/communication campaign With this will come a realisation on the part of the enterprise (and particularly those bodies involved in compliance and governance) that policy can be used to leverage change and a move towards best practice and compliance
10.2 Lack of Reviewing Feedback
Lack of feedback following reviews can also be a fairly common complaint from the policy development team This is fine if the reviewers have read the policy and simply don’t have any feedback; the problem arises when they have skimmed over the document without reading it closely or taking in the implication
of its content In these cases problems may only be noticed at a much later stage or, even worse, after publication This can serve to weaken the policy and even discredit the policy development process as a whole
One solution is to review each document in detail at a meeting (or meetings) with each group of reviewer The development team representative can read through each policy statement and seek feedback on each one This will help make sure the reviewers have both read and thought about the policy in detail
Sometimes reviewers may not be sure what is required of them and this may result in a low level of feedback To avoid this, inform all your reviewers about the process and what is expected of them (e.g., you are looking for feedback on the technical content of the policy rather than on typos and grammar errors)
Another possible reason for this is simply not giving the reviewers enough time to review Be aware of their workload and agree a realistic timescale in advance If you are dealing with review groups regularly for more than one policy, agree a regular timescale and stick to this
10.3 Resources Shortage
This is frequently caused by two things: lack of management support and genuine resource shortages due to high workloads and cost cuttings exercises
Trang 4© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
If you really can’t get access to those people you need to to write the policy, consider putting it on hold until the resources are available Try management your plan and point out that the company will be without the policy until resources can be found This may change their mind or they may decide that other things take priority
10.4 Reviews are Slow and Cumbersome
Sometime reviewing policy can seem to go for a long time This can be because the project team size is too large The optimum size for the core team is around
3 people 2-4 is fine but any more than 4 and you start to have to take a lot longer to air everyone’s views on each policy statement If there are other people who are keen to be involved, keep the project team small but have the additional people review the policy as external stakeholder in a review period of their own This way not everyone has to be consulted every step of the way but everyone still has an input
Another reason for slow reviews is that often no one wants to take responsibility for making a decision This is particularly the case on more contentious issues such as whether to allow instant messaging for all employees or what kind of mobile devices are allowed to be used Reviews can often get stuck if no one wants to make the final decision As always, take account of all opinions but try not to let policy get stuck on this Maybe make a softer policy statement in the interests of getting something published You might find in 6 months things have changed and a decision can be reflected in a more strongly-worded updated policy
10.5 Legislation Compliance Queries
How do we know if we are complying with legislation? This is a commonly asked question in relation to policy To ensure compliance, it is important to use your Legal and Compliance teams Get their input on what is required and tie your policy statements to specify legal or regulatory requirements
For larger companies, consider investing in a policy management system which will help you to track where your policies correlate with legislation and best practice
10.6 Policy is Quickly Out of Date
If your users are complaining that policy is out of date when it is published, take this seriously It is another issue that can quickly discredit your policy
development program
Reason for this include your review process being too slow (see section 7.4) or that policy is too focused on current practice and future changes aren’t
considered during the development stages Make sure to consult your reviewers
on where they think security is heading in the future for a given technology or
Trang 5© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
application This will ensure this is reflected in policy as well as what happens today
10.7 Policy is Unclear
If people can’t understand or interpret your policies, they are unlikely to comply with them Indeed, policies shouldn’t be open to interpretation; they should be clear and concise, with each statement having only one possible meaning To ensure this is the case, use a style guide and the services of a technical writer or
an editor for each policy Make sure you have a proper final review process in place where your policy is proof-read before being published This should get rid of any last-minute typos or issues that will prevent comprehension
10.8 People get Upset by the New Policy
People don’t like change Especially when they have been doing something one way for a long time, they don’t like to told that there are now new rules that say they have to do it differently – even if those new rules will make their lives easier
in other ways once they’ve got over the short term pain of making the changes
These are the simple reasons why there is often resistance to new and revised policies Some of the industry’s most experienced security experts have
encountered this phenomenon13 and it is something that you can expect to contend with throughout the policy development process
Users will often have well-founded reasons for being concerned They don’t want to be bound by tight controls that make their job more difficult and management are concerned by possible increased costs associated with putting the policy into practice14 The best you can hope for here is to draw their
attention to the benefits of developing the policy and point out that you need their help to do it properly and so that their fears aren’t realized Users and system support staff will often be concerned that the policy development team is going to force policy upon them without any comeback and this can make them resistance
to participating in the development process Be sure to fully explain your process
to them at the start and make it clear that you need their input Be firm, this policy is getting written, but you want to make sure it is workable and you want their help to do this You anticipate that once it is in place it will actually help them in their job role because it will give them a clear template for which controls they have to adhere to See section 2.4 for more detail on this issue
Lastly, persevere Initial reluctance can often give way to beneficial input and good support later on
13 Guel, p.5
14 ibid
Trang 6© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
11 Conclusion
Policy is both the starting point and the touchstone for information security in any company Policy provides evidence of the company’s stance on security and provides a living tool for every employee to help build and maintain that level of security It is therefore essential that security policy is accurate, comprehensive, and useable It can be a daunting task to produce policy that lives up to this standard Assessing policy audiences, topics, and methods using the processes
I have described in this paper will help to ensure that your policy documents are
as efficient and useable as possible In turn, this will help ensure that your efforts
to raise the standard of security in your company are worthwhile
Trang 7© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
References
Barman, Scott Writing Information Security Policies New York: Que, 2001
Danchev, Dancho “Building and Implementing a Successful information Security Policy.” 2003 URL: http://www.windowsecurity.com/pages/security-policy.pdf (10 July 2006)
Desilets, Gary “Shelfware: How to Avoid Writing Security Policy and Documentation That Doesn’t Work.” 20 Apr 2001
URL: http://www.giac.org/practical/gsec/Gary_Desilets_GSEC.pdf (10 July 2006) Guel, Michele D “A Short Primer for Developing Security Policies.” 2001
URL: http://www.sans.org/resources/policies/Policy_Primer.pdf (12 July 2006) Harris, Shon, CISSP All in One Certification Exam Guide New York: The McGraw-Hill Companies, 2002
Jarmon, David “A Preparation Guide to Information Security Policies.” 12 Mar
2002 URL: http://www.sans.org/rr/paper.php?id=503 (10 July 2006) JISC, “Developing an Information Security Policy”, 1 May 2001 URL:
http://www.jisc.ac.uk/index.cfm?name=pub_smbp_infosec (10 July 2006) Kok Kee, Chaiw “Security Policy Roadmap – Process for Creating Security Policies.” 2 Oct 2001 URL: http://www.sans.org/rr/paper.php?id=494 (10 July 2006)
Lambe, Jennifer L Intercom, “Techniques for successful SME interviews.” Mar
2000, pp.30-32 Lindley, Patrick J “Technical Writing for IT Security Policies in Five Easy Steps.”
20 Sept 2001 URL: http://www.sans.org/rr/paper.php?id=492 (10 July 2006) Long, Gerald P “Security Policies in a Global Organization.” 25 Feb 2002 URL:
http://www.sans.org/rr/paper.php?id=501 (10 July 2006) Peltier, Thomas, R “Information Security Fundamentals.” 2002
URL: http://www.gocsi.com/ip.htm (29 Sept 2003)
Trang 8© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Russell, Chelsa “Security Awareness – Implementing an Effective Strategy.” 25 Oct 2002 URL: http://www.sans.org/rr/paper.php?id=418 (10 July 2006)
“Best Practices – Security Plans and Policies.” URL:
www.itsc.state.md.us/info/InternetSecurity/BestPractices/SecPolicy.htm (24 Sept 2003)
Trang 9© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Appendix 1: Governing Policy Outline
The outline below gives the broad topic headings for a sample Governing Policy
The sections outlined in the Policy Document Outline section of this paper should also be included at the beginning of any Governing Policy
Many of these topics will be relevant to the information security of all organizations, however some will vary according to the technology, systems, and applications used
1 Responsibilities – Information Security and Audit Departments
2 Email and Internet Use
3 Ethics and Appropriate Use
4 Personnel / Administration
5 User Identification and Accountability
6 Managing Users Accounts
7 Authentication
This section might include statement like:
• User IDs and passwords must not be shared
• Passwords must not be written down
8 Access Control
9 Authorization
This section might include statements like:
• Authorization must only be granted to access company information and systems
to the level required for a user’s job role
• Authorization to access information and systems must be re-verified at a minimum annually
10 Auditing
11 Physical
12 Hardware
13 Software
14 Incident Response
15 Intrusion Detection
16 Cryptography
17 Data Classification
Trang 10© SANS Institute 200
7
, Author retains full rights.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
18 System and Network Controls Including software settings and system configuration and settings and patching
19 Business Continuity / Disaster Recovery
20 Compliance Measurement
21 Change Management
22 Information Handling Including printing, copying, faxing, mailing, emailing, etc
23 Information Backup
24 Remote Access
25 Third Party / Service Provider Management
26 Network Connections Including internal and external and wireless
27 Instant Messaging
28 Web Conferencing
29 Voice Communications
30 Application Development Each section should detail what the company’s stance is for each area in terms
of the high-level requirements