Category: Budgeting & Finance

How Should CISOs Think About Risk?

There are a lot of different ways for CISOs to think about and measure risk, which can be bucketed into two different categories. Qualitative measurement, which is a subjective measurement that follows an objective process or quantitative measurement, which is an objective measurement grounded in dollar amounts. Quantitative risk measurement is what CISOs should strive to achieve for a few reasons. One, it grounds the risk measurement in objective numbers which removes people’s opinions from the calculation; two, it assesses risk in terms of dollar amounts, which is useful for communicating to the rest of the business; and three, it can highlight areas of immaturity across the business if they are unable to quantify how their division contributes to the overall bottom line of the company. In this post I want to explore how CISOs should think about quantitatively measuring risk and in particular, measuring mitigated, unmitigated and residual risk for the business.

Where should you start?

A good place to start is with an industry standard risk management framework like NIST 800-37, CIS RAM or ISO 31000 and for the purposes of this post I’ll stick with the NIST 800-37 to be consistent. In order for CISOs to obtain a qualitative risk assessment from the NIST 800-37 they need to add a step into the categorize step by working with finance and the business owners to understand the P&L of the system(s) they are categorizing. The first step is to go through every business system and get a dollar amount (in terms of revenue) for how much the systems(s) contribute to the overall bottom line of the business.

Internal and External Security Costs

After you get a revenue dollar amount for every set of systems, you now need to move to the assess stage of the NIST 800-37 RMF to determine which security controls are in place to protect the systems, how much they cost and ultimately what percentage the security controls cover. There are two categories of security controls and costs you will need to build a model for. The first category is internal costs, which includes:

  • Tooling and technology
  • Licenses
  • Training
  • Headcount (fully burdened cost)
  • Travel
  • R&D
  • Technology operating costs (like cloud costs directly attributable to security tooling, etc.)

The second category is external costs, which includes:

  • 3rd party penetration tests
  • Audits
  • Managed Security Service Provider (MSSP) costs
  • Insurance

As you fill in the costs or annual budget for each of these items you can map the coverage of these internal and external costs to your business to determine the total cost of your security program and how much risk the program is able to cover (in terms of a percentage).

Mapping Risk Coverage

Once you have all of these figures you can start to map risk coverage to determine if your security program is effectively protecting the business. Let’s say your business generates $1B in annual revenue. Your goal as a CISO is to maintain a security program that provides $1B of risk coverage of the business. Or, if you are unable to provide total coverage, then you need to communicate which parts of the business are not protected so the rest of the C-Suite and board can either accept the risk or approve additional funding.

As a simple example, let’s say you spend $1M/year on a SIEM tool, which takes 6 people to operate and maintain. The total cost of the 6 people is approximately $6M / yr (including benefits, etc.). The SIEM and people provide 100% monitoring coverage for the business and the SIEM and people can be mapped to 20% of your security controls in NIST. I’m skipping a lot of details for simplicity, but for a $1B business this means your SIEM function costs $7M / yr, but protects $200M of revenue ($1B x 20%). As you map the other tools, processes, people, etc. back to the business you will get a complete picture of how much risk your security program is managing and make informed decisions about your program to the board.

For example, you may find your security program costs $100M / year, but is only able to manage risk for $750M (75%) of the business. Your analysis should clearly articulate whether this remaining 20% of risk is residual (will never go away and is acceptable) or is unmanaged and needs attention.

Complete The Picture

By mapping your security program costs to the percentage of controls they cover and then mapping those controls to the business, CISOs should be able to get an accurate picture of the effectiveness of their security program. By breaking out the security program costs into the internal and external categories I’ve listed above, they can also compare and contrast the costs to the total amount of risk to determine which investments yield the best value. These analyses can be extremely effective when having conversations with the rest of the C-Suite or board, who may be inclined to decline additional budget requests or subjectively recommend a solution. By informing these stakeholders of the cost per control and the risk value of that cost, you can help them support your recommendation for additional investment to help increase risk management coverage or to help increase the value of risk management provided by the security program.

The following chart is an example of what this analysis can yield.

Once you have this data and analysis you can start driving conversations with the rest of the C-Suite and the board to inform them of how much risk is being managed, how much is residual, how much risk is unmanaged and your recommendation for additional investment (or acceptance). These conversations can also benefit from further analysis such as the ratio of cost to managed risk to determine which investment is providing the best value and ultimately support your recommendation for how the company should manage this risk going forward (people or technology).

Wrapping Up

Managing P&L is a fundamental skill for all CISOs to master and can help drive conversations across the company for how risk is being managed. CISOs need to master skills in financial analysis and partner with other parts of the business like business operations or business owners to understand how the business operates and what percentage of the business is effectively covered by the existing security program. The results of this analysis will help CISOs shape the conversation around risk, investment and ultimately the strategic direction of the business.

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.

What happens post incident?

One of the most exciting, stressful and true tests of a CSOs ability to lead during crisis is during a security incident. Unfortunately, it is inevitable that CSOs will experience several security incidents during their tenure. This could be something as small as a configuration error, or as large as a full on public data breach. I also think CSOs should assume they are operating in some state of compromise such as a malware infection or an attacker with complete remote access. Given this volatility of enterprise environments and the inevitability of some sort of security incident, the question becomes what happens afterwards? Just because you are no longer under active attack doesn’t mean your work is done. As a CSO, here are some things you should consider after an incident:

Retro / Post Mortem

First, I highly recommend conducting a retro or post mortem on the incident. This is a blameless session to discuss what happened, why it happened and most importantly what the team learned from the incident and what they are collectively going to do differently. During this exercise the CSO should plan to ask questions and listen a lot. I find being the note taker is exceptionally helpful because it is difficult for me to talk while taking notes. I want to hear opinions and ideas from the team on what happened and how we are going to improve. The result of this retro will likely kick of follow on activities such as increased training, requests for investment, development of new processes, creation of new detections or even additional automation. The point is it is a time to learn and rebuild.

Investment

Never let an incident go to waste. Instead of viewing the incident as a failure, I choose to look it as an opportunity for growth. It is easy to point the finger after the fact, but no environment is 100% perfect and secure. Therefore, after the retro is completed it is important to capitalize on the incident to ask for additional investment to respond to the improvement areas raised in the retro. This could mean asking for additional personnel to respond to events, it could mean additional training to fill knowledge gaps, it could mean a new tool or technology to improve detection and response or new processes to improve responses. As the CSO you need to distill down the retro suggestions into an actionable plan that focuses on the risks along with areas for improvement and investment.

Increased Regulatory Requirements

Unfortunately, there are consequences for having a security incident. For publicly traded companies this can come in the form of increased regulatory requirements such as being required to have an independent 3rd party audit your security practice on a periodic basis. It could also mean fines or reporting the incident as material in your upcoming SEC filings. You may even get inquiries from various regulatory bodies asking what happened and what you are doing to prevent it in the future.

Legal Ramifications

Similar to the regulatory requirements your company may face increased legal pressure as a result of the security incident. This could come from a number of different sources such as: lawsuits from outside entities (such as a consumer group or class action), increased contractual obligations from customers who are now concerned about your security practices, law enforcement investigations and costs for outside counsel who have expertise in your specific business area and are helping your company limit the damage.

Financial Implications

This is probably the biggest area for a company to navigate after an incident. Financial implications can manifest in a number of ways. Here are a few:

Increased Cyber Insurance Costs

As a result of the incident, your company may face an increase in cyber insurance premiums. These premiums may even become so expensive that your company can no longer afford to pay them, or your company could be deemed uninsurable.

Customer Impact

Depending on your business, this could be something simple like contracts not getting renewed and loss of new business or it could be something more material like having to pay to notify all of your consumers, paying for credit monitoring and having to compensate your loyal customers in some way to retain their business.

Market Impact

This is a broad area, but post incident your company could face a decrease in stock price. It may even be more difficult for your company to secure lines of credit because of the business risk. The severity and financial impact of the incident could potentially put your company at risk for M&A takeover or may require the business to declare bankruptcy and look for a buyer who has enough capital to weather the storm.

Budget Impact

Again, this is a broad area, but whenever I have an incident I try to keep track of the number of people involved, number of hours it took to deal with it and the opportunity cost of dealing with this versus doing something else I had planned. As an example, the opportunity cost could be something like “as a result of this incident we had to delay project x for 3 months while we dealt with the incident.” All of this will have an impact to timing, budgets and manpower.

Can You Calculate The True Cost Of An Incident?

Unless your company keeps track of everyone’s time and is able to create a time code entry for each specific incident, I find it unlikely that we will ever know the true cost of an incident. There are many direct costs, but there are so many indirect costs that are hard to estimate. The ramifications of an incident may stretch on for years and may change hands from one CSO to the next. However, I do think a CSO should have enough grounding in business principles to be able to estimate the cost of an incident. This can be useful when gaining support from your other C-Suite peers, when presenting to the board or when making investment requests to the CFO. Having context for all of the ramifications of an incident along with potential areas of growth and improvement can be a valuable story to tell.

The Different States Of A Security Program

It may be obvious, but every company that has a security program is in a different state of maturity. As a CSO, it is important to recognize and understand what these different states mean in terms of where your energy will be applied. If you are interviewing or hiring into a company, it is critically important to understand what state the security program is in so you can determine if the opportunity is right for you and to ultimately maximize your impact in the role.

The Different States

In general, a security program can be in one of three different states:

  • New / Building
  • Existing / Incremental
  • Shrinking / Decline

New / Building

A security program that is new typically comes along with new companies, startups or possibly new business units that are acquired via acquisition. However, a company may also be establishing a new program if they are found deficient during an audit or if they suffered a security breach. In this state the CSO (or security leader) needs to establish a program from scratch, which will include mapping risks, developing a budget and establishing funding, recommending tools, evangelizing security best practices and hiring a team. There will be a lot of focus on foundational aspects of security like asset inventory, reporting and initial risk baselines for the organization. Your team will also go after initial program certifications like ISO27001, SOC or other compliance activities. You may even need to establish new processes and ways of working.

Here are some good questions to ask to determine if a program is in the new / building state:

  • Who is performing the function of security today?
  • What goals does the organization have in the first year and three years from now?
  • What is the expected annual budget?
  • How many headcount do you expect for the security team in the first year?
  • Where does your company operate and do you expect to have security resources in those geographic regions?
  • What security tooling is in place today (if any)?
  • Does the company have any existing compliance certifications (like SOC, ISO, etc.)?
  • Why is the company focusing on hiring a security leader and building a security program? Did this come about due to a security incident or other security event like a failed audit?
  • What industries does the company do business in? E.g. finance, government, healthcare, etc.

In my experience, establishing a new security program from scratch is a rare opportunity, but if you get the chance it is truly exciting and offers the opportunity for giant leaps forward in terms of security maturity for the company.

Existing / Incremental

The next state of maturity is existing or incremental and most companies will be in this state. In this state a security program has already been established and has the foundations in place in terms of people, processes and technology. Tooling has already been purchased and implemented, an annual budget has been established and a team exists with different functions like security engineering, security operations and security compliance.

An existing security program usually has smaller goals or incremental annual objectives designed to address some specific area of risk that has been outstanding, or to address a new risk area based on business growth. For example, perhaps the organization has an existing Identity and Access Management (IAM) program, but needs to roll out 2-Factor Authentication (2FA) to further secure access. Or, maybe the business is expanding into the financial industry and needs to become PCI-DSS compliant. These are incremental improvements to the security program and will require increases or reallocation of people and budgets.

A CSO or security leader in charge of an existing security program will generally keep things running smoothly, make sure the company doesn’t regress with respect to security maturity and will continually be evaluating the business for new or existing risks that need to be managed.

Here are some questions you can ask if you are interviewing for a new role that will lead an existing security program:

  • What is the annual budget for the security program?
  • What security tools are in place?
  • How is the team structured?
  • What are the security objectives for this year? For three years?
  • What security compliance certifications does the company maintain (e.g. SOC, ISO, etc.)?
  • How many people are in the security team?
  • What functions does the security team perform? (I.e. security engineering, compliance, risk, product security, security architecture, security operations and incident response, etc.)
  • Why are you looking for hire for this role or who am I replacing if I am hired?
  • How do you expect the business to perform over the next year?

Shrinking / Decline

It is an unfortunate reality that not all programs are in the building or existing states. Sometimes security programs shrink or slip into decline. This can be for a number of reasons such as poor leadership or a declining business. A shrinking security program can also be a temporary state that matches normal expansion / contraction of a mature business and the economy. Whatever the reason, leading a declining security program has significant challenges. First, the security leader will need to over communicate the existing risks to the business and make sure budget and headcount reductions match the reduction of risk as the business shrinks. A CSO can run into real trouble if the reductions are arbitrary and leave the business exposed.

Second, you can expect to have to do more with less. As the business contracts your team will still need to perform, but there may not be additional perks such as training, travel, new tooling, etc. You may also need to consider shrinking budgets and reductions in license counts or other tooling.

Another reason for a shrinking / declining security program is during mergers and acquisitions. Depending on how the deal is structured and the capabilities of the acquiring business, your security team may be redundant or parts of your team may no longer be needed.

A shrinking / declining security program isn’t the end of the world, but it does require careful leadership to make sure the risks are managed appropriately and morale doesn’t completely decline and impact the performance of the remaining team.

Not Everyone Is Good In All States

Not everyone will admit it, but the reality is not everyone is good in all states. This shouldn’t be surprising. Startup founders routinely find they can’t scale a company past a certain point and require additional help. Similarly, I have personally experienced that security programs require different leadership depending on the state of the program and the skills of the individual. Some people just can’t scale a program past the building phase and into the incremental phase. Some people don’t know how to handle decline. Leadership skills aside, some people just have a specific preference for what they like to do.

No matter where you are in your professional career or whatever state your security program is in, I hope this post will help you identify and navigate the type of security program you enjoy leading or are looking to lead one day.

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.

Centralized vs. De-Centralized Security Team?

Whether you are building a security team from scratch, expanding your team or re-allocating resources, you may be wondering what is more effective – a centralized or decentralized security team? Both have their pros and cons and I’ll discuss them and my experience with each in this blog post.

Centralized Security Team

This is probably the most common structure for a security team. In most organizations it makes sense to group all people doing the same thing into a single org. Sales people, IT, Finance, HR, etc. all get grouped into a single org with an executive leader at the top. For the security team it has some distinct advantages.

First, the CISO has direct control over the resources in their org. The reality is, whoever is responsible for the performance reviews and paycheck for the resource, is the one who actually controls that resource. This may sound obvious, but I have seen a lot of weird matrixed, resource sharing organization structures that quite frankly don’t work. There can only be one leader and centralizing the security resources under a single security org provides direct control of how those resources will be used.

Second, it provides a single point of contact or “front door concept” for the rest of the business. If there is an incident, security question, customer inquiry, etc. everyone knows who to reach out to and who the leader is for the security group. This can allow the CISO to more easily track metrics, measure risk and dynamically adjust priorities based on the needs of the business.

However, the downside of a centralized security organization is it often gives the impression that the rest of the business is absolved of their responsibility for security. I have heard the following from various parts of the rest of the business:

Why isn’t security doing that?

What is security doing if I have to do it?

What are you doing with all those resources?

A centralized security team can exacerbate the confusion about who is ultimately responsible and accountable for security within the organization. Or, the security team is held accountable for the security failings of the rest of the business even though they aren’t responsible for doing the things that will make the business more secure. These shortcomings can be overcome with a strong security first culture and when the CISO has strong relationships with the other business leaders in the org.

De-Centralized Security Team

A de-centralized security team can improve on some of the short comings of a centralized security team, but it also has disadvantages.

First, a de-centralized security team allows the business to place resources close to and often within the team that is actually responsible for doing the thing. Think about fixing software vulnerabilities. If the development team building the software product has security expertise on their team, that resource can help prioritize and even fix some of the issues as part of an embedded team member. They can raise the security performance of the whole team. This can be an efficient way to deploy resources on a limited budget.

A de-centralized security team can also spread the cost of security around the org in an equitable way. If each function is required to embed a few security resources then those resources (and headcount) are allocated to that business function.

The downside of a de-centralized team is loss of control. The CISO may still be held accountable for the security of the business, but they may not control the headcount budget for these embedded resources. If the CISO is able to hold onto the headcount budget, that is great, but it doesn’t prevent another issue – having the resources go native.

In my experience, de-centralized teams can often go native. This means the resource fails to prioritize the security asks of the team, fail to hold the team accountable or simply start doing non-security work when asked to do so by the rest of the team. If the CISO doesn’t control the headcount then this is effectively a lost (or non) security resource. Even if they do control the headcount, they may have to constantly battle and remind the embedded resources to prioritize security work. This is a particularly glaring problem when there is a weak security culture within the rest of the business.

What Should I Choose?

There really is no right answer here, but if I had to choose one over the other I would choose to centralize the security team and then spend a large amount of time with the rest of the org to articulate their responsibility for security. In an ideal world, that has a large enough headcount budget, I would choose both. Keep a core centralized team like incident response and GRC, but de-centralize application security engineers and architects within the teams that do development work. The structure of a centralized team and even a de-centralized team will be highly dependent on the needs of the business and who is ultimately responsible security.

However, the reality is your organization probably grew organically with the rest of the company and at some point you may be wondering if your organization structure is best to support the rest of the business. Shifting from centralized to de-centralized (or vice versa) is not impossible, but will require careful thought on how to deploy and control the resources so they can be effective. My suggestion is to start small, experiment and see what works for your org.

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

Scope and 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:

  1. 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.
  2. The business will maintain existing investment and exposure to risk, but not increase it.
  3. 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 organization 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.