Securing third-party access to your corporate network
-
@Dashrender said:
If not it's possible that your usernames and passwords are walking out the door with those leaving employees.
This is probably my biggest concern because a few years ago I was indirectly involved in a case where a disgruntled MSP's ex-employee logged onto a client's network and caused some damage. That ended up with the ex-employee going to prison. Not a nice situation.
At the moment, I can't protect against that happening to me.
For a while I disabled the AD accounts of our third-parties and required them to contact me when they needed access. I then enabled their account. When they were done I disabled their accounts again. This worked ok, but I couldn't do this when I was on holiday - which is more often than not the time when they need access. So I abandoned that policy.
-
@Carnival-Boy said:
@Dashrender said:
If not it's possible that your usernames and passwords are walking out the door with those leaving employees.
This is probably my biggest concern because a few years ago I was indirectly involved in a case where a disgruntled MSP's ex-employee logged onto a client's network and caused some damage. That ended up with the ex-employee going to prison. Not a nice situation.
At the moment, I can't protect against that happening to me.
For a while I disabled the AD accounts of our third-parties and required them to contact me when they needed access. I then enabled their account. When they were done I disabled their accounts again. This worked ok, but I couldn't do this when I was on holiday - which is more often than not the time when they need access. So I abandoned that policy.
Why not just open them while you are on holiday, then close them down again when not?
-
Yes, I did that for a while. It doesn't cover me when I'm off sick, or when I simply forget to enable them.
A powershell script and a scheduled task would help me here though.
-
I like your style.
When I have needed to allow third party access in the past, it was via AD authentication on a Citrix portal with an RDP "app" straight to the server with the vendors software on it. They had local admin rights on the server. -
@nadnerB said:
I like your style.
When I have needed to allow third party access in the past, it was via AD authentication on a Citrix portal with an RDP "app" straight to the server with the vendors software on it. They had local admin rights on the server.That is a good idea... hadn't thought of doing it that way before.
-
We do much of the same, but normally issue user accounts, not company accounts, and we never know what the password is so that if we need to accuse someone of something we have as assumption that their were responsible for the access. As long as we know the passwords, we are responsible for their actions too, which we don't want.
-
I was setting up a few external access accounts this week. Other than using UIDs in a different range we treat them basically like any staff or contractor. They get access via our normal methods (Jump station in this case) and access only to what they need from there. We know when they log on or off, what they access, etc.
-
@Carnival-Boy said:
@Dashrender said:
If not it's possible that your usernames and passwords are walking out the door with those leaving employees.
This is probably my biggest concern because a few years ago I was indirectly involved in a case where a disgruntled MSP's ex-employee logged onto a client's network and caused some damage. That ended up with the ex-employee going to prison. Not a nice situation.
At the moment, I can't protect against that happening to me.
For a while I disabled the AD accounts of our third-parties and required them to contact me when they needed access. I then enabled their account. When they were done I disabled their accounts again. This worked ok, but I couldn't do this when I was on holiday - which is more often than not the time when they need access. So I abandoned that policy.
With LMI, for example, accounts are free. Why use company accounts there when individual is more secure? Then you have accountability and the MSP and you have the ability to granularly cut off people when they quit or are fired or even if they just change job role and no longer need access?
I assume the AD licenses for the users is too expensive and that's why you are using a single CAL for multiple users rather than separate?
-
@Carnival-Boy said:
LogMeIn supports two-factor authentication. It doesn't work where a third-party company has one user account for multiple support staff. I could get around that by setting up separate accounts for each and every support staff, but that means more AD accounts and more LMI accounts to manage.
Security takes overheard, unfortunately.
-
@scottalanmiller said:
I assume the AD licenses for the users is too expensive and that's why you are using a single CAL for multiple users rather than separate?
Disabled accounts don't need CALs so you could just enable the one for the person that will be doing the work that time and save some on cals.
-
@thecreativeone91 said:
Disabled accounts don't need CALs so you could just enable the one for the person that will be doing the work that time and save some on cals.
True, although that makes for a huge pain if you need regular, semi-regular or access during unpredictable times.
-
This is one of those really big, but never mentioned, benefits to fully open source systems. Working in a primarily UNIX environment, we have no per user costs. Adding users doesn't require compromises based on cost. This may sound trivial or petty, but at the end of the day, many of these concerns are around money. On a Linux system you could add each user for free, audit each one individually and enable two factor authentication for free because it is per user. Easier, safer, more effective.... for free.
These little things add up to big benefits when they are all taken together. This one is minor enough that no one ever mentions it. But you run into these constantly.
-
Are LMI accounts still free? Regardless, money isn't an issue, either for LMI or AD. It's convenience mainly. Partly mine, partly the third-party. I don't actually know the names of some of the people who connect to our servers. Often times I'll just know them as "Bob from the Helpdesk", and I might not even find that out until after they have closed the call. I'm also guessing that their systems for storing client credentials might not work well with individual accounts.
-
@Carnival-Boy said:
Are LMI accounts still free? Regardless, money isn't an issue, either for LMI or AD. It's convenience mainly. Partly mine, partly the third-party. I don't actually know the names of some of the people who connect to our servers. Often times I'll just know them as "Bob from the Helpdesk", and I might not even find that out until after they have closed the call. I'm also guessing that their systems for storing client credentials might not work well with individual accounts.
You don't know their names? Anyone I've ever had allowed to remote in has to had to have paper work on file and we did background checks on them ourselves before they were allowed in ours systems. When it comes to any issues that may occur this information is really needed.
-
-
@Carnival-Boy said:
I'm also guessing that their systems for storing client credentials might not work well with individual accounts.
That's potentially a problem. Although each person can store there own in that case, no need for a centralized system.
-
@scottalanmiller said:
@Carnival-Boy said:
I'm also guessing that their systems for storing client credentials might not work well with individual accounts.
That's potentially a problem. Although each person can store there own in that case, no need for a centralized system.
They can always use keepass or lastpass etc.
-
@thecreativeone91 said:
You don't know their names? Anyone I've ever had allowed to remote in has to had to have paper work on file and we did background checks on them ourselves before they were allowed in ours systems. When it comes to any issues that may occur this information is really needed.
When you are dealing with helpdesk outsourcing that can be tough as you are dealing with a pool of people, not a named engineer.
-
@scottalanmiller said:
@thecreativeone91 said:
You don't know their names? Anyone I've ever had allowed to remote in has to had to have paper work on file and we did background checks on them ourselves before they were allowed in ours systems. When it comes to any issues that may occur this information is really needed.
When you are dealing with helpdesk outsourcing that can be tough as you are dealing with a pool of people, not a named engineer.
I've always done if for the people that were on vendor support contracts. Not a big deal just meant every time there was a new employee there was a day or two delay til they could do anything with their software on our network. Much of it was required by regulations anyway.
