Analytics
2/4/2013
06:42 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Tech Insight: How To Build An IT Security Budget

For most security professionals, building a budget is unfamiliar territory. Here are a few tips to help you navigate

[Nicholas Takacs is engineering manager at PenTeleData. His content is contributed through the auspices of the (ISC)2 Executive Writers Bureau.]

Part 1 of a two-part series

There is nothing more anxiety-inducing to an information security department than the preparation, presentation, and approval of its annual budget. This process can create unnecessary tension, stress, and other negative feelings between the security team and company executives, who may balk at allocating money to projects to protect against potential intrusion.

Even with the best statistical data, risk assessments, and real-world testimonials, it can be difficult for security pros to build a budget that conveys their needs in a way that top executives can relate to and understand. In Part 1 of this series, we are going to look at how to pull the numbers together. In Part 2, we'll discuss how to present them to management.

Like any other IT function, building a budget involves three core components: people, process, and technology. The first step in budget development is to select or develop a framework to guide the selection of new investments (or reinvestments). You can use another company's budget as your template -- tailoring it to your specific company needs -- or you can initiate an internal effort to build one from scratch.

A proper budget framework is much like a project management methodology. That is, it defines the steps/stages necessary to move from concept (the need for a budget) to production (a final, approved budget). The nice part about this framework is that it usually doesn't require a large approval process, and it can be kept mainly for your own departmental use.

After selecting a framework, your next step -- as with any IT project -- is requirements-gathering. The goal of this step is to determine what types of new or updated security controls -- whether processes, technologies, or educational programs -- that the company may need.

Soliciting requirements feedback from executives, midlevel management, and even rank-and-file workers can yield valuable information about operational risks that may otherwise be obscured as data moves up the management ladder. Requirements feedback may include strategic business challenges, regulatory or compliance risks, data or systems incidents, or any other external factor that drives a need for security spend. Most importantly, ask your CIO or other group executive for a budget target, which gives you the baseline target to achieve.

While some requirements feedback may not fit neatly into the budget framework, the information gained through this process may help give you the justification you need during the review and approval process. Even if you don't use all of the data in your final budget, don't discard it --keep track of it under separate cover (this is sometimes called a requirements "parking lot").

Once you have your list of requirements and concerns, the focus then turns toward the specific security needs of the organization. This should break up into three distinct categories: needs, wants, and nice-to-haves.

Needs are processes or technologies required to maintain or improve a critically deficient area in the organization's security posture, such as firewall updates, a new intrusion detection system, or certification training for security staff to maintain competencies.

Wants are processes or technologies that would provide a beneficial benefit, but are not mandated by control requirements within the organization, such as an SSL VPN upgrade from IPSec, a new security workflow system, or updated security awareness materials.

Nice-to-haves are processes and technologies that would enhance existing security controls or programs, but do not necessarily provide a major benefit. They may give a "feel good" sense of security or positive public relations for the department, such as security program trinkets or bleeding-edge technology research.

To determine how to categorize your requirements, consider how each of these items reduces organizational risk and impact, any alternatives that may exist at a lower cost, and the risk of simply not having them.

Once this categorization is complete, map each of your needs to the existing budget framework, followed by the wants, and then the nice-to-haves. Cost considerations should not be barriers during this initial mapping process, but you should develop a rough cost "order of magnitude" for each item.

Armed with a list of items, orders of magnitude, and a framework to organize it all, you should be ready to build your preliminary budget. List each of the categories, with estimated costs.

Don't forget to include the costs of personnel, implementation, and post-installation support when arriving at an estimated cost for each item. Depending on the specific organizational requirements, you may want to split the costs between capital expenditures, operational expenditures, and expenses. And because you are dealing with security issues, your budget should also address the risk of not doing a particular item.

Once you have arrived at a total cost, compare it with the baseline number you got from your group executive during requirements to refine your figures and develop an over/under target.

Congratulations! You now have a rough draft for an information security budget. If your budget total is higher than the baseline number that you received from your group executive, then begin a careful review of nice-to-haves, followed by wants, if necessary. Consider each item and lower-cost alternates, and eliminate items until you reach the target.

If your budget total is less than the figure that your group executive gave you, then consider additional items that you may have overlooked. While it might seem good to be under the baseline, it's better to hit the baseline on the initial proposal, leaving you some room to reduce your figures later in the approval process.

The preliminary budget deliverable that you give to management should include a few key sections. First, give a high-level overview describing the strategy and framework used. Then provide financial breakdowns that divide costs into capital expenditures, operating costs, expenses, etc., as required by your financial department. Finally, you may also need to include departmental breakdowns of any costs that will be charged back to specific business lines.

After you've completed these steps, your budget is now ready for the review and approval process. In Part 2 of this series, we'll look at methods for achieving executive buy-in and getting as many security dollars as possible.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Landoll
50%
50%
Landoll,
User Rank: Apprentice
2/4/2013 | 4:15:54 PM
re: Tech Insight: How To Build An IT Security Budget
Where is the risk assessment? The most important part of this entire process is determining the risks to the organizations sensitive data and critical systems. You address this cornerstone step as "Soliciting requirements feedback from executives..."[survey/interview] and "consider how each of these items reduces organizational risk and impact...and the risk of simply not having them" [intuition-based, desktop risk assessment].-

This surface approach to security risk assessment is a major mis-step at the beginning of an important process and will lead to faulty conclusions. You have a good process after this step but with a light (inaccurate) security risk assessment this process devolves into a GIGO process.
Register for Dark Reading Newsletters
White Papers
Cartoon
Latest Comment: LOL.
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6212
Published: 2014-04-19
Unspecified vulnerability in HP Database and Middleware Automation 10.0, 10.01, 10.10, and 10.20 before 10.20.100 allows remote authenticated users to obtain sensitive information via unknown vectors.

CVE-2013-6213
Published: 2014-04-19
Unspecified vulnerability in Virtual User Generator in HP LoadRunner before 11.52 Patch 1 allows remote attackers to execute arbitrary code via unknown vectors, aka ZDI-CAN-1833.

CVE-2013-6214
Published: 2014-04-19
Unspecified vulnerability in the Integration Service in HP Universal Configuration Management Database 9.05, 10.01, and 10.10 allows remote authenticated users to obtain sensitive information via unknown vectors, aka ZDI-CAN-2042.

CVE-2013-6215
Published: 2014-04-19
Unspecified vulnerability in the Integration Service in HP Universal Configuration Management Database 10.01 and 10.10 allows remote authenticated users to execute arbitrary code via unknown vectors, aka ZDI-CAN-1977.

CVE-2013-6218
Published: 2014-04-19
Unspecified vulnerability in HP Network Node Manager i (NNMi) 9.0x, 9.1x, and 9.2x allows remote attackers to execute arbitrary code via unknown vectors.

Best of the Web