15 min read

This article created by Andreas Baumgarten, Ronnie Isherwood, and Susan Roesner the authors of the book Microsoft System Center 2012 Compliance Management Cookbook, mentions all System Center Product we work with in the book. It also talks about responsibilities/stakeholders, and the reports involved.

(For more resources related to this topic, see here.)

Understanding the responsibilities of the System Center 2012 tools

This recipe shows how the System Center tools, in addition to Security Compliance Manager, work together and it also explains the focus of each tool.

Getting ready

In order to create a successful compliance program, you must have a clear understanding of your goals and regulatory and business requirements. This information is key in understanding which control objectives are required and which control activities fulfill your goals and requirements, that is, your control objectives.

How to do it…

Based on your company and regulatory requirements, you must create your control objectives. There are libraries, such as the Unified Compliance Framework (UCF), that provide control objectives and control activities based on regulatory requirements such as privacy laws and frameworks such as COBIT, COSO, and so on. These compliance libraries are great tools to help you with this first step, but always keep in mind that they are just tools.

The following diagram provides a visual summary of the tasks required for the successful creation of a technical compliance program showing which System Center tool to use for the different tasks. The tasks are as follows:

  • Define compliance requirements
  • Perform authorized implementation
  • Review adherence to compliance requirements
  • Perform remediation

Microsoft System Center 2012 Compliance Management Cookbook

The minimum steps that are required are as follows:

  1. Define and document your compliance program, including compliance policies, standards, corresponding control objectives, and control activities. The results of this step are control objectives and control activities.

    Based on the scenario of access compliance, you should create a password policy that states the password rules and the reasons for the policy. This must be distributed to your users.

    With your policy and, more importantly, regulatory and company requirements in mind, decide on your control activities.

  2. The results of step 1 are the input for this task—for manual controls, use System Center Service Manager for documentation. The results are control status information.

    Based on the password policy scenario, in case no System Center Configuration Manager exists, the correct implementation of password policy would have to be checked manually. The result of this check should be entered into System Center Service Manager. This could either be entered in Incident or Change Management. Creating either one provides a record of the manual control and has the benefit of being included in the System Center Service Manager reports.

  3. The results of step 1 are the input for this task—for automated control activities based on configuration settings do the following:
    1. Use Security Compliance Manager to create compliance baselines for control activities of configuration settings. The result is the compliance baseline.

      Create a baseline with your password policy.

    2. The input is the compliance baseline from the previous step. Use Compliance Settings within System Center Configuration Manager to run the compliance baseline. The results are compliance control status information.
      Use the compliance baseline from Security Compliance Manager to ensure adherence to it. After configuring the controls, those will be run automatically. In addition, auto-remediation of failed controls is possible.
  4. The results of step 1 are inputs for this task—for automated control activities based on breach status, use Audit Collection Services from System Center Operations Manager. The results are compliance breach information.

    Based on the password policy scenario, create a monitoring rule for unauthorized access to critical systems and unauthorized changes to your password policy.

  5. The results from steps 2, 3, and 4 are input for compliance status and audit reports. Reports are available in the following:
    1. System Center Service Manager for manual control activities. In addition to centralized reports of automated controls, where input of the controls comes from other tools such as System Center Configuration Manager. The reports are based on the System Center Service Manager function of Incident or Change Management.
    2. System Center Configuration Manager for control activities in the previous step 3.
    3. System Center Operations Manager for control activities in step 4.
  6. The results from step 3 could be remediated automatically. The results of steps 2 and 4 must be considered and, if required, steps for remediation should be taken.

How it works…

The tool to use for control objectives and the corresponding control activities depends on the possible input and the required result of the control activity. The most basic questions that have to be answered are as follows:

  • Does the control activity have a manual input/output?
  • Is the control activity based on a query for system or application configuration status information?
  • Is the control activity based on a query for monitoring/breaching status information?
  • What type of control (manual or automated) and which characteristic of the control (preventive or detective) do you require?

Based on the answers to those questions, it is possible to understand which System Center tool or Microsoft technology to use.

Creating automated control activities within the System Center tools is but one task. The next steps must be as follows:

  • Creating notifications or alerts for relevant stakeholders and reports
  • Performing remediation

Every System Center tool has its own reporting capability. This means there are different compliance reports in different System Center tools. To enhance usability, System Center Service Manager could be used to centralize most of those reports.

Remediation for automated control activities, based on configuration settings, is the feature of System Center Configuration Manager. Depending on the requirements, after running a control activity compliance baseline that includes storing the results, all negative results of control activities could be remediated automatically. For auto-remediation based on monitoring or breach information, System Center Configuration Manager offers the capability to define actions. System Center Operations Manager offers the same capabilities.

Each breach of a baseline could be auto-remediated out of the box. Regardless of the tool used, remediation must always be done in a documented fashion as this is a very common compliance requirement. In case a change is involved, the change management capabilities of System Center Service Manager should be used. All System Center tools create logs showing the action performed.

There’s more…

Besides the already mentioned System Center tools, there are two more tools that belong to the core System Center product family. These are System Center Virtual Machine Manager and System Center Data Protection Manager.

System Center 2012 R2 Virtual Machine Manager doesn’t offer any compliance functionalities. It includes an audit log of administrator activities. This is a requirement in several regulatory requirements and therefore is quite useful. Out of the box, no additional benefits are provided.

System Center 2012 R2 Data Protection Manager (SCDPM) is different. This tool is used for Backup and Disaster Recovery. These two topics are requirements in many standards and regulatory requirements. But there are already great books out there focusing on SCDPM, such as the following one:

http://www.amazon.com/Microsoft-System-Center-Protection-Manager/dp/1849686300/ref=sr_1_1?ie=UTF8&qid=1403700777&sr=8-1&keywords=System+Center+Data+Protection+Manager

Therefore, we have not included any recipes of SCDPM in this book.

See also

Planning the implementation of Microsoft System Center 2012 Service Manager

Microsoft’s System Center 2012 Service Manager (SCSM 2012) can be used to manage IT management processes (ITIL and MOF). The compliance management process is related to the IT management processes as well.

Compliance issues can be handled as incident records; also, compliance related changes can be managed in SCSM 2012 as Change Requests.

Getting ready

Before we start planning the installation of SCSM 2012, you should be familiar with the ITIL or MOF management processes.

Also, you should have planned the Incident and Change Management process for IT.

How to do it…

An example of the steps to plan the installation of the SCSM 2012 environment is as follows:

  1. Identify the required components of SCSM 2012. The SP1 or R2 version are also suitable.
  2. Identify the sizing of the SCSM 2012 infrastructure.
  3. Identify the amount of Configuration Items you want to have in the CMDB of SCSM 2012.

How it works…

For good performance in SCSM 2012, sizing and planning of the environment is essential. There is a Service Manager Sizing Helper tool available in the Service Manager job that aids documentation. You can download the SM_job_aids.zip file at http://go.microsoft.com/fwlink/p/?LinkID=232378.

One sizing related factor is the amount of managed Configuration Items (CIs), for instance, managed users, computers, groups, printers, and other IT-related objects. Planning the numbers of CIs influences the sizing of the SCSM 2012 as well.

There’s more…

The IT Governance, Risk and Compliance Management Pack (IT GRC MP) is not supported in SCSM 2012 R2. The last supported version is the Microsoft System Center 2012 SP1 Service Manager.

See also

Planning and defining compliance reports

The goal of compliance reports is to answer two things: “How am I doing” and “How effectively am I doing it” especially with regard to helping the business understand current and future threats.

This recipe gives an overview on how to plan compliance reports.

Getting ready

Research the regulatory requirements using your country’s respective laws, industry standards, and regulation. This will ensure your reports are relative only to your business and technical compliance objectives. For example, there are standards such as SOX section 404 that demand reports with certain criteria.

How to do it…

There are going to be at least two different types of reports you must plan for:

  • Compliance status or audit reports
  • Stakeholder-targeted reports

Compliance status / audit reports

Compliance status / audit reports are based on your controls. For these reports to answer the question about the actual compliance status and the effectiveness of the compliance program for your business, careful considerations have to be made as to which control activities will produce your business objectives. Therefore, the planning stage of these reports is already completed by the planning of your control objectives and their verification through control activities.

With regard to System Center, out-of-the-box reports will be sufficient for many of these compliance status reports and audit reports.

As mentioned in the Getting ready section of this recipe, be aware that several laws and industry standards demand certain formats for audit reports. In cases where the System Center out-of-the-box reports do not fulfill them, customized reports will have to be used.

Stakeholder-targeted reports

The purpose of these reports is to keep the stakeholder of your company informed about the compliance program. Therefore, the following questions must be answered:

  • Who is the target audience of this report?
  • What is your goal for this report?
  • What input/output data can provide the required information?
  • Who is responsible for the report (owner)?
  • What is the frequency of the reports?
  • How do you want to present this report?
  • What is the improvement process on reports including data source input/output and controls?

We will focus on the first question. You will have to consider reports for different levels such as the following:

  • CEO and/or board members
  • CISO and/or IT/Security team
  • IT application owner

Depending on the targeted audience of the report, different input/output values have to be used and sometimes, translation of inputs/outputs must be used.

Using out-of-the-box reports from System Center tools will be possible for reports targeting IT application owners, CISO, the IT Security team, or the compliance team. Reports based on the analysis of certain control input/output data will either be accomplished using customized reports within System Center Service Manager or using additional tools such as System Center Orchestrator or dashboards.

Regardless of the actual report, during the planning phase, several principles, that will increase the value of the reports to the business, should be followed. These principals are as follows:

  • The overall report should be complete for its context
  • The input of these reports should be consistently measured, at a low cost and preferably, as a number or percentage in context
  • The output should be relevant
  • The input and output should be transparent

Complete

Based on previous experience, compliance and IT security staff, while attempting to create reports, put in as much information and statistics as possible. In general, the report must be complete for the context it is designed for. So, on a CISO level, besides technical controls, manual controls including policy or process compliance may have to be included. Still, the report must be concise too.

As a best practice, start out with the out-of-the-box reports provided by the System Center tools as they offer a large number of compliance reports.

Measurable

Being measurable is a key principle for creating valuable reports. The input and output data source or control should be measured in a consistent way. So, two different people using the same control at the same time should produce the same output. As much as possible, control should be automated to ensure this consistency and also to minimize cost. In case the control has to be done manually, it is essential that the people performing them do this in a consistent way. To accomplish this goal, each control should be documented; for example, there should be a document on the IT compliance for identity and access management. For the general users, one important document is the password policy, which should answer the questions why, what, how, and by whom. For IT people, there should be an additional document stating the technical implementation and automated or manual control, to ensure compliance with the password policy. In addition, it should mention how the control activity should be performed.

In addition, whenever possible, controls used for reports should be expressed in numbers or percentage against a unit. For example, a control saying “10 systems out of 100 systems” have missing critical security updates, provides a clear value for a decision on what to do next, compared to a control with the value of “medium”.

Relevant

This principle is important especially for the stakeholder-targeted reports. Reports should include controls or output that help the targeted audience in decision making. So the question of to whom the report will be provided is a decision factor on what to include and how to present the report. The IT security staff or compliance team requires the exact numbers of controls, for example, that 10 systems from 100 systems have missing critical security updates, whereas the IT application owner requires a drill down on which systems and security updates were missing.

Transparent

The target audience of a report must understand the controls or output used in the report. The labels should be plain and consistent; and clear measures for controls or input/output should be used. In addition, they must understand how these results came to be. This is especially true for indexes that comprise several controls. If this is the case, it should be clear as to which controls are included. If possible, indexes should be avoided as they average out the value presented in the report; for example, System Center Service Manager allows a report on incidents in the category under Security Compliance | System Security. The overall status of System Security may be green, as all controls besides the patch management control relating to critical security update did not report any issues. In case the affected systems hold sensitive information or are accessible by the public, this could be a factor in the decision process for immediate remediation steps. Understanding which controls are within the System Security category and being able to drill down into those controls or input/output used is important for a report.

How it works…

The focus is to give you an understanding of the type of reports you should consider and some basic considerations you should include in planning your reports.

The first step is the planning of your control activities. If the control activities do not provide a measure of the effectiveness of your control objectives, then no report will be able to answer this question. Hence, qualified input/output controls are required. In this regard, the stakeholder of controls must provide input and sometimes must be included to improve processes or controls.

Use the questions in this recipe to start out with the creation of your reports, but keep in mind that you have to adapt the information provided here to meet your business requirements and objectives.

There’s more…

All System Center reports are based on the SQL Reporting service. This means you can create customized reports should the out-of-the-box reports provide the information you require.

See also

Detailed information on how to plan and implement reports based on System Center may be found in the book Security Metrics, Andrew Jaquith, Addison-Wesley Professional (http://www.amazon.com/Security-Metrics-Andrew-Jaquith-ebook/dp/B0050 G2RC8).

Security Metrics is a book focusing more on effective measuring of IT security operations. It provides insights into implementing qualitative and meaningful data sources, ensuring reports that provide knowledge to help make the right strategic decisions.

Look out for an upcoming cookbook by Sam Erskine from Packt Publishing. This book on System Center Reporting will provide detailed information on how to plan and implement reports based on System Center.

Summary

This article provided recipes on how to integrate the System Center products. The recipes use hands-on examples to show the required planning and implementation that must be made to align the System Center tools with the compliance process.

Resources for Article:

Further resources on this subject:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here