The $6B Binance heist, Meta’s AI bug tests and looming quantum deadlines Transcript, AI Summary & Key Points

00:00 Panelists, today we're talking bank heists, quantum safes, and pop quizzes. But my question for you is this. Where are you vacationing after your Oceans 11 getaway? I know where I'm going. Back to Japan because there's still food I have to eat there. >> I'm going to Alaska. >> Amsterdam. It's a lovely time of the year. It's a great place to be. And I think it has something to do with Oceans 11.

00:20 >> Switzerland. I'm going to go hide all the money there. >> That might be the best answer. Hello and welcome to Security Intelligence, IBM's weekly cyber security podcast where our expert panelists turn the biggest industry news stories into practical takeaways you can use. I'm your host Patrick Lucas Austin and we've got an interesting set of new stories for you today and an amazing panel of guests.

00:47 We've got Seth Glasgow, Cyber Range executive adviser, Dimple Alwalia, global offering leader at IBM Cyber Defend, and Suja Visen, vice president of security technology. Thank you guys for joining me today. Our first story talks about where we're getting all that money. Um, we're getting it from these Binance hackers. Unfortunately, uh, a hacking campaign directed at Binance, the cryptocurrency exchange, has robbed the company of a few billion dollar worth of cryptocurrency, about $6.34 billion.

01:21 So, they have since recovered or frozen about $2.85 billion of those stolen funds. Binance says it is absorbing the cost of those stolen funds, so users will not be affected by the theft. Um, I find this story to be incredibly fascinating, especially because it is a heist that took a few months to to plan and execute. Uh, Binance says the heist began in June and continued until the end of October after hackers compromised an employes laptop who downloaded an infected version of a MacOSS package manager.

01:59 That hacking did not stop there, unfortunately. In September, another employee was compromised via a job hunting platform. something I'm sure Binance did not want to hear about. Um, where they downloaded a quote unquote assignment during a job interview that compromised their device. From there, hackers were able to use malware and other AI tools to compromise other engineers devices where they were able to initiate these crypto transfers.

02:24 Seth, I'm wondering if something like this was sort of um just waiting to happen. >> Yeah, you know, potentially. This is obviously a very advanced threat actor, right? uh this shows a good deal of research done upfront about the target. All of the pretexts that they use in order to enable the social engineering are incredibly specific and very very believable.

02:44 Right? So it's a lot of planning on the front end to be able to execute this and even gain an initial foothold and then what you see as the attack unfolds, you know, we don't have the technical details of yet this yet, but they were able to um weaponize or use some sort of internal AI tool to expand their access, right? Need to figure that out. But then even on the back end, they were able to transfer the money in a process that was outside of the standard process.

03:09 Which means they had enough knowledge about not just the technical working of the system, but the business processes that would allow them to violate policy rules. All of the controls that would normally be put in place, they were already around them. So that type of research and that type of persistence is what allowed them to pull off at this size.

03:27 since it wasn't a usual smash and grab. This was incredibly advanced deliberate tactics. >> That's a great point at the sort of advanced nature and the that sort of unauthorized access that that they gained. I'm wondering maybe why or whether or not this affects I would say more traditional financial institutions. Are they under the same sort of threat or is Binance being a crypto exchange somehow make it a different sort of target?

03:55 I do believe that it affects every financial they need to be careful right every every one of them it affects crypto it's newer so the regulations are still still work in progress so there are a lot of holes that they can but all of financial industry any any enterprise is can be a victim to this if they are not careful we have been talking about zero trust for years so one thing in this one I find it interesting is that attackers don't think in silos as Seth was pointing pointing it out.

04:25 They knew everything. They don't operate in organizational silos while cyber security does. You have a somebody managing the identity, somebody managing secrets, somebody managing the sock. So there is an organizational silos there in the security side of the ones while the attackers don't think like that anymore thanks to AI and thanks to the scale at which they can operate in.

04:47 So that is the the biggest challenge right now. >> I'd agree. I think in addition to what you just highlighted, Suja, I think uh some organizations haven't gone back and changed their their playbooks either. And so some teams in practice continue to think um they probably like more of a human based routine. So they're thinking like, oh, I need to detect, I need to triage, I need to escalate, and then I isolate and then I reimage the device.

05:14 And that's like a traditional thing where AI just changed the rules of that game. And so if people haven't necessarily caught up and changed their playbook, then there's going to be a challenge because that scenario works well if it's, you know, you've got the attacker slope. But now we're not talking about the same issue. And when you change that those par any of those parameters, then organizations are just getting caught uh in terms of just not being being ready in that case.

05:42 And those who are doing it well, they've stopped relying on a person to make the first move and they're automating and so detection get triggers whatever the containment activity is, right? And they automate it. Um whether it's isolating a device, whether it's killing a session, revoke tokens, all the things you're saying that today are done in silos, it comes together more autonomously um in some ways.

06:08 And then the people. Gosh, we can't underestimate the value of the people because that's what's needed to then kind of play the detective work and see how people connect to each other and investigate what could come next. So that's kind of like the augmentation with the AI rather than um one versus the other. >> Temple, you mentioned zero trust. Sua, you also mentioned zero trust.

06:29 I'm wondering how that plays into um any sort of mitigation strategies when it comes to a bad actor making making their way through a system using you know employee credentials using internal AI tools. Is there a way to sort of you know put these checkpoints in place where every major step every you know potential you know every potential transaction requires a either a human review or a more extensive automated review.

06:59 Um, are there any are there any policies that can be put in place to make these these transactions and these and these changes a little more, you know, give them a little more friction. >> Yeah, I think it's uh I love that word in terms of friction. For once, it would be for a positive rather than people complaining about it. So, make it noisy. It's it's kind of like, you know, you you tie something to like bells.

07:23 Here they come. and and so just kind of get everybody uh alerted to it. And Patrick, yeah, I think so. I think there are certainly activities people can change how they um action or how they operate uh to improve that and and whether people call it zero trust whether they talk like I was mentioning about playbook but you absolutely recommend it is you know people need to be thinking about um uh adding that friction where it's appropriate and then automating where where that's better so you can contain the you know

07:58 first contain the situation with some sort of pre-approved authority for security to isolate a device. So adding friction there would only delay things. So I wouldn't necessarily say everywhere but then you definitely should assume that everything on whatever the device is is is burned. So including whether it's your tokens, your keys, your browser session, whatever it can reach and and and look at cleanup.

08:23 And then third is really about working out what the attacker learned. Um and that's where uh you kind of go into the what they touch and and and from there on right and and then hunt for lateral movement. So zero trust practices play throughout the the course here particularly if you also start looking at treating um internal AI tools like privileged users um which is uh going to put a little bit more focus um and and noise in the in the system so that you're scoping access you're doing the logging you're able to shut

09:00 them off. Um those are the type of things that we had zero trust in our in our current mode of operations that we now to kind of tweak a little bit redefine a little bit of how it would fit in the context of this AI world. simple to your point about what we need to do from a controls perspective. Um you know even you know what was sort of started here was some social engineering and we educate on this but we need to expand that sort of zero trust mentality into the education that we're giving folks from an antisocial

09:30 engineering perspective right hey this was used a very good pretext it was very very believable and so we have to educate employees especially ones with high privilege and high access who are going to be targeted that hey you are going to be targeted these are the types of things they're going to probably come at you so that you can start to be aware of it right AI's transformed how you know this industry works across many facets, but social engineering is similar.

09:54 A lot of the older tells, a lot of the visual hallmarks of what used to be a social engineering attack have faded away and everything looks a lot better. And so we have to sort of be very mindful of how we bake that into training to get folks to be a little more uh unaware, right? A little more zero trust kind of mentality, right? Because uh ultimately we can't patch the people.

10:15 We have to educate them. I think for me the education is from board level to the C level to a new college grad and intern that's starting a company everybody is a high value target everybody is in high value target as we are learning from the news everything that's happening in the world so education goes some ways the bigger thing for me is that assume we are going to be compromised then what if I'm compromised how soon can I stop it right in this challenge is how do to contain once a trust relationship is compromised

10:49 how quickly can you revoke permissions rotate certificates recover from it and then stop the containment right there I think that's why a lot of work even as security product development we are working around it thinking about how do you bring identities secrets certificates machine credentials all of things together so that the attackers cannot exploit the gaps if something happens you're able to cut off immediately that and isolate it because we have to operate at the operate with the idea that someone of us is going

11:22 to get compromised even the smartest person doesn't matter. >> Anybody know that game uh six degrees of separation to Kevin Bacon? >> Oh, sure. >> Yes. when I read this story or when it came about that's kind of like the example that came to mind for me is that you know you have uh where you can well the game is for those who aren't familiar it's link any actor to Kevin Bacon as an actor in a few steps less than six preferably right and in this case of the Binance story it was like the attackers were never one step you

11:57 know they were they were one step away from from the vault they were only few hops away so you talk about a recruiter, an engineer laptop, um AI, internal AI tool, then deployment token. So, they're like in that realm and and Patrick, you touched on a great point in terms of creating that friction. So, Suja, you just said assume that they're already in um and so we would we should look at making each hop harder, noisier to your point, Patrick.

12:24 So, you know, for example, segment those highv value systems as if you are doing wallet signing and and deployment. So an engineer's laptop is never a stepping stone onto the next. So we just have to figure out how to do that. But uh when I was reading through the the story, I was like, "Oh yeah, it kind of reminds us of of the games that we were we were playing in in the past."

12:46 >> Before we move on to our next story, I want to I want to suggest that everybody watching on YouTube uh like and subscribe to um Security Intelligence so you never miss an episode. Our second story involves Meta taking a different approach to automated bug testing that could make it a less human intensive affair. Um, which could be a potential double-edged sword depending how you look at it.

13:10 Meta is sharing the results of its deploying catching JIT tests in its production. The JIT stands for just in time. Um, and this new testing approach generates bug tests just in time for pull requests. Um, so Meta can catch bugs before they hit production. The goal is to generate tests that find bugs with minimal human intervention and uh fewer false positives.

13:35 Uh, according to Meta, they've since integrated JIT tests into their infrastructure and engineering workflows. Um, I'm going to just direct this question to you, Seph. Let's talk about just in time. I've heard of just in time logistics from my uh favorite guy Tim Cook. um just in time compiling what is just in time testing >> from the way the article works is essentially they're having the AI and the LLM's construct test cases to validate the development of the software right and using automated testing is not new but

14:07 using LLM to develop it is quite new and what we see is that in traditional models uh LLM sort of catch a lot of false positives right they are not very high confidence findings uh the way that the tests exist sometimes we can find very literal things but we context and that's very common for the LLMs. And so what Meta has done here that I think is really interesting is they essentially look at it as almost two different testing workflows when they go to generate them, right?

14:31 It is both a uh context unaware where we're just going to hey, I'm going to look at the source code. I'm going to try to find bugs. I'm going to write tests to fetter those out. And then also a contextaware one which is what I think is really interesting where it is not just going to evaluate the code. It is going to read the feature. is going to look at what the intent of the code was, right?

14:53 Building that additional context in um I think that's a really important distinction. Uh back before I got into security, I was in development and analysis space and I did a lot of QA testing and a lot of authoring of manual testing. And as I read this, it sort of reminded me of, oh yeah, well, this is the difference between user accepting testing, right, which is very contextaware, very much about is this behaving right according to a more abstract business rule as opposed to IST, which we call this integrated systems

15:21 testing, which is much more technical in nature and looking for actual backend items. And so I really think it's a good perspective that they've taken to sort of allow the LLM to sort of break that out in this particular process. I find the another interesting um part of this this whole um git testing is the human in the loop versus human on the loop um distinction that that meta is drawing.

15:44 So for example um in the human in the loop scenario a human will review an output before an action but in the human on the loop scenario a human defines a sort of parameters for success um and then the AI sort of executes on that um autonomously. Um SUA the human on the loop human in the loop it seems there are pros and cons to each. Um, is there a way for them to I guess sort of coexist with one another in a in a development environment?

16:16 >> For years we have been focusing at least since the advent of LLM, we have been focusing on how quickly developers can write code, right? But now it it generates incredible speed but the bottleneck is shifting. So what we are learn one thing I'm observing is that AI doesn't reduce the value of experiences experienced engineers in many ways it increases it.

16:38 That's that is the thing that I'm seeing where I want the architects to like think of it as you have an intern driving or uh you have your teenager driving a car you need to give them the right guidelines you have to watch them you have to do see what they're doing so that becomes the most important thing so for a senior engineer to sit there architect for example needs to write down everything so the LLM can operate that's what the human on the loop as opposed to ll they do all the mistake then come to the parents and

17:09 say I had an accident help me um then you're dealing with a mess you have to be there with them driving along with them giving the right directions and what needs to happen that is the part of it where the human on the loop is this is this is extremely important because AI can generate implementation only experience can provide those judgment so that that's what I see it where we need to be working hand inhand with these AI and that's where The jet test is not something that can happen automatically.

17:43 Somebody needs to architect needs to define it, provide the context as Seth was talking about and then tell what we are doing. So it becomes very important that we go back to the writing culture. Not asking AI to write what I want. You have to basically articulate what am I trying to accomplish? How am I how do I want it? What are the guardrails? Everything needs to be defined clearly for AI to develop, test and deploy securely.

18:06 Dimple, the the setup of the sort of human on the loop test, as Suda described, seems very similar to setting up an AI sandbox for testing. Um, you know, as long as you've crossed your tees and dotted your eyes and everything is perfect, everything will go swimmingly and great and the human on the loop can, you know, have lunch and just watch the watch the code roll by.

18:28 Um, what is the what is the downside? what are we what are we losing when we when we sort of turn to a more automated bug bug detection or bug testing uh service like this? >> Yeah, look, I think it's an interesting concept and I I would approach a little bit more cautiously, right? Um so one of the one of the things that we should be cognizant of is that reviewers can lose context and skill if they're only seeing summaries.

18:54 Um and then if there is a drift, it's a possibility if there is a system drift and and nobody may notice because the metrics look good, but they may not have the context to be able to to take action, right? And so plus people are people and and we may get things wrong at times and setting the guard rails may be one of those areas. So we also have to be careful about creating these single points of failure.

19:21 So I' personally I'd love to see some early learnings um beyond the productivity improvements and all that kind of stuff and and do some sort of sampling audits of what the system does not flag. Um and so there's clear ownership of the criteria. We're really looking at you know a rule that the the highest risk changes um and and still get a human to look at it.

19:46 So rather than going it's in my opinion it's a little too early to go on an autopilot. So even even autopilots, they they set the course and they monitor, but they still have to train to to be able to fly manually in the case of an emergency, right? And and so I think in this particular case, I'd say the same is leverage the uh the approach um but put it through its paces and really test it to make sure that one um it's functioning as designed.

20:19 get a little bit more data under our belt um in in that regard. And then making sure that um we don't use this as a yes yet as another means of people having um lack of knowledge uh that makes them uh so much more valuable to be able to help with that human in the loop. I would say that AI amplifies what already exists in an organization. If it's good, it's great.

20:48 If it's bad, it's going to be catastrophic. So you we it basically amplifies whatever whatever we put whatever is exists in an organization. So for me what I learned is that from this AI doesn't eliminate the need for engineering discipline. It raises the bar for it. It raises the value for it. That's what we need to remember. It's you just because it's there it you cannot just throw it out the window.

21:13 It raises the bar. It expects engineers to know the context, know the big thing. So strong architectural p patterns, clear documentation, clearly defined security requirements, good governance, all these are very very important in software development. Whether it's AI doing it or us when AI is doing it, it's all the more important. >> You know, to Such's point too, it's really about a force multiplier for skilled and quality engineering, right?

21:40 because effectively we got to a point where we weren't able to review due to the volume of output. We weren't getting enough human review and it was becoming that bottleneck. Moving to this model, it allows us you know with the proper controls and the proper sort of governance around how this works. It allows us to use the AI to create more test coverage and from that output create higher quality software that's been put through better testing paces so that we have less rework later.

22:05 Right? And that's really the long-term value is let's do this correctly up front and using this as a false force multiplier of good software engineers allows them to really do test coverage that was unheard of previously in terms of depth and specificity given the context. IBM is introducing quantum safe which helps enterprises with their postquantum cryptography migration.

22:33 The unified suite combines planning, discovery, remediation, and continuous governance tools to create action plans based on migration goals. Um, as the cyber security industry is well aware, the quantum revolution is fast approaching with deadlines uh in 2030 approaching from various government organizations asking enterprises to be ready for the sort of transition into postquantum uh cryptography.

23:00 Suja, I want to talk a bit about the the trend or the concern that is the harvest now decrypt later tactic that is um um basically waiting for the quantum revolution. Let's say I've got some data that was stolen in 2021. Do I care that it's decrypted by 2030? Why am I very wrong in saying that I don't care that it's decrypted by 2030? >> There are a few things, right?

23:25 for for us it's it might seem very different from what we talked before but it's all part of the same broader discussion that's number one so for a long time it also felt like a future problem increasingly I'm hearing as you said the 2030 is looming we got decades to pro to build uh quantum computers the NIST got eight years to come up with uh standards and everything all we got is four years less than four years now because we're almost end of 2020 26 so less than four years to get ready for the 2030 deadline.

24:00 So that's why it's become important. Why do I care for the data that is being stolen like four years, 5 years, like seven years back? The reason is that there are certain things like finance, your healthcare data, lot of those live as long as we live. If you're like my like my gene and you have you have grandmother who live to be 100, you need to be saving my data for much longer than many other average people.

24:26 So that is why this becomes very very important. Are we going to be adding to the problem or are you going to get proactively uh solving this problem? Uh that's what get us to where we are today where let's get ready start planning because you cannot protect things that you don't know. We have it's a life cycle problem. First we need to know what am I what where am I exposed discover discovery then you have to go look at it and then say okay prioritize it because you're going to discover all kinds of things how do I

24:54 prioritize which are the top things to do and then go figure out how you are going to action it am I going to prevent it by changing the changing what how the product is or am I going to do it in a way that it's going to until the computers are ready it's going to keep me safe it it's step by step what I'm going to do and then govern it monitoring so that it doesn't drift away from it.

25:20 It's a life cycle problem of cryptography that we need to start acting now. If you are upgrading your hardware, are you making sure that they are quantum safe? If you are already rotating your keys or recreating it, are you making sure so that as part of the basic hygiene, if you take care of it, the problems get lesser and lesser rather than you're adding to that problem.

25:43 Dimple when we talk about postquantum you know migration what does that mean for existing enterprises their infrastructure the tools they use how do they and how do they prioritize what gets ported and migrated first and secured first and what can sort of wait until you know we've made this first migration wave and now we can move on to our sort of maybe less important um or yeah less important data sets for example >> yeah I think Patrick if if somebody knows about their environment really well, they'll be able to

26:15 prioritize what are areas that are going to be a greater risk. It becomes a risk based approach like like most things, right? But I think one of the things that we find is that particularly organizations who've been in business for an extended period of time, you may not always know where things exist. As much as we've all talked about it in the past and and people have yet to still come up with any um uh really strong uh you know uh asset inventory kind of a of a situation where it's not just the the knowledge of the

26:49 asset but then what are the applications running on it and what may be um some uh interdependencies or linkages like until that happens I think people really need to think about is yes you'll have knowledge about a finite set of things in your environment and you make a decision in terms of what will have the most impact and you start working on it and to Sua's point some of these areas are going to take an extended period of time you're not going to go and refresh all your hardware overnight so as you are doing things

27:20 between a combination of the high-risk and then looking at your existing whether it's business as usual or transformation programs is really bringing that information together to say what are areas that I can catch naturally naturally because it's my business as usual. I'm upgrading a network. I'm making that's one aspect of it. And then others are going to be a little bit more targeted.

27:41 So people can people can certainly go go down that path. And it kind of brings us a little bit also back to what we were just talking about a few minutes ago on zero trust. Same principles, right? When I think about PQC, um, one of the the things is that some organizations have a focal that's spearheading and driving adoption, making sure that they're doing the socializing with different parts of the businesses and line of businesses and and everything, but um, it still requires that coordinated um, orchestration

28:14 operation kind of a thing, right? so that people are looking at every aspect in of PQC from the network to the identity to the data to the applications and and so on. So I think uh when when we're thinking about uh how to prioritize um people are really going to have to look at the information in context and and then make some judgment decisions around what is high risk to them just like we used to say your crown jewels may be very different than other organizations.

28:44 And so I think it's in it's a similar fashion >> and and those crown jewels are even more specific. I know that SUJ mentioned healthcare that has to be protected for well past 2030. There's also internal uh data that you have to consider in this as well in terms of if you're a production company, you manufacture something, internal formulas, uh financial uh firms and proprietary trading algorithms or just general best practices, institutional knowledges that organizations have built that sort of translates to their

29:13 intellectual property and sort of that confidential data. You know, a formula for Coca-Cola or something is going to last. We need to protect that forever. that outlasts all of any other data type, right? That is the that is the product so to speak. So there's a number of data types like that. And I think I kind of whenever we we talk about quantum in the range with clients, I always sort of mentally come back to sort of the way we look at Y2K.

29:38 Well, hey, nothing really happened. Well, the reason nothing really happened is because we took a yearslong, very concerted effort as an industry to ensure that nothing happened. And so now we look back at it like, oh, that was all a bunch of nothing. Well, it was only a bunch of nothing because we took a very serious and strong effort to make sure it was nothing and and we need to do the same here as it relates to quantum cryptography.

30:02 >> I will also add that it is it is like in some ways like Y2K and some ways it is not because it will come in waves. In Y2K you you fix the dates, it took a long time, you fix the dates and you were done. Here that's not going to be the case. The algorithms are going to keep on evolving things with AI with quantum everything is going to evolve. Agility becomes very important.

30:23 Agility matters. Binance's story because if you cannot quickly rotate certificates, you cannot if you cannot update the trust relationships and if you cannot up update your cryptographic infrastructure, every future migration becomes harder. So that's why this becomes very very important. And when I'm talking to clients, what what they are not worried about the mathematics of quantum computing.

30:47 They are worried about execution because this is not this is a people process and technology problem. Okay, that's what it is. It's it's a technology problem for sure. But the bigger thing is how do we discover things? How do I manage transition? If I have applications that have been running with with us not looking at all, now that application belongs to a company that doesn't even exist.

31:10 Now I have to migrate my entire system off of that product that I have been using because that company doesn't exist. So there are so many layers of it that it needs to be looked at. That's why I would say it's more of an execution and a people challenge, people and process challenge bigger than the technology. That's why the companies that are going to win are the ones that are going to start early, not the one that's running fast.

31:32 They need it's like a marathon. You need to start early. >> Absolutely. I mean, it's right now we're we're telling you if you do not start now, you will have an sort of just exponentially increasing technical debt that you will have to solve almost instantly if you don't start to plan for this now. And so, um, this is this is about the last time to actually buy time, which is a general difficult thing to get.

31:54 >> Yeah, I don't think there is an instant in that one, Seth. I don't know if I'd be really surprised if somebody can do it instantly. >> And I think that does it for today's episode. Thank you very much to our panelists Dimple, Seth, and Suja, as well as our producers. And thank you for watching and listening. Please subscribe to Security Intelligence wherever podcasts are found so that you never miss an episode. And stay safe out there.