Curing Inventory Paralysis: Perfect Data is the Enemy of real-world Progress

We're looking at thousands of systems with tens of thousands of subcomponents and dependencies and the data is never complete. Welcome to Shielded, the last line of cyber defense by PQ Shield, the podcast where we are moving the conversation around post Quantum Cryptography from the why to the how. I'm Joe Lindson, your host and I'm here to guide you through the challenges, innovations and solutions that will help your organization stay secure in the quantum era. Let's future proof your defenses together. Welcome to Shielded. I'm your host Joe Linson and today we're joined by Anthy Roponen from IBM Consulting. Anti serves as global quantum safe transformation leader where he drives the execution and scaling of quantum Safe programs across EMEA. He works directly with CISOs and CTOs to help the world's leading organizations move beyond theory and into real world migration. Antti welcome to Shielded. Pleasure to be here. Thanks for inviting, thanks for taking the time and of course I'm curious, looking at your background and how long you've been swimming in the sea of quantum migration, you've already been diving into this topic, I believe since 2019, before most enterprises were even discussing the looming quantum risk more broadly. So what made you convinced at that time that this wasn't just theoretical issue? Yeah, it's definitely been a while. I think obviously IBM and IBM Research specifically has been in the game of quantum computing and post quantum cryptography for quite some time now and part of the niche process and so forth. But for me, I think really the pivotal year was 2019. I think there was something before that as well. I had the pleasure on having a couple of very enthusiastic people in the team, Joachim and Niamh, that were very much into believers already back in the days, back in 2018 or so. Working very closely with the research and obviously hanging out with these guys made me think that, hey, maybe there's something. But I was still a bit skeptical. But then I think it was July 2019 when we started our first project and my first project, Quantum Risk Assessment project for a South European bank, was kind of funny that we were calling it quantum risk assessments, where kind of those were starting to pop up now with many companies. But we were doing that already then. But that first project was really, I was skeptical before that, but I think that project there really made me realize the complexity, like how things are interconnected and interwoven together, the dependencies and really the scale of the problem, not from a technology perspective, but from a transformation perspective. And also it was a risk assessment type of project first to understand like how is cryptography handled, where are the risky spots, like all of the usual typical stuff that organization nowadays do. But then it was quickly pivoting into architectural planning, like designing crypto agility architectures for the main business channels and services. So that also helped to understand really that hey, this is not just like a lift and shift, like flick switch type of thing it requires in a large organization. It requires a lot of work and it requires like very sort of multi headed beast type of operations. And I think that was like really pivotal for me to really understand it from firsthand that hey, this is not just a technology thing, this is major thing. And then if it's like this for a one still like small but fairly large organization from a European scale, like what does it mean globally? And that was a light bulb moment for me to understand that hey, there's something I want to learn more and I want to do more on this. So that was probably the moment. It's interesting that you, even in those somewhat early days, the initial realization is that hey, this is really an organizational challenge and not just one that sits in the realm of technology. I think that's fascinating. And that view probably hasn't shifted too much over the past seven, eight years that you've been doing this. And I think fast forward and part of the reason frankly we're speaking today is that recent article that you published on LinkedIn that caught my eye and I'm sure many others as well. I think it was titled something like Quantum Safe is the new cloud migration and let's not repeat the same mistakes. So I'm curious to hear your take on that because obviously we've learned a lot from the idea of cloud migration is a lift and shift. Right. And so what are the risks of running into those same mistakes once again? Yeah, and that sort of comes from the whole article and such. Before even my quantum safe days or before those first projects, I was working very much in different type of cloud migration and modernization programs, like looking after the security and ensuring security is embedded into the programs, but also learning quite a bit the maturity shift from the early days of cloud migration or kind of that just was cloudifying things into how things are run now. And there's been quite a bit of a learning curve. It's interesting you mentioned lift and shift. I think that's probably one of the first things on a lot of organizations in the beginning of the cloud migration era when things were starting that was top of mind, like lift and shift versus how is it now? On real transformations. So early cloud migration programs basically were focusing on just moving, hey, let's take this workload on premise and move it to cloud and rinse and repeat that a hundred times or a thousand times without really thinking about the architecture or redesigning the architectures and so forth. And I think the same, it is one of the analogs also to the quantum safe effort that it's easy to think about just like hey, let's just swift a configuration or algorithm or whatever like without too much paying attention that hey, there might be a need to completely re architect and introduce crypto agility. And it's not just like a flick switch exercise. There are many other areas as well in sort of the analog that I've faced and still facing in the quantum safe discussions around that, hey, you're talking about this. But actually it's basically the same stuff that people were talking about with regards to cloud migration in 2016, 2017, 2018 type of things. So there's a lot of lessons learned that we can work on. One of the things and which is quite obvious is the sort of the inventory paralysis. Well, if you look at cloud migration and the cloud journeys, they often in the early days they were stalled because of trying to understand a comprehensive and hundred percent accurate CMDBS or cloud and application mappings and comprehensive and executing those like cloud or application mappings on premise. And we're basically or we in the quantum safe space try to do the same thing like hey, before we can do anything, before we can move the needle, we need to have a complete visibility and only after that that we have the complete visibility we're able to do stuff and so forth. So there are a lot of those similarities between the cloud migration and modernization during Those early days, 16, 17, 18 odds compared to maybe the 25, 26 of quantum safe migration these days. So really like you said, right? Just looking it as a flicker switch changeover, really missing out on the opportunity as well to revisit architectures that were established in a time when on PREM and ownership and all that was a given and not really also reaching all the promises of optimization that the cloud has brought to the way things are organized, things are architected, like you said. And then I think your point about inventory at the time, it was even just understanding what type of applications do I even have on PREM and what are they even doing. And I think you've just used the term of analysis paralysis or inventory paralysis. Right? Where organizations in the early times, the first step that was recommended for quantum safe migration is always get an inventory, get an inventory, get an inventory. And I think in the conversations that you and I had previous to this podcast, you did mention that you notice a little bit of this perilous. Alice is speaking to your clients, so maybe you can speak a little bit about that as well. Yeah, and obviously we've been engaged, and I've been engaged in many of large scale projects to try to build an inventory, but very often the scope becomes way too large. Like in a large organization, we're not looking at hundred systems and such, we're looking at thousands of systems with tens of thousands of subcomponents and dependencies. And then if you do the math, it starts to grow quite a bit and it seems to be that the data is never complete. You run a scan or you use an existing inventory from other tools and two weeks later it's showing different data. There's a gap in quality, there's a gaps in the findings and such. It sort of starts to be a never ending story. And then quite often there's been exercises to run inventories across like very large amounts of the enterprise IT estate. You get a ton of results, you get a ton of findings, but then what are you going to do with those findings? Like are they really actionable? Is there really a link between what you found through discovering inventory on the surface versus how are you going to prioritize where you put your eggs and what's the best value for the buck? Are you just looking at the surface of the problem or are you really understanding the root causes? Because it might be that you're looking at one system, but then that's connected to three other ones. And actually the fourth one is really the one who matters, who is behind the problem. And you're not necessarily understanding the dynamics, the dependencies by just surfacely looking at that, hey, here's a library, here's a key, here's a certificate, and so forth. So it becomes non actionable and going forward and then typically stalls the whole journey going forward and taking the next steps. So I heard prioritization, I heard interconnection of those applications and system parts that you find in dependencies. Right. So those seem to be the core items to take care of if an organization wants to step into sort of more mitigation, remediation phase of such a project. So how do you typically guide on avoiding these traps and falling into this analysis paralysis? Is there sort of a slightly different approach to it or how do you approach that? I think many of the best ways to handle this I've seen in practice are really down to thinking a bit on the risks and the threats and doing sort of a classification understanding really from a quantum threat perspective and the different types of quantum threats perspective, not only like harvest now, decrypt later, but like now even more and more based on the latest insights on things around threats, around authentications and tokens and things like that, like understanding that, understanding also the mapping between those threats and the different systems and applications and then making a risk based approach in a certain company or in a certain field, you may want to prioritize a specific type of threat over another one, or you may want to kind of based on your budget, based on stakeholders or the context, you want to focus on a certain area. And doing that analysis first seems to be working because you're not wasting time and effort and resources, which typically are very limited on just doing an inventory of the whole thing you focus on, hey, let's double click on this one. Because that is what we see from the risk classification the most interesting for us. And then even with partial data, partial inventory, you can make some plans and start mitigating or start at least planning the remediation. So no need to wait for a full blown inventory. And I think that also goes back to the earlier discussion about the analog and the lessons learned from cloud. Like I don't think everyone remembers it's now so common to talk about landing zones and best of practice architecture patterns in cloud, but that was not the case like 10 years ago. And if you look at the analog like when things started to move, that hey, here's a landing zone, here's a pattern you don't need to know everything about. So you can just like, okay, if we go to this landing zone, if we follow this target pattern and reference architecture that ensures that we tick the necessary boxes. So combining these two in a way that taking the risk lens, taking the prioritization based on the risk and threats that matter the most to you and are the contextual, and looking at mitigation tactics and those sort of cryptographic landing zones, if I may, and moving towards them, that probably ticks a lot of the boxes without going the heavy lifting of full blown analysis, which probably never is complete because things are changing all the time anyways, right? So don't let perfect be the enemy of good enough to some degree and really doing those inventory definitions to a point until such a time that it allows you to translate the quantum threat. Like you said, harvest now, decrypt later, or trust now, forged later authentication, depending on what your specific use case and organization is to be able to translate that technological quantum threat into a business risk and then be able to lead from that risk perspective that come up with the risk mitigation plans. Now I think we're in a phase where a lot of organizations are switching over to more mitigation remediation phase. There are, you know, some of the large organizations I'm sure that you work with that are now also finished with some of their pilots of specific cases and are looking to scale. So I'm curious to hear your take on successful ways of scaling from this one initial pilot case to, you know, you did mention it earlier on thousands of applications and systems and dependencies. So where is sort of the key to do the scaling right? And that in many instances what I've seen becomes a sort of a gatekeeper that you've done some pilots, you've done some even testing on some mitigation tactics and techniques, maybe deployed some PQC technologies and so forth, and run some awareness. But then it almost like this glass ceiling effect that you can't really push forward. And in most cases it's because you're still looking at from a technical problem versus looking at it from an organizational problem. And how do you run enterprise wide or organization wide transformation and it's a cultural transformation, it's a behavioral transformation. And how do you coordinate hundreds of different teams, application teams, platform teams and such potentially that are scattered across globe, across different business units to take action when they have other competing priorities and other dependencies. So building that vehicle, that governance structure, organization structure and motivating people to take action and to make it easy to take action becomes a lot of the focus versus to technical proof of concepts and such and also understanding and what we've kind of discussed with many organizations and typical questions is like how do you drive a transformation overall in your organization? And sometimes when the quantum safe program is initiated in the security organization or in the operational cryptography, they don't necessarily have the visibility on how is this, how is my company driving organization wide transformation? Right. Too much in their own silo. Yeah, too much in the silo. And looking at like these are things like you could think about other things like business like changing regulations or kind of tariffs or geopolitical situation. How do you adapt to these type of new risks or new changes? What is the de facto style and technique and structure you need to orchestrate yourself to efficiently execute these type of changes? And that's not trivial in many organizations and that requires that structure and change of the governance, change of the practices and change of the maturity of the Quantum Safe program. From hey, this is a cottage project within security into hey, we're talking about an enterprise wide transformation. So looking at the programs that you've been involved with in those large scale transitions, in the cases of projects that are going well or are somewhat successful, who would typically own the overall responsibility of such a transformation program? That depends and varies between organization to organization. We did this or IBM did this study. Last year was an Update on our 2023 study, Quantum Clock is Ticking or something like that, where we interviewed and studied quite a number of organizations that are fairly large and interesting finding for me, which I was sort of having a gut feeling already. But the study proved that it's accurate that in many instances the Quantum Safe program is not owned by the CISO. The study showed that only 11% of the organizations that we studied, the Quantum Safe ownership lied within the CISO organization. And then if you calculate the CTO office, the Chief Information Office, Head of Technology Strategy and transformation and even CEO have counted more than 50%. So in average, like just based on that study alone, in a typical organization, the Quantum Safe transformation is somewhere outside of the CISO organization because of the magnitude, because like you need to really get on board the full organization for the chain. So Natural Place is maybe a CTO office or head of Technology transformation and so forth. I would think that organizations that already have like a digital transformation office or something similar like that would be the natural place to run the Quantum Safe Migration program as well. Now, in one of your earlier remarks you did mention regulations, so of course I want to dive into that topic as well. Especially given that you focus a lot on emea, but you know, it's global multinational clients that you work with. I'm sure things like GDPR and even more now the Cyber Resilience Act, CRA are high on the list. So I'm always curious to hear if you see this regulatory framework as an enabler, as somewhat of a gatekeeper or something in between and what are they doing to, you know, speed up or slow down those migration programs? I think for a speed up perspective, doing analysis, doing risk classification, doing that kind of a threat analysis of your critical assets and applications from a quantum Safe perspective, looking at, hey, how is confidentiality handled in an application or integrity or availability? Typical CIA triad. Well, the same CIA tried, you're probably going to touch in those other regulations or those kind of frameworks as well. So if you've already done that, that is beneficial for the quantum safe journey as well. So you probably get two flights at once or vice versa. If you are successful in doing that in the quantum safe space, that could potentially feed into your work with NIST2 or others, or potentially even GDPR, if that's not finished yet. But then the question is like how much do you want to wait on the compliance versus the risk reduction or building the quantum resiliency? And the way we approach it and recommend to approach it is to have the regulation and the weight of the regulation as one of the factors for the prioritization. So where you understand your threats, your applications, you look at it from a risk perspective, you understand the quantum risk associated, you understand from a business perspective also the value of those assets. And then you need to have a third factor which is from a regulatory perspective. What does that mean from a regulatory perspective? Is it something that will boost up the prioritization in relative to others or will it turn it down? And then if you sort of look that through a lens of the complexity and the amount of dependencies those assets and applications are, you come up with a very good way to prioritize your efforts which take into account not only the risk score, not only the value, but also risk value and the regulation. So the regulation is a factor in the priorisation. And then by that you avoid on just doing a tick box exercise that have regulation, we've done yada yada yada yada. But you actually look at it also from like, hey, we're making our company more resilient for the quantum threat. We're handling the risk, we're doing the effort and we're focusing on the stuff that values the most. So it becomes a balanced prioritization versus something that is only from one direction, more of a holistic approach to prioritization. Like you said, not looking at compliance as a checkbox mandate, but really using it as an additional tool to prioritize your activities and your next steps in that migration process. It's very interesting approach there. Thanks for sharing that. And then of course the other thing that you did mention is budgets, right? Who's going to pay for all of this? None of this is going to come for free, this transformational programs. So how do you support someone who needs to make a financial case for such a multi year transformation program within their organization? What are some of the best practices, some of the language that you've seen working in your cases? And there are probably a few different angles to it, but a common theme when talking to senior leaders, talking about building a business case, a compelling business case, is really about how do you quantify, how do you make it tangible? Because for a certain level of leadership, if you say that hey, we've done an inventory and found 300,000 of bad things, then it's like okay, what's that? Like what's the value, what's the risk, et cetera. So the case is really about like what are the quantified metrics that you can show the risk reduction over time? Like how much are you actually reducing the risk? Or building resiliency year 1, 2, 3 onwards. That's one factor. The other one could be to look at kind of the same way as in the cloud transformation, like the cost reduction and such was one. But also looking at the technical debt, which is sort of the future rework cost. Like what is the potential and how do you avoid the future rework cost? That's also something that's typically interesting. So that ties back to the crypto agility aspect that you mentioned earlier as well. Like redesigning some of your cryptographic depth in your systems. Exactly. But also kind of alignment with existing programs. So if you're anyways running some digital transformation or introducing new capabilities or moving from legacy payment systems into new or whatever that might be moving from mainframe to something more robust, if you're anyways running those existing in flight projects, like if they're continuous as is, without any change of direction, any new policy standards or guidelines when it comes to cryptography, you basically, if their project is a three year, you end up like garbage after the three years. And then that garbage has a cost to actually mitigate. So you want to get funding for something small now, which avoids the future rework cost, which is cumulative over those potential existing projects that will create that new legacy per se. So to include some aspects of the quantum safe migration into existing refreshment programs that your IT department likely knows how to run and operate. And there might even already be budget for it in the usual replacement cycles there. Exactly. And not budget only, but also focus. Like if you have an organization that has hundreds of teams that work on different applications and platforms and if you can influence 90% of that through existing programs, that's probably a better way rather than introducing something else on the team's backlog because they're kind of a first in, first out type of thing. So you want to be on the top of the list versus the last one on their list. That creates focus and momentum as well. Make sure you get the prioritization. So with everything that we spoke about. I'm curious to hear your take on how is this and you've said that in between here and there, how much of this is generally applicable and how much of this is going to be very different for say a financial organization versus a pharmaceutical versus an energy provider or industrial Iot out driven organization. What are the nuances here? Each organization have their own nuances for sure. If you look at banks, banks are very much. There's a very big tension to keep things running. You don't want to end up in an ATM and you don't get a cash, you want that, you want your mortgages paid and so forth. So that's one thing that you need to balance with the cryptographic modernization or quantum safe. But it doesn't necessarily need to be a trade off between those two based on the right type of prioritization, right type of planning of different smaller iterations or wave based planning. You don't need to modernize everything at once. And you can focus on the critical systems, the critical trust flows and maybe some anchor points or hot points where you can quickly introduce change in infrastructure or key management and so forth and then roll out incremental and have good plans on rolling things back as well. Right. Typical type of practices in system deployment. So that allows it to balance between what the bank expect from an like an operational banking perspective and also from an operational banking regulation perspective. But then the quantum safe and sometimes what we see is that like even analyzing banks, the operational banking requirements and the banking resiliency requirements are somewhat the same from a quantum safe perspective. But there is a lot more in the quantum safe space that you need to take into account so you can sort of mix and match and balance things. When it comes to other organizations, similar type of thinking process needs to happen. If it's a pharmaceutical, for example, there's most likely some clinical trial data that is very sensitive, needs to be secured for decades going forward. But on the other side, sort of the other thing to wait is for example the supply chain, the critical manufacturing operations day to day, which could link into the availability of medicines for the citizens and hospitals and such. But there you also, if you look at it from a quantum risk perspective, where is the risk accumulating the most probably is where there are the long late high value data. And maybe you want to focus that first and then very quickly after that shift focus into the more of the operational systems where there are a lot of integrations like potentially third party external facing services, partners involved, third party technology involved and so forth. So it's not either or trade off. It really goes back to understanding like what matters from a risk and threat perspective and where do you want to place your egg and doing that going forward. Yeah. So that sounds like a very actionable advice. Right there is to start with the most vulnerable data and then do your application mappings, look at your highest risk profile and get started with, you know, small chunks. Don't look at this as a sort of a big bang changeover. Exactly. Don't get stuck in the analysis. Right. Exactly. So talking about analysis paralysis and misconceptions, as we start to wrap up this conversation, I'm curious and I'm not going to ask you about the date that we're going to see cryptographically relevant quantum computer. I think that's one of the misconceptions that we actually have something like a Y2Q with an actual date. So I'm not going to ask you that. But I'm going to ask you what is the biggest misconception about the quantum migration that you're facing as you engage with those leading organizations? You sort of answered that partially already. I think it's even the speculation about when do we have cryptographically relevant quantum computers or when the potential attacks come and such that easily links to the thinking that hey, it's a future problem. I think the biggest misconception is that hey, it's not now, it's somewhere in the future, whether is it near or longer term. But like that's something that we still face quite a bit. No need to consider it now in the future perhaps. And then to replace that misconception with something actionable. What behavior, what initial step would you recommend organizations take and can take relatively easily today? The no regret sort of actions. Well, don't treat it as a quantum safe transformation. Treat it as more of a business as usual ongoing engineering transformation. Like how do you change engineering practices, your technology development practices and so forth on an ongoing basis which you can start now. You don't need to give that a fancy quantum safe label. You can just talk about it on the terms as is. Fantastic. Anthy, thanks so much for sharing your insights and I always like to ask the question of where is a good place to follow your work for our listeners if they want to see more of my work. I try to Keep posting on LinkedIn or Medium quite a bit, typically late at night. Some thinkings that comes to my mind, some lessons learned from the field and that's probably the best. Also attending quite a number of different sessions events across the globe. Fantastic. Great. Well, thanks for sharing your insights Santi. Appreciate it. I know you have a busy schedule so appreciate you joining us here today. Thank you very much. It's been pleasure. It's always fun to talk about these topics. Absolutely. Thank you. And to our listeners, as always, thanks for joining us today. Don't forget to like share and subscribe so you don't miss a future episode. In the meantime, subscribe, Stay safe, stay vigilant and stay shielded. Thank you. The Quantum Era is already here. With the right tools, the right knowledge and the right mindset, together we can face it head on. To find out more about PQ Shield and how our cutting edge solutions can help you secure your data against the Quantum threat, visit pqshield.com make sure to search for shielded, the last line of cyber defense in Apple, Apple Podcasts, Spotify or anywhere else you get your podcasts. Don't forget to click subscribe so you never miss an episode. On behalf of the team here at PQShield, thanks for listening.