CHAPTER 23
Security and Delegation in Configuration Manager

The rising number of high-profile data breaches in recent years has increased awareness of the importance of security in information technology (IT). This chapter discusses security issues to consider when implementing System Center Configuration Manager (ConfigMgr). It includes a detailed discussion of how to safeguard Configuration Manager workflows and protect ConfigMgr from compromise. The chapter begins with a discussion of how to address security requirements during ConfigMgr design and planning. Configuration Manager is a powerful platform you can use to implement core security controls. This chapter includes an overview of those controls. It presents ConfigMgr role-based administration (RBA), which allows you to assign access to IT support personnel on a least-privilege basis. The chapter also discusses how to prevent unauthorized administrative access to Configuration Manager and takes a deep dive into options for hardening your ConfigMgr environment against malicious attack.

What am I trying to protect?

From what do I need to protect it?

How can I implement the required protection?

Much of this chapter focuses on the last question. This section looks at the first two, discussing things to consider as you think about what you are protecting and from what you are protecting it.

You need to protect the data stored in the ConfigMgr site database. The site database contains extensive information about your environment. An attacker could use this information to learn about your systems, networks, and applications, as well as your organization’s security posture. Many ConfigMgr features collect and store user information. Recently there has been increased emphasis on securing personally identifiable information (PII). PII is any data about an individual that can be used to establish his or her personal identity. PII is highly regulated in many jurisdictions, most notably in the European Union (EU); be aware of those privacy regulations. Engage with the persons responsible for privacy in your organization to learn what requirements are in place for personal user data. You may need to limit the data you collect or implement additional controls to protect user data.

Protect your site systems and the services they provide. A ConfigMgr service failure could affect normal operations, user productivity, and security; users could lose access to applications, and administrators could be unable to patch systems efficiently.

In addition to protecting ConfigMgr itself, plan your solution with a view toward protecting your larger environment. The “ConfigMgr Security Solutions” section, later in this chapter, discusses how to use ConfigMgr to protect systems and data. Realize that a ConfigMgr security breach or an administrator’s mistake could compromise the security of managed systems.

Most large organizations have teams dedicated to security, regulatory compliance, and privacy. Involve these teams in the design and planning phases of your deployment, make them aware of the security and compliance solutions ConfigMgr offers, and help them recognize the criticality of the ConfigMgr infrastructure and the threats to that infrastructure. Understand your organization’s security policies and the business drivers for security as they relate to your deployment, as this will help focus your efforts on the highest-priority security and compliance objectives.

Working with the security team can help avoid costly delays and poorly planned security controls. During design and planning, work with your security group to identify threats to each ConfigMgr service you plan to provide and select risk management strategies to deal with those threats. Most threat actors have a financial motivation. In the past, payment card and banking information was commonly targeted for financially motivated cyber-crime. Recent trends include using extortion and increased targeting of intellectual property and health information. In addition to financially motivated cyber-criminals, significant threat actors include disgruntled employees and others with personal animosity toward an organization, political “hacktivists” seeking to promote some cause, and nation-states seeking economic or military advantage. Following are some important changes to the threat landscape since the publication of System Center 2012 Configuration Manager (SCCM) Unleashed (Sams Publishing, 2013):

Emergence of Ransomware as a Primary Security Concern: Ransomware typically encrypts data using keys known only to the attackers, who demand bitcoin payment for the keys to decrypt that data. Ransomware attacks against consumers have become very common. A recent development has been ransomware attacks on enterprise servers. Some attackers also threaten to expose sensitive data or to exfiltrate and monetize the data in other ways.

PowerShell as a Weapon: Systems administrators understand that PowerShell is a highly capable and flexible tool for managing all resources in the Windows environment. Attackers are aware of this, and toolkits such as PowerSploit and PowerShell Empire have made PowerShell the weapon of choice to attack Windows systems.

Digitally Signed Malware: Digital signatures provide a foundation of trust that files come from a trusted publisher and have not been tampered with. Attackers gain access to code-signing certificates by various means, such as by stealing them from developer workstations or purchasing them from legitimate certificate authorities (CAs).

The number of known digitally signed malicious binaries as of the 4th quarter of 2017 is well over 20 million. Code signing as a service is now available in the underground economy.

Rise in Cryptographic Attacks: While there were earlier exploits based on flaws in cryptographic technology, the number of exploits directed against the cryptographic methods at the core of Internet security has risen dramatically since the disclosure of the Heartbleed vulnerability in April 2014.

Slash and Burn: Traditionally, attackers attempted to cover their tracks using techniques such as deleting log files. More recently, attackers have tried to do as much damage as possible after achieving their initial objectives.

Many companies and government agencies have become victims of a class of attacks known as advanced persistent threats (APTs) from sophisticated, well-financed hacker groups, often backed by nation-states. Targets include virtually every type of business, with a general objective of stealing valuable intellectual property and business secrets for military or economic advantage. APTs often take advantage of user mistakes, such as clicking links or opening attachments sent though social media or phishing emails. Once in the door, they spread laterally from machine to machine, seeking to find high-value targets. These attackers often attempt to compromise domain controllers as a control point to reach systems across the enterprise. As companies use increasing vigilance to secure domain controllers, management systems become the next logical point of attack. Defending against APT attacks requires different approaches from defending against traditional malware and hackers. Make your security team aware that ConfigMgr site systems are potential targets for these attacks.

The next section introduces security concepts and terminology used throughout the chapter. If already familiar with concepts such as the CIA (confidentiality, integrity, availability) triad, risk management, and layered defense, you may choose to skim this section briefly or skip it altogether.

Confidentiality: Keeping secret information you are responsible for secret.

Integrity: Protecting information and systems from unauthorized modification.

Availability: Keeping systems and services running.

Accountability: Maintaining effective audit logs to track security-sensitive operations on a per-user basis. The completeness and integrity of audit logs is essential in demonstrating regulatory compliance. Audit logs are also an integral part of the incident response and forensic investigation processes.

A guiding principle in security is the concept of risk management. No organization can keep its assets completely secure. Organizations must therefore implement strategies to prioritize and deal with risks. Following are some essential terms used in risk management:

A vulnerability is a weakness that could result in compromise of the confidentiality, integrity, or availability of information or systems.

A threat is a potential danger to information systems. Threats include malicious and inadvertent actions. Good security helps protect against honest mistakes by users and deliberate breaches by hackers and malware creators.

A risk is the likelihood of a threat being realized and the associated business impact.

Effective risk management depends on understanding the risks to your systems and data and making appropriate business decisions on how to deal with each set of risks. Following are some approaches for dealing with risk:

Risk Avoidance: You might decide that the business value of undertaking a technology initiative does not justify the risk. As an example, you might determine that the value to your company of Internet-based client management (IBCM) is not sufficient to justify exposing your ConfigMgr infrastructure to the Internet.

Risk Mitigation: You might decide to implement countermeasures to address potential threats to reduce risk. Much of the material in this chapter relates to risk mitigation strategies.

Risk Acceptance: You might decide to accept certain risks if the business value of the activity and cost of implementing additional controls to mitigate risk outweigh the potential losses posed by the risk. As an example, say that you determine that using a file server running an older version of Windows as a distribution point (DP) provides sufficient business value to justify the risk, while the cost of providing a more secure system is not justified by the risk mitigation it would provide.

Leading security organizations, such as the following, publish lists of critical controls to help you prioritize your security efforts:

Center for Internet Security (CIS): Leading industry and government stakeholders in information security support this not-for-profit organization. CIS publishes extensive guidance on cyber-defense, including the CIS Controls for Effective Cyber Defense. See https://www.cisecurity.org.

Information Assurance Directorate (IAD): Part of the National Security Agency (NSA), IAD shares its expertise with other government agencies, industry, academia, and the public. Its valuable publications include IAD’s Top 10 Information Assurance Mitigation Strategies. See https://www.iad.gov/iad. Note that the iad.gov website uses TLS 1.2, supported by a Department of Defense (DoD) PKI certificate. Website users will need to have the current DoD Root and Intermediate CAs loaded into their browsers to avoid receiving untrusted website notifications.

Australian Signals Directorate (ASD): ASD is the Australian authority for information security. It provides leading cybersecurity research, including Top 4 Strategies to Mitigate Targeted Cyber Intrusions. The Australian government’s information security manual is at https://www.asd.gov.au/infosec/ism/index.htm.

Microsoft has worked with CIS and IAD to develop best practices for Windows operating systems, Active Directory (AD), and other Microsoft products. Microsoft provides a free tool, Microsoft Security Compliance Manager (https://www.microsoft.com/download/details.aspx?id=16776), for use in comparing your systems against baseline Microsoft recommendations. You can customize the baselines to the needs of your organization and export them to use in ConfigMgr compliance settings, AD group policy, and other security tools.

Security experts generally advocate implementing controls throughout your environment— addressing threats to the network perimeter, internal network, system hardware, OS, applications, human resources, and so on. This method, known as the layered security model or defense in depth, recognizes that while any single control can fail, it is difficult for an attacker to defeat controls at every layer of the computing stack.

Traditional risk mitigation strategies focused on preventing known threats. Security experts now teach that no organization should expect to prevent every attempt to gain unauthorized access to their networks and systems. It is therefore important to adopt a “prevent, detect, respond” model, in which you prevent as many intrusions as you can but are prepared to detect and respond to compromise when it occurs. The first indication of compromise is often unexpected system behavior, such as crashes or degraded performance. Make sure systems administrators consider the possibility of system compromise when troubleshooting stability and performance issues. If they are unable to determine the root cause, involve the incident response team to check systems for indicators of compromise (IOCs).

Active Directory: Although ConfigMgr sites and hierarchies can span more than one AD forest, such an arrangement might compromise your AD security design. The forest is a security boundary in AD. Weigh the importance of maintaining the strongest possible security boundary between forests against the possible administrative advantages of a single ConfigMgr hierarchy to manage multiple forests.

ConfigMgr Site Selection: The fewer sites you have, the easier it is to maintain site security. Additional sites increase the number of site servers, site databases, and intersite communications links to administer and secure. However, in some cases you might require additional sites. Chapter 4, “Architecture Design Planning,” discusses reasons to deploy additional sites.

Site System Role Assignment: You should move client-facing roles, such as the management point (MP) and DP, off the site server. The risk of a network attack is greatly reduced if you restrict client access to only server roles that require it. The site server and site database server are the most important roles in your site; opening network access required for clients to establish a connection to these systems is a risk you should consider eliminating.

Separating server roles generally reduces the requirement for services and open network ports on each system, which reduces the system attack surface. Weigh this advantage against the effort required to support and secure additional site systems. As installing Internet Information Services (IIS) on a server greatly increases its attack surface, you should generally separate server roles requiring IIS from those that do not. You also should separate the Fallback Status Point (FSP) server role from all other system roles. The FSP must accept unauthenticated client data, presenting a risk to which you would want to avoid exposing other site roles.

Perhaps the most important security consideration for assigning system roles is to avoid using systems hosting other applications as site systems, especially those with applications based on IIS or SQL Server. Poorly written or vulnerable web and database applications are favorite targets of attackers and could be exploited to gain control of a site system. Placing a DP on a server that provides file and print services presents a much lower risk.

Server Placement: Deploy site systems in locations that are as secure as possible in terms of physical and network access. An attacker with physical access to a site system could compromise your system by installing a hardware device such as a keystroke logger or booting the system to an insecure operating system (OS). Restrict network traffic to that which is necessary for ConfigMgr operations and basic server functions. Using a host-based firewall or taking advantage of the microsegmentation capabilities available through network virtualization provides the most granular control of network traffic. If possible, place the site server and site database server in a secure network zone, isolated from systems with lower security requirements, such as user workstations.

Managing Clients on the Internet: If you plan to manage clients on the Internet, consider using a cloud management gateway for managing Internet-based clients. Doing so eliminates some security challenges associated with Internet-based client management, especially the need to expose your on-premise infrastructure to the Internet.

Administrative Workstations: If administrators must reach site systems from less-secure network zones, have them use a virtual private network (VPN) to connect to systems in the higher-security zone. Consider providing an extra measure of security by using a “jump box.” In this scenario, administrators establish a Remote Desktop Protocol (RDP) session to the jump box to run the console and other tools rather than connect directly to site systems.

Grant the least privilege necessary for each administrator to carry out his or her responsibilities. Assigning overly broad privileges to users or administrators greatly increases the chances of compromising systems or data. Review permissions in the built-in roles; consider customizing the roles by removing permissions not required in your administrative model.

Employ separation of duties wherever possible to make it more difficult to abuse administrative access. When a person carries out improper activity on his or her own, the level of effort and risk of detection are much lower than when the person colludes with others. For example, a user with the Application Administrator role could introduce unauthorized code into an application and then target specific systems for attack. Assigning the Application Author role and the Application Deployment Manager role to separate individuals can mitigate this risk. The extent to which you choose to separate responsibilities for related tasks depends on your security requirements and available resources.

The “About Role-Based Administration in ConfigMgr” section, later in this chapter, explains how to use RBA to assign ConfigMgr administrative permissions.

Several ConfigMgr features can provide significant risk mitigation for your managed systems. The next section reviews these features.

Patch Management: A large number of exploits take advantage of unpatched systems that remain vulnerable even after a fix is available from the software vendor. ConfigMgr facilitates patch management for Microsoft operating systems and applications through its software updates feature set. Chapter 15, “Managing Software Updates,” discusses patch management.

Conditional Access: Keeping unpatched or otherwise inadequately protected devices and systems from accessing services such as SharePoint and email provides a strong line of defense against threats that might use these systems to compromise data. Chapter 18, “Conditional Access in Configuration Manager,” discusses conditional access.

Compliance Settings: Misconfigured systems are another major category of vulnerabilities. The ConfigMgr compliance settings feature supports enforcement of configuration standards and reporting on system compliance. Chapter 10, “Managing Compliance,” describes how to use ConfigMgr to enforce consistent, secure system configuration based on best practices and organizational standards.

Certificate Profiles: ConfigMgr can deploy and manage certificates profiles used for secure access to resources such as a VPN or wireless access point.

Endpoint Protection: ConfigMgr can provide centralized management of Windows Firewall policies and Microsoft Endpoint Protection antimalware policies. Endpoint protection also allows you to manage the Microsoft Endpoint Protection engine update and signature file distribution. Chapter 19, “Endpoint Protection,” discusses endpoint protection.

New ConfigMgr functionality includes integration with Windows 10 security features such as Device Health Attestation and Passport for Work. Device Health Attestation provides strong, hardware-enabled security to ensure the integrity of the OS and other core system components. ConfigMgr provides extensive reporting on Device Health Attestation status and allows you to use health status in compliance rules for conditional access. Passport for Work eliminates the need for password-based authentication across the network, as the user authenticates to the local device using Hello biometric authentication or a locally stored PIN. Digital certificates then provide access to network resources. ConfigMgr allows you to control passport policies in your organization.

Beyond these specific features, well-managed environments are inherently more secure than less-well-managed environments. Central management of day-to-day IT functions such as software installation, OS upgrades, and troubleshooting reduces the need for large numbers of privileged users and provides better auditing and control. Comprehensive inventory and reporting are essential to security planning. Much of this chapter focuses on potential misuse or compromise of the ConfigMgr infrastructure; the risks of not having effective configuration management are much greater.

The next section describes how to assign the appropriate ConfigMgr administrative access.

Execute arbitrary code on any ConfigMgr client system, in the context of the privileged system account or the logged-on user.

Collect and view any file from client systems.

Interact directly with client systems through remote tools.

Misuse of administrative rights can occur in three ways:

An authorized ConfigMgr administrator can deliberately abuse his or her privileges.

An attacker can gain access to the administrator’s account.

An administrator might make an honest mistake.

The ConfigMgr RBA security model is similar to that of other System Center components. Sets of related administrative tasks are grouped together to define roles. ConfigMgr administrators are assigned roles based on job function. The roles provide the minimum privilege required to carry out the user’s responsibilities. The next section shows how ConfigMgr administrators in the Odyssey domain provide the web server administrators with the minimum permissions necessary to manage the specific servers for which they are responsible.

1. In the ConfigMgr console, navigate to Administration -> Security -> Administrative Users -> Add User or Group.

2. Click Browse and select a user or group from the Select User, Computer, or Group dialog. As a best practice, assign roles to AD groups rather than to individual users. Figure 23.1 shows the Add User or Group dialog.

3. Click Add and select one or more roles from the Add Security Role dialog. Figure 23.2 shows this dialog with roles selected for web server administrators. (The following section, “Security Roles,” describes security roles.)

4. Optionally, restrict the account to assigned security scopes or collections. The “Using Security Scopes” section, later in this chapter, discusses these options.

To view the roles and their descriptions, navigate to Administration -> Security -> Security Roles. The Full Administrator role provides unrestricted access to all ConfigMgr operations. If your organization separates security administration from operational duties, you might assign the Security Administrator and Operations Administrator roles to separate users; however, you must have at least one user with the Full Administrator role. The “Auditing ConfigMgr Administrative Actions” section, later in this chapter, explains how auditors or security personnel can keep an eye on all administrative users, including full administrators.

1. Navigate to Administration -> Security -> Security Roles.

2. Right-click the role you want to customize and choose Copy.

3. On the Copy Security Role page, enter the name and an optional description for the new role. Figure 23.3 shows the Copy Security Role dialog for the Asset Manager role without access to manage mobile device enrollment profiles.

You can export a custom role and import it into a different hierarchy. For example, you might develop and test all custom roles in your lab environment and import them in production. After creating a custom role, you can edit its permission set and other properties on the role’s property sheet. Built-in roles and roles imported from other hierarchies are not editable.

Collections: To specify the set of devices and users an administrator can manage, assign specific device collections or user collections to the administrator. You can assign one or more collections to each user. By default, each administrative user is assigned the All Systems and All Users collections.

Security Scopes: To specify other sets of objects an administrator can manage, assign specific security scopes to the administrator. A security scope is essentially a container that contains one or more types of securable objects. You can assign one or more security scopes to each administrative user. By default, each administrative user is assigned the Default security scope.

Permissions on some types of objects apply to all type instances, and you cannot restrict these by collection membership or security scope.

You can associate objects of the following types with security scopes:

Antimalware settings

Application

Authorization lists

Boot image packages

Boundary groups

Client settings

Configuration items

Configuration policies

Device enrollment profiles

Device setting items

Device setting packages

Distribution point groups

Distribution point info

Driver packages

Firewall policies

Global conditions

Image packages

Metered product rules

Migration jobs

Operating system install packages

Packages

Queries

Sites

Software updates packages

Subscriptions

Task sequence packages

Virtual hard disk (VHD) packages

Virtual environments

There are two built-in security scopes: All and Default. Administrative users assigned the All security scope can administer all objects related to their role. Built-in instances and newly created instances of securable objects are assigned the Default security scope. Perform the following steps to create additional security scopes:

1. Navigate to Administration -> Security and right-click Security Scopes.

2. Choose Create Security Scope.

3. In the Create Security Scope dialog, enter the security scope name and an optional description and then click OK. Figure 23.4 shows the Create Security Scope dialog for the Web Server Resources scope.

After creating a new securable object, set its security scopes. Follow these steps:

1. Locate and right-click the object in the ConfigMgr console. Use the standard Ctrl and Shift options to multi-select objects for which you want to specify the same scopes.

2. Choose Set Security Scopes.

3. In the Set Security Scopes dialog, select one or more scopes to associate with the objects and then click OK. Figure 23.5 shows the Set Security Scopes dialog.

By default, all administrative users have permissions on the All Systems and All Users collections. You may choose to remove these default permissions. If you do, users can only see and manage resources in collections to which you explicitly grant access. This practice minimizes the chance a user could accidentally gain access to resources he or she does not need to see. Allowing access to All Systems and All Users collections simplifies administration by eliminating the requirement to grant access explicitly to individual collections. Note that when you create a collection, you can base the new collection on an existing collection. Users with access to the original collection inherit access to collections based on the original one.

1. Navigate to Administration -> Security -> Administrative Users.

2. Double-click the user or group you want to customize to open the Properties page.

3. On the Security Scopes tab, select Associate assigned security roles with specific security scopes and collections. Select the role you want to edit and click Edit to open the Edit Security Scope dialog. Figure 23.6 shows the Security Scopes tab for the OdysseyWeb Server Admins Security group with the Compliance Setting Manager role selected.

4. In the Edit Security Scope dialog, select the All Systems collection and the Default security scope and click Remove. Then click Add and choose Collection. Select Device Collections from the upper-left dropdown and check the box for the appropriate collection. Click OK. Click Add and choose Security Scope, select the appropriate scope, and click OK. Figure 23.7 shows the edited list of security scopes for the Web Server Admins group.

The Configuration Manager Toolkit, available at https://www.microsoft.com/download/details.aspx?id=50012, includes the Role Based Administration Modeling and Auditing Tool (RBAViewer.exe), which simplifies the customization and auditing of security roles. RBAViewer allows you to create a new role based on one or more existing security role(s) and provides a tree control for viewing and editing permissions for the newly created role. When your customization is complete, you can save the role as an eXtensible Markup Language (XML) file and import it using the ConfigMgr console. RBAViewer also provides a consolidated view of RBA objects. Figure 23.9 shows an RBA Administration Modeling and Auditing Tool view of the web server admins.

An attacker could alter ConfigMgr security through AD. ConfigMgr roles are assigned to AD users and groups. Anyone who gains the requisite AD privileges could add himself or herself to a group with access to ConfigMgr.

An attacker with access to modify the site database could alter ConfigMgr security by directly modifying the RBA objects in the site database.

An attacker could steal the credentials or hijack the session of a legitimate administrator.

Protecting against these risks requires effective security at the AD and database layers; it also depends on maintaining a strong auditing policy. The following sections address these issues.

Restrict rights to manage ConfigMgr administrative accounts and groups to a small group of senior administrators and remove any delegated rights to groups such as help desk personnel. Consider moving administrative accounts and groups to specific organizational units (OUs) to simplify security management.

Set auditing to record any changes to these user accounts and groups and monitor such changes.

Provide ongoing education for administrators on security best practices. Some of the highest-profile security breaches have targeted administrators using phishing or other social engineering methods. A hacker who tricks an administrator into clicking the wrong link or attaching the wrong device to a system has a good chance of compromising your network.

Pay extra attention to securing administrative workstations and other systems where the console is installed. The security practices discussed in the “Securing Site Systems” section, later in this chapter, apply to administrative workstations and to servers. It is especially important to disable password caching on administrative workstations and locate these systems in areas that are physically secure and not easily accessible for shoulder surfing. Windows 10 Credential Guard technology uses hardware-assisted virtualization to protect the Local Security Authority Subsystem Service (LSASS). Credential Guard and Passport are both able to take advantage of a hardware Trusted Platform Module (TPM) if available. The authors recommend that all administrator workstations run Windows 10, have hardware TPM (preferably version 2.0), and have the Credential Guard and Passport features configured though group policy.

This section described some specific AD security practices that are particularly relevant to ConfigMgr administrative access. Microsoft provides guidance on AD security best practices at https://technet.microsoft.com/library/dn487446.aspx.

JEA provides role-based administration for anything you can manage through PowerShell, including Windows, AD, and various applications. It allows you to provide users with access to specific administrative tasks on designated systems without adding them to the administrators group. JEA uses PowerShell Desired State Configuration (DSC) to enable centralized administration of task delegation. It does not work with traditional graphical user interface (GUI)-based administrative tools. If you require use of the GUI tools by administrators with limited, delegated permissions, consider third-party role-based access control products.

Microsoft provides guidance on security considerations for SQL Server at http://msdn.microsoft.com/library/ms144228.aspx. SQL Server Reporting Services (SSRS) implements its own role-based access control model. Learn about SSRS security in another book in this series, System Center Configuration Manager Reporting Unleashed (Sams Publishing, 2016).

ConfigMgr generates status messages of type Audit to provide an audit record of certain security-sensitive operations. The SMS provider generates an audit message when a user creates, modifies, or deletes a ConfigMgr object or changes the associated security scopes for an object. Remote control of client systems also generates audit messages. Audit messages for object modifications indicate the user making the change, the target object class and object ID, and details about when and how the change occurred. The specific attributes changed are not included.

Chapter 20, “Configuration Manager Queries,” describes how to run status message queries and create custom status message queries. Many of the built-in status message queries display audit messages. You can use these queries as is and as a basis for creating your own queries. Following are the built-in status message queries you can use to audit administrative activity:

All Audit Status Messages from a Specific Site

All Audit Status Messages for a Specific User

Boundaries Created, Modified, or Deleted

Client Component Configuration Changes

Collection Member Resources Manually Deleted

Collections Created, Modified, or Deleted

Deployments Created, Modified, or Deleted

Packages Created, Modified, or Deleted

Programs Created, Modified, or Deleted

Queries Created, Modified, or Deleted

Remote Control Activity Initiated at a Specific Site

Remote Control Activity Initiated by a Specific User

Remote Control Activity Initiated from a Specific System

Remote Control Activity Targeted at a Specific System

Security Roles/Scopes Created, Modified, or Deleted

Server Component Configuration Changes

Site Addresses Created, Modified, or Deleted

An important auditing consideration is the audit records retention period. You may be required to retain audit data for a specified time to meet regulatory requirements. Chapter 24, “Backup, Recovery, and Maintenance,” discusses audit message retention policy.

ConfigMgr provides several reports based on audit messages. Table 23.1 lists reports you can use to audit sensitive actions.

TABLE 23.1 Reports Displaying Audit Messages

Report Folder	Report Name	Description
Status Messages - Audit	All audit messages for a specific user	Displays a summary of all audit status messages for a single user. Audit messages describe actions taken in the ConfigMgr console that add, modify, or delete objects in ConfigMgr.
Status Messages - Audit	Remote Control - All computers remote controlled by a specific user	Displays a summary of status messages indicating remote control of client computers by a single specified user.
Status Messages - Audit	Remote Control - All remote control information	Displays a summary of status messages indicating remote control of client computers.
Administrative Security	Administration Activity Log	Shows the log of administrative changes made for administrative users, security roles, security scopes, and collections.

Many organizations use a security information and event management (SIEM) solution to aggregate and correlate data from various security information and event sources. SIEM solutions monitor activity in real time and allow rapid detection and response to suspicious activity. If you have such a system available, it is desirable to connect all audit data feeds to the SIEM solution. Most SIEM solutions have facilities to extract event data from database sources. The site database stores status messages in the StatusMessages and StatusMessageInsStrs tables. Audit messages can be distinguished by the condition [StatusMessages.Type] = 768.

It is important to log and audit sensitive actions at every layer of the infrastructure. In addition to the auditing described in this section, auditing of the following systems and services will help protect your ConfigMgr environment:

Active Directory

Site systems

SQL Server activity

Network infrastructure devices

Microsoft provides extensive guidance on auditing AD, Windows, and SQL Server in its learning centers for each product. Some specific events you should consider incorporating into your organization’s incident response plan follow:

Changes to Active Directory Groups with ConfigMgr Access: Administrators responsible for ConfigMgr security should review these changes.

Changes to Local Users and Groups on ConfigMgr Site Systems and the Site Database Server: These events should rarely occur.

Changes to the Local Security Policy on ConfigMgr Site Systems and the Site Database Server: These events should rarely occur.

Changes to the SQL Server Security Configuration on the Site Database Server: These events should rarely occur.

Threats to systems generally fall into one or more of the following categories:

Fingerprinting is an attempt to enumerate and gather information about resources on the network. Typically, the attacker tries to discover system characteristics such as operating system, open ports, and installed applications in order to determine what vulnerabilities may be present. Fingerprinting is generally a precursor to a more serious attack. Detecting an attack at this stage may enable you to prevent the attack from progressing.

Execution attacks are the greatest threat to systems. Execution attacks are attempts to execute unauthorized code on the system. These attacks use methods such as malware, application layer attacks, and network-based exploits of remote code execution vulnerabilities.

Identity-based attacks are another major threat to systems. These attacks involve stealing a legitimate user’s credentials or bypassing authentication or access controls. The “Securing Administrative Access to ConfigMgr” section, earlier in this chapter, discusses mitigation strategies for identity-based attacks.

Denial-of-service attacks are attempts to bring down or disrupt essential IT services.

The following sections discuss methods to mitigate these risks through secure design supplemented by security technology.

Constrained language mode limits PowerShell access to features such as the Win32 API, .NET framework, and COM objects that can invoke unverified code. AppLocker integration enforces PowerShell constrained language mode when AppLocker is in allow mode. If you have scripts requiring extended language support, use a mechanism such as a trusted enterprise-signing certificate allowed by AppLocker policy to run those scripts.

Utilize Windows 10 Antimalware Scan Interface (AMSI) integration. PowerShell submits all script content to the registered antimalware service on the system. Traditional scanning based on file access might miss PowerShell scripts that exist only in memory and never touch the disk. No special configuration is required.

Use group policy, Registry settings, or PowerShell commands to enable and configure PowerShell logging. As with other security logging, use a SIEM or Windows Event Forwarding to store log data off the box. PowerShell 5 includes the following logging:

System-wide transcript logging provides a record of commands entered in each session.

Deep script block logging provides execution details of all script activity on the system. Use Windows 10 Protected Event Logging to protect sensitive data stored in logs, such as credentials used by PowerShell.

Many organizations are incorporating application whitelisting programs into their malware protection strategies. The IAD and ASD top controls lists, referenced in the section “A Security Primer,” earlier in this chapter, both list application whitelisting as the number-one control. Whitelisting allows only “known good” programs to run, as opposed to signature-based antimalware that eliminates “known bad.” AppLocker provides application whitelisting technology. Use the Group Policy Management Microsoft Management Console (MMC) snap-in or PowerShell to manage AppLocker. AppLocker can allow or ban executable code by attributes such as publisher, product, and filename. Some application whitelisting programs allow implementation of policies to allow software updates made through specific methods. For example, your policy might allow the ConfigMgr agent and Windows Update executables to add or modify software and block other processes from making such changes. While such dynamic whitelisting reduces administrative overhead by eliminating the need to manage the whitelist manually, expect to spend time tuning the rules for each distinct system build. Application whitelisting is best suited to relatively static environments with effective change management and consistent processes, as should be the case with production servers. It is more difficult to implement in highly dynamic environments such as development environments and end-user systems.

Software firewalls, including Windows Firewall, provide protection against network-based attacks. In high-security environments, consider using specialized host intrusion prevention (HIP) software to provide an additional layer of protection by detecting and blocking a more extensive range of suspicious process activity, such as nonstandard memory access methods. The latest versions of Windows have impressive built-in memory protection. HIP software may supplement Windows memory protection by providing signatures to block known memory-based attacks such as those exploiting known application vulnerabilities. File integrity monitoring (FIM) software protects critical files from alteration. Consider using FIM to alert you if changes occur to key ConfigMgr files such as the service executables, site control file, and client source files.

Endpoint detection and response (EDR) is one of the hottest new security technologies. Working with preventive technologies such as traditional antimalware and application whitelisting, EDR implements a prevent, detect, respond approach to security, described earlier in this chapter, in the section “Planning for Security and Delegation.” EDR software monitors endpoints (including end-user systems and servers) for suspicious or anomalous activity, correlates detections across the enterprise, and enables administrative or automated responses.

Security programs are intrusive by nature, often consuming significant amounts of system resources and sometimes blocking legitimate activity. Test and adjust your security software settings in your proof of concept environment and monitor the impact of security software in production. To improve system performance and availability, you may decide to create exceptions, such as excluding certain folders from virus scanning. Exclusions typically apply to files locked during normal operations, such as database files, or to files that are frequently accessed and that are not common vectors for introducing malware, such as log files. Any exclusions you create can introduce potential weaknesses in your protection framework that could be exploited by malware. Follow your organization’s risk policy when considering any exclusions or other exceptions in your controls. Microsoft TechNet Wiki provides a comprehensive list of resources for related to AV exclusions at http://social.technet.microsoft.com/wiki/contents/articles/953.microsoft-anti-virus-exclusion-list.aspx. This includes recommendations for software on site systems including ConfigMgr, Windows, SQL Server, and IIS. Major AV vendors also provide guidance on the use of their products on Microsoft systems. Also, consider any vendor-recommended exclusions for installed components such as backup software or host-based adapters (HBAs). Note that vendors are typically more concerned with the functioning of their products than with the security of your systems and might publish overly broad recommendations for excluding their software.

Create a process to respond to events from security software such as malware detections and blocked activity. If you find false positives, evaluate the impact on system functionality and modify security software settings as required. Process Monitor is a Windows monitoring tool that shows detailed process-related activity; it is available for download at https://technet.microsoft.com/sysinternals/processmonitor.aspx. If you suspect that virus scanning is affecting system or application stability or performance, Process Monitor can help determine what files are being opened. If you see files that are frequently scanned, you might consider them for exclusions. Some antivirus applications allow you to apply different on-access scanning exclusions based on the process accessing files. For example, a file modification by the Windows Module Installer (TrustedInstaller.exe) might be considered a low-risk event and may not trigger a scan, whereas a file modification by Internet Explorer would be far more likely to introduce malware and warrant an immediate scan. Using this type of feature is safer than allowing all processes to read from or write to the excluded files without scanning. If your antivirus software supports it, designate ConfigMgr processes as low risk and apply exclusions for specific site roles only to low-risk processes. Some processes you might want to designate as low risk follow:

ccmexec.exe (on management points)

sitecomp.exe

smsexec.exe

smswriter.exe

sqlservr.exe (on site database servers)

sqlwriter.exe (on site database servers)

Configure SQL Server to use Windows authentication only and enable logging at least for failed logon attempts. Use a low-privilege domain account rather than Local System for the SQL Server startup account. When you run SQL Server in a low-privilege account context, you must register the service principal name (SPN) manually for the server in AD. Clients use the SPN to locate SQL services. Use the procedure described at http://technet.microsoft.com/library/hh427336.aspx#BKMK_ManageSPNforDBSrv to register the SPN.

Site servers

Site database servers

Site systems that run IIS

Management points

Fallback status point

Confidentiality: ConfigMgr uses encryption to prevent disclosure of sensitive data. Encryption converts data into a form that only parties with access to a secret key can read.

Authentication: ConfigMgr uses digital certificates to authenticate the identity of systems during network communications and to sign sensitive files exchanged between systems. ConfigMgr can use either public key infrastructure (PKI) certificates or self-signed certificates. Chapter 4 introduces the certificates used in ConfigMgr.

Integrity: ConfigMgr uses hashing and digital signatures to protect the integrity of data such as the content used in software distribution. A hash is generated by applying a hashing algorithm to a file. The receiving system re-creates the hash and compares it to the hash value provided by the policy provider. Any alteration of the file also alters the hash and causes the comparison to fail. This protection does not apply to App-V streamed content or to certain mobile device and non-Windows clients.

The authors highly recommend using PKI certificates rather than self-signed certificates wherever possible. The following features require PKI:

HTTPS communications

Support for clients on the Internet

The Microsoft Intune connector for mobile device management

There are no silver bullets in security. Security researchers have recently discovered several flaws in cryptographic methods that have been Internet standards for many years. If you haven’t already, you should disable SSL 3.0 and enable TLS 1.1 and 1.2, as described at https://support.microsoft.com/kb/245030. In addition, at least one major certificate vendor has had its root CA canceled. This does not detract from the importance of cryptographic controls in securing your data. However, it underscores the importance of using multiple layers of security and keeping systems up to date on all security patches.

The next sections discuss the two principal scenarios where ConfigMgr uses cryptographic controls: securing network communications and securing content distribution.

Misdirection Attacks: In this type of attack, a client or site system is provided with the wrong name, Internet Protocol (IP) address, or MAC address for the partner with which it needs to communicate. Secure service advertisement and name resolution services to avoid misdirection attacks.

Spoofing Attacks: In this type of attack, a rogue system impersonates the actual system with which a client or site system needs to communicate. All communications must be properly authenticated to defeat these attacks.

Eavesdropping or Sniffer-Based Attacks: This type of attack involves an attacker intercepting network communications and gaining access to confidential information. Data encryption is the primary defense against breach of confidential communications.

Man-in-the-Middle (MITM) Attacks: These attacks occur involve an attacker stealing, altering, or interrupting communications by routing data through an intermediate node under his or her control. You can often defeat MITM attacks by using mutual authentication. Digitally signing files can help detect alterations due to MITM attacks.

Denial-of-Service (DoS) Attacks: In this type of attack, an attacker uses large amounts of data or malformed data packets to crash systems or clog communication links. A resilient network infrastructure and fault-tolerant service delivery design are the best defenses against DoS attacks.

Microsoft provides several security features to protect the confidentiality, integrity, and availability of ConfigMgr communications. The next sections discuss using these features to secure communications between ConfigMgr clients and their site and communications between ConfigMgr sites and site systems.

Most ConfigMgr HTTPS traffic is encrypted. This prevents an attacker eavesdropping on client communications from gaining access to sensitive data such as vulnerability data that could be used to attack the client. Even with HTTPS, state messages sent to the FSP, PXE requests to a PXE-enabled DP, and notification data to an MP are not encrypted.

ConfigMgr HTTPS implements mutual authentication. Authentication protects the client from being redirected to a rogue site system. With HTTP communication, the MP is authenticated using a self-signed certificate; however, other site systems are not authenticated. As HTTP clients do not authenticate themselves to MPs, you accept either the risk of untrusted clients joining your site or the added effort of managing client approval.

Mutually authenticated HTTPS prevents an attacker from impersonating the client in order to carry out MITM attacks, which may be used to tamper with and access data.

The site server should have the highest level of system, network, and physical security you can provide. There may be instances in which you cannot provide the same level of security for all site systems. In such instances, consider enabling the Require the site server to initiate connections to this site system setting on the less secure systems. To enable this setting, check the appropriate box on the General page of the Add Site System Roles Wizard. This site system setting protects the site server by preventing less secure systems from initiating communication to the site server.

The application catalog represents another potential point of attack against clients. Configure the application catalog website to use HTTPS rather than HTTP. The authors recommend separating the Application Catalog website and the Application Catalog web services role, particularly if the website can accept connections from the Internet.

Another important consideration for software distribution is preventing users from leveraging deployments to gain elevated privileges. Avoid configuring both the Allow users to view and interact with the program installation and Run with administrative rights program options. These options enable the user to influence the execution of a program running in an administrative context, generally Local System. In some cases, the user might break out of the user interface provided by the setup program and spawn another program, such as a command shell, providing unlimited access to the system. You can specify these options for software distribution packages on the Standard Program page of the Create Program Wizard. For Windows Installer applications, you can control user interaction through the msiexec /q command line switch; group policy or registry settings govern whether or not Windows Installer runs packages with elevated rights.

ConfigMgr can only protect the content you provide; you must ensure the integrity of the source files. Download software only from trusted sources and verify the files after download. Similarly, inspect any physical media used to receive files for a certificate of authenticity and tamper-resistant packaging.

Scan all source files for malware and keep them on a secure network share or storage system. Consider using file integrity monitoring software to prevent alterations.

Secure the reference computer by placing it in a secure network environment, blocking unauthorized access, and keeping patches and antivirus software current.

Secure all boot images, OS images, drivers, and driver packages as you would secure package source files.

Password protect all boot media and keep media physically secure.

Use a secure network channel such as IPsec to protect private or confidential data during user state migration. Secure user data on the user state migration point and delete all user content that is no longer needed. Use the latest version of the User State Migration Tool (USMT) supported by ConfigMgr.

Enable encryption for all multicast packages to prevent tampering and exclude rogue computers from multicast sessions.

Use strong passwords and change those passwords regularly.

Enable the Password never expires and User cannot change password options for Windows and AD accounts used by ConfigMgr.

Use a password management application to secure ConfigMgr passwords. Restrict access to administrators on a need-to-know basis and track who knows those passwords. If a person with access to ConfigMgr passwords leaves the company or if you suspect that a password is compromised, change the affected passwords immediately.

Keep track of which accounts are used where and deprovision any accounts no longer needed.

Configure each account with the minimum rights to accomplish its job.

When you use AD accounts, allow time for newly created accounts to replicate throughout the domain before adding them to ConfigMgr.

Do not grant the interactive logon right. You may need to grant it to an account temporarily so the account can be used for troubleshooting purposes. An exception is the Task Sequence Run As account, which needs interactive logon rights on systems where a task sequence configured to use this account runs.

Microsoft provides detailed descriptions of all ConfigMgr accounts in the online documentation. To help you sort out these accounts, the next sections present ConfigMgr accounts organized into functional groups. Find additional details about ConfigMgr accounts at https://technet.microsoft.com/library/mt627794.aspx.

Following are the accounts used for installation purposes:

Site system installation accounts are used to install and configure site systems.

Client push installation accounts are used to install and configure client systems when using the client push installation method. Client push is less secure than other client installation methods; avoid using it if possible.

Chapter 6, “Installing and Updating System Center Configuration Manager,” discusses site server installation. Chapter 9, “Client Management,” discusses client installation methods. Use AD or local accounts for site system installation and client push. These accounts must be in the local Administrators group on the target systems. Do not add these accounts to the Domain Admins group because it provides excessive privileges to the accounts. Create groups that include the appropriate accounts and use group policy or local computer management to add those groups to the local Administrators group. To limit the administrative scope of these accounts, consider using multiple accounts and granting each account access only on the systems where it is used.

TABLE 23.2 Database Roles for Connection Accounts

Account Name	Database Role
Management point connection account	smsdbrole_MP
Certificate registration point account	db_datareader
Enrollment point connection account	smsdbrole_EnrollSvr
Multicast connection account	smsdbrole_MCS
Source site database account	db_datareader and smsschm_users on the source (ConfigMgr 2007) site database during migration
Reporting services point account	Administrative rights on the SSRS instance

TABLE 23.3 Accounts Used in Task Sequences

Account Name	Where Used	How Used	Required Permissions
Capture operating system image account	Task sequences with the Capture Operating System Image step	To access the folder where captured images are stored	Read/write permissions on the network share where the captured image is to be stored
Task sequence editor domain joining account	Apply Network Settings task sequence or Join Domain or Workgroup task sequence	To join newly imaged computers to the domain	Right to join computers to the target domain
Task sequence editor network folder connection account	Connect to Network Folder task sequence	To connect to network shares	Access to content
Task sequence run as account	Run Command Line task sequence	To provide a context for running commands during a task sequence	Interactive logon rights and other rights required by the specific command

OSD accounts are generally AD domain accounts, although you can use local accounts for the capture operating system image account and the task sequence run as account.

In addition to the accounts listed in Table 23.3, OSD and software distribution use the network access account to access network resources when the client computer account and/or current user does not have access. This account typically is used for client computers in workgroups or untrusted domains or during OSD before the computer joins the domain. Grant the account domain user permissions only.

For granular access to packages, specify one or more package access accounts on a per-package basis. Package access accounts can be any Windows user or group. Generally use existing groups as package access accounts rather than creating accounts for this purpose. The default package access permissions are assigned to the local Users group with read permission and local Administrators with full control. In general, you change these defaults only to restrict those packages that you do not want all users to be able to access. Occasionally you might grant modify permission for package access accounts if a setup program needs to write back to the source folder.

Software Update Point Proxy Server Account: The software update point (SUP) uses this account to authenticate to a proxy server or firewall to synchronize with Microsoft Updates or an upstream Windows Server Update Services (WSUS) server. Use any account that can authenticate to your proxy server or firewall and access the site for WSUS synchronization for this account.

Software Update Point Connection Account: WSUS services use this account to configure settings and request synchronization. This account is required only if the SUP role is assigned to a remote server or a network load balancing (NLB) cluster. The account must be a member of the local Administrators group on the SUP.

Chapter 15 describes the Software Updates feature.

Active Directory Group Discovery Account: ConfigMgr uses this account to discover AD security groups and group memberships.

Active Directory System Discovery Account: ConfigMgr uses this account to discover computer objects.

Active Directory User Discovery Account: ConfigMgr uses this account to discover user accounts.

Active Directory Forest Account: ConfigMgr central and primary sites use this account to publish data to AD. ConfigMgr also uses this account for AD network infrastructure discovery.

Each discovery account requires read access to the AD containers specified for discovery. The Active Directory forest account also requires full control permissions to the System Management container to publish to AD.

Asset Intelligence Synchronization Point Proxy Server Account: The Asset Intelligence synchronization point uses this account for proxy authentication when connecting to System Center Online.

Exchange Server Connector Proxy Server Account: Exchange uses this account for proxy authentication when connecting to the Internet.

Configure proxy server accounts with the minimum permissions required to authenticate to the proxy server.

Exchange Server Connection Account: The site server uses this account to connect to the Exchange server for mobile device management. Chapter 15 discusses how to configure this account and the permissions it requires.

Remote Tools Permitted Viewer Accounts: Any Windows users or group can be included in the permitted viewers list to allow remote control access to clients. Chapter 9 describes how to configure permitted viewer accounts. Under most scenarios, it is better to use RBA to delegate remote control access than to use permitted viewers.

SMTP Server Connection Account: The site server uses this account to authenticate the mail server using Simple Mail Transfer Protocol (SMTP) to send email alerts for Endpoint Protection.

Source Site Account: ConfigMgr Current Branch uses the source site account to connect to ConfigMgr 2007 sites during migration. This account requires read access on the source site and all objects to be migrated. Chapter 7 describes the configuration and use of this account as well as the source site database account.