CHAPTER 7

Developments Within IT and Online Banking

Dilip Krishna

NCR Teradata

Introduction

Information technology (IT) has now become a key enabler of business advantage. Banks such as the Commonwealth Bank of Australia1 and the Royal Bank of Canada2 have used IT to “change the game” in their respective markets. The advent of the Internet has accelerated this trend. There are now real companies generating sustainable profits whose business models are entirely dependent on the wired online world. Many “bricks-and-mortar” financial organizations are becoming increasingly dependent on Internet technology in key functions ranging from customer experience to human resources.

This increased dependency on IT has increased systems-based corporate vulnerability as well, changing both the magnitude and scope of IT risks. Previous generation issues such as system outages, data loss, and computer-related fraud have also grown to become far more complex. At the same time, new risks have emerged such as Internet security and offshore outsourcing risks. The coincidence of the increasing dependence on IT in a time of vastly increased technological complexity has raised the importance of IT risk management.

IT risk is generally considered within the context of operational risk. Almost every operational risk in the Basel framework such as “improper business or market practices” can have associated technology components such as front-running detection systems within brokerage firms.3 Like other operational risks, IT risks can have severe knock-on effects on the firm’s reputation. The nature of IT threats can vary greatly. For example, the Barings debacle4 could arguably have been averted had a better management information system reporting consolidated firmwide positions been in place, making the situation transparent, and eliciting corrective action much sooner.

This instance may at least have been exacerbated due to the lack of appropriate technology. While such technology-related risks certainly present current threats, we will instead primarily focus on those risks that are closely related to the IT environment in large financial corporations, looking also at techniques for IT risk management, mitigation, and control.

Risks Within Information Technology

Information technology environments are in a constant state of flux driven by rapidly changing business needs, which are themselves, in some cases, driven by technology improvements. At any given time, parts of the IT environment can be in one of two states—operational or developmental. These can be visualized in terms of the systems lifecycle (see Exhibit 7.1) and discussed in the following texts.

Exhibit 7.1 Typical system lifecycle

Source: Author’s own.

• Operational state. This represents the steady-state operation of IT systems. Systems are typically managed by organizations skilled in ensuring that they perform to the service-level agreements (SLAs) agreed with business users. Users typically rely on these systems as critical components in their business processes. The primary goal of the operational state as far as the IT organization goes is the elimination of variance. Another important consideration in IT operations is optimizing the cost versus the reliability equation.
• Developmental state. Change is the dominant characteristic of the developmental state. Specifications for new systems (or new versions of old systems) are generally prepared collaboratively by business users and development organizations. Work proceeds in roughly chronological order through development and testing cycles until the new system is ready for ­implementation.
• Production rollout and sunsetting. State transitions are involved when the system is migrated to an operational state. Often this transition is accompanied by retiring (sunsetting) the earlier version of the system.

Most IT organizations have some systems in operation while others are in development; therefore, state transitions also occur quite frequently. There are a number of risks that IT environments are exposed to in each stage (see Exhibit 7.2). Given the range of IT operations within financial institutions, this list is intended to be representative rather than comprehensive.

Exhibit 7.2 Risks in IT environments

Source: Author’s own.

Risks in IT operations

Broadly speaking, IT systems in an operational state are expected to perform within a pre-specified range of reliability, expressed as an SLA between the user community and the IT operations organization. ­Typically, SLAs lay out measurements and performance targets along the dimensions covered in the agreement. Some system characteristics specified in an SLA are:

• Reliability: a statistical measure of unexpected system ­downtime (e.g., due to a disk crash);
• Availability: similar to reliability, but specified in terms of expected system downtime (e.g., system backup time);
• Response time: a measure of the system’s ability to interact with users;
• Security: ensuring protection of system information from unauthorized users; and
• Privacy: protecting individual (e.g., customer) privacy by selectively restricting access to highly privileged users.

In the context of operations risk management, these aspects can be roughly classified into business continuity, security, and privacy risks.

Business Continuity Risks

Technology risks are a critical component in any business continuity scenario. Events such as the World Trade Center attacks in September 2001 and the disastrous hurricane season in the United States in 2005 have brought a new sense of reality to the need to manage and mitigate disaster risks.

Disaster risks can come in several guises. Critical business functions can be disabled by loss of infrastructure due to natural catastrophes or malicious physical attacks. The resulting outage from such a disaster can impact firm viability, severely affecting operations, quality of service, and ultimately the firm’s reputation.

Disaster-recovery planners must understand fully the risks to their specific operations and consider all kinds of unlikely events in their analysis and planning. During the events of Hurricane Katrina in the southern United States, for example, there were cases where the geographic extent of the destruction was so great that both the primary and secondary IT centers were affected, leading to the irrecoverable loss of years of invaluable data.

Security and Privacy Risks

Computer databases have long posed security challenges and have been vulnerable to unauthorized modification as well as theft. These risks are quite significant, even in the non-networked world. Companies have had to safeguard the physical disks as well as tape back-ups. Ironically, good business continuity practices can be a cause of vulnerability, as in a recent case where back-up tapes containing the personal records of more than a million credit card customers were lost.5

The prevalence of data security attacks is due to a variety of reasons:

• data can be stored compactly which makes for easy ­transportation;
• data are easy to steal compared to documents, especially as information access has become a key demand of most users;
• computer systems are complex and lend themselves to ­difficult-to-anticipate failure modes; and
• security failure is often caused by human error of omission or commission. Improper application of recommended security policy is a common problem, for example, not overriding manufacturer passwords.

The advent of the Internet has raised security and privacy risks to a new level. Large sums of money are being lost to fraudsters, in addition to indirect losses being generated by identity theft and related activity. The research firm Gartner estimated that two million Americans lost a combined US$2bn to online banking fraud in 2004.6

Internet-exposed systems can be compromised in three ways.

• Unauthorized access. Internet-facing systems are most at risk for this kind of intrusion. All internal corporate systems are at risk, however, including those that do not contain critical data. In the famous case of the German hackers who compromised the systems of the US defense network, they had, in fact, accessed the network through a dormant Internet account.7 While this was a case of attack from an external source, threats from within the network (e.g., from ­employees) are critical risks as well.
• System incapacitation. Internet systems have become very important to most large financial organizations. Malicious activity has sometimes been targeted toward making systems inaccessible through means such as denial-of-service attacks. Attackers may attempt to prevent legitimate users from using the service via methods like flooding the network with traffic.

  Accidents such as the famous Robert Morris Internet worm8 can be as disabling as malicious activity. In 1990, Morris, a student at Cornell, released a “worm” program into the Internet as a research project. Unfortunately, a bug in the program caused the worm to multiply unchecked, bringing large swathes of the still-nascent internet to its knees.

• Client-facing attacks. More recently, a new class of ­Internet-related security risks has emerged directed not at ­corporate systems themselves, but rather at ­clients of large financial institutions. One attack that has recently become common is called phishing. This involves sending e-mails to customers that masquerade as legitimate corporate communication asking customers to log into the company’s website. ­Customers are in fact diverted to a bogus “corporate look-alike” site whose sole purpose is to capture customer passwords and logins. Passwords obtained in this manner can be put to illegitimate use in a number of ways.

  Phishing is an example of social engineering. Human ­vulnerabilities such as customer’s inexperience with the ­Internet are being exploited. Web-jacking is another ­example of social engineering. Internet domain names, which in some cases legally trade for millions of dollars, have been stolen by targeting insufficient controls in network registrars. A recent and complex case involved the web-­jacking of nike.com, in which users were redirected to a website hosted in Scotland.9 The resulting flood of ­traffic ­incapacitated the Scottish website (a legitimate web business not involved in the web-jacking), while at the same time diverting customers away from nike.com, ­making this a case study in denial of service as well as web-jacking. The flurry of resulting lawsuits is testimony to the fact that these incidents can lead to both legal as well as reputational risk.

Risks in System Development

Project Implementation

System development has proven a notoriously hard-to-control process. The Standish report,10 which has been tracking IT project success for more than a decade, suggests that only 29 percent of projects complete on time and within budget. System-development projects are constrained by three dimensions: time, cost, and scope, usually depicted by the triangle in Exhibit 7.3. The cost dimension includes personnel, development, and implementation infrastructure costs. Cost and time are typically easy to quantify, especially if a fairly robust project process is used.

Exhibit 7.3 Project constraints

Source: Author’s own.

The same cannot be said of project scope. At project inception, much of the work is in developing the requirements definition, so there is at best a fuzzy characterization of scope. Only after requirements have been well documented can scope be properly defined. Even at this point, however, it is possible to trade off the quality of the finished outputs against cost or time.

One dimension cannot be changed without affecting the others. For example, attempting to speed up systems development (reducing the time dimension) can only be accomplished by adding more resources (increasing costs), reducing scope, or both (see Exhibit 7.3). There are, of course, practical limits to how much each dimension can be modified and there are also measurement challenges with regard to both scope and quality. For example, a project might be seen to achieve both time and cost reductions without compromising scope, only to inadvertantly reduce the quality of the final deliverable.

While planned change causes sufficient difficulty in projects, unplanned variations in time, scope, or cost can be disastrous. The main goal of project risk management is, therefore, to ensure variability is minimized.

Major IT project risks include:

• scope definition and change;
• lack of senior management support;
• over-engineered solutions—eschewing simple, procedural alternatives in favor of complex technology; and
• lack of discipline in project process.

A recent phenomenon is the increasing occurrence of ­enterprisewide projects, driven by a combination of technological progress and changing business environments. These greatly increase the risks as they cut across established business and IT silos and exacerbate the risks discussed previously.

Software Development Outsourcing

Many large financial organizations utilize offshore development today, driven by soaring IT resource costs, rising sophistication of offshore development providers and reduced telecom costs. The application-­development model now incorporates elements of onsite, offsite, and out-of-country development resources all working in concert with each other.

Offshore development introduces a number of risks.

• Implementation risks. Offshore development brings geographically and culturally diverse teams together to work on complex, interrelated tasks, exacerbating development challenges.
• Data security. Rigorous testing on historical data obtained from the environment where the new system is to be installed is necessary for projects to be successful. Sending ­sensitive data to offshore locations heightens the security risk as there is generally less direct control over data security in these installations.
• Intellectual property (IP) rights. Depending on the laws of the jurisdiction where offshore development is taking place, there can be a significant risk that the software IP can be misappropriated.
• Loss of key project personnel. With increasing focus given to offshore development and aggressive moves by large, global systems integrators,11 massive demand is affecting availability of offshore resources, which can cause devastating losses of key development resources during a project.

While offshore development adds new risks, there is evidence that it may also mitigate project implementation risks by forcing the ­adoption of strong software development methodologies. This is imperative in ­projects requiring clear communication between groups that are remote from each other in location, time, and culture. These benefits tend to flow over time, even to projects that do not have an offshore component.

Open-Source Software Risks

Open-source software (OSS) is software that users are allowed to run, study, modify, and redistribute without paying a licensing fee. The past decade has seen open-source software gain increasing legitimacy. Without going into the reasons for the growth of OSS, it is sufficient to note that organizations often have polarized views on the topic—some view it as a free alternative to expensive applications while other companies view it as too risky to consider. The truth, is somewhere in the middle. OSS can bring significant benefits to users as long as the risks are properly addressed. These include the following.

• Strategic risks. If OSS gains wide-scale acceptance in the IT organization without a supporting IT culture and architecture, the firm could be exposed to critical dependency on software that is unsupported or incompatible with other technologies in the environment.
• Operational risks. Open-source code needs to be tested with the same rigor as in-house developed software. There is a heightened danger that the OSS code may contain faulty conditions that can cause major application failures once it is in production.
• Legal risks. OSS is usually developed in an informal ­environment by large numbers of unaffiliated parties. This raises the risk of copyright infringement via proprietary algorithms being unwittingly included into the code base. OSS software also comes with certain specific licensing terms that companies can unconsciously breach.12

OSS risks must be managed proactively. Contingency plans must be adequately prepared for events such as code-base forking or product abandonment. Use of external support can also mitigate OSS risks. In addition, companies are well advised to properly address the potential legal risks.

Risks in System Replacement

System replacement is risky as it involves transitioning a new system into a stable environment. A good example of what can go wrong was the week-long outage experienced by customers of the Royal Bank of Canada in June 2004 caused by an incorrectly coded program update to their payment processing systems.13

Development, usually done in a cloistered environment, may not be able to simulate all the issues related with the systems in production. Incumbent systems typically have incremental modifications that may not be fully documented and incorporated into new system design. For example, the myriad rules used to protect systems from invalid user input may not be fully represented in requirements.

Control processes are critically important in guarding against transition risks. The software development lifecycle (SDLC) must seamlessly address processes from development through operations and include consideration of issues such as user training. It is worth noting that many IT organizations have at least an awareness of the risks in system replacement, and some have reasonably mature processes in place to address system transition.

Data Issues

While firms have long relied on information to make decisions in running the business, data have, however, not been viewed as a corporate asset. Strong regulatory requirements in the form of the Sarbanes-Oxley regulations, the Basel II capital accord, and Solvency II regulations have forced firms to reconsider this position.

Poor data quality can have negative effects on both the operational and developmental states. It can inhibit firms’ ability to react promptly and appropriately to market events. For example, the trouble several banks had in putting out precise loss estimates in the wake of the Enron failure led to a loss of confidence and reputational risk issues. Lack of appropriate data can also put firms at a competitive disadvantage. Leading credit card issuers use detailed customer data to target precisely profitable segments of their customer base. An inability to compete with this game-changing capability will, over time, be a significant business risk.

Poorly managed data can also cause implementation risk. In recent Basel II implementation projects, lack of good data has been one of the biggest risk factors standing in the way of firms’ ability to comply with the accord. Reports have shown that a large part of global spending on Basel II initiatives is, in fact, spent on fixing the bank’s data infrastructure.14

IT Risk Management and Mitigation

The first step in mitigating and managing IT risk is to consider each system individually and address risks at this level. The framework proposed by the National Institute of Standards and Technology (NIST) provides a good example.15 This framework subdivides the risk management effort into risk assessment and risk mitigation.

Risk assessment is used to determine the extent of the potential threat and the risk associated with an IT system, and consists of nine steps:

• Characterize system scope along dimensions such as ­hardware/software, support personnel, and so on;
• Identify threat sources (hackers, terminated employees, etc.);
• Identify vulnerabilities to threat sources;
• Analyze current control processes around the system;
• Determine likelihood of risk by considering the threat sources and vulnerabilities against the relevant control processes;
• Determine adverse impacts for each risk;
• Determine overall risk considering likelihood and impact;
• Determine additional risk mitigation and controls; and
• Document and communicate the risk assessment.

Once risks have been assessed in this manner, the next step is to ­prioritize them and implement additional controls and mitigation steps recommended in step 8 by trading off risk impacts against implementation costs.

While individual system risk management is a key first step, mature IT organizations need to consider the complex interactions between systems and the consequent risks. The best way to address this issue is through a comprehensive system of IT governance and control.

Implementing Risk Management via IT Control Frameworks

Renewed interest in corporate governance has driven the emergence of various IT governance frameworks. The Sarbanes-Oxley Act (SOX), for example, has been a key imperative for companies doing business in the United States. One of the challenges in implementing a complex regulation, such as SOX, is that it is not prescriptive. Regulators publish guidance on how companies can become compliant and it is then left as an exercise for companies to establish the appropriate internal control processes and systems required to achieve regulatory approval. Banks have had the same experience with Basel II, which specifies capital calculations reasonably well but leaves internal risk management process requirements much more ambiguous.

In order to comply with the recent barrage of regulations, ­companies have relied on a handful of frameworks for risk management and ­control. U.S.-based firms have turned to the COSO internal control integrated framework,16 as there has been some SEC guidance on this for SOX compliance. This framework has recently been expanded into the larger COSO enterprise risk management framework.17 While the older framework was targeted at financial reporting and accounting processes, the newer document can be applied to IT environments as well.

The COSO ERM framework defines four objectives (strategic, operations, reporting, and compliance) and defines risk management as a function to control unforeseen deviations from these objectives. The methodology of control is laid out in eight components or logical steps:

• importance of the internal environment in creating an ­appropriate risk culture;
• define corporate goals via objective setting;
• identification of risk events;
• considering likelihood and impact of risk events via risk assessment;
• define a risk response to risk events;
• control activities (policies and procedures) to ensure proper risk management;
• focus on stakeholders via information and communication; and
• monitoring risk in management processes.

The COSO framework is itself too general to provide specific guidance for IT management. IT-specific frameworks and best practices, such as COBIT and ITIL, can, however, be applied within the overall context of an ERM framework to hone in on areas that need to be addressed for a particular compliance initiative. Some of the IT frameworks that are commonly used are described briefly in the following texts.

• COBIT (Control Objectives for IT): used widely by audit organizations in the United States, COBIT is a standard set of guidelines that formalizes processes and controls to align the IT environment with enterprise business objectives.
• ITIL (IT Infrastructure Library): an established set of best practices for IT service delivery, ITIL is very popular in Europe but also gaining currency in the United States.
• CMM (Capability Maturity Model): developed by the ­Software Engineering Institute, CMM is aimed at the ­software development process and has been widely adopted by software development organizations.
• ISO 17799: this is a set of standards focused on information security controls and practices.

These frameworks are not mutually exclusive, but can be used in conjunction with each other to reinforce aspects of the IT environment. For example, COBIT and ITIL are sometimes used together. The ISO 17799 standards are often used to ensure best practices for security management in conjunction with other best practices. These frameworks must be not thought of as an all-or-nothing proposition. It is not only possible but also prudent practice to implement the frameworks incrementally, keeping in mind the risk/return needs of the organization.

For example, most financial services companies are not usually well served by implementing the highest-level CMM processes (level 5) in their internal application-development organizations. This would most likely impose undue costs and reduce the organization’s flexibility to respond to legitimate business needs, to boot. Rather, the goal should be for a robust level of sophistication that preserves flexibility. A similar implementation approach can be used for IT governance processes as well. Addressing specific compliance needs while adhering to a strategic plan for overall process improvement will result in efficient improving risk management processes as well.

Risk Management Roles and Responsibilities

IT risk management is not only the responsibility of IT managers. Rather, it must also be integrated into an organization’s overall operational risk management plan, extending beyond defensive risk management practices (such as security) to the full range of IT risks, including data and implementation risks. Consequently, the following personnel must play key roles.18

• Senior management. Responsible for ensuring adequate resources to support IT risk management and integrating IT risk assessment processes into overall decision making.
• Chief Information Officer (CIO). Ensuring that decision making within the IT environment is done in the context of an overall IT risk management programme. The CIO is also responsible for ensuring that comprehensive development processes are adopted to mitigate implementation risk.
• Chief Security Officer (CSO). Developing a firmwide security programme, ensuring its implementation and monitoring continued adherence to security policies. The CSO also acts as consultant to senior management to ensure that the firm is secure on an ongoing basis.
• Data governance committees. These comprise senior management representatives from business, technology, and data management functions and are responsible for funding and management processes for data. This is a critical structure for mitigating data issues discussed earlier.
• Data stewards. These are operatives who design and operate data quality and semantics management processes within the framework designed by data governance committees.
• Security administrators. Personnel such as systems and database administrators are responsible for the implementation of security procedures at a system level and for ensuring that proper procedures are followed on a continuing basis.
• System owners. Ensure that proper controls are designed and implemented for all systems within their remit.
• IT programme managers. Responsible for executing IT ­programmes while adhering to the corporate standards for project management.

Conclusion

We have covered a wide range of risks in the IT environment, and governance and control frameworks to manage these risks. Control processes and disciplines are being institutionalized with some urgency by financial institutions in response to new regulatory regimes that are being imposed upon them.

While IT risk management is growing in its sophistication, there is a striking imbalance between methodologies of risk control and those for risk measurement. Mature practices in managing other risk classes involve sophisticated techniques for modeling risks based on a few predictive measures so that forward-looking risk assessments may be made for any situation. Such measures allow for precise quantification of risk and return.

These techniques are at a nascent stage in IT risk management. Methods used in quantifying operational risks are being used for IT risks as well. These include bottom-up quantitative techniques analyzed such as loss distribution analysis and Bayesian belief-network analysis. The same sorts of classification and data availability issues exist as well for IT risk management. Establishing precise risk quantification of IT risk is critical to the formulation of risk management strategies. There is not, at present, a robust analytic framework that allows managers contextually to determine for any given IT risk whether risk mitigation or acceptance is the proper strategy. Such a framework will also allow managers to determine the most effective mitigation technique for each risk, such as insurance or outsourcing. These areas are new frontiers for IT risk management and are likely to see some exciting developments in the coming years.

---