Security Transformation With James Kaplan

“James Kaplan: The security model of your software provider mattered only so much. You needed to understand that the software developer wrote secure code. Other than that, there wasn't too much you needed to concern yourself with. Hedge funds didn't used to care about cybersecurity. Now, they're obsessed with it. I would say, there's macro-level changes we see occurring.

[INTRODUCTION]

[0:00:31] Guy Podjarny: Hi, I'm Guy Podjarny, CEO and Co-Founder of Snyk. You're listening to The Secure Developer, a podcast about security for developers, covering security tools and practices you can and should adopt into your development workflow. It is a part of The Secure Developer community. Check out thesecuredeveloper.com for great talks and content about developer security and to ask questions and share your knowledge.

The Secure Developer is brought to you by Heavybit, a programme dedicated to helping startups take their developer products to market. For more information, visit heavybit.com.

[INTERVIEW]

[0:01:04] Guy Podjarny: Hello, everybody. Welcome back to The Secure Developer. I'm Guy Podjarny. Today, we have a great guest, James Kaplan from McKinsey. Welcome to the show, James.

[0:01:13] James Kaplan: Glad to be here. Thank you for having me.

[0:01:16] Guy Podjarny: James, I know you're a partner at McKinsey, McKinsey & Company, I should say. You're based in New York. If I understand correctly, you head up the 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?

[0:01:35] James Kaplan: Sure. I've been at McKinsey going on 20 years now. I'm one of the core partners in what we call McKinsey Technology. As you mentioned, 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 via cybersecurity programmes.

[0:02:12] Guy Podjarny: Okay, cool. How did you get into this space in the first place? What happened prior to McKinsey?

[0:02:17] James Kaplan: I was CTO of a startup many, many years ago in the 1990s. Then went back to business school when I decided the startup was only going to go so far. I got very, 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 organisational issue, and utterly critical to the technology success of some very important institutions, especially large banks. You're 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. I am someone who's always curious and looking for the next issue. 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 and 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. We launched some very significant research efforts, including one back in 2013 with the World Economic Forum, that I had the opportunity to present to Davos, and which became the foundation of a book I wrote with a couple of other people called Beyond Cybersecurity: Protecting Your Digital Business.

[0:04:30] Guy Podjarny: Very cool. Yeah, it sounds like quite a journey indeed. Cool. Let's actually dig into specifically that, right? We're going to talk –

[0:04:36] James Kaplan: It makes sense in retrospect, but I can't claim there was a structured plan from the beginning.

[0:04:43] Guy Podjarny: Yeah. Those are the best ones. You roll with the opportunities. Strategic opportunity taking. Specifically, very relevant indeed to what we're digging into here, right? 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 did the two combine? Maybe starting at the top, you work with a lot of these large companies. 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 – this indeed digital transformation?

[0:05:25] James Kaplan: 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 of financial services markets. As one, the 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. 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-attack 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 the information from or extract information from your prime broker.

In many, 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.

I think in addition to traditional notions of risk, which are very, very important, you're also seeing cybersecurity become an important commercial issue in many sectors. A 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, and software, especially as software providers move to SaaS type of delivery models. Anything which provides critical infrastructure, any business which provides critical infrastructure and many parts of the healthcare ecosystem. In contrast, if you have a company that does manufacturing of commodity products, then their cybersecurity might be a little bit less, or somewhat less strategic.

[0:09:25] Guy Podjarny: Yeah, very related to the data, right? Like, the amount of data that they end up containing and as a result of commercial pressure to demonstrate security.

[0:09:34] James Kaplan: Yeah, if the amount and nature of the data they consume are taken from customers. Then also, the criticality of technology to what might be described as core business processes. If you speak to a senior medical executive, so the 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 to 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, computerised position order entry, for example, in a hospital network dramatically compromises a hospital or set of hospitals' ability to fulfil 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 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. Other than that, there wasn't too much you needed to concern yourself with.

However, now if you're a 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's 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, much more thoroughly interrogated for that software provider.

[0:12:08] Guy Podjarny: Okay. Understood. The businesses are increasingly acknowledging and explicitly asked to ensure the security practices, especially as they indeed hold more data, or operate more of the activities. When you go into, indeed, you work with these large organisations, how do they currently, or if you will, pre-digital transformation, or in the areas that are a little bit less inclined to be less driven by technology versus this change, what type of change do they need to undergo? How, coming along, you've acknowledged this importance of security. You acknowledge digital needs and the opportunities over here. How do the two combine? What are the big hitters on how does cybersecurity change?

[0:12:55] James Kaplan: I would say, there's a few characteristics of, for one, a better term old-school cybersecurity, but sometimes we call this cybersecurity as a control function. It's barely disconnected from the business and treated as something of a silo. That security is layered on top, rather than designed in. 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. 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 fulfils that request having responded to a ticket in an IT service management system. If you need a vulnerability scan of an application, you put in a request to security. Several days later, or a week later or two weeks later, they will come back to you and say, “Yeah. We've done a penetration test. We've done a vulnerability scan. Here's the issue. Or 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, or 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 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 can degrade performance and which can create compatibility issues. It's slow. The business has increasing expectations about speed. The 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, on 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 DevOps, cloud, analytics, RPA, all disrupt this traditional security model in a fairly substantial way.

[0:16:06] Guy Podjarny: Yeah, I fully agree. It's all about the continuous process and the continuous process just doesn't leave room for gates. You don't stop to do XYZ for the most part. No, you're a continuous. You continue to run and indeed, just does not fit that model. How do you see them then adapt? This is the need. I fully agree with you around just the need to transform. Potentially, has never really been a great idea to have security be outside the business, but just 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?

[0:16:45] James Kaplan: I would say, there's three macro-level changes we see occurring. The first of which is much more granular and analytic risk management. This implies developing relationships with the business to identify what is and is important. Being able to understand and quantify where the vulnerabilities are. Making in a structured, quantitative way, making decisions about where the institution can most effectively “buy down” the risk. Tracking that in a very systematic, analytical way.

The second is deeply integrating security into the business value chain. 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 a 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. 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 the cloud in a secure way. 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.

We think of security as less a bureaucratic set of responses to requests and more the 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 the asset of APIs, which has the twin benefits of being much more agile and ensuring that many things get done the right way, the secure way the first time. It makes it harder to do the wrong thing.

You also asked about organisation. I would suggest to you, this is an issue of an 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 organisation. It's a question of how the security organisation organises itself. For example, will it create scrum teams? I would suggest to you that the CISO report may be among the least important parts of the discussion, which is to say, there's a – actually, I got 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 - should 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 who report to the CIO, and will continue to do so for the foreseeable future. That's just fine. But in fact, many of the most effective CISOs I have known have reported either to the CIO, or the head of operations and technology, and that has not prevented them from having an independent channel to the board, having very deep and consultative relationship 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 is thinking about, should they pivot their organisations to become 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 in the given institution, and 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 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 technologies, even more so everything they do, compared to some of their customers.

[0:23:48] Guy Podjarny: Yeah. 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 of Slack on the show. 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, that he is reporting within engineering. Another conversation there was around the, 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, 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 built on and being nearby, the group that you coordinate with has played a big role there.

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

[0:24:53] James Kaplan: Exactly.

[0:24:54] Guy Podjarny: - to the rest of the organisations, versus being a naysayer, a blocker. They need to help the business thrive, so.

[0:25:01] James Kaplan: All of the least effective security organisations I've observed have seen themselves as policy shops, that the CISO 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.

[0:25:41] Guy Podjarny: Yeah, absolutely. There's a lot to drill down in here. In general, we'll post the links 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 quantifying risk, and the risk that you buy down. One of the challenges in security is that it tends to be fairly invisible, right? You don't know whether that great lock that you bought for the door was too much, was too little, unless you got breached, right? Unless somebody snuck in the house.

[0:26:13] James Kaplan: There's in many cases, a counterintuitive 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 risk is fundamentally increasing.

[0:26:33] Guy Podjarny: Very well said. At Snyk, we deal with known vulnerabilities and open-source components. Oftentimes, there's this perception that when you see a library or a framework that have 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 organisations quantify cybersecurity risk? what are your recommendations around trying to measure this abstract entity?

[0:27:01] James Kaplan: I tend to be a sceptic of top-down risk appetite statements because I don't believe they're measurable. You have this risk appetite. We will take all appropriate measures to protect critical business data. It's a hard thing to measure against. In effect, I think you manage your risk appetite by something of an inductive process. There's a set of risks we have. 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 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 assistance has been patched to at least M-1 currency? What percentage of applications receive vulnerability scans before they're put into production? What percentage of systems require two-factor authentication? What percentage of data is encrypted and motion encrypted at rest? You can imagine, you have a full set.

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 PII will have encryption at rest. Will be patched to M-1 currency, will require two-factor authentication, and so forth. You can imagine the list. Then you can very concretely measure adherence. If this is our control spec for certain types of business data, then you can interrogate our track and measure. Adherence against that control spec. You might say, in business unit one, 57% of our assets adhere to all the aspects of our control spec.

In business unit 2, it's a little bit of – sorry, 72% of all our assets adhere to our control spec. It might be more negative when you take a look in terms of the most important assets. You say, “Wow, across businesses, only 45% of all systems with the most sensitive data adhere to every aspect of our control spec.” Also, you can take a protection base view, which says, “Okay, gee, some percentage or other of systems adhere to our control spec around data protection, or around identity and access management.” 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 stem 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. There's a list of things that's longer than can possibly 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 two years, right? Taking this type of view around adherence to specification, particularly for the most important information assets, can be an incredible and powerful way of structure and conversation of the business unit CIO and localising the most important things to address.

[0:31:50] Guy Podjarny: Who do you see applying the adherence? I'm specifically, I’m focusing on maybe this the DevOps technology side, right? 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, 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? Have that changed?

[0:32:21] James Kaplan: At the end of the day, adherence is an incredibly business unit-specific issue, right? 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 your commonality of approach.

Ultimately, the true determinative 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 CIS leadership team as an integral part of that leadership team, right? If that is true, then the business unit CISO can use context to help make a set of decisions around priorities.

Let's just say, okay, only X percentage of our systems adhere to our standards around two-factor authentication. Okay, that is what it is. We have a development roadmap over the course of the next few years. 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.

[0:34:39] Guy Podjarny: What resolution do you see these BISOs? At what unit size, if you will?

[0:34:44] James Kaplan: The BISO, ideally, should be a very small group. Obviously, depends on how big the business unit IT organization is. It's not uncommon to have fragmented security delivery and therefore, the BISO should have responsibility for this group of penetration testers over here, or these folks taking care of an obsolete and bespoke identity and access management platform. That may be necessarily in the interim state, but I would suggest to you that ultimately, there should be a highly standardised set of security services that are provided via the centre. There's no need to have multiple capabilities to do vulnerability scanning, or multiple capabilities to do encryption and motion. Those should be enterprise services and the BISO should be a very strategic function thinking about integration with the businesses, 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 agile and agile development, and 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.

[0:36:13] Guy Podjarny: The security champions.

[0:36:14] James Kaplan: Exactly. Yeah. 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.

[0:36:32] Guy Podjarny: Yeah, that definitely, you see that a lot across technology groups and I guess, it's just an aspect. It's a specific aspect of security, but it's one that's security and –

[0:36:41] James Kaplan: Yeah. Then part of a DevSecOps type of model.

[0:36:44] Guy Podjarny: Indeed.

[0:36:44] James Kaplan: One discussion I was having yesterday was the institution who's already thinking about infrastructure champions and every scrum team. The question is, “Okay, 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'll be a lot of experimentation and multiple routes to success around the specific instantiation at each individual institution.

[0:37:12] Guy Podjarny: Yeah, for sure. James, this has been fascinating and I've got maybe a dozen more questions for you, but I think we're running out of time. Before I let you go, can you just say a couple of words about, if people want more of your great insights and perspectives here, how do they find you, or a relevant group in McKinsey?

[0:37:31] James Kaplan: Okay. Well, 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.
[0:37:47] Guy Podjarny: Well, James, this has been a pleasure. Thanks a lot for coming onto the show.

[0:37:50] James Kaplan: This was fun. As I said, we just scratched the surface here. We have an article coming out in, I guess, a couple of weeks what security means for the commercial discussion in the SaaS world. That was based on a survey we did about 60 CISOs. We have one coming out after that on risk management practice and cybersecurity. We have one also in the pipeline around open questions, longer-term stuff that people should be thinking about from a cybersecurity standpoint.

[0:38:26] Guy Podjarny: Thanks again, James. Thanks everybody for tuning in. I hope you join us for the next one.

[END OF INTERVIEW]

[0:38:32] Guy Podjarny: That's all we have time for today. If you'd like to come on as a guest on the show, or get involved in this community, find us at thesecuredeveloper.com, or on Twitter @thesecuredev. Visit heavybit.com to find additional episodes, full transcriptions and other great podcasts. See you next time.