CHAPTER 12

Negotiation

Negotiation is not an act of battle; it's a process of discovery.

– Chris Voss

Opportunity

In my experience, all leaders expect to leave an imprint on the organizations they serve. Every attempt to change the status quo is a negotiation. The concepts we have described throughout the book equip you to understand, empathize, and communicate with your colleagues in their terms. This chapter covers the art of letting others have your way. Like Harry S. Truman, 33rd President of the United States, once said, “It is amazing what you can accomplish if you do not care who gets the credit.”

The average tenure of a CISO has been estimated at 18 to 26 months by various sources in recent years.1 Indeed, some of the reason that CISO tenures are so short is that the role is one of influence, not control. Cynthia James estimates that CISOs only have control of 60% of what might get them fired.2 I posit, therefore, you must be a trim tab. You must hold difficult conversations with uncertainty abound, and you must obtain results through others. Usually, all this happens without formal authority. You must build your circle of influence through moral authority so that people want to follow your leadership. You must be prepared to scale your impact by empowering others in your team to hold the same conversations successfully. Often requests from cybersecurity departments appear at odds with the primary goals of the business. After all, there are only so many hours in a day. Every minute your company spends on cybersecurity is a minute that the business could spend elsewhere.

Now, before we go on further, it's worth clarifying that negotiation isn't about taking the most for yourself and leaving the scraps for others. If you favor an abundance mindset rather than playing a zero-sum game, you can relax and enjoy the journey. You can appreciate the relationships you build and relish the business value you protect. You can avoid the burnout and moral dilemmas that have driven many cybersecurity leaders out of the field entirely.

The opportunity to negotiate is ever-present. It's not just about getting what you want. It's about getting what you want and having the other party feel good about it. In my first CISO role, I neglected to recognize how important it was to make sure the other party felt good about the work we accomplished. In my first 90 days, we achieved an enormous feat, narrowly avoiding fines for recurring PCI failures. I paid the price every day after, in the form of malicious compliance and an undercurrent of resistance. My greatest lesson from that experience was that I needed stronger relationships if my legacy was to survive beyond my time with an organization. Indeed, short-term gain can cause long-term pain.

Eventually, I left that role and took a year to travel. I invested the time to think and learn new skills. Finally, when I surfaced in the job market in pursuit of a new role, I positioned and promoted myself with this catchphrase:

I am an organizational change catalyst laser-focused on enterprise cyber resilience. I inspire change through piercing insights and profound relationships. Notably, my success as a security professional comes at the heels of dogged persistence and intense discipline.

When you look closer, what I'm saying is that it is essential to bring both intellect and heart to the role. I didn't realize it at the time, but negotiation is the confluence of piercing insights and profound relationships. So, in this chapter, I'll adapt techniques from Chris Voss's book Never Split The Difference: Negotiating As If Your Life Depended on It to the CISO role. I'll show how consistent application of these concepts can add up over time to produce a rising tide, in essence, the virtuous cycle of a cultural shift. That shift is the most powerful tool in your arsenal, and it happens slowly. Despite what you might think, there's no bolt of lightning. Culture shift does not happen overnight. Instead, the persistent presence of influence gradually saturates the culture. Like filling a bucket one drip at a time, applying these techniques will help you cultivate and nurture that cultural change one conversation at a time.

Principle

In this section, I will provide some techniques I have adopted to avoid being the department of “No” without succumbing to wimp-win negotiations. Here, we'll explore tactical empathy, which fuels both piercing insights and profound relationships. Additionally, we'll cover forced empathy to ensure that your colleagues reciprocate the compassion you meticulously cultivate.

The Department of “No”

For years, businesses have become accustomed to cybersecurity teams that function as the department of “No.” In my career as a consultant, I saw businesses struggle to adopt wireless technologies. Those that did successfully adopt Wi-Fi first had significant cultural and performance advantages. Then I saw the onslaught of mobile technologies that transformed into the various forms of shadow IT that we live with today. The battle of bring your own device (BYOD) eventually gave way to cloud workloads deployed on expense cards. Every few weeks, I participate in conversations with cybersecurity departments uncertain about adapting to enable digital business strategies that leverage hyper-scale public clouds.

While one strategy is to be the force of innovation, it is unrealistic to expect that the cybersecurity department can be the source of all innovation. By observation, often, businesses evolve in the space beyond their cybersecurity capabilities. And as they do, cybersecurity leaders and their teams either absorb the progress as a personal assault or recognize that it's not about them – it's about agility, growth, cost containment, and in some cases, survival.

Even so, it's very tempting to lead with “No.”

A look at the psychology behind “no” reveals that you feel safe and protected once you have said no. You have made no commitment. And the great thing about “no” is that anything you say while exploring the potential paths of implementation after you have said “no,” flows more easily. There's no risk of confusion or unknowns, or ambiguity. Simply, “no” is safe. “No” is comfortable.

However, we cannot reside in the cozy cocoon of “No.” If we want a seat at the table, we must find ways to facilitate calibrated risks and informed decisions. So, there are a few great alternatives to a simple “no” answer in the heat of conversation. Tactfully navigating pressure situations is a skill every successful executive should master. If you find yourself in one of these situations, stay calm and create room to maneuver with any of these responses:

· I'm not sure that I fully agree.

· This makes me feel uncomfortable.

· I don't understand.

· I'd like more information.

· I don't think we have adequate resources to support that safely.

· I believe we'd be better off considering an alternative.

· Let me check in my peer slack channels or CISO forums to see how others think about this challenge.

· I'd like to have an SME from [my team, a consulting partner, etc.] participate in making sure I'm considering all the angles.

Then, you can immediately follow with a solution-based question or simply observe your colleague's emotional response.

For example:

· It seems like you are not satisfied with this approach.

· What about this doesn't work for you?

· What would you need to make it work?

Using this strategy avoids a hard no, avoids offering approval to proceed, and indicates you are engaged in finding a solution that works for everyone. Then, focusing on the solution and offering your colleague an opportunity to explain more about their goals, approach, or strategy will help you identify new pieces of information that often permit you to divorce the goal and the strategy. More times than I can count, through this discovery process, I have separated the outcome from the steps to obtain it. Doing so frequently results in solutions that neither side was considering when the conversation started. Steven Covey refers to this as the third alternative. It is not your way, nor is it mine, but instead we agree to find a new way. Both parties should expect an outcome that is better than either party imagined in the first place.

More interestingly, if you use these alternatives in conversation, you are not cornered to make difficult decisions. You end up recruiting the most talented resources in the room to identify what is acceptable as an alternative and build buy-in for the solution. In the end, you won't carry the stress of a controversial decision or feel trapped if the chosen path blows up.

You eliminate that layer of stress, which helps you avoid burnout. When we, together, collaboratively design what we feel is the best solution, there is buy-in. Of course, let's be pragmatic. In some cases, you simply cannot get aligned. As a last option, push for a Risk Acceptance Form (RAF) signed by the department executive. Make sure you have a structured approach to communicating the risk. Don't forget to review the techniques covered in Chapter 7 – Translating Cyber Risk into Business Risk. Take time to purposefully articulate the risk so that business leaders know what risk they are accepting. Consider the 5-point finding format provided in the Risk Acceptance Form template available online at www.CISOEvolution.com.

“Yes” Is NOT the Goal

Just like there is safety in “No,” you are likely to encounter hesitation in “Yes.” More than one cybersecurity leader I know is challenged by operating in a culture that lacks accountability. The negotiations that take place on the internal battlefield include both the support you require from your business counterparts, as well as the security diligence you can offer to them. I mean that sooner or later, you will need a change in process, support to implement a technology, or even just access to a new system. Sometimes you will have to negotiate to get your way.

However, yes is not simply yes. Chris Voss has identified three styles of “Yes.” They include:

· Counterfeit – this is one in which your counterpart plans on saying “no” but either feels “yes” is an easier escape route or just wants to disingenuously keep the conversation going to obtain more information or some other kind of edge.

· Confirmation – is generally innocent, a reflexive response to a black-or-white question; sometimes a confirmation “yes” is used to lay a trap, but mostly it's just simple affirmation with no promise of action.

· Commitment – a commitment “yes” is the real deal; it's an actual agreement that leads to action, a “yes” at the table that ends with a signature on the contract. The commitment “yes” is what you want, but the three types sound almost the same, so you must learn how to recognize the differences.3

Chris argues that since “yes” is so tricky, you are seeking “That's right.” The way you get there is by labeling feelings to pull them out. Once you get to an emotional and intellectual alignment, you can pursue the strategy. Although my style is to think big, start small, and move fast. I continue to learn that it's essential to take the time to obtain emotional alignment and ensure that the subsequent steps are clear. As a finishing touch, you can create accountability with the simple script:

Who, does what, by when, and how will we follow-up?4

Forced Empathy

First, what is empathy? In its purest form, it is understanding both content and feelings.

You don't have to agree with someone to empathize with them. However, once you have demonstrated empathy, you must be exceptionally careful to honor other people's feelings. If you don't, you can quickly reverse all the goodwill that stems from empathy.

Here we are going to use “how” questions to engage your counterpart. In particular, “How am I supposed to do that?” Remember, your tone will make or break this technique. How questions can alter the conversation in a way that improves relationships and enhances security culture. Here's the typical dialogue:

Sales: “We want to sub-contract application development with this very innovative boutique consultancy. We want to carry them on our paper. They don't feel like it's necessary to perform the third-party diligence process since they already serve large healthcare customers. We need to move quickly, so we don't lose this deal. I just need your approval to proceed. Will you approve this?”

Me: “No. We can't do that and maintain our compliance.”

As an alternative, you can leverage forced empathy via a “how” question. Here's what that might sound like:

Me: “It seems like this relationship has the potential to be a game-changer. And this deal is important. Assuming that's true, my concern is that we're going to sign a contract today, and eventually, the nature of the relationship may change over time. If that happens, the small risk we have today evolves subtly, and soon we're taking on much greater liability than anyone anticipated. How could we mitigate the risk of a compliance failure and elevated liability over time if we don't perform third-party diligence as the standards require?”

Sales: “Well, the deal is average in size, so it's not a game-changer, but to answer your question – these guys aren't going to have any access to sensitive information. And we're only working with noncompliance customers.”

Me: “Hmm. Okay. It strikes me that less than 15% of our customers have no compliance requirements. So, 15% doesn't sound like a needle mover. I wonder, is all the effort for a partnership worth it? I mean, that essentially excludes them from doing business with most of our clients. It also really feels like a heavy qualifier as we try to include them in pre-sales efforts. Is our lead flow deep enough and qualification process streamlined to justify a partnership that at best can help us with 15% of deals?”

Sales: “I suppose we want them working on customers with more sensitive data eventually. Certainly, for the relationship to matter, they are going to have to.”

Me: “If that's true, it seems like a hassle to track all this in a way that will satisfy our auditors until they are ready. It would be a disaster to have audit findings that might trigger exit clauses with our existing customers. This potential for disaster raises a few more questions for me. For example, are you prepared to manage client communications if that happens? Are our CRO and CFO bought into this already? How do you think that notifications should work? How can we ensure that other key executives are included to help make this strategic decision?”

Sales: “Well, I wanted to focus on this first deal. But if this partnership is going to function, we're going to need them to step up and do the assessment.”

Me: “That's easier for our team since we have a whole platform and dedicated staff trained to facilitate the process.”

Sales: “Let's go that route. I'm going to push a little harder to have them complete the process. Otherwise, we can find another vendor to partner with.”

Me: “Okay, let me know, and we can press for more broad-based executive support if you think the risks and additional process are worth it.”

You can see that calibrated “how” questions caused the sales rep to consider the additional challenges he was introducing. In other words, forced empathy. In this case, maybe he realized the impact on his existing customers, and the energy to push the deal forward with the other executives might not be worth the time. Either way, he qualified the actual value of the relationship and ultimately decided that the path of least resistance was a more persistent pursuit of the security diligence process. In the dialogue, he also learned how our compliance program works and gained a further appreciation for the interconnected processes inside our business.

Now imagine the cumulative effect of this type of dialogue taking place repeatedly throughout your team and the many touchpoints in your business. With forced empathy, you gradually start to bend the culture in a direction that favors effective cybersecurity. You avoid being a department of “no,” and others can feel good about the collaborative outcomes you achieve.

Influencing Those Behind the Table

In Chapter 5 – Articulating the Business Case, we reviewed a case study on utilizing SCIPAB® to Present a Business Case for Password Management and then we examined a case study to present the Cost-Benefit Analysis performed for that same initiative. Combined, the messaging and cost-benefit analysis provided enough for us to obtain executive approval and funding to execute the roll-out. However, in that chapter we also described Stakeholder Analysis and Influence Mapping, two activities that influence the execution of a project after it has been funded. In this case, I failed to do both.

For better or for worse, I did a great job presenting the business case, but in the process of execution, I intentionally suppressed the voice of others whom I figured might have concerns. I thought that it was better to just push forward without building consensus. That was too slow. Years later, we achieved only a partial roll-out of the solution despite having tried on three separate occasions.

At the onset, I anticipated the project would be entirely uncontroversial. So, following such an extensive effort to get full executive buy-in, there was no way I was going to give anyone outside the executive team further opportunities to find obstacles. If you recall, my thinking on the effort was:

As the first CISO, I was naturally working to establish a positive presence in the business. I wanted to dispel the false narrative that security is always inconvenient. I was also working to highlight the difference between security-driven culture and compliance-driven culture.

I thoroughly regret the damage to relationships I inflicted in the process of failing to stop for red lights. So much for a quick win that enhances the overall sentiment of the InfoSec department. In hindsight, I wish I had taken just a moment to ask a few questions to influence those behind the table:

· How does this affect the rest of your team?

· Who are the other key players here? Will they have objections we should consider further?

· What do your colleagues see as primary concerns for this project?

I believe that if I had improved my negotiation approach, we would have saved a lot of effort, learned about better alternatives, and built stronger relationships in the process.

Application

This section will present how tactical empathy and intellectual curiosity helped elevate our application security program systematically over time. To set the stage, in early 2017, I joined Logicworks following a recapitalization event. This enabled opportunities for growth and the introduction of several changes in the business, including the formalization of a product team, reorganization of our service delivery functions, modification of our pricing strategy, refinement of our target markets, and the evolution of our revenue model.

Case Study – Security Culture and Application Security

As the company sustained hypergrowth over several years, there was limited software development life cycle (SDLC) documentation, and the ground was shifting beneath our feet.

The product team was challenged with a healthy volume of change – structurally with new leadership and team members, new agile development processes to adopt, and the fluidity of staffing up quickly. The product roadmap was aggressive given the pace of change and natural evolution of the industry. Needless to say, there were a lot of competing priorities to work through in addition to addressing the need for additional code security measures.

As you will see below, we were neither the source of innovation nor the killer of ideas or inspiration. Of course, I was concerned with the trailblazing appetite to integrate new cloud-native features. I prefer much more definition in our processes and made mention of that on several occasions. I simply communicated that I don't understand, and I'd like more information. Eventually, we all agreed that we needed additional resources to support the goals of our business.

Nevertheless, we started with awareness. We met for three hours. In the first hour, I provided an overview of the common frameworks and standards, including Building Security In Maturity Model (BSIMM), and how leveraging The Open Web Application Security Project (OWASP) Top 10 was essential to maintain PCI compliance. Then we conducted a threat model using Microsoft STRIDE. Just under 90 days on the job, I walked away from the conversation, happy that the code didn't perform anything critical yet. I learned that we were coding in Python on Django. The team mentioned that all the concepts we touched upon were not new to them. We ended the session with three enhancement opportunities for the sprint schedule:

· Password Complexity

· Dual Factor Auth Support

· Logging of State Changes

Recognizing that the vulnerabilities we identified were not exactly groundbreaking, I probably underappreciated the primary outcomes of this conversation. I was now a customer, and we established that vulnerability budgets, similar to SRE error budgets, would be burned down timely.5 The other thing that happened is that we had a shared understanding of all the things that make up a software security initiative. The team gained exposure to the full suite of practices we would consider. They knew we would add capabilities incrementally. This interaction happened very near the instantiation of the Product department.

In our subsequent conversations, I pushed forward with tactical empathy. Only, my questions were genuine in that I had quite a bit of learning to do myself. I inquired, “How can we validate, in addition to understanding threat modeling and OWASP Top 10, that we are proactive in identifying and mitigating vulnerabilities in our code? How can we be confident that the software we expose to the internet is safe? And how would you like to add the security touchpoints we've discussed incrementally?”

After burning down the findings we identified in our threat model, we committed to conducting a grey-box (credentialed, code-assisted) penetration test of our client portal web application. So, with outside consulting help, we conducted an informal threat model to reinforce the process and centered our assessment on evaluating our performance against the OWASP Top 10. The test revealed a few findings, but overall we faired much stronger than I anticipated.

We fixed those issues, and later that year, around the time of AWS re:Invent, a release of new features on the AWS WAF product prompted conversations for us to experiment with an OWASP aligned AWS CloudFormation Template. As Amazon and Microsoft release new features and services that get integrated or offered to our customers, it is important to ask additional questions on limitations or areas of concern.

In different meetings throughout the business I asked, “How can we be prepared to support the AWS WAF if we aren't familiar with the technology? How can we be advocates for the solution if we don't have experience deploying and operating it ourselves?” So, we implemented the WAF internally in a low-maintenance way. Later we also established a WAF responsibility matrix and supported the WAF as a solution in our managed cloud operations. We found that it helped us overcome some limitations in manually blocking IP addresses, and it also automated remediation for several repeat findings that were flooding our NOC. So, we augmented revenue opportunities and rationalized our operating costs.

Meanwhile, we evaluated several security partners in search of a cloud-native, forward-thinking partner that would help us address a comprehensive attack surface. Internally, we experimented with containers, and we were already deploying them with a variety of container orchestration engines for our customers. We knew that we wanted visibility into the containers we leveraged in our applications. As we integrated Threat Stack, Inc. into our security program, we took the opportunity to implement the runtime application self-protection (RASP) features. I asked, “What would prevent us from adding these features, especially as we augment our defenses and help clients consider leveraging the full solution?” After all, they were already licensed, and it was easy to integrate.

At some point along the way, we discussed the need to ensure our software didn't include any problematic open-source licensing issues, so we acquired a software composition analysis tool that we eventually integrated into our evolving continuous integration (CI) pipeline. Our CFO was pleased knowing we didn't have any software packages that could disrupt our valuation or sale should a future investor make an offer.

As we have continued to align our offerings to be congruent with Site Reliability Engineering (SRE) and the value software drives in our business has continued to grow, tactical empathy has been a very productive tool. Incrementally, with some humility, a lot of “how” questions, a bit of luck, and some patience, we've enhanced a defensible software security program. I believe we have a positive relationship with most of our development team. We even integrated an infrastructure as code (IaC) scanner that the development team identified for us!

We now leverage open-source libraries inside our Image Factory (a multi-level image bakery) to ensure image hardening. Soon enough, we'll add staff to support a team that already views nonfunctional security requirements as a critical part of developing a quality code. It's through their support in requesting additional DevSecOps resources that we've secured the budget in the first place. We'll be conducting an independent third-party review of our CI/CD maturity on the same timeline. I'm confident we'll continue to mature our practices, and I'm happy with both the relationships and the progress we've made to date.

Key Insights

· When negotiating you should honor your relationships over your immediate priorities. In other words, prioritize people first.

· You should rehearse scripted responses that offer you a means to retreat during high pressure negotiations. Then follow up with a solution-based question. This pattern is an effective way to stay engaged without caving-in or becoming the department of “no.”

· Calibrated “how” questions can help you achieve forced empathy. Further, persistent application of forced empathy techniques can lead to culture shift over time.

· It's never too early to predetermine successful execution by starting to influence behind the table. Ensure those not present in the room have a voice.

· There are three types of “yes,” and you want to obtain the commitment “yes,” which comes in the form of “that's right.” To get there you need to ensure emotional alignment.

Notes

1. 1 Morgan, S., “24 Percent of Fortune 500 CISOs on the Job for Just One Year,” Cybercrime Magazine, 2020. Accessed May 24, 2021. https://cybersecurityventures.com/24-percent-of-fortune-500-cisos-on-the-job-for-just-one-year/.

2. 2 James, C., “Why Are CISOs (Chief Information Security Officers) so Cranky?!?” LinkedIn, 2021. Accessed May 24, 2021. https://www.linkedin.com/pulse/why-cisos-chief-information-security-officers-so-cranky-cynthia-james/.

3. 3 Voss, C., Never Split The Difference: Negotiating As If Your Life Depended on It, Harper Business, 2016.

4. 4 Patterson, K. et al., Crucial Conversations, McGraw Hill, 2013, 245.

5. 5 Thomson, J., and Laing, D., “Extending the Error Budget Model to Security and Feature Freshness,” Usenix Association, 2019. https://www.usenix.org/conference/srecon19americas/presentation/thomson.

If you find an error or have any questions, please email us at admin@erenow.org. Thank you!