Ask 10 security professionals the above question and you’ll get 12 different answers. Each of those answers is right for some organization but what is right for you, for your organization is dependant on how much risk you are willing to carry. The right amount of protection will balance the amount of Risk your organization is willing to carry, and that is an answer that has to come from within your organization, and from the management team, not the IT, Operations, or Security teams.
By instituting Risk Management policies you will have an evolving and comprehensive analysis of the strengths and weaknesses of your organizations security posture and where your vulnerabilities are in the current threat landscape. With a Risk Management Program, you can instead ask “What protection do I need to protect these systems from those threats?” which will have much more consistent answers.
A Risk Management program, while influencing and ultimately implemented by Information Technology, is in fact a management policy. As a policy it is prudent to define the program in terms of objectives, strategy, and objectives and refrain from requiring specific technologies, methodologies or implementations. By divesting objective from implementation you will create a much more flexible program that is able to quickly adapt to emerging technologies and threats. After all, it will almost always be faster to roll out a new technology than change a business policy AND roll out a new technology.
The Executive Summary exists so that readers can, at a glance, determine if and why the policies applies in a given situation. It should be concise and cover three main points. Why the program is required, what organizational units are subject to the program, and what the desired outcomes from a successful program should be. These three points are generally referred to as the Purpose, Scope and Key Goals.
As previously stated the Risk Management Program is foremost a matter of policy over implementation, as such a successful Risk Management Program needs to be driven by leadership. The Policy should outline specific roles and responsibilities for: the creation and maintenance of the policies, implementation, and periodic review of the program. At this level specific procedures should be referred at a high level and as external documents to maintain the separation between policy and implementation and, just like with specific technology, to preserve as much flexibility for updating and improving procedures.
After defining “Why” and “Who” the next section of the Risk Management Policy should define “What” is to be protected from “Which” threats. These questions are sometimes referred to as an Asset and Threat inventories. Your asset inventory can include hardware, software, processes even personnel that is critical to the successful operation of the organization. As above the specifics of this list should exist in separate documents, the policy should define the purpose for, scope of, and required information within each of these inventories.
With the asset and threat inventories defined above you will need to conduct periodic Risk analysis. This is not a one-time task, and the execution of the Risk analysis will be result in documents external to the Risk management Policy. Within the Policy you should clearly articulate the frequency of these analyses as well as a consistent analysis framework.
Furthermore you will want to establish procedures for periodic proactive assessment of your security posture for continuous improvement, and to discover potential vulnerabilities before they are exploited.
Which specific Threats need mitigation strategies is likely going to be a natural byproduct of both the above risk analysis and any applicable regulatory requirements (PCI-DSS, GDPR etc) at a minimum you will probably want to include a requirement for the organization to maintain up-to-date strategies for the following:
Moreso than any other document that results from the Risk Management Program, an Incident Response Plan (IRP) should be continuously updated. In addition to the periodic review and update there should be a Post Mortem after each incident where the IRP is updated with lessons learned. The IRP is not a single document; therere should be a general IRP, as well as a specific IRP for each threat that scored high in the risk assessment. There should also be a requirement to create an IRP for any new threats as part of the Incident Post Mortem.
Effective IT Security is not a set-it-and-forget-it proposition. The threat landscape is continuously evolving and continuous monitoring and early detection are key components to maintaining a strong security posture. The Risk Management Policy should outline the purpose for, minimum requirement of, and expected results of your organizations monitoring and detection efforts. Typically this will include:
When defining key performance metrics try to focus on metrics within your control, and that promote the positive improvement you want to see. For example: while “Number of Attacks” is a tempting metric, it is both outside of your control (therefore not a measure of anything you are doing) and encourages under reporting incidents.
Employee Training is a critical aspect of any security policy, and this is never more true than at leadership positions. Consequently the requirement for Training and Security Awareness at all levels of the organization (not just within IT) is a critical component of the Risk Management Program.
While specific regulatory compliances are usually mentioned in the Executive summary they need to be a constant consideration for each subsequent section, and each subsequent document that comprises the Risk Management Policy. Furthermore an key, and often overlooked, aspect of this is maintaining a program to evaluate and mitigate any risks associated with using third party service, and ensuring that any third party processors remain compliant.
While it is no small undertaking, a robust Risk Management Program will produce results that far exceed the efforts it takes to implement and maintain.