ConfigMgr/SCCM Operating System Deployment (OSD) is a huge topic! Because is so complex there is a lots to consider for OSD especially in environments where security is extra important. Things to consider:
Restrict access to the ConfigMgr Console and Media. Make sure that only those users that should have access to the ConfigMgr Console and Media have access. If someone were to have gain unauthorized access to your environment they could maybe deploy Task Sequences to your computers and resulting in accident data loss, system outages and discovering sensitive information like account credentials and volume licensing keys used by ConfigMgr/SCCM for OSD tasks.
Use built-in ConfigMgr Security Roles! such as the Operating System Deployment Manager and if necessary custom security roles to ensure only those OSD users have access and they can only deploy to certain collections.
The last thing we want is people who shouldn’t access to OSD causing problems on purpose or because they have features they don’t understand and they end up deploying to a Collection like All Systems or others that are big deal if targeted wrong.
Be careful with use of collection variables! Administrators could maybe read sensitive information they might be in there.
State Migration Points
There’s no way to limit amount of data a machine stores on a state migration point (SMP). So is possible for an attacker’s machine to take all disk space on the SMP, which would cause a denial of service…
Block the Client Certificate if compromised
If you discover the client certificate has been compromised (is required to deploy a OS) then if the certificate is a PKI certificate revoke it. Also you block it in the ConfigMgr. Not blocking might let attacker be able to impersonate ConfigMgr Client and have the capability to download Policies which can contain sensitive information.
Don’t enable Command Support on your production Boot Images
Enabling Command Support you can press F8 to start Command Prompt if a machine build fails so you perform troubleshooting and looking at the smsts.log. Obviously a security risk… attacker potentially has access to your network and access to variables in the Task Sequence environment maybe could have sensitive data.
Protect the Client Authentication Certificate during its capture
If attacker could get the Client Authentication Certificate it allow them to impersonate a valid Client on your network. This happens because they would have access to the Private Key in the certificate.
Do not grant the Network Access Account (NAA) excessive rights
The NAA makes you have just the Access this computer from the network right on any Distribution Points or other servers that hold package content the machine needs to access.
Do not re-use the account configured as the NAA
Ideally, the NAA only be used by Client computers when they cannot use local computer account to access content on DPs.
Do not configure the same account used for the NAA for these:
- Capture Operating System Image Account.
- Task Sequence Editor Domain Joining Account.
- Task Sequence Run As Account
Configure a unique account for those instead!