Most people don’t think of cyberattackers as guys and gals in secret hideouts trying to infiltrate companies’ Windows 10 operating system deployment (OSD). A good Microsoft System Center Configuration Manger (SCCM) administrator does though. An attacker who compromises Windows 10 deployment process can do all manner of evil.
Attackers look everywhere for undiscovered security vulnerabilities, even in relatively obscure and esoteric corners of IT such as Windows 10 OSD with SCCM. Cyberattackers usually start by trying the things that administrators are most likely to overlook, so your job is simple: overlook nothing! Okay, that’s not simple at all. You can, however, apply known best practices, including the following:
Secure the Console and Media
The people who have access to the SCCM console should be 100% vetted and authorized, and they should have a specific need to use it. This should be reviewed periodically as well since somebody who needed access last year many not require it this year. My days in IT are long behind me, but I know from experience how many admins—if left unchecked—will be loose about security. “Oh, that’s Tom, he’s my buddy, we worked together at xyz company. He can have access to everything.”
No no no no, no!
If someone has access to the ConfigMgr console they can do almost anything they want to almost any computer company-wide. They can walk away with sensitive information, hold the company for ransom, be destructive, etc.
The same goes for OSD media. If someone has the ability to install a new Windows 10 computer on your domain, they have a domain-joined computer, and a foothold into all kinds of high-stakes mischief.
Use Caution with Custom Security Roles
As much as possible, stick to out-of-the-box security roles such as the Operating System Deployment Manager. Of course, when it’s necessary, you can use custom security roles to limit users involved with OSD to the minimum required permissions, and only allow them access to certain collections. Be careful though. You definitely don’t want somebody to get access to OSD without authorization. Whether by accident, or with bad intentions, they could do something like deploy to the All Systems collection or other non-designated targets—wiping out those machines entirely.
Be Careful with Collection Variables
Collection variables are easy to overlook as a possible source of an information leak. However, local administrators can potentially read them along with any sensitive information they may contain.
Be Aware of SMP Disk Overload Vulnerability
SCCM provides no way to limit the amount number and size of files a machine stores on a state migration point (SMP). That means an attacker could fill the disk of an SMP system to capacity. The result? Denial of service. Obscure, but you should be aware of it.
Kill Exposed Client Certificates
If a PKI client certificate has been compromised, or even if you reasonably suspect it has been, you need to revoke it and replace it in your OSD process. Also, you ought to block it in the SCCM console. To do that, in the Administration workspace, navigate to Security\Certificates. Then right-click on the certificate and select Block.
If you don’t do this, an attacker who has the certificate can impersonate a valid SCCM client, and that’s bad. The can download policies that have sensitive information, and much worse.
Disable Command Support on Boot Images
For testing your OSD builds, of course you need to enable command support. You and your team need to be able to press F8 to start a command prompt when builds fail, so you can troubleshoot by doing things like looking at the smsts.log file. However, in production this presents a security risk! An attacker could press F8 to get a command prompt, and then access your network as well as sensitive variables in the Task Sequence.
Guard the Client Authentication Certificate During Capture
This almost goes without saying, but client authentication certificates must be properly secured. Your company is vulnerable if an attacker gets hold of your client authentication certificate. They could access the private key and then impersonate a valid client on your network. As I’ve noted elsewhere in this blog, that’s “bad.”
Limit the NAA Permissions
No account should have more permissions than it needs, that’s a very basic best practice. However, the network access account (NAA) bears calling out because administrators may not be aware how little access it really needs. The only permission the NAA requires is Access this computer from the network, which it needs on any DPs or other servers containing the package the system needs to access.
Never Reuse the the NAA Account
There is one scenario and one scenario only where the NAA should be used: when client systems cannot use their local computer account to access content on DPs or other servers.
Although it might be tempting, do not configure the same account used for the NAA for purposes including but not limited to: capture operating system image account, task sequence editor domain joining account, and task sequence run as account. Use unique accounts for all those. It’s not always super convenient, but it’s more secure.
IT Security is Never Done
As you are very well aware, these tips are just a tiny piece of a ginormous security puzzle. The more you know, the more you can do to keep your company safe. Adaptiva offers additional technical resources to help SCCM administrators secure their environment, as well as deploy best practices for Windows 10 OSD.
