June 2023 – 370 Security Blog

Vendors: If You Want To Reach CISOs Stop All The Noise

I had an interesting conversation with a bunch of CISO friends last week about the current problem with vendor communications and particularly how there is a high volume of noise in the industry right now. The current problem is predicated on the assumption that more volume of communication will lead to sales leads, which will lead to an actual deal. I’ve been both on the sales side and the corporate side and I can tell you that vendors view it as a numbers game. However, I’m here to tell you the numbers game isn’t helping you achieve your goals because you are annoying the very people you are trying to connect with.

Bad Behavior

Most CISOs and security professionals I know don’t start out having a contentious relationship with vendors, but once you achieve a specific level and title, the calls, texts and SPAM inevitably start. If you are a vendor, here are a few things guaranteed to get you blacklisted from the people you are trying to reach:

Claiming you were referred by someone else in the company (when you weren’t. Yes we check.)
Sending repeated SPAM (it is unsolicited for a reason and we have no obligation to respond so stop it.)
Calling our personal cell phones (at any time)
Reaching out to our boss and saying we aren’t responding to you (you’re kidding right?)
Sending unsolicited texts
Sending unsolicited gifts

I know the behavior above is referring to a small minority of vendors, but the problem is the volume of noise from these vendors drowns out any legitimate outreach from anyone else.

What Can CISOs Do To Cut Down On The Noise?

If you have a public profile on any social media platform it is inevitable vendors will find you. My suggestion is to use a custom email address for each platform so you know if the social media platform sells or leaks your information. You can do the same thing for conferences or if you fill in your email for webinars and other vendor activities. If you don’t have the ability to create custom email addresses you can also use throw away or temporary free email services. If the vendor won’t accept these temp email services then move on…trust me that white paper isn’t worth it.

Controlling your email is not the only way to cut down on the noise. If vendors, conferences or other activities require you to input your work address you can use the primary address field or secondary address field to list the name of the vendor. This way if they send you junk mail or gifts you know who it came from.

Aside from controlling your information, I know several CISOs that set specific rules for how to engage with them. These are typically rules like only going through a certain Value Added Reseller (VAR) and only coming to the office and presenting on certain days (like the last Friday of every month). These specific days are good ways for security groups and CISOs to learn about a lot of different technologies at once.

What Can Vendors Do To Reach CISOs?

The biggest thing vendors can do to reach CISOs is respect boundaries. Treat CISOs and their security teams the same way you want to be treated. Most importantly, no one wants to feel like a transaction. The security industry is small and if you truly want results, cultivate lasting relationships that can follow you wherever you go. If you abuse people’s time and attention you will get blacklisted. We all talk and word will get around quickly.

The most effective way for vendors to connect with CISOs is to go to vendor days or partner with VARs and get on their docket for innovation days where the VAR shows you off along with a list of other companies that are of interest to the CISO.

Wrapping Up

Being a CISO is stressful enough without getting harassed constantly by vendors. CISOs need to set rules for how vendors can engage with them so vendors know not to resort to bad behavior to get their attention. On the other hand, vendors need to respect boundaries and cultivate lasting relationships independent of the technology company they represent. If you resort to bad behavior you will be blacklisted and word will get around not to do business with you.

When Risk Management Goes Wrong

Last week I took the opportunity to take some time off and spend a few days with my family at a popular amusement park in California. On the second day my kids and I decided to go to the water park to go down the water slides and during this experience my kids and I were on the receiving end of risk management gone wrong.

Let me explain…

Let’s assume I’m the CSO of this amusement park company and I’m helping the legal team and rest of the C-Suite evaluate the risks involved in this particular activity. So the general question is: “What are the risks involved in going down a water slide?” Here are a few easy examples:

Someone could go down the slide and not be able to swim so they could possibly drown in the splash pool.
Someone could go down the slide and collide with another person in the splash pool injuring them both.

How would you manage these risks as a business to make sure you aren’t continually sued by your guests?

It is easy to take the extreme case and simply try to manage these risks to the point where you have minimized your liability. In example 1, you can simply hire and staff life guards at the splash pool to make sure people don’t drown. You can also minimize the depth of the pool so there is enough water for a safe landing, but not so much that it is over people’s heads. Overall, these risk management techniques would make guests feel safe and not really impact the overall experience of the ride in anyway.

Example 2 is where it gets interesting. How do you make sure people don’t crash into and injure each other? On the extreme case you can make guests wait until the current guest is all the way out of the pool. This would minimize the risk of crash injury and be the safest option, but it comes at a tradeoff. The tradeoff is wait times for the ride, which ultimately impacts guest experience and satisfaction. Waiting for each guest to exit the pool took anywhere from 30 seconds to a few minutes (depending on the guest) before they would let the next guest go down. This doesn’t sound like a lot, but when you add up the time it takes for someone to go down (let’s say 30 seconds) combined with the time for them to get out of the pool (another 30 seconds to several minutes) you are looking anywhere from one minute to several minutes between guests. This means if the line is long your guests are waiting a really long time to ride this ride.

Risk is a difficult concept for companies to navigate because it is subjective. In order to get a reasonable risk outcome you need to use an objective process to make sure you are assessing and managing risk in a consistent way. It is up to the CSO organization to communicate and advise on how to manage risk in a way that is conducive to the business. Most importantly, you can’t let one group dominate the conversation about risk without taking into account other stakeholder perspectives (like legal, sales, finance, HR, IT, etc.).

In this example above the amusement park business minimized their risk at the expense of customer experience. This is equivalent to having extremely long latencies on your e-commerce site as a result of security checks. It may sound like a great idea, but ultimately will impede your business in the long run. In this particular case I am unlikely to go back to that particular amusement park because of the frustratingly long wait times.

As the CSO, it is your job to effectively communicate risk. You could be advocating for a new control to reduce risk, a new process to manage risk or an exception to accept risk. These are all acceptable outcomes as long as the business owners are involved in and acknowledge the ultimate decision. Most importantly, you need to balance customer experience, user experience and the needs of the business when implementing controls and processes to manage risk. At the end of the day not all risk can (or should) be managed because the business has to function and this comes with inherent risk.

A CISO Primer On Navigating Build vs Buy Decisions

Every year CISOs propose and are allocated annual budgets to accomplish their goals for the upcoming year. Within these budgets are allocations for purchasing tooling or hiring new headcount. As part of this exercise CISOs and their respective security teams are asking: should we build this thing ourselves or should we just buy it? It may be tempting to simply buy a tool or to build it yourselves, but both options have advantages and disadvantages. Here are my thoughts on how CISOs should think about this classic business problem.

Strategic Considerations

The first question I ask myself and my team is – will building this thing ourselves become a strategic capability or differentiator for our business? If we build it can we use it ourselves and sell it to customers? Are we building a capability unique to the industry that could lead to patents or a competitive advantage? Most importantly, do we have the resources to develop, maintain and support this capability for the indefinite future? If the answer to these questions is yes, then you should consider building the capability yourself, but this also comes with a cost in terms of people resources.

Use of People resources

While building a capability can look attractive at first, it generally has long term costs that can easily add up to be more than the cost of just purchasing a tool or capability. This is because CISOs will need to staff engineers or developers to build the thing. This means they will need to hire (or borrow) resources who will need coding skills, database skills, AI/Big Data Skills and a bunch of other skills that aren’t typically key skills in a traditional security team.

Let’s say you will need to hire or borrow people to build your new thing. These people have salaries, benefits, bonuses, equipment costs, facilities costs and other expenses that can easily cost as much as (if not more than) the annual cost of purchasing a tool. Additionally, if you hired people, they can’t just move on once the thing is built. They will need to support it, maintain it, etc. If you borrowed resources then you will need to figure out who is going to handle ongoing operations and maintenance of the tool and you need to consider the opportunity cost of using these borrowed resources to build something for you instead of doing something else for the business that could have value.

The point is people aren’t cheap and they tend to be the most valuable resources for a business. Using these resources wisely and in a cost effective way is an important consideration for every CISO.

Financial allocation (CAPEX vs OPEX)

One other consideration for Build vs Buy is how your company allocates financial costs towards either CAPEX or OPEX. The reason this is something to consider is it may be easier to get OPEX budget than CAPEX (or vice versa). This can influence your decision to buy something over building it depending on how finance wants you to allocate the cost (or how easy it is to get budget in one of these buckets).

Time to deploy

Another consideration for Build vs Buy is – when do you need the capability and how long will it take to build it vs how long it will take to buy something and deploy it? If you need the capability immediately it may make sense to buy the tool and deploy it rather than trying to hire resources, onboard them, build the thing, support it, etc.

Integration Costs

Similarly, integration costs can be a huge factor towards whether the capability is truly effective or not. For example, if you can stand up the new thing relatively quickly, but it takes six months or a year to integrate it into your existing tools then that could throw your overall timeline off and may sway your decision towards building it yourselves instead.

Security Considerations of SaaS / Cloud Products

Lastly, and most important, CISOs need to think about the security considerations of buying a product vs building it in house. Software supply chain security is a top security risk for businesses and CISOs need to evaluate new tooling to see if they are adhering to the security requirements required by the CISO. If the product is a SaaS or Cloud Product then CISOs need to think about the risk of sending their data, source code or other information to a third party environment they don’t directly control. Similarly, if the CISO chooses to build the capability in house then they will need to make sure the team is making the new capability as secure as possible so the business and their customers aren’t exposed to unnecessary risk.

Wrapping Up

Choosing to build or buy a new capability isn’t an easy decision. Both decisions have explicit and hidden costs that can be difficult to navigate. Like any decision the CISO should weigh the risk of the decision and ultimately choose the option that supports the strategic direction of the business, meets financial and budgeting requirements and is sustainable by the security organization for the life of the capability.