Distributing Information Security Policies

To be effective, information security policies need to be read and understood by every member of the organization. This seemingly simple requirement is now becoming a standard practice to reduce risk, comply with regulations and demonstrate due-diligence.  Why is this control so important and how can it be done in practice?

Regulatory Requirements

Every regulatory framework or information security standard has some variation of the following requirement:  “Validate that written information security policies are distributed to every member of the organization.”  (See the table below)

Many organizations are being exposed to information security for the first time via a regulatory requirement.  For example, a company that processes credit cards must comply with PCI-DSS.  A contractor to a Federal agency may be required to adopt FISMA.  In these cases, organizations are presented with an onerous checklist of items they must comply with.  Often, the reasons behind these requirements are vague or difficult to understand.

There are two fundamental reasons why organizations must distribute security policies and track acknowledgement.   The first is that written security policies define “rules of behavior” for the way in which users interact with data and systems.  Given the fact that most data breaches can be traced back to some form of human error – this seems to be a reasonable way to reduce risk.   If employees don’t understand how to use systems securely, it creates a dramatic increase in potential risk.  These “rules of behavior” are most commonly expressed as Acceptable Use Policies.

The second (and perhaps less appreciated) reason is to demonstrate due-diligence regarding information security.  Information security is not a prescriptive science.  In other words, organization are often encourages to adjust their information controls based on “the size and scope of the business” or “the results of a risk assessment.”  Variations of these statements show up in regulations like HIPAA/HiTECH and GLBA.  This essentially implies that organization can add or remove controls based on a risk assessment or other business justification.

This is fine until there is a data breach or other serious incident.  Once an incident happens, the organizations are quickly under scrutiny to determine if they were are fault.  (The issue of culpability and issuing fines is way beyond the scope of this article.  However, there is a consistent pattern.  If organizations are willfully negligent, the penalties and fines increase dramatically.)

Reducing Risk

[In the classic view of risk analysis, information security controls have two primary functions:  To reduce the “likelihood” that an event will happen and reduce the “impact” of an event that does happen.  In that context, requiring users to read policies fits both conditions.   Educating uses should help them reduce mistakes, and performing due-diligence is likely to reduce fines or criminal charges for negligence.]

Demonstrating Due Diligence

Requiring users to read and acknowledge security policies is simply one of the most effective ways to demonstrate due-diligence with regard to information security.   Despite the large and growing army of technical solutions, information security is still a people-oriented business.  And information security policies represent a key control point where security technology meets human behavior.

There have been numerous legal cases in which users were disciplined for not following corporate policy.  However, in those cases some employees argued effectively that they have never seen or understood the policy.

This seems like a reasonable idea.  But for organizations with hundreds or thousands of employees and contractors, this can present a huge challenge.  In fact, the process is not really feasible unless some of technology is used to automate the process.

Policy User Acknowledgement: Key Elements

So now that we understand that this is a good idea, how does an organization go about doing this in practice?  For organizations with hundreds or thousands of employees and contractors, this can present a huge challenge.  Our experience with hundreds of organizations can be distilled into two key requirements.

Security Policy Design

First, make sure that security policies are targeted at the right audience.    Some organizations still make the mistake of “co-mingling” technical and process policies with user-oriented policies.  In other words, most users need to understand Acceptable Use of computer and communication systems.  They to NOT need to know how a firewall is configured or how to document a system change.  Information security policies need to be organized by topic and targeted at the appropriate user groups.

Security Policy Automation

Second, use a policy automation tool to distribute policies to different users groups. In fact, the entire policy distribution process is not really feasible unless some of technology is used to automate the process. Security policy automation or management tools provide the following key functions:

1. Enable a documented workflow for creating, reviewing and approving policy documents;

2. Enable targeting of specific users and groups based on their job functions;

3. Require formal acknowledgement of the written policy document;

4. Provide reports that document progress across the organization.

Every policy management tool must have some variation of these key requirements.   This has now become a required feature in Governance Risk and Compliance (GRC) tools. In 1998, there was only one commercial tool available to help automate policy management.  Today, there are dozens.  Information Shield has chosen to partner with Policy Hub because we believe it has the strongest set of functions available in the market when it comes to “pure” policy management.

Of course, commercial tools are not required.  Organization can develop their own systems using custom code, MS-Sharepoint or even a combination of email with logging software.   In general, though, unless these systems are already in place within the enterprise, it can be difficult to justify development when so many robust commercial tools are now available.

_____________________________________________________________________________

Information Security Policy Requirements of various compliance frameworks

ISO 27002: Section 5.1.1 “A set of policies for information security should be defined, approved by management, published and communicated to employees and relevant external parties.

“These policies should be communicated to employees and relevant external parties in a form that is relevant, accessible and understandable to the intended reader, e.g. in the context of an “information securi y awareness, education and training programme” (see 7.2.2).”

PCI-DSS 3.0:  12.1 Establish, publish, maintain, and disseminate a security policy.

Examination Procedures: 12.1 – Examine the information security policy and verify that the policy is published and disseminated to all relevant personnel (including vendors and business partners).

Gramm-Leach-Bliley Act (GLBA) Title V – Section 501 –  “Each Bank shall implement a comprehensive written information security program [policies] that includes administrative, technical and physical safeguards.”

NIST SP 800-53: AC-1 Control:  The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles] … An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;