Author: Lee Vorthman

I'm a U.S. Navy veteran and the Global Chief Security Officer (CSO) at a Fortune 100 cloud company where I've built a successful security program from the ground up and have partnered with the business to increase trust and reduce risk. I have over 25 years experience across a wide variety of industries such as technology, government & defense, education and oil & gas. I hold a number of professional certifications such as, EC-Council's Certified Chief Information Security Officer (C|CISO), Digital Director's Network (DDN) Board Certified Qualified Technology Expert (QTE) and ISC(2) Certified Information Systems Security Professional (CISSP). Previously I was the Chief Technology Officer (CTO) for Civilian Agencies and Cybersecurity Initiatives at NetApp U.S. Public Sector and the Chief Information Security Office for an Oil & Gas software company. I am available for consulting and speaking opportunities. Thoughts and opinions are my own and do not represent any employer past or present.

Defining Your Security Front Door

A key skill for any security program is to partner with and enable the business to be successful. CISOs need to ensure their security teams are approachable, reasonable and most importantly balancing the needs of the business against potential security risks. While security teams exist to help protect the business, they don’t own the business systems or processes and as a result need to adopt an advisory or consultative role with the rest of the business to ensure success.

With that in mind, the way the rest of the business finds and engages with the security team can create a good first impression or can set the tone for a difficult interaction. Think of a house that has great curb appeal – it feels inviting and gives the impression that the owners take good care of their property. The same concept exists for the security program, which I call the Security Front Door.

The Front Door Concept

The security front door defines how the rest of the business engages with and interacts with the security team. The front door can be a confluence page, slack channel with pinned information, or some place that is easily discoverable and accessible. Your security front door should clearly lay out information and resources so the rest of the business can either self serve or easily request and receive help when needed.

What Should Be In Your Front Door?

The front door for your security program should include ways to perform the most commonly requested actions from the security team. For example, you probably want really clear ways to request the following:

Report an incident
Request vulnerability remediation help
Request an exception
Request an architectural review
Dashboards
Discover documentation for policies and processes
Other – a general way to request help for anything else

The front door is not just a way to make a good first impression and enable the business, but when set up correctly it can actually offload the security team and help the business move faster.

Wrapping Up

The front door is a great way to engage with the business to help them move faster, find information and request assistance from the security team. When done correctly it can allow the rest of the business to self serve and can actually offload the security team by reducing the volume of requests that come in. Setting up the security front door may require a lot of up front work, but by understanding the rest of the business, their key pain points and most commonly requested security asks, you can design a front door that will be a win-win for everyone.

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.

Career Options Post CISO

Last year was a busy year for CISOs. Increased regulation from the SEC and other entities are raising the stakes for companies and CISOs. 2023 demonstrated that regulators and law enforcement are not only going to hold companies accountable for incidents and breaches, but they will also pursue accountability against individual CISOs. The CISO role is at an inflection point created by new technologies, increases in regulation and unprecedented personal risk. Given the high stakes of the role I think we are going to see an exodus in the number of people who are willing to shoulder the burden and personal liability of this role. Which begs the question: what are the options for someone after serving in a CISO role?

Serving On A Board

Serving on a board seems like a popular choice lately and now that the SEC has mandated cybersecurity experience on the board I think companies will look to increase their board membership with former CSOs and CISOs. The challenge with serving on a board is finding one that can compensate you sufficiently. I’ve served on several boards over the past 15 years and the compensation will depend on the company size and maturity. Start ups are typically able to offer compensation in the form of equity in the company, but this may turn out to be worthless if the company doesn’t make it. Big company board positions are few and far between, but will pay the best. My advice for CISOs looking to transition into a paying board position is to serve on a board or several boards in your spare time and then transition to become a full time, paid, board member if and when the company can support it.

Advisory CISO / CISO In Residence

One way to “float” between a CISO role and a board member role is to get connected with a Private Equity (PE) or venture Capital (VC) company as an Advisory CISO or CISO In Residence. These roles help the PE and VC companies evaluate potential investments and then help guide the companies to success. If you are an Advisory CISO you can evaluate the companies and if you see one you think has real potential you can choose to be their CISO or serve on their board. Advisory CISOs are not only compensated by the PE / VC company, but they “consult” to the investment companies on a periodic basis and sometimes they are offered the opportunity to invest in the companies they are advising. Not a bad gig.

Consultant

One of the most common post C-Level career paths is to become a consultant. If you are well connected, are in a critical industry or are just great with people, this can be a viable career option. The experience you have built up over your career still has value and companies will pay you handsomely for your time to help advise them. If you work for a company that is unwilling to protect you if you are sued then this may be a way to continue in a CISO capacity, but without the personal risk. I’ve known people who have quit their current role out of frustration and when the company realizes the expertise they are about to lose they hire the person back as a consultant.

Field CISO

Field CISOs are fancy titles for people that are in sales or pre-sales. They typically have a specific region they are assigned and they use the Field CISO title to establish executive relationships with other CISOs and C-Suite members to help sell products and services. Field CISOs typically have extensive industry experience in a particular vertical and then they use that expertise to help tailor solutions to their customers.

Title Change (But Still Security)

Another option post CISO role is to get a title change, but still work in a security related role. This could be something like a Chief Trust Officer or Chief Risk Officer. These roles can offer more flexibility to have a positive impact on the business because they aren’t constrained by the same expectations as a CISO role. At the end of they day you are still a C-Level security executive and can continue to advance your career towards your goals.

Role Change (Not Security)

CISOs are one of the few roles that touch every aspect of the business. As a result, CISOs are well versed in a lot of different business disciplines and it would be easy for a CISO to transition to a CTO, CIO, engineering executive or product executive. For example, a CISO who is looking to exit the role may look to join a security focused startup as their CTO. Their deep industry experience and past credentials will provide credibility and allow them to continue working in the security space in a different capacity. Eventually, they can even hire a CISO to report to them and have oversight over the security function.

Start A Company

CISOs are also well positioned to see gaps in the industry where a solution hasn’t been developed. Lots of well known companies have been formed by former security executives who have left their role to start a company to develop a security related product or service. Starting a company doesn’t mean you have to develop a new technology. You could also start a consulting company, a training company or a staffing company. If you are sitting on a great idea then this is a viable option for you.

Double Down

Lastly, if you enjoy the CISO role, but don’t feel supported or protected by your current company, then find a new CISO role that gives you the support and protection you seek. Part of the interview process for your new role should include questions about who the role reports to, what is the expected budget and headcount, will the role be included in the D&O Policy, what happens if you are personally sued, what is the severance package and how will success be measured? These should all be table stakes for any company looking to hire or retain a CISO and satisfying these requirements will go a long way to making your CISO feel comfortable that you have their back and won’t treat them as a scapegoat.

2023 End Of Year Review & 2024 Look Ahead

At the start of 2023 I created personal and professional goals for myself to speak at conferences more, attend more professional events and capture my professional experience in a series of blog posts. In this post I’ll share what worked, what didn’t and how my results compared to my goals. At the end I’ll discuss what my goals are for 2024

Blogging (and Podcasts)

Just before 2023 kicked off I created this blog, primarily to capture my experience as a way to give back to the industry and to catalog my professional experience as a historical reference for myself. The two biggest lessons learned are: just get started and be consistent.

Just Get Started

I talked to a lot of people in 2023 about this blog and a surprising number confessed they also wanted to write a blog or create a podcast, but hadn’t started for a number of reasons, such as:

“I’m not a good writer”
“Nobody wants to hear what I have to say”
“I don’t have time”
“I need to get permission”

It is easy to hide behind these excuses and never start so my advice is to stop procrastinating and just get started. No one cares if your grammar isn’t perfect or if your content isn’t perfect. If you need permission, then track down who can approve your content and remove that barrier. Getting started will allow you to iterate, try new things and learn how to get better. The only way you will be able to get started is to set some ground rules for yourself. I personally found I work best by setting aside time on the weekend to write a post and then reward myself with some screen time such as video games or a movie. I also found that I write better when I have an idea and start writing it as soon as possible. If I wait, I often forget my thought process and then don’t write about that topic. Lastly, I found keeping a running idea log on my phone worked well. Whenever I have an idea I write it down in the idea log with as much context as possible, often creating a rough outline on the spot. Then when I get in front my my computer I can fill in the rest of the post.

Be Consistent

My goal in 2023 was to write one blog post or LinkedIn post a week. This felt sustainable without being a massive time commitment every day that would distract from my day job. My secondary goal was to increase my number of readers, followers and connections both virtually and in person. Being consistent is the best way to accomplish all of these goals. I was most consistent when I set aside time on the weekend to write for a few hours before rewarding myself with another activity. I found writing a post on the weekend or during the week allowed me time to refine it before posting it. I also relied heavily on scheduling posts, which allowed me to write several posts when I felt inspired and then post them when I was ready. This also allowed me some wiggle room if I was sick or traveling. By being consistent you continually pop up in people’s feeds and the social media algorithms will begin to recommend your content to people, which will increase your follower base.

So How Did I Do In 2023?

At the start of 2023 I set a goal to write one post per week. On this blog I achieved 38 posts and a combined 94 LinkedIn posts (which includes the blog posts). I started 2023 with 2010 followers and 1938 LinkedIn connections. I now have 2392 followers and 2091 connections. In general I connect with anyone on LinkedIn, but I do prune the connections if people try to sell me stuff or abuse the connection. Overall, I saw a 20% increase in followers and an 8% increase in connections and I’m very happy with these results.

Networking Events

I attended dozens of networking and industry events in 2023 and these spawned tons of additional follow on meet ups. If I meet someone new at an event, I try to connect with them on LinkedIn and then meet up for coffee or drinks to get to know them better. The top events I attended in 2023 were:

Gartner Evanta CIO / CISO Summits
HMG Strategy Denver Summit
Colorado=Security CISO Dinner Series

Public Speaking

One of my 2023 goals was to get back on the public speaking circuit. There are a few security related conferences in Denver with the top one being the Rocky Mountain Information Security Conference. In 2023 I gave a talk at RMISC about “A CISO Primer On Legal Privilege,” which gave a high level overview of legal privilege and had great audience discussion around the topic. I also spoke at a smaller, more intimate conference put on by BrainGu called RS². This conference wasn’t security specific, but it did have a wide variety of speakers and thought leaders. The smaller conference setting allowed for great networking opportunities and I met a lot of great people there. Lastly, in July 2023 I met Hunter Muller of HMG Strategy as part of being nominated as a 2024 CISO of the Year. At the HMG Denver Summit I spoke on a panel with 3 other CISOs about “Innovation in Cybersecurity”. The HMG conference was a fantastic opportunity to meet other technology executives and hear their lessons learned.

Other Activities

In 2023 I explored joining a few new advisory boards. I’ve been on the CIO/CISO Advisory Board for the Denver Gartner Evanta community for the past few years, but at the end of 2023 I was also asked to join the HMG Denver Advisory Board. I also joined the advisory board of Phoenix Security and the STAR network for 1011 Venture Capital. My goal in all of this is to expand my network, keep up to date with industry trends and give back to the security community.

In addition to advisory boards I also explored doing video blogs and podcasts with other leaders. Most notably, Milan Patel and I have been doing a series of video blogs about the intersection of security and compliance. This has been great to cross pollenate our ideas and also draw from a different pool of followers.

2024 Look Ahead

I had a busy year in 2023 and am very happy with my results. So what’s in store for 2024?

Continue the blog with a focus on being more timely with hot topics. My most popular posts were the ones that discussed my thoughts on topics that had immediate relevance in the news or industry.
Do more blogs, podcasts or webinars with other industry leaders.
Submit to speak at conferences. I’ll plan to continue to submit to speak at RMISC, a Gartner Evanta event and an HGM Strategy Summit. If another opportunity pops up I’ll definitely write a post about it.
Explore joining additional advisory boards. I am enjoying advising various companies and industry groups on how to navigate the complex cybersecurity market. My experience as a CISO, CTO and lifelong technologist provides perspective so I can help guide these groups to be successful.

Opsec During Incidents

When I first got into Information Technology over 20 years ago, I started out in networking and data centers. When doing work, we always made sure to have another method of accessing our gear in case a configuration change didn’t work and eliminated access to the equipment or environment. Also, during my military service we would always discuss what would happen in a worst case scenario and have contingency plans in case something went wrong. I’ve carried these principles over into my security career and they have served me well. Given the high likelihood that we are all operating in some type of compromised environment, I think it is good to cover how these principles can be used to maintain operational security during incidents.

Philosophy

Hope for the best, prepare for the worst

No battle plan withstands first contact with the enemy

Train how you fight

There are a lot of things you can do to prepare for a security incident such as, running table top exercises, preparing playbooks and modifying tool sets, but there is an important area that I think is often overlooked during preparation. There is an implicit assumption that all of the fancy tools and environments you have prepared will be available when the incident kicks off. If you are preparing for your incidents with this assumption then you could find your team in trouble. One key component of a realistic table top scenario is to remove capabilities and see how the team reacts. This could be something as simple as saying the incident commander is no longer reachable or something more drastic like not being able to access your SIEM. The point is, the more worst case situations you can prepare for, the better off you will be during a real incident. Here are a few things you should consider to maintain operational security and the ability to respond.

Access To Playbooks

Playbooks are a critical tool for responding to an incident. Incidents can be highly stressful and playbooks exist to help your responders remember all of the steps, access methods, processes, tools, etc. they need to successfully respond. What would you do if an incident kicked off and you couldn’t access your playbooks? Does your team have these playbooks stored in an alternative environment? Do they sync them to an offline, physical storage device that is stored in a safe or passed between people on call?

Playbooks need to not only be accessible via alternate methods, but they also need to be protected. What if the attacker had access to your playbooks? I’m willing to bet your playbooks have a detailed list of all the things your team will do to respond and this can be a useful blueprint for an attacker to follow to avoid detection or expand their footprint. I highly recommend encrypting your playbooks and vaulting the credentials so you can monitor and control access as needed.

Access To Tooling

Tooling is also essential during the incident response process. Tools help teams investigate, gather evidence and ultimately recover from the incident. Access to tools and scripts can help with a number of activities such as, identify hashing algorithms, identifying password encryption types, scanning for open ports or scanning for vulnerabilities. Tools that are useful during incident response should be stored in an image or container that is updated regularly and kept in an offline environment. This will help the incident response team in a few ways. First, it will make sure all of the necessary tools that are needed in the playbook are available even if systems and network access isn’t accessible. Second, it avoids having to pull tools from the internet that haven’t been vetted. In a stressful situation like an incident it is possible to overlook small details that could make your situation worse, such as downloading a tool that has a trojan or backdoor in it. Lastly, it is important to control the flow of information during an incident. If your team is using online tools as part of the investigation they could be leaking information to the internet that can reveal details about the incident, which could not only derail your investigation, but could harm your company brand and reputation.

Another consideration for tooling is how you plan to preserve evidence if you are under active compromise. Having pre-staged environments that are isolated and only used for incidents can be useful. Similarly, having tooling available to image machines, quarantine networks or even encrypt files to send them to an alternate cloud / storage provider can all be useful during an incident.

Access To Communications

Communication during an incident is key. I like to set up a standing War Room where people can come and go as needed. My presence is there to make decisions and help direct resources where they can be most useful. In the chaos of an incident it is important to make sure you have primary, secondary and sometimes even tertiary communication methods available. What happens if Zoom or WebEx is down and you can’t stand up a virtual war room? Do you have access to a call sheet so you can get a hold of everyone and stand up a conference call? What would you do if your primary chat method such as slack or teams wasn’t available or was compromised? Do you have Signal or Wickr set up so you can still chat with your team?

Additionally, I highly recommend you copy legal on your incident communications so they can advise you accordingly (see my post on Legal Privilege). I also recommend you encrypt your communications, which can help protect your comms if you are operating in a compromised environment.

Access To People

Lastly, but probably the most important, is access to your people. People are essential when responding to an incident and running table tops to prepare them is essential. Cross training should also happen regularly in case an expert in a specific skill isn’t readily available. Ultimately, the more training and cross training your team has, the better prepared you will be for an incident.

Conducting table top drills and running through failure scenarios can be fun and also educational. Next time you run a table top exercise take out your top person and see how the team reacts. Put people on the spot in different roles such as investigation, evidence gathering, recovery, interfacing with engineering, etc. If someone struggles with a role during the table top you can flag that area for additional training.

Leadership is also essential during an incident and I’ve written blog posts about this in the past. Try rotating people in different leadership positions so they can get a feel for what it takes. This can also help them understand and anticipate what is needed from them during an incident.

Wrapping Up

Incidents can be both exciting and stressful at the same time. The thoroughness and frequency of your training will dictate how well your team responds during an incident. Most importantly, planning for various worst case scenarios can ensure your team is able to successfully respond, communicate and lead the rest of the business through an incident.

Will CVSS 4.0 Help Companies Manage Vulnerabilities Better?

About two weeks ago FIRST published version 4.0 of the Common Vulnerability Scoring Standard (CVSS), largely in response to feedback from the industry on the shortcomings of CVSS 3.1 and previous versions. The main complaint from industry with version 3.1 was that it didn’t offer any way to add additional context in a way that could help determine and prioritize risk. This led to companies to come up with their own processes to add context. In a previous blog about The Problem With Vulnerability Scanners I specifically highlighted how CVSS scores weren’t very useful and needed additional business context to make a risk prioritization decision. With that in mind, CVSS 4.0 attempts to address these shortcomings. Let’s take a look at what they changed and if it will help.

What’s New?

Both CVSS 3.1 and CVSS 4.0 include ways to evaluate vulnerabilities using the intrinsic characteristics of the vulnerability (Based), how the vulnerability changes over time (Temporal v3 or Threat v4) and how the vulnerability specifically applies to your environment (Environment). New for v4 is a Supplemental section which doesn’t impact the CVSS score, but allows you to add additional context for the vulnerability.

Additionally, CVSS 4.0 promises the ability to add real time threat context by allowing teams to use Threat Intelligence as an input to the CVSS score for a vulnerability. This additional context can be provided in new sections such as Attack Complexity, Attack Requirements, Vulnerable System and Subsequent System. CVSS 4.0 attempts to acknowledge unique environments by allowing additional fields for things like safety, ICS systems, etc. You can read about the full CVSS 4.0 specification here.

Finally! A Way To Prioritize Vulnerabilities!

CVSS 4.0 definitely seems like a huge step towards allowing teams to provide additional context to a vulnerability with the ultimate goal of influencing the score for better risk prioritization. The most common complaint I hear from engineering teams is there are too many vulnerabilities with the same criticality and they are unsure where to start. This was also feedback provided by industry to FIRST because it seemed like vulnerabilities were clustered more towards the critical and high range after the changes from v2 to v3.

CVSS 4.0 definitely answers some of the previous shortcomings and allows teams to add additional context to help make better decisions about which vulnerabilities should be prioritized for remediation over others. I know it is fairly common for the top priority to be given to external, publicly facing systems. The problem was CVSS 3.0 didn’t really provide a way to delineate between internal and external systems very well. So overall, the changes introduced in v4 are very welcome and should help teams really focus on what matters.

Is More Choice A Good Thing?

While it may seem like a good thing to be able to adjust the CVSS score for a vulnerability I do see this causing issues, particularly with external reporting. Security teams will need to have a robust process documented for how they are adjusting the score of a vulnerability and I can see situations in the future where companies are accused of subjectively adjusting their vulnerability scores down to paint a better picture than the reality.

Additionally, more choice comes with less transparency. Over the past year I have seen the volume and complexity of security questionnaires increase. The top questions focus around vulnerability remediation SLAs, incident response times and software supply chain security. Adding additional complexity into the CVSS scoring process, that allows companies to subjectively adjust the score up or down, will be extremely difficult for customers and regulators to navigate. Think back to Log4j and the reaction from your customers if you said you had Log4j vulnerabilities, but weren’t prioritizing remediation because they were on internal systems only. This may be a reasonable risk response for the business, but the perception from your customers will be difficult to manage.

Time Will Tell

Overall, it seems like CVSS 4.0 is attempting to become more of an overall risk score, rather than just a severity score. It is certainly welcome to be able to add additional context and take additional input to adjust the CVSS score as it applies to your environment and business. However, the new standard adds additional complexity and subjectivity that will make it difficult for customers and regulators to assess the true risk of a vulnerability to the business in a common way across the industry. Security teams will need to be particularly diligent in documenting a robust process for how they are adjusting the CVSS score to avoid being accused of arbitrarily adjusting the CVSS score down to make their company look better.

Chief Incident Scapegoat Officer (CISO)?

Last week the SEC filed a complaint in the Southern District of New York charging SolarWinds and specifically its CISO, Timothy Brown, with fraud. According to the compliant, the SEC alleges the company and Brown made false statements about its security posture to investors. Along with the Uber CISO, Joseph Sullivan, this is the second CISO in the past year to be specifically charged for failing to do their job. In my opinion, these court cases are going to negatively impact the CISO role and make security less transparent to investors. Let’s dive in.

What About The Other C-Levels?

Both cases are unique, however the first thing that stands out to me is only the CISOs are being named and charged. I find this odd because in an ideal organization the CISO still has to partner closely with the other C-Level execs to achieve security objectives. Things like external messaging to customers, SEC filings, etc. all require the coordination and knowledge of other C-Level execs like the CFO, Legal, Marketing and even the CEO. Why aren’t these individuals being named and charged for also contributing to the fraud?

In the worst case scenario, a CISO is poorly supported and struggles to get any of their security objectives funded or implemented. Is the CISO to blame in this scenario? What about the CEO and CFO who withheld funding? How about the Engineering leader who failed to prioritize the security recommendations of the CISO? The point is, I have never found a situation where a CISO is able to operate in a vacuum and so the other C-Level execs also have a responsibility to make sure the company is making true statements and not perpetrating fraud. They should all be held equally accountable.

Responsibility Without Authority

The CISO role has had a lot of press and a surge in visibility over the past few years, but the role still has a long way to go to be on par with other C-Level roles. It is common for the CISO role to report to the CTO, CIO or Chief Legal Counsel. It is uncommon for the CISO role to have a direct reporting line to the CEO. We can discuss who the CISO should report to, but in my opinion, the CISO role still needs to mature compared to the other legacy C-Level roles. The position is currently not on the same level as a CTO or CIO role and this impacts the scope and authority of the role.

Additionally, most CISOs don’t actually own the things they are trying to improve the security posture of. There is always a business or engineering owner that is actually responsible for building and operating the systems that make the company money. As a result, the CISO role typically ends of with all of the responsibility for security, but none of the authority. If the CISO makes a recommendation to fix something and the engineering leader rejects it, who is held accountable for that decision?

Chilling Effect On Open Discussion

My biggest concern with the SEC complaint is the reference to emails that are pointing out the known security issues with the Orion system. Matt Levine wrote a great article in Bloomberg questioning the SEC’s logic and I agree with his assessments. I have never read an SEC filing or investment statement expecting the company to highlight their massive security investments. In fact, I would question if a company should disclose that in a filing at all (unless it is material) because you may inadvertently provide information to attackers that could be used to hack the company.

Additionally, most security teams openly discuss security issues via chat or email. I find these discussions are almost always expressing frustration with current situations with the goal of gaining support for investment to remedy the issue. However, discussions via chat and email also happen to be legally discoverable forms of communication. This means every single email about how much your security sucks will be taken out of context by lawyers and used against you. The obvious solution is to never put your current security failings in writing, which means you can never create a presentation to convince the company to invest in improving security. Or alternatively, if you do place things in writing you frame them in a way that they are asking for legal advice so they can be protected by legal privilege.

Predictions For the CISO Role

I wrote a blog post after the Uber verdict, but both the Uber and SolarWinds cases have caused significant anxiety within the CISO community, which I think will impact the CISO in the following ways going forward:

New CISOs hiring into a role will require companies to list them on their Directors and Officers (D&O) Liability Policy. Also, based on this Bloomberg Law Article about FTX, I recommend making sure the D&O policy specifies how much you will get if all the executives are trying to use the policy at the same time for legal fees.
It will become standard for companies to cover the costs for legal counsel specified by the CISO, should they be individually named in a lawsuit.
As these cases become more common, CISOs will demand higher compensation and protect themselves contractually to minimize their personal risk.
Companies will (hopefully) prioritize security investments to minimize the risk of lawsuits, regulatory actions or security incidents.
Costs for companies to employ and retain a CISO will go up over time.
In extreme cases, the CISO role may shift from a salaried employee to a consultant (I-9) to offload the accountability for security to the company and protect themselves.

Final Thoughts

I can’t recall the last time I saw a CTO or CIO charged with investor fraud for making false statements about their products or enterprise environment. Yet, the CISO role has been getting a lot of scrutiny from regulators recently. I’m all for holding people accountable, but the CISO role doesn’t seem to carry the same weight as the CTO or CIO. The role still struggles with gaining support and funding to place security first. If a company culture is weak or the other executives minimize security, then the CISO will fail to make any meaningful progress. In my opinion, if the CISO of the company is named, then all the officers should be named to drive home the message that they are all accountable for the security of the company.

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.

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.