It’s easy for technologists to start looking for technical solutions to help with solving problems, including our own. Like most IT services providers, we’ve been taking an inward look, especially since the summer of supply-chain attacks. Had we been practicing what we were preaching to our clients?
We’ve been using the NIST-CSF and CIS20 (now CIS18) for a couple of years as guidelines for our clients’ businesses. Because of our work with investment firms, we blended those with requirements from financial regulators. We took this framework and went through it as objectively as we could. That process identified some areas for improvement. We’ll explore them here.
Train Your Employees
We started to bring our employees through the same security-awareness training that our clients go through. We added training for our technicians on how our standards affect the security of our company and our clients’ companies.
As technology service providers, we have access to sensitive information. The first step to taking appropriate care is understanding the risks of possessing or accessing sensitive information.
Least Privilege
We only need the rights to do the tasks we’re doing right now. For example, as I write this article, I’m using my daily account on my laptop. My daily login has access to my documents and my email account, as well as the ability to run my applications. I don’t have admin rights on my computer, and the account is not the global admin for my Office 365 account. My accounts as an owner are the ones that would be at most risk. And, as good as all of us are at identifying a dodgy email or attachment, it’s just not worth the risk.
If the data or process does not have to be accessed by the employee, don’t allow it — or only set it up temporarily. For example, we don’t allow our technicians to delete assets from our remote monitoring and management (RMM), professional services automation (PSA) or documentation. Occasionally, however, we need to do some cleanup. So, I give the assigned tech access, and I send a future email reminder to take it out.
Multi-Factor Authentication Everywhere
We reviewed every application to which we had a login account. First were the riskiest ones (remote control, RMM, documentation, PSA, etc.) Next, we reviewed all the systems listed in our password manager and made sure our accounts used multi-factor authentication (MFA) or single sign-on (SSO) with Azure. If the application or site didn’t have MFA available and couldn’t be replaced or eliminated, we used long and random passwords stored in our password managers.
Use Secure Networks
We’ve been a virtual team for more than five years, since when I closed my physical office. We have been sharing our networks with our families for a long time. As much as I’d like to think differently, that does put us at risk. It was time to look inward, and we segmented my home network. We created segments for our IoT devices, our family and the business, and we prevented crossover wherever possible.
Because we’re all mobile, and because I can’t control the networks my techs are using, we implemented a Secure Access Service Edge (SASE) system on all our work computers. And although we cannot lock down all our vendors to just those IP addresses, our policy is that you must use that system actively for work. The IPs are logged and alerted on for other systems, like Office 365, so that, if a tech steps out, I’m going to know, and they know I’m going to ask questions.
Review Your Third Parties
We use third parties to augment our businesses, such as an outsourced security operations center (SOC) or help desk, or the software-as-a-service (SaaS) solutions we use to service our clients. These third parties bring great value, but they also bring risk. It’s time to review them and ask them questions about their internal security practices. There’s no assurance that they won’t suffer a breach, just as there’s no assurance that we won’t.
Log Everything
If your systems allow it, keep logs. If you can, keep them in another system. If your logs allow it, get alerted for riskier activity, such as logging in from an unknown location or downloading a lot of data.
Build an Incident-Response Plan
One thing that became evident to me—in particular, after the Kaseya breach —is this: Any response plan I may have had was only in my head. Also apparent was that I wasn’t confident that my team would know what to do. We had built business-continuity and resiliency plans for our clients, ran recovery tests and even done security tabletop exercises, but we hadn’t for ourselves. We began documenting all our critical systems as well as our contingencies if we needed to do without. (For example, independent remote management, backup and secure storage of documentation and passwords, and more.)
Of course, this only scratches the surface. These aren’t earth-shattering ideas. They weren’t revolutionary to me, either, when I heard others bring them up. But just as with marketing, the recipient has to be ready to receive the message.
