Automated Compliance Expert Working Group Charter

Automated Compliance Expert (ACE)
Working Group

Working Group Charter

Version 1.1

Authors:

Shawn Mullen, IBM

Guha Prasad Ventakaraman, IBM

This Charter describes the purpose and objectives of the proposed Automated Compliance Expert (ACE) Working Group.

August 26, 2008

Table of Contents

Automated Compliance Expert – Working Group

Confidential

Introduction......

Purpose and Objectives......

Deliverables......

ACEML......

ACE Content Directives......

Benefits......

Benefit to Compliance Organizations......

Benefit to End Users......

Expected Resources......

Compliance Organizations......

Software Providers......

End Users......

Other Standards Organizations......

Roadmap and Timelines......

Working Group Administrative Information......

Appendix A

Automated Compliance Expert – Working Group

Confidential

Introduction

This paper proposes the charter for The Open Group Automated Compliance Expert Working Group.

According to AMR Research, North American Companies are estimated to spend $29.9B on regulatory compliance and will spend $8.8B this year on technology solutions to solve their compliance requirements.The cost worldwide is huge, and the need to comply is not an option. Reducing this cost is therefore a business imperative.

The key components needed to reduce the cost of compliance are automation and a consistent reproducible process. The Automated Compliance Expert Working Group (ACE-WG) will create a knowledgebase format which can be consumed by compliance tools. These tools will be able to achieve the high degree of automated compliance configuration and monitoring. This in turn will reduce the cost of compliance for end users and increase security consistency amongst their IT systems.

There are many different compliance standards. There are many areas of compliance within these standards. Not all elements of compliance can be automated. However, many of the compliance standards have overlapping guidance in the area of IT security and configuration. The Open Group can lead the way in providing an XML based compliance knowledgebase from which compliance automation tools can be built.

Purpose and Objectives

The purpose of this WG is to produce a standard which can be used to automate regulatory compliance. The objective of this standard is to be utilized by different and sometimesdisparate set of compliance organizations.These compliance organizations will be able to describe their compliance requirements using this standard. Software manufactures will be able to produce applications which can importand implement the requirements. End users will be able to automate the security hardening and configuration of their computer systems.

The following scenario might best illustrate the way this standard will streamline the compliance process and benefit industry. A corporation is required to meet PCI-DSS (Payment Card Industry – Data Security Standard). They will download the PCI-DSS pdf file and start reading. They note that much of the standard centers around security configurations. Currently the System Admin must manually configure each OS to meet these compliance requirements. There may be hundreds of systems involved. However, with this standard, the user would download an associated PCI-DSS XML configuration file or better described as a knowledgebase. This knowledgebase would then be ingested by compliance automation tools which would in turn configure the OS of one or more computer systems. All systems are automatically configured securely and consistently. This level of automation reduces human error, which reduces the vulnerability of the systems. It also saves the corporation time and money by reducing deployment time, monitoring effort, and audit schedules.

Not all areas of IT compliance standards can be automated. However, many configuration requirements can be automated. For example, many IT compliance standards mandate a minimum password length ofseven characters. Currently the end Compliance Officer or System Administrator must read the text of the Compliance Standard, “Require a minimum password length of at least seven characters[1].” They would then manually configure the OS to enforce this requirement. Obviously, if this same requirement was represented in a standard XML description, a software application could easily automate the configuration change. This same application could also check the configuration to meet reporting and audit requirements.

Compliance has some existing automation tools in the area of OS or platform configuration. However these solutions are currently proprietary and not fully integrated with the compliance organizations. This standard will allow these tools to advance to a greater level of efficiency and reduce the overall of cost of compliance.

Deliverables

The ACE Working Group will deliver a standard which can be categorized into two deliverables: ACEML, and ACE Content Directives.

ACEML

The ACE Markup Language (ACEML) is the XML schema or Data Type Definition (DTD) that defines the constraints and structure needed to formally express compliance requirements.

ACEML will be used by compliance organizations to express requirements.
ACEML will be used by compliance automation tools to implement these requirements through configuration controls upon the underlying device in a automated manner.
ACEML will be used to form a auditable historical log which records the details of any configuration change.

A single ACEML XML rule is divided into 3 areas.

Figure: Three sections of an single ACEML rule.

The Compliance Content is the only section described by the compliance organization. The Platform Specific Configuration Content is derived by the compliance automation tool as it maps the generalized Compliance Content into directives that can be understood by the underlying device. The Implementation Log Information is filled out by the automation tool to describe any overrides and command results or failures.

Let us now consider the above three requirements of ACEML and their interdependencies. This is best illustrated by examining the process and lifecycle of an ACEML described compliance document.

Figure: Lifecycle of an ACEML File

ACEML must be well organized, simple and concise. If ACEML attempts to capture all possible directions and situations, it will grow to be unusable. The following is the first-blush at the aceml xml. The job of the ACE-WG will be to fully describe this XML and the compliance content directives.

ACE Content Directives

ACE Content Directives is the

<ACEML>
<Mapped-Rules>
<Group name="User">
<Pre-requisites/>
<Attribute identifier="Password_len" selected="True">
<Value type="Numeric">
<Lower-bound>8</Lower-bound>
<Upper-bound>8</Upper-bound>
</Value>
<Satisfies>
<Standard name="PCI" version="1.0" date="Sept 10, 2008"
reference="URI"/>
</Satisfies>
<Conformant>
<Standard name="PCI" version="1.0" date="Sept 10, 2008"
reference="URI"/>
</Conformant>
<Platform name="AIX" version="6.1.0.0">
<Command>/usr/bin/chusattr</command>
<Arguments>-len=8</Arguments>
<Environment</Environment>
<Pre-requisites/>
</Platform>
<Platform vendor="Cisco" name="LINUX" version="1.2.3.4" applicable="False">
<Command/>
<Arguments/>
<Environment/>
</Platform>
</Attribute>
</Group>
<Group name="User1" extends"User">
<Pre-requisites/>
<Attribute identifier="Password_age" weight="1.0" selected="True">
<Value type="Numeric">
<Lower-bound>8</Lower-bound>
<Upper-bound>8</Upper-bound>
</Value>
<Platform name="AIX" version="6.1.0.0">
<Command>/usr/bin/chusattr</command>
<Arguments</Arguments>
<Environment</Environment>
<Pre-requisites/>
</Platform>
</Attribute>
</Group>
</Mapped-Rules>
</ACEML>

<ACEML>
<Mapped-Rules>
<Group name="User">
<Pre-requisites/>
<Attribute identifier="Password_len" selected="True">
<Value type="Numeric">
<Lower-bound>8</Lower-bound>
<Upper-bound>8</Upper-bound>
</Value>
<Conflicts>PCI</Conflicts>
<Matches>COBIT</Matches>
<Platform name="AIX" version="6.1.0.0">
<Command>/usr/bin/chusattr</command>
<Arguments>-len=8</Arguments>
<Environment</Environment>
<Pre-requisites/>
</Platform>
<Platform vendor="Cisco" name="LINUX" version="1.2.3.4" applicable="False">
<Command/>
<Arguments/>
<Environment/>
</Platform>
</Attribute>
</Group>
<Group name="User1" extends"User">
<Pre-requisites/>
<Attribute identifier="Password_age" weight="1.0" selected="True">
<Value type="Numeric">
<Lower-bound>8</Lower-bound>
<Upper-bound>8</Upper-bound>
</Value>
<Platform name="AIX" version="6.1.0.0">
<Command>/usr/bin/chusattr</command>
<Arguments</Arguments>
<Environment</Environment>
<Pre-requisites/>
</Platform>
</Attribute>
</Group>
</Mapped-Rules>
</ACEML>

Benefits

The two primary beneficiaries of the Automated Compliance Expert standard are: compliance organizations and the end users obligated to meet these standards.

Benefit to Compliance Organizations

The compliance organizations will be able to accurately and succinctly describe many of their configuration and IT management requirements. This will eliminate ambiguity in written compliance documents. It will reduce audit time through automated report generation and monitoring.

Below is a list of such Compliance Organizationswho might benefit from the ACE Standard.

TCG
PCI
NIST
ISO
COBIT

Benefit to End Users

The benefit to the end user will be the reduction of time and money needed to configure IT devices in order to meet regulatory compliance mandates. In the case of the SOX law and COBIT Compliance, this is any publicly traded US company. In the case of PCI-DSS compliance, this is any company that conducts transactions with the Payment Card Industry.

Expected Resources

This standard is being submitted by Platinum Member IBM under the Fast Track Standards Process and will require typical resources from The Open Group for such a standard. Shawn Mullen from IBM will chair this working group.

The success of any standard requires participation from all groups which will use and benefit from the standard. The groupswhich ACE will likely attract interest fromcan be categorized as follows.

Compliance Organizations which will use ACE to concisely define their regulatory compliance requirements.
Software Providers which will produce applications that can read ACE described compliance requirements and automate the implementation on computer systems.
End Users who will be able to automate their system configuration, monitoring and auditing in accordance with their compliance requirements.
Other Standards Organizations with similar interest will be able to leverage the ACE standard to enable and enhance their current or future efforts and goals. We are not aware of any other standards work that speaks to goals of the ACE standard. However, there is Standards with similar interests. Collaboration with these groups will be mutually beneficial.

Compliance Organizations

The following compliance organizations must be contacted and offered inclusion in this process:

Payment Card Industry
Payment Card Industry – Data Security Standard.
COBIT
COBIT 4.0 as it relates to Sarbanes-Oxley Act of 2002.
ISO
ISO 27001:2005 Information technology – Security techniques – Information security management systems – Requirements.
NIST – National Institute of Standards and Technology
Including but not limited to:
NIST Special Publication 800-53 Recommended Security Controls for the Federal Information Systems.
XCCDF – The Extensible Configuration Checklist Description Format.
Federal Information Security Management Act.[2]

Software Providers

There is a broad set of software providers that might have interest in contributing to this standard with the goal of developing applications that can aid in the automatic configuration, monitoring and audit report generation based on compliance regulations written within the ACE standard. This list may include companies such as: Hewlett-Packard, IBM, Raytheon, SAP, Sun Microsystems, and Symantec to name a few. It is also envisioned that open source security groups such as Bastille[3] could also provide enabling applications.

End Users

The end users which will benefit from this standard is any organization which is required to meet regulatory compliance IT governance or security. This list may include: Allied Irish Bank, American Express, AT&T, Asahi Techneion Co., Austin Energy, Eli Lilly, Boeing, Toyota, to name a few.

Other Standards Organizations

There are other Standards Organizations which should be exposed to the ACE-WG goals and specifications. From these contacts the level of collaboration on the current ACE standard can be determined. Also, there may be interest in follow-on work or cross reference with other standard specifications.

An example of such Standard Organizations are:

OASIS
Including but not limited to:
WS-Security.
SAML.
NIST– National Institute of Standards and Technology
Including but not limited to:
Security Content Automation Protocol[4].
Security Configuration Checklists Program for IT Products[5].
Trusted Computing Group
Including but not limited to:
Server Specific Specifications.
Trusted Network Connect.
Trusted Platform Module.

Roadmap and Timelines

The ACE-WG inauguration of this ACE-WG is planned from October 20-24, 20th Enterprise Architecture Practitioners Conference. These face-to-face working group sessions will lay the ground work for follow-up individual work and regular conference calls.

The timeline goals may be refined over time, but in general it is proposed that the ACE XML schema be complete by the second quarter of 2009 and the initial compliance content directive will be completed in the forth quarter of 2009.

Working Group Administrative Information

This working group will be chaired by Shawn Mullen of IBM. This standard is being submitted by Platinum Member IBM under the Fast Track Standards Process.

Appendix A

ACEML : Stands for Automated Compliance Enablement Markup Language. This will be the root element.

Standard: This element contains the security attributes policy for that standard. The attributes of this element identifies the actual standard document that this xml represents.

Properties / Types / Remarks
name / String / Used to store the name of the standard
Version / String / Specifies the version number of the standard.
Date / Date (Mon-dd, yyyy) / Version of the standard
Reference / URI / Indicates the location of the standard; Optional

Contains : Group+

Group : Contains the list of security attributes pertaining to this group.

Properties / Types / Remarks
name / String / Used to store the name of group
Extends / String / List of groups from where the attributes are extended. See the note1.

Note1: If the group that extends from other group, has the same attributes, those attributes take precedence… that is, it overrides the values specified in the base group. If it contains new attributes, then it should be appended. However, there is no way to remove any of the security attributes that got extended.

Pre-requisites : Contains the list of groups that should be enforced before enforcing this group. Optional.

Attribute : This element specifies security properties of an attribute.

Properties / Types / Remarks
Identifier / String / Open Group standardized attribute identifier
Selected / Boolean / Specifies whether the administrator chose to enforce this attribute or not. Optional. Default is True

Value : This element specifies the security value for an attribute.

Properties / Types / Remarks
Type / String / Options are : Numeric, String, Date & Boolean

Lower-bound: This element will be used only if type of Value is “numeric”. This element specifies the lowest acceptable value.

Upper-bound: This element will be used only if type of Value is “numeric”. This element specifies the maximum acceptable value.

Choices : This element should be used only if the type of value is “String”. The individual strings should be enclosed in double quotes and each choice should be delimited using a comma separator.

An example:

<ACEML>

<Pre-requisites/>

<Lower-bound>8</Lower-bound>

<Upper-bound>8</Upper-bound>

</Value>

</Attribute>

<Choices>”Admin”, “User”, “Manager”</Choices>

</Value>

</Attribute>

</Group>

<Pre-requisites/>

<Lower-bound>8</Lower-bound>

<Upper-bound>8</Upper-bound>

</Value>

</Attribute>

</Group>

</Standard>

</ACEML>

mapped rules will be :

ACEML

<Mapped-Rules>

<Pre-requisites/>

<Lower-bound>8</Lower-bound>

<Upper-bound>8</Upper-bound>

</Value>

<Standard name="PCI" version="1.0" date="Sept 10, 2008"

reference="URI"/

</Satisfies>

<Standard name="PCI" version="1.0" date="Sept 10, 2008"

reference="URI"/

</Conformant>

<Command>/usr/bin/chusattr</command>

<Environment</Environment>

<Pre-requisites/>

</Platform>

</Platform>

</Attribute>

</Group>

<Pre-requisites/>

<Lower-bound>8</Lower-bound>

<Upper-bound>8</Upper-bound>

</Value>

<Command>/usr/bin/chusattr</command>

<Arguments</Arguments>

<Environment</Environment>

<Pre-requisites/>

</Platform>

</Attribute>

</Group>

</Mapped-Rules>

</ACEML>

Automated Compliance Expert – Working Group

Confidential

[1] Payment Card Industry (PCI) Data Security Standard; section 8.5.10.

[2]

[3]

[4]

[5]