Gediminas Černiauskas: Resilience Under Fire: Lessons from Cyber Defense in Ukraine

This talk addresses the lessons learned from cyber defenses in Ukraine, particularly during the ongoing conflict. The speaker emphasizes the importance of understanding what security measures hold up during extreme stress and the necessity of applying practical controls rather than relying on assumptions established during peacetime. Case studies from attacks like LockBit, Viasat, Industroyer, and Kyivstar are discussed to illustrate the vulnerabilities exposed under duress, particularly concerning administrative controls and the trustworthiness of dependencies. The speaker proposes enhancing incident response plans by factoring in connectivity loss and the realities of decision-making during crises, urging organizations to test assumptions, prepare for unexpected scenarios, and focus on fundamental security controls. Through these discussions, the talk highlights that robust cybersecurity is about maintaining discipline in basic processes rather than relying solely on advanced technologies.

Thank you. Um, so I guess most of you were here on Wednesday and you maybe got a bit of taste of uh some of the alerts on the phone. So, that maybe has contributed to the audience in the room. Looks like we only have a few spare seats left. Um, but I wanted to start with uh telling a little bit about what this talk is about and

what it's not about. So, this talk is not about sort of geopolitics and attribution on the very high level. And it's also not about uh malware reverse engineering on the low level. And that's why kind of I picked this topic because of I think over last few years since the full-scale invasion, we've seen quite a lot of um talks and research and and and posts about the

very high level, sort of the 30,000 ft up there, and also some very good and solid research on the malware level, reverse engineering the malware and the attack path. But, I think what we maybe haven't seen as much of is that middle, sort of the practical layer for the defenders. What can we learn from those lessons? What we can take back to our companies and our enterprises,

and how we can shore up our defenses. So, in this scenario, um Ukraine is not sort of the only case, but I think it's the first case. Uh it's sort of the first case where we've seen Ukraine being uh used as a ground zero for testing zero-day malware. And then afterwards, once it gets tested, it also um goes past geographical boundaries, and that can come to other

enterprises in the Western Europe, our allies, and elsewhere. So, if we don't learn these lessons, we don't take them back to our enterprises, it's at our own peril not to learn from the lessons of the others. So, as this is not about sort of the reverse engineering and not the here geopolitics, it's that middle ground, it's all about how What are the assumptions we make at peacetime

that fail at at at at at extreme stress. We often focus on sort of the audit side of things, how we could put good controls in place to pass the audit, but real controls survive the incident, and that's sort of one of the focus areas today. Very briefly about me. So, I'm Gediminas. I spent last 15 years in UK. I just came back to Lithuania last year

to join PwC. Um and I want to say a special thanks to our team in Ukraine. So, I'm clearly not Ukrainian myself. The last time I was in Ukraine was in 2017. Um so, Ukraine team did a lot of work pulling together some of the insights and the research. So, a big thanks go to them. They were not I wanted them to come as well, participate in

person, but it's a bit difficult logistically to travel at this time uh with trains rather than planes. the key question is in their scenario is when things like power, connectivity, networking are down, what controls still operate in our environment? What can we rely on and trust on to keep our enterprise up? Um at points of peace, we have these reassuring controls in place. We say about Well,

we have policies in place. We have dashboards. We have monitoring. We have backups. Our incident response plan is documented and sitting somewhere. But at a points of destruction and and stress, those become a bit less reassuring. They become questions. What will really keep up and what will fall over um in a in a destructive attack? Um because uh attackers don't go after our policies. They go after

our dependencies, our entire dependency stack, and look for points that cause a maximum impact, the maximum destruction. So, the test here isn't do we have controls, but it's more about what still works when nothing does. Um I just before I go into the actual use cases, I just want to very briefly sort of help put up this framework to keep in mind that we'll see a repetitive

pattern of these uh these sort of steps. And it's it's similar to attack kill chain, my trade, to all those good frameworks. It's a little bit simplified, a little bit tailored to what we've seen um in Ukraine. And I think what we often see in enterprises is we are often focusing some of our effort and controls on step one, preventing the initial compromise, sort of detective controls

around the perimeter and identity. And then we also monitor around step four, sort of the point of impact. Do we have the alerts in place to trigger in our seam and our sock, and then we trigger incident response. Those points around two and three in the is that we often do not put quite as much focus on, and we will see that those are the key areas

where some of the case studies in Ukraine, where that's where the most of the action happened and most of the decisions were made that led to those catastrophic consequences. And then five is on the recovery as well. We've seen that most attacks are sort of dual dual purpose. One is to wipe and destroy, the other one is also to target recovery so that services cannot be brought

back up online very effectively and to disrupt that as much as possible. So the key question here to keep in mind as we go forward is um whether our controls are up optimized uh for the blast. We only see when something is happens on number four, and we respond when we are already bleeding and our um operations are degraded, or do we have the preparation in place

to to notice these things in up front and minimize the blaze blast radius as much So with that with that in mind, we have four cases uh for you today that I will go through. Um these are not all the interesting cases from Ukraine. These are just the four picked and every case has just one purpose in this talk to test one assumption that we often make

at peace time that will not necessarily hold up at a point of uh, destruction and stress. So, we have Hermetic Wiper that uh, targeted Ukraine's uh, government sector primarily and that test our assumption about the central admin tools. What what are controls we put there and how much we can trust our admin planes and what can be um, pushed to the environment from them. Then the Viasat

satellite attack and the AcidRain Wiper tested the connectivity to assumption. What how much trust do we put in the connectivity in our incident response plans and recovery plans and what do we do when connectivity is not there? Industroyer 2 a follow-up from the Industroyer, the first edition back in 2017 or so, targeted the energy sector and that's where it's more about the OT segmentation and recovery. This

is the one that targeted both the OT environment and recovery in parallel to not only bring the substations down, but also slow down the recovery as much as And finally, Killnet star, the most recent out of these and maybe the most uh, talked about in the media and most widely publicized uh, is about noticing the attack in time when there's a very long dwell time and what

can we do? What are the decisions we make under pressure when 24 million subscribers are impacted? So, all these attacks have uh, common common attacker behind them. They're at different time, they attack a different sector, but all of them convert cyber breaches, cyber access into real destructive incidents and that's what they have in common. So, let's dive in. So, case one uh, Hermetic Wiper. These are days

and months coming up to the full-scale invasion. Uh, the wipers were actually pre-positioned a long time Um, and multiple organizations were com- And this is where it was a very planned attack co-timed with the kinetic attack. So, everything was pre-planned in advance. It was not like a smash and grab kind of attack. It was pre-planned well before. And the key detail here that matters is not the

wiper itself, not the malware itself. It's more the deployment path. And that's the key lesson that we will be able to take away from this. So, in this case, again, the domain was compromised um, well before. The attacker has privileged access inside the organizations. They were able to map out the the infrastructure, get the system context for where where and how the wiper can be deployed. Where

can it cause maximal destruction? And effectively, the key thing here is how it was pushed out via your usual IT The attackers did not need to compromise the endpoints. They did not need to fish the users. They did not need to have any user interactions whatsoever. They just pushed out via active directory group policy updates. So, from IT perspective, it looked normal. It was normal. It's normal

IT process, it's normal change management process, and that just distributed the malware across the enterprise. So, it allowed that execution to happen at scale. It seemed normal to IT, delivered like IT, wasn't noticed. So, in peacetime, we fall back to again, where was those where are those assumptions we make? Well, we do have EDR, we have backups, we have a good well-documented change control process. And we

only have a few domain admins. We know who they are. We sort of monitor the privileges. All of that was true. Didn't stop the wiper in this case. So, in this case, the reality check is if we have if our domain admin is compromised how much they can damage can be done? What can be pushed in the environment and how quickly? Because in this case, the controls

were not taken out, they were not degraded, uh your tooling effectively becomes the attacker's tooling to cause the maximum damage. So how how what do we do about these kind of attacks? What should we take into account? And the controls here are not very exciting. In fact, so in most cases they're pretty boring. But that's the same sort of, you know, rigid discipline and structure we should

apply to our um tier zero control planes that enables us to spot these such attacks earlier and prevent mass destruction via using those admin planes. So tier zero separation, you know, let's put all those good controls in place around our privileged accounts, active directory, our hypervisors. Um what we often see in enterprises, especially these days with a lot of sort of data and app-focused, is that we

put a lot of attention and time and controls to protect our applications, our endpoints, our sensitive data. I think the key lesson here is to make sure we do not forget about that tier zero control plane and we apply the same rigor of monitoring and access management to the crown jewels. Because if attackers can breach those management planes, they don't need to also attack your endpoints. They

can effectively instruct the the edge to self-destruct. Privileged identity hardening, again, the good best practice is about fishing resistant MFAs. Ukraine learned to use the FIDO keys uh to have just-in-time access, have ephemeral privileged access accounts that do not have any sitting privileges. Deployment path monitoring, again, you don't necessarily need to detect the wiper itself, but you need to detect what a mass uh distribution looks like.

So have alerts on mass global policy updates um and and and schedule tasks around that. You can set up in uh those in your seam and sock and put those alerts in in place. And pre-detonation hunting, I mentioned that, but I will not talk about it a little bit more now because we will have a a different case that double clicks on that even in a more

relevant way. So, this case showed more about how the attackers in Ukraine used your own IT tools against you. The second case on Viasat is more about the connectivity. What are the assumptions we make about connectivity in this crisis situations and how do we work around that? So, before I sort of go into the details, still to this day we see every so often these sort of

incident response plans. Just to walk through an example. So, we have an incident team who can who are able to coordinate and need to respond to the incident and they work through these assumptions in this sort of linear logic that okay, so we're going to if an incident happens, we're going to connect via our connectivity layer, we will identify to our our accounts via the VPN into

corporate network. And what we're going to do then is we will set up this crisis bridge, the war room on Teams, where we're going to sit there and we sort of going to coordinate our response to how we're going to bring back up our critical operations. And then what happens then? The whole house of cards collapses at the very initial stage. You don't have connectivity, nothing else

in your incident response plans matters if you do not have an out-of-band path. And this was the case in the in the Viasat attack. In peacetime, we again, we make these assumptions. Well, we have a document uh we for our incident response plan. We just updated last week. It sits on that SharePoint site in our corporate network, right? How do How good is that if the VPN

is down and you can't even connect to your network? We have crisis bridge on Teams. We're going to set that up. Again, it falls down like a house of cards. We have a coms tree and we have no offline path. So, again, if your response is cannot have any of those tools in the stack, how do they coordinate? Um in this case, just to very briefly run

through, the attack itself it was pretty simple and boring. It was just a vulnerability in the Fortinet VPN. And Fortinet have not had a great run lately, have they? There's been a lot of them there vulnerabilities in the in the out there right now. Once they exploited the uh VPN, again, they managed the reach the management segment that con- trolled all the residential modems, and they were

able to push out um uh flash memory override to all of those modems, which effectively brought down over uh not only the modems themselves, but impacted the connectivity not just in Ukraine, but it was also experienced in the Western Europe, um where over 5,000 wind turbines in Central Europe lost their remote monitoring. So, the impact was quite wide. But, in this case, it's not just about losing

the connectivity or to the monitoring, but also how it impacted the responders. That was the key thing here on how they were not able to really do anything with that uh assumption stack collapsing. So, again, if your incident response plan requires that the systems that are under attack work, you don't have an incident response plan. You have a sta- a set of assumptions that will fail if

such destructive attacks happen. It might be good enough in peacetime when we worry more about the ransomwares and and more sort of peacetime kind of breaches that are incentivized with financial gain, but we talk about destructive scenarios that don't care about your data, don't care about the money, but want to bring your network down, your incident response plan will not be good if it relies on such

assumptions. And the malware itself was simple. It was more about the attack path what was powerful here. So, what's the takeaway here? Harden the dependency chain. Again, nothing very exciting, simple, good controls that we often forget about at peacetime. Survive here by planning for connectivity loss, not assuming around that. So, how Ukraine was able to recover and survive this incident is some of these things that I

really list on the slide here. So, in terms of mapping the comms dependency chain, have you cannot protect a dependency that you have not mapped that you're not aware of. So, if you make these assumptions about email bridge, VPN, map them out, what depends on what, and what's the out-of-band path. Have at least one, you don't need five, but have at least one out-of-band path. What will

happen if the connectivity is down? Obviously, have those incident response plans printed and not just sitting somewhere in SharePoint on your corporate network. Pre-staging the crisis comms, have a phone tree that you have tried and it's working, you know that people will pick up the phone. If that if the phone is down, have a plan B. It could be just really really a physical location. Agree on

a cafe shop around the corner that if everything is on fire, everything is down, meet up in a cafe around the corner, and then you can perhaps as a group try start to coordinate and figure out what you do next assuming all connectivity is down. And then rehearse with the network down. Often, we see these war gaming and table top exercises that start with an alert. There's

an alert in our seam, in our sock, something is happening. What do we do now? You're starting at the point of impact. You're starting at that step four that I showed in the earlier on. Start with number one. Your table top starts, nothing works. What's your step one after that? So, these are the kind of more resilient scenarios for you to try out to really test that

uh muscle of your organization to be able to respond when nothing functions. So, the takeaway here is plan for the day that your whole stack is the incident and not just some individual pieces are gone. The controls you trust the ones the most are we're going to be the ones that attacker will go after first in these kind of scenarios. So, we've seen your case one was

about your own tools being used against you. Number two, you have no tools, the Um if we go to three, um it's a more OT related and recovery related case where the uh energy sector was attacked uh with Industroyer 2 um in April 2022. So, in this case, uh the malware was again pre-positioned on on IT side. It was staged in IT and the crux here is

that there it was effectively a logic bomb. It was a logic bomb scheduled to execute at a specific time, 16:10 UTC, April 8th, um to go over to deploy the the malware uh payload to the ICS uh side of the network to bring down the substations, but more importantly, it has a twofold. It would also have a pre-staged wipers on the recovery side. So, the engineering workstation

meant to be used for the recovery side and the backups, they had the wiper scheduled there on the both Windows, Linux, and Solaris systems as well to not only bring down the substations, but also, as much as possible, disrupt the recovery so that they cannot be brought back up online quickly. So, how do What does it What does it look like in peacetime? Again, we say, "Well,

our OT segmented, we have a clear boundary, and we are monitoring it. We have backups. We have the SOC that watches the those bo- borderlines." And sometimes even these more obscure explanations that well, our OT protocols are so old and obscure, we barely know them themsel- ourselves, so nobody can really exploit them because they're so weird and obscure. But, the defender win condition here is that um

how quickly can you detect, how can you minimize the dwell window, and that you can respond not after the impact, but catch it up front. So, in this particular scenario, the fight wasn't at the impact, it was in the dwell time before the impact happened. Because it did not execute. This is one example we have picked where Ukraine CERT uh team has actually caught it before the

logic bomb has executed. So, there was no actual impact, caught in the dwell time, which is your window to respond and react before the attacker executes. Uh across all those three or four stages, the pre-positioning, the dwell window, the execution, and the impact, if you only detect it at impact, you're watching fireworks. So, in this case, they were hunting for something that that has not executed yet,

and that's what helped catch it before the logic bomb executed. So, in terms of those minimal viable controls, um the key here is to hunt for those pre-positioned payloads. When it comes to threat hunting, often times our threat hunting is based on known IOCs and active threats. If you're doing that, you're going to miss these sort of attacks. You have to more make more assumption-based threat hunting.

For example, you know, what are It's not about have I seen this hash X in our system, it's more about what are the payloads sitting on our critical systems that have not executed for a long time and have a some sort of scheduled execution time. So, you need to make these more assumption-based threat hunting rather than to know to hunt for something you already know is known

to the industry or they have uh mapped out hashes. What's the IT/OT boundary? Again, in this scenario, the malware was staged in IT side and was uh coded to deploy the payload in ICS, so we need to watch that boundary carefully. And uh and monitor not only what happens in OT, but also in IT side. And the recovery paths here, uh why it's important is that in

this case if your recovery and backup sits on the same management plane, shares the same credentials, sometimes shares the same network path, your recovery is just part of the blast radius. It's going to be no good in the case of a of a wiper. So, you need to make sure that's segregated properly, and assume that your wipers are already staging there. How do you detect them? How

do you make sure that your backups are not impacted um by that? And again, monitoring the scheduled tasks and dormant binaries, those are the quiet things that sit there in your network for a while. If you don't hunt them from them proactively, they have the dwell time to map out your network, map out your dependencies, find where it hurts the most, and then trigger the execution. So,

in this case, um the the defenders won, not because uh they were able to do something after the impact and minimize the breach. They were hunting for that was there already, and they were able to find it in in uh in time before And then case four, uh again, probably the the best-known case study is uh a bit later, December 2023, Kyivstar, the largest telecoms operator in

Ukraine. Um this is more about again a little bit about the dwell time, but also about the sort of a race to make critical decisions at a time when all the services are collapsing. So, in this case, uh it's all about the telecom core. The attack paths were again twofold. Uh there was uh two payloads. One was to target the telecom core infrastructure itself, but also to

uh attack the base stations to break the firmware on the base station. Uh in this case, the base station attack actually failed. It was only a few base stations were impacted, but it failed to propagate more broadly. But in terms of the telecom core, about 40% of the core was wiped. And as I mentioned, about 24 million subscribers were out of service, and it took weeks to

gradually and slowly recover. But the attack path again in this case is pretty boring. It was a compromised partner account. So, it's a supply chain attack effectively. Initial access was through a third-party partner. In this case, it almost doesn't matter how it was gained, whether it was a phishing attack on the partner or stolen credential. In this case, the impact is that there was a trust on

the on the on the defender side on the Kyivstar side. There was a trust of that provider that was not tested sufficiently, was not segmented sufficiently, that allowed a breached partner account to gain access to the management plane of the core network. And a key here is the the length of dwell time. So, the researchers say that they were in there at least since May 2023. An

attack executed on 12th of December. So, they were in the network for over 7 months, allowing them to quietly and slowly enumerate the network, identify the privileges, use tools like Mimikatz to to gain credential dumps. And effectively by that time, after 7 months of dwell time, the attackers knew the network probably better than most of Kyivstar own And then they triggered the attack, as I mentioned, destroying

the infrastructure. About 40% went down. And the key here is also on the response At that point, they made a difficult and difficult decision to pull the plug. They effectively brought the service down to contain further spread and allow them to recover. And as a result, 24 million subscribers did not have the service. So, in peacetime, we'd we'd say, "Well, we'd notice in 7 months, surely there

would be some kind of signals. We would notice the attackers and do something about it." We do have MFA across all our admin accounts. We have supplier risk scores for our suppliers. We do third-party risk management, right? So, we have good controls in there. And we have backups, so in case something happens, we're able to recover. But the question is, how long would it take for you

know, how long would it would attacker be able to be in your network before you notice them? And if supplier account is compromised, how much damage can they do? So, that's something worth testing on the supplier account side. In this case, these assumptions failed, and that led to this brutal decision to uh pull the plug and shut down the entire service. So, in this case, when the

core itself is a blast radius in the telecom uh environment, resilience became a decision speed problem. The sooner they decided to pull the plug, the more they were able to limit the damage and start recovery. And that was a difficult decision made by uh the telecom uh leadership as well as the SBU on the Ukrainian side. So, the takeaway here is a few things. It's how you

do you shrink the dwell window and how do you minimize what the attackers can do in the time that they are in your network. So, obviously, treat the partner access as untrusted. We talked about privileged access hardening on your own admin planes at admin sites. Apply the same principles to your to your suppliers in terms of FIDO keys and malware um fishing-resistant MFA. Just-in-time access, segmentation in

what the suppliers can or cannot reach. Hunt for long-term presence. So, again, this is about those accounts that are dormant for a long time, for example, and suddenly activate. Log in from uh unusual locations geographically geographically and at unusual times. Monitor for internal reconnaissance. So when the attacker sit there in your network doing all those reconnaissance activities, credential harvesting, design uh network paths, they do leave traces.

They do leave activities that can be monitored, can be noticed, but that requires discipline and internal processes to do that careful methodical internal scanning to look for these signals, look for these breadcrumbs, and have alerts configured that they're able to respond in time. And then finally, have that pre-decide pre-decision for containment authority. If something goes down and everything's if you need to make those difficult decisions about

bringing your network down, pulling the services, if you need the approval from your CEO, the board, CISO, three more people, you'll be losing valuable time. So you need to have some kind of pre-written authority. Who's able to pull the plug on 24 million subscribers at 6:30 a.m. on Monday? That will save precious minutes that will be able to contain the impact and allow you to begin discovery

and So summarizing in terms of what controls held up. So you've seen sort of common themes around those all those use cases around connectivity, identity, um admin trust, recovery, uh third-party suppliers, and human decisions um uh at the points of stress. So in a nutshell, protect the control plane. We talked a little bit about that. Putting in place the controls and controlling your crown jewels, not only

protecting your endpoints, your data, and your applications, but putting the same rigor, same discipline to controlling your admin uh planes uh at tier zero. Segment to limit blast radius. I mean, zero trust has been around for what, 15, 16 years? We've talked about it for a long time. It's network segmentation still works. It's not going to prevent and stop a persistent, well-funded APT attacker. It will buy

you time. It will limit what they can do with the one set of credentials, with one attack path, and will buy you time to recover and identify the attack faster. So, network segmentation still works. Hunt in the dwell window. I think that's the one of the key lessons that we've seen in multiple cases where being able to do hunt in the dwell window, and again, not just

looking for active threats, but making that um assumption-based threat hunting to look for dormant binaries that uh sitting on your critical systems that have some kind of logic to execute that have never run before, look for those, not just for known hashes that uh that will not be you know, those those hashes that these APTs use, they will not be known yet, so you will not able

to find them. Plan for degraded operations. You know, don't start those table top and war gaming exercises with a SOC or similar. Start from assumption that nothing What would be your first step? How do you plan for out-of-band communication? How do you pre-decide that authority is able to pull the plug at critical times? And finally, make recovery survivable. So, that's about the backup segmentation and how usable

they are at the time of crisis. Make sure they're offline, they're immutable, they're not connected to your environment in a way that your backup becomes part of the blast radius and is unusable unusable in a destructive attack. There's no shiny tools here. There's no AI. There's no three, four letter acronyms that all the vendors trying to throw around us. Again, these are basic controls in most cases,

but they're applied with the discipline and rigor that matters in a point of crisis, and that's what we've seen in Ukraine. And I'm not saying all these tools, AI, etc., are not useful. They are, and we're we're probably going to see more of them. But that's you know, in the last three or four years, we have not seen that yet playing a critical role, but it will

become more and more important in the future. In the meantime, if we get these basics right, that will strengthen our defenses and make us more resilient in the times of to take away from this, I sort of drafted this like five questions to ask yourself and ask your teams when you go back to work on Monday. If you're able to get confident, clear answers, that probably will

give you a bit of confidence that maybe you have certain things right. But if you hear something like, "Well, yeah, probably we have something documented. Well, yeah, the vendor is going to do that bit." Then you probably there's a bit more homework to be done. So, ask the these questions yourself if you are in a security role. If you're not, go and ask some of your CSOs

just to test what are the assumptions that we're making in a peacetime that will potentially fall over at the day of So, I'll leave you with this. It's a a quote about, you know, there's two kinds of organizations. Those whose controls have been tested by reality, and those who still think they don't need to be. And one thing for me to sort of take away from the

Ukraine experience is is Ukraine does not teach us that everyone must have a wartime cybersecurity architecture in their enterprise. It doesn't, and it would be disproportionate. We have to make sure we use proportionate measures based on our risk appetite and where we are. Same with like defense budgets. We're trying to, you know, get to 5% across NATO. Some do do a bit more, some do a bit

less. We're not necessarily going to go to 30 to 30 or 40% the way Ukraine is doing now, but it's all about having that thought process and making those conscious decisions about what are the assumptions we make at peacetime and how valid they would be at a time of crisis. So, I was going to finish here, but because I have a few more minutes of time, I

have like a a bonus slide, an appendix. Some of the bits that again our Ukrainian colleagues pulled together that didn't fit into sort of the main presentation, but what they are seeing in Ukraine is some of these things about how privacy is dead in Ukraine on both sides. All the identities pretty much at this point have been leaked. So, right now privacy is not a privilege that

anyone has. Civilians and military alike on both sides, it's more of an exception. Detailed PII has leaked multiple times including addresses, passport details. So, you pretty much can assume your identity is out there. Anonymity is eroding on the breach side as well. We're seeing doxing a lot more. Even hacker and and APT identities are known. So, you no no longer able to these activities in anonymity as

much as perhaps you have been able a little while ago. So, that's out there in the public as well. I think battlefield shadow IT is interesting as well. That has become a prominent problem and topic in the in the recent months as the drones and sort of these domestic drones started playing a more and more prominent part in in the war is the problems that creates also

with those drones effectively being part of shadow IT with no central coordination and monitoring. And the Telegram paradox is interesting for me because although it's a sort of Russia originated application with a bit of opaque governance, to this day Ukraine is uses that very extensively including official government channels and military channels. So there's a a bit of a paradox there how they continue to rely on the

application that is not perhaps the the best to be trusted in this kind of environment. if you haven't read the book this one yet, I recommend to do so if you're interested in the topic by Andy Greenberg. Um it's a more about the earlier attacks leading up to the last few years, NotPetya 2017 and earlier. It just gives a good context about the the threat groups in

Russia, Sandworm, etc. And the context in the last decade or so how they have been able to penetrate critical infrastructure in Ukraine and how that has spread to the Western Europe. So I'll leave you with that. Thank you. >> [applause] >> Test test. Okay, we have a microphone. thank you for your talk. First of all, this was amazing. I can I think everyone here agrees, right? Awesome.

So we have a ton of questions here, so let's start from the top. And we should be seeing it here so it makes it easier for you. >> Ah, okay. >> Uh so what what lessons from defending under fire do you wish peacetime engineering teams understood? What are we wasting effort on that you weren't to skip? >> Well, I I think some of that I've covered in

the last bit of the presentation. Perhaps the question was I a little bit earlier in the presentation in terms of what we should take away from this. In terms of the skipping I wouldn't say it's about skipping, but maybe what to to stress again is about the balance in terms of the control effort, the balance we put right now on the sensitive data, the applications, and the

endpoints. I I think we've seen lately a bit of a shift there of our attention. More and more controls are organized on that layer, and perhaps we sometimes a little bit forget about the tier zero, those admin planes. So, I'm not saying that we should skip monitoring the endpoints, but I'm saying let's not make an assumption that having the EDR in place, having a DLP is all

you need. In this case, in a destructive scenario, the attackers go after your management planes. They go after your crown jewels. They will not necessarily go after endpoints. So, just make sure you have the balance right, and make sure you give equal rigor, equal attention to your crown jewels as well. >> All right. Thanks for that. Let's go for the next question. So, what's the highest leverage

thing a Western engineering team could delete today to prepare for the kind of pressure your teams have lived under? >> Delete any any standing privileged accounts. Go to ephemeral privileged accounts that only get created at the point of need, get approved, get used, and then the moment the engineer is finished doing what they have done, the account itself disappears. It does not exist. You cannot fish that

account. You cannot gain access to it. It does not exist. So, I think ephemeral privileged access would be one thing I would recommend to take away and do as soon as possible that will, in this case, mitigate three out of the four case studies that we have seen. >> All right. Let's go for the next one. I love that you keep the questions coming. This is amazing.

So, what's the you wish a Western audience understood about cyber defense that they only see when it stops being abstract? >> I'm trying to pick one, you know, I think I I I think again all all five uh examples kind of added some color to I think when it comes to, you know, one thing about abstract perhaps is uh let's use again the cafe analogy. Like, you

know, in in Ukraine in the some of these case studies when nothing works, you sometimes have to fall back to simple physical meetups. Like, I I as I mentioned, having a room or a cafe or an office where your core team can actually meet up when there's drones flying over your head and there's no connectivity whatsoever, not just your corporate network VPN, I'm talking cell uh network

being down as well. How do you find the people you need to find in that case? Do you know their addresses? Do you know your where your CISO lives? Maybe you should. Maybe you shouldn't. But, have a have a conscious thought process about where would you go, whose door you would knock on in a crisis situation like that. And obviously look after yourself. At the end of

the day, if there's drones flying over your head, your company is probably the last thing you should worry about. >> Yeah, that's that's a great tip. So, 24/7 incident response over years is unsustainable for individuals. How did you keep defenders functioning? What did uh someone has told you? Had told you. >> I'm trying to understand the question what the asking means by it's unsustainable for individuals, whether

they mean an individual company or the people working in incident response in shifts 24/7 because we definitely see a churn of responders, especially you know, where you have to work shift patterns overnights and weekends. The churn is huge. So, that may be is unsustainable on the individual level. But as an organization, it's all scale-dependent. Like you if you're not an enterprise with, you know, thousands of employees

and billions of revenue, you might not necessarily be able to sustain a 24/7 incident response capability in a sock. But you should also take them proportionate measures. Maybe invest more in the preventative controls first so that there is less risk coming through to your incident response capability. You are a bit better around the edges and around the tier zero controls that maybe do not need a 24/7

incident response. But they have more automated 24/7 monitoring with having more of an on-call functionality. So, you don't need to be up 24/7 look at the screen. You maybe will just get a phone call if a critical alert's fired. So, have a proportionate measure depending on your risk appetite and the scale of the assets that you are securing. >> All right, let's see. In your experience, have

you seen any really well-planned successful social engineering attack by an insider, a spy that caused a lot of damage? >> Social engineering has I'm just trying to link that back to the Ukraine examples. Um it hasn't been the primary attack vector. I think we've maybe even in reality we've seen more social engineering insider threats in the Western world where the motivation is individual gain and financially motivated.

So, that's when these kind of insider attacks are a bit more prevalent if they want money. They want to steal your data. They want to sell it. They want to deploy ransomware. Or they are, you know begrudged employee that uh has feels that they were not treated fair. I think we've seen more of that in those environments. In Ukraine, they don't care they the attackers do not

care about the money and the data. They want to wipe and destroy destroy the infrastructure destroy the data. So that has not been um the primary attack vector. It was more APT um deployed malware. Um and in some cases we've seen that there is a smoke screen of ransomware. Like they they they still encrypt the data and they they present the mouse ransomware screen uh and demand

for ransom. But then the researchers understood later that there was no decryption key. So it was just a smoke screen to to delay the responders, have them think that they can negotiate potential and recover the data. In reality it was not recoverable. So then again that was a smoke screen because the intention of the attacker is just pure destruction. It's not financially >> All right. I think

we have 2 minutes, right? Okay, 2 minutes. So let's see what we have here. So when you had to make rapid resilience decisions under fire, what got deleted from your stack? What turned out to be ballast ballast? Sorry, my translation service is terrible right now. That you didn't need. >> I'm trying to link that to the scenarios. Um it wasn't it wasn't more about the the the

ballast that they didn't need, but I'm trying to link to the recovery scenarios where in all cases all three out of the four cases um one of the primary attack vectors was towards the backup. So that ability to sort of fully segregated having mutable offline backups became became key. So, in this case, you can maybe argue that some of the ballast would be potentially some of the

controls in your uh production area. Like if I go back to those you know, five five takeaways, five questions, if you're not able to respond to those questions confidently and have a clear answer that you can stand behind, don't add more controls. Adding just more controls, more acronyms to your security stack will just increase your blast radius. So, I think the ballot that the necessary ballast sometimes

is what every time we see some kind of gap, we just throw another control at it, we throw another tool at it. Sometimes it's not that, especially in these kind of crisis situations, it's having that good methodical baseline of these basics will take you further than throwing more and more tools that will start conflicting with each other and start creating new exposure paths and even bigger blast

radius. So, maybe in these crisis situations the ballast is sometimes over tooling and not looking at the basics in the right way.