Ep. #37, Security Transformation with James Kaplan of McKinsey & Company

Guy Podjarny: Hello, everybody. Welcome back to The Secure Developer. I'm Guy Podjarny, and today we have a great guest, James Kaplan from McKinsey. Welcome to the show, James.

James Kaplan: Glad to be here. Thank you for having me.

Guy: So James, I know you're a partner at McKinsey-- McKinsey and Company, I should say, and you're based in New York.

If I understand correctly, you head up this IT infrastructure and cybersecurity work over there.

Can you tell us a little bit of context about what that means, and maybe a bit of background about yourself so people can understand the context in which you're providing us this great advice?

James: Sure. I've been at McKinsey going on 20 years now and I'm one of the lead core partners in what we call "McKinsey Technology."

As you mentioned, I'm one of the leaders in our IT infrastructure and cybersecurity service lines.

I spend the large majority of my time with important institutions and financial services and healthcare and manufacturing and high technology, thinking through and implementing strategies for getting the most out of their technology infrastructure and for best protecting the institution of cybersecurity programs.

Guy: OK , cool. How did you get into this space in the first place? What happened prior to McKinsey?

James: I was CTO of a startup many years ago in the 1990s, and then I went back to business school when I decided the startup was only going to go so far, and I got very interested in the telecommunications industry and eventually wound up at McKinsey doing work on telecommunications strategy and operations and technology.

As a result of that, I got pulled into some of the very earliest work back in 2001 that McKinsey did around consolidating technology infrastructure.

That became very exciting to me, because it was a complicated technology issue, a complicated economic issue, a complicated organizational issue and utterly critical to the technology success of some very important institutions.

Especially large banks, and building a practice around that became a big part of my election platform as a partner at McKinsey.

Then some number of years after I became a partner we started to hear rumblings about cybersecurity, and I am someone who's always curious and looking for the next issue, so we launched a research effort to really get underneath the covers of cybersecurity as a strategic issue.

Out of that, we created our cybersecurity service line which became an avenue to help clients in some very interesting, exciting ways.

We really built a cadre of people who were excited to do that work and very capable in it given some of their backgrounds, and we launched some very significant research efforts, including one back in 2013 with the World Economic Forum.

I had the opportunity to present to Davos, which became the foundation of a book I wrote with a couple of other people called Beyond Cybersecurity: Protecting Your Digital Business.

Guy: Very cool. It sounds like quite a quite a journey, indeed. Let's actually dig in to specifically that. We're going to talk about--

James: It makes sense in retrospect, but I can't claim there was a structured plan from the beginning.

Guy: Those are the best ones, you roll with the opportunities, strategic opportunity taking.

Specifically very relevant indeed to what we're digging into here.

We're going to talk a lot about basically this combination of digital transformation, or using technology to boost your business and security and how do the two combine.

So maybe starting at the top, you work with a lot of these large companies and they are undergoing these big digital transformation changes, they need to think about security.

How do you see companies come into these projects with regard to security?

How much do they think about security, how do they see security playing a role as part of their digital transformation?

James: Two thoughts for you.

First of which, for many companies cybersecurity is increasingly a critical business issue, not only or even primarily a technology issue.

If you're a consumer bank you're constantly thinking about what role security plays in your customer experience and how to make the right trade-offs between the services and the experiences you provide to your banking customers and your responsibility to protect them and their information from attack.

It's perhaps even more pronounced as a business issue in wholesale or enterprise financial services markets.

As one CISO of an investment bank said a couple of years ago, he observed hedge funds-- That is, consumers of the bank's prime services or prime brokerage business didn't used to care about cybersecurity.

Now they're obsessed with it, and they as well as many other consumers of wholesale financial services are interrogating their banking suppliers about the integrity or the resiliency of their technology platforms in the face of cyber attacks and their ability to safeguard sensitive or confidential data that belongs to the customer.

If you're a hedge fund, you don't want someone else finding out proprietary trading strategies because they were able to compromise information from or extract information from your prime broker.

In many sectors you see a dynamic like this in enterprise group health insurance, or in pharmacy benefits management, often the CISO is spending a material part of his or her time with the sales force speaking to large business customers.

Because they want to understand if they're entrusting sensitive data from their employees about who's using which type of drug or who has which type of medical condition with another institution, precisely how that supplier is going to protect the data.

So I think in addition to traditional notions of risk, which are very important, you're also seeing cybersecurity become an important commercial issue in many sectors and part of the conversation, especially in B2B markets between suppliers and customers about the sensitivity of the data and the use of data.

Now I'll admit that this does vary quite a bit by sector, there are some sectors where cybersecurity is utterly at the middle of the strategic discussion--

Financial services, business services or business process outsourcing technology, outsourcing software, especially as software providers move to SaaS type of delivery models.

Anything which provides critical infrastructure, or any business which provides a critical infrastructure in many parts of the healthcare ecosystem.

In contrast, if you have a company that does a manufacturing of commodity products, then their cybersecurity might be a little bit less or somewhat less strategic.

Guy: Yes, very related to the data. The amount of data that they end up containing and as a result that commercial pressure to demonstrate secure products.

James: It's the amount and nature of the data that they consume or take in from customers, and then also the criticality of technology to what might be described as core business processes.

If you speak to senior medical executives at a hospital chain, they will often tell you five years ago or seven years ago or 10 years ago, the date varies.

But at some point in the not too distant past if they lost all their technology platforms they could still run the hospital on clipboards.

Right now, they'll say that's becoming all but impossible.

A cyber attack driven disruption of technology systems, computerized physician order entry for example, in a hospital network dramatically compromises a hospital's or set of hospitals ability to fulfill its mission to its patients.

More and more businesses are like that, in healthcare, obviously in financial services, and in software.

Now when you bought a software on premises or you bought software to install it and run it yourself on premises, the security model of your software provider mattered only so much.

You needed to understand that the software developer wrote secure code . But other than that there wasn't too much you needed to concern yourself with.

However, now if you're procuring software via a software as a service model where the software provider runs and operates a software, that provider is now taking on much more of the security responsibility for you.

They have to make sure there is a secure environment, they have to protect against insider threat, they have to configure the software in a secure way, and so forth.

You're much more dependent on that software provider from a security standpoint, and therefore, you're very likely to have a much more stringent set of requirements and much more thoroughly interrogated for that software provider.

Guy: OK, understood. The businesses are increasingly acknowledging and explicitly asked to ensure these security practices, especially as they indeed hold more data or operate more of their activities.

When you go into work with these larger organizations, how do they currently or, if you will, pre-digital transformation or in the areas they're are a little bit less inclined to be less driven by technology vs. this change.

What type of change do they needs to undergo? How, coming along you've acknowledged the importance of security, you acknowledged digital needs and the opportunities over here.

How do the two combine? What are the big hitters on how does cybersecurity change?

James: I would say there's a few characteristics of, for want of better term, "Old school cybersecurity." Sometimes we call this "Cybersecurity as a control function."

It's fairly disconnected from the business and treated as something of a silo that security is layered on top, rather than designed in, so it's a series of technology controls put on top of or around technology platforms.

In many cases it's focused somewhat more on the perimeter rather than on the individual business and technology assets, and it's what I would call ticket-driven which is if the business or the rest of the technology function needs something from security, they make a request.

At some point in the future the security team fulfills that request having responded to a ticket in an IT service management system.

So if you need a vulnerability scan of an application, you put in a request to security and several days later or a week later or two weeks later they will come back to you and say "We've done a penetration test, we've done a vulnerability scan. Here's the issue. Here's the set of issues, or not."

Or if you're earlier in the process, if you're thinking of implementing a new application, you say "We've written this application, we've architected this application. I need a security architect to come and review it and tell me if there's a problem with it architecturally."

In combination, this model has been suboptimal in several ways.

One, because of the absence of a connection to the business, it did not or has not focused protections on the most important business risks and information assets.

Second, it creates complexity in the environment. It procures more and more controls, which add cost, which sometimes degrade performance and which can create compatibility issues.

And it's slow, developers-- The business has increasing expectations about speed, developers want to do things quickly and then bam, they have to make a request on security and wait for security to get back to them.

Then finally, I'll note, it utterly breaks in the face of many of the evolutions expected of enterprise IT.

It is designed around a waterfall on premise model and the combination of dev ops, cloud, analytics, RPA, all disrupt this traditional security model in a fairly substantial way.

Guy: Yeah, I fully agree. It's all about the continuous process and a continuous process just doesn't leave room for Gates.

You don't stop to do X, Y, Z for the most part. You're a continuous and you continue to run, and indeed just does not fit that model.

How do you see them then adapt? So, this is the need and I fully agree with you around the need to transform.

Potentially has never really been a great idea to have security be outside the business, but it's becoming increasingly not viable.

How do the orgs change, specifically do you see the cybersecurity groups change their location within the org structure? How do they embed themselves better then?

James: I would say there's three macro-level changes we see occurring.

The first of which is much more granular and analytic risk management, so this implies developing relationships with the business to identify what is and isn't important.

Being able to understand and quantify where the vulnerabilities are, in a structured quantitative way making decisions about where the institution can most effectively "Buy down the risk," and tracking that in a very systematic analytical way.

The second is deeply integrating security into the business value chain, and this includes building the right connections between the security, IT, product development, marketing, customer care, to create a holistic experience for customers that feels both secure and convenient.

This means being able to articulate the company's security value proposition to their enterprise customers, and in many cases building security into the sales motion and sales process for anybody who's making any technology or physical product.

It means taking an integrated view of potential security flaws across operational technology and information technology, because for many companies a technology product or technology-enabled product is now an endpoint or a node on the enterprise network.

It means building the capabilities to have visibility into configuration issues and potential attacks on the operational technology that runs a manufacturing process, and it means really interrogating suppliers about how they are safeguarding a company's data and potentially contributing to risk or not.

The third part is creating security that will enable a digital set of technology delivery capabilities.

This includes building security into agile delivery processes and thinking about who on the scrum team is going to be the security champion.

It includes building the automation and the services that enable companies to make use of cloud in a secure way, and in many cases it involves transitioning security itself from having a ticket-driven model to what I call the API-driven model.

Building agile security capabilities so we think of security as less of a bureaucratic set of responses to requests and more of a construction of a set of highly automated services around identity and access management.

Or vulnerability scanning, or secure configuration in the public cloud that developers and scrum teams can call via a set of APIs.

Which has the twin benefits of being much more agile, and ensuring that many things get done the right way and the secure way the first time. It makes it harder to do the wrong thing.

You also asked about organization, I would suggest to you this is an issue of operating model.

It's an issue of capabilities. It's an issue of relationships and credibility with the appropriate and important folks in the business, and in the rest of the technology organization.

It's a question of how the security organization or organizes itself, for example, "Will it create scrum teams?"

I would suggest to you that "Where does the CISO report?" May be among the least important parts of the discussion, which is to say there's a-- Actually, I got into this debate on LinkedIn yesterday.

There are various people who believe the CISO has to report to the CEO, the CISO has to report to the CRO.

At the end of the day outside technology companies and enterprises, enterprise consumers of technologies, banks, healthcare companies, manufacturers, what have you.

The overwhelming majority of CISOs report to the CIO and will continue to do so for the foreseeable future.

And that's just fine, in fact many of the most effective CISOs I have known have reported either to the CIO or the head of operations in technology.

And that has not prevented them from having any independent channel to the board and having very deep and consultative relationships with senior business executives and BU heads.

In fact, you could argue some of the changes that I described a minute ago imply an increasing degree of integration between security and the rest of the technology function, in the sense that for example infrastructure is thinking about how to become agile.

And many heads of infrastructure are thinking about "Should they pivot their organizations to become one much more dominated by scrum teams that are automating infrastructure services rather than 'Killing tickets?'"

That's a very parallel set of activities as the one I described potentially happening in security.

I will acknowledge the considerations are slightly different or somewhat different for technology companies, I think obviously a technology company doesn't have a traditional CIO that handles all the technology, and they give it institution.

You can make a good case that for a SaaS provider or for a hardware manufacturer or even an IT services provider, that the CISO is the even more senior role than it is at some enterprises and perhaps I think increasing you'll see the CISO reporting to the CEO for those types of enterprises, because the technology is even more so everything they do compared to some of their customers.

Guy: I think that the changes make a lot of sense to me, maybe one example that comes to mind is that I had the pleasure of having Geoff Belknap from Slack, the CISO from Slack on the show, and he did point out that it was fairly significant for them to actually move to be --

They're not, I believe at least at the time, reporting to the CEO.

He is reporting within engineering, and another conversation there was around basically where the primary risk lies as well when you're a SaaS platform.

The primary risk that you're really tackling is indeed about managing customer data, it's about access, it's about the technology platform versus maybe if you've got a retail chain of stores across the world, maybe the most important security threats that you face are a little bit different.

So it's a little bit harder, but fundamentally the collaboration and being nearby the group that you coordinate with has played a big role there.

Also by the way, emphasized the other points that you mentioned, also heard from New Relic and PagerDuty and the likes about APIs or security teams being service providers--

James: Exactly.

Guy: For the rest of the organizations, versus being a naysayer or a blocker, they need to help the business thrive.

James: All the least effective security organizations I've observed have seen themselves as policy shops that the CEO and his minions or her minions make a series of pronouncements from on high, which they deliver to various parts of the business, to leaving the other parts of the business to figure out how to achieve adherence.

That simultaneously doesn't achieve the appropriate level of protection, and frustrates the hell out of just about everyone from an ability to get things done standpoint.

Guy: Yeah, absolutely. There's a lot to drill down in here, and in general we'll post the link to your great article on this topic as well in the podcast show notes as there's a lot of additional content there.

I'd like to drill down a little bit into metrics, you mentioned a lot around measuring and understanding and quantifying risk and the risks that you buy down.

One of the challenges in security is that it tends to be fairly invisible.

You don't know whether that great lock that you bought for the door was too much or too little unless you got breached, unless somebody broke into the house.

James: Right, and there is in many cases a counter-intuitive dynamic around metrics in cybersecurity.

That is, if you see more issues that may be the result of increasing your capability to find those issues rather than the fact that a risk is fundamentally increasing.

Guy: Very well said. At Snyk we deal with known vulnerabilities in open source components and oftentimes there is this perception that when you see a library or a framework that has a lot of vulnerabilities disclosed on it, you think of it as one that is less secure.

When oftentimes the reality is precisely the opposite, hence it's well-informed.

How do you see organizations quantify cybersecurity risk? What are your recommendations around trying to measure this abstract entity?

James: I tend to be a skeptic of top down risk appetite statements, because I don't believe they're measurable. These risk apps will tell you "We will take all inappropriate measures to protect critical business data."

It's a hard thing to measure against, and in effect I think you manage your risk appetite by something of an inductive process.

There's a set of risks we have and for $50 million dollars we can address this set of risks, for an incremental $25 million dollars for a total of $75 million dollars we can address this other set of risks in addition.

I think that type of discussion tends to be reasonably effective with business managers.

You give them choices and via that set of choices you inductively arrive at an implicit risk appetite.

What's more, I think it's incredibly important to focus on what I would call leading indicators as opposed to lagging indicators or explicitly lagging indicators.

I think some management teams fixate on a number of attacks, number of breaches, number of incidents, all of which I would describe as lagging indicators.

Leading indicators are indications of levels of vulnerability in the environment, and therefore something you can do something about.

For example, "What percentage of systems have been patched through at least at minus one currency?"

"What percentage of applications received vulnerability scans before they're put into production?" "What percentage of systems require two factor authentication?"

What percentage of data is encrypted in motion encrypted at rest?"

You can imagine the full set, and then one synthesis of that set of metrics I like is to indicate a set of standards for protections.

For example, all systems with customer API will have encryption at rest, will be patched to N minus one currency, will require two factor authentication, so forth.

You can imagine the list, and then you can very concretely measure adherence.

If this is our control spec for certain types of business data, then you can interrogate or track and measure adherence against that control spec.

So you might say, "In business unit one, 57 % of our assets adhere to all the aspects of our control spec. In business unit two, it's a little bit a different story. 72 % of all our assets is adherent to our control spec."

But it might be more negative when you take a look in terms of the most important assets, you say "Across businesses only 45 % of all systems with the most sensitive data adhere to every aspect of our control spec."

And also you can take a protection based view which say, "OK, some percentage or other of systems adhere to our control spec around data protection or around identity and access management," and that has a couple of benefits.

First of which it takes into account the fact that most breaches or at least most problems I've seen stemmed from an absence of adherence to standards, not because the standard wasn't stringent enough.

Then second, there's always a backlog of things to be fixed.

Any CISO is going to be talking to the business unit CIO, and there's a list of things that's longer than can possibly be done in the short term.

One CISO from a bank told us that remediating the known items would in effect consume all the bank's application development capability for the next three years.

So, taking this type of view around adherence to specification, particularly for the most important information assets can be an incredible and powerful way of structuring our conversation with the business unit CIO and localizing the most important things to address.

Guy: And who do you see applying the adherence? I'm specifically focusing on maybe the DevOps technology side.

Developers are running fast, per your previous comment, they don't want to wait for it.

What do you think is a successful scenario around when you're not adherent and who gets those reports?

How much do you feel still boils down to the security teams to be enacting that adherence versus the rest of the org, that changed ?

James: At the end of the day, adherence is an incredibly business-unit specific issue.

I have found it very powerful to have a BISO or business unit CISO construct to help develop strategies for deployment of new security capabilities inside a business, and achieving adherence to a set of security standards.

That BISO, I think it's helpful for the BISO to report hard line into the CISO because you get common practice and commonality of approach.

But ultimately the true determinant of success for the CISO is what I describe as a "Two to hire, one to fire" type of model.

That BISO must be trusted both by the CISO and the business unit CIO, must sit in effect at both tables.

The enterprise CISO and the business unit CIO, and must be accepted and respected by the business unit CIO's leadership team as a integral part of that leadership team.

If that is true, then the business unit CISO can use context to help make a set of decisions around priorities.

We would say "OK . Only x percentage of our systems adhere to our standards around two factor authentication."

OK. That is what it is. We have a development roadmap over the course of next few years, and the systems in our portfolio are being remediated and addressed for a variety of things over a series of 24 months or what have you.

Therefore the business unit CISO can work with the development leaders to integrate remediation of an application, to make use of a standard two factor authentication solution into existing roadmaps, based on a set of priorities and based on capacity and based on, in effect, often leveraging in-flight initiatives to re-architect applications or to enhance applications.

Guy: What resolution do you see these BISOs? What unit size, if you will?

James: The BISO ideally should be a very small group. Obviously it depends on how big the business unit IT organization is, so it's not uncommon to have fragmented security delivery and therefore the BISO has responsibility for this group of penetration testers over here.

These folks taking care of an obsolete bespoke identity and access management platform, know that may be necessary in the interim state but I would suggest to you that ultimately there should be a highly standardized set of security services that are provided via the center.

There's no need to have multiple capabilities through vulnerability scanning or multiple capabilities to view encryption at motion--

Those should be enterprise services, and the BISO should be a very strategic function thinking about integration with a business' priorities and technology roadmap and application portfolio, and so forth.

The one other thing I'll note is particularly as companies start to adopt the agile national development, particularly as they start trying to move to an API-driven security service model, you do see a lot of interest around creating a community of practitioners for security and application development.

Guy: The security champions.

James: Exactly, some people call them security champions.

On every scrum team there's somebody who doesn't report to the CISO, is not an incremental person but who has the responsibility of understanding the security services that are available and how to consume them in an effective way.

Guy: Yeah, you definitely see that a lot across technology groups. It's just an aspect, a specific aspect of security, but it's one--

James: Part of a DevSecOps type of model.

One discussion I was having yesterday was the other institutions already thinking about infrastructure champions and every scrum team, and the question is "OK. Do you have a security champion and an infrastructure champion? Or is the infrastructure champion the same person as the security champion?"

I think there will be a lot of experimentation and multiple routes to success around the specific instantiation at each individual institution.

Guy: Yeah, for sure. James, this has been fascinating and I've got maybe a dozen more questions for it, but I think we're running out of time.

Before I let you go, can you just say a couple words about if people want more of your great insights and perspectives here, how do they find you or a relevant group in McKinsey?

James: OK. You can always go to McKinsey .com and look for McKinsey Technology or McKinsey Cybersecurity Practice.

We frequently publish content about our latest security thinking.

Guy: James, this has been a pleasure. Thanks a lot for coming onto the show.

James: This was fun. As I said, we just scratched the surface here.

We have an article coming out in a couple of weeks, "What security means for the commercial discussion in the SaaS world," and that was based on a survey we did of about 60 CISOs.

We have one coming out after that on risk management practice and cybersecurity.

And we have one also in the pipeline around open questions and longer term stuff that people should be thinking about from a cybersecurity standpoint.

Guy: Thanks again, James, and thanks everybody for tuning in. I hope you join us for the next one.