Insights

How to Set Up ConfigMgr for GDPR, HIPAA, PCI and Other Regulations

by

As a ConfigMgr professional, how much to you know about government regulations? At the very least, you should learn the basics to make sure you’re maintaining compliance across your organization.

Any system that accesses regulated data needs extra protection. Examples of this kind of data are GDPR, HIPAA, FERPA, and PCI. This blog is by no means a guide to fully protecting these systems, but could provide ConfigMgr admins with some guidance on how to set up ConfigMgr to manage these systems.

Regulated Data Types

There are several types of regulated data defined in the laws of the US and European Union. The four most widely talked about are those listed above – GDPR, HIPAA, FERPA, and PCI.

The General Data Protection Regulation (GDPR) is a regulation passed by the European Union to unify data protection for everyone in the EU. It specifically regulates the transfer of data about EU citizens to counties not in the EU. The regulation also recommends that large organizations have a Data Protection Officer whose sole responsibility is safeguarding personal data.

The Health Insurance Portability and Accountability Act (HIPAA) was passed by the US Congress in 1996. It has five titles, but we’re only really concerned about Title II. This section establishes the privacy and security rules around the sharing and transfer of health information.

The Family Education Rights and Privacy Act (FERPA) was passed by the US Congress in 1974. It established regulations regarding the transfer and sharing of educational records. It also establishes what information about a student is FERPA-regulated and what information is not. It also has somewhat controversial (especially among parents paying for the child’s education) regulations, like student consent prior to the release of records.

Finally, Payment Card Industry Data Security Standard (PCI DSS, or simply PCI) is not a law. It is a standard agreed upon by banks and the credit/debit card industry in the US. This standard has twelve requirements that merchants must adhere to. If there is a breach and the merchant did not adhere to the PCI standard, fines and other penalties may occur. Some US states, such as Minnesota and Nevada, have laws that specially require PCI compliance for merchants.

Scope

The most important thing to remember when dealing with regulated data is that ANY system that touches the data is considered “in scope” of the regulation. That means that if you use ConfigMgr to manage these systems, your ConfigMgr environment is considered in scope. The same goes for Active Directory, file services, printing, or any other recourse.

Ideally, to control this scope, admins would set up a separate environment to manage these systems. This would keep the scope of regulations confined to a sub-set of your overall environment. This almost always is not possible, because organizations usually don’t have the resources for two environments and it’s cost-prohibitive. I’m not just talking about ConfigMgr here, but all services that interact with regulated systems.

Middle Ground

Because creating two environments is not feasible, admins usually must find some middle ground. It all comes down to delegated duties and ensuring that delegation and security scopes are defined correctly. Admins must be sure that their regulated systems are walled off enough that the risk becomes acceptable. This might include separate AD containers with dedicated admins and not allowing read rights for all users. It might also mean another domain with a transitive trust. Also, separate file volumes and print servers might be in order.

For ConfigMgr, you’re looking at separate collections and applications at a minimum. You also need to consider separate user roles and security scopes. You need to make it so that the only users who can see the device objects are the admins directly responsible for managing your regulated machines (this is also just good general practice). Don’t forget about access to the All Systems collection here, or any general “All xx Devices” collections (such as “All Windows 7 Devices” or “All Servers”). You may have to get a little more specific with these general collections.

In my environments, I set up top-level collections called “All Clients”, “All Servers”, and “All Regulated Systems”. These are also separate top-level containers in my AD. Access is granted at these levels or lower. No one has access to “All Systems” except for those listed as Full Administrators in ConfigMgr. Also, all other collections are limited by these top-level collections or lower collections in that branch. Nothing is limited by “All Systems” (expect these top-level collections). Under these collections, I’ll have “All Clients – Windows 7” and “All Regulated Clients – Windows 7”.

For software, it’s also best to have separate source repositories and ConfigMgr applications for your regulated machines. This ensures that the source files for your regulated machines cannot be tampered with or changed by someone who doesn’t have the correct level of access. These applications should have their own security scope in ConfigMgr that is only applied to those responsible for managing regulated systems.

As I said in the beginning, it comes down to delegated responsibly and ensuring that access is assigned appropriately. Ensuring those two things will get you a long way to towards finding an acceptable amount of risk.

Matt Tinney
CEO, Windows Management Experts