Volume 1, January 2014

In This Issue:

Call for Articles

How are you using COBIT® at your enterprise?

We welcome articles on your

experiences with this framework. Deadline to submit copy for

volume 2, 2014: 10 March 2014

Submit articles for

peer review to: publication@isaca.org

Case Studies

Visit the COBIT Recognition and

Case Studies pages to read more COBIT 5 and COBIT 4.1

case studies.

• Middle East Bank Improves Information Security • Information Security Management at HDFC Bank: Contribution of Seven Enablers • Supporting PCI DSS 3.0 Compliance With COBIT 5 • Developing a Governance Framework for the Global Support Organisation at GlaxoSmithKline,

Using COBIT

Middle East Bank Improves Information Security By Abbas K, CISA, CISM, CGEIT, COBIT 5 (Foundation), CEH, C|CISO, PRINCE2 As a result of its initiative to improve information security with the help of COBIT, a Middle East bank realized several benefits, including: • Improved integration of information security within the organization • Informed risk decisions and risk awareness • Improved prevention, detection and recovery • Reduced (impact of) information security incidents • Enhanced support for innovation and competitiveness • Improved management of costs related to the information security function • Better understanding of information security

Obtaining buy-in from senior management is a common complaint among information security professionals. However, at one Middle East bank in Kuwait, the information security manager did not have that problem when implementing COBIT to define the enterprise’s information security principles because senior management at the bank was already well aware of the industry-accepted framework. As a result, his assessment report was quickly completed, quickly accepted and greatly appreciated.

The organization uses many standards and frameworks, including ISO 27001, the Payment Card Industry Data Security Standard (PCI DSS) and the IT Infrastructure Library (ITIL), and wanted to align its department processes and principles with a common framework that is highly flexible and adaptable, and has controls and processes in common with other industry frameworks. The organization found this in COBIT®, which in its latest edition—COBIT® 5—offers detailed mapping with other frameworks including International Organization for Standardization (ISO) standards, The Open Group Architecture Framework (TOGAF) and the Project Management

Come join the discussion! Abbas K will respond to questions in the discussion area of the COBIT 5—Use It Effectively topic beginning 24 January 2014.

Volume 1, January 2014 Page 2

Body of Knowledge (PMBOK).

No other framework provides such detailed mapping with various, industry-accepted standards. The bank has used COBIT 5 and COBIT® 5 for Information Security for a number of projects: • COBIT 5 Tool Kit was used to identify the statement of applicability (SOA) for each domain, along with the

corresponding 37 processes and 210 practice statements. • The COBIT 5 principles have been mapped to the information security department’s current processes with an objective

to identify any potential gaps. (See the Supporting Evidence column in figure 1 for results of the mapping.) • All gaps identified in the assessment were addressed based on recommended guidelines for each of the practice

statements.

Information Security Principles As outlined in COBIT 5 for Information Security, information security principles communicate the rules of the enterprise in support of the governance objectives and enterprise values, as defined by the board and executive management. These principles need to be: • Limited in number • Expressed in simple language and state, as clearly as possible, the core values of the enterprise

These principles (figure 1) are generic and applicable to all enterprises and can be used as a basis for developing information security principles unique to the enterprise.

Figure 1—Bank’s Information Security Principles Based on COBIT 5

Principle Objective Description Status Supporting Evidence

1. Support the business.

Focus on the business.

Ensure that information security is integrated into essential business activities.

Individuals within the information security community should forge relationships with business leaders and show how information security can complement key business and risk management processes. They should adopt an advisory approach to information security by supporting business objectives through resource allocation, programs and projects. High-level, enterprise-focused advice should be provided to protect information and help manage information risk both now and in the future.

Implemented Information security strategy

Deliver quality and value to stakeholders.

Ensure that information security delivers value and meets business requirements.

Internal and external stakeholders should be engaged through regular communication so that their changing requirements for information security can continue to be met. Promoting the value of information security (both financial and nonfinancial) helps to gain support for decision making, which can, in turn, help the success of the vision for information security.

Implemented Information security strategy

Volume 1, January 2014 Page 3

Figure 1—Bank’s Information Security Principles Based on COBIT 5

Principle Objective Description Status Supporting Evidence

Comply with relevant legal and regulatory requirements.

Ensure that statutory obligations are met, stakeholder expectations are managed, and civil or criminal penalties are avoided.

Compliance obligations should be identified, translated into requirements specific to information security and communicated to all relevant individuals. The penalties associated with noncompliance should be clearly understood. Controls should be monitored, analyzed and brought up to date to meet new or updated legal or regulatory requirements.

Implemented PCI compliance status, ISO 27001 compliance status

Provide timely and accurate information on information security performance.

Support business requirements and manage information risk.

Requirements for providing information on information security performance should be clearly defined, supported by the most relevant and accurate information security metrics (such as compliance, incidents, control status and costs), and aligned to business objectives. Information should be captured in a periodic, consistent and rigorous manner so that the information remains accurate and results can be presented to meet the objectives of relevant stakeholders.

Implemented Information security monthly management report

Evaluate current and future information threats.

Analyze and assess emerging information security threats so that informed, timely action to mitigate risk can be taken.

Major trends and specific information security threats should be categorized in a comprehensive, standard framework covering a wide range of topics such as political, legal, economic, sociocultural and technical issues. Individuals should share and build on their knowledge of upcoming threats to proactively address their causes, rather than just the symptoms.

Implemented Periodic security testing and review

Promote continuous improvement in information security.

Reduce costs, improve efficiency and effectiveness, and promote a culture of continuous improvement in information security.

Constantly changing organizational business models—coupled with evolving threats—require information security techniques to be adapted and their level of effectiveness improved on an ongoing basis. Knowledge of the latest information security techniques should be maintained by learning from incidents and liaising with independent research organizations.

Implemented Key performance indicators; monthly and annual management reports

Volume 1, January 2014 Page 4

2. Defend the business.

Adopt a risk-based approach.

Ensure that risk is treated in a consistent and effective manner.

Options for addressing information risk should be reviewed so that informed, documented decisions are made about the treatment of risk. Risk treatment involves choosing one or more options, which typically include: • Accepting risk (by a member of

management signing off that he/she has accepted the risk and no further action is required)

• Avoiding risk (e.g., by deciding not to pursue a particular initiative)

• Transferring risk (e.g., by outsourcing or taking out insurance)

• Mitigating risk (typically by applying appropriate information security measures, e.g., access controls, network monitoring and incident management)

Implemented Information security management system (ISMS) and PCI compliance risk assessment

Protect classified information.

Prevent disclosure of classified (e.g., confidential or sensitive) information to unauthorized individuals.

Information should be identified and then classified according to its level of confidentiality (e.g., secret, restricted, internal, public). Classified information should be protected accordingly throughout all stages of the information life cycle—from creation to destruction—using appropriate controls such as encryption and access restrictions.

Implemented Information security policy and standards

Concentrate on critical business applications.

Prioritize scarce information security resources by protecting the business applications on which an information security incident would have the greatest business impact.

Understanding the business impact of a loss of integrity or availability of important information handled by business applications (processed, stored or transmitted) will help to establish the level of criticality. Information security resource requirements can then be determined and priority placed on protecting the applications that are most critical to the success of the organization.

Implemented Information security policy and standards

Develop systems securely.

Build quality, cost-effective systems on which business people can rely (e.g., that are consistently robust, accurate and reliable).

Information security should be integral to the scope, design, build and testing phases of the system development life cycle (SDLC). Good information security practices (e.g., rigorous testing for information security weaknesses; peer review; and ability to cope with error, exception and emergency conditions) should play a key role at all stages of the development process.

Implemented Information security standards

Volume 1, January 2014 Page 5

3. Promote responsible information security behavior.

Act in a professional and ethical manner.

Ensure that information security-related activities are performed in a reliable, responsible and effective manner.

Information security relies heavily on the ability of professionals within the industry to perform their roles responsibly and with a clear understanding of how their integrity has a direct impact on the information they are charged with protecting. Information security professionals need to be committed to a high standard of quality in their work while demonstrating consistent and ethical behavior and respect for business needs, other individuals and confidential (often personal) information.

Implemented Background checks

Foster a positive information security culture.

Provide a positive information security influence on the behavior of end users, reduce the likelihood of information security incidents occurring, and limit their potential business impact.

Emphasis should be placed on making information security a key part of business as usual, raising information security awareness among users, and ensuring that they have the skills required to protect critical or classified information and systems. Individuals should be made aware of the risk to information in their care and empowered to take the necessary steps to protect it.

Implemented Information security governance committee (ISGC) meetings

Benefits of COBIT 5 Implementation The bank achieved its goals in a short time—just three months—improving a number of processes, including: • Ensure governance framework setting and maintenance • Ensure benefits delivery • Ensure risk optimization • Ensure resource optimization • Ensure stakeholder transparency • Manage the IT management framework • Manage strategy • Manage enterprise architecture • Manage innovation • Manage requirements definition • Manage assets • Manage continuity

Conclusion The bank plans to continue using this assessment framework on an annual basis and as other projects warrant it. The latest version of COBIT is easy to understand and implement, particularly the tool kit, which provides all the required information needed to use COBIT within the organization.

Abbas K, CISA, CISM, CGEIT, COBIT 5 (Foundation), CEH, C|CISO, PRINCE2 Has more than 14 years of experience with cross-functional sectors of information security and information risk. He is the manager of information security at a leading regional bank in the Middle East. Previously, he has worked with Ernst & Young and KPMG. He is well versed in IT standards and frameworks, such as COBIT, ISO 27001, PCI DSS, TOGAF and ITIL.

Volume 1, January 2014 Page 6

Information Security Management at HDFC Bank: Contribution of Seven Enablers By Vishal Salvi, CISM, and Avinash W. Kadam, CISA, CISM, CGEIT, CRISC, CBCP, CISSP, CSSLP HDFC Bank was incorporated in August 1994 and has a nationwide network of 3,062 branches and 10,743 automated teller machines (ATMs) in 1,568 Indian towns and cities.

HDFC Bank operates in a highly automated environment in terms of IT and communication systems. All of the bank’s branches have online connectivity, which enables the bank to offer speedy funds transfer facilities to its customers. Multi-branch access is also provided to retail customers through the branch network and ATMs.

The bank has prioritised its engagement in technology and the Internet as one of its key goals and has made significant progress in web-enabling its core businesses. In each of its businesses, the bank has succeeded in leveraging its market position, expertise and technology to create a competitive advantage and to build market share.

Use of COBIT As an early adopter of COBIT® 4.1, HDFC Bank’s IT governance journey started almost six years ago, when COBIT 4.1 was just introduced. Almost all of the 34 IT processes defined in COBIT 4.1 were adopted by the bank.

Following COBIT® 5’s introduction in April 2012, HDFC Bank took some time to consider a migration. Because the bank has successfully implemented COBIT 4.1 to great benefit, it will not immediately migrate to COBIT 5. However, the seven enablers introduced by COBIT 5 were intuitively adopted by HDFC Bank even before these were popularised in COBIT 5.

COBIT 5 describes seven enablers, which are factors that, individually and collectively, influence whether something will work—in this case, governance and management of enterprise IT (GEIT): 1. Principles, policies and frameworks are the vehicles to translate a desired behaviour into practical guidance for day-to-

day management. 2. Processes describe an organised set of practices and activities to achieve certain objectives and produce a set of outputs

in support of achieving overall IT-related goals. 3. Organisational structures are the key decision-making entities in an enterprise. 4. Culture, ethics and behaviour of individuals and the enterprise are often underestimated as a success factor in

governance and management activities. 5. Information is pervasive throughout any organisation and includes all information produced and used by the enterprise.

Information is required for keeping the organisation running and well governed, but at the operational level, information is often the key product of the enterprise.

6. Services, infrastructure and applications include the infrastructure, technology and applications that provide the enterprise with IT processing and services.

7. People, skills and competencies are linked to people and are required for successful completion of all activities and for making correct decisions and taking corrective actions.

Organisational Structures Organisational structures are the key decision-making entities in an enterprise.

Information security at HDFC Bank is driven by its information security group (ISG). The group is headed by the chief information security officer (CISO), who reports to the executive director of the bank. The ISG is primarily responsible for identifying, assessing and proposing mitigation for every information-security-related risk. This responsibility is carried out by interacting with various committees and stakeholders and preparing plans, proposals, policies, procedures and guidelines.

Come join the discussion! Vishal Salvi and Avinash Kadam will respond to questions in the discussion area of the COBIT 5—Use It Effectively topic beginning 24 January 2014.

Volume 1, January 2014 Page 7

The implementation of these is assigned to the implementation teams across the bank.

The governance framework at HDFC Bank is driven by a number of top-level committees (figure 1). The importance given to information security is evident from the number of top-level committees that have information security on their agenda.

Roles and responsibilities for the ISG have been well defined through a RACI chart (figure 2). One of the main points to be noted is that, although the responsibility for information security management is with the ISG, the accountability is squarely with the function heads. Similarly, although the ISG is accountable for the risk assessment definition, function heads are accountable for risk assessment execution. This segregation of

Figure 2—ISG Roles and Responsibilities

Information Security Tasks Info. Security

IT Operations Business Legal Audit HR Function Heads

Governance A/R C C C C R C Policies, process and standards A/R C C I C C C Strategy A/R C C C I C I Risk assessment—definition A/R I I I C I Risk assessment—execution C R R R C A Information security management R/C R R R R R R A/R Security architecture A/R R C Security technology C A/R C Security engineering C A/R C Secure development C A/R C Operations and service delivery A R R C Project management A/R R I I C Audit, review and monitoring R/C R I I I A/R I Incident response A/R R R I C C I Legal and regulatory environment A/R I I I R R I Awareness, education and training A/R I I I I C R

Source: HDFC Bank. Reprinted with permission.

Figure 1—HDFC Bank’s Governance Framework

Source: HDFC Bank. Reprinted with permission.

Volume 1, January 2014 Page 8

responsibility and accountability creates ownership of risk mitigation and information security management with the function heads.

The overall framework for governance to implementation is provided in figure 3.

The 21 components are constantly monitored for maturity level. The assignment of work to the ISG team members is based on these controls.

Principles, Policies and Frameworks Principles, policies and frameworks are the vehicles to translate the desired behaviour into practical guidance for day-to-day management.

HDFC Bank has created a comprehensive policy document of around 100 pages. The current version is 3.x, and it is being revised to version 4.0. This document covers the 11 information security domains as specified in ISO 27001 in a platform- and technology-agnostic manner. It is modeled on Information Security Forum (ISF)’s Standard of Good Practices.

Because the bank uses 30 to 40 different technologies, there are more detailed policies created for each technology. These are fine-grained technology-specific policies for reference by the technical team responsible for implementing these technologies.

These policies are further subdivided into records for mapping against various authoritative standards/frameworks, such as ISO 27001, COBIT and Reserve Bank of India (RBI) guidelines. These records are input into a governance, risk and compliance (GRC) tool that provides the bank’s internal unified control framework (UCF). This helps to identify, in an automated fashion, the compliance level achieved. The tool provides almost 40 authoritative sources that are already mapped through the UCF. Thus, compliance with any source can be easily found.

The ISG team uses the Factored Analysis of Information Risk (FAIR) methodology for computing probable risk by capturing threat event frequency and loss event frequency, giving appropriate weight to each factor, and deriving the risk rankings for prioritising and decision making. The ISG team also reviewed ISO 27005 and created a sound approach to risk management with the help of these standards.

A short version of the policy document has been created as a 20-page user guide supported by a list of top 10 rules for information security.

There are a number of vendors providing services to HDFC Bank. The supply chain security is assured by regular third-party reviews of vendors, which are performed by external audit firms.

HDFC Bank is certified for ISO 27001 and BS 25999, is planning to achieve the ISO 22301 certificate, and has achieved 92 percent compliance with the RBI guidelines.

Figure 3—Governance to Implementation

Policy, Processes, Standards Procedures, Technical Controls

21 Components Application security, cryptography, monitoring, incident management,

online banking security, malware management, data protection, secure software development life cycle, business continuity planning,

privacy, identity and access management, risk management…

Volume 1, January 2014 Page 9

The ISG team is currently focused on creating a sound incident management system; providing adequate data protection; ensuring appropriate implementation of bring your own device (BYOD); and detecting, containing and removing advanced persistent threats in a timely fashion.

Processes Processes describe an organised set of practices and activities to achieve certain objectives and produce a set of outputs in support of achieving overall IT-related goals. The ISG follows an information security process model based on 21 components: 1. Application security 2. Cryptography 3. Monitoring 4. Incident management 5. Online banking security 6. Malware management 7. Data protection 8. Secure software development life cycle 9. Vendor (third-party) management 10. Business continuity planning 11. Privacy 12. Identity and access management 13. Risk management 14. Physical security 15. Awareness 16. Governance 17. Policy 18. Asset life cycle management 19. Accountability and ownership 20. System configuration 21. Network security

The information security planning, designing, deployment and monitoring is done for these individual components. This approach keeps the teams focused. The policies, procedure, guidelines, standards, technologies and tools are built for these components. This approach provides granularity in managing each focus area and also leads to defense-in-depth architecture.

Each of the components contributes to building the control standards and control procedures that satisfy high-level policy requirements. This is a bottom-up approach that serves to mitigate the top-level security concerns for business processes by providing adequate security for the assets used by these processes.

The work of mapping all business processes with assets is currently being carried out. The business processes are being ranked based on the criticality and impact they may have on the business. If one asset, e.g., a server, is hosting multiple IT processes supporting multiple business processes, it gets the ranking attributed to the most critical business process.

The approach followed by the HDFC Bank ISG is closely aligned with COBIT 5’s goals cascade (figure 4).

Figure 4—COBIT 5 Goals Cascade

Source: ISACA, COBIT 5, USA, 2012

Volume 1, January 2014 Page 10

Stakeholder drivers identified by HDFC Bank are shown in figure 5.

Information Security Maturity Levels ISG has developed an information security maturity model. The model has defined five levels of maturity as shown in figure 6.

Figure 5—HDFC Bank Stakeholder Drivers

Payment Cards Industry Data Security Standard (PCI DSS)RBI Regulations for Cyber Security Controls –April 2011Indian Privacy Law – WIPIDRBT Information Security Framework

HacktivismCybercrimeCyberattacksAdvance Persistent Threats CyberespionageInformation Leakage Mobile Malware

VirtualisationCloud ComputingBig Data IP V6

UIDNAT-GRID

E-governance ProjectsCybersecurity Policy for India

Creation of Sectorial CERTS

IT ConsumerisationSocial Networking

Social MediaMobile/Tablets

Source: HDFC Bank. Reprinted with permission.

Figure 6—Information Security Maturity Model

Column1 Level 1 Level 2 Level 3 Level 4 Level 5 Initial Developing Defined Managed Optimized Policy No policy Limited policy Comprehensive policy

defined and published Policy published and implemented consistently

Continuous review and improvement of the policy

Roles and responsibilities

No defined roles and responsibilities

Roles some-what defined

Clear roles and responsibilities defined

Roles and responsibilities defined and executed

Roles and responsibilities reviewed on ongoing basis

Automation Manual Semi-automated

Automated Automated and fully operational

Constant upgrade of automation

Scope Not implemented Limited coverage

Critical assets Complete Regular review of scope to ensure 100% coverage

Effectiveness N/A Low Medium High Very high

Incident management

No tracking Limited visibility

Critical incidents tracked

All incidents tracked and closed

RCA done for all incidents and remediated

Measurement No measurement Limited measurement

Comprehensive measurements defined

Measured and reviewed on a regular basis

Measurement criteria reviewed regularly

Reporting No reporting Limited reporting

Reporting defined Reports sent to senior management and reviewed

Reporting requirements regularly reviewed and updated

Source: HDFC Bank. Reprinted with permission.

Volume 1, January 2014 Page 11

ISG has defined eight desirable attributes for information security components. These are listed in column 1. Requirements for achieving each level for an attribute have been defined in the subsequent columns. For example, the policy attribute is at level 1 if there is no policy defined for a particular component, and it is at level 5, i.e., optimised, if there is continuous review and improvement of the policy.

Tracking of each of the 21 components is based on this model. The maturity model has been successfully used by HDFC Bank to build a sense of benchmarking within the organisation. It helps in finding areas for improvement. These evaluation exercises are done in a workshop mode. There is a healthy two-way communication leading to a sense of participation and clarity about the strategy and vision of the enterprise. The model is strictly used for internal gap analysis and for identifying areas for improvement. It is not meant for use to provide assurance to a third party.

The above maturity model was created by the ISG to meet its unique needs for defining specific improvement plans. This maturity model is loosely based on the maturity model defined in COBIT 4.1. One of the criticisms of the COBIT 4.1 maturity model was that the criteria for levels are subjective. HDFC Bank is now considering mapping the current processes with the COBIT 5 Process Assessment Model (PAM), which is based on ISO 15504.

Services, Infrastructure and Applications Services, infrastructure and applications include the infrastructure, technology and applications that provide the enterprise with IT processing and services.

HDFC Bank uses almost 40 different technologies. Various services, infrastructure and applications are built around these technologies. As described under the processes enabler, each of these services is mapped to the information security maturity level. A continuous updating of the maturity level against attributes such as automation, effectiveness, incident management and measurement ensures that these services are monitored very closely. All projects for improvement of the services are based on the maturity level aimed at the particular service.

Information Information is pervasive throughout any organisation and includes all information produced and used by the enterprise. Information is required for keeping the organisation running and well governed, but at the operational level, information is often the key product of the enterprise.

Reliable information for security management is a key factor. Information in terms of strategy, budget, plan and policies is regularly presented through board papers. Information security requirements are captured through a risk acceptance form (RAF) and are reviewed at the information security risk management committee (ISRMC). The ISG also prepares various information security review reports, including audit findings, maturity reports, threat analyses, vulnerability assessment reports, information risk registers, breaches and loss reports, and information security incident and problem reports.

The maturity model provides additional inputs for good quality information. Various information security metrics and measurements have been created based on the ISO 27004 framework and are presented as a dashboard. Currently, work is in progress to implement an IT GRC tool to capture all the information at the source and demonstrate compliance against numerous requirements, including RBI guidelines, PCI DSS and Basel II. The tool also provides mapping of various controls from COBIT 4.1.

People, Skills and Competencies People, skills and competencies are linked to people and are required for successful completion of all activities, for making correct decisions and taking corrective actions.

HDFC Bank has deployed a number of techniques to create awareness about security and to build appropriate skills and competencies. Following is a list of some of the initiatives: • Information security movie—A 20-minute movie was created and presented with all the trappings of a real movie

theatre experience (e.g., tickets, popcorn). The movie has proven extremely popular, and so far 40,000 employees have seen it. Every training programme begins with this movie.

• Information security cartoon strip—A cartoon strip was created with two characters, one named Sloppy and the other Sly. Their exploits entertain the readers and also carry a very powerful security message. This cartoon strip is now planned to be printed in a calendar format.

• Security net—The security net (an intranet) houses all relevant material, such as policies, standards, guidelines, contact

Volume 1, January 2014 Page 12

lists, business continuity plans and approach notes.

• Email and picture campaign—Regular emails are sent cautioning everyone about being alert, e.g., a reminder about avoiding phishing emails is sent after any successful phishing attempt.

• Ten security commandments—The user policy document has been summarised into key information security rules that are easy to read and remember (figure 7).

• Security First course—All employees have to undertake this one-hour course every two years. Taking the examination and obtaining passing marks is mandatory. A certificate is issued to all successful candidates. The certificate acts as an official recognition. Apart from the certificate, the star performers are also recognized through global mailers sent to all the bank’s employees as well as monetary rewards.

• One-day workshop—A one-day workshop is conducted periodically for senior management at which the CISO explains the importance of information security for the bank and the specific measures deployed for its implementation.

Culture, Ethics and Behaviour Culture, ethics and behaviour of individuals and the enterprise are often underestimated as a success factor in governance and management activities. Nonetheless, they are important contributors to the success of an enterprise.

COBIT 5 has identified eight types of behaviours that contribute to building security culture in an organisation. Various initiatives taken by HDFC Bank have led to creating the right type of security behaviours. HDFC Bank has used multiple channels of communication, enforcement, clear policies, rules and norms. Secure behaviour is also encouraged through recognition, e.g., a security certificate, and strong messages to defaulters. Secure behaviour is strongly influenced through raising awareness.

The eight types of behaviour are reproduced here for reference along with the specific measures adopted by HDFC Bank to embed these behaviours into the daily practice of bank employees: • Information security is practiced in daily operations. HDFC Bank management has conveyed its expectations of

employees by stressing the principle of zero tolerance for unacceptable behaviour relating to information security, rewarding good behaviour, recognising and rewarding people for good work towards risk management, and constantly reminding everyone through the tagline “Security is incomplete without U.” This has ensured that information security is practiced in daily operation.

• People respect the importance of information security policies and principles. The security culture has been built over time through constant efforts in creating awareness. Employees now understand the importance of information security and take security initiatives seriously. Audit has also played an important role in enforcing various security policies and principles.

• People are provided with sufficient and detailed information security guidance and are encouraged to participate in and challenge the current information security situation. HDFC Bank believes in engaging all stakeholders in the security effort. Introduction of any new process involves ensuring open interaction with all the affected parties. The issues are discussed in workshops and buy-in is achieved through two-way dialogue—allowing everyone to clarify any doubts they may have. Extensive training is provided for every new information security initiative, not only to the information security group but to all stakeholders.

Figure 7—HDFC Bank 10 Commandments

Volume 1, January 2014 Page 13

Research Update

Recently Released COBIT 5 Materials

• COBIT® 5: Enabling Information

Upcoming First Quarter 2014 COBIT 5 Releases

• Risk Scenarios for COBIT 5® for Risk

Additional COBIT 5 Initiatives in Development

• COBIT® 5 Online: Access to publications in the COBIT 5 product family and to other non-COBIT, ISACA content and current, relevant GEIT material (tentative release second quarter 2014)

• COBIT® 5 for Sarbanes-Oxley (tentative release second quarter 2014)

• Controls and Assurance in the Cloud: Using COBIT® 5 (tentative release second quarter 2014)

• COBIT 5 Online: Ability to customize COBIT to fit the needs of your enterprise with access for multiple users (tentative release third quarter 2014)

For more information on COBIT publications, visit the COBIT 5

page of the ISACA web site.

COBIT 5 translations are available on the COBIT Product

Family page.

• Everyone is accountable for the protection of information within the enterprise. The information security group is responsible for identifying and managing the risk whereas the business heads are held ultimately accountable. This has been clearly documented in the RACI chart discussed earlier. This makes all the stakeholders feel responsible as well as accountable for protection of information within the enterprise.

• Stakeholders are aware of how to identify and respond to threats to the enterprise. Threat identification is part of the training provided to stakeholders. Stakeholders are encouraged to report incidents, e.g., send an email to the ISG about any spam or phishing email received. The response received by the ISG on a day-to-day basis shows the keen awareness of everyone to identify and report incidences.

• Management proactively supports and anticipates new information security innovations and communicates this to the enterprise. The enterprise is receptive to account for and deal with new information security challenges. ISG is constantly engaged in introducing innovations to deal with information security challenges. There is full management support to interact with industry and share knowledge and experience with a larger audience as well as learn from others. This case study is an example of this openness.

• Business management engages in continuous cross-functional collaboration to allow efficient and effective information security programmes. The structure of various committees is an example of continuous cross-functional collaboration. Making information security independent of the IT function has provided a much broader reach and direct access to various business groups across the organisation.

• Executive management recognises the business value of information security. The CISO works at a strategic level, reporting to a senior person in the bank. This has empowered the CISO to drive various information security initiatives with a great amount of freedom. This is a good indication of management’s recognition of the business value of information security.

Leadership as an Influencing Factor In addition, the leadership in HDFC Bank plays a prominent role in building the security culture. Active participation by executive management and business unit management in the various top-level committees where information security is an important agenda item demonstrates the commitment at the top. Participation by leadership in business continuity planning exercises to discuss various disaster scenarios also shows deep involvement.

Vishal Salvi, CISM Has more than 20 years of industry experience, having worked at Crompton Greaves, Development Credit Bank, Global Trust Bank and Standard Chartered Bank before taking on his current role as chief information security officer and senior vice president at HDFC Bank. At HDFC Bank, he heads the information security group and is responsible to provide leadership to the development and implementation of the information security program across the bank.

Avinash W. Kadam, CISA, CISM, CGEIT, CRISC, CBCP, CISSP, CSSLP Is a leading authority on information security. He has four decades of experience in IT management, information systems audit, and information security consulting and training. He is currently advisor to ISACA’s India Task Force. Previously, Kadam served as an ISACA international vice president from 2006 to 2008 and president of the ISACA Mumbai Chapter from 1998-2000. He is the recipient of ISACA’s 2005 Harold Weiss Award.

Volume 1, January 2014 Page 14

Supporting PCI DSS 3.0 Compliance With COBIT 5 By Stefan Beissel, Ph.D., CISA, CISSP The Payment Card Industry Data Security Standard (PCI DSS) aims to improve the security of cardholder data and is required when cardholder data or authentication data are stored, processed or transmitted. The implementation of enabling processes from COBIT® 5 can support compliance to PCI DSS.1 COBIT 5 assists enterprises in governance and management of enterprise IT (GEIT) in general and, at the same time, supports the need to meet security requirements with enabling processes and management activities. The mapping of COBIT 5 enabling processes to PCI DSS 3.0 security requirements facilitates the simultaneous application of COBIT 5 and PCI DSS 3.0 and helps create synergies within the enterprise.

PCI DSS 3.0 PCI DSS was released by the PCI Security Standards Council (PCI SSC), a panel of five global payment brands—American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. PCI DSS also includes requirements for data security and related audit methods. In particular, the primary account number (PAN) is the defining factor in the applicability of PCI DSS requirements.

The goal of PCI DSS is primarily to protect the confidentiality of cardholder data. Confidentiality, as part of the information security triad that includes integrity and availability, is one of the main objectives of information security and protection. Confidentiality is the assurance that data cannot be viewed by or disclosed to unauthorized persons and, thus, be compromised. Measures that are used to protect confidentiality often also protect integrity. For example, if data are

compromised by an attacker or malicious software, integrity will often be affected, too. Integrity is the assurance that data remain accurate and complete and cannot be tampered with or altered by unauthorized means. Availability means that authorized users or systems can access data at any required time. The availability is guaranteed by the systems and infrastructure, which are ready for use and have sufficient capacity to process all requests as quickly as necessary. Attackers can compromise the information availability by flooding a system with service requests and, thus, cause a denial-of-service attack, preventing access to critical information or data.

For credit card processing companies, the setup of a PCI-DSS-compliant environment is necessary because without it a significant part of their business model would not be achievable and significant losses would be incurred. In addition, loss of

Come join the discussion! Stefan Beissel will respond to questions in the discussion area of the COBIT 5—Use It Effectively topic beginning 24 January 2014.

Figure 1—PCI DSS 3.0 Topics and Requirements

Network and Systems

1. Firewall configuration

2. Security parameters

Protection of Cardholder Data

3. Protect stored cardholder data

4. Encrypt transmission

Access Control Measures

7. Restrict access

8. Authentication

Vulnerability Mgmt. Program

5. Antivirus software

6. Secure systems and applications

Monitoring and Testing of Networks

10. Track and monitor

11. Test security

Information Security Policy

9. Restrict physical access

12. Maintain a policy

Volume 1, January 2014 Page 15

reputation and possible fines by credit card companies can be expected. Credit card processing companies are classified into four merchant compliance levels (levels/tiers one to four) relating to the number of transactions affected over a 12-month period.2 Each level has specific PCI DSS compliance requirements. Companies that are classified in levels two to four must perform an annual self-assessment questionnaire (SAQ) and complete a quarterly network scan by an approved scanning vendor (ASV). Companies with an annual number of transactions of six million or more are classified as level one and must create an annual report on compliance (ROC) and be audited by a Qualified Security Assessor (QSA). The result of the audit is documented with an attestation of compliance (AOC).3

The PCI DSS addresses 12 major requirements (figure 1) for control measures that are divided into topics, including network (requirements 1 and 2), protection of cardholder data (requirements 3 and 4), vulnerability management program (requirements 5 and 6), access control measures (requirements 7, 8 and 9), monitoring and testing of networks (requirements 10 and 11), and information security policy (requirement 12). Each requirement is further divided into subrequirements and testing procedures.

In November 2013, version 3.0 of PCI DSS was published. By 2015, compliance to this new version will be binding for all card-processing companies. In comparison to version 2.0, version 3.0 contains changes in the form of additional clarifications, guidance and advanced requirements.4 The 20 advanced requirements are aimed at achieving improvements in the areas of awareness, flexibility and security responsibility.

COBIT 5 COBIT 5 provides a comprehensive framework that assists enterprises in achieving their objectives for GEIT. It helps enterprises create optimal value from IT by maintaining a balance between realizing benefits and optimizing risk levels and resource use.5 The COBIT 5 product family also includes enabler guides, professional guides and a collaborative online environment. The most significant change in comparison to COBIT® 4.1 is the reorganization of the framework from an IT process model into an IT governance framework.

The following chapter maps the PCI DSS 3.0 security requirements to the key, associated COBIT 5 enabling processes. The COBIT 5 process reference model includes processes for GEIT (figure 2).6

COBIT Enabling Processes by PCI DSS Topics Network All sensitive systems must be protected against unauthorized access from untrusted networks. Firewalls are used for securely

separating networks. They control the network traffic and block unwanted access between networks. They can be used locally on workstations or they can be dedicated systems within the network infrastructure.

Use of restrictive configurations can minimize the risk of unauthorized access from outside of the company network. System defaults that are present upon delivery of systems and components represent a security risk. Passwords and other settings that were specified by the manufacturer of the systems are usually widely available and can be exploited by unauthorized persons. Also, a variety of unneeded services are usually activated after the initial installation of operating systems. These services can also be exploited by unauthorized persons. Key enabling processes in COBIT 5 that can help mitigate risk are listed in figure 3.

Figure 2—COBIT 5 Process Reference Model

Processes for Governance of Enterprise IT

Processes for Management of Enterprise IT

Evaluate, Direct and Monitor (EDM)

Align, Plan and Organize (APO)

Build, Acquire and Implement (BAI)

Deliver, Service and Support (DSS)

Monitor, Evaluate and Assess (MEA)

Volume 1, January 2014 Page 16

Figure 3—Network Processes

PCI DSS 3.0 Requirement COBIT 5 Process 1. Install and maintain a firewall configuration to protect cardholder data

APO01.08 Maintain compliance with policies and procedures. APO03.02 Define reference architecture. APO12.01 Collect data. BAI03.03 Develop solution components. BAI03.05 Build solutions. BAI03.10 Maintain solutions. BAI06.01 Evaluate, prioritize and authorize change requests. BAI07.03 Plan acceptance tests. BAI07.05 Perform acceptance tests. BAI10.01 Establish and maintain a configuration model. BAI10.02 Establish and maintain a configuration repository and baseline. BAI10.03 Maintain and control configuration items. DSS01.03 Monitor IT infrastructure. DSS02.03 Verify, approve and fulfill service requests. DSS05.02 Manage network and connectivity security. DSS05.04 Manage user identity and logical access. DSS05.05 Manage physical access to IT assets. DSS05.07 Monitor the infrastructure for security-related events. DSS06.03 Manage roles, responsibilities, access privileges and levels of authority.

2. Do not use vendor-supplied defaults for system passwords and other security parameters

APO01.08 Maintain compliance with policies and procedures. APO03.02 Define reference architecture. BAI03.03 Develop solution components. BAI03.10 Maintain solutions. DSS04.08 Conduct postresumption review. DSS05.03 Manage end-point security. DSS05.05 Manage physical access to IT assets. DSS05.07 Monitor the infrastructure for security-related events.

Protection of Cardholder Data Cardholder data must be stored and displayed only under certain conditions. Relevant requirements address data storage, deletion, encryption and masking (figure 4).

PCI DSS addresses encryption as well as specifics such as handling electronic keys. Where cardholder data are transmitted over open public networks, their encryption is required. If data are transmitted (e.g., via the Internet, wireless networks, Global System for Mobile Communications [GSM], General Packet Radio Service [GPRS]), there is an increased risk that an attacker can eavesdrop and manipulate cardholder data. The application of encryption, as specified, is one of many suggested methods to minimize this risk.

Volume 1, January 2014 Page 17

Figure 4—Processes for Protection of Cardholder Data

PCI DSS 3.0 Requirement COBIT 5 Process 3. Protect stored cardholder data. APO01.06 Define information (data) and system ownership.

APO01.08 Maintain compliance with policies and procedures. APO13.01 Establish and maintain an information security management system (ISMS). APO13.03 Monitor and review the ISMS. BAI08.02 Identify and classify sources of information. BAI08.05 Evaluate and retire information. BAI09.02 Manage critical assets. BAI09.03 Manage the asset life cycle. DSS01.01 Perform operational procedures. DSS04.08 Conduct postresumption review. DSS05.03 Manage end-point security. DSS05.04 Manage user identity and logical access. DSS05.05 Manage physical access to IT assets. DSS05.06 Manage sensitive documents and output devices. DSS06.04 Manage errors and exceptions. DSS06.05 Ensure traceability of information events and accountabilities.

4. Encrypt transmission of cardholder data across open, public networks

APO11.02 Define and manage quality standards, practices and procedures. APO11.05 Integrate quality management into solutions for development and service delivery. BAI03.03 Develop solution components. DSS01.01 Perform operational procedures. DSS01.02 Manage outsourced IT services. DSS01.04 Manage the environment. DSS01.05 Manage facilities. DSS05.01 Protect against malware. DSS05.02 Manage network and connectivity security. DSS05.03 Manage end-point security. DSS05.06 Manage sensitive documents and output devices. DSS06.05 Ensure traceability of information events and accountabilities.

Vulnerability Management The use of antivirus software is required to protect systems against malicious software. It can include pattern-based and behavior-based detection techniques. Pattern-based detection techniques detect viruses only after new virus patterns are updated to the antivirus software. Behavior-based detection techniques can identify malware on the basis of nonconventional behavior patterns, but these detection techniques may be inaccurate and may produce false positives and false negatives.

Development and maintenance of systems and applications must be secure, too. This includes the prevention or elimination of vulnerabilities that can be exploited by attackers to compromise or manipulate cardholder data. Regular installation of patches for operating systems and applications must be done, and secure programming of developments is required. Careful testing ensures that vulnerabilities are found. (See figure 5.)

Volume 1, January 2014 Page 18

Figure 5—Processes for Vulnerability Management

PCI DSS 3.0 Requirement COBIT 5 Process

5. Use and regularly update antivirus software or programs.

APO12.01 Collect data. APO12.03 Maintain a risk profile. DSS05.01 Protect against malware.

6. Develop and maintain secure systems and applications.

APO12.02 Analyze risk. APO12.04 Articulate risk. BAI03.03 Develop solution components. BAI03.05 Build solutions. BAI03.07 Prepare for solution testing. BAI03.08 Execute solution testing. BAI03.10 Maintain solutions. BAI06.01 Evaluate, prioritize and authorize change requests. BAI06.02 Manage emergency changes. BAI06.03 Track and report change status. BAI06.04 Close and document the changes. BAI06.01 Evaluate, prioritize and authorize change requests. BAI07.01 Establish an implementation plan. BAI07.04 Establish a test environment. BAI07.05 Perform acceptance tests. BAI07.06 Promote to production and manage releases. DSS05.01 Protect against malware.

Access Control Measures The access to cardholder data must be restricted depending on appropriate roles as defined by the business need. According to least-privilege and need-to-know principles, only those persons authorized to access cardholder data for business purposes should be permitted access. This requires the implementation of control and authorization management, where each person can be assigned to a role with appropriate permissions (role-based access control [RBAC]) (figure 6).

For each person with system access, the assignment of unique identification (ID) is required. This is usually implemented via personal accounts. Only a person who can be successfully authenticated using a password, token or other authentication method will be allowed to access a computer or system.

Physical access to cardholder data must also be restricted. Trespassers who gain entry to offices or data centers could steal, damage or manipulate media or computer components. Media can include electronic media (such as diskettes, CDs and hard disks) as well as paper. With physical access control and the visible wearing of badges, unauthorized persons can be distinguished from authorized users.

Figure 6—Processes for Access Control Measures

PCI DSS 3.0 Requirement COBIT 5 Process 7. Restrict access to cardholder data by business need-to-know.

DSS05.04 Manage user identity and logical access.

8. Assign a unique ID to each person with computer access.

APO03.02 Define reference architecture. APO07.01 Maintain adequate and appropriate staffing.

Volume 1, January 2014 Page 19

9. Restrict physical access to cardholder data. APO01.06 Define information (data) and system ownership. DSS05.04 Manage user identity and logical access. DSS05.05 Manage physical access to IT assets.

Monitoring and Testing of Networks All access to network resources and cardholder data must be tracked, monitored and logged (figure 7). With protocols, unauthorized access can be identified and traced. In addition, they are helpful for technical failure analysis. The PCI DSS requires logging of every access to cardholder data.

Security systems and processes need to be regularly tested. This includes regular scanning for security vulnerabilities and attack vectors. These threats must be identified and removed before they can be exploited by a would-be attacker.

Figure 7—Processes for Monitoring and Testing of Networks

PCI DSS 3.0 Requirement COBIT 5 Process 10. Track and monitor all access to network resources and cardholder data.

DSS01.01 Perform operational procedures. DSS01.03 Monitor IT infrastructure. DSS04.08 Conduct postresumption review. DSS05.04 Manage user identity and logical access. DSS05.05 Manage physical access to IT assets. DSS05.06 Manage sensitive documents and output devices. DSS05.07 Monitor the infrastructure for security-related events. DSS06.04 Manage errors and exceptions. DSS06.05 Ensure traceability of information events and accountabilities.

11. Regularly test security systems and processes.

APO03.02 Define reference architecture. APO12.03 Maintain a risk profile. APO12.01 Collect data. DSS02.01 Define incident and service request classification schemes. DSS05.07 Monitor the infrastructure for security-related events. MEA01.02 Set performance and conformance targets. MEA01.03 Collect and process performance and conformance data. MEA01.04 Analyze and report performance. MEA02.01 Monitor internal controls. MEA02.02 Review business process control effectiveness. MEA02.03 Perform control self-assessments. MEA02.04 Identify and report control deficiencies.

Information Security Policy An information security policy must be created and maintained by each company and communicated to, and followed by, all employees (figure 8). It contains requirements for information security to which all employees are bound. Topics in an information security policy include the communication of the PCI DSS requirements, the training for security awareness, the establishment of an incident response plan and the monitoring of the security posture of service providers.

Volume 1, January 2014 Page 20

Figure 8—Processes for Information Security Policy

PCI DSS 3.0 Requirement COBIT 5 Process 12. Maintain a policy that addresses information security for all personnel.

APO01.01 Define the organizational structure. APO01.02 Establish roles and responsibilities. APO01.03 Maintain the enablers of the management system. APO01.05 Optimize the placement of the IT function. APO01.06 Define information (data) and system ownership. APO13.01 Establish and maintain an ISMS.

Conclusion Companies that store, process or transmit cardholder data or authentication data must comply with security requirements of PCI DSS. By using COBIT 5, these companies can cover PCI DSS 3.0 security requirements with COBIT 5 enabling processes. From another point of view, they can use the PCI DSS 3.0 security requirements to facilitate a COBIT 5 implementation and achieve objectives for GEIT. In both ways, these synergies help to optimize risk levels and resource use.

Stefan Beissel, Ph.D., CISA, CISSP Is an IT security officer, responsible for the management of security-related projects and compliance with PCI DSS, at EVO Payments International.

Endnotes 1 The objective of this article is to provide a broad-brush review of the synergies between COBIT 5: Enabling Processes and PCI DSS 3.0. Cursory

knowledge of the PCI DSS, PCI Security Standards Council (PCI SCC), COBIT 5 product family and associated enabling guidance will be helpful. 2 Visa, “Compliance Validation Details for Merchants,” 2012 3 PCI SSC, Payment Card Industry (PCI) Data Security Standard—Requirements and Security Assessment Procedures, Version 3.0, 2013 4 PCI SSC, “Payment Card Industry (PCI) Data Security Standard—Summary of Changes from PCI DSS Version 2.0 to 3.0,” 2013 5 ISACA, COBIT 5, 2012 6 ISACA, COBIT 5: Enabling Processes, 2012

Developing a Governance Framework for the Global Support Organisation at GlaxoSmithKline, Using COBIT By Steve Williamson Like most innovation-led organisations, GlaxoSmithKline (GSK) is highly dependent on IT. Its large, centralised IT support group has used COBIT® 4.1 as the basis for developing an organisational IT governance framework. GSK is beginning its transition to COBIT® 5.

The mission of GSK is ‘to improve the quality of human life by enabling people to do more, feel better and live longer’. In support of this mission, GSK develops and makes pharmaceuticals to treat a range of conditions including respiratory diseases, cancer, heart disease and epilepsy. GSK researches and makes vaccines that protect against infectious diseases, including influenza, rotavirus, cervical cancer, measles, mumps and rubella. It makes innovative consumer health care

Come join the discussion! Steve Williamson will respond to questions in the discussion area of the COBIT (4.1 and earlier)—Use It Effectively topic beginning 24 January 2014.

Volume 1, January 2014 Page 21

products, with a portfolio that includes well-known brands such as Horlicks, Panadol and Sensodyne. GSK is a global company operating in more than 115 countries with approximately 100,000 employees.

One of GSK’s strategic priorities is to simplify its operating model by reducing complexity and thereby becoming more efficient. This will free up resources to invest in other, more productive, areas of the business. One of the outcomes of this strategy is a more centralised IT organisation, offering standard IT support services to all business areas.

The application support group was formed by merging a number of autonomous, business-facing IT groups and is responsible for a portfolio of more than 2,000 applications supporting every stage of the value chain (research, development, manufacturing, commercial and corporate functions). This department has several hundred permanent staff, based at different locations worldwide. Additional technical support is provided from two offshore business partners.

The application support department has developed a governance framework for GSK.

Governance for an IT Support Function Shortly after the formation of the new global support department, the need for an evaluation of governance processes was identified. The aim was to verify that the newly formed organisation has the right structures, processes and controls in place to enable successful execution of its strategy, and to ensure alignment with the enterprise strategy.

Organisational governance is a commonly accepted management term, which most people loosely understand. However, trying to define precisely what IT governance is and how it applies to an IT organisation is in itself a challenge. Thus, reference to commonly accepted industry frameworks is useful. In this case, GSK’s application support department utilized COBIT® (version 4.1 was used for this exercise).

ISACA defines IT governance as, ‘The responsibility of executives and the board of directors; consists of the leadership, organizational structures and processes that ensure that the enterprise’s IT sustains and extends the enterprise’s strategies and objectives’.1

Why COBIT? One of the advantages of COBIT 4.1 is that it is a framework that is strongly focused on control rather than execution. It covers a broad range of governance areas (e.g., human resources, finance, strategic alignment, risk management, service management) and can be mapped to other industry standards, such as ISO 27001 for security and ITIL for service management, which made it a good fit for GSK.

How GSK Used COBIT 4.1 COBIT 4.1 is comprehensive, yet simply structured, with each process area sub-divided into process description, control objectives, management guidelines and maturity models. This makes it easy to select the processes that are most applicable to the organisation’s goals and ignore those that are either not relevant or of lesser importance. For example, the COBIT processes PO2 Define the information architecture and PO3 Determine technological direction are the primary responsibility of another department within the enterprise, so these were excluded from the application support department’s framework, and other COBIT 4.1 processes had only partial applicability.

The application support department took the following steps to create its governance framework: 1. Identify the applicable process areas from COBIT 4.1. 2. Identify the applicable control objectives within each process area. 3. Perform the risk assessment, i.e., ascertain the impact to the organisation of control failures in each process. 4. Identify which existing processes, procedures or working practices address this process area, and evaluate against the

control objectives. 5. Review with subject matter experts and senior management, including those responsible for implementing the controls. 6. Document any gaps or weak controls, describing the risk and input this information into the relevant process improvement

work stream.

When control weaknesses are identified, it normally indicates that a policy is not being implemented effectively. This identifies the need for corrective action, which is the responsibility of management. This type of analysis could reveal a more fundamental problem, such as a previously unrecognised or an inadequately mitigated risk. In such a situation, the corrective action would be changes to the policy framework. Such actions would not be addressed by management, but by the compliance board. This could result in new or amended policies and/or decisions relating to the risk tolerance.

Volume 1, January 2014 Page 22

The governance framework is structured by IT governance focus areas (mapped to COBIT process areas) and includes the following: • IT organisation and relationship governance • The strategic alignment of business and IT objectives • Quality, risk and control policies framework • Communications, training and knowledge management • Investment portfolio, financial management and value delivery governance • System development, deployment and maintenance • Third-party services/supplier management

For each governance focus area, control objectives, key risk factors and implementation were defined (figure 1).

Figure 1—Structure of Governance Focus Area

Section Description

Control objectives These were taken directly from COBIT 4.1. Applicable control objectives were selected (excluding those that had only a tenuous association).

Key risk factors This is the analysis of organisational impacts from failure to effectively meet control objectives. Example risk impacts include operational inefficiencies, increased likelihood of security breaches, regulatory failure and legal penalties.

Implementation This section described the procedures, controls and organisational structures that were currently in place and addressed the control objectives. This revealed gaps and weaknesses.

One may ask, why go to the trouble of creating a separate document rather than using the COBIT material directly? The reason is that having a framework with familiar business context allows it to be more intuitive to those who need to use it. Its purpose is to evaluate GSK’s processes against a commonly accepted standard for governance, not to redefine metrics or introduce new ways of working. This ensured the document is meaningful to a wide range of people, most of whom have little or no experience using COBIT.

Findings and Derived Value Control objectives can be met by a procedure (e.g., change control process) or through effective organisational structures (e.g., representation on leadership teams), which clearly demonstrated accountability and control. However, during the analysis, the application support department found that some control objectives are being effectively met through nonprocedural methods. Although less formal than a management-approved procedure, most of these methods were documented or implied as part of job descriptions, thus demonstrating accountability.

Determining whether or not a procedure addresses the needs of the control objective is relatively easy. Judging the overall effectiveness of a procedure across a newly consolidated IT department is more difficult without extensive data gathering or audit. As a means of addressing this, newly implemented monitoring activities were used to assess the effectiveness of the mitigation techniques and they were the key source of information, making possible ongoing programme improvement.

In 2013, a department-wide governance audit was performed. This framework document was the basis for audit preparedness. It did not cover everything the auditors assessed, but it helped demonstrate the adequacy of the controls structures in place.

Next Steps The framework gives a point-in-time evaluation of the application support department’s controls and allows for the identification of threats, vulnerabilities and inefficiencies, risk factors, and issues (which would have otherwise gone unnoticed). It will be maintained in line with organisational changes (e.g., if the organisation starts to offer a broader range of IT services, the framework can easily be expanded).

The next evolution of this governance model will include process capability assessment models for key process areas. The COBIT 5 process assessment model will be the basis for designing and implementing these models. This also marks the transition to COBIT 5. The process areas selected for capability assessments are those that would have the greatest risk impact if they failed to operate effectively. As before, the models will be based on COBIT, but will reference GSK’s metrics and processes. The first step is to perform a baseline assessment to determine current maturity levels, and then long-term

Volume 1, January 2014 Page 23

Framework Committee Steven A. Babb, CGEIT, CRISC, ITIL, UK, chair David Cau, ITIL, MSP, Prince2, France Sushil Chatterji, CGEIT, Singapore Frank Cindrich, CGEIT, CIPP, CIPP/G, USA Joanne De Vito De Palma, USA Jimmy Heschl, CISA, CISM, CGEIT, ITIL, Austria Katherine McIntosh, CISA, USA Andre Pitkowski, CGEIT, CRISC, OCTAVE, Brazil Paras Shah, CISA, CGEIT, CRISC, CA, Australia

Editorial Content Comments regarding the editorial content may be directed to Jennifer Hajigeorgiou, senior editorial manager, at jhajigeorgiou@isaca.org.

COBIT Focus is published by ISACA. Opinions expressed in COBIT Focus represent the views of the authors. They may differ from policies and official statements of ISACA and its committees, and from opinions endorsed by authors, employers or the editors of COBIT Focus. COBIT Focus does not attest to the originality of authors’ content.

© ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Please contact Julia Fullerton at jfullerton@isaca.org.

improvement objectives will be established to ensure continued process improvement over the next five years.

Steve Williamson Is the director, IT risk management, at GlaxoSmithKline, responsible for information security, regulatory compliance and quality management. Williamson started his IT career 25 years ago as a software tester in the banking industry. Williamson has been with GSK for the last 16 years in various project management and governance, risk and compliance roles.

Endnotes 1 ISACA, Glossary

©2014 ISACA. All rights reserved.