An It Risk & Compliance Management System

An IT Risk & Compliance Management System: Unraveling the complexities of IT Risk & Compliance to reveal the value

Steven Schlarman June, 2007

© 2007 All rights reserved. Materials contained in this document are confidential. No part of this publication may be shared, reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without prior written permission of the publisher.

Introduction Compliance is everywhere these days. From the boardroom to the data center, compliance activities are taking a considerable chunk out of many people’s days. Whether it is reacting to a new industry regulation or meeting the demands of a business partner or customer, companies have found themselves balancing precariously between business progress and control management. Managing the spending on compliance activities and meeting regulatory and business requirements has become a continual battle. In the United States, while the Sarbanes Oxley efforts may be leveling out, new regulations and continually changing business requirements are still forcing organizations to contemplate controls in every part of the business. Globally, one of the key factors affecting almost every industry and business sector is the continued increase of regulations. Regulatory impacts have become so high profile that in PricewaterhouseCoopers’ 2007 Annual CEO survey, overregulation was cited as the number one risk to growth by CEOs participating in the survey. When it comes to Information Technology, regulatory issues continue to impact CIOs. As cited in the 2005 Harvey/Nash CIO survey, another survey sponsored by PwC, CIOs reported a significant portion of IT funding has been funneled into compliance activities; security is still a major focus; and more strategic vision and connection to the business is key to the success of the IT function. Interestingly the top four objectives for the CIOs in this survey were, in order: 1) Security; 2) IT Governance; 3) Simplification of IT environment, and 4) IT support of compliance regulations. All four of these objectives are intimately linked. Taken in concert with the facts that a considerable amount of time and money has already been spent on compliance and CIOs wish to be more strategically aligned with the business, these priorities converge on the strategic goal of deploying an infrastructure with an inherent, built-in “IT Compliance and Risk Management” culture. The Different Views of Risk and Compliance The implementation for a consistently managed controls environment, backed by an effective and cost conscious compliance program, takes on several slants when looked at through the various lenses within the company. Executives and board members are concerned with liability and overall governance. Reducing overall corporate risks and managing the bottom line is at the forefront. In response, Chief Risk Officers (CRO) or equivalents are focused on putting together the plan to manage risk and compliance throughout the organization. Governance, controls, compliance measurement and cost effectiveness are key to their objectives. Finally, when the “Compliance Puzzle” reaches IT, the IT leadership (CIO, CISO, etc.) are looking to juggle both business progress – “get systems and applications up quickly” – and compliance – “get those systems up securely”. When the CIO looks at his organization, he sees a collection of people working through many different processes utilizing many different technological enablers. He also sees the external forces continually pulling in different directions – compliance and business progress. Managing this sometimes conflicting set of goals within the complex arena of IT poses a significant challenge to the CIO of this era. At the core of this issue is “How do regulatory and business requirements impact the technology and the organization supporting the technology?” CIOs faced with this question must confront the problem via several angles. The first though is the purely technology focused view. Since the technology itself is looked upon as the ultimate enabler and enforcer of controls, it is necessary to gain an understanding on where the technology fits into the grand scheme of the controls environment. In other words, how does one rationalize the implementation of controls and leverage the technology to its fullest potential? Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

The Bottom Up Approach One way to approach this is the “Bottom up” approach. This entails looking at different technologies (already in place or on the “wish” list) and validating or justifying the technology in the context of specific control requirements. The technology vendor community is especially good at helping with this. Vendors analyze what their individual technology can do and then tie these functions back to a regulatory requirement. The result is an extremely high “noise” level within the technology vendor sector with “Compliance” as the focus of every other marketing pitch. However, the vendors are partially right. Those solutions have every right to claim a piece of the “compliance puzzle”. Many times IT organizations are forced to look at individual technologies in this context to justify specific expenditures or validate the existing security and control environment. This isn’t necessarily a bad way to look at a technology and many “control oriented” technologies need to be evaluated in this manner. However, using this approach as the sole method leaves much to be desired since the bottom up approach leads to multiple gaps including non-managed systems, process and people controls and the lack of a consolidated view of compliance. As an example:

This illustration shows a very simple relationship to specific requirements in the Payment Card Industry Data Security Standard (PCI). The point is that specific technologies, and features and functions within the technology, can be related to specific requirements. This can be done for a variety of tools and technologies. This is a valid “justification” of the relationship between a compliance oriented tool and individual regulatory requirements. Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

However, this approach leaves some questions on the table: • • •

What does the organization do for technologies (platforms, systems applications) that are not addressed by these individual technologies? How are control requirements for processes (non-technology controls) defined and monitored? How does the organization communicate responsibilities to personnel?

And most importantly: • How much time does it take to get a consolidated view of compliance with each tool enforcing, enabling and/or monitoring different controls? The Top Down Approach Another approach is to take the Top Down approach by identifying supporting technologies for specific regulatory or business requirements. This is a common way companies identify specific areas of technologies that are needed. Individual requirements determine what controls must be instituted and appropriate technologies are then introduced into the environment. This requires the organization to focus on one requirement at a time. Again, PCI is an excellent example of how IT organizations deal with specific regulations. PCI has four specific requirements on system accounts, securing systems, monitoring and testing that could be addressed by a mix of technologies. Host-based, network-based and a consolidated management system could be used to help an organization meet these requirements. For instance: • • •

A host based vulnerability management tool could be used to address host based configurations such as default accounts, password configurations and file system controls. A vulnerability scanner could be used to identify network based vulnerabilities such as open network ports, remote vulnerabilities and unauthorized services. An event management system could be used to consolidate logs and identify compliance related events and issues.

Each of these technologies perform a specific compliance task related to PCI requirements. Additionally, each technology provides reporting around the specific control area within its scope.

Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

The top down approach begins building a logical chain and focuses on one regulation at a time. Looking at one regulation in this view can reveal several interesting points within the control architecture. Technology overlap where multiple tools are selected for similar control areas can be discovered. Gaps where technology could be used to enforce and enable controls can be discerned. However, in addition to the questions raised from the “bottom up” approach, the organization is faced with more dilemmas: • Are these the right technologies and controls to meet requirements? • Are the controls within the technology enablers active and configured properly? • How can I connect the configuration of the compliance tool to the compliance driver? And again, most importantly: • Where can I get a consolidated view of my compliance?

Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

The Compliance to Technology Map Regardless of the approach - a top down or bottom up approach – the results look something like this. Looking at PCI across all 12 control requirements and the wide range of technologies the regulation could affect, a depiction might be as follows.

This is not an exhaustive list of the technologies or the mappings but a representative conceptual depiction taking various tools from across the market. There seems to be a wide gap between a regulatory requirement and the actual technology itself. For instance, while the regulation states “Restrict access to data by business need-to-know”, the technologies deployed include a variety of user provisioning, access control and entitlement functions. Where does the connection to the individual controls in the environment exist and how does one rationalize the individual functions in the technology against the requirements? Secondly, where do the process and people controls manifest themselves in the environment? The major consideration though is if this represents one regulation, how does the organization rationalize the technology infrastructure against multiple regulations? The gaps and overlaps become increasingly difficult to manage. This is exacerbated by the fact that many regulations are not prescriptive in control requirements and rely on individual interpretation. Using PCI as an example here makes the mapping at least somewhat straightforward. Looking at other regulatory and business drivers, the relationships are not as easily identified. Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

Multiple Regulations One way to clarify this mess is to begin dissecting this confusing mix of requirements into Technology functions or Control areas. This helps focus the requirements into the context of the technology function.

The ability to segment control areas into domains and then understand the relationships between the control requirements and the technologies reduces the complexity. These various controls eventually collapse into a “cloud” of requirements. Requirements have to be organized to properly articulate the connection between regulations and the underlying technologies. These requirements generally will manifest into Policies, Standards or Procedures specific to the functional area. Companies begin to develop policies to communicate requirements, drive those policies into more granular standards and eventually to specific controls. The key to this process is to maintain the connection between the reason behind the control and the control itself. Note though, that these relationships must be two-way. Not only should the requirements manifest themselves into policy to drive control implementations, but a strategic way to monitor and measure the control is also fundamental to the process. Understanding what needs to be done is only one piece. The organization must be able to articulate the current state of the enterprise in the terms of the requirements to demonstrate compliance.

Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

The Risk & Compliance Management System This entire discussion is a long way to get to a simple concept – a system to manage compliance requirements and report current state within the organization. This system is not necessarily one single platform but an integrated approach at meeting the needs of the compliance program. As a part of this system, it is necessary to identify the current processes organizations are using to meet compliance concerns. The “bottom up” approach, the “top down” approach and the technology mapping all serve as avenues to compliance. However, once an organization matures to the point where it is managing multiple regulations and compliance requirements, these approaches begin to break down under the sheer weight of the complexities involved. An intermediary process and system are necessary to strategically meet the shifting requirements of any industry. When compliance is viewed as a whole, the technology is only one portion of the equation. People and processes are just as critical to the compliance approach. While the technology is enforcing or implementing controls, the processes around the technology are just as important. Additionally, many control areas could be completely process-oriented. Roles and Responsibilities are also critical to compliance requirements.

IT compliance depends on the classical “two sides of the same coin” – 1) Design of Controls and 2) Measurement and monitoring of Controls. A Risk & Compliance Management System at its core is the backbone of the many derivative and ancillary processes involved with defining controls and measurement and monitoring. Any system that is positioned to manage these two components should have the capability to support these processes. The system should support and facilitate both sides of the compliance equation.

Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

Without a balanced approach, many cracks can develop in the fabric of the compliance infrastructure. • Detailed and well designed controls without a supporting monitoring process will languish as unenforced doctrine. • Heavily monitored environments with poor control design will be resource laden, costly and result in high levels of non-compliance due to improper communication and requirement setting. Both of these scenarios result in significantly higher costs, complexities and inconsistencies in the IT environment and little strategic value to the organization. A Risk & Compliance Management System should have the following attributes: Design of Controls • Enterprise wide - The system should be the authoritative source of policy, standards and controls that can clearly communicate requirements across the enterprise. While there will definitely be the need for localized procedures, the basic control design, as manifested in policy and standards, should be consistent. Additionally, control baselines should be utilized to leverage knowledge across the organization, build consistency and reduce complexity in IT systems. • Structured data – The information should be stored in a manner where relationships can be built and managed. In other words, cumbersome documents and spreadsheets with little connection make the information less usable and management an administrative nightmare. Content that is in manageable chunks can be rationalized, mapped, connected and managed on a much more consistent basis. • Collaborative – The system should have the ability to workflow the design of controls. This includes the ability to create content, provide approval and versioning of the content and keep the knowledgebase up-to-date in a multi-functional manner. Input from varied groups internal and external to IT will be necessary to get the right buy-in for the setting of policy. • People, Process and Technology “aware” – The system should have the ability to handle multiple types of controls – not just soft (process) or hard (technical configuration) controls. As noted, a true compliance program must have a balanced approach and understand and address each of these components. • Communication vehicle – Since the core executors of any control program, regardless of how much technology is used, are the people in the IT department, it is imperative for the system be not only a management tool but a communication tool. The information must be easy to use and user focused to get the right information to the right people. • Multi-regulatory “aware” – The changing demands placed on IT forces the organization to implement a flexible structure to meet new regulations and requirements. The system should be able to adapt and provide a “mult-regulatory” view. Monitoring and Measurement of Controls • Business context – The ultimate goal, and really the only reason to be spending so much time on compliance, is the ability to connect the current state of the organization to the specific controls. In other words, if you the organization cannot connect the compliance state to the stated requirements without an “interpretation gap”. • People, Process and Technology measurement – The people, process and technology paradigm has to continue through compliance measurement. This Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

• •

•

• •

requires the system to have the ability to gather data from varied sources including technology platforms such as those listed above as well as from people. Compliance correlation – Given the influx of compliance data from multiple sources, the ability to blend the data sources to create cohesive view is the ultimate goal of the system. Risk and business aware – Risk and business awareness is a key benefit of a compliance management system. The ability to prioritize and value assets to determine resource allocation, prioritize remediation efforts and give overall visibility into the operational state are critical factors to successful compliance management. Remediation and Exception handling – Control failures through “fixing” or “accepting” risks is going to be part and parcel of the compliance process. Acknowledging the fact that the environment cannot be 100% compliant, and the ability to manage the gaps in a prudent and intelligent manner, must be part of the infrastructure. Context reporting – Compliance means different things to different people and therefore requires reporting for specific roles in the organization. Executive and operational views into the data provide the right reports for the right person. Minimal operational impact – Leveraging existing infrastructure without huge reinvestment or re-tooling is necessary for success. Organizations have already spent millions of dollars on infrastructures in layering on technologies like those described above. A layer between the controls design and the technologies themselves means the ability to abstract controls and report on the current state with little operational impact.

Use Cases The following table represents just a few of the use cases of the Compliance Management System as it pertains to technical controls. As illustrated, one requirement can branch into multiple Standards, Technologies, Controls and Configurations. External Requirement Track and monitor all access to network resources and cardholder data (PCI)

Internal Standards

Technology

Controls

Configuration

Access to critical hosts must be monitored on critical systems.

Host operating system (measured directly on the host)

Audit failed login attempts.

Configuration on local system that logs failed login attempts.

Host operating system (measured via a host based assessment technology)

Creation of local accounts

Configuration on local system that logs creation of accounts.

User provisioning technology

Creation of user accounts.

Privileged access to database tables must be logged.

Database

Audit access to the database by privileged accounts.

Events related to access of critical data must be reviewed.

Security Event Management system

Review failed login attempts.

Event rule monitoring systems for failed logins.

Identify brute force attacks.

Event rule monitoring for brute force attacks.

Brabeion Software Corporation

Configuration limiting ability to create accounts is restricted to appropriate individuals. Configuration within database that logs access by privileged accounts.

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

Taking one step further into People and Process controls reveals an even broader coverage of controls. External Requirement

Internal Standards

Control Area

Controls

Configuration

Restrict access to data by business need-to-know (PCI)

Command line access must be restricted to authorized personnel.

Host operating system

Restrict access to local command line and shell accounts.

Configuration of shell access for user accounts.

User provisioning technology

Creation of user accounts.

Configuration limiting ability to create accounts is restricted to appropriate individuals.

User registration process

Access request forms must be signed by the application owner.

Security Event Management system

Monitor user creation event on critical systems.

Application Owner

Review user account lists once a quarter.

Access to critical applications must be approved by the information owner of the system.

Application owners must review user lists on a quarterly basis.

Event rule monitoring for user creation on critical systems.

Conclusion An IT Risk & Compliance management program needs a foundation to build on and a backbone to support and connect the many facets of the process. Traditional views consistently agree that internal policies must be the foundation for a successful program. A Risk & Compliance Management System takes those policies, wraps a management process around them and extends the impact into the entire organization by integrating into the infrastructure for continued “audit” and compliance visibility.

Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

As illustrated, RCMS becomes the center of the IT compliance universe. The concept is not to perform or enforce every aspect of compliance but define and measure processes, assist in the definition of controlled technology architectures and influence people’s actions. The definition of controls with accompanied balanced measurement offers a strategic value to the organization by: • Clearly articulating expectations to employees; • Delivering control information in an actionable format; • Supporting the various processes and roles with the organization; • Closing the loop on setting expectations with measurable results. The role of the RCMS is a major driver for compliance program management but more importantly becomes the central focal point to articulate the program.

Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]

Author: Steve Schlarman, Chief Compliance Strategist, CISSP, CISM Brabeion Software Mr. Schlarman brings deep compliance, security and audit expertise to Brabeion Software. As Chief Compliance Strategist, Mr. Schlarman is responsible for product design and architecture, industry input, thought leadership and content management. Prior to joining Brabeion, Steve was a Director in PricewaterhouseCoopers’ Advisory Practice focusing exclusively on information security and compliance consulting and auditing. During his 8+ years at PwC, he led a wide range of security and compliance engagements including security strategy, security policy development, IT audits, penetration studies, Sarbanes-Oxley preparation and computer crime investigation. In 1998, he became the lead developer of PwC’s original Enterprise Security Architecture System (ESAS) and led product management until Brabeion acquired ESAS in 2005. Steve served as PricewaterhouseCoopers’ global Subject Matter Expert on Enterprise Security Architecture and Security Policy. He has published many articles on key topics in security, and was a primary developer of PricewaterhouseCoopers' methodologies on Enterprise Security Architecture and security policy development. Prior to PwC, Mr. Schlarman had operational roles in information systems at the Missouri State Highway Patrol and A.G. Edwards. He has worked in application development and support, computer operations, network administration and production control. Mr. Schlarman received a Bachelors of Science degree in Mathematical Sciences from Southern Illinois University-Edwardsville. He is a member of ISACA and ISSA and holds both the CISSP and CISM certifications.

* The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Brabeion Software Corporation

· 1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 · 703.752.9300 www.brabeion.com · [email protected]