Compliance by Design: IT controls that work

By Chong Ee

In Compliance by Design, Chong Ee will show you how your organisation can benefit from becoming compliant with the relevant national and international standards. You will discover how integrating controls into your processes will improve your security, increase your productivity, save you time and money, and increase your profits.

• Language: English
• Publisher: itgovernance
• Release date: Sep 27, 2011
• ISBN: 9781849282970

Chong Ee

Chong Ee did not start out being an IT auditor; he became one after donning the hats of an IT management consultant and a business analyst. Over time, Chong worked on both sides: external auditing and in-house compliance. In 2012, he returned to systems implementation for cloud apps after eight years in Sarbanes–Oxley compliance. He has spoken at conferences hosted by the MIS Training Institute (MISTI), Information Systems Audit and Control Association (ISACA), Institute of Internal Auditors (IIA) and Society of Corporate Compliance and Ethics (SCCE), and has had articles published in the Internal Auditor magazine and ISACA and Information Systems Security Association (ISSA) journals. His first book, Compliance by Design: IT Controls that Work, was published by IT Governance Publishing in September 2011. Chong is an active Certified Information Systems Auditor (CISA) and Certified in the Governance of Enterprise IT (CGEIT).

Book preview

Resources

INTRODUCTION

Unraveling controls

For all the differences in opinion surrounding its implementation, one thing the Sarbanes-Oxley Act of 2002 (SOX) did was demystify the language of internal controls. What was once seen as the domain of audit, security and compliance personnel became common currency, whether amongst system developers and administrators, or management and reporting staff. When engaged in efforts to build or sustain controls however, it can be easy to become entangled in control-speak – manual versus automated controls, or those that comply with the recent Model Audit Rule (MAR), or the updated Payment Card Industry Data Security Standard (PCI DSS) – rather than uncovering the true underpinnings of good control design.

I invite you to embark on a journey to unravel the essence of IT controls. Along the way we will gather elements, parse out principles and weave together strategies that incorporate controls into the very fabric of every-day work. We will also look for telltale signs and ponder examples mirroring real-life scenarios.

To be sure, this is hard work beyond simply checking the box, or running a script. Unlike a traditional outside-looking-in approach that either captures external compliance demands or control frameworks and maps these as requirements within, this one emphasizes a fundamental grasp of contextual control elements and principles as the basis for developing effective and sustainable IT compliance strategies (see Figure 2).

Figure 2: A tale of two approaches

The rewards, though, can pay off, for those willing to roll up their sleeves in solving real-world riddles, such as:

•  Best-practice controls that feel implanted and out-of-sync with the local environment.

•  Recurring control failures, despite timely intervention and regular monitoring.

•  Targeted solutions that may appear counter-intuitive initially, but ultimately contribute towards security and compliance objectives.

Ways of seeing

How we look at controls is of fundamental importance and is a recurring theme throughout this book. Consider the following pitfalls of control myopia:

•  Intent on adopting a best practice internal control framework, an enterprise invests a disproportionate amount of time gaining consensus on controls that do not apply to its environment.

•  By focusing on compliance as an end in itself, key resources are caught in a perpetual firefighting loop, duplicating, and in some cases, contradicting efforts in other parts of the enterprise.

•  In embracing GRC, emphasis is placed on transposing existing control matrices from unstructured to structured data, rather than driving real changes in the manner technology functions and processes are governed within the enterprise.

Most of us are familiar with the optical illusion known as Rubin’s vase (see Figure 3). Developed by Danish psychologist, Edgar Rubin, around 1915, it illustrates the distinction our brain makes between figure and ground during visual perception. In looking at Rubin’s vase, do you see a vase, or two people facing each other? How we look at controls can be analogous to the way we view Rubin’s vase:

•  Do we focus on compliance as the subject, or are we able to take in other variables, such as performance, the white space surrounding the subject?

•  In thinking about the cost of non-compliance, do we merely focus on direct costs in recovering from a data breach, or paying penalties imposed by authorities? Are we able to see surrounding indirect and opportunity costs?

•  When revisiting the design and operating effectiveness of IT controls, have we been conditioned to watch for exceptions or deficiencies, rather than paying attention to the organization of control elements in the background?

Figure 3: Rubin’s vase

By trying on a fresh pair of eyes, wide-ranging real-world challenges, ranging from automating controls to complying on a shoestring, begin to take on a new significance in the clear light of day.

Unintended consequences

Pioneered by the late Dutch traffic engineer, Hans Monderman, in the Netherlands, and replicated in the United Kingdom, the naked street concept advocates the stripping of road signs, markings, and traffic lights at specific street junctions, forcing pedestrians and drivers alike to pay more attention to their immediate surroundings. Despite the relaxation of these commonplace controls, road deaths and accidents actually decreased.

Watching out for unexpected turns is another recurring theme in this book. In Chapter 1: People, we identify the chain of stakeholders participating in a process with an emphasis on system, a network of interconnections. In Chapter 4: Systems, we survey the geography of technology controls from an end-to-end process perspective.

Be prepared for surprises, both good and bad, in spite of the best of intentions. In the case of the naked street phenomenon, less can be more. In a different scenario, this time combining password complexity with existing password aging, maximum failed log-in and other controls, more can result in less, after factoring in negative externalities on usability and supporting processes.

Therein lays the challenge (and fun) in designing IT controls. Designed right, compliance becomes a by-product rather than a forced outcome.

Reading this book

The vocabulary of control design can be characterized by elements as building blocks, principles that govern the organization of elements, and strategies that incorporate the effective use of principles and elements in attaining and sustaining compliance. This book is structured as such, concluding with Part IV: Action (see Figure 4).

Figure 4: How this book is organized

You are highly encouraged to go with this narrative flow; by skipping ahead, you may run the risk of implementing controls that are not fully operational, to say nothing of experiencing brief bouts of disorientation.

Because the elements and principles are intended to get you to see controls and compliance in a whole new way, they are not tied down with restrictive definitions, serving instead as malleable constructs, with different meanings, in different contexts. Combined, they shape the very strategies developed to attain and sustain compliance.

While the views expressed are my own, and may, or may not, reflect the views of my current, or past, employers, the areas that I have chosen to cover stem from gestated experiences in consulting, business analysis, support, quality assurance, audit and compliance.

The book is not intended to be an introductory, all-encompassing textbook on IT compliance, security or audit. Readers expecting a retelling of evolved, and evolving, compliance regulations or security standards, will be disappointed. As are readers expecting boilerplate internal control templates or automated scripts. That said, you don’t have to be an auditor or a security professional to appreciate the subtle nuances, or reap tangible benefits of good control design. In fact, one of the main thrusts of the book is that IT controls are part and parcel of everyday life. A tenet of good control design is to ensure that they become, and remain, that way.

The book would speak directly to anyone who has had to work with, talk about, report on, or validate, IT controls, whether in an operational, business, technology, shared services, audit or consulting capacity.

It would especially appeal to those who are prone to hand wringing, hair pulling, or lip biting, at the mere mention of IT control.

The size of your organization does matter, as do various environmental factors that we will discuss later. Specific strategies work well in specific environments, less so in others. To some extent, we can anticipate this by drawing contextual clues from the foundational elements in place.

What if you already work in an organization armed with a formidable arsenal of risk and control documentation, testing, reporting, workflows and tools? Does it still make sense to dabble in elements and principles, revisiting the drawing board, as it were? All the more, I would argue, compared to a contemporary toiling away in an organization without formalized controls.

The human tendency to anchor on, and be swayed by available information structures, cannot be underestimated. In revisiting control elements and principles, you may uncover new findings. As old issues get recast in new light, tired assumptions lose their grip. It may yet dawn on you that the control infrastructure at your fingertips may be unwieldy at best, tenuous at worst.

For those of you who are building the control infrastructure from ground up, a sound grasp of varied elements and principles gives you the necessary groundwork to make informed decisions on the areas to prioritize to attain compliance and others still to phase in over time.

Control and chaos

To understand the inner workings of an artist, it is not uncommon for curators to look for misplaced notes, half-formed sketches and other preparatory material. The creative process that emerges vacillates between control and chaos. When the former is too excessive, the artist starts afresh to seek something of value.

The design of IT controls to attain compliance is not that different. To deliver timely, and possibly even innovative, solutions to present day challenges, it may be necessary to unearth deep-rooted biases and weed out inner trappings.

Let the unraveling begin!

PART I: ELEMENTS

In exploring control elements, we are really asking questions. Not all questions have answers; some lead to more questions; fewer still come with the answers we already have. The point is to keep an open mind and leave your preconceptions at the door. Too often, we delight in pseudo questions if only to confirm answers we hold dear.

In the forthcoming chapters, we will be exploring six control elements. Some of the material will be familiar to you, others not so much. At times, you may be suspended in disbelief. What does tennis or Alice in Wonderland have to do with controls? Other times, the content mirrors real-life, to the point where you feel compelled to throw up your arms and cry, I give up! Ironically enough, to truly understand the building blocks of an IT control, we first need to have the ground dissolve beneath our feet.

Part I contains the following chapters:

•  Chapter 1: People

•  Chapter 2: Data

•  Chapter 3: Objectives

•  Chapter 4: Systems

•  Chapter 5: Activities

•  Chapter 6: Risks.

CHAPTER 1: PEOPLE

Cooking broth

Too many cooks spoil the broth? This notwithstanding, it is remarkable that there are not more errors made in an increasingly distributed, outsourced and virtualized world.

Consider the lifecycle of a problem ticket for an application bug (see Figure 5).

Figure 5: Problem management

Potential errors that can arise with managing the ticket:

•  Multiple tickets are created for the same issue

•  The support personnel fails to escalate the ticket in a timely manner

•  The analyst assigns the ticket to a developer in the wrong group

•  The tester tests the bug and logs the status in a separate test management tool

•  The release manager releases the fix with management approval, but fails to update or close the ticket.

In spite of these what-can-go-wrongs, the bug gets fixed. The end-user can’t tell from checking the ticket status though. It is like sitting in a restaurant waiting for your soup; it is piping hot and ready, but you would never know to ask.

Before layering in real-life complexities, such as emergency fixes, support tiers and secondary approvals, there are some more soup questions to ask:

•  Who serves the soup? Who owns the ticket upon creation? Who ultimately makes sure the ticket is resolved and communicated to the end-user?

•  I didn’t order soup. Conversely, can a fix be released into production without a ticket? This is a tricky question whose answers may surface snaking workarounds and unauthorized changes.

•  Let them eat soup. What about concerns raised by the technology personnel – support, analysts, developers, testers or release management – do these translate