#leadership – 370 Security Blog

Are We Peak CISO?

Let’s be honest…the CISO role is weird right now. It is going through a transformative phase and the industry is at an inflection point similar to what other C-Level roles (like the CFO) have gone through in the past. What makes the role weird? The CISO community and any company that has a CISO is facing unprecedented regulatory pressure, the economy and interest rates have people on edge, layoffs in the tech sector have shaken employee confidence (to the applause of investors) and technology innovation via AI is causing additional disruption and risk across all sectors.

In additional to these external pressures the past few years have seen the proliferation of CISO title sprawl and confusion from companies about how to best employ and utilize a CISO (hint, we aren’t your scapegoats). Despite all of this turmoil, change is also a time for opportunity and there are a few things I think will help clarify and mature the CISO role.

CISO Title Sprawl

I’ve been tracking job titles and job postings on LinkedIn for the past year or so and I’ve noticed a phenomenon I’ll call title sprawl. A quick search for titles shows there are vCISOs, Advisory CISOs, Fractional CISOs, CISOs In Residence and Field CISOs. On top of this, add in Chief Security Officers, Chief Trust Officers and Heads of Security. Do we need all of these titles? Maybe, but I think this title sprawl is more indicative of three things 1) People with CISO titles are in high demand and people want to retain the title once they get it and 2) Companies are still uncertain about how to title and employ someone to lead their security function. 3) Title sprawl is a result of the political power struggle occurring between the CISO role and other C-Level roles (more on that below).

From the titles above there are really only four functions for a current or former CISO – board member (in some capacity), executive management (officer of the company), consultant and sales. There is similar title sprawl and variance with CTO titles, but not to the extent of the CISO title (yet). Time will tell if other C-Level roles start to follow suit, but for now, let’s break down the functional CISO role buckets.

Board Member – These are current or former CISOs who sit on a board either as a technical advisor, business advisor or some combination thereof.

Executive Management – Individuals employed by a company to lead the information security program. May also manage other parts of IT such as identity, privacy, data, etc. Titles may be CISO, CSO, CISO in Residence (for Venture Capital), Chief Trust Officer and Head of Security.

Consultant – These are individuals who are providing their expertise as a current or former CISO to other companies to help them establish, transition or manage a security program. Often the companies employing these individuals claim they can’t afford a full time CISO, but they seem to be able to afford other full time C-Suite titles (hmm…)? Titles may include Virtual CISO (vCISO), Fractional CISO, CISO in Residence and Consulting CISO. (CISO in Residence again because they can “consult” to their VC holding companies about the state of their security programs).

Sales – These are people who are experts in the field of security, may hold one or more certifications and may be past CISOs. Their job is to help the company they work for drive sales. Typically the title they use is Field CISO or Advisory CISO.

Standardize The Reporting Structure

Moving on from title sprawl, companies are also confused about where the CISO title should sit. Some companies advertise it as a Director level role reporting into the VP of some function. Other’s title it as a VP level role reporting into a Senior VP or some other executive. Still other companies have the CISO reporting to the CEO, CIO, CTO or General Counsel. It is even possible this person is an individual contributor. Companies are clearly confused about whether the CISO is a technologist, regulatory compliance specialist or true C-Suite executive. While reporting structure may be a direct reflection on company culture, it is also a public example of the battle for equivalency that is playing out between the CISO and other C-Level roles. Often, CISOs are hired by other C-Levels (not the CEO) and until it becomes more common for CISOs to report to the CEO as an accepted peer to other C-Levels, this confusion and variance will persist. That being said, if you are considering a CISO title and the company isn’t willing to add you to the D&O liability policy then you may be better off taking a lower level title to eliminate personal risk.

Bolster Security Management Certifications

Security certifications from popular organizations talk a lot about regulations, risk and different security concepts (technical or not), but few, if any, offer a comprehensive certification on what it truly takes to be a CISO. Any CISO level certification should include potential career paths that lead to the CISO role, career paths post CISO role, difference in the CISO role based on company size, exposure to business topics in addition to security topics, SEC reporting, interfacing with law enforcement and lastly discussion of how to maximize success based on where the role sits – e.g. reporting to the CEO, CTO or CIO and how that may change your lens as a CISO. This begs the question if there should be a true professional level CISO certification similar to a professional engineer, accountant or lawyer, but let’s save that discussion for a future blog post.

Embrace Increased Regulation

Given the recent increase in regulation, particularly from the SEC, bolstering CISO certifications to include more business acumen may soon be table stakes instead of a nice to have. Recent regulations forcing companies to disclose material cybersecurity events in their 8k filings are starting to accelerate the maturity of the CISO role at publicly traded companies. Companies can no longer fail to invest in security or report breaches (unless they want steep penalties). In particular, this is forcing the CISO role into the board room or at least on par with other C-Level roles because they have to help these companies navigate the decision to report material events in their filings. Existing and future CISOs can embrace this increase in regulation to backstop their authority at companies who are struggling to fully embrace the CISO role as a C-Level executive. While it may not elevate the current role with a promotion, it should at least open the door to the board room and provide a seat at the table for discussion.

While CISO reporting structure may be a direct reflection on company culture, it is also a public example of the battle for equivalency that is playing out between the CISO and other C-Level roles.

The last point I’ll make about regulation is – while the SEC watered down the requirements for cybersecurity expertise on boards, I predict this expertise will still be required and in demand as companies start to navigate the new SEC reporting requirements. In particular, companies may be penalized and eventually required to demonstrate cybersecurity board expertise (via experience or certifications) if they are found to have a material security breach and can’t demonstrate appropriate security governance at the board level.

What’s The End Result?

It is clear the security industry and the CISO role are in a state of confusion as a result of the tight job market, uncertain economy, increased regulation and pace of technology innovation. The net effect of title sprawl and the struggle for equivalency is – it confuses customers, investors, partners, recruiters and job candidates. Title sprawl artificially increases competition for jobs and causes a wide variance in how the CISO role is employed. However, I think this state of confusion is a good thing because it is forcing conversations and causing people to stop and think. The CISO role is the newest member of the C-Suite and it is growing up and trading in the hoodie for a collared shirt. We are starting to claim our seat at the board level and are able to hold our own or make other C-Level roles redundant. As the CISO role evolves from a “nice to have” to a “must have” in the C-Suite, we will see this confusion fade away and the CISO role will truly reach its peak.

Security Theater Is The Worst

We have all been there…we’ve had moments in our life where we have had to “comply” or “just do it” to meet a security requirement that doesn’t make sense. We see this throughout our lives when we travel, in our communities and in our every day jobs. While some people may think security theater has merit because it “checks a box” or provides a deterrent, in my opinion security theater does more harm than good and should be eradicated from security programs.

What Is Security Theater?

Security theater was first coined by Bruce Schneier and refers to the practice of implementing security measures in the form of people, processes or technologies that give the illusion of improved security. In practical terms, this means there is something happening, but what that something is and how it actually provides any protection is questionable at best.

Examples Of Security Theater

Real life examples of security theater can be seen all over the place, particularly when we travel. The biggest travel security theater is related to liquids. TSA has a requirement that you can’t bring liquids through security unless they are 3 ounces or smaller. However, you can bring a bottle of water through if it is fully frozen…what? Why does being frozen matter? What happens if I bring 100, 3 ounce shampoo bottles through security? I still end up with the same volume of liquid and security has done nothing to prevent me from bringing the liquid through. As for water, the only thing that makes sense for why they haven’t relaxed this requirements is to prop up the businesses in the terminal that want to sell overpriced bottles of water to passengers. Complete theater.

“Security theater is the practice of implementing security measures that give the illusion of improved security.”

Corporate security programs also have examples of security theater. This can come up if you have an auditor that is evaluating your security program against an audit requirement and they don’t understand the purpose of the requirement. For example, and auditor may insist you install antivirus on your systems to prevent viruses and malware, when your business model is to provide Software as a Service (SaaS). With SaaS your users are consuming software in a way that nothing is installed on their end user workstations and so there is little to no risk of malware spreading from your SaaS product to their workstations. Complete theater.

Another example of security theater is asking for attestation a team is meeting a security requirement instead of designing a process or security control that actually achieves the desired outcome. In this example, the attestation is nothing more than a facade designed to pass accountability from the security team, that should be designing and implementing effective controls, to the business team. It is masking ineffective process and technologies. Complete theater.

Lastly, a classic example of security theater is security by obscurity. Otherwise known as hiding in plain sight. If your security program is relying on the hope that attackers won’t find something in your environment then prepare to be disappointed. Reconnaissance tools are highly effective and with enough time threat actors will find anything you are trying to hide. Hope is not a strategy. Complete theater.

What Is The Impact Of Security Theater?

Tangible And Intangible Costs

Everything we do in life has a cost and this is certainly true with security theater. In the examples above there is a real cost in terms of time and money. People who travel are advised to get to the airport at least two hours early. This cost results in lost productivity, lost time with family and decreased self care.

In addition to tangible costs like those above, there are also intangible costs. If people don’t understand the “why” for your security control, they won’t be philosophically aligned to support it. The end result is security theater will erode confidence and trust in your organization, which will undermine your authority. This is never a place you want to be as a CISO.

Some people may argue that security theater is a deterrent because the show of doing “security things” will deter bad people from doing bad things. This sounds more like a hope than reality. People are smart. They understand when things make sense and if you are implementing controls that don’t make sense they will find ways around them or worse, ignore you when something important comes up.

With any effective security program the cost of a security control should never outweigh the cost of the risk, but security theater does exactly that.

Real Risks

The biggest problem with security theater is it can give a false sense of security to the organization that implements it. The mere act of doing “all the things” can make the security team think they are mitigating a risk when in reality they are creating the perfect scenario for a false negative.

How To Avoid Security Theater?

The easiest way to avoid security theater is to have security controls that are grounded in sound requirements and establish metrics to evaluate their effectiveness. Part of your evaluation should evaluate the cost of the control versus the cost of the risk. If your control costs more than the risk then it doesn’t make sense and you shouldn’t do it.

The other way to avoid security theater is to exercise integrity. Don’t just “check the box” and don’t ask the business you support to check the box either. Take the time to understand requirements from laws, regulations and auditors to determine what the real risk is. Figure out what an effective control will be to manage that risk and document your reasoning and decision.

The biggest way to avoid security theater is to explain the “why” behind a particular security control. If you can’t link it back to a risk or business objective and explain it in a way people will understand then it is security theater.

Can we stop with all the theater?

What’s The Relationship Between Security Governance and Organizational Maturity?

Organizational and security governance is touted as a key component of any successful security program. However, I’ve been thinking about governance lately and how it relates to the overall maturity of an organization. This has prompted some questions such as: what happens if you have too much governance? and What’s the relationship between security governance and organizational maturity?

What Is Governance?

First, let’s talk about what governance is.

Governance is the process by which an organization defines, implements and controls the business.

Let’s unpack what this means for a security organization. The process of defining security for the business is done through policies, standards and guidelines. Security policies are requirements the business must meet based on laws, regulations or best practices adopted by the business. These policies align to business objectives. Implementation is done through security controls that are put in place to meet a specific policy or to manage a risk. Lastly, controlling the business is done via audits and compliance checks. The security org follows up on how well the business is following policies, implementing controls and managing risk. Control can also include enforcement, which can involve gating processes, such as requiring approval for business critical and high risk activities, or recommending additional security requirements for the business to manage a risk.

Why Do We Need Governance At All?

In an ideal world we wouldn’t. Imagine a business that is created entirely of clones of yourself. There would be implicit and explicit trust between you and your other selves to do what is best for the business. Communication would be simple and you would already be aligned. In this case you don’t need a lot (or any) governance because you can trust yourself to do the things. However, unless you are Michael Keaton in Multiplicity, this just isn’t a reality.

Governance achieves a few things for a business. First, it communicates what is required of its employees and aligns those employees to common objectives. Second, it helps employees prioritize activities. None of this would be needed if human’s weren’t so complex with diverse backgrounds, experiences, perspectives, education, etc. In an ideal world we wouldn’t need any governance at all. The reality is, we do need governance, but it needs to be balanced so it doesn’t unnecessarily impede the business.

How Does This Relate To Organizational Maturity?

Organizational maturity refers to how your employees are able to execute their tasks to achieve the objectives of the business. This relates to things like the quality of code, how quickly teams resolve operational issues or how efficiently they perform a series of tasks. It can be loosely thought of as efficiency, but I actually think it combines efficiency with professionalism and integrity. Maturity is knowing what good is and being able to execute efficiently to get there. There is a fantastic book about this topic called Accelerate: The Science of Lean Software and DevOps: Building High Performing Technology Organizations by Nicole Forsgren PhD.

Which brings us to the relationship of governance and maturity…

There is an inverse relationship between organizational maturity and organizational governance. In simple terms:

The less mature an organization, the more governance is needed.

For example, if your organization struggles to apply patches in a timely manner, continually introduces new code vulnerabilities into production or repeatedly demonstrates behavior that places the business at risk, then your organizational maturity is low. When organizational maturity is low, the business needs to put processes and controls in place to align employees and direct behavior to achieve the desired outcomes. In the examples above, increased governance is an attempt to manage risk because your employees are behaving in a way that lacks maturity and is placing the business at risk.

What causes low organizational maturity?

Organizational maturity is a reflection of employee behavior, skillset, knowledge, education and alignment. In other words, organizational maturity is a reflection of your organizational culture. In practical terms your employees may simply not know how to do something. They may not have experience with working for your type of business or in the industry you operate in. Perhaps they had a really bad boss at a past job and learned bad behavior. Whatever the reason, low organizational maturity is linked to lots of sub-optimal outcomes in business.

How To Improve Organizational Maturity?

If governance and maturity are inversely linked, the question becomes how can we increase organizational maturity so we need less governance? There are a lot of ways to increase organizational maturity. One that is fairly obvious is to start with a mature organization and maintain it over time. However, this is easier said than done and is why some organizations are fanatical about culture. This relates to everything from hiring to talent management and requires strong leadership at all levels of the company.

“The less mature an organization,
the more governance is needed.”

Other ways to improve organizational maturity are through training and education. This is why security awareness and training programs are so critical to a successful security program. Security awareness and training programs are literally attempting to improve organizational maturity through education.

One last way to improve maturity is via process. The security organization can establish a new process that all teams must follow. As teams go through this process you can educate them and reward teams that exhibit the ideal behavior by relaxing the process for them. You can also help teams educate themselves by publishing the requirements and making the process transparent. The challenge with imposing a new process is having the discipline to modify or remove the process when needed, which comes back to governance.

What’s the right level of governance?

The optimal level of governance is going to be based on your organizational maturity and desired business outcomes. In order to determine if you have too much or too little governance you need to measure organizational maturity and the effectiveness of existing organizational governance. There are industry standard processes for measuring organizational maturity, like the Capability Maturity Model Integration (CMMI) and Six Sigma, or you can create your own metrics. Some ways to measure governance effectiveness are:

Ask For Feedback On Security Processes – Are the processes effective? Do teams view them as an impediment or are they viewed favorably? Are the processes easy to navigate and objective or are they opaque and subjective?
Measure Effectiveness Of Security Controls – Are your security controls effective? If you ask a team to do work to implement a security control you should have clear metrics that determine if that control is effective. If you implement a control, but that control hasn’t changed the outcome, then the control is ineffective. This can indicate your governance is ineffective or your organizational maturity needs to improve.
Assess and Update Policy – Security policies should be living documents. They shouldn’t be set in stone. Security policies need to map back to laws and regulations they support and the business requirements needed to be successful. Laws, regulations and business requirements all change over time and so should your security policies. By having up to date and relevant security policies you can ensure your organizational governance matches the maturity of the business.

What Are Typical Scenarios For Governance And Maturity?

There are four scenarios related to governance and maturity:

A mature organization with too much governance – your organization is mature, but you are overly controlling with process and requirements. The net effect will be to slow down and impede the business unnecessarily. You are effectively lowering the organizational maturity due to too much governance.

An immature organization with too little governance – this is a recipe for disaster. If your organization is immature and you fail to govern the organization you will open the business up to unnecessary risk. You will get out maneuvered by your competitors, you will miss opportunities, you will fail to comply with laws and regulations and generally will have a lot of activity without any result. Your employees will lack coordination and as a result your business will suffer.

A mature organization with too little governance – This isn’t a bad scenario to be in. A mature organization implies they are doing the right things and don’t need a lot of guidance. A laissez faire attitude may be the right thing to allow employees flexibility and freedom, but it does come with inherent risk of not being compliant with laws and regulations. It may also mean there is duplication of effort or multiple ways of doing things, which could be optimized.

Governance and maturity are balanced – obviously this is the ideal scenario where your organizational governance is balanced to the level of maturity of the organization. Easy to think about in practice, difficult to achieve in reality.

Wrapping Up

Organizational governance and maturity are inversely related and need to be balanced in order for the business to operate effectively. There are ways to measure organizational maturity and governance effectiveness and by having a continual feedback loop you can optimally align both for success.

The Dichotomy Of Security

If you have ever read Extreme Ownership or The Dichotomy of Leadership by Jocko Willink, then you will be familiar with the concept of dichotomy and how opposing forces of a skill set can compliment each other. Mastering both sides can allow flexibility and increase the effectiveness of that skill set when dynamically applied to a given situation. This is true in the security space, where fundamental opposing forces need to be balanced in order to manage risk and achieve success. Let’s take a look at a few examples.

Security Extremes

The easiest example of the dichotomy of security is to look at the extremes. Security professionals jokingly say the most secure company is one that is not connected to the internet. While this may be true, it will also prevent the company from conducting business effectively and so the company will cease to exist and security will no longer be needed.

On the other end of the spectrum there is the extreme of a business that has zero security and so there are no impediments to conducting business. While this may sound great to some, the reality is the company will be unable to effectively conduct business because of the real threats that exist on the internet. In the situation the company will also cease to exist because they will be hacked into oblivion.

It is obvious there is a dichotomy between no security and no connectivity and these forces need to be appropriately balanced for a security program to be effective, while allowing the business to operate.

Manual vs Automated Security

Another example of dichotomy is between manual security tasks and automation. While every CISO I know is striving to increase automation of security tasks, the reality is humans are still going to be needed in any security program for the foreseeable future.

Manual tasks are ideal for situations where humans need to demonstrate creativity, intuition or make complex decisions based on subtle context. Security functions like penetration testing, threat hunting, red teaming and offensive security require high amounts of skill and experience that automation, like AI, hasn’t been able to replicate. Additionally, soft skills such as reporting to the board, shifting culture, building alliances and making prioritization decisions are all extremely complex and unlikely candidates for automation. However, while manual activities benefit activities that require a high degree of creativity, they are inherently slow and can impede the normal flow of business.

Recently, the advances in automation and artificial intelligence have exponentially increased their usefulness. Automation is extremely useful for offloading repeatable tasks that lend themselves to being programmatically defined. For example, attack simulation products have made huge strides in offloading repetitive tasks of reconnaissance, enumeration, vulnerability assessment and remedial exploitation. We are seeing additional advances in automation related to incident response where events can be correlated and specific activities in an IR playbook can be completed to offload analysts and help focus their attention. AI has also helped to offload lower level operational activities like call centers and help desk inquiries.

While automation may accelerate parts of the business and offload humans from repeatable tasks, it does introduce complexity, which can be difficult to troubleshoot or can cause outright failures. Automation is also rigid because it is only as good as the parameters of the process it is following. This means it can’t think outside of the box or demonstrate creativity. There is also the risk of introducing bias into your processes if your underlying model is flawed.

As you can see manual security processes and automated security processes are opposing forces that need to be balanced based on the skill of your security team and the needs of the business.

The Human Problem

The last dichotomy I want to discuss is the human problem in security. Humans are necessary because of their creativity, diversity and capacity for adapting to an infinite number of situations. However, the flexibility in human nature also presents one of the fundamental security problems – how to you protect against human nature?

The reality is humans are flawed, but in a good way. Threat actors can try to take advantage of these flaws, whether they are logical (like firewall rules) or physical (like human psychology). Humans are essential to every aspect of a business and so we have to figure out how to protect them. The most difficult balance in security is developing a program that is comprehensive enough to protect against human nature without stifling it.

The Security Ideal

The ideal security program will recognize the dichotomy of the security challenges it faces and balance them accordingly. The ideal security program balances security with flexibility. We are seeing this balance manifest in mature security programs via concepts like security guard rails and the paved path. The paved path and guard rails attempt to allow a certain amount of latitude for acceptable behavior, while being rigid enough to protect users and the business accordingly.

Application In Other Domains

The concept of dichotomy is universal across any domain. In fact, this is an area of extensive research in disciplines like mathematics, computer science, military strategy, and economics. Specifically, in the space of network and graph theory there is a concept call max flow, min cut. These are counter principles that are opposite, yet complimentary. If you think of any network (road, supply chain, computer network, etc.) the point of maximum flow across that network is also the point where maximum disruption (minimum cut) can occur. From a military or security stand point you will want to protect the max flow/min cut, but from an attacker stand point, the max flow / min cut, is the area that will require the least amount of effort for maximum damage. Pretty neat!

Wrapping Up

An effective security program will balance the needs of security with the needs business with the ultimate goal of effectively managing risk. A critical skill for any security practitioner is to be flexible and adaptive. Specifically, by recognizing that security issues have two sides to them, security practitioners can demonstrate empathy towards the business and find an appropriate balance that can protect without impeding the business.

Exploring The Advantages and Disadvantages of Centralized vs. Decentralized Teams

This blog post is part of the Compliance Corner Series developed in partnership with Milan Patel. This series includes a variety of discussion topics around the intersection of security and compliance. The series includes blog posts, live web streams (with Q&A) and podcasts.

What is more effective – A decentralized or centralized security and compliance team? What are the factors you need to consider, what are the pros and cons of each model, does company size matter, are they simply analogs of organizational maturity or should leaders consider one model over another model for their org?

When leaders are creating or maturing their organization should they consider a centralized or decentralized organization structure?

Lee: If you have the opportunity to create or modify your organization I personally prefer a centralized organization structure. This is because it concentrates the roles, responsibilities and authority for security into a single function that can offer governance and all of the additional expertise expected of a security organization. The rest of the business knows where to go and who to talk to for all security issues. I have seen problems arise in both decentralized and heavily matrixed organizations because it confuses the roles and responsibilities of the function. Who is actually responsible for making security decisions if major parts of security are spread out across the organization? Sharing resources doesn’t really work very well because it is confusing for the individual team members and when sharing resources one side typically loses out to the other side. I have also seen shared resources get mis-used or repurposed for things other than security. This doesn’t mean the security team can’t place resources in different parts of the org, but they should report into and be owned by the security function. In my opinion whoever is responsible for the budget and the headcount truly controls that resource and decentralizing the budget and headcount causes problems.

Milan: Business leaders must first consider what role they want their compliance organizations to have. Will their compliance team actually offer governance, or just auditing? Are they going to cover corporate policies, or just audit frameworks that attest to customer reports? These are important scope questions to answer before setting up (or maturing) a compliance organization. It can drastically change how you fund and scope skills for the team, and whether a decentralized team will meet the overall risk management and corporate goals.

Investment size must also be considered, I get that question all the time, “How much should a business invest in compliance?”. I have seen everyone from flat personnel-project based funding, to actual percent of overall business operations spend. I focus on scope first, as then you can directly cost out what the deliverables/responsibilities are. Governance will drive a big factor of centralized or decentralized teams. Governance requires authority, charter, and appropriate level of independence to actually hold teams accountable. In a decentralized model, governance becomes much more difficult, as the fox ends up guarding the hen house.

Does company size, organizational maturity or other factors influence the decision to have a centralized vs. decentralized organization?

Lee: Company size can definitely influence the initial decision to create a centralized or decentralized function. Smaller organizations or startups may not be able to justify the initial cost of a dedicated security leader and may lump this responsibility under the CIO, CTO or Chief Counsel. As a result the security function may initially grow as a decentralized function until the organization decides it is either time to offload the original leader or they realize they need more specific security leadership and it is time to build out a dedicated function.

Organizational maturity can also impact the decision. Immature organizations may struggle to effectively use decentralized resources and so the weaker the organizational culture the more a centralized security organization will make sense. However, in really large organizations it is common to see a hybrid approach which I like to call a federated model. In a federated model you have a centralized security organization that sets policy, governance, manages risk, makes decisions and has all the authority for anything security. Business units within the large company then staff specific security resources based on expertise for specific industries or to help navigate their specific security and regulatory requirements. This can be advantageous in terms of presenting a single view of overall risk, consolidating processes and leveraging economies of scale for purchases to get a better price for tools or contracts used for security across the organization.

Milan: Company size, and breath of products, can definitely influence the model. In smaller companies, there will likely be less resourcing (and complexity) to consider, which makes a centralized model more affordable and practical. You are not going to have much ability to fund a larger team (and wouldn’t likely need it), so a centralized model pretty much is the only option.

In larger companies, decentralization is used (and we’ll talk about advantages and disadvantages later), but the better model is hub and spoke. A strong central team, chartered with governance, but small “spoke” compliance teams that are the boots on the ground in the team. Small presence that can keep engineering on track, participate in design reviews, threat model reviews, and know enough to ensure that engineering teams and products are on the right track from the start. They also can drive best practices for that team, but they are based on the central team requirements, and can escalate to the central team (that ideally has a governance charter) to ensure adherence at the right senior level.

What are the advantages and disadvantages of each model?

Lee: Centralized models offer consolidation of budget, resources, governance, responsibility and authority. It presents a single function that the rest of the business can go to for anything security related. Centralized models are typically more efficient because it avoids each group having to create and duplicate resourcing, tooling and processes. The one downside of a centralized model is if the security organization forgets that the rest of the business is their customer then it can become extremely difficult to interact with that group who effectively becomes a gatekeeper for business progress.

Decentralized models can offer some initial advantages when companies are extremely small. This is typical during startups or when you are operating in a mode where everyone is doing a lot of different jobs. However, this usually isn’t sustainable long term. I also find people who operate in this mode usually can’t scale to a larger organization where more governance is required. Decentralized models are also more prone to duplication of resources, technology and processes because there isn’t a single leader coordinating strategy and investment. Decentralized functions can also run into problems where the resources are misused or go “native” and stop performing the intended security role. Decentralized functions may end up with different levels of maturity across the different groups in the organization, which can make it difficult to obtain compliance certifications or to standardize processes and technology for a unified approach to security.

Milan: In general, a centralized structure offers the best overall coverage and governance. You can set consistent policies and practices across multiple organizations, which inherently will reduce risk as it’s easier to ensure consistency, and accuracy with one process vs many. You also can provide more controls to validate continuously that processes are working, plus attest much easier. Continuous compliance in a cloud environment is basically the norm now, but not all organizations, especially those with a decentralized model, can effectively ensure compliance of many regulations that come in and now must be enforced at the corporate level, and not just at the product level.

You also reduce cost, as having one set of compliance experts is cheaper, and can provide more optimization of skills. In a decentralized model, you end up having to hire more individuals, as you must replicate specialized skills in multiple areas.

One aspect that is often overlooked in centralized vs decentralized is pricing power. For compliance, for instance, you can collective bargain auditing to drive better prices in a centralized model. In a decentralized model, every team is determining it’s own bidding and metrics, which basically allows for suppliers to cost every team as individuals, reducing the overall negotiating power of the company. In a decentralized model, you usually also have more junior leaders (as the team and overall scope is smaller), and that dilutes the overall governance credibility, as they are not truly objective, as again, this can give the impression of the fox guarding the hen house.

Is there a clear winner here or is this more of a dogmatic approach / “it depends” type of answer?

Lee: Obviously there is always an “it depends” type of answer, but I personally think a centralized team offers far more advantages than a decentralized team. I have operated in decentralized teams, startups, and heavily matrixed organizations and they have all had incredible inefficiencies, process problems, lack of technological standardization and contention between the leaders in control of the different resources. While anyone can demonstrate leadership, the reality is there can only be one leader for a function. If you want to build a strong and effective security organization my personal recommendation is to avoid the decentralized model and strongly advocate for a consolidated, centralized function for all of the reasons I listed above.

No matter what size your company is, at some point your business will get big enough that it will either need to transition to or will need to build a centralized security org. Even when your company gets truly massive a centralized security organization will offer tremendous advantages for coordinating the rest of the functions across the business. This doesn’t mean you can’t have specific expertise embedded within the different lines of business, but there should be one overarching function that sets strategy, governance and has the authority to coordinate everything related to security across the organization.

Milan: I am going to lead off with a “it depends”, but “it depends” on what the SLT wants the function of the Compliance team to be, and how they want them to operate. For example, if they want what they “should” want. Corporate SLT should want an independent compliance organization that has the charter and weight to actually drive governance and accountability. Any decisions made by an engineering leader where the compliance team reports directly to them will be suspect if there is an issue, as how can compliance be seen as impartial if the decision can be overturned by the product or engineering leader directly? Did the right conversation happen, does that decision align with similar decisions with other product groups/lines of business? It can be a real problem if there is an issue and companies have to explain.

That is very difficult in a decentralized model. In a decentralized model where the compliance team, which has to drive hard messages and needs to engineering leaders, are they truly independent and will they speak up, as they tend to be mostly more junior, without any real organizational or peer power with the teams they are supposed to govern? The answer I’ve seen is rarely. I’ve seen and worked with many compliance teams that are frankly afraid to raise issues, or particularly escalate (and if they would escalate, who would they escalate to, as it would be their own management that signs their pay stubs). I’ve seen it both on the compliance and security side, where even mid level leaders will not raise or push issues, as they are worried for their jobs. It’s very difficult to find compliance teams and leaders that can truly be “politically unencumbered” in terms of raising issues, when they report to the fox that likely already doesn’t like having to do compliance work.

I believe that a strong and chartered central team, made up with the right personnel that understand engineering and can translate, and govern engineering compliance practices is the overall best option, particularly for larger organizations where standardization and efficiency must be improved. In a large company, compliance “spokes” with specific charter are important, as it’s the only way to scale the appropriate knowledge down to the teams.

What Causes CISO Burnout?

Burnout isn’t exclusive to the security industry, but it certainly seems like there is a higher incidence of burnout within security and particularly among CISOs. I have had my fair share of burnout and have tried a lot of different techniques to recover, however for this post I want to cover – What are the most common causes of CISO to burnout?

Lack of Appreciation

There are a number of reasons for burnout, but one of the main causes is lack of appreciation. This could be something as simple as celebrating the successes of the security organization more broadly or it can be more complex like advancement to the next level within the company. Given the broad range of CISO levels across the industry, advancement is certainly one of the issues that can manifest as lack of appreciation. For example, I see a lot of head of security positions or CISO level positions posted as Director or Sr. Director level positions. While this may make sense from an organizational standpoint it can put the CISO role at an inherent disadvantage compared to their other peers (like the CTO, CIO, etc.). Celebrating the successes of the CISO, acknowledging their contributions and promoting them to the appropriate level based on their scope and impact is one of the first ways you can reward a CISO, acknowledge their value and prevent burnout.

Lack of C-Suite Support

Another main reason for CISO burnout is the lack of equivalent C-Suite support. If the CISO isn’t supported by their peers and is always at odds with them, this will lead to burnout very quickly. Being on an island all alone is no fun, particularly when dealing with complex issues like security or when attempting to change behaviors across the organization. A CISO needs support and the C-Suite needs to be aligned to the overall security goals of the organization otherwise the rest of the organization will undermine the CISO. Without this support the CISO will spend all of their time just battling for political relevance instead of actually identifying and managing risk and this will lead to burnout.

Too Many Responsibilities

This can vary depending on organization size, but it is not uncommon to see a CISO with additional responsibilities such as Privacy, Data, Risk, Compliance, etc. all in their remit. Typically a CISO does deal with these things, but the organization has to be careful to not lump things under the CISO just because there is no one else to do it. The CISO organization shouldn’t be the janitor or garbage dump for the rest of the org and they shouldn’t be the place where all the misfit toys go. If the organization is going to lump additional responsibilities onto the CISO then those responsibilities need to come with support in terms of additional budget or resources. In addition to responsibilities and resources, the CISO needs to understand their strengths and weaknesses and delegate accordingly. Otherwise, the CISO will take on too much, not be able to scale and burnout.

Operational Burnout

Operational burnout is a big problem. If your operational tempo requires the CISO to constantly deal with incidents, respond to investigations, answer regulatory questions, deal with lawsuits, etc. then the CISO won’t be able to focus on other parts of the job like driving strategy, managing risk or prioritizing resources. Instead, they will constantly be reacting to situations which causes stress and takes a toll on personal health. Operational tempo can be difficult to manage, particularly if the CISO organization is understaffed, which means the team can’t maintain normal working hours. Personal care, such as maintaining normal routines to eat, sleep, exercise and decompress, can be seriously impacted if not managed properly during operational situations and this will lead to burnout extremely quickly.

Another area of operational burnout is constantly dealing with vulnerabilities, keeping up with the the latest trends, dealing technical debt or responding to increased reporting requirements. All of these scenarios have a never ending aspect to them and can cause the CISO to begin to feel like the situation is hopeless.

Risk Tolerance Misalignment

This is a very common area of frustration for CISOs and it boils down to not feeling appreciated. If the CISO is constantly making reasonable recommendations for how to manage risk and the business ignores them then there is clearly a risk tolerance misalignment, which will ultimately make the feel CISO unappreciated. To be clear, I’m not expecting every recommendation to be followed because you don’t want to get into a chicken-little type of scenario, but the CISO needs to have enough organizational credibility that the recommendations are acknowledged, considered and discussed. Organizations that don’t do this will rapidly find their CISO burned out and seeking other opportunities because you can only be ignored so many times before taking the hint and moving on.

Shiny Object Syndrome

At the next conference you go to, take a look around at the vendors and read their messaging. I bet you find it is hard to tell the difference between several of the companies there. Buzzwords like threat intelligence, machine learning, block chain, artificial intelligence, next generation, zero trust, etc. all hype up companies with buzz words, but remove differentiation for decision makers like CISOs. Keeping up with the Gartner Hype Cycle and the latest product buzz words is tiring because CISOs really just want to know what your product does and if it will be useful to solve their problems. Continually having to sift through the noise of buzzwords and hype is exhausting to CISOs and can burn them out quickly to dealing with vendors.

On the other side of this equation is technological churn. If your organization is continually implementing new tools and then replacing them after a short period this can also cause burnout. A security function needs a certain amount of stability and predictability to be effective. Shiny object syndrome from executive leadership or other parts of the business can make it difficult for a security team to find their natural rhythm or implement effective processes around those tools. Shiny object syndrome can quickly burn through the credibility or effectiveness of a CISO, which can ultimately lead to burnout.

Impossible Goals

It takes a considerable amount of effort for a new CISO to make their mark, effect change and achieve their goals at a new organization. This effort alone can cause CISOs to burn out, but it is made worse when the organization has impossible expectations or sets impossible goals for the CISO and their team. Examples of impossible goals are – achieving a compliance certification within an impossible timeframe, improving security posture when there is a significant amount of technical debt or trying to meet expectations for response times without appropriate staffing. The CISO needs to set realistic goals and have the latitude to adjust those goals as needed to avoid burning out.

Lack Of Accountability

The last situation that is sure to cause burnout for a CISO is lack of security accountability in the rest of the organization. If the business expects the CISO function to magically fix all of their security problems without support then that is unrealistic. The business (think CEO) needs to hold the other C-Suite members accountable for supporting and meeting the security objectives set by the CISO. If this accountability is not in place then other parts of the business will keep making decisions that increase risk or incur security technical debt, which places the CISO in an impossible situation and will cause burnout.

Wrapping Up

Burnout is an unfortunate byproduct of an otherwise exciting industry. CISOs are particularly ripe for burnout due to the immaturity of the role with respect to other C-Levels and the wide range of responsibilities that can be lumped under a CISO. Additionally, industry hype, lack of resources, lack of accountability and operational tempos can all cause CISOs to burn out. A CISO who is burned out is not as effective at their role and the level of burnout will take a proportional level of recovery. Hopefully, the examples above can help you recognize common situations to avoid or if you find yourself in that situation, recognize that it will quickly lead to burnout so you can make proactive changes and keep leading your team effectively.

The Most Powerful Word A CSO Can Say Is No

A Tale Of Two Extremes

A few weeks ago I was sitting across the dinner table from a CIO and a CISO who were discussing how security works within their specific businesses. The CIO was complaining that the security team had unreasonable processes that slowed down his ability to deliver new technology projects within his org and as a result he ignored a lot of their requests. This resulted in an engaging discussion about the best way to balance security requirements against the needs of the business. I found it interesting that some of my fellow CISOs were adamant about having teams meet security requirements without exception, regardless of the impact to the business.

After this discussion I spent some time thinking about own my stance on this issue and how I have tried to balance security requirements against the needs of the business over the course of my career. I pride myself on finding ways to partner with and support the business, instead of just telling them no all the time. However, I have also found that sometimes the most powerful word in my vocabulary is NO. Saying no is particularly useful during the rollout of new processes or security controls where you are changing behavior more than you are implementing a new technology.

Tug Of War

Security requirements and business needs can often be in a perpetual tug of war. This isn’t necessarily a bad thing when you consider the purpose of a CISO organization is to help protect the business not only from attackers, but often from itself. However, it can be difficult when the tug of war is biased towards one side or the other. If the business simply steam rolls and ignores all security requirements then clearly the CISO isn’t valued and the business isn’t interested in managing risk. However, if the CISO says no to everything, then this can be a significant and costly drag on the business in terms of people, processes, technology and time. Lost productivity, lost revenue, inability to deliver a product to market quickly can be difficult to measure, but have real impact to the business. Worse, the business may just ignore you. It is important for CISOs to find an appropriate balance to allowing the business to function, while meeting the desired security objectives to protect it. I firmly believe when done correctly, CISOs can avoid being a drag on the business and can actually enable it.

Just Say No

Despite my general inclination to find ways to keep the business moving forward, I’ve also found saying no to certain things can be extremely useful. For some things, when teams want an exception I usually say no as my initial response. I have found often teams just need to hear an exception isn’t an option and this unblocks them to pursue another alternative to the problem. As a result the teams improve their security while also delivering their business objectives.

Sometimes the teams will ask for an exception a second time. In these cases, I usually reconsider, but often still tell them no. My expectation after telling them no a second time is to either get them to fix the issue or if the issue can’t be fixed to present a plan with different options along with their recommendation. When teams come back for the third time it ends up being an actual business risk discussion instead of an exception discussion. The outcome usually ends up being some sort of compromise on both sides, which is exactly what you want. Taking a balanced approach develops an appropriate level of partnership between security and the rest of the business where one side isn’t always sacrificing their objectives for the other side.

Seriously, Just Say No

Next time a team comes to you with an exception request try saying no and see if they respond differently. You may or may not be surprised when they find an alternate solution that doesn’t require an exception. For me, it has become a powerful tool to nudge teams towards achieving my security goals, while still delivering on their business objectives.

Leadership During An Incident

At some point in your CSO career you are going to have to deal with and lead through an incident. Here are some things I have found helpful.

Know Your Role

Unless you work at a very small company, I argue your role is not to be hands on keyboard during an incident. You shouldn’t be looking up hashes, checking logs, etc. Your role is to coordinate resources, focus efforts and cognitively offload your team from key decisions. You need to lead people during this chaotic event.

Declaring An Actual Incident

This may vary depending on company size and type, but in general the CSO should not be the one to declare a security incident. The CSO (and their representatives) can certainly advise and recommend, but declaring an incident carries legal, regulatory and business ramifications that should be made by a combination of the Chief Legal Counsel and some representation of C-Suite members (CEO, CTO, etc.). Once an incident is declared, your company will most likely need to disclose it on SEC forms and customers may need to be notified. All of this could impact your company’s reputation, stock price and customer goodwill.

Use A War Room

A war room is simply a place where everyone can gather for updates, questions, etc. It is a place that is dedicated to this function. If you are physically in the office, it is a dedicated conference room that has privacy from onlookers. If you have a virtual team it is a Zoom, Teams, WebEx, etc. that gets created and shared with people that need to know.

The CSO’s role in the war room is to keep the war room active and focused. Once the war room is created and the right people join, everyone should discuss what happened, what is impacted and what the course of action should be. Document this somewhere and pin it to the appropriate channels. If people join and start asking basic questions, send them away to read the existing documentation first. If people want to have a detailed technical discussion then send them to a breakout room. The point is to keep the main room clear for making decisions and directing resources.

Bridge The Gap

Your role during an incident is two fold – 1) Communicate to other leaders within the company about what happened so you can get the appropriate support to resolve the incident and 2) Direct the appropriate resources to focus on resolving the incident quickly, while following appropriate chain of evidence, legal requirements, customer notifications, etc.

Communicating To Executive Leadership and the Board

Keep it short and sweet so they can respond as needed. The purpose of this email is to inform them so they can give you the support you and your team need. Make sure to invoke legal privilege and keep the audience small (I discuss this in my post about Legal Privilege).

I use the following email template when communicating about an incident.

Subject: PRIVILEGED – Security Incident In [Product/Service X]

A security incident was detected at [Date / Time] in [product x] resulting in [data breach/ransomware/etc.] At this time the cause of the incident is suspected to be [x]. Customer impact is [low/medium/high/critical].

The security team and impacted product team are actively working to resolve the incident by [doing x]. This resolution is expected [at date / time x].

For any questions please reach out to me directly or join the war room [here].

Next update to this audience in [x time period].

Communicating To Responders

Your job here is to get the team any resources they need, offload them from decisions and then get out of their way. It is also important that you buffer them from any distractions and protect them from burnout by enforcing handoffs and reminding people to take breaks. It is easy for your team to get caught up in the excitement and sacrifice their personal well being. Learn to recognize the signs of fatigue and have resource contingency plans in place so you can shift resources as needed to keep the overall investigation and response on track.

Designate someone to help coordinate logistics like meeting times, capturing notes, etc. Capture action items, who owns the action item and when the next update or expected completion time will be.

Have A Backup Plan An Practice Using Them

Hope for the best and prepare for the worst. Can your incident response team still function if your messaging service is down? What if your paging program doesn’t work or you can’t stand up a virtual war room? Part of your incident response playbooks should include fallback plans for out of band communications in the event of a total disruption of productivity services at your company. Practice using these during table top exercises so everyone knows the protocols for when to fall back on them if needed.

Wrapping Up

Incidents are both exciting and stressful. It is up to the CSO to lead from the front and provide guidance to their team, executive leadership and the rest of the organization. CSO’s need to buffer their teams to allow them to focus on the task at hand, while protecting them from burnout. CSO’s also need to remember the conduct and response of the organization could be recalled in court some day so following appropriate evidence collection, notification guidelines and legal best practices are a must.