• Bookmark

Leveraging COBIT to Implement Information
Security (Part 3)

By John Frisken, CISA, CA

COBIT Focus | 31 August 2015

This article is a continuation of the article originally published 4 May 2015 called ‘Leveraging COBIT to Implement Information Security’. Part 1 covered how COBIT 5 can be used to establish the overall framework for the collaboration of technical standards such as the IT Infrastructure Library (ITIL), ISO/IEC 27001 and SANS Critical Security Controls. Part 2 focussed on using COBIT to implement information security process controls within an ITIL system to provide protection envisaged by SANS Critical Security Controls. Part 3 looks at how to implement an information security management system (ISMS) governance framework and enable tools to manage the security program.


The implementation of an ISMS is designed to assist in the management of the large number of activities that need to be coordinated, recorded and followed up to maintain security. In the context discussed here, it is envisaged that controls within the system are selected by management on a risk-assessed basis to address the perceived threats to the security of the organisation’s core business processes. Once selected, the ISMS is the basis for collecting evidence for operation and reviewing the efficacy of the implementation on an ongoing basis as part of the security forum. The forum is created by senior management, typically the chief executive officer (CEO), as a collaborative round table where managers from IT security, IT, human resources (HR) and major business functions can come together to make decisions on the basis of regular reporting from the system.


Figure 1 provides a snapshot of what a typical ISMS may look like for a specific control objective; in this example, the objective is access control. This example uses ISO 27001 as the control objectives framework; however, conceptually, any other control framework, including COBIT, could be used as long as it is suitable, a judgement that management, IT security and internal audit need to make. In the ISMS presented in this example the COBIT Responsible, Accountable, Consulted, Informed (RACI) Matrix is used (refer to section E in figure 1) as a technique for designing and embedding controls around the business process (refer to section B in figure 1). This fact means that it would be quite normal to borrow many features from COBIT when considering the design and implementation of the security controls within the information security master plan, the key document coordinating the policies, controls, work instructions and forms (refer to sections C and D in figure 1) for addressing information security.


Figure 1—Information Security Management System Overview

View Large Graphic
Source: John Frisken. Reprinted with permission.


Another key aspect of this ISMS is the internal workflow of accountability and review (refer to section A in figure 1) that occurs as part of the operation of the ISMS. This is based on the Plan-Do-Check-Act (PDCA) model and refers to documenting who needs to be involved in the operation of the selected controls. This is important, because controls do not operate in isolation within organisations—someone needs to ensure they are working and be accountable if they do not work, ensuring that the gap is addressed. In this example, the organisation has selected information security agreements (similar to service level agreements [SLAs] as used in ITIL) to summarise the responsibilities of each key manager within the organisation to ensure that they are fully informed about how they are required to participate to maintain security within the organisation. These individuals will have a representative on the forum, and therefore, they will have a voice about how well this process is working.


Having outlined how the ISMS is designed to work, the questions arise as to how this is practically implemented as part of the organisation’s management systems, how people are trained and motivated to operate the controls, and where the evidence for the operation of the controls is kept. These are a few of the questions that senior managers have asked over the years with regard to operating an ISMS.


The author was advising an organisation that operated critical national infrastructure. In this organisation, the managers were aware of the need for information security (it was self-evident given its prominent role in society), but there was concern about the costs and efficiency of operating a major system to address such a singular focus. It was this challenge that resulted in the author working with senior management to find an alternative to maintaining massive spreadsheets for documenting who was doing what and where the evidence was maintained. Through this process, the concept of the information security agreement was developed, which became the main accountability document for evidencing the discharge of management’s information security responsibilities.


What was created was a set of activities that each manager was required to take responsibility for and focus on implementing. Managers could maintain the evidence for the operation of the controls in whatever way they believed was appropriate. This evidence provides the information security officer (as well as the internal and external auditors) a point of reference for inspecting those controls as part of the ongoing audits and reviews that the ISMS activities set out in the calendar. Issues discovered were then recorded within the ISMS for follow-up and action and included in the formal forum reporting. Auditors typically would review the forum reports and registers of the ISMS and focus their activities on key risk and adverse findings that came to light during the operation of the ISMS. The objective of this exercise is to optimise the operation of the system through the involvement of each of these functions in a structured and managed way using the system.


The design of the information security organisation is shown in figure 2. This graphic shows the various organisational personnel involved in carrying out information security and shows representative activities and functions for each.

Figure 2—Information Security Program (ISP) Overview

Source: John Frisken. Reprinted with permission.


The green boxes represent more general security activities that are undertaken by end users or their representatives, depicted by the green stick persons.


The blue activities are those that require a more technical understanding of information security concepts or technology generally. They are undertaken by information security or IT specialist personnel seconded from IT or contracted to specialists.


The yellow activities are those undertaken by risk management or control specialists with an understanding of the IT security vulnerabilities and control techniques. These activities are usually undertaken by a dedicated information security officer or personnel seconded or contracted to him/her, especially for the more specialised activities.


The red boxes are the checking or compliance activities that are involved in ensuring that the various controls and processes have been appropriately implemented and are working effectively.


Having outlined how the security program operates (supported by the ISMS), decisions need to be made about how these activities and systems are to be implemented. There are no right answers; however, some answers are often found in how the organisation addresses other processes such as quality, safety, occupational health and safety, incident management, or the US Sarbanes-Oxley Act of 2002 and other legislated requirements that are often well supported with systems to manage policies, work instructions, and the collection of evidence around deviations, noncompliance and corrective action.


Many aspects of the operation of the information security controls and processes can be automated using specialised tools (refer to Part 2 of this series of articles). This releases personnel from activities associated with doing controls and allows them to focus on higher-value activities associated with review/enforcement, consultation/advice and training.


The inclusion of project managers and architects as key roles within information security is because security begins at project conception and must be built into the design—it is not an afterthought.


Methods such as the Comprehensive, Lightweight Application Security Process (CLASP) by the Open Web Application Security Project (OWASP), Sherwood Applied Business Security Architecture (SABSA), or COBIT 5 for Information Security by ISACA are all powerful open source frameworks that describe how to build security in as part of application life cycle management (ALM) to provide reliable and secure applications that continuously conform to the outcomes required by users and stakeholders throughout their life. Figure 4 sets out a high-level overview of CLASP design security in design principles that guide organisations in how to build in security, step 2 of the security planning process described in figure 3.


Figure 3—Information Security Involvement in the Systems Development Planning Process

Source: John Frisken. Reprinted with permission


Figure 4—Developing Information Security Requirements

Source: John Frisken. Adapted from CLASP version 2.0., OWASP, March 2006. Reprinted with permission.


The final point to make is that given the importance of information security during the design and construction phases, considering information security as a cross-domain function operating as a core program management office (PMO) advisory team is a powerful way to ensure that information security is well understood and the security team is kept informed of corporate plans and strategies.


Conclusion

COBIT facilitates the development of the governance framework within which the information security function makes assessments around risk and priorities for information security, permitting multiple technical standards to operate within the organisation. In the design of the controls and their embeding within the organisation, COBIT’s RACI techniques allow for controls to be designed taking into account requirements from multiple standards and implemented within a cohesive framework for ongoing review and enforcement.


Author’s Note

This case study has been developed based on a real client situation in Australia. The name of the organisation and some other identifying information have been removed. All material is either owned by Information Systems Group Pty Limited or used with permission.


John Frisken, CISA, CA

Is an application development specialist with a distinguished career in professional practice with Ernst & Young and, subsequently, as founder and owner of the Information Systems Group, an international systems integration and applications development company headquartered in Sydney, New South Wales, Australia. Since establishing ISG in 1996, Frisken has overseen the development of ISG’s services through delivery of complex applications leveraging advanced messaging and secure platform technologies in NSW Health and Toyota Motor Corporation. He currently serves as ISG’s director of professional services.

THIS WEBSITE USES INFORMATION GATHERING TOOLS INCLUDING COOKIES, AND OTHER SIMILAR TECHNOLOGY.
BY USING THIS WEBSITE, YOU CONSENT TO USE OF THESE TOOLS. IF YOU DO NOT CONSENT, DO NOT USE THIS WEBSITE. USE OF THIS WEBSITE IS NOT REQUIRED BY ISACA. OUR PRIVACY POLICY IS LOCATED HERE.