Application security – moving from folklore and feelings to facts

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.

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:

  1. AC1 Source Data Preparation and Authorisation - concerned with origination, error detection, irregularities, segregation and approval
  2. AC2 Source Data Collection and Entry -addresses timely input and correction by authorised and qualified individuals
  3. AC3 Accuracy, Completeness and Authenticity Checks - can these be performed as close to transaction/ data origination?
  4. AC4 Processing Integrity and Validity - error detection
  5. AC5 Output Review, Reconciliation and Error Handling - is the output still relevant, sufficient and appropriate to the needs of the organization?
  6. 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.

  1. BIS Basel II annex 7 Detailed Loss Event Type Classification
  2. 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

Read more on IT risk management