By Samuel Shanthan B.Sc.Eng. (Hons), MBCI, CPRM, CIPM, CISM
This article discusses the need for the business unit in charge of security, of any organisation to hold budget (i.e. funding), which grants power to accomplish and achieve security objectives, while helping to prioritise and spend wisely.
Depending on the manner in which information security/cyber security forms in the organisation structure, the same concept can be equally applied to Risk or Business Continuity or as a combined Security and Continuity budget.
In organisations where security management/discipline is shown as a profit centre, it would have better influence and budget, however, in many organisations it is considered as a cost centre and this article assumes it.
Funding problems
Funding is a challenge and a problem to fulfil security objectives, as shown in many surveys and a few are provided below.
According to The Security Profession in 2018/19 report from the Chartered Institute of Information Security, “threats are rising and budgets falling behind – implying a constant stress to achieve more (or defend better) with less resources”.
According to Spiceworks survey (2019), Security is among the top three (3) factors for increase in IT budgets.
Approaches
In many small and medium organisations separate security budget does not exist, instead every time a business case has to be raised or budget has to be allocated from general operational expenditure or form other business unit budgets, which can be challenging and lead to waste of time for the security professionals.
There are two possible approaches to create a security budget as in Figure 1 above:
- Get the budget for the setup. To negotiate to find the budget for the right security programme. In this approach the security uplift and the ongoing cost (CAPEX and OPEX) is estimated for the desired/target security setup, without taking into consideration the organisational appetite for spending. This should align with the security strategy, but is not discussed in this article.
- Plan the setup (project) to fit the budget. In this approach the organisational appetite for spending is obtained from executives before prioritising actions. After the CAPEX and OPEX are determined projects are prioritised to achieve security objectives.
In my experience, I have come across both methods being used and there is no right approach. Most professionals prefer the first approach and canvass continuously to obtain budget from the executives over a time. If they fail, then they try a reduced cost version and so on. There are pros and cons in each approach as in Table 1.
Challenge for CISOs
As security professionals and Chief Information Security Officers (CISO) we owe the responsibility to inform the management of the appropriate security setup that suits the business and leave them to make the decision. At the same time, we need to influence to gain budget approval to achieve the security objectives.
In requesting budget, there is a fine balance, security managers and CISO’s should be aware of as in Figure 2 above:
- Left: If more funding is requested, beyond the business can afford, while showcasing the security risks, then security may not be seen as a business enabler, and the CISO is at the risk of losing his/her role.
- Right: If the business is not provided with the appropriate security setup and minimum spending is made, and security risks are shown as minor it would be well with the business. However, if a major security incident occurs then security function will be considered as a failure and the CISO will be at risk of not taking reasonable care and not providing management adequate information of the risks. Additionally, the CISO may also lose his/her credibility in the market making employment with other organisations difficult.
Case study: Recently when I identified an absence of a disaster recovery setup for a critical service, I prepared a budget for a high availability solution. However, it was costing beyond the appetite for the management to spend. When I learnt that the management was reluctant to spend, I inquired and found the amount that the management may be comfortable to spend. Based on the appetite to spend, I reduced the scope, proposed using some used hardware with a warm DR setup. Although this did not achieve all the requirements in terms of risk and recovery time objectives, it was a middle ground and reduced the risk from high to medium (rather than to low) and reduced the recovery time objective from weeks to days (instead of hours). This solution was well accepted by the management and placed the organisation in a position where risk was managed well.
Influencing and gaining power
The diagram below (Figure 3) shows the influencers, power and elements of a budget.
- Influence
Different ways to influence budgets (funding) is suggested below.
Scope small: Sometimes it is important to prove the concept and by reducing the scope while leaving room for expansion later. This helps to show the quick wins and assists later in requesting additional budget when management is convinced of “facts” not “opinion”.
Case study: In recent times, I was reluctant to ask budget for a SIEM (Security Information and Event Management), so I planned only for one of the states in Australia and conducted a POC (Proof of Concept). When the POC was successful the management requested to roll out the SIEM Australia wide.
Plan low: In some organisations budget overrun is permitted up to a level ranging 10-15%. If only a limited budget is available, it is worth to consider planning low, without adding for contingency and then adding scope within budget extension limits.
Cost benefit analysis: Risk management can be used to measure the impacts and probability and use estimated cost in justifying the budget (i.e. cost benefit analysis).
Case study: For example, if the outage of a communication link could cost $1m in 2 hours as penalty and the SLA is 2 hours, estimate the likelihood (probability) from risk assessment (preferably enterprise risk assessment), say once in 3 years. The annual cost of this outage incident occurring would be $ 1M x 1/3 = $ 333K. In such a situation it is possible to justify a VSAT or a microwave link between the sites which cost only $100K and could be easily accepted by the management. It would be better if these estimates are drawn from the enterprise risk assessment, as it will have better credibility.
I have used similar cost benefit analysis in several business cases including security setups, audits, disaster recovery setup etc., by quantifying impacts including reputational impacts in dollar terms, and were very successful with executives.
Insurance saving: Good security and business continuity setups reduce the risk and there will be savings from the insurance premiums. However, it could be challenging to quantify it as the insurers may not give a specified value for the reduction in premium. One way is to influence the insurance assessor when they meet the C levels, to mention that the risk is reduced due to good business continuity setup. Cyber insurance is growing and reduction in cyber insurance premiums could be an added advantage of investing in security.
Case study: In one of the insurance assessments in a bank, the Chief Risk Officer sent an email to the other C levels stating the insurance company assessed the risks related to disruption, people, service level obligations etc., as low due to the successful disaster recovery planning and testing. This helped in obtaining support for additional spending from executives.
Insurance assessors are generally not subject matter experts in security or continuity, but they assess the associated risks. One way to convince insurers quickly is to provide independent assurance such as ISO 27001 (for Information Security) and ISO 22301 (for Business Continuity) certificate. I have found certifications (accreditations) to be convincing within a 10 minutes discussion and the evidence is easy to provide and for the insurers to understand. Insurers understand risk well and it is important to explain how information security risk assessment is performed and it is represented in enterprise risk and board meetings.
Capital Vs Operational expenditure: Some organisations are sensitive for CAPEX and others for OPEX. In making capital investments there are different models that can be used for servers, data centres or even applications such as SAAS to normalise the payment over a three to five year period. Now most of the security solutions (e.g. Firewalls, SIEM) are offered with cloud-based solutions from leading vendors and has less capital commitment.
Case study: Several years ago, when it was planned to setup an off-country data centre, it was costing a lot to build a separate data centre in Europe. After consulting with various providers for a fraction of the price with a three year commitment it was possible to use a collocated data centre, with adequate security, which was comfortable for the management with equal three year payments rather than a huge CAPEX. However, it had challenges in addressing security concerns.
Bundle:
Case study: Several years ago when remote working was not popular, I started using remote working for business continuity purposes and after a particular test, the Private banking business unit wanted remote working for normal use (BAU) as the customer service agents were visiting the clients (VIP) and wanted access to the banking system by connecting via VPN (Virtual Private Network) and MFA (Multi Factor Authentication). To facilitate this I expand this usage and provided a combined proposal and charged majority of the cost to the business and only the incremental to the business continuity setup. If it is a special budget and there is a business need the chances of obtaining approval are high and could be used for the advantage of security or business continuity (i.e. piggybacking).
Spending evenly: Significant number of organisations approve budgets, based on past year actual expenditure. This is a separate governance issue, not a security issue with organisations encouraging business units to spend to get more for next year budget, without a need; which ideally should not be the case. However, we need to follow the organisational practices and try to keep projects over a period or break it in phases rather than having a large project at one time and then being without projects. It would also help the security function to allocate time evenly balancing operations and projects.
Project inclusion: Security must be part of all projects from inception till testing. This must be not only for ICT projects but also for new products or outsourcing or even change of organisational procedures. Security involvement can be fruitful only if adequate budget has been included within those projects. Many projects include security audits and penetration tests, but do not allocate adequate budget to rectify the recommendations (findings).
Case study: In one of the organisations that had to provide 24×7 customers service, when a new call centre (contact centre) system was established they excluded disaster recovery (DR) setup, as the cost was overrunning. In other words, completion of the project within budget and time was the focus at the expense of excluding the DR setup.
- Power
The budget provides power to achieve security or business continuity objectives.
Spend extra to achieve: In some instances, by spending something extra, objectives can be achieved, and obstacles overcome.
Case study: In one instance when I was implementing a training system and the IT department did not have resources. To solve this problem, I spent little extra and implemented the training in a SAAS model and kept the project on track, as it was important to get the users aligned and build the culture.
In another instance in a small organisation when in-house cyber incident response capabilities were not available and was not cost justifiable, the easiest and quickest was to outsource incident response services from a specialised external service provider. This will provide better assurance to the board and executive leadership, while also reducing the risk.
Implement projects: If the security dept., holds the budget it can keep projects on track or even create new projects that were not initially planned and will not require begging other departments for implementation. In addition, if there is insufficient project managers or staff (resources), if budget is available staff can be hired to accomplish the project.
Help others: Sometimes security can influence others and gain power by helping others.
Case study: In one the large banks, the Facilities department was discussing the deployment of radios but did not have the budget. I was managing another project in which radios were hired for a specified duration and before returning it back I gave it for the Facilities department to use it as much as they could for a month, and I handled the budget within my allocation. The result was that the Facilities department studied usage of radios freely and was able to select the best for them from the different models that I provided. This created a strong bond and trust from the Facilities dept., for future projects.
- Budget elements
It is important to identify elements for security and is not comprehensive.
Projects: Depending on the organisation and its maturity on security or business continuity, projects could vary in including security or continuity in the budget. However, in an organisations path to maturity, projects will include governance documents, security baselining, disaster recovery etc., at the minimal and at different levels and phases.
Technical configuration: Changing the technical configurations of system (e.g. network, application coding, hardening of devices) require time and effort which will cost for labour and tools including external consultancy, vendors and project management. This part of budget must be within security and not with the IT dept., because in practice this funding will be used for some other initiatives by the IT dept., and security will not be implemented. It is important to note that IT focuses on performance and delivery, and not security.
Training: General staff training budget may be allocated within the human resources or people and culture business unit, but for specific security training for selected groups and embed security within the culture, there should be separate budget allocated within the security department.
Testing: It would be good to have the cost of testing within security or business continuity or within Risk. However, for outsourced contracts and other vendor services it would be better to build the number of tests (e.g. penetration, incident response and disaster recovery) into contracts so that there will be no chance of cutting the cost later or including budgets separately.
Software/Tools: The cost of tools to help security or risk or business continuity software, if applicable could be a considerable amount must be included to achieve efficiency and effectiveness. These may include detection, monitoring and responding tools such as SIEM, IPS, IDS, DLP etc.
Standards & assurance: The cost of certifying for standards and the audit and consultation fee need to be separately allocated. Obtaining accreditation to standards does not make an organisation secure, however, it helps the organisation to be in the path of achieving the desired security setup. Assurance activities should also include third parties, which is on the increasing trend.
Conclusion:
Establishing an effective security setup and maintaining it involves obtaining sufficient funding. Having a reasonable budget within the security department can be used to gain power within the organisation and achieve security objectives easily for the betterment of the organisation.
Security budgets should not lead to overspending or underspending, instead security should be seen as enabling the business.
Factors that could influence funding needs to be identified and used based on the organisation setup and culture.
Depending on the organisation setup, culture and values, one of the two approaches for budget should be chosen and implemented for greater success in security.
About the author: Samuel Shanthan B.Sc.Eng. (Hons), MBCI, CPRM, CIPM, CISM
Samuel Shanthan has over 19 years of Information Security, Business Continuity and Risk related experience in large multinationals and fortune 500s, and has held global and national leadership roles. Currently based in Melbourne, he can be reached at Samuel.Shanthan@gmail.com.