Prioritizing Security Projects: A Closer Look

Mar 21, 2005 3:45 PM, Nalneesh Gaur & Kevin Faulkner

Here’s more information about the following article — a longer version of the text and an accompanying Excel spreadsheet.
Spreadsheet

A longer version of the article

Security projects are no longer tied only to best practices. Regulatory and compliance issues — such as Sarbanes-Oxley and HIPAA — make some security projects necessary to resolve audit and regulatory issues. The projects are deemed non-discretionary. However, it is impossible to address all the other, non-discretionary projects at the same time.

So how can security projects be prioritized when resources are limited? Companies faced with limited budget, people and time — but keen on security — must somehow decide which security projects get preference. This article presents a framework for evaluating these types of security projects. Developed in the context of information security, these evaluation tools are also applicable to physical security.

Organizations tend to take one of three positions at the end of a security audit:

• accept findings and work on remediation;

• dispute findings and generate response; or

• deny the existence of findings.

It is not uncommon to see a combination of all three responses at the end of an audit. Organizations that take audits and regulations seriously and strive to remediate findings rather than denying their existence will be faced with a list of short-term and long-term projects to be implemented.

Most organizations face budget and resource restraints, but expending the effort to remedy audit findings must often be viewed as a necessary evil. This is where the Security Projects Decision Framework (SPDF) comes into play. The SPDF assigns three dimensions to each project — rationale, exposure and cost. Each project is measured by assigning values to the various aspects of each project dimension, as explained below.

The value of a project is determined in response to the question “Why do the project?” The emphasis of this dimension is on the value delivered by the project. The scoring process looks at three aspects of where a project delivers value:

• achieving regulatory compliance;
• addressing an audit finding; and
• other benefits besides security.

Two types of scoring approaches can be used here:

A weight is assigned to each aspect. For example, regulatory compliance and audit findings may be weighted more heavily than non-security benefits. A total score is calculated as a sum that reflects the benefits and their weights.

A scale is developed for each aspect depending on the importance of the aspect to the organization. Next each project is ranked within the respective aspect scale, and subsequently all scores are added up to arrive at the Project Quantitative Score (PQS). For example:

• regulatory compliance scale: 1-10;
• audit scale: 1-6;
• other benefits: 1-3.

There is no set maximum PQS when using the “Weights and Counts” approach. However, the maximum PQS is limited when using the “Aspect Scale” approach. Using our example scale, the maximum dimension score cannot exceed 19 (10+6+3).

Helping to answer the question “What if the project is not done?”, a qualitative score is assigned to each project based on risk. The exposure assessment looks at four aspects of a project:

• risk of internal breach;
• risk of external breach;
• political risk; and
• financial risk.

The risk of not doing a project is assigned to each aspect. A qualitative scale is used to assign values to each aspect of the dimension. A 1-5 scale can be used or, for simplicity, a three-value scale such as high (3), medium (2), and low (1) can be considered. Cumulative values are calculated to arrive at the Risk Exposure Index - REI (an arbitrary term used to aggregate risks).

Ultimately, cost is generally a heavily weighted component in the decision-making process. Project costs are assessed in terms of implementation effort and operational costs. Detailed cost estimates are not necessary at this stage, and order-of-magnitude estimates can be prepared to estimate vendor and internal resource costs.

Two types of costs should be considered here: initial costs and operational costs. Initial costs include the cost of hardware, software and implementation effort (i.e., workdays or hours). Upgrade costs should be included where applicable. The operational costs should include maintenance contracts, service fees, subscription costs and the estimate of any personnel costs.

A spreadsheet-based tool can be used to visualize the dimensions. This tool is used to perform if-then type analysis, and to assess the cost and impact of selecting one set of projects vs. another. Such a tool is described in more detail — and the Excel spreadsheet is available — at the magazine's Web site at securitysolutions.com

The Security Projects Decision Framework does not directly address project risks such as delays in execution or loss of a critical resource. These would have to be factored in by means of elements such as contingency costs in the cost dimension. The tool is standalone in nature, in the sense that it does not factor in other ongoing security or non-security projects that may be dependent on a shared resource pool. Such impacts can again be addressed by modifying the exposure and cost dimensions. The spreadsheet tool also assumes a constant hourly rate to compute implementation costs. This is because a blended (or average) rate was used to simplify the implementation cost estimates. Finally, it is important to note that project findings themselves are a result of interpretations by the auditors. It is better to question and resolve the findings right after the audit rather than during the Security Projects Decision Framework analysis process.

The SPDF provides decision-makers with metrics that can be used to prioritize projects and allocate resources. The whole process of plugging in the values should preferably be done in a collaborative manner with the involvement of the decision-makers and stakeholders.

Nalneesh Gaur, CISSP, ISAAP, is a manager with Accenture's security specialty practice. He consults with clients in the area of security strategy, architecture and risk assessment. Kevin Faulkner is a director of business systems with HSBC Technology Services, San Diego.

Want to use this article? Click here for options!
© 2008 Penton Media Inc.

This month in Access Control

• Targeting The Customer
• Electronic Pedigrees
• One Hero Among Many
• Who? What? When? Where? Why?
• More from September's issue