Recently I described a process that I use with customers to help them make decisions about where to spend their money allocated to information security. That post explained how to identify projects, but it didn’t address how to prioritize those projects. After all, we always get budgets that allow us to accomplish everything we believe needs to get done, right?
Yeah… back to the real world. How one should prioritize spending falls in to that class of answers called “it depends.” Which isn’t very satisfying. So I’ll share a few tips that will help you navigate the nuances of “it depends.”
Remind Me…..
To briefly summarize, the best way to develop a security plan is to evaluate your needs in each phase of the information security management process:
- Plan: defining security policies and communicating them
- Implement: documenting and configuring the security of your systems, networks, manual processes, and physical security, to accurately and cost efficiently enforce your security policies
- Execute: monitoring your configuration for unapproved changes and system security events for indications of potential attacks
- Measure and feedback: Periodically comparing your configuration to your security policies to ensure that the implementation accurately reflects your policies and that your implementation is as cost-effective as possible given new attacks and new counter-attack technologies and feeding those results back into the process.
OK, What’s Next?
Once you have a list of security projects that need to be addressed, prioritizing them depends on a number of items. These include the size of your budget, the cost of the projects, the phase of the security management process in which the various projects fall, and high-priority corporate tactical requirements.
I use one hard and fast rule and a few “rules-of-thumb” when I work with customers attempting to prioritize their spending.
Hard and Fast Rule
Projects that address the highest risk(s) to the organization are assigned the highest priority.
Regardless of where the project falls in the security management process, the higher the risk addressed by that project, the higher its priority in your budgeting process.
Just because a project addresses a known risk, however, doesn’t mean it should automatically be prioritized higher than projects that address reducing the cost of managing security. Spending too much money on day-to-day security management is a business risk, too.
TIP: Be sure to factor in the “risk” of spending too much time on repetitive security tasks. Ask yourself if some tasks can be automated. What other risks could you address with the time you save?
For example, your employees must change passwords for their user profiles every 90 days. You have one project to design and implement a process for changing passwords associated with “service user profiles” just as often. Not changing these passwords is a known risk. The risk is as high as the risk of not changing employee passwords several times a year.
On the other hand, you also have a project to implement integrated authentication between Windows domains and your server platform (IBM i, AIX, Linux, etc.) The latter can help you reduce the cost of maintaining passwords, including calls to the help desk related to resetting passwords, etc.
One can rationally argue that the authentication project is higher priority because it saves a large amount of money — far more than the cost of implementing the project.
Compare that to the service user profile password change project which has higher costs relative to the return. Why? Because:
- It requires designing and implementing a process involving operations and development and code changes.
- Management probably perceives the risk as being relatively small.
- Finally, because the authentication project’s cost is small in terms of time and money, you will be able to address more security projects than you could if the service user profile password project was prioritized.
In effect, management could see the high internal cost of password management and authentication as a greater risk to the bottom line than not changing service user profile passwords on a regular basis.
This example also illustrates another attribute of security project prioritization: different organizations can and often do arrive at different prioritizations of the same projects. Therefore, I have a corollary to the hard and fast rule:
There is no absolute right and wrong prioritization
of security projects!
Rule of Thumb 1
The earlier in the information security management process a project falls, the higher the priority of that project.
This rule arises directly from the fact that information security management is a business — not a technical — process. Its implementation and execution do involve technical aspects, but it is first and foremost a strategy used to make your business successful.
Every business process starts with planning: defining what you intend to accomplish. If you don’t do this, then there is no way to tell if you have accomplished what you needed and wanted.
Therefore, if you haven’t formally defined (and communicated) your security policies, there is no way to determine if your implementation accurately (and cost efficiently) enforce the behaviors that are required to secure your information assets. Similarly, if you haven’t documented the security configurations of your systems that are required to enforce your security policies, there is no way to monitor if or when those configurations are changed without management approval. And so on…
Therefore, in the absence of any other criteria, projects that fall earlier in the information security management process have a higher priority.
Rule of Thumb 2
A project related to fixing a known deficiency in your security implementation (usually found in the execution or feedback phase) is higher priority.
This rule relates to identified exploits in software, for example.
Exploits found in commonly-used software — whether published by an external source or discovered internally — must be addressed quickly. Commonly-used software has a bigger attack surface because attackers have more chances to learn about security issues. They can learn how to attack you successfully by first attacking another organization. The less access time they require, the more likely they will succeed without you noticing at the time of attack.
Exploits for home-grown software will not be published externally, but security flaws still need to be addressed as soon as they are found. There is a tendency to feel more comfortable about home-grown software because of the “security by obscurity” myth. However, if you discovered the flaw, attackers can, too.
Rule of Thumb 3
Corporate mandates – passing a PCI audit, for example – are typically assigned a higher priority.
This rule is really straight-forward. A paraphrase is “If the boss says do it and do it now, then you do it now.”
PCI compliance is a good example of something the organization must do or face steep penalties — or forego credit card transactions, which will likely result in loss of business. High priority!
But there are other scenarios as well. For example, an external security audit may identify certain deficiencies that you classify as medium or low risk, but the boss thinks otherwise. The priority of that project just got boosted.
Summary
Every organization is different and has a different risk profile — even if they are in the same industry. Therefore, there is no single “right” way to prioritize your security spending.
Addressing the issues that represent the greatest risk is an obviously good place to start, but that doesn’t always mean lower risk items shouldn’t be addressed until the highest risk item is fixed. There are always competing priorities. Those priorities are likely to be very different from organization to organization.
These rules of thumb will provide a framework for you to evaluate the variables when deciding where to prioritize your scarce security resources.
