For large systems like ConfigMgr 2012 there are a lot settings needed in order to get it running. Sometimes you miss a setting or two, or you forget to properly set the right access for an account.
From a security point-of-view there is a lot that can go wrong.
ConfigMgr requires a lot of security rights on client computers, on active directory, and servers ( if you use it for servers ) And if someone manages to get full access to the console well.. then you’re screwed.
Even if you managed to lock down your environment as tight as uncle scrooge’s vault, that won’t mean a thing if you didn’t setup the site for encrypted traffic (of course there is a lot of hassle for someone to make some damage to your environment , but it can be done ) ConfigMgr 2012 leverages PKI for encryption, authentication and proof-of-identity between clients and site servers (Check my previous post on setting up PKI for SCCM 2012) But there are also some other options that we will go trough in this post which can heighten your security level in ConfigMgr.
In order to configure ConfigMgr for PKI, you have to change a site property, configure Site system settings for HTTPS only.
In order to deploy certificates to clients you can use the following deployment types.
* Use the /UsePKICert parameter with ccmsetup (This is most used for clients that connect from the internet) and remember you must also specify /:mp (With FQDN )
If a certificate is not found, it will fall back to http with a self-signed certificate.
* Deploying autoenrollement of certificates in AD. (Best for intranet clients)
* Using client push (Best for intranet clients)
NOTE: Because the location of the CRL is added to a certificate when it is issued by a CA, ensure that you plan for the CRL before you deploy any PKI certificates that Configuration Manager will use.
NOTE: When you issue client PKI certificates from the same CA hierarchy that issues the server certificates that you use for management points, you do not have to specify this root CA certificate. However, if you use multiple CA hierarchies and you are not sure whether they trust each other, import the root CA for the clients’ CA hierarchy.
If you are unable to use PKI. you can configure use of signing and encryption using 3DES and SHA-256.
-
In the Configuration Manager console, click Administration.
-
In the Administration workspace, expand Site Configuration, click Sites, and then click the primary site to configure.
-
On the Home tab, in the Properties group, click Properties, and then click the Signing and Encryption tab.
-
Configure the signing and encryption options that you want, and then click OK.
Remember to check that all your clients supports SHA-256, older computers with old version of XP or Server 2003 might have some issues with this.
Remember this options of signing, protect the data from tampering but it does not encrypt the data.
And the option of encryption, encrypts the inventory data and state messages that clients send to management points in the site. But remember the additional CPU usage that will be required on clients and the management point to perform the encryption and decryption.
If you manage to setup SCCM with PKI Good! but there are a lot of other factors that you need to check as well.
* Keep your systems up to date.
Patching, patching & patching. Always remember to have the latest security updates installed. We saw from a little while ago how short amount of time It took before an exploit was available for the security hole in RDP.
* Site-to-site server
Although Configuration Manager does secure communication between the site server and the computer that runs SQL Server, Configuration Manager does not secure communication between site system roles and SQL Server, therefore you should use IPsec to secure communications between these servers. If you do not setup secure communication here, they can be the victim of man-in-the-middle attacks.
* Site server to package source server
You should also use IPsec here if possible, if not use SMB signing to ensure that the files are not tampered with before clients download and run them.
Of course in order to view communication between servers a user would have to be on the same network as the servers are. But always remember to use custom VLAN and ACLs where possible.
* Use non-default port numbers
A lot of attackers go after well-known ports. For instance 1433 is a known SQL server port, and HTTP & HTTPS use 80 & 443. If you want to use custom port numbers, remember to use them consistently across all sites in the hierarchy.
* Isolate site system roles
By having a server for each role you reduce the attack surface against vulnerabilities on one site system can be used against a different site system. The fallback status point on the other hand should never be collated with other roles since this site system role accepts unauthenticated data from clients.
* Restrict user access.
Use RBAC, and delegate only permissions as needed.
* Job rotation
If someone has full admin access to ConfigMgr (of for that matter the CAS) remember to have a job rotation schedule, the biggest threat for a company is always a disgruntled employee that has full access from the inside.
* PowerShell execution policy set to Bypass.
This setting allows clients to run unsigned PowerShell scripts, which cloud allow for instance malware to run on client computers.
* Deploying applications to “All systems”
If you have a licensed application like an Adobe application distributed to all systems, would mean that if a rogue client installs an agent, get its client information from AD would get access to that application.
* Desktop Viewers option
Make sure that you create a custom policy for each computer group, so you don’t have a help desk user that can remote view every computer (and user for that matter) in your site.
* Client Push Account
Create your own service account for this user, and create a policy to deny the account the right to log on locally, since this account needs to be a member of the local admin group on each machine.
If someone gets access to this account, then that lucky guy would have access to every client in your site. Of course you don’t need to use the client push install, and just do it by group policy.
* Require a password to PXE boot
If you enable this option, this adds an extra level of security to your site. Since now you reduce the risk of a rouge computer joining your site.
Also remember not to include business applications that contain sensitive data in a task sequence, since we don’t want the rogue computer getting access to get data.
* Restrict whether users can install software interactively by using the Installation permissions client setting.
If you have this settings enabled for all users, and you have this setting enabled for servers. Users that have access to that server that install an application on a terminal server.
* Best practice from Microsoft.
Microsoft has a free tool available named Security Configuration Wizard (SCW) which allows you to create a security policy which you can apply to all your servers.
It also has a template available for ConfigMgr 2012 which you can download here –> http://www.microsoft.com/en-us/download/details.aspx?id=29265
These are just some pointers of what you have to think about when deploying ConfigMgr 2012. There are a lot of other factors as well, which depends on what features you think about deploying in your site.
I recommend you check the TechNet documentation Microsoft has regarding Security in ConfigMgr http://technet.microsoft.com/en-us/library/hh508779.aspx