The mobile rang, the question all CIOs dread: "Have you
seen the news today? Could this happen to us?" And so began Sam's
day. I've only been here for two years and we've been full on since
I arrived.
The door opened. "Sam are you ready for us to start?"
"Yes, come in and sit down Steve. I've been having some
premonitions about security, and particularly applications
security. You've been here a lot longer than I have. What's your
gut feeling?"
"Well if I am really honest I think we have been very lucky so
far. You may not be aware that five years ago we took over two of
our competitors primarily for their systems, much like Lloyds Bank
did a few years ago when they took over TSB"
Whilst this dialogue is completely fictitious, something about
it nevertheless has a ring of truth to it.
There are a number of situations that should trigger a review of
application controls. Current examples being virtualization and
computing in the "cloud" may seem obvious candidates. Sharepoint,
and similar applications may also benefit from closer scrutiny.
Before we can begin any review of controls we should always
revisit the risks the organization faces to remind ourselves and
perform a reality check, to confirm completeness and continuing
relevance. Consideration also should be given to the organizations
risk appetite, stakeholder expectations and emerging compliance and
regulatory issues.
Annex 7 of the Bank of International Settlements (BIS) Basel II
(1) document contains a "loss event type" table which is a good
place to start a reality check for a specific application or a
subset representing the most important group of information
services.
Once we understand the risks we can then move on to consider the
controls. There is a grave danger when we focus in on a subject
that we lose sight of the context, and nowhere does this seem to
happen more often than in IT, and in relation to controls.
"Controls" can and often are a very emotive subject. We all like to
feel we are in control and none of us like to feel we are being
controlled. When someone broaches the subject of additional
controls we all too often see this as a challenge to our
trustworthiness.
This is a good time to remind ourselves that the only reason we
have controls is to mitigate the potential impact from risks to an
acceptable level. This means that for controls to be "effective",
their cost of operation must be less that the potential loss, and
perhaps more importantly today , the potential impact on the
"customer experience " of applications controls should be given
careful consideration.
Applications controls are one of the three broad classifications
of controls available to organizations, the others being Business
and General IT controls. The term application controls is used to
describe those controls built into the application to control the
processing of transactions and data. The diagram illustrates how
they should all work together to provide protection to the
organisation and its stakeholders.
Each organisation needs to develop its own "cocktail" of
controls, and the adjacent table format can be used to see and
understand how the layers of control work together to provide the
protection that's needed.
We are now in a position to put the application controls under
the spotlight. This can be problematic particularly with third
party applications.
COBIT 4.1 (2) is on hand to help us identify our current
requirements , which COBIT describes as "business requirements for
information". Seven distinct but overlapping criteria have been
identified and found to work in practice. These are effectiveness,
efficiency, confidentiality, integrity , availability, compliance,
and reliability. The requirements should be re-visited with the
owner of the application/ service. (It should be remembered that
the business is responsible for identifying the application control
requirements , with IT ensuring third party vendors satisfy the
requirements in the best way for the organisation.)
We can then turn to the applications controls in COBIT 4.1 and
consider whether the existing application controls are sufficient
to meet our current and projected needs.
COBIT consolidates applications controls into six broad
groups:
- AC1 Source Data Preparation and Authorisation - concerned with
origination, error detection, irregularities, segregation and
approval
- AC2 Source Data Collection and Entry -addresses timely input
and correction by authorised and qualified individuals
- AC3 Accuracy, Completeness and Authenticity Checks - can these
be performed as close to transaction/ data origination?
- AC4 Processing Integrity and Validity - error detection
- AC5 Output Review, Reconciliation and Error Handling - is the
output still relevant, sufficient and appropriate to the needs of
the organization?
- AC6 Transaction Authentication and Integrity - maintaining,
authenticity and integrity during transmission or
transport.
Where we are concerned that there may be inadequate applications
controls, we will want to consider locating compensating controls
as close as we can to the risk. We will need to decide what
preventative, detective and corrective measures are most suitable
and whether these need to be in the business and or IT.
From the IT perspective all 34 COBIT processes are mapped to the
business requirements for information , thus providing focused
guidance on which IT general controls can help address shortfalls
in application controls.
Whilst performing this exercise you will find it useful to
document your assumptions to make them explicit and test their
reasonableness. They can then be used to help identify those
changes either with the organization or the wider environment that
would cause you to want to reconsider or reverse the current
controls. Then ask yourself "What key risk indicator can we put in
place to trigger a timely re-appraisal of the situation?"
You may find "COBIT and Applications Controls: A Management
Guide", due for imminent publication by ISACA /ITGI a useful
addition to your library.
- BIS Basel II
annex 7 Detailed Loss Event Type Classification
- SACA/ITGI COBIT 4.1 is
free to download. There is
more detailed help in the Control Practices and Assurance
Guides.
Roger Southgate, is a past president of ISACA London and an
independent governance and risk consultant