Hacking Security is a monthly podcast on emerging trends in application security development hosted by Steve Giguere, lead EMEA engineer at Synopsys.
In Episode 2, we discuss notable CISOs and then dive into the four tribes found in the Synopsys CISO Report. Take 20 minutes to listen to the latest episode below.
Welcome to the Hacking Security podcast. Hacking Security is a podcast for emerging trends in application security development. I am your host, Steve Giguere, and full disclosure: This podcast series is sponsored by the Synopsys Software Integrity Group.
Like all good software development projects, this is a multidisciplinary effort where we put together the minds and hearts of the Synopsys Software Integrity Group. And this is Episode 2 of Hacking Security. Our first episode was largely talking about the name of the podcast, just a little bit of a test to make sure that people were out there and people were listening and to get ourselves hooked up on iTunes. But this one is going deep. This is the four tribes of the CISO. Now, if you’re a CISO, maybe you know a CISO, maybe you’re on LinkedIn with a CISO—if you’re involved in security, it’s a good chance that at some point, you will encounter this beast. CISOs are humans too.
Now it’s worth noting some notable CISOs that you may or may not have heard of. For example, Alex Stamos, formerly from Yahoo, now the CISO for Facebook, very, very prominent figure. Or Stephen Schmidt, Amazon Web Services CISO. It’s worth noting that if you look at top CISOs—there was a report last year, the 100 top CISOs—seven of them were named Steve. Just saying. Anyhow, notable CISOs: Michele Hanson, now the CISO for Gatwick Airport, formerly Transport in London. And of course, if you’ve been to conferences, you may have seen Jaya Baloo, the CISO for KPN Telecom, speaking about encryption services and lots of other advanced and clever things. These are kind of our high benchmark for a CISO. Now of course, bringing this side down, maybe the Equifax CISO, Susan Mauldin, whose background was in music composition. And that’s kind of the sort of thing that’s driving this work: trying to look at the different CISOs and put them into different flavors, different approaches or tribes.
Now it’s worth giving credit where credit is due. This podcast is born out of some work done by the Synopsys Software Integrity Group, and it was a paper called the CISO Report, Version 2, a.k.a. The Four CISO Tribes and Where to Find Them. The authors of the paper and key contributors to the research were Gary McGraw, Sammy Migues, and Brian Chess. The result of the research, the four different flavors, approaches, or tribes of CISO, have emerged with unique characteristics.
To give you a little bit of background, some of the companies that were used for this research—there were 25 different companies and therefore 25 different CISOs—included Bank of America, Cisco, Starbucks, Morningstar, LifeLock, JPMorgan Chase. You get the idea. These are a lot of CISOs in very prominent positions who have been there and been around the block. It’s worth mentioning that the first version of the CISO Report only featured 12 companies and therefore 12 CISOs. So Version 2 has doubled our efforts and has given more credibility to the report. As a result of this research, the four different flavors that we will get into, the tribes of the CISO, have emerged with unique characteristics, and I think if you’re listening as a CISO or perhaps somebody who directly reports, you’ll find a fit for yours within these boundaries.
Disclaimer: It’s worth mentioning what this research did not cover. This was not a laundry list approach to a CISO to-do list. It was more about the differing approaches that each CISO took, with the idea that potentially each could learn from each other and perhaps you can also learn from this knowledge yourselves.
If you didn’t already know about the authors of this research, they were the founders of the BSIMM project, BSIMM standing for the Building Security In Maturity Model, which acts as a guide and measurement model for determining the maturity of your entire software security initiative using an unbiased method of determination, enumeration, and evaluation of the people and process within an organization. A very similar approach was used to establish our CISO tribes.
Three domains that every firm had in common were identified. They were Workforce, Governance, and Controls. Now that may sound like just a rebranded “people, process, and technology” mantra, and it kind of is. Let’s break those three down a little bit. So we have Workforce. Workforce covers people and includes things like organizational structure, board interaction, MBOs, and things like staff development. I mean, kind of the boring stuff, but very necessary. Governance—that covers processes like metrics, reporting, budgets, line of business interaction, that sort of thing. Controls—this is where I find it gets a little more interesting and where more of my work lies—that is more like the technology. So that’s cyber security frameworks, risk management, security features, assessment and vulnerability management, software security, and so on. If it were me, I kind of just want to live in the Controls world, but the CISO has more responsibility than that. So let’s divide those up.
In order to assess our CISOs based on our three domains, the research team identified a series of 18 what they called “discriminators” they could use to—and I quote the report—“tease apart the CISOs.” These discriminators were lumped into the three categories as follows: In the Workforce domain (this is kind of the boring one, from my perspective, but absolutely necessary):
|I.||CISO executive stance|
|III.||CISO curation of security message|
|IV.||CISO and compliance|
|V.||Security organization structure|
|VI.||Security career path|
|VII.||Security alignment with the business|
|VIII.||Company culture and security|
Actually, I really liked VIII because I think without that being properly addressed, very little software security initiatives will succeed.
Now let’s move on to Governance. They’ve numbered all these in a I–XVIII fashion, so you’ll find that I’m going to start at IX now. So Governance:
|IX.||KPIs, KRIs, and metrics|
|X.||Security and crisis|
|XIII.||Risk management and technical debt|
That is Governance. Now finally, let’s bring the final five into the Controls domain. Those five discriminators are:
|XIV.||Cyber security framework|
|XVI.||Vulnerability management, risk, and threats|
|XVII.||Lines of Business alignment|
And last but certainly not least,
And that is the software security initiative.
Now, each of these discriminators, you’d think, might be enough. How do we make decisions surrounding them? Well, for the report and for the assessment, each had subentries or criteria—again, to tease out the approach to each. Now I’m not going to go into each subentry. We would be here all day. But I will give you an idea from each domain how clarity was provided in assessing each of these discriminators. For example, from the Workforce domain, I chose “Company culture and security,” VIII, because that is one I believe in considerably. Now the subentries for this to make decisions, it’s almost like a multiple choice quiz. I’m sure it was deeper than that. But when you read it at a glance, that’s how it comes across.
So let’s choose the first aspect of the first subentry of “Company culture and security” is #1—or let’s say A: “Company culture aligns with security and is partially defined by security.” That sounds good. B: “Company culture is beginning to align with security at senior executive levels. However, harmonized vision is not yet driven down, sometimes even in the security organization itself.” Hmm. B sounds familiar, doesn’t it? Let’s go to C: “Company culture is not conducive to security. Compliance is the one and only currency.”
Now, I’ve worked for a lot of different companies. I’ve worked as a consultant. I’ve worked four different places. And looking at those three selectors, I can almost definitely put every company into one of them. Some of them were amazing, and some of them…yeah, compliance. I liked the way it’s worded, that compliance was the one and only currency. Sometimes that is your one and only driver, and that’s not necessarily the best. However, in certain verticals, it is definitely sufficient.
So let’s move on to the next category falling within Governance. I chose “Risk management and technical debt.” Back to our multiple choice. A: “Security is treated as risk management. Technical debt is understood and accounted for in the risk management paradigm.” Hmm, OK. B: “Security is treated as risk management. However, technical debt is not accounted for in the risk management paradigm.” OK, and C: “Security is limited to a compliance exercise. Security has little or no handle on technical debt.” I think you’re getting the picture now. A sounds awesome. C sounds a little bit like security is a tick box exercise. And these answers are part of what slots a different CISO, or I guess a different security posture, into which tribe.
Moving on. The final category, and the one nearest and dearest to my heart, of course: the Controls domain. I chose “Cyber security framework.” A: “A cyber security framework (e.g., the NIST framework) is used proactively to drive the security story forward.” OK. “B: A cyber security framework (e.g., the NIST framework) is used proactively to drive the security story forward. Use of the framework may not be creatively tailored to the business.” And C: “There is no underlying cyber security framework.” So I hope you’ve got an idea now of the discriminators and the subentries that were used as assessment criteria, essentially to tease out the different approaches between each CISO. After the research was completed, the four tribes of the CISO were established.
We’ve left this until near the end, but now we’ll reveal the four tribes. Are you ready? Excellent. Tribe 1: Security as Enabler. Tribe 2: Security as Technology. Tribe 3: Security as Compliance. And Tribe 4: Security as a Cost Center. The theory, as it stands, is that any CISO can be slotted into one of these tribes. Now, I realize some of these tribes sound better than other tribes. And I’ve worked at a lot of companies and provided consulting, and it’s held true so far that each one seems to be able to slot into one of these tribes, although I will admit it’s difficult not being biased, knowing the tribes in advance, because there is that potential to shoehorn people into buckets that you’re already aware of. So some scrutiny is required after listening to this podcast or reading that report.
So what do they actually mean, Tribe 1 to Tribe 4? It’s easy to give them titles: Enabler, Technology, Compliance, and Cost Center. But let’s try and break down each tribe and give them a clearer definition that you can better decide where you as a CISO or your CISO fits.
So let’s start at the top. Tribe 1, Security as Enabler. Stealing directly from the CISO Report, it is defined as:
“The Enabler tribe has a number of salient characteristics. Firms in this tribe have long since evolved the security mission from compliance to commitment.”
And I think that’s a very good statement, breaking from the scripted text. “Compliance to commitment” is the journey that we’re all on, from a security perspective. Going back: “This means a firm’s culture prioritizes security and gets compliance as a planned side effect. Even the Board of Directors has moved past compliance and uses a risk management approach to provide oversight. Security is not just a technical problem, and the business-focused approach gets Lines of Business to participate in the security mission. Staff balance between technologists and executives is carefully constructed. Speaking of executives, regardless of whether CISOs in the Enabler tribe have a deep technical past, today they look like their senior executive peers from a business standpoint. Like good senior executives, CISOs in this tribe proactively get in front of the problem both internally and externally by intentionally influencing the standards by which they will be judged.”
And that’s the end of that one, Security as an Enabler. A lot of the people I mentioned at the beginning of this podcast as leaders in the security domain fall into this category. These are people who are, I think, the final statement about influencing those standards by which they will be judged. It’s not just influencing, but in a way it’s giving back to the security mission.
OK, so let’s move onto Tribe 2, Security as Technology. Again, taking directly from the CISO Report:
“One salient characteristic of the Technology tribe is an approach to security not bounded by compliance. Because CISOs in the Technology group started their careers as alpha geeks”—sounds like they’re talking about me—“their world view tends to overemphasize the technical aspects of security challenges. They bring the technology hammer to bear on every problem first. All that aside, a Technology CISO sets out to be a good business person but has not attained the senior executive gravitas of the Enabler tribe. Learning the business ropes the hard way (that is, through trial and error and raw experience) is an ongoing challenge. Because technologists like to solve hard problems, one common trap for Technology CISOs is to take on the stickiest business challenges themselves. An undersupply of business acumen leads to what we call the “superman syndrome,” in which the Technology CISO often gets down in the weeds on a particular problem instead of delegating—for example, weeding through the morning’s catch of threat intelligence at 5 a.m.”
Now Security as Technology, the technology CISO—that’s something that I can relate to, because my enthusiasm for technology could easily be the way that my greatest strengths could easily become my greatest weakness. And getting in the weeds is something I quite enjoy doing.
OK. Let’s move on to Tribe 3, Security as Compliance.
“Compliance is both a boon and bane for security. The Compliance tribe intentionally leverages compliance requirements to make real security progress. But compliance alone has never kept a bad guy out. That means compliance is both a bare minimum standard that must be reached and a bar that some firms are struggling to get over. In many cases, previous security leadership was replaced at the same time that a compliance regime was imposed from outside (possibly in the wake of a crisis). Historical underinvestment in security, which may have reached crisis proportions, leads these firms to continue to underinvest in security even in the face of compliance requirements. That’s because the compliance spending of today is in many cases more than the pre-crisis spending of yesterday. Simply put, they were spending a dime instead of a dollar in the past and are now sanguine in spending a quarter when a dollar is still what’s required. CISOs in the Compliance tribe tend not to be deep technologists, but at the same time they tend to have strong managerial and leadership skills. This can lead to a situation in which limited resources are being properly allocated and clear progress is being made, even while technical debt is accumulating.
OK. I think we’ve all run into the compliance-driven security scenario to an extent where it can override even somebody who’s on the fence between Tribe 3 and Tribe 2, when they may have strong security background, strong technology background, compliance can still be that bane.
Moving on: Tribe 4, Security as a Cost Center.
“The Cost Center tribe is overwhelmed and underresourced. In most cases, security leadership exists under several levels of executive leadership (and sometimes even middle management) that treat security as a cost center. Security consumes budget but never drives budget creation and in some sense has a thick glass ceiling imposed on it. Without a real executive seat at the table, security is relegated to plumbing, much like the help desk.”
Now what’s interesting is that is the shortest description of all of the different tribes. And when you read through each one—from Enabler, Technology, Compliance, and Cost Center—you can lump your own security team or your own security initiative into one of these, perhaps even pushing your CISO. I think to lump the CISO in there in a way is kind of blaming the CISO, and actually there’s a lot more to it. The CISO has to react to many business elements that surround their environment and do the best they can. They may be driven by compliance, and that might override their desire to be technology-driven. They may not have the access to the board to become that enabler. And certainly when security is looked at as a cost center, certainly by the board or executive leadership, then it’s not necessarily the CISO’s fault for being part of that tribe.
So it’s interesting, the different tribes. The tribes are more of a state of being as opposed to an intended result from the individual in that position. Or perhaps I’m being too kind.
So in this podcast, we have learned a bunch about CISOs, and I hope you have to. Everywhere that our researchers went so far, there’s been a great interest in what CISOs actually do, why they do it, and how they can do it better. Occasionally, groups of like-minded CISOs get together, especially if they are all from the same vertical or same geography. This is a very encouraging trend that we at Synopsys support. And the best of all possible worlds: The model that has been described can not only become a common vocabulary but also a basis for further discussion and professionalism around the CISO role.
If you can, I highly recommend going to the Synopsys website and downloading the CISO Report, Version 2 of course. And if you can, if you don’t want to do that, why not just share this podcast? It’s a nice little summary of the report and gives you a good flavor for what the reading entails. If you’re a CISO yourself and would like to be involved in the project, get in touch. Everybody is welcome.
This has been a podcast from the Synopsys Software Integrity Group. I’ve been your host, Steve Giguere. Special thanks goes to the team at Synopsys: Beth Gannett, Gabby McDonald, and of course the contributing authors to the CISO Report and the researchers, Gary McGraw, Sammy Migues, and Brian Chess. Thank you for listening. This has been Episode 2 of Hacking Security.