Introduction
In our last chapter, we review one of the core topics that all security and risk mitigation operations revolve around – the organization’s cybersecurity program policies. Policies are the foundation for a security program. They explain the requirements for specific processes, including who has the responsibility for process execution, and specify the resources required for mature operations. For many organizations, not having the correct policies in place can significantly impact its ability to defend itself against cyber criminals and can degrade the ability to recover from a cyber incident. It is the responsibility of the CISO and executive management to have the correct policies in place, ensure the organization follows the policies, and periodically update them as the business/technology environment changes.
In this chapter, we will provide insight into the recommended policies an organization should have in its portfolio and describe in detail the components of a corporate information security policy. The authors approach this subject from different viewpoints, and you can rightfully assume that their wealth of experience on this subject demonstrates the importance of security policy for the CISO.
Bill provides his viewpoint that information security policies are foundational to an organization. He discusses the relationship between policy, standards, guidelines, and procedures. Throughout, he notes how important it is to maintain the connection between business objectives and the organization’s policies. Finally, Bill asserts that “policy has a purpose,” that it is written for action, and he elaborates on the principles and steps for establishing an effective cybersecurity policy.
Matt states that CISOs use security policies to be effective in fulfilling the requirements of their position. He discusses the balance between creating a policy that has a specific objective, and that is actually used in the organization. Matt then articulates the core elements of a well-structured policy and provides recommendations for specific policies that he deems crucial for an organization and its cybersecurity/risk management programs.
Gary provides insight into the essential components of an organization’s information security policy. He then walks the reader through a step-by-step process for creating an incident response policy and describes how an organization should use it. He concludes his discussion by providing a list of recommended policies that a CISO should build and use to address the risks facing their organization. He makes the case that through the use of these policies and resulting work practices, the CISO can enable the organization to be more resilient to the risks it faces.
Some of the questions the authors used to frame their thoughts for this chapter include:
♦ In building the organization’s information security policy, what components should the CISO consider essential?
♦ Does the organization have a formal, documented incident response policy and plan? If not, what best practices does the CISO need to consider to create them for the organization?
♦ In developing a mature cybersecurity program, what recommended policies should the CISO develop to increase his/her security program’s effectiveness?
Security Policies – Stamper
Many CISOs may feel that our titles don’t reflect what we do on a daily basis. It may seem that we are 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. Having too many policies results in policy overload and policy fatigue among our colleagues. If we have too few, 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 we address the objectives of the policies, procedures, and practices without generating security apathy among our colleagues.
Just as significant as the right balance and number of policies is how we enforce them. We should not write policies that will only be shelfware. We should operationally translate policies 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, we should encrypt critical data, that we should have strong passwords, and on and on. However, without specific guidance on how we achieve these end states, there is too much room for ambiguity. As I noted earlier in this book, “Declare War on Ambiguity!” Procedural guidance should indicate how to perform the practices, how to conduct and show evidence of review and approval activities, as well as the documentation and systems used to complete a given procedure.
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 critical 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 procedures and practices needed for the policy’s compliance. Note this individual or role 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 who are impacted by the policy’s scope, including the formal approval of executives beyond traditional IT roles such asthe CIO or CISO.
♦ Employee acknowledgement and sanctions – For policies to be effective, they need to be read and acknowledged by employees and, in many cases, independent contractorsand 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 employees have signed the policy, 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 version number should change 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 determine where applicability to needed 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., PIIor ePHI).
♦ Procedures and practices – Policies should reference the specific procedures and practices required to ensure that the organization is meeting the policy objectives. Proper procedural documentation leaves little space for ambiguity. 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. There should be no doubt what’s required, who is doing the work, and how it is measured and validated.
Procedures should include a basic RACI. This should 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)
♦ Informed (those departments, individuals, clients, regulators, boards, etc. that should know about the existence of a procedure and the outcomes of its activities).
Collectively, these elements are necessary constituent parts of a well-structured policy.
