Culture – 370 Security Blog

Navigating The First 90-180 Days In A New CISO Role

Late one Friday afternoon a call comes in and you find out you landed your next CISO role. All the interview prep, research, networking and public speaking has paid off! Then it dawns on you that you could be walking into a very difficult situation over the next few months. Even though the interview answered a lot of questions, you won’t know the reality of the situation until you start. How will your expectations differ from reality? What can you do to minimize risk as you come up to speed? How should you navigate these first 90-180 days in your new role?

Prior To Starting

Let’s assume you have some time to wind down your current position and you are also going to take some time off before starting the new role. During this transition period I highly advise you reach out to your peers in the new role and start asking questions to get more detail about the top challenges and risks you need to address. Start with the rest of the C-Suite, but also get time with board members and other senior business leaders to get their perspectives. Focus on building rapport, but also gather information to build on what you learned during the interview process so you can hit the ground running.

You can also use this time to reach out to your CISO peers in your network who are in the same industry, vertical or company type to get their perspective on what they did when they first joined their company. Learn from their experience and try to accelerate your journey once you start. Keep the lines of communication open so if you run into a situation you are unsure of you can ask for advice.

Once You Start

Build Relationships

First and foremost, start building relationships as quickly as possible. Target senior leadership first, such as board members, the C-Suite and other senior leaders. Work your way down by identifying key influencers and decision makers throughout the org. Play the “new person card” and ask questions about anything and everything. Gain an understanding of the “operational tempo” of the business such as when key meetings take place (like board meetings). Understand the historical reasons why certain challenges exist. Understand the political reasons why challenges persist. Understand the OKRs, KPIs and other business objectives carried by your peers. Learn the near and long term strategy for the business. Start building out a picture of what the true situation is and how you want to begin prioritizing.

Understand the historical reasons why certain challenges exist. Understand the political reasons why challenges persist.

Plan For The Worst

Don’t be surprised if you take a new role and are immediately thrown into an incident or other significant situation. You may not have had time to review playbooks or processes, but you can still fall back on your prior experience to guide the team through this event and learn from it. Most importantly, you can use this experience to identify key talent and let them lead, while you observe and take notes. You can also use your observation of the incident to take notes on things that need to be improved such as interaction with non-security groups, when to inform the board, how to communicate with customers or how to improve coordination among your team.

Act With Urgency

Your first few months in the role are extremely vulnerable periods for both you and the company. During this period you won’t have a full picture of the risks to the business and you may not have fully developed your long term plan. Despite these challenges, you still need to act with urgency to gain an understanding of the business and the risk landscape as quickly as possible. Build on the existing program (if any) to document your assumptions, discoveries, controls and risks so you can begin to litigation proof your org. Map the maturity of security controls to an industry framework to help inform your view of the current state of risk at the company. Begin building out templates for communicating your findings, asks, etc. to both the board and your peers. Most importantly, the company will benefit from your fresh perspective so be candid about your findings and initial recommendations.

Evaluate The Security Org

In addition to the recommendations above, one of the first things I like to do is evaluate the org I have inherited. I try to talk to everyone and answer a few questions:

Is the current org structure best positioned to support the rest of the business?
How does the rest of the business perceive the security org?
Where do we have talent gaps in the org?
What improvements do we need to make to culture, diversity, processes, etc. to optimize the existing talent of the org?

Answering these questions may require you to work with your HR business partner to build out new role definitions and career paths for your org. You may also need to start a diversity campaign or a culture improvement campaign within the security org. Most importantly, evaluate the people in your org to see if you have the right people in the right places with the right skillsets.

A Plan Takes Shape

As you glide past the 90 day mark and start establishing your position as a trusted business partner, you should arrive at a point where a clear vision and strategy is starting to take shape. Use the information you have gathered from your peers, your program documentation and your observations to start building a comprehensive plan and strategy. I’ve documented this process in detail here. In addition to building your program plan you can also begin to more accurately communicate the state of your security program to senior leaders and the board. Show how much the existing program addresses business risk and where additional investment is needed. I’ve documented a suggested process here. Somewhere between your 90 and 180 day mark you should have a formalized plan for where you are over invested, under invested or need to make changes to optimize existing investment. This could include restructuring your org, buying a new technology, adjusting contractual terms or purchasing short term cyber insurance. It could even include outsourcing key functions of the security org for the short term, until you can get the rest of your program up to a certain standard. Most importantly, document how you arrived at key decisions and priorities.

Take Care Of Yourself

Lastly, on a personal note, make sure to take care of yourself. Starting a new role is hectic and exciting, but it is also a time where you can quickly overwork yourself. Remember building and leading a successful security program is a marathon not a sprint. The work is never done. Get your program to a comfortable position as quickly as possible by addressing key gaps so you can avoid burning yourself out. Try to establish a routine to allow for physical and mental health and communicate your goals to your business partners so they can support you.

During this time (or the first year) you may also want to minimize external commitments like dinners, conferences and speaking engagements. When you start a new role everyone will want your time and attention, but be cautious and protective of your time. While it is nice to get a free meal, these dinners can often take up a lot of time for little value on your end (you are the product after all). Most companies have an active marketing department that will ask you to engage with customers and the industry. Build a good relationship with your marketing peers to interweave customer commitments with industry events so you are appropriately balancing your time and attending the events that will be most impactful for the company, your network and your career.

Wrapping Up

Landing your next CISO role is exciting and definitely worth celebrating. However, the first 90-180 days are critical to gain an understanding of the business, key stakeholders and how you want to start prioritizing activities. Most importantly, build relationships, act with urgency and document everything so you can minimize the window of exposure as you are coming up to speed in your new role.

Is Agile and DevOps Holding Back Your Security Program?

There are a variety of development models you can run into as a CISO. If you are in the defense or government sector your engineering teams will probably use something like waterfall. However, if your company produces software products or services then most likely your organization uses Agile or SAFe and DevOps as the core development methodologies. Most companies have shifted to Agile over the past decade due to the ability to break work into smaller chunks, iterate and get products to market faster. They have also shifted to DevOps, where the teams that build the thing are also the team that operates and maintains it. However, there are some disadvantages to using Agile and DevOps methodologies and as a CISO you should be familiar with the negative aspects and how to deal with them.

When DevOps Isn’t

If your engineering and development teams aren’t very mature, or if there is an imbalance between engineering, product management and sales, your Agile development and DevOps models can become skewed too far towards new feature development at the expense of all else. If this happens the security organization will find it difficult to inject security priorities into the sprints. This can cause a build up of tech debt, which can heavily impact security roadmaps.

For example, if one of your main development platforms needs to be upgraded to the latest version in order to make a new security feature available, then this will need to be prioritized and planned for within the sprints. Ideally, you can do this upgrade without any down time, but that isn’t always the case. If dev teams don’t have any slack in their sprints for operational maintenance, such as upgrades, refactoring code, improving observability, improving reliability or practicing good fundamentals, then tech debt will build up over time and the security org will find it difficult to advance their roadmap and effectively manage risk.

If you are finding your dev and engineering teams aren’t allowing enough time for DevOps activities then it is worthwhile to go back to the fundamentals and develop a RACI for who is responsible for the different tasks required to operate and maintain your products and services. Set clear expectations and metrics to measure teams. Often, when the DevOps model is broken there is a weak sense of ownership and dev teams need to be reminded that they need to maintain the things they build. You may also need to spend time with your Chief Product Officer, Chief Technology Officer or your Chief Revenue (Sales) Officer to set expectations and get their support to change the behavior of the engineering teams and how they interact with product or sales. Ultimately, good reporting that can reveal patterns of behavior, backlogs, tech debt and lack of fundamentals will go a long way to articulating the problem set and enlisting the support of the rest of the C-Level to fix the broken DevOps model.

When Agile Becomes An Excuse

Similar to the example above, Agile methodologies can become an excuse for engineering teams to not prioritize security requests such as code fixes, library updates, software patches and vulnerability remediation. Your security org may start to recognize this problem if the engineering teams never insert your activities into the sprints or if they over estimate how long it will take to complete your security request (a common delaying tactic).

When Agile becomes an excuse for dev teams it can help to have security champions or product security specialists that embed with the engineering teams to champion security priorities and make sure they get included in the appropriate sprint to hit the milestone or deadline. Often, engineering teams just don’t understand the activity and having a security expert embedded in the team can help remove the FUD (fear, uncertainty and doubt) and get the teams comfortable with including and completing security priorities. Once this muscle gets exercised enough and the engineering teams are showing consistent performance, the security champions can move on to another team that needs more help.

When dev teams are using Agile as an excuse there can be a variety of reasons such as lack of maturity or over prioritization of features over all else. This is where good metrics such as sprint velocity, capacity and estimation accuracy can help. Measuring these metrics over time and discussing them at the executive level can help identify teams that need help or are consistently under performing. This can be important for a CISO who is trying to get security priorities inserted into the team. Understanding where an engineering team is on the maturity scale and using clear metrics to report on their performance can help shift priorities as needed.

One thing you absolutely should not do as an executive team is assign engineering teams percentages of work, such as “spend 20% of your time on security activities”. This is a recipe for disaster because unless the work going into the 20% is clearly agreed on, engineering teams may use any type of work they think is security work to include in the 20%. This will cause a serious disconnect between security and the engineering teams because engineering will point out they are spending 20% of their time doing security stuff, but security won’t be getting the priorities they need. Instead of assigned percentages, it is better to have dynamic sprints where work is pulled in based on their priority with clear criteria, such as risk or revenue, that can help teams fill their sprints appropriately.

When MVP Isn’t Good Enough

Lastly, Agile is a really good methodology for building products that can iterate and develop functionality over time. It is rare that these are mission critical products and instead are products that are launched with a small feature set or core service that expands in functionality over time. However, when it comes to mission critical products, like security products, Agile and the MVP (minimum viable product) just won’t cut it. The reality is unless you have a really robust MVP, you will most likely need a GA (general availability) of the product before it has the type of functionality you need for your security program. Understanding the limitations of Agile and how to negotiate when you will get the features you need is important for organizations that build their own products internally or for organizations that partner closely with external companies to build custom products or develop products in tandem.

Whenever I interface with a team that plans to build a security product internally or with a company that is developing a custom product for my group I make sure I am extremely clear about the features and functionality I need before I will adopt the product. Often, I will compare the product in development with other existing products or I will perform extensive testing of the new product based on real world scenarios. However your security team decides to verify and validate the new thing, make sure your requirements are clear and your testing is repeatable. Document every decision and for external partners consider contract language that can protect you if the full functionality of the product or service isn’t working after you buy. Most importantly, don’t buy or renew based on promises from an external partner. If it doesn’t exist when you buy, it will be tough to get them to prioritize your requests after you hand over the check.

Wrapping Up

I’ve covered a few scenarios where Agile and DevOps can go wrong and ultimately hold back your security program. If this happens it is important to recognize the behavior and develop tactics to correct the issue. This can involve setting expectations with your C-Suite counterparts, developing clear RACI models with engineering teams or clearly documenting functionality required for a security purchase. Whatever the issue, measuring and monitoring performance will help to articulate any issues you run into and build strong relationships between security and the engineering (DevOps) teams.

Should Security Be An Approver For IT and Business Requests?

Over the course of my career I have consistently seen security in the approval chain for various IT operations and business requests, such as identity, network and even customer contracts. Having security in the approval chain may seem logical at first glance, but it can actually mask or exacerbate underlying operations issues. Having a second set of eyes on requests can make sense to provide assurance, but the question is – does it make sense for security to be an approver?

Understand The Scope of Your Security Program

First and foremost, the scope of your security program will ultimately dictate how and when security should be included in an approval process. For example, if security owns networking or identity, then it will make sense to staff an operations team to support these areas and it will make sense to have security as an approver for requests related to these functions.

It may also make sense to include security in the approval chain as an evaluator of risk for functions security doesn’t own. For example, security won’t own the overall contract, finance or procurement processes, but they should be included as an approver to make sure contract terms and purchases align to security policies and are not opening up the business to unnecessary risk. They can also be included in large financial transfers as a second set of eyes to make sure the business isn’t being scammed out of money. In these examples, security is creating good friction to slow critical processes down in a healthy way to make sure they make sense and to use time as a defense mechanism.

Other Benefits Of Security As An Approver

Including security as an approver for general IT processes can have other benefits, but these need to be weighed carefully against the risks and overall function of the business. For example, security can help provide an audit trail for approving activities that may create risk for the company. This audit trail can be useful during incident investigations to determine root cause for an incident. It can also help avoid compliance gaps for things like FedRAMP, SOC, etc. where some overall business or IT changes need to be closely managed to maintain compliance. However, creating an audit trail is not unique to the security function and, if the process is properly designed, can be performed by other functions as well.

Another advantage of including security in the approval chain is separation of duties. For example, if one team owns identity, and they are requesting elevated privileges to something, it can present a conflict of interest if they approve their own access requests. Instead, security often acts as a secondary reviewer and approver to provide separation of duties to make sure requests by a team that owns the thing isn’t approving their own requests.

Where Including Security As An Approver Can Go Wrong

The biggest issue with having security in the approval chain for most things is they typically are not the owner of those things. If approval processes are not designed properly (with other approvers besides security), then the processes can confuse ownership and give a false impression of security or compliance. For example, I typically see security as an approver for identity and access requests when security doesn’t own the identity function. At first glance, this seems to make sense because identity is a critical IT function that needs to be protected. However, if security doesn’t own the identity function (or the systems that need access approved), how do they know whether the request should be approved or not. Instead, what happens is almost all requests end up being approved (unless they are egregious) and the process serves no real purpose other than creating unnecessary friction and giving a false sense of security.

Another issue I have seen with including security in the approval chain is they effectively become “human software” where they are manually performing tasks that should be automated instead. Using security personnel as “middleware” masks the true pain and inefficiency of the process for the process owner. This takes critical human capital away from their intended purpose, is a costly solution to a problem and opens up the business to additional risk.

When Does It Make Sense For Security To Be An Approver?

I’ve listed a few examples where it makes sense for security to be an approver for things it doesn’t own – like large financial transactions, some procurement activities and security specific contract terms. However, I argue security shouldn’t be included as an approver in most IT operations processes unless security actually owns that process or thing that needs a specific security approval. Instead, the business owner of the thing should be the ultimate approver and processes should be designed to provide appropriate auditing and compliance, but without needing security personnel to perform those checks manually.

One of the few areas where it will always make sense to have security as an approver is for security exceptions. First, exceptions should be truly exceptional and not used as a band-aid for broken or poorly designed process. Second, exceptions should be grounded in business risk, while documenting the evaluation criteria, decisions, associated policies and duration. This is a core security activity because exceptions are ultimately evaluating risk and deviation from policy. I’ve written other posts about how the exception process can have other benefits as well.

Wrapping Up

Don’t fall into the trap of using your security team as a reviewer and approver for IT operations requests if security doesn’t actually own the thing related to the request. This places the security team in an adversarial position, can be a costly waste of resources, masks process inefficiencies, gives a false sense of security and can open up the business to risk. Instead, be ruthlessly focused in how your security team is utilized to make sure when they are engaged it is to perform a function that is at the core of their mission – protecting the business and managing risk.

Following SnowFlake, Cloud Providers Need To Shift To Secure By Default

In May 2024, SnowFlake experienced a data breach as a result of exposed credentials that allowed a threat actor to access customer accounts that weren’t secured with MFA. The fallout from this data breach ultimately impacted large SnowFlake customers like Ticketmaster, AutoZone, Santander Bank and AT&T. Following the announcement of the breach, SnowFlake implemented refined security measures to avoid similar incidents in the future. However, the question remains why aren’t publicly accessible cloud companies secure by default?

A Pervasive Stigma Against Security

Before we can answer the question about why companies aren’t secure by default, we need to look at the underlying psychology and motivation for companies and in particular the arguments that are made against implementing security.

Startup Mentality

One of the most pervasive (and quite frankly horrible) arguments against building in security by default is the “move fast and break things” mentality that is pervasive at startups. Startup life is a tough one and a good metaphor is you are building your parachute as you are falling. Either you succeed and live, or you burn in and cease to exist. The problem with startup mentality is when you succeed and live, most startups fail to to shift from survival mode to maturity mode as the company grows and matures.

In maturity mode, companies need to resolve all of the debt they incurred just to survive. This can be operational debt, technical debt or security debt. Unfortunately, if the survival mentality persists, this debt continues to accrue and can kill the company because the cost to continue to operate exceeds the incoming revenue.

Security Is Bad For Productivity

Another argument that frequently pops up against implementing security is the perception that security is bad for productivity. I find this argument particularly ironic since employees seem willing to tolerate bad processes, bad experiences and other examples of bad friction, yet they complain the loudest about new security controls (like being required to change their password periodically). My own opinion about this perception is employees are largely indifferent to security (or in general they think it is a good thing). However, security often results in very visible changes to processes and ways of working and it is the change that employees don’t like. They associate security with change and since change is bad, security is bad.

This is similar to the argument that security increases friction and the assumption that all friction is bad. While this assumption is not only false, it also leads to the thought process that any friction in the customer experience will lead to lost customers and sales. The reality is some friction is good and acts as safeguards to steer people towards a desired (secure) outcome.

Security As An Upsell

One last reason for failing to implement security by default is when companies choose to profit from security as an upsell (I’m looking at you Microsoft). By charging extra for the most useful or best features these companies are implicitly and explicitly placing a cost on adding in security, which is perpetuating the stigma that security is bad.

The reality is some friction is good and acts as safeguards to steer people towards the desired (secure) outcome.

Changing Perception

Leading research for high performing cultures indicates teams that are able to effectively prioritize and execute on all of their demands are the highest performing teams. In particular, teams that were able to incorporate security into their processes actually went faster and performed better, than teams who struggled with or ignored security altogether. If you want to read more on this you can check out Accelerate by Nicole Forsgren, PhD.

One other thing we can do to change this negative perception of security is to stop allowing members of the security function introduce bad friction. We have all experienced bad friction in the form of time wasters, security theater and the dreaded “no”. This behavior doesn’t help the mission of security and perpetuates the stigma against our profession.

Default Opted-In

Assuming companies can overcome the startup mentality, successfully incorporate security into their development processes and overcome the stigma of security as being bad, what should they be doing to make their products and services secure by default?

The first thing companies can do is discard the notion that increased security will inhibit sales or drive customers away. Instead, companies should use security as a selling point and configure their services to be secure by default, which means customers will need to go through some sort of initial security setup when they purchase the product or service. Customers that don’t want to do this will need to explicitly opt-out or seek alternate providers, firmly placing the liability for not meeting security best practices on their shoulders.

Enforce Security Best Practices

What security functionality should companies offer by default to their customers? Here is a short list:

Multi-Factor Authentication – including the option for OTP, secure tokens and passkeys.

Encryption – all data and transport protocols should be encrypted by default with the latest versions available.

Access Control and Detection – default deny for access to resources and make customers explicitly allow access. This includes making resources non-public by default until a customer specifies otherwise. Detect changes in the state of resources and notify customer contacts of abnormalities.

Easy Button For Fundamentals – make it easy for customers to pull a comprehensive asset inventory, control their instance or tenancy with a master account and offer simple reports for ways they can improve their security posture.

Wrapping Up

There a lots of reasons why security becomes an afterthought for companies. Often, it is because they fail to shift from survival mode to maturity mode. Other times, their culture persists the notion that security has a bad stigma and inhibits the business. Some companies even upsell customers on security functionality, which limits the adoption of security controls. The reality is companies that practice secure by design and incorporate security into development cultures move faster and outpace their competition. Companies that offer publicly available software and services need to shift their mentality to make security a default setting that is turned on at the onset of the relationship, like any other core product feature. Until companies start making security default opt-in, we will continue to experience massive data breaches like the one from SnowFlake.

How CIOs, CTOs and the rest of the C-Suite Can Better Support CISOs

There are a variety of reporting structures for CISOs, such as reporting to the CTO, CIO, CFO or CEO. No matter who the CISO reports to, the CISO is still an integral part of the C-Suite. Yet despite this, CISOs don’t always receive full support from the rest of their C-Suite peers, which can cause friction and open up the business to risk. In this post I’ll cover how the rest of the C-Suite can better support their CISO peers and how doing so will actually help them achieve their goals as well.

Strategic Planning

First and foremost, the CISO needs to be included in strategic planning sessions about new markets, mergers and acquisitions (M&A), divestitures, new product launches and new customer types. Each of these areas will create new security risks and regulatory requirements that can have lengthy lead times for addressing. The CISO needs to be informed about product roadmaps, new features and new technology initiatives. If the CISO and security group are left out of these strategic discussions the business could be forced to delay a new business opportunity or worse enter the new opportunity without properly managing the risks.

Master The Fundamentals

Second, CTOs and CIOs need their teams to master and execute on the fundamentals. This means things like asset inventory, logging, observability, QA, QC and operations support (event notification and cost analysis). The reality is the rest of the business needs these things and these are not problems the CISO should own, yet if they are not in place they will cripple a security program. For this reason, a lot of CISOs will try to tackle these issues, but they won’t be successful without support from the C-Suite that actually owns these functions. So, one of the best ways the CTO and CIO can support the CISO is to lead the way on the heavy lifting for these fundamentals that way the CISO can draft off of these and focus on making their security program as effective as possible to manage risk.

Accountability

Speaking of mastering the fundamentals, what we are really talking about is accountability. The rest of the C-Suite needs to hold their teams accountable for completing or resolving security issues. This could be things like resolving technical debt, completing training, fixing vulnerabilities or appropriately prioritizing security requests. If accountability isn’t enforced at the C-Suite, then the rest of the business will become siloed and ignore other initiatives across the company. This can cause security issues to pile up and open up the business to risk that will be impossible for the CISO to manage. By holding your teams accountable and partnering with the CISO function you will create a partnership that can accelerate the business instead of creating unnecessary friction.

One easy way to get visibility into what your teams are doing, so you can drive accountability, is with an exceptions process. Exceptions are a common process for a security function and it allows the security team to have escalating levels of approval based on risk. It also allows for reporting and metrics about how many exceptions a team has requested, how many have been approved and how long it takes the team to resolve an exception. This can provide other C-Suite members valuable insights into how their function is performing with respect to their security commitments and it also allows the C-Suite to drive accountability into their functions by acting as the senior executive approver for critical risks in their function.

An exceptions process doesn’t have to be just for security. The entire company can benefit from an exceptions process such as for purchasing, contracts, sales, finance and engineering. Exceptions across the company can give visibility, promote good friction and drive accountability.

Support Good Friction

There are two different types of friction in a company and we have all experienced them. Good friction exists to help slow people down to consider their actions or minimize risk. These are processes like confirming large financial transactions or requiring validation of someone’s identity before using a critical resource. Bad friction wastes people’s time and is adversarial. These are processes that are inefficient, people that exercise unnecessary control over others or people that never follow through on activities. This type of friction needs to be avoided.

The rest of the C-Suite can support the creation of good friction with respect to security and how security engages with their teams. Good friction can actually accelerate the business by front loading activities where they will take less time, instead of trying to resolve issues later in the lifecycle where they are incredibly difficult and expensive to resolve. Some examples of good friction are security checks as part of the CI/CD pipeline, like SAST, automated attack simulation, or automated compliance reviews. When the rest of the C-Suite supports good friction it will actually make everyone’s job easier and less risky.

Help Advocate For Security

Another way the rest of the C-Suite can support the CISO is by helping to advocate the value of the security function beyond being an insurance policy or compliance function. While the security function may be viewed as a cost center, it can actually drive revenue and generate value. By including the CISO in the strategic planning process, CISOs can advocate product features with customers and engage with customers in a more proactive way. CISOs can also work with the go to market and finance teams to create processes for tracking customer engagements by the security team. This can shed light into the direct and indirect ways the security function is driving revenue, which can change the perspective of the security function from simply being a cost center. Having other C-Suite members advocate and support the CISO with customer engagements, building revenue tracking and involving the security team in all phases of the business can help improve the value of security and reduce overall risk.

Cultural Change

The last area the C-Suite can help the CISO with is cultural change. The Chief People Officer or Chief HR officer can work with the CISO to create and adapt comp structures for the security team that reflects the competitiveness of the market. They can also work with the CISO to create career paths, training and job specific performance metrics for the security function. The Chief People Officer and the HR function are also critical partners for the CISO to backstop security policies and enforce these policies across the company. HR can create and enforce consequences for policy violations, such as lack of eligibility for promotion, and they can also help manage the worst offenders with termination. HR can also set incentives to reward good security behavior such as giving spot bonuses, rapid promotions or even tying bonuses to completion of key security goals.

Outside of the culture of the security function, the rest of the C-Suite can set the tone for the culture with respect to how the company should view and engage with security. In particular, the C-Suite can lay the foundation for a security first culture and hold people accountable for implementing this throughout their functions. They can also shift the culture by holding business owners accountable for the things they own. Lastly, if the rest of the C-Suite carries KPIs, OKRs or other annual performance metrics as part of their annual goals this can help cross pollinate and incentivize the entire company to execute on effectively managing risk.

Wrapping Up

Close partnership with the rest of the C-Suite is essential for the CISO to be successful. The rest of the C-Suite can support the CISO and the security function by involving the CISO in strategic planning, driving accountability, mastering the fundamentals, supporting good friction, advocating for security and helping to drive cultural change. By supporting these areas, the rest of the C-Suite will set the tone from the top and work with the CISO to govern the risk of the business in a way that allows it to eliminate bad friction, accelerate growth and remain competitive.

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.

Using Exceptions As A Discovery Tool

Security exceptions should be used sparingly and should be truly exceptional circumstances that are granted after the business accepts a risk. In mature security programs the security exceptions process is well defined and has clear criteria for what will and will not meet the exception criteria. In mature programs exceptions should be the exception, not the norm. However, in newer security programs exceptions can be a useful tool that provides discovery as well as risk acceptance.

Maturing A Security Program

One of the first things a new CISO will need to do is understand the business and how it functions. As part of this process the CISO will need to take an inventory of the current state of things so he or she can begin to form a strategy on how to best manage risk. As a new CISO your security program may not have well defined security policies and standards. As you begin to define your program and roll out these policies, the exception process can be a valuable tool that gives the perception of a choice, while allowing the security team to uncover areas of the business that need security improvement. Over time, as the business and security program mature, the CISO can gradually deny any requests to renew or extend these exceptions.

Rolling Out A New Security Process

Another area that is useful to have an exceptions process is when rolling out a new security process. For example, if you are rolling out a new process that will require teams to perform SAST and DAST scanning of their code and fix vulnerabilities before going into production, then allowing security exceptions during the initial rollout of the process can be useful to allow teams more time to adapt their development processes to incorporate the new security process. Allowing exceptions can foster good will with the development team and allow the security function visibility into the behavior and culture of the rest of the business. This can allow the security function and development team the opportunity to collaborate together with the ultimate goal of removing any exceptions and following the process to reduce risk to the business.

Tackling Security Tech Debt or Shadow IT

A common maturity evolution for companies is the elimination of shadow IT. The security function can assist with the elimination of shadow IT by creating an exception process and allowing an amnesty period where the business is allowed to continue to operate their shadow IT as long as it is declared. In reality you are giving the business the perception that they will be granted an exception when they are really giving the security function visibility into things they wouldn’t otherwise know about. This can be a useful tool to discover and eliminate policy exceptions as long as it is used sparingly and with good intent (not punitively).

Documentation Is Key

No matter how you choose to use exceptions within your security program there are a few best practices to follow.

Exceptions should be truly exceptional. If you do grant one for discovery purposes make sure there is a plan to close the exception. Exceptions shouldn’t be the rule and they shouldn’t be expected. Sometimes the rest of the business just needs someone to tell them no.
Time box the exception. Don’t just grant an exception without some sort of end date. The business needs to know an exception is temporary and there should be a well defined plan to make improvements and close the exception. The security team should grant a reasonable amount of time to execute that plan, but it shouldn’t be a never ending story.
Review often. Security exceptions should be reviewed often. Part of your security program should review the open exceptions, which ones are ending, if there are patterns where there are lots of similar exceptions and if there are teams who request a high volume of exceptions. Reviewing exceptions gives you insight into how well security processes and controls are working. It also gives you insight into which parts of the business need help.
Require the business owner to sign off. The reality of a well run security program is the business ultimately owns the decision if they want to accept a risk or not. The CISO makes a recommendation, but they don’t own the business systems or processes. As a result, the security exception process should require the business owner to sign off on any exception. This will ensure there is documentation that they were made aware of the risk, but this can also act as a visibility tool for the business owner into their own teams. I’ve often found a business leader is not always aware of what their teams are doing at the tactical level and the exceptions process can provide them the opportunity to check their team and correct behavior before it gets to the CISO.

Wrapping Up

The exception process can be a valuable tool for discovery of hidden risk throughout the business. By offering an amnesty period and giving the perception of flexibility, the security team can foster good will with the business while gaining valuable visibility into areas that may be hidden. The exception process also is a valuable tool for the security program to document risk acceptance by the applicable business owner, but can also provide business owners visibility into how well their team is meeting security requirements. Lastly, as the security program matures, the security team can gradually require the business to close down the exceptions by improving their security posture.

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.

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.