an it risk & compliance management system

8/14/2019 An IT Risk & Compliance Management System

1/13

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

Steven SchlarmanJune, 2007

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


2/13

Brabeion Software Corporation1943 Isaac Newton Sq., Suite 150, Reston, VA 20190 703.752.9300www.brabeion.com [email protected]

IntroductionCompliance is everywhere these days. From the boardroom to the data center, compliance activities aretaking a considerable chunk out of many peoples days. Whether it is reacting to a new industry regulationor meeting the demands of a business partner or customer, companies have found themselves balancingprecariously between business progress and control management. Managing the spending oncompliance 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 andcontinually changing business requirements are still forcing organizations to contemplate controls in everypart of the business. Globally, one of the key factors affecting almost every industry and business sectoris the continued increase of regulations. Regulatory impacts have become so high profile that inPricewaterhouseCoopers 2007 Annual CEO survey, overregulation was cited as the number one risk togrowth by CEOs participating in the survey.

When it comes to Information Technology, regulatory issues continue to impact CIOs. As cited in the2005 Harvey/Nash CIO survey, another survey sponsored by PwC, CIOs reported a significant portion ofIT 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 fourobjectives for the CIOs in this survey were, in order:

1) Security;2) IT Governance;3) Simplification of IT environment, and4) IT support of compliance regulations.

All four of these objectives are intimately linked. Taken in concert with the facts that a considerableamount of time and money has already been spent on compliance and CIOs wish to be morestrategically aligned with the business, these priorities converge on the strategic goal of deploying aninfrastructure with an inherent, built-in IT Compliance and Risk Management culture.

The Different Views of Risk and ComplianceThe implementation for a consistently managed controls environment, backed by an effective and costconscious compliance program, takes on several slants when looked at through the various lenses withinthe 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 RiskOfficers (CRO) or equivalents are focused on putting together the plan to manage risk and compliancethroughout the organization. Governance, controls, compliance measurement and cost effectiveness arekey 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 andcompliance get those systems up securely.

When the CIO looks at his organization, he sees a collection of people working through many differentprocesses utilizing many different technological enablers. He also sees the external forces continually

pulling in different directions compliance and business progress. Managing this sometimes conflictingset 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 theorganization supporting the technology? CIOs faced with this question must confront the problem viaseveral angles. The first though is the purely technology focused view. Since the technology itself islooked upon as the ultimate enabler and enforcer of controls, it is necessary to gain an understanding onwhere the technology fits into the grand scheme of the controls environment. In other words, how doesone rationalize the implementation of controls and leverage the technology to its fullest potential?


3/13


The Bottom Up ApproachOne 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 specificcontrol requirements. The technology vendor community is especially good at helping with this. Vendorsanalyze what their individual technology can do and then tie these functions back to a regulatoryrequirement. The result is an extremely high noise level within the technology vendor sector withCompliance 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 specificexpenditures or validate the existing security and control environment. This isnt necessarily a bad way tolook 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 upapproach leads to multiple gaps including non-managed systems, process and people controls and thelack of a consolidated view of compliance.

As an example:

This illustration shows a very simple relationship to specific requirements in the Payment Card IndustryData Security Standard (PCI). The point is that specific technologies, and features and functions withinthe technology, can be related to specific requirements. This can be done for a variety of tools andtechnologies. This is a valid justification of the relationship between a compliance oriented tool andindividual regulatory requirements.


4/13


However, this approach leaves some questions on the table:

What does the organization do for technologies (platforms, systems applications) that are notaddressed 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 ApproachAnother 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 oftechnologies that are needed. Individual requirements determine what controls must be instituted andappropriate technologies are then introduced into the environment. This requires the organization tofocus on one requirement at a time.

Again, PCI is an excellent example of how IT organizations deal with specific regulations. PCI has fourspecific requirements on system accounts, securing systems, monitoring and testing that could beaddressed by a mix of technologies. Host-based, network-based and a consolidated managementsystem 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 configurationssuch 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.


5/13


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. Gapswhere technology could be used to enforce and enable controls can be discerned. However, in additionto 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?


6/13


The Compliance to Technology MapRegardless 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 couldaffect, a depiction might be as follows.

This is not an exhaustive list of the technologies or the mappings but a representative conceptualdepiction taking various tools from across the market. There seems to be a wide gap between aregulatory requirement and the actual technology itself. For instance, while the regulation states Restrictaccess to data by business need-to-know, the technologies deployed include a variety of userprovisioning, access control and entitlement functions. Where does the connection to the individualcontrols 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 inthe environment?

The major consideration though is if this represents one regulation, how does the organization rationalizethe technology infrastructure against multiple regulations? The gaps and overlaps become increasinglydifficult to manage. This is exacerbated by the fact that many regulations are not prescriptive in controlrequirements and rely on individual interpretation. Using PCI as an example here makes the mapping atleast somewhat straightforward. Looking at other regulatory and business drivers, the relationships arenot as easily identified.


7/13


Multiple RegulationsOne way to clarify this mess is to begin dissecting this confusing mix of requirements into Technologyfunctions 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 thecontrol requirements and the technologies reduces the complexity.

These various controls eventually collapse into a cloud of requirements. Requirements have to beorganized to properly articulate the connection between regulations and the underlying technologies.These requirements generally will manifest into Policies, Standards or Procedures specific to thefunctional 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 maintainthe 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 manifestthemselves into policy to drive control implementations, but a strategic way to monitor and measure thecontrol is also fundamental to the process. Understanding what needs to be done is only one piece. Theorganization must be able to articulate the current state of the enterprise in the terms of the requirementsto demonstrate compliance.


8/13


The Risk & Compliance Management SystemThis entire discussion is a long way to get to a simple concept a system to manage compliancerequirements and report current state within the organization. This system is not necessarily one singleplatform 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 meetcompliance concerns. The bottom up approach, the top down approach and the technology mappingall serve as avenues to compliance. However, once an organization matures to the point where it ismanaging multiple regulations and compliance requirements, these approaches begin to break downunder the sheer weight of the complexities involved. An intermediary process and system are necessaryto 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 andprocesses are just as critical to the compliance approach. While the technology is enforcing or implementingcontrols, the processes around the technology are just as important. Additionally, many control areas couldbe 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 thebackbone of the many derivative and ancillary processes involved with defining controls andmeasurement and monitoring. Any system that is positioned to manage these two components shouldhave the capability to support these processes. The system should support and facilitate both sides ofthe compliance equation.


9/13


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 un-

enforced 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 ITenvironment 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. Whilethere will definitely be the need for localized procedures, the basic control design, asmanifested in policy and standards, should be consistent. Additionally, control

baselines should be utilized to leverage knowledge across the organization, buildconsistency and reduce complexity in IT systems.

Structured data The information should be stored in a manner where relationshipscan be built and managed. In other words, cumbersome documents andspreadsheets with little connection make the information less usable andmanagement an administrative nightmare. Content that is in manageable chunkscan be rationalized, mapped, connected and managed on a much more consistentbasis.

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 thecontent and keep the knowledgebase up-to-date in a multi-functional manner. Inputfrom varied groups internal and external to IT will be necessary to get the right buy-infor the setting of policy.

People, Process and Technology aware The system should have the ability tohandle multiple types of controls not just soft (process) or hard (technicalconfiguration) controls. As noted, a true compliance program must have a balancedapproach 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 isimperative 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 tothe right people.

Multi-regulatory aware The changing demands placed on IT forces theorganization to implement a flexible structure to meet new regulations andrequirements. The system should be able to adapt and provide a mult-regulatoryview.

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 theorganization to the specific controls. In other words, if you the organization cannotconnect the compliance state to the stated requirements without an interpretationgap.

People, Process and Technology measurement The people, process andtechnology paradigm has to continue through compliance measurement. This


10/13


requires the system to have the ability to gather data from varied sources includingtechnology 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 ofthe system.

Risk and business aware Risk and business awareness is a key benefit of acompliance management system. The ability to prioritize and value assets todetermine resource allocation, prioritize remediation efforts and give overall visibilityinto the operational state are critical factors to successful compliance management.

Remediation and Exception handling Control failures through fixing or acceptingrisks is going to be part and parcel of the compliance process. Acknowledging thefact that the environment cannot be 100% compliant, and the ability to manage thegaps in a prudent and intelligent manner, must be part of the infrastructure.

Context reporting Compliance means different things to different people andtherefore requires reporting for specific roles in the organization. Executive andoperational views into the data provide the right reports for the right person.

Minimal operational impact Leveraging existing infrastructure without huge re-investment or re-tooling is necessary for success. Organizations have already spentmillions of dollars on infrastructures in layering on technologies like those describedabove. A layer between the controls design and the technologies themselves meansthe ability to abstract controls and report on the current state with little operationalimpact.

Use CasesThe following table represents just a few of the use cases of the Compliance Management System as itpertains to technical controls. As illustrated, one requirement can branch into multiple Standards,Technologies, Controls and Configurations.

External Requirement Internal Standards Technology Controls Configuration

Track and monitor allaccess to networkresources and cardholder

data (PCI)

Access to criticalhosts must bemonitored on

critical systems.

Host operatingsystem (measureddirectly on the

host)

Audit failed loginattempts.

Configuration on localsystem that logsfailed login attempts.

Host operating

system (measuredvia a host basedassessment

technology)

Creation of local

accounts

Configuration on local

system that logscreation of accounts.

User provisioningtechnology

Creation of useraccounts.

Configuration limitingability to create

accounts is restrictedto appropriateindividuals.

Privileged accessto database tablesmust be logged.

DatabaseAudit access to thedatabase byprivileged accounts.

Configuration withindatabase that logsaccess by privileged

accounts.

Events related toaccess of critical

data must bereviewed.

Security EventManagement

system

Review failed loginattempts.

Event rule monitoringsystems for failed

logins.

Identify brute force

attacks.

Event rule monitoring

for brute forceattacks.


11/13


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

ExternalRequirement

Internal Standards Control Area Controls Configuration

Restrict access todata by businessneed-to-know (PCI)

Command line accessmust be restricted toauthorized personnel.

Host operatingsystem

Restrict access tolocal command lineand shell accounts.

Configuration of shellaccess for useraccounts.

Userprovisioningtechnology

Creation of useraccounts.

Configuration limitingability to create

accounts is restricted toappropriate individuals.

Access to criticalapplications must be

approved by theinformation owner of thesystem.

User registration

process

Access request formsmust be signed by the

application owner.

Security EventManagementsystem

Monitor user creationevent on criticalsystems.

Event rule monitoringfor user creation oncritical systems.

Application owners mustreview user lists on aquarterly basis.

ApplicationOwner

Review user accountlists once a quarter.

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 internalpolicies must be the foundation for a successful program. A Risk & Compliance Management Systemtakes those policies, wraps a management process around them and extends the impact into the entireorganization by integrating into the infrastructure for continued audit and compliance visibility.


12/13


As illustrated, RCMS becomes the center of the IT compliance universe. The concept is not toperform or enforce every aspect of compliance but define and measure processes, assist in the definitionof controlled technology architectures and influence peoples actions. The definition of controls withaccompanied 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 importantlybecomes the central focal point to articulate the program.


13/13


Author:

Steve Schlarman, Chief Compliance Strategist, CISSP, CISMBrabeion Software

Mr. Schlarman brings deep compliance, security and audit expertise to Brabeion Software. As ChiefCompliance Strategist, Mr. Schlarman is responsible for product design andarchitecture, industry input, thought leadership and content management. Prior tojoining Brabeion, Steve was a Director in PricewaterhouseCoopers Advisory Practicefocusing exclusively on information security and compliance consulting and auditing.During his 8+ years at PwC, he led a wide range of security and complianceengagements including security strategy, security policy development, IT audits,penetration studies, Sarbanes-Oxley preparation and computer crime investigation. In1998, he became the lead developer of PwCs original Enterprise SecurityArchitecture 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, andwas a primary developer of PricewaterhouseCoopers' methodologies on Enterprise Security Architectureand security policy development.

Prior to PwC, Mr. Schlarman had operational roles in information systems at the Missouri State HighwayPatrol 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 inMathematical Sciences from Southern Illinois University-Edwardsville. He is a member of ISACA andISSA and holds both the CISSP and CISM certifications.

* The names of actual companies and products mentioned herein may be the trademarks of theirrespective owners.

an it risk & compliance management system

Documents