Practical IT Research that Drives Measurable Results Develop & Deploy a Security Policy

Introduction 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.

Policy Implementation and Enforcement Establish a Baseline The value of PolicyWhat 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 iceberg when 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 in how 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

Policy Implementation and Enforcement Establish a Baseline of Understanding Build the Policies Follow a framework during document creation Negotiate stringency with 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”. Determine required Policies Determine number of framework layers Assign Policies to framework layersDevelop and distribute Policies

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.

Info-Tech Helps Professionals To: Sign up for free trial membership to get practical Solutions for your IT challenges “Info-Tech helps me to be proactive instead of reactive - a cardinal rule in stable and leading edge IT environment.” - ARCS Commercial Mortgage Co., LP