[49] – PSA Security Best Practices

Welcome to PSA Impact, your podcast for all things PSA, RMM, and MSP, with your hosts, Rayanne Buccianico and Chris Tim. Learn how to get the most out of your PSA tool and manage your business by maximizing profitability and increasing efficiency within your MSP business. Let's listen in. Hi, everyone, and welcome to another episode of PSA Impact with your hosts, myself, Chris Tim, and my co-host, Rayanne Buccianico. Hey, Rayanne, how are you doing?

I'm doing great today. How are you? Very well, thank you. All is good this side of the world. Oh, that's good.

Good. Hey, listen, Chris, I was thinking, you know, we finished up our implementation series and we never stopped long enough to talk about, you know, the big security data breach that Kaseya had, and what does that mean for MSPs and security at the PSA level? And I thought, you know, maybe we should at least touch on that. Great question. And nobody likes to talk about security, but I guess for the purposes of this podcast, I'm going to say it's my favorite topic, but security is not really, but for the purpose of this, it is.

Right. I don't know that it's anybody's favorite topic, but it's one of those, you know, necessary evils. So I'm sure that there's plenty of things that an MSP can do to protect their data in PSA. I remember years ago, you know, when PSA was a brand new thing on the block and, oh, well, you didn't really have very much confidential information in your PSA. I recall people not having very secure passwords, right?

Well, you know, the world has changed. The PSA has changed. We have all sorts of information that's in the PSA, passwords, configuration items, connections, single sign-on connections to the RMM tools and all of that other stuff. So what are some of the hot tips that people can do to secure their PSA? Yeah, great, great topic and great, great thing to talk about.

You're right. And I think, you know, security and passwords have come on a long way since the days, well, the old days of IT and the old days of Autotask. So certainly they've made a lot of changes in the product by bringing out things like enforced 2FA and all of those sorts of things. But you know, one of the ways that I think people can get around this breach that's recently happened is try and lock down the systems as best as you can. And one of the ways that Autotask allows you to do that now is to use single sign-on.

So using SSO with Microsoft or, you know, any of those kind of tools where you're actually using your Microsoft credentials to log in to Autotask. So then you don't need to have an Autotask username and password and 2FA and all of that kind of stuff. And all of the security side of, you know, using your SSO stuff or your Microsoft credentials, all of that is now used inside Autotask when you log in. Interesting. So now we're talking about a single pane of glass, right?

And so you're logging in to multiple places with one logon. How does that make that even more secure than having multiple logons with different passwords? I mean, it's no more secure than using 2FA, but I think, you know, Microsoft has a lot of security features that are kind of built in. Conditional access is one of those. So being able to, you know, auditing of users inside Microsoft and who's logging in and all of those kinds of things.

So there's a lot more security built in using the Microsoft logins and SSO from Microsoft than there would be if you were just using just a normal username and password. The other thing it also means is, you know, the more passwords, in my opinion, that you give to somebody to remember, the more likely they are to just put, you know, rubbishy passwords in there. So if you kind of said, look, the only place you really have to change this in is Microsoft, you know, you change your Outlook account or your Microsoft login account, and that automatically is the same account that you then use to log into Autotask with. People are less likely to use, you know, weak passwords or less likely to use passwords that are going to not be secure. So I think neither of them are safer necessarily than the other.

I think, you know, using 2FA is a good option, but equally, you could have a password of Crescent Sandella Consulting with a password of 12345 and 2FA, and then it's kind of not really that secure. Whereas also Microsoft forces you to have strong passwords. Yeah, that's true. And before I move on to my next tip or suggestion, I just want to say that if you're using the single sign-on with Microsoft, the rest of these tips probably don't even apply to you. But let's say, for example, that you're not using the single sign-on with Microsoft 365.

Maybe you're a Google shop, maybe, you know, you just haven't set it up, but Autotask actually provides a great paper to show you step-by-step how to set up the single sign-on. So you should check that out. All right. So the next thing is to use possibly random usernames and random passwords. I haven't remembered a password in probably two years since we've adopted a password manager called LastPass, but I know that there's a ton of them out there.

There's KeyPass, there's all sorts of one password, right? There's RoboForm. There's all sorts of password managers out there. And I don't let anybody in my office actually make a password. One of my coworkers, she would have to hunt and pet to try and come up with some crazy password because I require strong passwords on everything.

And I simply showed her the little generate secure password option in LastPass, and she didn't even know that the feature was there. So now she does, and now generating passwords is no longer an issue. But you know what people probably don't always understand is that your Autotask username does not have to be your email address. It can be any email address that ends in your domain that you would like, right? And it doesn't even need to be a live email address.

So don't even feel like you have to create an email address for it because any communication is done with the email address on the first tab of the information, your name and who you are and what your phone number is and your email address. But the second tab, the security tab, is the username, and that could be anything that you want, run ragged or whatever. So make something up and something fun if you'd like. So I was going to say, and so actually here's the thing. So, you know, you were talking about the random password generator.

So what I actually did is I went in and used LastPass to create a random password effectively, which I used in the first part of my username. So it was completely random, completely weird, and then saved it in LastPass because I never have to remember it. So yeah, there's nothing that says it has to be a valid email address. And actually, here's another tip that I think a lot of people don't know. Actually, if you went to Datto and asked them to change your domain name, you can actually change your domain name to anything else you want as well.

It does not have to be your domain name to log in. So if you really want to be secure and you don't want hackers to potentially know what your domain name is, go to GoDaddy, set up some random domain name, then go to Datto and ask them to just set your domain name to be whatever you've just set up with a weird password, and you're good to go. That's interesting. I hadn't thought of that. But I do recall seeing a number of people who had Autotask domains that are different from their actual domains.

And I totally forgot about that. So good tip. All right. So API users, how many API user accounts are there that are no longer active? Yeah, sure.

They're not charging you for the API user, you know, but why are you leaving that open? Yes, it's only an API connection and there's probably very little a human being can do with an API connection, but you're still leaving that window open. If the integration is no longer being used, get rid of the API user. And here's the other thing is API user accounts by default use a full system administration security level. You can actually set that security level in the same way as you can with any other user security level.

So, you know, you could set it so that your API user, whichever one you're using, is only able to access tickets or only able to access the CRM and not be able to create accounts and all that kind of stuff, because it depends on the API integration that you're using. You know, of course, if you were using a third party quoting tool, then you're going to need to be able to create accounts and you're going to need to be able to update accounts and opportunities and all those kinds of things. But you probably don't need to create a ticket depending on the tool. So why give it full admin access? Why don't you just say for that particular API account for that application, I'm just going to give it the rights that it actually needs in order to connect.

And I think a lot of people don't actually realize that with API accounts as well. Right. So what are some of the next tips that you have? So I think and you mentioned it about removing all API accounts that are no longer needed. One of the other things I would do is to say also remove all normal user accounts that are no longer needed.

So, you know, a lot of people will just inactivate the account, which is fine. You can obviously inactivate it because no one can log in. But what I would actually do is to redact that account. If you think you're never going to use it again, and it's going to get to the point where you are, you know, you're not going to maybe that person's left and it's probably never going to come back and you may not necessarily give their user account to anyone else, then just redact the account completely. And all that will happen is you'll end up getting a user account or any information that you see inside the PSA will just say, you know, this ticket was updated by a redacted user or, you know, this note was added by a redacted user.

So you won't know who they are, but you won't lose any of the information. You'll just lose the username against it and just see the word redacted user. And sometimes that's helpful, especially when a really poor employee finally leaves. You may not want to stare at their name for the rest of your natural life. So, you know, the redacting of that employee would at least remove that person's name from site and that goes a long way inside the company, believe it or not.

And actually, I just wanted to circle back to the API accounts to talk about something. So you mentioned about doing the random usernames and passwords on API accounts. But the other thing that's really important to do is to make sure that you select the integration vendor as well. Don't select your API account with none as the integration vendor. 90% of the stuff that integrates with Autotask actually is on the integration vendor list.

Make sure that you select that. And the reason for that being is if that API account gets hacked or, you know, the integration that you're using decides to become naughty and play games, you can easily see where that's coming from, right? So you can see where the naughty application is, which one's been causing the problems, because it'll say to you, it's come from this user account with, that's part of this integration vendor. So you'll immediately be able to know that it's QuickBooks or whatever tool it is, that's actually causing the issue. I recall seeing some integration that failed for not picking up the integration vendor.

So I want to say that it's probably, I think they're starting to require that. They use the integration vendor. I'm not even certain you can save it without it. Well, you can, believe it or not, still with Zapier. So up until about a month ago, well, it depends when you're listening to this.

It could be six months ago, or it could be a year ago. It depends when you're listening to this. But at the time of recording, about a month ago, Zapier still used API accounts with a none as integration vendor. And it's only recently that it's actually been updated to use, although the integration vendor was always there, but it never actually worked. So their workaround was to use the none, but it now works.

And so there are some instances where that might happen. So maybe we should talk about things like passwords in the configuration item, because you can protect those passwords. So let's talk about that for a minute. Yeah, and that's a great point to bring up, is a lot of people store passwords inside the configuration item. So you might have a server and you might have the username and password and what have you inside that configuration item field.

So you can create user-defined fields for those configuration items. And then if you actually go into user-defined fields, specifically on config items, you'll see two little checkboxes, or actually three checkboxes now, which says protected, encrypted, and I think the other one says private. So the protected means that you can actually lock that down to certain users. So if you had a password for a server, for example, you could say, you know, this password is not available to X, Y, Z user, right? So all they will see is a bunch of stars.

The field will be grayed out. They won't be able to make any changes. They won't be able to do anything. You can also equally give somebody view-only rights to that password. So all they can do is see it, but not actually change it.

And then, of course, you can give people access to completely edit and change that password. So that's what protected means. And then, of course, you've got encrypted. And encrypted will do two things. Or a few things.

It will lock the password down and encrypt it inside the database so that even the people at Datto, when they are supporting you with their sort of elevated security login, they won't be able to see that password inside the database. But the other thing it won't be able to do is no API accounts will be able to pull that information as well, because the API accounts are reading the database directly, and all they will see is the password hash in there. So it's really good if you've got configuration items, especially if you have API user accounts reading from and writing into those configuration item user-defined fields, you might want to make sure that they are encrypted and set as only certain people can access them. You know, so you bring this up, and that leads me into security levels, right? Because I can't tell you how many times I talk to people that they haven't gotten around to understanding the security levels or how to set them, and what does this security level get this person versus that?

Oh, let's just give everybody system admin. And not only are you opening up all sorts of company confidential information to people that may or may not, you know, need it or should not see it. So take a look at your security levels and make sure that each user or each resource in your PSA is assigned the appropriate level of security inside the PSA, because there's an awful lot of things that they can get to that you may not want them to, and it really doesn't take a whole lot of effort for somebody to start poking around in places that they don't belong. Absolutely. Yeah, I agree.

And I think those security levels are a really important thing to set. And like I said, not just for normal users on the system, but also for API users. Make sure that people don't just have the rights to be able to delete anything. Or, you know, you might have a standard help desk user and you don't want them to be able to delete accounts or anything like that. And also, you don't want that person to be able to see any financial information.

So make sure that those security levels are set exactly as you want them to be for every single user on the system. All right, so now I'm going to ask you a question that's probably a bit controversial in the IT community right now. Okay, so question number one, given we had the SolarWinds tech now the Kaseya, how safe is it for the MSP to be working under a single pane of glass? Because I can see a couple of benefits. You know, if you're using a very secure company and you want to put everything into one place because it's one portal you can log in, you know, that manages all of your clients backup and security and all of that stuff, right?

So it makes a lot of sense to go with a company like Datto or Acronis that really has the security in one big pane of glass. Or should they go for the vendor spread? Spread themselves out over a number of vendors which would include more portals, more logins, but different things would be protected by different companies. Which do you think is the better way to go? Wow, that's a great question.

Nothing like putting me on the spot. So firstly, I would say that nothing is 100% secure. So it doesn't matter what you use, even if you put all of the security things we just talked about inside Autotask, there's still a chance that potentially it could be hacked. It could potentially be breached. To answer your question though, I think the more tools you use, the more passwords you have to set, the more 2FAs you have to set, the more things you have to do to keep on top of all of your security and the more places you're opening up for people to hack.

Because as soon as you turn on all these integrations, if you don't have secure API users or you don't have secure connections to it, then yeah, all they need to do is to hack into one of those other tools and they'll get into your PSA. Which is why you need to make sure that you try and secure anything that's connecting into the PSA as much as you possibly can by locking down your API accounts and all of those sorts of things. But also I do think you need to use multiple tools because the PSA, yes, it's a single pane of glass, but it's probably only going to be a single pane of glass for 80% of your business. It's never going to address 100% of everything that you're trying to do. So there's always going to be a better tool that's going to do something better and there are going to be times when you are going to need to use other tools.

So I do think you do need to use lots of other tools. You just have to make sure that all of those tools are firstly as secure as they possibly can be in themselves, but also that the connection to your PSA tool is as secure as it possibly can be. Yeah, I have the exact same viewpoint, right? Because the more portals that you're logging into, the more chances are that one of those vendors is going to get hit. And today I think we can all agree that it's not a matter of if, but it's really a matter of when.

We know that they're out there targeting the MSPs and we know that they're out there targeting the MSP tools, especially the ones that provide the secure information. So the more vendors, the vendor spread starts to become not only difficult to work with, but maybe not as secure as working with one or two or even three trusted vendors. And you're right, not every vendor is going to have the solution for every one of your customers and you will have to branch out and you should from time to time, look at the different vendors and make sure that you're offering the latest security, the best solution for your customer and something that is going to keep them safe and that you can work with and easily manage. Because we're all in this to scale, none of us are in here in this business to just get by. We want to be successful in business and have our profits show that, right?

Absolutely. And you raised a really interesting point there about being hacked and from time to time, all these tools will be hacked. I remember hearing or seeing a saying that somebody said, and that is, there's two types of people in this world, those who have been hacked and those who will, or at least those who an attempt will be made to hack you. So the only way you're never going to get hacked or you're never going to get your data potentially stolen is to turn off all your devices and go and live in a hole in the ground somewhere and kind of never touch technology and never go near the internet. Because at some point there is going to be a hacking attempt on either the tools that you're using or you as an MSP directly, or whatever the case might be, and we can't get around it.

But what we have to try and do is to mitigate that as best as we possibly can by locking down all of the tools that we have and using the security at our disposal to lock those tools down to the best way that we possibly can. I agree. Well, I don't know that we're going to solve the world's problems on ransomware and hacking today, but hopefully we've given our listeners some useful tips. And if you have any other useful tips out there, this is a call out to our listeners. Did we miss something?

Is there something that we should add to the list? You know, reach out to us on all of the socials and let us know how we can improve the list. Absolutely. You know, and if we're completely wrong by what we've said, then, yeah, I mean, by all means... You can count on that too.

Yeah, exactly. Come in and tell us, right? Come in and talk to us and tell us why we're wrong with how we should set these up. I'd love to hear the thoughts of other MSPs, especially around things like, should we use SSO versus 2FA? Or, you know, what are the security risks or implications of using both of them?

So, yeah, call out to any MSP that is listening to this that wants to come on our podcast. Reach out to us. We would love to have you come on. So, that was a really cool, fun episode and a good topic to talk about, Rayanne, and hopefully we've given some really useful information in there. I think so.

And I thought it was a fun conversation, but also one of those necessary conversations that we have to have from time to time. Are we doing enough to secure our systems and secure the systems of our customers? Absolutely. And that's not a question you can answer once and move on. It's a question that you need to ask yourself at least three times a year.

Exactly. I agree. So, yeah, awesome topic, Rayanne. And you know what I'm going to say now? The only thing left really for me to say is, your PSA is the key to your business success.

So, go out and make an impact on your world today. Thanks, Chris. Great conversation. Thanks, Rayanne. Thank you for joining us today on PSA Impact.

We hope you've learned something and that you'll join us next time when we answer new questions posed by our listeners.