We have few hundred tech.support engineers, technicians who offer remote support to laptop/desktop users either via phone or timbuktu to the endpoint and troubleshoot any app/software problems. Few of those, actually do field support, i.e., going to enduser's location and physically get the laptop from them and troubleshoot any OS/App related problems.
When I create an encryption policy, I was asked to add "all the tech.support" people. I do not see any reason, why to have so many tech.support users with their default passwords residing in every endpoint. I thought it would make sense only to add those who are going to break-fix any OS related issues by physically having access to these encrypted endpoints. Any app/ software related issues/ even user recovery, machine recovery can be still handled by tech. support via the Web HelpDesk access.
Is this a right approach? Pls. let me know your thoughts.
With several hundred field support staff, who often touch encrypted machines, I opted for a shared account for them. It has no rights except for Boot the machine, and we don't use single sign-on. The shared account is NOT an AD account.
You should also use that account with strong, long-expire password, disable password change. Distribute password to your techs as you change it.
remember, shared accounts are forbidden under most regulations, PCI, CMA207, 800-111 etc. You need to be able to distinguish between users.
Under CMA207, absolutely - it's a hard requirement. The others, no, encryption is not mentioned so you are free not to use it, well, as long as you don't mind publicly admitting to every lost device to everyone who's information potentially could have been stored on it.
Encryption and proper authentication is one of the mitigating technologies you can use to cover against this kind of embarrassing situation. Most regulations don't consider data lost as long as it was encrypted, and the key was not lost with the data, and you can prove all this.
While I agree with the concept of "no shared accounts", if you don't have SSO turned on, and you're using an unlinked EEPC ID, what use is a shared EEPC account?
Yes, it means that a group of users have the ability to "anonymously" boot up a windows client. If they could obtain the code of the day, they could also mount the drive and access data that way, I suppose. It seems to me that either way, the call as to "compliant" or not still has quite a bit of grey in it.
As SafebootMEE suggested, my initial effort has been to get a seggregated list of support staff that 1) have physical access to the machine and do imaging/recovery etc 2) troubleshoot day-to-day problems like Network issues, AV, email issues etc.
I have not yet been so successful with this approach, as there are many overlaps. Am still trying...
Can you separate your support staff where your WinTech/SafeTech technicians (or field staff) is assigned to the machines only? The support staff that only needs to reset/recover a EEPC user account password via Web Recovery does not need to be assigned to machines. It sounds like all your support staff needs both functions though.
You could possibly assign only support staff managers and assistants that could export the SDB file (machine configuration) from the database. They can give this file to their staff for Wintech/SafeTech recoveries (Authenticate to Database after Authorization). This will eliminate many of the EEPC support user accounts from the machine. I guess you could add the staff managers and assistants to the machine only if you need to Authenticate to SBFS just in case the SDB file does not work.