S6:E4 – Cybersecurity Awareness

Speaker 1:

From Carr, Riggs & Ingram, this is, It Figures, the CRI podcast, an accounting advisory and industry focused podcast for business and organization leaders, entrepreneurs, and anyone who is looking to go beyond the status quo.

David Mills:

Hi, welcome to this month’s podcast. This month we’re going to be talking about cybersecurity. I’m David Mills with CRI.

Tyler Mills:

And I’m Tyler Mills with CRI.

David Mills:

So we wanted to actually just throw some things out there for you. Hope it helps and hope it gives you some ideas and some takeaway. So one of the things I really have been hearing a lot about and trying to figure out just exactly what all of it means from a user perspective is the use of pass keys versus passwords. And pass keys came out, I remember starting to see those maybe a year or so ago, something like that. But it looked like a QR code, and so it was a little concerning but it actually uses what’s referred to as public key infrastructure versus passwords, which we know are inherently insecure. So Tyler, what’s your take on pass keys versus passwords?

Tyler Mills:

Well, I like pass keys. I use them. They’re convenient. I would say that they’re not necessarily going to replace a password in most respects because in a lot of situations where you’re going to use a pass key, you’re going to use it as your form of MFA or multifactor authentication, and it will serve as the sort of physical part or something you have a part of that multifactor handshake. So I think there’s still a place for passwords because we don’t want to have that single form of identification. But pass keys end up being a lot more convenient for the user. And unlike almost anything else, the more convenient option is actually more secure because it’s very difficult to phish a pass key because the user only ever really inputs a biometric, which is difficult to phish.

When you’re talking about using a traditional password and maybe a token or a one-time passcode where they’ll send you a four-digit code via text message or something like that, that’s pretty easily phished. You can pretty easily convince somebody to give that to you once you have it. With a passkey, it lives on your phone. There’s a private key on your phone and it uses your thumbprint or your face ID to authenticate against that private key, and then all of that information is passed without any further intervention from the user.

David Mills:

So where are those passkeys stored? Are they actually, like for example, we’re in the Mac ecosystem. So is it stored on the new password app that Apple has out?

Tyler Mills:

Yes. Well, the public key information is stored in the cloud, yes. The private key part of that is stored on the device. So when you create a passcode, the phone generates a public key, and that’s what gets stored in it’s just called Apple Passwords now. It was the iCloud password manager. That’s the piece that gets stored in the cloud and that syncs across all the devices. But when you restore your iPhone, you have to recreate them because that key goes away.

David Mills:

So it’s necessarily not just a QR code, it is a QR code based on some encryption and the public key infrastructure. But literally when it says when you’re going to give a passkey, it asks for your fingerprint or some other biometric in the Mac ecosystem right?

Tyler Mills:

The QR code is really only to build the key set.

David Mills:

Got it.

Tyler Mills:

So when you do it on your phone, you don’t have to do a key code or a QR code because it just automatically can generate because it’s all on device. The QR code comes in when you’re using a non-Apple, or if you’re in the Android ecosystem, a non-Google service like Microsoft. If you are using a passkey with Microsoft, or I use it, my iPhone for passkeys with Google. So if I sign into Gmail, I use my passkey to do that. To create that key pair so that the phone knows to build that handshake it needs the QR code to get that information to know where to point. But the QR code doesn’t have anything to do with the actual key.

David Mills:

So outside of the Apple ecosystem, there’s no fingerprint. Let’s say there’s no fingerprint reader or anything like that. How does that work to be secure?

Tyler Mills:

You need a hardware passkey, like a YubiKey.

David Mills:

Or maybe even Microsoft Authenticator?

Tyler Mills:

That’s slightly different. I guess that I actually don’t know if Microsoft Authenticator has a passkey functionality built into it.

David Mills:

Okay. Seemed like I read here recently that it does or that they were adding it. But yeah, that was where I was concerned was when you get out of the Apple ecosystem, now you’re talking about something that doesn’t have a fingerprint reader on it. So a lot of times it’s just going to be some sort of an authenticator mechanism.

Tyler Mills:

You need a physical token.

David Mills:

Got it. So that’s the second factor or the something you have?

Tyler Mills:

Yes, that is one factor of the whole passkey is a single factor of authentication that counts as one but you have to have something physical where the private key can live. If you’re a Firefox user, you can store the private key on your computer, you can do that. It’s less secure, but you can do it. But something like a YubiKey, which is a physical hardware key can-

David Mills:

A USB token or something.

Tyler Mills:

That’s right. And you can use that instead of a phone. There’s no biometric associated with it, but it’s still technically not knowledge based like a password or a biometric. So it does count as a something you have. The biometric part of the passkey is still, I guess technically I see where you’re coming from. Technically, there’s two factors of authentication because you have to have the phone to use the biometric. But if you’re talking about NIST standards, I believe that only counts as one. So if you need authentication level two or three, you’d have to have a truly separate set of authentication.

David Mills:

So just for those of you who are listening, we keep talking about things, things you have. When you’re talking about true two-factor authentication, there’s three areas. There’s something you know, something you have or something you are. And something obviously is a password or maybe even a picture identifier. And then something you have would be a device. Normally this is a device that is not the device you’re trying to log in on, although as Tyler said, there’s some like Firefox will allow you to technically do that. So you have to be careful about that. But then there’s something you are, which is the biometric, a retinal scan, a fingerprint reader or something like that.

So the beauty of this is that you’re not having to remember long passwords and trying to type those back in. It does meet the two-factor authentication requirements that we’re talking about. And just as a reminder, make sure you understand the difference between two-factor and really multifactor. Multifactor means that there’s two forms of authentication but oftentimes people get confused about whether or not that form of authentication is the same. So for example, if you have a password and a picture, that’s really not two-factor authentication, right Tyler?

Tyler Mills:

No. Yeah, that’s not an acceptable form of multifactor. As a matter of fact, well, if you’re using both, that’s technically acceptable. But if you’re talking from a NIST standpoint, authentication level one, you only have to have a single form. But it specifically says that it can’t be knowledge-based, so it can’t be a picture or something like that. So if you were going to do that, it would add a level of security, but there has to be a password in front of it.

David Mills:

Got it. So speaking of NIST, didn’t they just released some new password requirements. So can you give us maybe a quick overview of that?

Tyler Mills:

So this is big buzz. All of the articles that I’ve read about it sort of are pulling out of context the changes to their password parameter guidelines. In other words, traditionally and if you work in a corporate environment, you’d be familiar with this, you have to have 8 to 12 characters. But then some of those characters have to be capital letters. Some of them have to be lowercase.

David Mills:

Complexity.

Tyler Mills:

Yes. Some of them have to be numbers and some of them have to be special. Essentially what the new NIST article says is that they no longer have to include that. I no longer have to include special characters. That you shall not, as a matter of fact is the wording impose composition rules like mixtures of different character types and so on and so forth. They do say it has to be 8 characters long and they suggest it be 15. Just from an entropy standpoint, the math around hacking a password, the longer it gets, the more difficult it is, no matter how complicated it is. It’s not irrelevant, but the length is really what makes it difficult for somebody to crack a password.

David Mills:

But that almost sounds counterintuitive to what we’ve been trying to preach now for the last few years, which is obviously length and complexity to get maximum entropy or randomness if you will for a password.

Tyler Mills:

Well, it’s more efficient to guess a password than it is to crack one. So if you got a password database, you could run it against a rainbow table or something like that, which would potentially give you a match on the back end there. But the reason why, the thinking behind the complex password is that if you’re only requiring people to have 8 characters, because that’s about as many as anybody can remember, if you’re only going to require him to have that, it can’t be roll-tied because everybody in Alabama-

David Mills:

Or it can’t be monkey or-

Tyler Mills:

That’s not enough characters but yes, but yes, it can’t be an easily guessed password. So if I know that my boss is a big Alabama fan and I put his username in and put roll-tied, and that’s his password I’m in, right? So if you have to make it roll-tied, but it has to be a zero instead of an O and exclamation points instead of an L, there’s some security there. So that’s the original thinking behind it. What it really does is make it so that people can’t remember them, so you have to write them down or you should use a password manager. But if you’re going to go to that point, you might as well use incredibly long and complex passwords because you don’t have to remember them.

But the psychology is that the more complicated you make people make their passwords, and the more often you make them reset those passwords, you give them more opportunities to manage them insecurely, write them down on a post-it note, something like that just because of the inconvenience of it. So the idea that’s been picking up steam lately is that you require a long password, so 12 to 15 characters, but don’t require it to be complex. And the guidance that you give to your people is use a passphrase. So use like four unique, four to five letter words.

David Mills:

That really don’t relate to each other.

Tyler Mills:

No, don’t necessarily relate to each other or that aren’t easily guessed, it’s not clear. This guy loves video games or whatever. So it’s the Mario characters or something like that. But yeah, so a 15 character all lowercase letter password is more secure as far as entropy is concerned. The mathematics around the encryption and the math needed to crack it is more secure than an 8 character password that is mixed case-

David Mills:

With complexity.

Tyler Mills:

Correct.

David Mills:

Yeah.

Tyler Mills:

So this does make sense. The article does make some amount of sense, but of course the sensationalism behind it is actually you don’t have to have complex passwords, everybody’s doing it wrong. And you only have to have 8 and you should have 15, but you only have to have eight. And NIST says complex passwords don’t matter anymore, which is technically true, but it’s not the whole story. The rest in context, the rest of the article is for any level of real risk system, I do a lot of bank work. So like a core application or a wire, anything you can wire money out.

I mean even your banking at home, if you can do an outside transaction or something like that, that’s of significant enough risk that you really need to be looking at a level two level of authentication as far as the NIST levels are concerned. Once you get to that point, the password guidance still holds, but the requirement is that you have a second factor of authentication. Some sort of, even if it’s just an out of band multifactor authentication like we talked about earlier where you get a four digit code sent to a text message or something like that. If it falls up under that level of risk, you need that second factor of authentication. So really the new password guidance only impacts systems and environments of extremely low risk.

David Mills:

That’s the big identifier there, and I think that’s where people are maybe getting the context wrong. I know that if I think about it, I have very few places that I would have that low or risk level to utilize that guidance. And I’m sure there are probably circumstances out there where that would apply. But certainly in most cases I would always recommend that you have at least level two set for anything that you can set it to. And then if there is something that you don’t have a particular or is unable to set the second factor of authentication, then you use the very long passwords, not necessarily the special characters, but the length of the password. And that’s really, if I remember correctly, that’s really because you never break a password one character at a time. It’s got to be done as a whole.

Tyler Mills:

As long as the authentication is working like it’s supposed to, yes. That’s actually one of the specific requirements in the article is that it authenticates against the entire password as a string, not as individual characters.

David Mills:

Not as individual characters. So sometimes the movies don’t portray that just quite right.

Tyler Mills:

No.

David Mills:

And so I think that’s where we kind of get into a little bit of difficulty there. So I guess in summary, if you read that NIST article, just make sure that you understand the leveling of the passwords and that certainly we’re not saying use an eight character password with no complexity for things that you have any risk about, but that you use that level two scenario. And really for me, it would be if I can’t have a second factor authentication, then I’m going to use a very difficult password.

Tyler Mills:

I think that the way that the industry is headed is passwords are sort of they’re not really doing what they once did. They’re constantly getting leaked. People are reusing them everywhere and there’s no real way to prevent that.

David Mills:

Or even if we ask them to change their password off and they’re just adding a character to the old password a lot of times when the systems won’t let them.

Tyler Mills:

Yeah. So where the industry’s going is MFA. It’s going to be everything has MFA or you have to opt out, which is how it is now. Almost everything you log into now it’s like, hey, you don’t have MFA set up. You should set that up, but you don’t have to. But in a corporate environment, there are so few instances of software that would be low enough risk to not need that extra layer. So to me right now, if you’re an IT admin and you’re reading this and going, great, I’m going to reduce everybody’s passwords to nothing. I would say that you should read-

David Mills:

Read the whole article.

Tyler Mills:

Read the whole article but consider the risk. Do a risk assessment and decide, well, this system’s protecting this level of data. And the NIST levels don’t map on necessarily exactly to everything because they’re government, but use your best judgment and decide, hey, that this data’s worth protecting so we’re going to protect it.

David Mills:

Yeah, I think that’s the bottom line is just make sure that we don’t read the first part of the NIST article and run off and start lowering all our password parameters. So one of the things we’d like to talk about here is Veeam and the recent exploit that came out about that. Veeam is a very popular product that we see quite often in the backup world. Tyler, can you give us an overview of that particular exploit and where we are on it?

Tyler Mills:

Yeah, absolutely. I mean, it gets real technical, but it is very interesting. So what essentially it’s an unpatched version of Veeam allows for what’s called remote code execution, which essentially means that an attacker can send code from one place through a network and have it execute on the Veeam server. And what’s really interesting about this is that it allows it to do it unauthenticated.

David Mills:

That’s as bad as it gets by the way from a compromise perspective.

Tyler Mills:

It is very serious. So essentially what that means is that they can run commands and elevate their own privileges without authenticating. So if they are able to compromise a network, which is something they do have to have access to the network first. But if they’re in there, they can tell the Veeam server to build new local administrators and then exfiltrate data. So pull backups off onto their own servers and potentially make configuration changes. So make it so you are no longer backing up or not backing up in the way you thought you were.

David Mills:

So effectively they can get complete copies of your virtual servers. Is that kind of what I’m hearing?

Tyler Mills:

Yeah, well, and yes, anything you’re backing up, they can get copies of it and change the way that you’re backing up going forward. So the attack or the end game really that interestingly enough, Sophos, which uses or has an MDR program, which like a cyber security not kind of thing where they’re looking for data exfiltration-

David Mills:

So they’re monitoring this kind of thing.

Tyler Mills:

Well, this is a service that they’re providing to clients. They act as a vendor and they’re watching for data exfiltration as part of data leakage prevention and things like that. So they have an article out that essentially says that they confirm that this has been exported in the wild that it has happened. And the end game is to pull data off and get sensitive data about the rest of the network, give yourself admin privileges on the server, and then potentially deploy ransomware so now that you have messed the backups up, they can’t recover. So once you’ve put your ransomware in place and it encrypts all the data and they go to recover it from Veeam, you can’t do it. Those backups are-

David Mills:

Encrypted as well.

Tyler Mills:

Correct. But they have clean copies of all your data. Traditionally ransomware is they’ve encrypted all your data and they have the key to decrypt it, but they’re not necessarily getting any of the data off. But in this case, it’s a double whammy because they’ve exfiltrated a bunch of data and then they also have encrypted your data and are charging a ransom to decrypt your data and then can potentially I guess charge you to delete your data off of their servers or can blackmail you with further attacks because they have all that information. I mean, it’s really bad. There’s a patch for it. So there’s another topic I’d like to talk about towards the end, but there is a patch for it. The patch actually came out prior to the exploit being made public really. I went on GitHub this week and you can download the exploit and run it, and it’s fairly straightforward.

You do have to have some knowledge of how XML packet injection works, but not a ton. And you have to have access to the target network, which is hard to get. Usually you’d get that through a phishing attack or something like that. As a matter of fact, the Sophos report stated that almost all of the instances of this being successfully exploited was initiated because of insecure VPN connection which did not have MFAs activated on it.

David Mills:

So we’re right back to that MFA topic again being kind of sort of a key layer in your defenses.

Tyler Mills:

So if you lose or if you have your VPN credentials compromised and there’s no MFA on it, they’re in right? And that’s not that hard to do to phish somebody into giving them your password.

David Mills:

So we’ve got a patch though, correct?

Tyler Mills:

There is a patch on Veeam. So if you are on the latest version of Veeam, this is closed and that patch was early September, September 4th, something like that. But the environment we’re in with patching is a weird one now because of the CrowdStrike outage.

David Mills:

The latest patching, we’re going to say improperly.

Tyler Mills:

Yes. So I mean that was such a high impact event and so far-reaching. The news got it which in cybersecurity doesn’t happen often. Usually there will be like this Veeam thing, huge news as far as how bad of an exploit it is and how risky it is to not patch. That’s not really in mainstream news. But with the CrowdStrike outage, obviously it was. People couldn’t get on planes because all of the computers at the airport were blue-screened. Especially at the sea level, there’s some trepidation about installing patches too quickly now because the whole reason that CrowdStrike thing occurred is because that patch got pushed overnight and then by the time everybody came to work in the morning, the broken patch had already been deployed.

David Mills:

But the fact there is that they didn’t deploy the patch to a set of test systems to validate that it didn’t cause the problem. Is that correct?

Tyler Mills:

CrowdStrike didn’t, which they should have done because this was a kernel. That was a kernel.

David Mills:

That was a kernel update, yeah.

Tyler Mills:

Big problem. So they should have definitely tested on their end first. When you deploy something like that that’s that important.

David Mills:

And I think all the news articles that I read talk about that.

Tyler Mills:

But to your point, should the IT administrators have deployed into a test environment first before taking a patch like that wide? And traditionally that would be the course of action with any patches that you run it on a small set of servers and workstations if applicable. You run on a small set there first, make sure that it doesn’t break and then you can install it wider.

David Mills:

So the guidance that we have out there on patching is still valid. It says to test and evaluate and then deploy. I think the speed at which we test and evaluate sometimes comes into question.

Tyler Mills:

It needs to accelerate, yes.

David Mills:

But I think that the bottom line here is that you can’t deploy a patch just without doing some level of testing. And I think that this Veeam patches probably falls into that category too, where you need to test it in hopefully a test environment before you deploy the patches to all your Veeam servers.

Tyler Mills:

Now, if you’re not already patched at this point and you’re running a vulnerable version of Veeam, you should sort of stop everything you’re doing and patch.

David Mills:

Yeah, get it patched.

Tyler Mills:

Test it if you can certainly, but with zero days you have to accelerate that process. That has to be something that gets patched fairly quickly.

David Mills:

And when we talk about that, accelerating that patch process I think that the zero days probably are probably the most risky from that perspective. But I do think that if you’ve ever, and there’s a lot of companies now that hopefully not as many that you would think, but there’s a lot of companies out there that have experienced a breach. And anytime anybody experiences a breach, I always am a little concerned about did the breach get completely eradicated? Is there anything left behind? So I think for those companies that have experienced a breach, maybe that patch cycle should be a little faster just in case. But I think as a whole, we’ve got good patch processes out there from a guidance perspective, and I think that the companies really should take a look at those and make sure that they’re deploying them properly.

Tyler Mills:

And the final point I’d like to make on it is there are mitigating controls that could have potentially prevented an attack like this. Like I said, it was an insecure VPN connection that allowed attackers to go in a lot of cases.

David Mills:

Yeah. Now we’re talking about the Veeam exploit here.

Tyler Mills:

Yes. Going back to the Veeam exploit specifically. Good controls on your VPN could have potentially protected some of us there. Another piece that is also important is air gapping and immutability in your backups. An air gapped backup would essentially be completely separated from the internal network. So if an attacker did deploy ransomware or gain access to your Veeam configuration, anything like that, the air gap, a true air gap would allow you to have some level of backup assurance depending on how often you can move a backup to the error gapped server. And that would sort of give you a fail switch if something like that were to occur. And those are just some best practices that if you can do them, would definitely have helped in this situation.

David Mills:

Great points. I think that wraps us up. Thanks everybody. This is David.

Tyler Mills:

And this is Tyler.

David Mills:

We’re signing off.

Speaker 1:

If you want more CRI insights or are interested in learning about our firm, please visit our website at criadv.com. Thanks for listening to this episode of It Figures, the CRI podcast. You can subscribe to It Figures on Spotify, Apple Podcasts, or wherever you prefer to listen to your podcasts. If you liked what you heard today, please leave us a review. CRI Advisors LLC is not a CPA firm. Assurance, attest and audit services provided by Carr, Riggs & Ingram LLC. Carr, Riggs & Ingram and CRI are the brand names under which Carr, Riggs & Ingram LLC, CRI CPA, CRI Advisors LLC, CRI Advisors or Advisors and CapinCrouse LLC, CapinCrouse CPA and CRI CapinCrouse Advisors LLC, CapinCrouse Advisors provide professional services. CRI CPA, CapinCrouse CPA, CRI Advisors, CapinCrouse Advisors, Carr, Riggs & Ingram Capital LLC and their respective subsidiaries operate as an alternative practice structure in accordance with the AI CPA Code of Professional Conduct and applicable Law Regulations and Professional standards.

CRI CPA and CapinCrouse CPA are licensed, independent, certified public accounting firms that separately provide a test services as well as additional ancillary services to their clients. CRI CPA and CapinCrouse CPA are independently owned CPA firms that provide attestation services separate from one another. CRI Advisors and CapinCrouse advisors provide tax and business consulting services to its clients. CRI advisors and its subsidiaries, including CapinCrouse Advisors are not licensed CPA firms and will not provide any attest services. The entities falling under V or CRI brand are independently owned and are not responsible or liable for the services or products provided or engaged to be provided by any other entity under the Carr, Riggs & Ingram or CRI brand. Our use of the terms CRI, we, our us in terms of similar import denote the alternative practice structure conducted by CRI CPA, CapinCrouse CPA, CapinCrouse Advisors and CRI advisors as appropriate.