Security Policies – Stamper

Many CISOs may feel that our titles don’t reflect what we actually do on a daily basis. It may seem that we are actually the CPO (Chief Policy Officer) of the organization and not the CISO. Our days are filled with writing, reviewing, and updating policies rather than deploying next-generation security tools, the fun stuff. Indeed, it can seem that there is no end to the number of new policies that we need to draft and disseminate within the organization. Too many policies, however, results in policy overload and policy fatigue among our colleagues. Too few policies and the commensurate gap in procedures and practices could lead to operational blind spots that put our organizations at risk. There has to be a reasonable balance to ensure that the objectives of the policies, procedures, and practices are addressed without generating security apathy among our colleagues.

Just as important as the right balance and number of policies is how they should be enforced. A policy that is shelfware only should never be written. Policies should be operationally translated into documented procedures and practices – to wit, the notion of P-cubed (policy, procedure, and practice). Policies without the associated guidance on the procedures and practices are incomplete. It’s easy to say that we should employ a least privilege methodology, that critical data should be encrypted, that we should have strong passwords, and on and on. However, without specific guidance on how these end states are achieved, there is too much room for ambiguity. Procedural guidance should indicate how the practices should be performed, how review and approval of activities are conducted and evidenced, as well as the documentation and systems used to complete a given procedure. Although often maligned as stifling and/or trivial, checklists can help validate that routine practices are accurately and completely addressed.

Structure Counts: Consistent Policy Design

One reason why so many policies are ineffective is that the actual structure of the policy has never been standardized within the organization. The consequence of this is that policies are incomplete and omit key elements required for their successful implementation, notably management authorization and employee acknowledgment. A well-structured policy should at a minimum include the following core elements:

  • Policy ownership – in the context of a RACI matrix, a policy requires someone to be accountable for the policy’s required procedures and practices. This individual or role should be noted as the policy’s owner.
  • Review and approval – policies should be reviewed and approved by executive management. This authorization should be formalized and include those executives that are impacted by the policy’s scope. Stated differently, policies should capture the review, approval, and formal authorization of executives beyond traditional IT roles such as the CIO or CISO.
  • Employee acknowledgment and sanctions – for policies to be effective, they need to be read and acknowledged by employees and, in many cases, independent contractors and vendors. A policy should include a formal acknowledgment section where employees confirm that they have read the policy and understand that failure to comply with the policy, unless duly authorized by management (and this would be an exception), could lead to disciplinary action up to and including employee dismissal. Ideally, once the policy has been signed by employees, these acknowledgment forms should be kept by human resources and maintained in each employee’s HR file.
  • Effective date – policies should have a clearly stated effective date. This formally conveys that the policy is in force and is part of the organization’s overall governance practices.
  • Review date – policies should be subject to review. Ideally, policies should be subject to an annual review where there may be updates to procedures and practices, scope, or policy ownership. Language indicating that the policy may be reviewed and updated from time to time-based on changes to the organization, technology, or other changes should be incorporated to offer flexibility.
  • Version – policies should be version controlled. The versions should be changed following each annual review (or during an interim review if required).
  • Scope – policies should have a defined scope or boundary for their required procedures and practices. The policy’s scope will define where applicability to required procedures starts and ends within the organization. As a case in point, there may be a policy to require encryption of data in transit and at rest. The scope of the policy would specify which types of information should be encrypted (e.g. PII or ePHI).
  • Procedures and practices – Policies should reference the specific procedures and practices required to ensure that the policy objectives are being met. Good procedural documentation leaves little space for ambiguity. Procedures should include a basic RACI (RASCI for those so inclined) to note who is Responsible (the individuals or departments doing the actual work), Accountable (the specific role or individual that effectively owns the result of the procedure), Consulted (individuals with expertise and knowledge of a given domain that can help validate and inform procedures and practices), and Informed (those departments, individuals, clients, regulators, boards, etc. that should know about the existence of procedures and the outcomes of its activities). Procedural documentation should also capture the system(s) of record used to carry out the activities, the types of documentation created relating to the procedure, and where this documentation is stored. Validation and verification activities should also be clearly captured and understood. The documentation related to procedures and practices should operate with a basic premise to “declare war on ambiguity.” There should be no doubt what’s required, who is doing the work, and how it is measured and validated.

Collectively, these elements become requisite constituent parts of a well-structured policy. Clearly, there is also the actual content of the policy delineating the specific outcomes desired by the policy’s enforcement.

Ch9-2 New-01a

While the number of topics that could be incorporated into a security policy seems limitless, there are some important minimum necessary topics or domains that should be found in every security policy. It’s important to note that these could be addressed in a single document or across several distinct documents that cross-reference other policy domains.

Key Policy Elements

Here are some of the key…

Copyright © 2016, 2018 CISO DRG JV – All Rights Reserved.