develop security policy

Practical IT Research that Drives Measurable Results

Develop & Deploy a Security Policy

1Info-Tech Research Group

Introduction

Info-Tech Research Group 2

• Many organizations have no formal documentation that indicates how employees should act to uphold security. Regulatory pressure is making this deficiency a business inhibitor due to the fines and sanctions that can be levied against enterprises that fail audits.

• On average, Security Policy development takes 12 months and costs $50,000; a major inhibitor to Policy development and adoption. This solution set eliminates those costs

• This solution set addresses Security Policy development and deployment in three steps:

Policy Implementation and Enforcement

Establish a Baseline of Understanding

Build the Policies

• This set will define an appropriate set of Security Policies. These documents will improve security while saving the enterprise the expenditure of precious resources.

• This set is targeted at enterprises that have no formal Policies, but is equally applicable to those looking to improve what they already have.

Executive Summary


Security Policy demonstrably improves overall enterprise security:• Security Policy defines the enterprise’s security intent and the methods it will use

to achieve that intent.

• Building Policy is shown to reduce the occurrence of breaches by as much as 93%.

Build Policy in a structured manner that involves all stakeholders:• Using an iterative process allows for the deployment of Policies as they are

created, rather than waiting for the full package to be developed. This improves security during the development process, not just at the end.

• The Policy must support, not inhibit, the enterprise’s business units. If business leaders are not involved in the process, the Policies may be inappropriate to the way the enterprise works.

Policy creation only the start; implement and enforce to realize value:• Staggered implementations that balance security impact against user impact

result in more successful rollouts. Security concepts will be new to many users though so remember to train before things get too complex.

• The work doesn’t end with implementation – enforcement required to make even acceptable Policy stick and dedicated tools are the key to successful enforcement.



Establish a Baseline

The value of Policy What goes in a Policy?

Build the Policies

Defining enterprise security intentions is the only way to demonstrably achieve them; Policy is that definition


Enterprises with Policies report greater sense of security

Security Policy is the document that defines overall enterprise intentions in regards to providing a secure computing environment.

Security Policy indicates the “what” and the “how” of enterprise security:

• What is going to be secured.

• How security will be achieved.

By following the rules as set out in a Security Policy, an enterprise is able to achieve a higher level of security because it is able to more thoroughly and consistently make day-to-day security decisions.

Survey data shows that when comparing enterprises with Policy against those without, the former group are more than twice as likely to report a high overall sense of security than the latter. Further, they are ten times less likely to report a low overall sense of security than their peers with no Policy.

Establishing security objectives is the tip of the icebergwhen it comes to Policy development


Objectives outline high-level enterprise security goals. They must be easy to digest but are not generally prescriptive.

Standards offer prescriptive guidance that govern actions. They expand upon policies to indicate specific expectations and requirements.

Baselines and guidelines are the enterprise’s security specifications. These are the “speeds and feeds” of enterprise security and the most likely component to change over time.

Procedures are the step-by-steps by which security is enacted. They tell employees the “how to” of security, not just the “what”.

Security Policy a hierarchy of related documents

Info-Tech’s twenty distinct Security Policy templates (see Appendix I) provide combined objectives & standards, include procedures, and suggest basic

baselines. This set streamlines the development of a comprehensive Security Policy.

Security Policy contents are not all the same; different types of information have different currency and relevancy. Structuring Policy into a series of documents, each with a focused intent, allows for more granular maintenance and keyed distribution of information.

More complete Policy sets provide better guidance inhow to be secure, leading to better enterprise security


Full Policy reduces the likelihood

of a security breach

By themselves “thou shalt/shalt not” objectives don’t do enough to protect the enterprise; they may indicate “what” needs to be done, but don’t provide enough context to discern the “why” and “how”. Without these factors enterprises find it difficult to enact security.

Only a full Policy set (objectives, standards, baselines/guidelines and procedures) provides sufficient information to implement appropriate protection, which is key to avoiding breaches.

Survey data shows that having objectives leads to a reduction in breach occurrence of anywhere from 19 to 46% (depending on breach type). However, having full Policies results in a total reduction of 57 to 93%. Clearly, knowing what to do and how to do it improves security more than just knowing what to do.

n=114

“Policy is ineffective without procedures to guide users on how to adhere. Procedures are required so that everyone interprets and acts on the Policy in a

consistent manner.”- IT Director of a small Not For Profit




Build the Policies

Follow a framework during document creation

Negotiate stringencywith the Business

Big bang not the answer; phased Policy development and deployment improves security faster


While it may seem ideal to first fully create and then implement the entire Security Policy, doing so slows down adoption and leaves security gaps during the process.

A phased approach allows for the deployment of individual Policies as they are developed, but calls for care that Policies are built and distributed in an order that makes sense.

Start the work by first determining what Policies the enterprise needs. Previously completed audits are a good guide as they highlight areas of weakness.

Group closely related Policies where the development of one links with the development of the others to gain economies of effort. Groups will be individual and enterprise specific.

Find natural relationships between groups so that the entire Policy can be laid out as “layers” in a framework. Layer structure also individual to each enterprise.

Build all the Policies in a individual “layer” at the same time. Once complete, roll them out before moving on to subsequent “layers”.

Policy frameworks Case Study;a complex sample based on a large set of Policies


Company ABC, a large multi-national, determined it needed a very complete ISO-based Policy. Development was projected at 12 plus months. Benefits were needed sooner.

Company ABC grouped those Policies specific to basic infrastructure and data security into layer 1 (the dark blue layer) and started work there. Building these Policies first put fundamental controls in place and gave management a sense of basic protection with only a couple of months of work effort.

Next they tackled Policies related to Account Management and Application Security (the mid-blue layer), as a natural connection between the basic l security they had built and personnel-focused security to come.

The user-related Polices (the red layer) became layer 3. These took time to get accepted, but the in-place controls were already providing solid protection.

The final components were tackled on an “as needs” basis over a period of months rather than as a specifically numbered layer.

Each box in this diagram represents a complete set of policies, standards, baselines/guidelines

and standards.

Policy frameworks,a simpler sample based on a reduced set of Policies


Framework design is individual to the enterprise and governed by factors such as corporate culture, staff ability and the number of Policies to be developed

Not all enterprises need as complex a framework as the previous example. Smaller Policy sets can use simpler frameworks. This represents a theoretical example.

As before layer 1 (dark blue layer) represents the Policy development start point and continues to include infrastructure and data security . It supplements these with core user management Policies to create a strong base.

The light blue mid-layer (layer 2) comes next and adds more user-focused Policies that will ensure user activity adds to, rather than detracts from, enterprise security.

Enterprises could finish with the assessment and response Policies as layer 3. These complete the set as a whole by allowing for ongoing verification of the security stance that the earlier Policies have created.

Each box in this diagram represents a complete set of policies, standards, baselines/guidelines

and standards.


Negotiate, not mandate, restrictiveness of Policy to ensure higher levels of acceptance and adoption

Determine Required Controls

Determine Required Controls

EstablishInitial

Stringency

EstablishInitial

Stringency

Review Interactively

with Business

Review Interactively

with Business

Publish Drafts, Solicit

Feedback

Publish Drafts, Solicit

FeedbackIT sets initial stringency such that its rationale can be provided in business terms.

This is a start point only; use it as the opening position but be prepared that it will change once business needs are understood.

IT and business units use workshop sessions to tailor the degree of constraint the policy represents.

Know going in which issues you can give on, and where you need to hold firm then practice give-and-take.

IT drafts policies based on agreed-to stringency, circulates for review, and incorporates feedback.

Maintaining business unit involvement eliminate the risk of error and disagreement at publication.Info-Tech Insight:

Policy is a living document – IT can work towards stronger policy over time.Remember; a weaker than ideal policy is better than no policy at all.

IT determines the areas where documented controls are needed by the enterprise.

Use the results of security audits to identify weak points in existing security controls. Standards such as PCI-DSS can guide as well.


Implement & Enforce

Implement with structureEnforcement leads to

success


Build the Policies

The first phases of policy implementation:obtaining acceptance and assessing impacts


Obtain Acceptance from ManagementManagement buy-in is key to policy acceptance; it indicates that policies are accurate, are to be upheld, that funds will be made available, and that all employees will be equally accountable.

Buy-in not just approval and funding, but also the championing of adoption - this says not just “we approve” but also “we will adhere”. Implementation must be seen to be top-down, not bottom-up.Assess Impacts of Policy DeploymentPolicy changes the way users and systems work; the magnitude of that change must be taken into account.

Balance the impact of policies on users as well as on security to determine which policies should be implemented first.

Focus on high security/low user impact Policies first to effect maximum change with minimal pain. Adopt low security/high user impact Policies last, when users knowledge is higher.

Policy impact matrix

“Policy is our most important security tool, but clean

implementation was vital.”- CIO of a regional telecom provider

Info-Tech’s Security Policy Implementation Tool will help establish an ordered ranking of Policy implementation


Info-Tech’s Security Policy Implementation Tool assesses the optimal order for Policy deployment.

Rank the factors that impact implementation, specify the policies to be implemented, and assign them to framework layers.

The tool indicates which Policies should be implemented first, and which can wait until later.

It provides ranking scores as well so that enterprises can see the net impact difference between Policies to tweak the order, if required.

Policy Implementation Guide Output Page

http://www.infotech.com/research/ss/security-policy-development-deployment/security-policy-implementation-tool?nav_id=2639

http://www.infotech.com/research/ss/security-policy-development-deployment/security-policy-implementation-tool?nav_id=2639

Minimize user impact to ensure that Policy implementation

is more successful


Make changes that improve security with no user impact

Get things moving and make quick security improvements with policies that don’t affect employees.

Train employees and record their acceptance of policies

Ensure users are ready for the capabilities to be introduced by educating before making changes that affect them.

Make final changes to existing systems and processes

Implement/adopt according to security & user impact; balance high security impact against low user impact where possible.

Implement net-new capabilitiesRemaining changes likely to have big impacts, but users will be familiar with and more accepting of processes by now.

“Getting the users trained on the policies early was the key to our successful rollout – the users knew what was coming and, most importantly, why.”

- CSO at a large retailer

Without enforcement, Policy just another piece of shelf-ware; tools are key to that process


Less than 4 in 10 recognize tools needed for Policy

enforcement

Process lays the enforcement foundation.Categorizing violations according to severity allows the enterprise to leverage more severe sanctions against more severe problems.

Clearly state sanctions that will be levied in the event of violation so there can be no doubt in the minds of employees.

Assign responsibility for verifying policy compliance to ensure consistent enforcement.Tools essential for measurement of policy compliance.Activity monitoring and logging the most basic tool required. Syslogs and other native tools provide this minimal capability but often not enough.

Dedicated user and system monitoring and management solutions may be required. These tools have configurable rules and automated reporting. Examples include IAM, SIM and GRC software.

n=114

Policy enforcement must be ubiquitously appliedor it will be undermined over time


It is essential that, unless exemptions are specifically written into the Policy, enforcement be applied equally to all users and all groups.

If differential enforcement of the Policy is allowed to exist, a “caste” system is created that becomes obvious . In time this undermines Policy acceptance and effectiveness.

Survey data shows that Policy enforcement is not leveraged against 60% of managers and 50% of IT staff. In comparison, only 30% of users escape sanctions when violating the Policy.

Users cannot be Policy scapegoats

“We are having a devil of a time getting Senior Management to

actually follow the security rules that they were part of creating. As a

result, our users are starting to grumble. If we can’t get this under control I’m concerned I’ll have a

revolution on my hands.”- Security Manager at a Mid-Size

Manufacturer

Summary


• Security Policies are hierarchical document sets that are shown to increase enterprise security. They include:– High-level goals that indicate intent.

– Prescriptive rules that direct behaviour.

– Specifications that provide compliance targets.

– Operational how-to’s to guide on-going activities.

• Building Policies not a task simply for IT – the business must be tightly involved so that the document meets their needs.

• When implementing, move slowly to ease acceptance – remember weak Policies that improve over time better than no Policies at all.

• Inconsistent enforcement is anathema to success – IT and Management cannot be immune to the rules.

Appendix IDescription of security policy documents


Info-Tech has created twenty standardized policy templates that clients can use to build their own policy documents:

• Security Infrastructure Policy• Systems Configuration Policy• Systems Maintenance Policy• Systems Change Control Policy• Systems Monitoring & Auditing Polic

y• Data Protection Policy• Media Protection Policy• Application Security Policy• Risk Assessment Policy• Security Assessment Policy

• Personnel Security Policy• Acceptable Usage Policy• Security Training Policy• Password Policy• Authorization, Identification

& Authentication Policy• Account Management Policy• Physical Access Policy• Incident Response Policy• Contingency Planning Policy• Secure Acquisitions Policy

Enterprises can pick and choose the policies they wish to use and customize each one to suit individual requirements.

http://www.infotech.com/research/security-infrastructure-policy-template

http://www.infotech.com/research/systems-configuration-policy-template

http://www.infotech.com/research/systems-maintenance-policy-template

http://www.infotech.com/research/systems-change-control-policy-template

http://www.infotech.com/research/systems-monitoring-and-auditing-policy-template

http://www.infotech.com/research/systems-monitoring-and-auditing-policy-template

http://www.infotech.com/research/data-protection-policy-template

http://www.infotech.com/research/media-protection-policy-template

http://www.infotech.com/research/application-security-policy-template

http://www.infotech.com/research/risk-assessment-policy-template

http://www.infotech.com/research/security-assessment-policy-template

http://www.infotech.com/research/personnel-security-policy-template

http://www.infotech.com/research/acceptable-usage-policy-template

http://www.infotech.com/research/security-awareness-training-policy-template

Appendix ISecurity Infrastructure Policy


Dedicated security infrastructure allows information systems to be provided a greater level of security than can be achieved through configuration control alone by delivering enhanced security capabilities.

Without dedicated infrastructure the potential exists that security vulnerabilities that cannot be mitigated by the capabilities inherent in information systems will be exploited leading to compromise of information system security.

Appendix ISystems Configuration Policy


Standardized configuration settings allow information systems to be consistently deployed in an efficient and secure manner.

Without standardized configuration settings the potential exists that information systems may be deployed that fail to meet security requirements , or that compromise the security requirements of other information systems with which they interconnect.

Appendix ISystems Maintenance Policy


Information system maintenance is required to ensure that information systems are always operating optimally.

Without systems maintenance the potential exists that information systems will be unable to provide appropriate information security.

Appendix ISystems Change Control Policy


Configuration change control involves the systematic proposal, justification, implementation, test/evaluation, review, and disposition of changes to information systems, including upgrades and modifications.

Without system change control the potential exists that changes could be made to the information system that, either intentionally or unintentionally, degrade the security of the information system, subjecting it to a greater degree of risk.

Appendix ISystems Monitoring & Auditing Policy


System monitoring and auditing is used to determine if inappropriate actions have occurred within an information system. System monitoring is used to look for these actions in real time while system auditing looks for them after the fact.

Without system monitoring and auditing it can be difficult to determine when a failure of the information system security, or a breach of the information systems itself, has occurred, and the details of that breach or failure.

Appendix IApplication Security Policy


Applications should be designed and implemented in as secure a manner as possible, using pre-defined application development principles and procedures.

Without secure application development, the potential exists that the application component of an information system could be constructed with flaws or other weaknesses that could allow for the subversion of the application and the contravening of other security controls.

Appendix IPersonnel Security Policy


Following defined protocols regarding staffing ensures that the users to whom it extends information system access will understand and treat that access with appropriate regard for information security.

Without these protocols the potential exists that information system users will have insufficient regard for the security of the information systems or information they use, increasing the risk the company is required to accept.

Appendix IAcceptable Usage Policy


Acceptable usage policies clearly indicate what information system users are and are not allowed to do.

Without these policies the potential exists that information system users could violate information security and avoid punitive actions by claiming to not know about any restrictions in place. This can make it extremely difficult to enforce the measures outlined in the policy and ultimately lead to a complete disregard of the policy.

Appendix ISecurity Training Policy


Security awareness training ensures that users of information systems understand the security implications of their actions and increases the likelihood that information system security will not be breached, either intentionally or unintentionally.

Without such training information system users have an increased likelihood of breaching security and have lower individual culpability should they breach security.

Appendix IAccount Management Policy


Information system accounts are the only legitimate method by which information systems may be accessed.

Without active account management, the potential exists that legitimate users can use these accounts for illegitimate purposes. Additionally, the potential exists that these accounts can be usurped and used illegitimately to access information systems.

Appendix IPassword Policy


Passwords are the primary form of user authentication used to grant access to information systems. To ensure that passwords provide as much security as possible they must be carefully created and used.

Without strict usage guidelines the potential exists that passwords will be created that are easy to break thus allowing easier illicit access to information systems, thereby compromising the security of those systems.

Appendix IAuthorization, Identification & Authentication

Policy


The use of authorization, identification and authentication controls ensures that only known users make use of information systems.

Without authorization, identification and authentication controls, the potential exists that information systems could be accessed illicitly and that the security of those information systems be compromised.

Appendix IData Protection Policy


Data protection mechanisms allow information to be provided a greater level of security than can be achieved with system based protection mechanisms alone.

Without data protection mechanisms the potential exists that information assets could be exposed to an unnecessarily high level of risk, particularly in circumstances where that information is taken out of the information system.

Appendix IMedia Protection Policy


Media protection mechanisms allow information to be provided a greater level of security than can be achieved with system based protection mechanisms alone.

Without media protection mechanisms the potential exists that information assets could be exposed to an unnecessarily high level of risk, particularly in circumstances where that information is taken out of the information system.

Appendix IPhysical Access Policy


Physical access controls define who is allowed physical access to facilities that house information systems, to the information systems within those facilities and/or the display mechanisms associated with those information systems.

Without physical access controls, the potential exists that information systems could be illegitimately physically accessed and the security of the information they house could be compromised.

Appendix IIncident Response Policy


Incident response capabilities are used to monitor for security incidents, determine the magnitude of the threat presented by these incidents, and to respond to these incidents.

Without an incident response capability the potential exists that, in the event that a security incident occurs, it will go unnoticed and the magnitude of harm associated with the incident will be significantly greater than if the incident were noted and corrected.

Appendix IContingency Planning Policy


Contingency plans are used to establish the manner in which information systems will continue to be operated in the event of a catastrophic failure to the information system or any of its components.

Without contingency plans the potential exists that, should some form of catastrophic failure occur, the company will be unprepared to recover from that failure and the unavailability of information systems will be extended.

Appendix ISecurity Acquisitions Policy


Following set protocols when acquiring information systems ensures that expenditures are made in as wise a manner as possible in regards to the provisioning of IT security.

Without such protocols, the potential exists that purchases could be made that undermine defined security requirements. Thus, the risk level could be increased and an additional purchase to re-establish an appropriate security level may be required.

Appendix IRisk Assessment Policy


Risk assessments are used to determine the likelihood and magnitude of harm that could come to an information system in the event of a security breach. This in turn determines how much of that risk should be mitigated and what controls should be used to achieve that mitigation.

Without risk assessments the potential exists that the organization can leverage inappropriate (either too strict or too lax) security controls to protect information systems.

Appendix ISecurity Assessment Policy


Security assessment is focused on determining the degree to which information system security controls are correctly implemented, operating as intended and producing the desired level of security.

Without Security and assessments, the potential exists that information systems may not be as secure as intended or desired.

Appendix IIMethodology


This solution set used data collected from a survey conducted in April 2010 on the topics of Security Policy development, deployment and enforcement. 117 responses were received.

Appendix IIMethodology


This solution set used data collected from a survey conducted in April 2010 on the topics of Security Policy development, deployment and enforcement. 117 responses were received.

Appendix IIIRelated Research


The following is a selection of the previously publish Info-Tech research related to the topic of Security Policy. For more coverage of this topic, please see the following:

– Policy Stringency Must Be Open to Discussion

– When Creating Policy, Use a Structured Approach

– Four Steps to Implementing a Security Policy

– Building Better Passwords

– Understanding Password Cracking the Key to Better Passwords

– Duty Segregation Mitigates Fraud

Technology

develop security policy