“Security is the study of failure. It's about systems that fail in ways that expose confidentiality, integrity, availability – even great platform engineers don’t necessarily think about failure in the same way.
“Security people think about that a little differently,” says JPMorgan’s Global CISO Pat Opet, sitting down to chat with The Stack – and tackling a question about how security is evolving with changing architectures.
In a number of recent conversations with digital leaders, security teams failing to keep up with evolving infrastructure needs has come up; one chief cloud architect for example recently telling us that their platform engineers were more important to the security of Kubernetes-based workloads than their security function (“who don’t get it”) would ever be.
To Opet, who owns cybersecurity across JPMorgan’s colossal technology footprint, the answer to a perceived failure among some security functions to “keep up” is, in part, ensuring security engineers are deeply embedded across an organisation’s lines of business and not siloed.
He points to a recent project in which two teams were “building functionally the same thing.” One had an embedded security-specific engineer; the other was a team of high performing engineers that didn’t. When it came to delivery, the latter had not thought of “all the failure scenarios that were top of mind from a cybersecurity perspective,” whereas the team with the security engineer had designed for them.
“Security engineering is a specialty that needs to be a part of the team building functionality,” he reiterates to The Stack on a recent call.
It’s a tangential point in a broader conversation that spans open source software security and supply chains; threat intelligence and geopolitical risk, but an interesting one regardless that highlights two mission-critical components to Opet’s remit: The need to think differently or bring a unique lens to the nexus of innovation and risk; and the need to ensure technology systems resilience at one of the world’s largest banks.
JPMorgan's Global CISO Pat Opet: Where it started…
JPMorgan’s Global CISO tells The Stack that whilst his formal training in cybersecurity started with an “NSA-certified master's degree in what was called Information Assurance with a lot of forensics and cryptography” it was early in his career, working with some hands-on defence-sector cybersecurity challenges that he really knew where his passion lay.
At Lockheed Martin, where he had a “great leader who put me in a cybersecurity training class run by the company about how to defend the firm from risks like intellectual property theft. I went to the training class, and the trainer said, ‘it's a week-long class, and we'll stay as long as you want every night. I think on the first night, as it eclipsed 1:30am, the trainers were regretting offering extended time” he recalls wryly, “but I walked out of that training class thinking ‘this is what I want to do!”
Opet went on to spend time in the Middle East, with some large firms that suffered cyber attacks, helping to guide their path forward – before being hired by JPMorgan in 2014, after the firm dealt with a very public data breach that affected 76 million households.
CISOs should have engineering chops
“I came up through the engineering side of things, and then eventually security engineering” he says. “I think that has been a great enabler.
“A lot of what security teams do is helping technology teams or the business achieve its goals – many of those goals at this point in time are rooted in innovative technology and for me, the engineering bent associated with this responsibility is something that I think aids me.”
Some genuine technical skills are important at CISO level, he suggests (touching on something of a perennial debate around the depth of engineering/networking/information security expertise a CISO needs to have; some come from a GRC or less commonly, even legal/finance background). Engineering capabilities “in my view needs [to be] a little bit more of the sort of standard for CISOs going forward” he suggests gently.
Opet is a relaxed conversation partner for someone overseeing security for a firm withover 35,000 developers and nearly $4 trillion in assets under management. Discipline learned over the years about when to let yourself switch off and having the backing of a great team all help maintain sanity, he suggests; so, no doubt, does having a significant budget (JPMorgan spends over $600 million annually on cybersecurity) and supporting executives who recognise the risks. But what does keep him up at night/what are some of his biggest current security concerns?
Geopolitical risk and running CNI
“First and foremost, top of mind is geopolitical risk” he says promptly.
“We operate in countries all over the globe, the world doesn't appear to be getting any safer.
“As part of the underpinning of the global financial ecosystem, we are a component of US critical infrastructure. As such, we look at disruption or recovery in a different light with respect to the services that we run – if they weren't performing, it would have a significant impact on consumers or on the market… We spend a lot of time on the resiliency and the protection of those services and our ability to recover them under any kind of threat condition.”
“So that's bucket #1: Geopolitics and critical infrastructure and ensuring that we can be resilient to changes in the geopolitical ecosystem.
Ransomware and threat intelligence
Opet is speaking to The Stack before the US subsidiary of ICBC, the world’s largest bank, was hit by ransomware, disrupting Treasury trades and refocusing minds from such attacks of disruption to the financial system, but ransomware is already top of mind for the JPMorgan Global CISO.
Continuing that conversation about threat landscape, he says: “Ransomware, has become so disruptive to the broader supply chain, the subsidiaries and others that we depend on – and it's become very profitable for bad actors – that we've put a lot of time and attention towards how we get ahead of, or disrupt ransomware operations.”
What does he mean?
“Some of our Threat Intelligence is turned outward on our supply chain; we assess our suppliers the way we analyse ourselves… we look for pre-compromise activity, for ourselves, as well as for those components of our supply chain where we feel disruption could cause harm to us… So we've kind of opened our aperture on what we collect on and what we analyse.”
It sounds compelling. How embedded does this mean JPMorgan is in the supply chain; is he referring to actually putting software agents or toolings in partner ecosystems? Not exactly: “We acquire a lot of raw data, use advanced analytics, and monitor the ecosystem constantly.. We've invested really thoughtfully in cyber intelligence. It's been a central focus of our programme for a number of years and so far, has been effective. Our goal is to tip off the ecosystem that attack activity is starting, help where we can do disrupt it, and ideally help to prevent any impact.”
"They're pretty dangerous..."
“I'd say the third component in terms of the threat landscape is what the sophisticated actors are doing; think of North Korea's entrance into the cryptocurrency ecosystem… that’s everything from ‘proper’ software supply chain concerns, through to [the risk of a] foreign actor embedded in a US technology company all the way through general concern about geopolitical instability and funnelling money into North Korean weapons programmes: You can't sanction North Korea more, there's nothing left on the table. So they kind of operate in a world where there's no impact [consequence] for actions they take, therefore, they're pretty dangerous.”
Stepping back to a more internal security focus, Opet’s team sits on the board of the OpenSSF Foundation. He recently highlighting the use of frameworks like Sigstore and its Alpha-Omega program as critical to improve open source software (OSS) security and urging more public-private collaboration. When it comes to ensuring secure development processes, whats the focus and the biggest challenge at global banking scale, does he think?
“With 35,000+ software engineers, we have to automate the mechanisms by which we deliver requirements and test for compliance” he says.
“We spent a number of years kind of building a front door for developers that allows us to profile what they're doing, then gives them the security requirements which are inherited into their backlog. We try and make it as easy and explainable as possible in terms of what you must achieve from a software engineering standpoint – and then on the other side of it, we have built this massive data collection ecosystem, to pull all that data back, centralise it, score it for risk and expose it to [security] teams. That becomes an interesting data set for our partners in audit, risk and others.
“As you know, security is designed around defence in depth and not every weakness that we can discover is meaningful. So we try to contextualise this data within the risks that we're managing, such that we can really differentiate between those things that are compliance issues, and those things that are true security, or resiliency issues. It's a pretty hard problem; there’s still a lot of room for growth across the industry.
How so?
“As an industry we’ve had this explosion of posture management tools, cloud posture management; data posture management… but if you listen to the conversation around those, there’s CISOs enamoured with the amount of findings that they're producing, as if findings are the value.”
“I think we’ve recognised that the findings are interesting, but they're not always important. We’re trying to avoid adding friction to the development process; making sure that when we ask somebody to do [security] work there's value behind it; it's not just for compliance…”
“It’s taken a big mental shift”
“Frankly, we haven't always been kind to our development process, we've imposed a lot of requirements that create friction. I'd say JPMorgan is a pretty transparent place; you know where you stand all the time! We re-designed our (security) teams in such a way that we're coupled with the product teams that are bringing capabilities to market.
There's a development pipeline [team] that supports the full end to end journey for our developers. Our security team is embedded in that pipeline team; whether on compute or databases we’re trying to ensure that when products are released for developers to use, they've got the full complement of feature and security embedded in.
It took a big mental shift in our world to say, ‘the security accountability is not on me to ensure that the database or the computeor the product is secure. It's on the product owner, and we embed the security experts in the team to help accomplish the goal. This helps the developers have full responsibility and accountability for their systems including the security, compliance and resiliency of it.
In addition, we measure where we’re succeeding and where we’re not. That ‘take your hands off the wheel’ thing for CISOs is really hard. But you can't scale otherwise. Security has to be the development community, and it has to be the infrastructure teams.”
Physical supply chain risk versus software supply chain risk
An often overlooked talking point among CISOs, The Stack suggests, is physical supply chain security. How does JPMorgan, which still rolls a lot of its own infrastructure, handle that? “We take pragmatic steps from secure boot while we're loading configuration files, looking for signed files, etc.” he says.
“[But] the reality is that hardware supply chain attacks are pretty hard to scale.
"There's far more opportunity to scale out a software supply chain attack than hardware – which often requires interdiction and access to the chips or access to the board. It’s a super targeted thing that's used by state actors for very intentional purposes. But take SolarWinds or an attack like that, which is only one kill chain that you've got to execute; that's something that I think the industry is generally still behind on and a more scaled up, more pressing threat than hardware supply chain attacks.
"We've looked at for years how to get better there. We’re starting to see some smaller technology companies that can help mitigate the software supply chain problem," he muses, adding: "Industry has gotten good at identifying vulnerabilities in the supply chain; SBOMs and so on.
"They're not good at insidious backdoors and logic issues that are built into software, and update mechanisms that could cause insertion or implants of malicious software; that's just not something the industry is focused on today.
"We have to rapidly get better otherwise… well, we’ve already seen the problem there. That’s part of why we're doing what we're doing with the OpenSSF – but we need better mechanisms to evaluate commercial software for malware as well.”
Join peers following The Stack on LinkedIn
