#budgeting – 370 Security Blog

Annual Planning For CISOs

The beginning of the year is a popular time for making personal resolutions, which can focus on health, finance or love. While the beginning of the year is a popular time to set resolutions, really what we are talking about is setting goals to improve ourselves. I’m a huge proponent of setting personal goals for the year because it gives focus and purpose to your actions. The beginning of the year is also a great time to review the annual goals of your security program to set your focus and establish priorities. Annual planning has several objectives that CISOs need to consider and include in their process and I’ll cover them in the rest of this post.

Strategic Planning (Strat Planning)

Strategic, or “strat” planning as it is sometimes called, looks at where the business and your organization want to be over a long term time period. Something like 18 months to 5 years is typical in strat planning. The planning session should include discussion of the one or more of the following macro level business topics:

Market forces and opportunities
Industry trends
Regulatory and legal landscape
Competition
Customer sentiment, goals, etc.
Economic and financial environment
Geo-political climate
Technology trends and latest research

This discussion could be part of a SWOT analysis (Strengths, Weaknesses, Opportunities, Threats), but the goal is to understand where your business is and where you want it to go in the long term.

Align The Security Program

Once the business has a strategic plan, the CISO should conduct a similar planning exercise for where they want the security program to be. These are sometimes called “North Stars”, but they are essentially high level objectives over the long term that merge technology trends, regulatory requirements and security goals into long term objective. These won’t be very specific, but instead should act as guidance for where your team should focus and hopefully end up over the next few years.

Examples

An example of a strategic trend and security objective are as follows:

Trend: As companies shift from the datacenter to the cloud and bring your own device (BYOD), the concept of a traditional perimeter no longer makes sense.

Strategic Security Objective: Shift to a zero trust strategy where identity becomes the perimeter.

The goal is to choose big ticket objectives that will take multiple years to achieve, but will provide guidance to your org and the rest of the business about the direction your team is taking. Your strategic plan will inform the next section, which is your operational plan.

Operational Planning (Op Planning)

Operational planning is more tactical in nature and covers a shorter time period than strategic planning. Op planning usually follows either a fiscal or calendar year that way it aligns to performance reviews and budgeting cycles. In op planning the CISO will select the high level goals they want the security organization to complete that year. Usually op planning will include discussion and planning of the following:

Budget creation, forecasting and changes
Headcount planning
Technology investments (if any)
Top risks to focus on
Any audits or compliance certifications needed that year
Development of timing and roadmap for completing specific projects and tasks
Discussion of security controls and services
Skill gaps and training requirements

The point is to create a tactical plan for the year that will inform your team’s specific goals and objectives. These goals should be clear and measurable. I typically use an iterative approach to break my goals down to my directs and then they break their goals down to their teams and so on. This ensures alignment throughout the business.

Measuring and Adjusting

One important aspect of any plan is to continually measure progress and adjust if needed. Goals and objectives aren’t useful if the business has shifted and they are no longer relevant or have become un-obtainable.

Wrapping Up

Strategic and operational planning are important activities for every CISO. These plans define the long term vision for the security organization and break down that vision into tactical objectives that are accomplished throughout the year. This post discussed a high level overview of what goes into strategic and operational planning, but aligning security plans to business risk, mapping security controls, obtaining funding and reporting progress are all complex activities that every CISO needs to master.

A CISO Primer On Navigating Build vs Buy Decisions

Every year CISOs propose and are allocated annual budgets to accomplish their goals for the upcoming year. Within these budgets are allocations for purchasing tooling or hiring new headcount. As part of this exercise CISOs and their respective security teams are asking: should we build this thing ourselves or should we just buy it? It may be tempting to simply buy a tool or to build it yourselves, but both options have advantages and disadvantages. Here are my thoughts on how CISOs should think about this classic business problem.

Strategic Considerations

The first question I ask myself and my team is – will building this thing ourselves become a strategic capability or differentiator for our business? If we build it can we use it ourselves and sell it to customers? Are we building a capability unique to the industry that could lead to patents or a competitive advantage? Most importantly, do we have the resources to develop, maintain and support this capability for the indefinite future? If the answer to these questions is yes, then you should consider building the capability yourself, but this also comes with a cost in terms of people resources.

Use of People resources

While building a capability can look attractive at first, it generally has long term costs that can easily add up to be more than the cost of just purchasing a tool or capability. This is because CISOs will need to staff engineers or developers to build the thing. This means they will need to hire (or borrow) resources who will need coding skills, database skills, AI/Big Data Skills and a bunch of other skills that aren’t typically key skills in a traditional security team.

Let’s say you will need to hire or borrow people to build your new thing. These people have salaries, benefits, bonuses, equipment costs, facilities costs and other expenses that can easily cost as much as (if not more than) the annual cost of purchasing a tool. Additionally, if you hired people, they can’t just move on once the thing is built. They will need to support it, maintain it, etc. If you borrowed resources then you will need to figure out who is going to handle ongoing operations and maintenance of the tool and you need to consider the opportunity cost of using these borrowed resources to build something for you instead of doing something else for the business that could have value.

The point is people aren’t cheap and they tend to be the most valuable resources for a business. Using these resources wisely and in a cost effective way is an important consideration for every CISO.

Financial allocation (CAPEX vs OPEX)

One other consideration for Build vs Buy is how your company allocates financial costs towards either CAPEX or OPEX. The reason this is something to consider is it may be easier to get OPEX budget than CAPEX (or vice versa). This can influence your decision to buy something over building it depending on how finance wants you to allocate the cost (or how easy it is to get budget in one of these buckets).

Time to deploy

Another consideration for Build vs Buy is – when do you need the capability and how long will it take to build it vs how long it will take to buy something and deploy it? If you need the capability immediately it may make sense to buy the tool and deploy it rather than trying to hire resources, onboard them, build the thing, support it, etc.

Integration Costs

Similarly, integration costs can be a huge factor towards whether the capability is truly effective or not. For example, if you can stand up the new thing relatively quickly, but it takes six months or a year to integrate it into your existing tools then that could throw your overall timeline off and may sway your decision towards building it yourselves instead.

Security Considerations of SaaS / Cloud Products

Lastly, and most important, CISOs need to think about the security considerations of buying a product vs building it in house. Software supply chain security is a top security risk for businesses and CISOs need to evaluate new tooling to see if they are adhering to the security requirements required by the CISO. If the product is a SaaS or Cloud Product then CISOs need to think about the risk of sending their data, source code or other information to a third party environment they don’t directly control. Similarly, if the CISO chooses to build the capability in house then they will need to make sure the team is making the new capability as secure as possible so the business and their customers aren’t exposed to unnecessary risk.

Wrapping Up

Choosing to build or buy a new capability isn’t an easy decision. Both decisions have explicit and hidden costs that can be difficult to navigate. Like any decision the CISO should weigh the risk of the decision and ultimately choose the option that supports the strategic direction of the business, meets financial and budgeting requirements and is sustainable by the security organization for the life of the capability.

Defining Your Security Organization

Whether you are inheriting an existing security team, or building an entirely new function, one of the first things you should do after building a strategic plan and creating an organization plan is to define what you want your security organization to look like. This step builds upon the organization plan by defining what each role in your organization will do (including skillsets), what the career path is for each role and what success looks like for each job function. This will not only help define the details or your organization plan, but it will help lay the foundation for how you want to build your organization (if you are starting from scratch). If you are inheriting and organization it can help you establish your expectations by clearly defining what you want from each part of your organization. It can also help you plan for a re-org or help to diagnose performance issues with a particular team or within the overall security org.

If you are part of a large organization most or all of this will be defined by your HR department, but I still find it useful to tailor the general HR approach to your specific security organization. If you are part of a start up or small organization then you may need to define everything yourself.

Mission Statement

First, I recommend creating a mission statement. This should be a really short statement about the overall purpose of the security organization. This mission statement will not only help to clarify what your group is trying to achieve, but it will also give a sense of purpose to the security practitioners within the security org. I recommend creating a mission state at the org level and then for each function within the security org to help clarify the purpose of that function. This will be useful to explain what your security functions do, especially when interfacing with non-security groups like legal, finance, hr, etc.

Example:

The mission of the security org is to enable [company x] to effectively manage risk related to security and privacy of our products and services.

Role Definitions

Once you have defined the purpose of your org, you will want to look at your organization plan and define what each role will do. Security Engineers, Security Architects, DevSecOps Engineer, Governance & Risk Practitioner, Incident Response Analyst, etc. will all need a short description of what the role will do. Going through this exercise will serve three purposes. First, if you need to hire for any of these roles you can use most of this information in the job description. Second, if you already have people in the role, it will help clarify your vision for the purpose of that role. Lastly, if you need to request budget, these role definitions will help explain what these people are going to do as part of the budget request.

Example Role Definition: Security Engineer

Designs, builds, configures, diagnoses, integrates and maintains security tooling required by the security organization. Establishes requirements, performs trade-off analyses and recommends tool selection. May work with other IT or engineering groups within the organization.

Career Paths

Once you have the roles defined you will want to establish career paths for these roles. Establishing career paths will require you to think about the scope and impact of each level of the role. For example, if you have 5 levels in your organization you will need to define titles for each level, the skillsets for each level and how those skills increase in scope and impact. You will need to do this for both individual contributor roles and management roles. I recommend breaking out the skills into general and role specific.

General Skills

General skills are skills required by all employees in your organization. These include things like communication, strategic thinking, agility and collaboration. If you are part of a large organization, these skills should already by defined so you can work with your HR team to adapt them to your security function and then define what each employee should be demonstrating at each career level.

Example: Communication

Level 1 – Able to articulate clearly and concisely when communicating
Level 2 – Able to convey thoughts and opinions in a compelling manner to the appropriate audience
Level 3 – Gains support for new projects by clearly communicating value and addressing concerns
Level 4 – Builds networks throughout the organization to support large initiatives and future endeavors
Level 5 – Champions strategic initiatives in ways that generate organization wide support

Role Specific Skills

Role specific skills are skills required by each role. They are unique. An engineer may require hands on knowledge of specific security tooling and the underlying platforms. An incident response analyst will require in depth knowledge of how to respond, contain and recover from an incident. Governance and Risk analysts may require specific regulatory knowledge. Input for these skills can come from the CIS or NIST control sets, industry job postings and industry certification requirements. All of these need to be defined in increasing scope and responsibility so employees know what is expected and can prepare for the next level of the role.

Example: Security Engineer

Level 1 – Demonstrates a working knowledge of security engineering concepts such as network security, identity, storage, encryption, operating systems, cloud, DevSecOps, etc.
Level 2 – Demonstrates a detailed knowledge of one of the following security engineering concepts – network security, identity, storage, encryption, operating systems, cloud, DevSecOps, etc.
Level 3 – Demonstrates a detailed knowledge of one or more of the following security engineering concepts – network security, identity, storage, encryption, operating systems, cloud, DevSecOps, etc.
Level 4 – Demonstrates a expert knowledge of one or more of the following security engineering concepts – network security, identity, storage, encryption, operating systems, cloud, DevSecOps, etc.
Level 5 – Demonstrates and applies expert knowledge of one or more of the following security engineering concepts – network security, identity, storage, encryption, operating systems, cloud, DevSecOps, etc.

The career paths will help you during budget requests to justify why you need a specific role level. For example, maybe an upcoming initiative is really critical and has a tight timeline so you need to hire someone very senior so they can start making an impact right away. Alternatively, maybe you want to hire a more junior person because it will fit in the budget, but now you need to plan to train them and ultimately, the project will take longer to complete.

Career paths will also help clarify what your team members should be working on to get promoted to the next level. They are also useful during goal setting, career conversations, performance reviews and mentoring sessions.

Example Career Path: Security Engineer

Level 1: Associate Security Engineer
Level 2: Security Engineer
Level 3: Senior Security Engineer
Level 4: Principal Security Engineer
Level 5: Distinguished Security Engineer

Scope and Impact

The last thing you should do as part of this exercise is define the scope and impact for each career level. Defining scope and impact gives further clarity to your team members about how they should be thinking about their role and what success looks like. It defines what part of the organization they should spend their time in and who (or what level) they should think about interacting with.

Example: Scope & Impact

At the end of this exercise you will be left will a very detailed explanation of not only what your security organization looks like, but what success looks like as well. Your Role Definitions will provide a short description of each role, your Career Paths will help define the levels and performance expectations for each role and the Scope and Impact will define the level where each role is expected to contribute. All of this will become a reference guide for every single member in your security org and will help you as the CSO to budget, plan, diagnose and shape your organization to achieve success.

Building A Security Budget To Address Risk

Over the past 9 months layoffs have been impacting the tech industry amid heightened concern over the economy, increased scrutiny on profits and over investment by companies in areas that don’t positively impact the bottom line.

As organizations tighten their belts it is possible they will look at the security organization with increased scrutiny and whether you need all of those people, tools or other line items in your budget. As the CISO you may be asked to justify your budget and explain how your budget links back to value or reduced risk for the company. You also need to avoid common budgeting traps like getting forced into a percentage or flat allocation. Here is my approach to this exercise.

Consider The Priorities Of The Business

First, review the immediate priorities from your strategic plan, regulatory and compliance obligations and top risks for the company. Are those still the right things to focus on? Did the development org drop a product or service area that no longer requires the security team to monitor or protect? Has there been a reduction in non-technical staff that may reduce the number of people that need security awareness or phishing training? Has your company abandoned investment in a particular business vertical, which means you no longer need to plan to complete a compliance audit or certification (like FedRamp or PCI-DSS)? Is your company planning to launch a new product, complete a merger & acquisition or expand in a new geographic region? Is there a new emerging threat to your business that needs attention?

Ultimately, the answers to these questions will result in a few possibilities:

The business is going to continue to grow and invest, which will require the security team to also grow and invest so the business can mitigate or reduce new risk.
The business will maintain existing investment and exposure to risk, but not increase it.
The business will reduce investment based on contraction of business areas that will result in reduced risk to the business.

Articulate A Plan To Address Business Risk

Second, the CISO’s job is to articulate risk and present recommendations to the business for how to address the risk. However, it is important to remember that the business may choose not to follow your recommendations and that’s ok. A CISO should have strong relationships with the other C-Suite executives, but they also need strong relationships with the various corporate functions like legal, HR and finance.

Whether your company is growing, staying the same or contracting, the CISO still needs to present an appropriate budget recommendation and plan to address the risks to the business. I’ve covered how to build a strategic plan before and that should be one of the primary inputs to this exercise.

Planning For Headcount To Reduce Risk

Generally, when considering people resources you should plan to have at least two years of work for those people to accomplish. This means you should look at your strategic plan and consider what risks you can address with the existing resources in your organizati on over the next two years. Map people to projects with realistic timelines, deliverables and deadlines. Link the priorities back to the strategic plan.

Next, consider what additional risks you could address if you could add additional people to your organization. Are they completing a new compliance audit like ISO27001? Are they implementing a new tool or developing a new process to address an unaddressed risk (such as SBOM or API security)? Do you need additional resources for your SOC to improve chase the sun coverage or to have redundancy when people are on vacation or sick? Is there a particular geographic region that needs investment or that offers similar talent to premium locations, but is currently less expensive? Remember it takes time to identify, hire and train new talent before they are productive.

Lastly, consider what would happen to your plan if people left the organization. Can you still accomplish your goals if you have 5% attrition, 10%, 20% or more? Will it simply take longer to reduce the risk or does less resources make the objective impossible and so now the business will now be exposed? Conduct succession planning to fill the immediate gaps and then build in contingencies in your budget to hire or backfill if needed.

Planning For Technology To Reduce Risk

Taking it one step further, consider what new tooling investments you need to make to address the top risks in your strategic plan. Do you need a new SIEM? Do you need a SAST/DAST scanning capability? Do you need better endpoint detection and response (EDR)? Can you free up people resources by implementing a new tool or automating a process? Determine the best tool and get budgetary pricing for your budget. Depending on how tightly your finance org runs the budget you may also want to add in a tooling contingency to allow the org to pivot or add something new part way through the fiscal year.

Other Budgetary Considerations

Depending on the remit of your security org you may or may not have other line items in your budget. Below are some examples:

Penetration tests conducted by an external company
Physical security improvements like cameras, alarms, badge readers, safes, etc.
Compliance Audits (SOC, ISO, FedRAMP, etc.) or other audits and certifications by external firms
Contractors or professional services for short term (1 year or less) engagements
MSSP or service providers if you outsource parts of your security org (like incident response)
BugBounties for external security researchers
Cyber Insurance (with planned increase if you are entering new business areas)
Possible legal fees for lawsuits, contractual reviews, outside counsel or other security related legal matters depending on how finance allocates these costs in the overall budget
Lab, subscription and equipment costs for threat hunting, security research, cyber ranges or training exercises
Executive protection costs for your C-Suite executives
Brand and reputation monitoring
Training costs for conferences, certifications, tuition reimbursement, security awareness, phishing exercises or other training and education related fees
Costs for maintaining specialized security functions like a SCIF, holding clearances, renewing clearances, liaising with law enforcement or other federal agencies
Costs for participating in security trade groups, boards or other industry facing security groups that help influence activities for your business
Outside consulting firms for specific areas of expertise and unique circumstances like VIP security protection or protecting large events (like company conferences or other extremely large events)

Security Isn’t Just A Cost Center

Don’t forget to offset your budget with activities that positively impact the bottom line for the business. Depending on how your organization is structured you may have customer and industry facing groups or groups that participate in activities like Mergers & Acquisitions. If you have Security Consultants, Professional Services, offer Managed Security Services or participate in other activities that positively impact the bottom line, then your org should get credit for these activities and they should help offset the other security budget items that are typically a cost center for the business. You can have your go to market team or customer facing security resources tag activities in your CRM tool and then pull reports based on this tag. You can also do this with a simple spreadsheet that captures the date, the dollar amount, how many security folks were involved and a short description of the activity. This can be really powerful to show how the security org is helping to not only protect the business, but directly or indirectly improve the bottom line.

Final Thoughts

A lot goes into creating a budget for your security organization with the ultimate goal of reducing or mitigating risk to the business. It is easy to fall into a trap of simply looking at the security org as a percentage of overall headcount for the rest of the business and then allocating budget accordingly. There are metrics floating around the internet claiming security budgets are on average some percentage of the IT budget, or some other percentage of the overall technology spend for an organization. This is the wrong approach in my opinion.

Allocating a flat percentage can result in underinvestment in the security org, which means risk to the business will tacitly (or explicitly) go unaddressed. Having a strong relationship with the finance org and linking your budget requests back to your security organization plan and strategic security plan is the best way to plan and execute a budget that is grounded in reality to reduce risk instead of using arbitrary percentages.

The finance org can also help to make sure you are following their accounting process such as spreading costs over quarters, not recognizing costs until the quarter you actually have to start paying for something, reminding the security org when renewals are coming up and making sure you are sent reminders for when accounting is going to reclaim allocated budget if you don’t spend it in time. They can also help you move things around within the fiscal year so you can maintain your budget based on shifting priorities.

Lastly, I encourage all CISOs to have a budgetary dispute resolution process facilitated by finance and decided on by either the rest of the C-Suite or the board. CISOs need to be able to raise critical risks in terms of staffing, tooling or other issues that will ultimately impact the budget and is separate from the normal budget process. This isn’t a blank check, but a process to break through during urgent situations (like breaches or incidents) and get the budget needed to quickly resolve the issue.

Building a budget for the security org is a time consuming, but critical process. CISOs need to be grounded in basic finance and understand the true P&L of the security function so they can accurately articulate value as related to risk management. The finance org is your greatest ally to assist you with this process to make sure you are putting things in the right buckets (Opex vs Capex). While finance may have rigid processes for how they want to plan for the budget, it is up to the CISO to link their budget back to a strategic plan to address risk for the business and present that plan for approval without falling into traps of percentages or flat allocations.