I have spent the better part of 20 years in the IT Support and IT Management business, and I have come to the conclusion that we are collectively terrible at “eating our own dog food,” as the saying goes. What we do for our clients should be a reflection of what we do in our own environments, but many IT service providers fall short in this regard.
As we make the transition from offering traditional managed services to incorporating security services into our stack, we’re taking on much more responsibility. Clients are now trusting us to provide them with the technology that can keep them protected, but how can they fully do so when we’re not also adopting this within our own business? Use the following tips to get started on practicing what you preach so your clients can enjoy better service delivery and increased satisfaction.
Why Should I Practice What I Preach?
Now, you might be asking yourself, “why is it so critical for me to adopt my security services internally?” First and foremost, it allows you to show your clients how serious you are about their security. “Security” shouldn’t be a blanket term, so when you’ve gone to great lengths to secure your internal environment, it proves that you believe in your own offering. The second reason is that you can provide proof that your security services work and can be applied to your clients’ environments as well. You shouldn't be selling something that you aren't comfortable using yourself. If actions speak louder than words, then this should ring loud and true as you begin showing your prospective clients the evidence of your own secure environment.
What Am I Doing Wrong?
Many IT service providers claim to provide security, yet few truly practice it in-house. We’ve all done this at some point, or are still doing it in at least one category or another of our managed services. However, there are two categories where I see this happen a lot:
My favorite example of this is firewalls. You offer it as a service and you have one or two vendor products in your stack to choose from, but internally you use neither or the cast-off from a client needing to upgrade.
2. Remote Monitoring and Management (RMM)
The second most common example is RMM. You install the agent on all of your client endpoints, but internally you don’t deploy it at all. While I realize that this is client-facing and not everything we offer our clients necessarily makes sense to adopt internally, when it comes to security, the foundational pieces that we offer our clients should be reflective of what we are doing internally. If we are their outsourced IT department, then we must ask ourselves, “who is our internal IT department?” If you aren’t planning to hire a third-party to do your IT, you should assign someone in your organization to be responsible for implementing and maintaining it.
How Can I Fix This?
Now, let’s talk a bit about the core security stack offerings that an IT provider should offer their clients AND adopt internally. There are three major areas that I think will make up your foundational security offering.
1. Servers, Workstations and Laptops
You can offer a bundled package to secure these devices that should include the following: antivirus, anti-malware, OS patching, third-party application patching, and email security. Then, there are some less tangible items that should be included, such as OS hardening, access control (no local admin rights), physical access control, and more.
2. Network Devices
Network devices can include items like firewalls, switches, routers, access points, etc. These will likely be some sort of bundled package where you include the patching and maintenance of the firmware and configurations. You can take this one step further by also monitoring and maintaining these devices, as well as offering or including this in a unified threat management offering.
3. IT Governance
This can get more complicated to define as the first two, but it is still extremely important. The policy creation and the procedures and execution within a client’s IT environment can get tricky because it requires working with the client. What the policies look like and how they are defined is critical when it comes time to change password polices or restrict user access from specific directories.
By Lily Teplow
By Brian Downey
By Dave LeClair