What is compliance?
This topic introduces you to the concept of compliance in BMC BladeLogic Server Automation (BSA). It includes the following sections:
This topic is intended for systems administrators with knowledge of server and infrastructure management, but who are new to BSA. It is specifically targeted for those administrators who manage system compliance in their environment.
Overview of compliance in BSA
In BSA, compliance is the process of determining whether the systems in your environment meet a specific standard. That standard might be a regulatory standard, such as DISA or SOX, or some type of internal standard defined in a corporate compliance policy.
So, what kinds of compliance are we talking about here?
The following list highlights some of the key areas of compliance you can track and remediate using BSA.
- Regulatory and security compliance - Defined by third parties such as CIS, DISA, PCI, or by internal corporate standards.
- Build compliance - Defined by internal standards for new systems, to ensure that the system is starting out in a known good state.
- Configuration compliance - Ensures that the system is still in a known good state even after being in production for a while.
- Patching compliance - Ensures that the system has the proper set of patches installed. (For more information, see the walkthroughs in the Getting started with patch management for more on patch compliance.)
- Change tracking - Ensures that the system looks the same today as it did yesterday (except for authorized changes).
Some useful terms
The following table lists some of the terminology used when discussing enforcing compliance with BSA.
|Components and Component templates|
Compliance analysis and remediation are performed based on two types of BMC Server Automation objects: components and component templates.
Components — The parts that make up a server configuration.
Component templates — Contain relevant compliance rules that you want your servers to adhere to. Essentially, templates contain the parts, or assets on the server, that you want to evaluate for compliance.
Compliance policies are the rules by which the servers or components are evaluated for compliance. Basically, these are the component templates mentioned above.
Compliance Policies for many common standards are provided out of the box by BMC as part of Compliance Content. These are pre-built regulatory policies, which are very helpful for auditors.
You can also create your own component templates to contain the compliance rules for your internal corporate compliance policies. This is a common course of action when analyzing operational compliance, which involves tracking the properties of operating system objects (such as files, configurations, user accounts, or services). A typical example for creating your own compliance policy would be for Build Compliance.
Pre-built component templates offered out of the box by BMC to analyze regulatory compliance or security compliance. Such templates can facilitate compliance analysis when you need to adhere to industry-defined compliance policies (such as CIS, DISA, HIPAA, PCI, or SOX).
Note: BMC Server Automation offers an additional type of compliance analysis based on Security Content Automation Protocol (SCAP) benchmark content. SCAP benchmark content is stored as sets of XML files in the depot and a special SCAP Compliance Job is available for analyzing adherence to SCAP benchmark rules. For more information, see SCAP compliance analysis and Creating and modifying SCAP Compliance Jobs.
Audit Jobs allow you to compare server objects, components, server object based snapshots or component based snapshots to determine whether their configurations match a standard configuration. You can base audits on components or server objects.
Performing an audit based on components requires you to identify a master — that is, one or more components or component-based snapshots that act as a master.
To determine whether a component satisfies its compliance rules, you run a Compliance Job. The Compliance Job looks at the component's compliance parts and compares them to the part and property conditions that the compliance rules require.
If a rule is not met and remediation is enabled, you can correct the compliance failure by deploying a BLPackage to one or more servers, assuming that a BLPackage is specified as part of the compliance rules. A Compliance Job can automatically perform this remediation if you enable automatic remediation for both the job definition and the component template. Alternatively, you can review the results of a Compliance Job and manually choose the compliance rule failures that require remediation.
Basic compliance workflow
The following table lists the tasks you perform when executing a basic compliance workflow.
|Define or acquire compliance policies|
Create your own component templates to contain the compliance rules for your internal corporate policies, or use the prebuilt component templates offered by BMC Software to analyze regulatory compliance or security compliance (such as CIS, DISA, HIPAA, PCI, or SOX).
If you are using Compliance Content, you must first install and load the content.
|Set up users and permissions||BMC recommends that you set up a compliance user who is in charge of performing compliance analyses, and limit the permissions so that this user cannot perform other types of actions in BSA. This process is described in Walkthrough: Restricting permissions for a Compliance officer.|
|Create a component template||Sometimes you have to create your own templates that contain custom compliance rules.|
When you create and edit your own template, you:
|Test the rule conditions and remediations|
To quickly determine whether a component's signature conditions are valid on its associated target server, you can run a short validation process on any existing component. This validation process is especially useful in the case of components that you created manually, or if you need to re-validate a component after modifying the signature in the component template.
You should also test the remediation packages to ensure they produce the desired result.
|Run a Component Discovery Job for the component template||Next, you run a Component Discovery Job to discover components and create a group for organizing target components — The Component Discovery Job associates components with servers that satisfy the discovery signature defined within the component template. The components that are discovered by the Component Discovery Job serve as targets for Compliance Jobs. For information about creating and running Component Discovery Jobs, see Creating and modifying Component Discovery Jobs.|
|(Optional) Create a component smart group for the discovered objects||You might find it useful to create a component group (either a static group or a smart group) that contains all of the discovered components that are relevant to the Compliance Job. For information about creating a smart group, see Defining a smart group. |
|Create a Compliance Job or Audit Job|
Your next step is to create the Compliance Job or Audit Job that examines the component's compliance parts and compares them to the part and property conditions that the compliance rules require.
You can set up the job to to correct any compliance failures automatically, by deploying a BLPackage to one or more servers, assuming that a BLPackage is specified as part of the compliance rules. To do so, you would need to enable automatic remediation for both the job definition and the component template. Or, you can review the results of the job and manually choose the compliance rule failures that require remediation.
|Run the Compliance Job||The Compliance Job determines whether or not a component satisfies its compliance rules. The Compliance Job examines the component's compliance parts and compares them to the part and property conditions defined within the component template's compliance rules.|
|Review the results of the job||Before you perform remediation on compliance failures, review the results of your Compliance Job for details about the components on each server that satisfied or failed to satisfy each of the defined compliance rules.|
|Remediate the compliance failures|
Remediation of a compliance failure involves the deployment of a remediation package to the servers on which compliance rules failed.
In some situations, you can set certain components as exceptions to particular compliance rules. For example, you might want to allow the responsible user time to resolve a problem before initiating remediation through BMC Server Automation.
|Re‐run the Compliance Job or Audit Job to verify remediation||To ensure that remediation has been completed successfully, run the Compliance Job or Audit Job again to verify that the targets are now in a compliant state.|
Where to from here
To get started, see the following topic to set up the user roles and permissions for the compliance administrator: