Securing third-party access to your corporate network
-
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.
