In this episode of Security Matters, host David Puner, dives into the world of evolving cyberthreats with Bryan Murphy, Senior Director of CyberArk’s Incident Response Team. Imagine a scenario where an attacker uses AI-generated deepfakes to impersonate your company’s VP of finance, gaining unauthorized access to your environment. Bryan Murphy shares insights on how these sophisticated attacks are turning identity into the attack surface and why your first line of defense might be as simple as a video call. Learn about the latest trends in social engineering, credential tiering and the importance of visual verification in incident response. Don’t miss this eye-opening discussion on how to protect your organization from the ever-evolving threat landscape.<\/p>\n
Imagine this scenario, someone calls your help desk in a panic. She sounds exactly like your company’s VP of finance. Same voice, same urgency, same backstory. I’m traveling and I lost my phone, she says. I’m calling from my son’s phone. I’m really late for my meeting with the CEO and need my credentials reset.<\/p>\n
Quickly, the IT support specialist on duty is there to help. So he does, but the caller isn’t your VP. It’s an attacker. With a single act of social engineering powered by AI-generated deepfakes, they now have access to your environment \u2014 not just as a user, but with the means to escalate, override, and erase. From resetting credentials, replacing MFA devices, and compromising your infrastructure, attackers are not knocking at your door. They’re already inside.<\/p>\n
So \u2014 how can you distinguish what’s what and who’s who when they sound just like you and your colleagues? Today I talk with Bryan Murphy, Senior Director of CyberArk’s Incident Response Team, about how evolving threats are further turning identity into an attack surface \u2014 the attack surface, really \u2014 and why your first line of defense might be as simple as a video call.<\/p>\n
Okay? Let’s get into it with Bryan Murphy.<\/p>\n
David Puner: Bryan Murphy, Senior Director of the CyberArk Incident Response Team \u2014 welcome to Security Matters.<\/p>\n
Bryan Murphy: Hey, thanks David. Appreciate you having me.<\/p>\n
David Puner: Absolutely. Great to have you back on the podcast. The last time you appeared on an iteration of this podcast was October 2022. Glad we could finally have you back on. Bryan, I know you’re a busy guy. Where have you been and what have you been up to?<\/p>\n
Bryan Murphy: We’ve been busy over here at CyberArk. We’ve started to form a new incident response team, which is going to help our customers recover from cybersecurity incidents. Previously I was working on our remediation team where we would just help recover CyberArk assets when incidents happened. But now, because our customers are asking for it, we’re actually building a full IR team to assist in those threat attacks.<\/p>\n
David Puner: So you’re saying you’ve been busy?<\/p>\n
Bryan Murphy: Just a little bit, sir.<\/p>\n
David Puner: Alright. Well, thank you for taking the time to talk with us today. Looking forward to diving right in. Today we’re going to talk about the evolution of cyber threats \u2014 which, you know intimately, I think it’s probably safe to say. And seeing that you’re on the incident response team, you obviously know firsthand what’s going on out there in the threat landscape. So you’re very much on the front lines.<\/p>\n
Let’s start things off with: in your role with the CyberArk Incident Response Team, what’s your purview and how do you enter the fray?<\/p>\n
Bryan Murphy: The way we work now is instead of coming in from an incident perspective and saying we want to be your second call after you call your incident response firm \u2014 debatable if you call the lawyers first \u2014 but after the incident response call, you would call CyberArk to help you figure out what happened with your identity platform that you have.<\/p>\n
And now we’re saying we should be your first call. Now instead of having to call an IR firm \u2014 or if you do call an IR firm, you can have us there alongside them \u2014 to help you work through these incidents that are going on. And what we found is a lot of these attacks happen through the identity platforms, as well as through your privileged access management solutions. Meaning the attackers are using these to gain deeper access to your environment. And this is why it’s crucial for CyberArk to launch and have this team to work alongside the other responders within the industry.<\/p>\n
David Puner: So are you on the hook? Are you on the other end of a burner 24\/7? How does that work?<\/p>\n
Bryan Murphy: No, I\u2019m not. I don\u2019t know that my family would love that. We do have a call tree process where they will get in contact with us as needed. And what I mean by that is you can contact CyberArk Support \u2014 the numbers we all know and love \u2014 and they have a process to do the initial triage to handle what\u2019s coming in first, to allow us the flexibility to not be on 24\/7, but still provide you that 24×7 service that you need when incidents arise.<\/p>\n
David Puner: Now that we’ve established that you’ve got a very close view into emerging threats \u2014 at CyberArk Impact this month, you hosted a session on evolving cyber threats and attack patterns to be on the lookout for. Let’s start generally and then dive into those big, notable emerging threats. What are some of the most significant changes in the evolution of cyber threats in the last few months?<\/p>\n
Bryan Murphy: I would say it starts with AI.<\/p>\n
David Puner: Okay.<\/p>\n
Bryan Murphy: And yes, I know it’s a buzzword and we’re talking about AI everywhere, and we’re gonna AI everything in our lives going forward \u2014 for good reason.<\/p>\n
David Puner: Yep.<\/p>\n
Bryan Murphy: But what we’ve seen in the emerging threat space with this: attackers are using AI to better craft, say at the simplest form, a phishing email \u2014 a way to get you to click what they’re looking for in the drive-by. But in addition to that, we’ve seen them be more sophisticated with deepfakes, where they’ll contact your help desk and say, \u201cHey, I’m Bryan from CyberArk. I’m on the phone, I need you to reset my password.\u201d But they’re doing it with AI, so it sounds like me. The person on the other end \u2014 if they know me \u2014 it\u2019ll sound like me, and they’ll trust.<\/p>\n
And what makes this really challenging is all of the controls we had before to prove someone is who they say they are aren’t really as good as they used to be. So with that, it\u2019s not good enough to say someone sent me a text message, someone sent me an email and said reset my credential, or they called in and I talked to Bryan \u2014 he was the person. You’ve really got to go through the steps of: did you check with their manager? Is this a legit request? Did you check them visually on a call?<\/p>\n
Doesn\u2019t have to be the whole time like we are here today. It could just be for five seconds to make sure they are who they say they are. But you need to do these things in addition to what we did before, because the attackers are getting better and better at faking and impersonating who they are.<\/p>\n
David Puner: With the help of AI, are attackers now attacking or attempting to attack help desks more than they were pre-AI? Or are they just doing it more effectively now?<\/p>\n
Bryan Murphy: I would say it\u2019s more effective, and it might also be that they\u2019re more successful.<\/p>\n
David Puner: Mm-hmm.<\/p>\n
Bryan Murphy: So we\u2019re seeing more of it in the industry, but I can\u2019t say that we\u2019re seeing more of it because they\u2019re upping the attacks they\u2019re doing. I think this is a way they\u2019ve found to be more successful.<\/p>\n
If you look back and you think about when we said, \u201cDo MFA,\u201d we said, \u201cUse an SMS push. That\u2019s the great way to do it.\u201d And you know, we said, \u201cWell, no, you don\u2019t want to do that because there\u2019s SIM swapping and cloning of phones and ways to take over the MFA device that you have.\u201d We shifted and we said, \u201cNo, put it on the device. Have an OTP pin \u2014 you know, an app that you\u2019re using \u2014 to get that information back to approve the request.\u201d<\/p>\n
This is just the next evolution where instead of them having to compromise your device, they\u2019re saying, \u201cI\u2019ll go directly to the help desk and set up a new device.\u201d And so how do they do that? Well, they call in and say, \u201cHey, I lost my phone.\u201d They play on the factors of \u2014 it\u2019s very urgent, people like to help.<\/p>\n
And if I called you and I said, \u201cDavid, I have this big issue. I need you to help me get my device reset. It\u2019s a really important call. I\u2019ve got to meet with the CEO of this company, and if I\u2019m not there, it\u2019s really bad.\u201d They play on that urgency. They play on getting you to do it quickly. And this is where people will succumb to wanting to help \u2014 and maybe they\u2019re helping the wrong people.<\/p>\n
David Puner: So is this an example then of an attacker having a brand-new phone or a phone that has nothing to do with the person they\u2019re claiming to be, and calling a help desk and saying, basically, \u201cActivate this phone because I lost my phone\u201d?<\/p>\n
Bryan Murphy: Yes, that\u2019s exactly what they\u2019re doing.<\/p>\n
David Puner: Is this now something that is becoming more well known \u2014 that folks are looking out for? Or how does it then evolve from that call to an actual successful attack?<\/p>\n
Bryan Murphy: It\u2019s definitely something we have to be more on the lookout for. Because in the past, if you think about it, we would just grab a credential. Maybe they would have you on your machine, click on a link, do something to grab your credentials for the system. And because we didn\u2019t have MFA as prevalent as it is today, they would be able to use those credentials and fly right by.<\/p>\n
Now we have to worry about them just taking over the MFA device and approving everything that they want to do. So obviously, they need the credential still, and that might be help desk reset my credential \u2014 it could be these different things that they\u2019re doing \u2014 but they\u2019re getting away.<\/p>\n
Now, the takeaway from this for the audience is: they\u2019re able to grab the credential and the MFA device. Meaning, they can reset the device to a new device. So now they\u2019re not waiting for the user to click \u201capprove\u201d \u2014 they\u2019re approving it themselves.<\/p>\n
David Puner: I want to get back to what organizations and help desks should be on the lookout for later on, but in keeping with the thread that we’re talking about here \u2014 in the actual attacks \u2014 so an attacker successfully gets in, the new device is either added or reset. So then what happens? Because obviously the end goal isn\u2019t just to get into the system.<\/p>\n
Bryan Murphy: Correct. So now they have access to your systems. And this is where they\u2019re in the environment \u2014 and they may not be a privileged user, they may just be a standard user, which we hope everyone is using least privilege and that that’s all the access the attacker has.<\/p>\n
David Puner: Right?<\/p>\n
Bryan Murphy: But now they\u2019re going to do reconnaissance, and they\u2019re going to look around \u2014 see what else you have access to, what other systems are available for them to look at, connect to, see the traffic \u2014 and this is where they start their privilege escalation.<\/p>\n
David Puner: What is something that they would \u2014 like an eye on the prize \u2014 what would they want to get to first?<\/p>\n
Bryan Murphy: So maybe I have an admin account that I use. Maybe I have administrative access to data. It doesn\u2019t have to necessarily always land at \u201cyou have administrative access to servers.\u201d It could be that you have access to data. Maybe you\u2019re working on a top-secret project. Maybe you\u2019re working on something for the company, that they\u2019re going to go in a different direction, they\u2019re going to acquire somebody \u2014 could be a litany of things. And they don\u2019t know what they\u2019re looking for, they\u2019re just looking for something that they can use for profitability.<\/p>\n
So if that\u2019s extortion against you or that\u2019s selling it to your competitors, they\u2019re looking for this information. But we typically see them go after the administrative access to the systems to take your environment down.<\/p>\n
David Puner: Okay.<\/p>\n
Bryan Murphy: This is where we get into the traditional ransomware \u2014 you know, all your systems are locked and encrypted. We all know this and are fighting against it. There are other ways for them to attack and extort you without taking over your systems with administrative access.<\/p>\n
David Puner: Okay, and is there anything new or novel that they’re going after these days?<\/p>\n
Bryan Murphy: I wouldn\u2019t say it\u2019s exactly new, but it is important to call out \u2014 and this has to do with your virtual infrastructure or your hypervisors.<\/p>\n
David Puner: Okay. So hypervisors \u2014 just to interject here so the listeners are all on the same page \u2014 tell me if I\u2019m right here, what a hypervisor is: it\u2019s kind of like the manager of virtual machines and it helps virtual machines share a computer\u2019s resources like memory or processing power without interfering with one another. Did I get that right?<\/p>\n
Bryan Murphy: Yes. Think of it as the host.<\/p>\n
David Puner: All right, sorry to interrupt there, but I think it\u2019s important that we define what a hypervisor is for the audience.<\/p>\n
Bryan Murphy: Absolutely.<\/p>\n
Bryan Murphy: So going back to why this is important \u2014 many of our customers that we see have their hypervisors domain-joined. So when you think about it, they\u2019re using a domain credential to access all of the hypervisors they have in their infrastructure.<\/p>\n
With all of these hypervisors there, the attacker \u2014 if they\u2019re able to grab that domain credential \u2014 now has access to the host or the hypervisor within your environment. So when you think about this from an attack perspective, they\u2019re not attacking each individual system or server you have. They\u2019re attacking what hosts or holds them all \u2014 and they\u2019re gaining their foothold there.<\/p>\n
So now they don\u2019t need to have the credentials to every system. They have access to the infrastructure. They\u2019re just gonna delete your backups. They\u2019re gonna shut down those systems. They potentially could clone them, take them offline, and try to brute force or do other things they want to do with these systems once they have that information.<\/p>\n
David Puner: This is in an on-prem environment that we’re talking about here?<\/p>\n
Bryan Murphy: Yes.<\/p>\n
David Puner: Okay. So do you see this happening in cloud environments also? And then what are the ramifications for both on-prem and cloud?<\/p>\n
Bryan Murphy: So it does, David, and I appreciate you bringing that up. The reason I started with the hypervisor in our conversation is that everybody has hypervisors. We understand they\u2019re in our infrastructure, and we have to protect them. But I don\u2019t think a lot of people understand the criticality of mapping them to the domain accounts. And it\u2019s not to say you can\u2019t use a domain \u2014 it\u2019s just saying it\u2019s usually tied to a credential that somebody knows, and it\u2019s giving them access to many machines.<\/p>\n
But getting back to cloud and where you were asking about this \u2014 we see the same thing. Maybe you\u2019re using Okta or something else for your IDP, and what you\u2019ll see is you replicate your credentials from your Active Directory on-prem to your IDP in the cloud. And now you have the same username, same credential in both spaces. And it\u2019s okay.<\/p>\n
But where we fall into a trap is that we use that credential in the cloud to gain us access to the systems \u2014 just like we said about the hypervisors. So now if the attacker has that credential \u2014 and I\u2019m going to segue back to the social engineering where they stole the MFA device \u2014 they can now approve anything in the cloud. They can do what they want to do there because they know the credential and now have the access.<\/p>\n
David Puner: So we\u2019ve gotten basically three levels of this attack. You\u2019ve got the initial help desk social engineering aspect of it, and then you\u2019ve got to the next level, which is the hypervisor attack. And then you\u2019ve got what you were just talking about \u2014 about taking it even further. So how can organizations prevent or mitigate these attacks, and at what phase? Because obviously if you don\u2019t mitigate it or protect yourself against it from the initial wave of attack, then you\u2019re onto the next level of it. So maybe let\u2019s start with the initial attack and then take it from there.<\/p>\n
Bryan Murphy: Yes. The best thing we see customers do is implement some sort of credential tiering and some way to isolate where the credentials have access.<\/p>\n
So to frame this up for our listeners \u2014 if you think about credential tiering, think of it as: whatever credential you\u2019re using has access to a limited number or subset of systems within your organization.<\/p>\n
Now, the traditional way we recommend this is we look at critical assets to run the infrastructure \u2014 yes, that would be the hypervisor, that would be the cloud infrastructure \u2014 and we would consider that to be called something like Tier 0.<\/p>\n
Now, with those, you would have a single credential to access Tier 0. Then when you move to your other tiers \u2014 we\u2019ll call Tier 1 our servers or our application servers that we use within our organization that are not infrastructure-related but still important for us to have \u2014 we would have a separate credential there.<\/p>\n
When you think about this from an attacker\u2019s perspective, they\u2019re now not looking for one credential. They have to get to multiple credentials to get to multiple systems. So what we\u2019re doing is we\u2019re making it harder for them to take over our whole environment \u2014 whether it be in the cloud or on-prem where we have our systems.<\/p>\n
David Puner: Is there a name for that?<\/p>\n
Bryan Murphy: It\u2019s called credential tiering, is what it\u2019s often known as.<\/p>\n
David Puner: Okay.<\/p>\n
Bryan Murphy: But I will say, I think a lot of us in the industry have had trouble implementing this, and we find it a very daunting task to do. And the way I try to pose it to our customers that work with our teams at CyberArk is that you don\u2019t have to do it end to end.<\/p>\n
So when you start talking about tiering, you go into: I\u2019ve got Tier 0, I\u2019ve got Tier 1, I\u2019ve got Tier 2, I\u2019ve got critical assets, I\u2019ve got this, I\u2019ve got all these different control planes \u2014 and it just becomes overwhelming. Just like everything in our life, if we feed ourselves too much data, we just get overwhelmed and we sort of shut down.<\/p>\n
What we tell our customers to do is \u2014 hey, start doing credential tiering, but maybe start slow. Let\u2019s start with Tier 0. Let\u2019s just figure out what those are. Let\u2019s put a credential around those. Everything else \u2014 it\u2019s just as it was.<\/p>\n
Is it perfect? No. But it puts us in a better position to react when a cybersecurity incident happens. And since we separated Tier 0, we now have an understanding, we\u2019ve practiced, we\u2019ve built repetition on how to build these credentials and isolate our assets. We can then in the future worry about the additional parts of tiering instead of trying to do it all at once.<\/p>\n
David Puner: Is there a fundamental new way that organizations should be training their help desk employees \u2014 or just employees in general \u2014 to recognize and respond to social engineering attacks?<\/p>\n
Bryan Murphy: This is me personally \u2014 I feel we need to do the… I don\u2019t know if you\u2019ve heard where somebody asks you a question, you sort of pause for a couple seconds and you process what they say before you respond.<\/p>\n
David Puner: Mm-hmm.<\/p>\n
Bryan Murphy: Yes. I think we need to implement more of that when we start working with our help desks. Because if somebody needs a credential, it\u2019s great. When one of my guys needs to have their credential reset, a lot of times they\u2019ll come to me and say, \u201cCan you open a help desk ticket? Can you do this for me? I need to get access.\u201d And we\u2019ll have a conversation.<\/p>\n
I\u2019ll either call them, I\u2019ll talk to them first \u2014 make sure that it is them that I\u2019m talking to \u2014 before we implement the request to get the credential reset. And a lot of times it goes through multiple people. It might be one of their peers says to me, \u201cYes, I know this person needs it.\u201d It might be myself and then also the help desk. Or they\u2019ll send me an email, they\u2019ll send me a text message \u2014 they\u2019ll do it through multiple protocols of ways to connect so that we can verify who they are.<\/p>\n
David Puner: Mm-hmm.<\/p>\n
Bryan Murphy: Right. And there\u2019s even been times where when they\u2019ve asked for stuff, I\u2019ve been like, \u201cHey, jump on a call with me. Let me see you physically.\u201d I think physically seeing someone is the most important thing. I don\u2019t have this problem, but your hair might not be done \u2014 things like that \u2014 when you get on the phone. It\u2019s fine. We just need to make sure you are who you say you are, because the attackers are now using these deepfakes to pretend to be us when they\u2019re calling other people within our organizations.<\/p>\n
David Puner: Wow. It\u2019s adding a whole new dimension to what you were doing prior to the whole AI revolution \u2014 or whatever we want to call it these days.<\/p>\n
Bryan Murphy: It is, David, and it\u2019s coming fast. And we just cannot ignore that it\u2019s coming \u2014 and it\u2019s here.<\/p>\n
David Puner: So then I grabbed onto another evolving threat that you were talking about in your Impact presentation. It was something that you called credential dumps \u2014 which, I know we were already talking about credentials. What are credential dumps, and how do the concepts of credential siloing and tiering come into play with the credential dumps?<\/p>\n
Bryan Murphy: Absolutely. And when you think of credential dumps, think of this as: I\u2019m not going to attack every user or every credential within your organization. What I\u2019m going to do is I\u2019m going to attack the system that holds the credentials.<\/p>\n
So maybe this is your IDP \u2014 your identity provider you have \u2014 that\u2019s SaaS, cloud-hosted, in your environment. Or it\u2019s your Active Directory or your directory structure that you have with those credentials you use to access your systems.<\/p>\n
Now, I want to be clear here. I\u2019m not saying that that\u2019s a bad way to store your credentials \u2014 it\u2019s not. This is the way you should be doing it. But it does open up an attack vector where the users that access these identity stores are a bigger target than others have been in the past.<\/p>\n
David Puner: So then what happens if or when your identity solution is breached? First of all, what would that look like? And then what steps can a breached organization take to recover, rebuild, and\/or fix their security gaps?<\/p>\n
Bryan Murphy: This is a great one. We do this all the time with our customers. And the way I can describe it to you is: you have to move away from a directory structure to localized accounts.<\/p>\n
David Puner: Okay.<\/p>\n
Bryan Murphy: And right away, I\u2019m sure everyone\u2019s thinking, \u201cWe can\u2019t do that. We have 5,000, 10,000 users. There\u2019s no way we can move to local accounts.\u201d You\u2019re right \u2014 and we\u2019re not saying to do that. But we\u2019re saying to use local accounts for just two users, to start to control where the trust is within your environment. So you\u2019re regaining the trust within your IDP \u2014 so that you can reset the verification factors, the way that people are going to get the identity store to be trusted again.<\/p>\n
Oftentimes what we do here at CyberArk is we will stand up a second identity structure with CyberArk to be the source of truth during the incident. So this way, you can use something new that you trust to then allow the federated access and everything you need to get into your systems \u2014 without doing local accounts everywhere \u2014 and regaining the trust.<\/p>\n
Once the trust is restored to the identity provider and we have control back, we can then switch back to the other identity store we have. We find customers do this and it works well.<\/p>\n
What they\u2019re starting to also consider is not having a single identity store anymore. And there are pros and cons to this. But they\u2019re starting to think about maybe having a second identity store just for their security tools \u2014 just for their IDP \u2014 so that if multifactor device A is compromised, it\u2019s not the same device they\u2019re using as B to connect to these high-target assets that they have.<\/p>\n
David Puner: Are there any particular pros and cons to that that you want to address \u2014 that you think are worthy of mentioning here?<\/p>\n
Bryan Murphy: I think it\u2019s definitely worth having the conversation, because there are challenges to it. If you\u2019re replicating data from a single source \u2014 if the source is compromised \u2014 it can trickle down between. But really the stopgap here is the multiple MFA devices that you would use.<\/p>\n
And this doesn\u2019t mean two phones. It could just be that you have two different authenticating apps \u2014 A and B \u2014 that you use for the different ways you\u2019re logging into the environment. So think of: if you\u2019re a privileged user, you\u2019re going to use MFA device A or app A. And you\u2019re going to use B if you\u2019re logging in as a standard user.<\/p>\n
So now, this way, if they go to do a reset, they\u2019re not doing a reset on just a single MFA product. They have to do it on multiple to gain the access. So it\u2019s definitely something to consider. There are challenges around it \u2014 it\u2019s not a perfect thing that you can do \u2014 but it\u2019s definitely something worth considering.<\/p>\n
David Puner: How does time factor into all this? It seems like anything more that people are expected to do or need to do \u2014 it feels potentially burdensome or time-consuming.<\/p>\n
Bryan Murphy: Our world is moving faster and faster. And what they want to do is they want instantly to have any access or any information that they need at their fingertips.<\/p>\n
And when you work on an incident, one of the biggest pitfalls we see customers fall into is \u2014 they\u2019ve been tied up and they haven\u2019t had the funds or the ability to make things the way they want them to be, for whatever the reasons are.<\/p>\n
And the trap they fall into with time is \u2014 they say, \u201cI now have the opportunity to build it the way I want to. I can make this perfect. I can make it as secure as it needs to be.\u201d And when you\u2019re working through an incident, that should not be your goal.<\/p>\n
Your goal should be to get a system functioning that provides the access others need. Because every little bit you add to it \u2014 you\u2019re taking time away from somebody else who may need to recover another system. Maybe Bryan here is sitting waiting for the hypervisor team to build me a VM to get my app up. They can\u2019t get to building my server until they build your server in the list.<\/p>\n
And when you work through an incident, you have to think of: these systems are only going to live in the state they are for about 30 days. And then, as we go past the 30 days, we can build it as robust, as secure as we want to \u2014 beyond. But we can\u2019t do it within that initial time when we\u2019re trying to get all of the systems functional and operational again.<\/p>\n
David Puner: So it\u2019s a step-by-step. It\u2019s phases.<\/p>\n
Bryan Murphy: Yes.<\/p>\n
David Puner: So then we\u2019ve established many times over here that you are on the front lines. So based on your incident response experience, what are some of the general best practices for incident response teams to effectively manage and recover from cyber incidents in general? We\u2019re going general here.<\/p>\n
Bryan Murphy: I would say you have to have, obviously, a plan. And any sort of incident you work through \u2014 it\u2019s all about how you prepare. So we said plan, preparation, being ready for it, how we respond \u2014 we want to know that. But even more so than that is understanding how you\u2019re going to validate. Understand who\u2019s on the calls, who\u2019s working with you \u2014 because you\u2019re going to have third-party vendors from every different product line that you have coming in to help you on these war room calls and things that you\u2019re going to do \u2014 which are not people that you know.<\/p>\n
And the reason I bring this up is \u2014 we have seen attackers be on the machines with us and on the remediation war room calls as you\u2019re trying to kick them out. This is where we\u2019re going to bring it all back to those deepfakes we started early on with, David. And we\u2019ve seen them say, \u201cI\u2019m going to verify this is John who\u2019s on the call. This is Tina who\u2019s helping us out.\u201d And someone is verbally verifying them \u2014 not visually, or not knowing what asset they\u2019re coming from.<\/p>\n
And we have seen where the attacker then is understanding what you\u2019re doing to find them and eradicate them from the environment \u2014 and they\u2019re able to stay one step ahead of you because they\u2019re hearing everything you\u2019re working on.<\/p>\n
So while it may seem a little bit like lip service \u2014 that, hey, do a visual verification, know who these people are \u2014 it\u2019s really critical to do that in your security events. Even if it\u2019s someone you haven\u2019t met, you just want to see them so you can see each time they join the call, they are the same person, they are in the same place. These things are happening with people you know, and it\u2019s not somebody new who\u2019s jumping on the call that\u2019s untrusted.<\/p>\n
David Puner: Are there any particular types of industries or organizations that are more susceptible to these new types of evolving threats that we\u2019re talking about today?<\/p>\n
Bryan Murphy: I have to say no, unfortunately. And that\u2019s because they don\u2019t have a bias. They\u2019re going after whoever they can get. And if they\u2019re able to get a credential, or get a phishing email to you, or craft something to get the credential from certain organizations \u2014 they\u2019re going to take what they can get.<\/p>\n
Now, I want to separate that from nation-state attacks and specifically crafted attacks against organizations. Those are still happening. For the general population that\u2019s out there, any of us could be susceptible to this by clicking on a link, doing something that we don\u2019t know, putting in our credentials on a site that\u2019s not correct, where they harvest them from us \u2014 it can happen to any of us.<\/p>\n
And this is why it\u2019s so important that every single person \u2014 whether it\u2019s your home life or your professional life \u2014 is very diligent about making sure they\u2019re not clicking on inappropriate links.<\/p>\n
David Puner: When you think about all of this \u2014 and the emerging threats and the evolving threats and everything that\u2019s going on in the cyber world \u2014 how are you thinking about identity as it figures into all of this?<\/p>\n
Bryan Murphy: The challenge I see with identity is that \u2014 with people \u2014 we\u2019re building a digital footprint. And as these applications and platforms grow, our digital footprint and our digital profile is growing.<\/p>\n
Now, the consensus is to have this all be one so that we can verify who somebody is by having one digital profile. It becomes challenging because now the attackers can really pinpoint who you are. They can say, \u201cI know you go to Subway every Thursday, and you do this because I see you used your card to get your rewards.\u201d And these different things happen \u2014 we\u2019re building patterns that are able to be tracked with big data.<\/p>\n
And it\u2019s allowing for, obviously, corporations to use it to advertise and market more \u2014 and it has value. But it also has equal value to our adversaries as well.<\/p>\n
David Puner: Whenever I talk with you, Bryan, you\u2019ve always got some interesting insights into how we conduct security at a personal level \u2014 which obviously has broader implications considering that individuals together comprise an organization. What are you seeing on this individual level these days that we can learn from and bring into our professional cyber hygiene practices?<\/p>\n
Bryan Murphy: I think the first one is \u2014 use a password manager. Use something to create unique, obscure passwords to what you use. And it sounds like an old term to say, but it\u2019s not being done today.<\/p>\n
I can\u2019t tell you how many people I talk to and say, \u201cWhat\u2019s your password?\u201d It\u2019s their kid\u2019s name and a date. It\u2019s their dog\u2019s name, plus another name that\u2019s in there. And it\u2019s very guessable.<\/p>\n
But the more concerning part is not that the password\u2019s guessable \u2014 it\u2019s that they don\u2019t have it unique across different platforms. They use it for, say, social media, for banking, for other financial trades they do online.<\/p>\n
And one of the things I like to see people do in their personal life is try to separate and decouple your social media \u2014 say email address or username that you use there \u2014 from your banking.<\/p>\n
And when you think about that \u2014 if someone steals your social media address, or some blog site you signed up for and they get your email address \u2014 what are they going to do? They\u2019re going to go to the Capital Ones, the JPMorgans of the world, and they\u2019re going to put that email address in and say, \u201cForgot password.\u201d Right? They\u2019re going to try to figure out where else you have accounts.<\/p>\n
Well, if those two don\u2019t match \u2014 well, your digital footprint is completely different between the two \u2014 and it\u2019s going to prevent them from potentially stealing actual dollars or funds from your accounts.<\/p>\n
David Puner: So on this podcast, we\u2019ve talked about passwordless and passkeys and alternatives to passwords \u2014 and of course, all the problems with passwords that everybody knows about. In your mind, are passwords here to stay? I mean, the reality is we still have them. But what is your opinion about when we may no longer use passwords anymore?<\/p>\n
Bryan Murphy: I don\u2019t think we\u2019ll ever get away from using passwords. I think it\u2019s going to be more: when do we use passwords and when do we do it a different way?<\/p>\n
Because if you think about a secret or a system we\u2019re accessing \u2014 you\u2019re always going to have a secret zero. The initial one that sets it up, the one that goes in \u2014 that will probably always have a password.<\/p>\n
Where we\u2019re moving with the industry \u2014 does that mean that I need a password to log into a website? Does that mean I need a password just to do basic things on the web or on a certain application I\u2019m using on my phone? Probably not.<\/p>\n
So I think we\u2019re at the age where passwords will still exist, but they\u2019re going to be less prevalent than they were before. And we\u2019re going to move to stronger authentication methods for the different things that we do with our devices.<\/p>\n
David Puner: And as you\u2019re seeing it, are users generally using stronger passwords and usernames than in the past?<\/p>\n
Bryan Murphy: I like to use the password analogy. When I say what people do, there are two analogies here that I\u2019ve had that have really made people\u2019s faces go \u201cAh.\u201d You say, when you’re building a system, they use a TLA \u2014 a three-letter acronym \u2014 123. So if you work for a company, it\u2019s the TLA of that company, 123 is the password. And it\u2019s generally the build account or the over-permissioned account to access systems.<\/p>\n
Now, that\u2019s somewhat gone by the wayside \u2014 but you still see it out there in the organizations.<\/p>\n
David Puner: So differentiate those passwords and your username across accounts, no matter whether it\u2019s in your personal life or at work.<\/p>\n
Bryan Murphy: Yes. And we have precedent for this too, David. If you think about it \u2014 when you log into a system, don\u2019t we do a dash A or a minus A account for your admin, and we do just your standard David account for logging into your systems?<\/p>\n
We already have precedent for separating it out. We just need to now take it a little further.<\/p>\n
David Puner: Bryan Murphy from the front lines \u2014 thanks so much for coming back onto the podcast. Great to talk with you and hope to see you soon.<\/p>\n
Bryan Murphy: Thanks, David. Always a pleasure.<\/p>\n
David Puner: All right \u2014 there you have it. Thanks for listening to Security Matters. If you liked this episode, please follow us wherever you do your podcast thing so you can catch new episodes as they drop. And if you feel so inclined, please leave us a review \u2014 we\u2019d appreciate it very much, and so will the algorithmic winds.<\/p>\n
What else? Drop us a line with questions, comments \u2014 and if you\u2019re a cybersecurity professional and you have an idea for an episode, drop us a line. Our email address is securitymatterspodcast (all one word) at cyberark.com. We hope to see you next time.<\/p><\/div>\n","protected":false},"featured_media":213792,"template":"","class_list":["post-209071","podcast","type-podcast","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\n