computers & security 26 (2007) 4455

available at www.sciencedirect.com

journal homepage: www.elsevier.com/locate/cose

Bridging the gap between general management and technicians A case study on ICT security in a developing country5
Jabiri Kuwe Bakari*, Charles N. Tarimo, Louise Yngstro m, Christer Magnusson, Stewart Kowalski
Department of Computer and System Sciences, Stockholm University/Royal Institute of Technology, Forum 100, SE-164 40 Kista, Sweden

abstract
Keywords: ICT security management Organisations Management Technicians Perception problem ICT-related risks The lack of planning, business re-engineering, and coordination in the whole process of computerisation is the most pronounced problem facing organisations. These problems often lead to a discontinuous link between technology and the business processes. As a result, the introduced technology poses some critical risks for the organisations due, in part, to different perceptions of the management and technical staffs in viewing the ICT security problem. This paper discusses a practical experience on bridging the gap between the general management and ICT technicians. 2006 Elsevier Ltd. All rights reserved.

1.

Introduction

The paper outlines a successful mission of how to bridge the gap between general management and ICT technicians. It is based on practical experiences obtained from an ongoing study which aims at developing guidelines for managing ICT security in organisations generally. The study was initially conducted in mid-2004 in ve organisations in Tanzania in order to make preliminary observations. Later, at the beginning of 2005, one organisation was earmarked as a test-bed for further observations and here we present some of the ndings. The organisation is a government-based service provider operating in 21 out of 26 regions in the country. The organisation has 900 staffs in total and its operations are based on four core services, where three of them are greatly dependent on ICT to

meet their intended objectives. The organisation has approximately 2 million customers scattered throughout the country with approximately 25% active customers. The study was guided by using the Business Requirements on Information Technology Security (BRITS) framework where risks are viewed as part of the actual business rather than primarily as part of the ICT, used together with the Security by Consensus (SBC) model where ICT security is viewed as a social technical problem (Kowalski, 1994; Magnusson, 1999; Bakari, 2005). BRITS is a systemic-holistic framework, combining nance, risk transfer, IT and security in a coherent system. The framework attempts to bridge the gap between top management and IT personnel by translating the nancial language into the IT and IT security languages, and vice versa. The translation is achieved by making use of a repository of

The paper was originally presented and published in the Security Culture Workshop at the IFIP SEC2006. This is an updated version. * Corresponding author. Tel.: 46 08 674 72 37; fax: 46 08 703 90 25. E-mail addresses: [email protected] (J.K. Bakari), [email protected] (C.N. Tarimo), [email protected] (L. Yngstrom), [email protected] (C. Magnusson), [email protected] (S. Kowalski). 0167-4048/$ see front matter 2006 Elsevier Ltd. All rights reserved. doi:10.1016/j.cose.2006.10.007

computers & security 26 (2007) 4455

45

mitigation suggestions, hosted in the Estimated Maximum IT Loss (EMitL) database (Magnusson, 1999; Bakari et al., 2005a,b). In the study the SBC model was used to view and explain security problems as layers of social and technical measures. In addition to these two methods, we also at different stages of the study made use of other methods, namely Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE), ITIL (IT Infrastructure Library), Control Objectives for Information and related Technology (COBIT) and the internationally recognised generic information security standard, comprised of a code of practice and a specication for an information security management system (ISO 17799). OCTAVE is a risk-based strategic assessment and planning technique for ICT security (Alberts and Dorofee, 2003). ITIL is a framework for IT management and COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks (ITIL, 2005; ISACA, 2005; ISO 17799). The ndings are organised in a list of 10 initial steps or aspects of importance to successfully bridge the gap. The presentation highlights the motivation and practical experiences of each step.

2. The ten aspects of importance in bridging the gap between the management and technicians
In this section, the 10 steps are introduced and later the experience encountered when executing each step is presented. The steps include: (i) Getting top managements backing (the chief executive ofcer (CEO) buying into the idea rst) (ii) Getting technical management backing (the technical department is the custodian of ICT in an organisation) (iii) Setting up the special ICT security project team (start by forming a provisional ICT security task force) (iv) Quick scan of the ICT-related risks and their consequences for the organisation (risk exposure due to ICT) (v) Getting managements attention and backing (the management as a whole need to buy into the idea as well) (vi) Getting the current status of ICT security documented (take stock of the existing situation) (vii) Conducting awareness-raising sessions (to allow staffs to recognise ICT security problems and respond accordingly) (viii) Carrying out risk assessment/analysis (ix) Working out the mitigation plan (short-term plan for issues that need immediate attention and long-term plan) (x) Developing countermeasures

security in organisations as suggested in some studies (Alberts and Dorofee, 2003; Caralli, 2004; Solms and Solms, 2004; Solms, 2005) and also appears as an important factor in corporate governance as discussed in Control Objectives for Information and Related Technologies (COBIT) by Information Systems Audit and Control Association (ISACA). However, getting an appointment to meet the CEO and talk about ICT security was not easy. In most cases, we were directed to see the IT director or chief security ofcer. Here one needs to be patient and accept a long-awaited appointment to see the CEO who is always busy and in this case the time slot would be only 10 15 min. Nevertheless, we achieved our goal of meeting them and introduced our agenda on what ICT-related risk is all about and what the challenges are in managing such types of risks. Further, the consequences of not managing such risks for the shareholder value were also discussed, emphasising that todays CEOs will be responsible to their board for the state of ICT security in their organisations. All these were discussed with respect to risk exposure to key performance indicators which may affect the organisation from reaching its mission and business objectives. An example of risk exposure discussed was the problem of business interruption which can be propagated through to the balance sheet with great nancial implications and cause embarrassing media coverage, loss of condence by customers and staffs, resulting in loss of credibility.

2.2. Step 2: getting technical management backing (technical departments are the custodians of ICT in an organisation)
It was hard and in most cases almost impossible to talk about ICT-related issues in the organisation without the permission of its IT department. This was mainly due to a perception problem which is also discussed in Bakari et al. (2005a) where the complex problem of ICT security has been relegated to the IT department or rather treated as a technical problem, with no relevant and operational organisation-wide ICT security policy and procedures. Most of those we asked for an appointment gave the following reaction: Have you consulted the IT department? On the other side, the technical staffs are aware of the ICT security problems, though mostly as a technical concern and not as a business concern. In order to get their support, we had to describe the security problem more holistically, i.e. including both technical and non-technical issues and the reasons why we should include and talk to other departments as well. Our observation indicated that the difference in perception between the management and the technical department made it difcult for the technical department to address the problem adequately. An attempt was made by Bakari et al. (2005b) to address this perception problem using EMitL tool as suggested in the BRITS framework by Magnusson (1999). Getting technical staffs to understand the non-technical components of the problem and how to communicate the problem to the management as risk exposures which needed its attention was yet another important step to take. There were concerns from senior technical staffs on how we were to make the management understand the problem, and what language to use for them to understand.

2.1. Step 1: getting top managements backing (the CEO buying into the idea rst)
ICT security appeared to be a new concept to most CEOs in the organisations studied. As conrmed by numerous researches, management backing is important in any effort to improve

46

computers & security 26 (2007) 4455

This was asked by senior staffs, when we were preparing to meet the management team in one of the talks (step 5).

2.3. Step 3: address the ICT security problem as a special project (forming a provisional ICT security task force)

Organisations can no longer be effective in managing security from the technical sidelines. Security lives in an organisational and operational context, and thus cannot be managed effectively as a stand-alone discipline. Because security is a business problem, the organisation must activate, coordinate, deploy, and direct many of its existing core competencies to work together to provide effective solutions. (Caralli, 2004) After succeeding in getting the support of the top management and technical management, the important question at this stage was how or where do we start? It was at this stage that we formed the special ICT security project team. The composition of the team included three technical staffs (software, network and hardware), one legal ofcer, one internal auditor, one security (physical/traditional) ofcer, and one member of staffs from operational departments (where core services of the organisation are processed). Also one more member of staffs from the insurance department was in the team purposely for risk management as there was no department other than insurance to handle/manage risks in the organisation. All team members were senior members of staffs who have worked with the organisation for more than ve years. The main question we faced here was then why to choose staffs from these departments? Our response was based on the facts below and which are also similar to OCTAVE (Alberts and Dorofee, 2003) principles, where the interdisciplinary ICT security project team is staffed by personnel from the organisation itself: Technical: partly the ICT security problem is a technical issue which could be a result of software, hardware or network problems. In the case of software, there are mostly two fundamental problems, one that affects the application system software and the other that affects the Operating System software. Both could be as a result of the introduction of malicious software (virus, worms, etc.) or system failure, either due to power failure or some other reasons. In the case of hardware, there could be physical damage, a power problem or the hardware or part of it being stolen. Network security can be a combination of both; problems that affect the software and hardware parts of the network. Technical staffs who are working in these sections would be in a good position to give more information about their experience regarding ICT security from a technical point of view. Auditors: traditionally, auditors are used to audit the nancial transactions or operational processes and compliances to laws and regulations, policies, standards and procedures. Given the nature of their work they can also stand back and see the big picture concerning the risk exposure facing an organisation. Auditing ICT is usually considered operational. The one prime focus for ICT audit is security evaluating whether the condentiality, integrity and availability of data and services are ensured through the implementation of

various controls (ISACA, 2005). It also involves evaluating the realisation of benets to the business from its investment in IT. Apart from building capacity for internal ICT audit, including the transition from traditional auditing to a hybrid type of auditing (meaning the auditing includes information systems), informed corporate auditors can be in a better position to provide the information needed to advise the management on the importance of paying more attention to ICT security management than technicians advice. Legal: as the dependency on ICT in an organisation grows, legal issues such as liabilities, in particular computer/cyber crime (a violation of the law committed with the aid of, or directly involving, a computer or data processing system) are becoming an indispensable part of ICT risk management. Involvement of a legal ofcer in the team facilitates in addressing the ICT security problems from a legal perspective. Security: most of the security departments particularly in the studied organisations still value physical assets, which means that security strategies end up taking more care of tangible assets than intangible ones. For example, currently CCTVs (close-circuit TVs) are installed in the reception area and along the corridors but not in the server rooms which keep valuable information assets. This situation as revealed here discourages one from stealing tangible company assets from the building as there is a chance of being seen. However, for someone who aspires to steal information assets, will have a free ride. By not having the server rooms monitored properly apart from those who can compromise the assets through the network it is implied that the security monitoring system is meant for outsiders. Thus, the involvement of physical security staffs helps to identify what needs to be re-engineered for the existing security in the organisation. Operations: operations is where the core services of the organisation take place. Thus, operations can be an area where the greatest adverse impact on the organisations mission and business objectives can be observed. In our work we considered having a senior member of staffs from the operations department who is fully knowledgeable of operational transactions. His participation in the team assists in highlighting the operational processes and identifying critical areas of operation. This is an important component in the risk assessment exercise. Insurance/risk manager: ICT security management is basically risk management focusing on ICT mainly how to insure valuable assets, including ICT assets. Human resources: human elements in security tend to be the weakest link in any security chain, even where the best technical security controls are in place (Bishop, 2003). A simple social engineering action, which is a result of not ensuring that staffs are aware of the risks and are familiar with sensible and simple security practices, can ruin the organisations credibility. Therefore, a strong ICT security management programme cannot be put in place without signicant attention being given to human resources. People from the human resources department/unit are responsible for personnel security which, according to ISO 17799, covers not only permanent and temporary staffs of the organisation but also extends to contractors, consultants and other individuals working on the organisations premises or using the organisations information and information processing assets.

computers & security 26 (2007) 4455

47

Furthermore, the human resources department is responsible for recruitment, terms and conditions of employment, including job descriptions and termination. It is also responsible for awareness-raising and training of staffs on security policy, procedures, and techniques, as well as the various management, operational and technical controls necessary and available to secure ICT resources, once such measures are in place (Wilson and Hash, 2003). Inclusion of a human resource person in the team from the beginning helps to take into consideration the human aspects of the security problem from the outset, when designing the ICT security management programme. Finance: there are two main reasons why nance should be considered. First, all operations of the organisation depend on nancial transactions. The roles and responsibilities of staffs vary as compared with other departments due to the nature of their work nancial transactions. Unclear roles and responsibilities can be tolerated in the manual system but not in the computerised nancial information system. Secondly, in most cases the end result of any security incident has nancial implications; sometimes damage can be propagated to the organisations nal balance sheet. Selection criteria: generally, the selection was strictly of staffs who have spent a substantial amount of time in the area of consideration and who are also ICT literate, for example, senior auditor with some general computer knowledge. The team was subjected to several orientations about ICT security management in general with reference to the organisation.

2.4. Step 4: quick scan of the ICT-related risks and their consequences for the organisation (risk exposure due to ICT)
Before meeting the management as a whole, we needed some kind of justication or evidence of ICT-related risks and their consequences for the organisation. This was obtained by rst working out some facts on the likely consequences of ICTrelated risks for the organisation. We achieved this by carrying out a quick scan of such risks with the help of the ICT security team. This exercise involved capturing information

on what the organisation is doing and how its core services are linked to the use of ICT and hence what kind of risk exposures and their consequences for the organisation. Faceto-face interviews with the CEO, chief nancial ofcer (CFO), IT managers and the heads of the departments involved in the provision of the core services were conducted. Our interview questions were based on OCTAVE processes 1 and 2, which are primarily for gathering information on the senior managements and operational area managements views of ICT assets, areas of concern, security requirements, current security practices and current organisational vulnerabilities. The two processes are among the four used in OCTAVE phase 1 when building asset-based threat proles of an organisation as detailed in Alberts and Dorofee (2003, p. 46). We used the collected information to gure out how the organisations objectives are supported by ICT assets and in turn what are the possible risks to, and consequences for, the organisations business objectives as shown in Fig. 1. We also made use of EMitL tool in an attempt to translate what management sees as damage exposure to corresponding ICT-related risks and hence ICT security properties as shown in Fig. 2. The tool helped to interpret the technical terminologies of the consequences of losses in the corporate value, based on nancial indicators. This interpretation was based on three groups of damage exposure due to ICT risks, namely liability claims, direct loss of property and business or service interruption; also explained in the works by Bakari and co-workers (2005, 2005b). The damage exposures are in turn mapped to ICT security properties.

2.5. Step 5: getting managements attention and backing (the management as a whole buy into the idea as well)
The management had to be convinced and understand that their organisation was vulnerable to ICT-related risks. Furthermore, we had to educate them on the magnitude of the security problem, and insist that ICT security was more than technology and more of a human issue. This means it

Fig. 1 Deriving risks to, and consequences for, the organisations business objectives.

48

computers & security 26 (2007) 4455

Fig. 2 Business damage exposure mapped to ICT security properties.

has something to do with the kind of policies and procedures that were in place in the organisation; the type of administration in place, the legal and contractual obligations the organisation had, particularly in delivering services, and also the ethics and culture of the individual staff member. The objective of this step was achieved by presenting to the

management the worked-out status of their ICT security obtained in step 4. Diagrammatic representation of the problem and how ICT security was being addressed in their organisation helped to get their attention. Fig. 3 shows how the problem was perceived on the lefthand side; and on the right-hand side of the gure can be

Fig. 3 How the ICT security problem was perceived and the way it was addressed.

computers & security 26 (2007) 4455

49

seen a holistic view of the ICT security problem, with people sandwiched between the social and technical aspects, being an extension of SBC model (Kowalski, 1994). For example, we were able to show to the management team, which constituted the CEO, CFO, human resources manager, chief legal ofcer, chief security ofcer, chief internal auditor, operational manager, and planning and investment manager, technical managers and other managers, where and how their functions t into the model. We also highlighted the problem in each dimension and discussed their role in managing the problem with respect to their positions in the organisation. This was approximately a one-and-a-half hour session with the entire management team. The fact that ICT security management is a multidimensional discipline, as depicted in Fig. 3, was emphasised. We were able to convince the management that this is a business problem, with an ethical/culture dimension, an awareness dimension, a corporate governance dimension, an organisational dimension, a legal dimension, an insurance dimension, a personnel/human dimension, an audit dimension, and nally a technical dimension, also discussed in length in the study by Solms and Solms (2004). It is a socio-technical problem (Kowalski, 1994). We used the gure to demonstrate the management how ICT security is currently being managed in their organisation. The demonstration showed that, currently, the focus is mostly on the technical aspect, meaning that the existing countermeasures are mainly addressing the technical dimension which corresponds to the second and third signs of the 10 deadly sins of information security management as discussed in Solms and Solms (2004). Referring to ISO 17799 and COBIT for the organisational dimension, a management framework should be established to initiate the implementation of information security within the organisation. By using SBC framework, we were able to bring the management team together and discuss the security problem as a business problem as shown in Fig. 3. We were able to point out, with examples, what the security issues in each dimension are and the areas of consideration and consequences if such an issue is not addressed. For example, by highlighting to the management that ensuring that staffs/users are aware of information security threats and their consequences for the organisations mission and business objectives, in the course of their normal work was the responsibility of people from the human resources

department, helped them to see that this is not a technical department responsibility.

2.6. Step 6: getting the current status of ICT security documented (take stock of the existing situation)
Our next step was to have an idea of what existed in the organisation with respect to ICT security. This exercise involved taking stock of what existed in terms of: systems (hardware, software, platforms, networks, applications, users and assets); environment (location and services); security (threat types and potential ones and countermeasures that are currently in place); and procedures (any policies and procedures in place). This information helped to identify the current status of ICT assets, their location and the type of services they provide, as well as threat types for each identied asset and the security measures that are in place. We made use of OCTAVE phase 2, process 5 in some of the stages (Alberts and Dorofee, 2003, p. 49). The OCTAVE phase 2 deals with identication of key components of an organisations information system. This exercise gave the security team more knowledge of ICT assets, their link to the organisations objectives and helped to highlight areas that needed immediate attention. In addition, we later used this information during the awareness-raising sessions to help staffs understand and appreciate the types of ICT security problems they have. For example, we established that most of the different types of operating systems currently in use have been un-patched since they were bought; some have security features which are not enabled, and some have no security features at all; the licence status is not clear concerning some of the software; and the existing policy was not helpful as it was outdated and only a few senior staffs knew of its existence.

2.7. Step 7: conduct awareness-raising sessions among users (with some feedback from steps 16)
At this moment we had gathered information about the organisation, information systems risks and their consequences. We had the full support of the management and the now well-informed internal security team. It was at this step that we rolled out the awareness-raising sessions in the organisation. Our approach was top down as shown in Fig. 4. We

Fig. 4 Awareness-raising sessions plan.

50

computers & security 26 (2007) 4455

started with the management and the topic was Managing Technology risks, the role of the management, which included legal issues in a computerised environment. Along with the presentation notes, we attached the timetable of other training sessions for their departments/staffs as well. This helped to get the message across to other staffs through their bosses who made sure that their staffs attended their respective sessions. The second group was comprised of managers and Principal Ofcers from all departments. A similar topic was delivered but with a different emphasis from the one used with the management strategic level. Here the emphasis was mainly on tactical and operational issues. More than 90% of the target groups attended the awareness-raising sessions in person. We made some observations during the sessions. For example, as we looked at the faces of staffs as they were arriving at the awarenessraising session room, we could read their faces saying, This session is not for me. However, after some time into the session the situation changed and people were getting concerned about the issues being discussed. ICT security awareness-raising efforts were designed to allow staffs from various departments to recognise ICT security concerns, participate effectively in the ICT security management process and respond accordingly as suggested in the study by Wilson and Hash (2003), where detailed discussion on Building an Information Technology Security Awareness and Training Program is presented. Apart from the general awareness-raising session, we also had special sessions with individual departments, namely legal, accounts, internal auditing, physical security, human resources and technical. For each session the focus was in accordance with their respective speciality. For the Legal section, for example, the main point of discussion was what the ICT risks are from the legal perspective and hence the legal issues in a computerised environment. Some questions were posed such as: what are the implications of using unlicensed software in the organisation? How could a crime committed through computers be handled? Are the cooperate lawyers conversant with the subject matter? If not, what are the implications for the organisation should such a problem arise? What we learnt in this particular session, for example, was that participants were very concerned and one of their comments was, then we need to revisit our policies and procedures in the computerised environment. In the Accounting and Human resources sections, the focus ` was on transactions in the computerised environment vis-avis roles and responsibilities. We discussed at length the consequences of not having in place a detailed job description, in particular the issue of roles, responsibilities and accountability of staffs when dealing with various transactions such as nancial in the computerised environment. The effect of the awareness-raising sessions was a realisation of the need to go for further training. It triggered staffs, for example, to register for Certied Information Systems Auditor (CISA) and Certied Information Security Manager (CISM) after realising that they needed further training, even if it meant sponsoring themselves. CISA certication focuses on IT auditing, security, and control, while CISM focuses on the information security management (ISACA, 2005). It also triggered the

concept of awareness through visiting other organisations (local and international) and preferably in the same industry, to learn what is going on as far as ICT security is concerned. Nevertheless, the local visits only showed that even the other organisations were still at the take-off stage.

2.8.

Step 8: carry out risk assessment and analysis

Using the security team, we started to conduct risk assessment and analysis starting with the operations department (where core services of the organisation are located), followed by the IT department, physical security and later other departments. The cooperation from staffs was very high due to the effect of the awareness-raising sessions. As suggested in Magnusson (1999), the need for countermeasures against ICT risks depends entirely on the effect these risks may have on the organisations mission and business objectives. Fig. 5 is an extension of Fig. 1 and shows how these countermeasures are derived from the organisations objectives. (i) Identication of organisations objectives In Fig. 5, the objectives are represented by (O1, O2, O3, O4, ., On). The organisations objectives, which will be taken into account, are those that are ICT dependent. (ii) Identication of ICT assets that support the organisations objectives The second stage involves identication of ICT assets that support the organisations objective/s (OxAx) and the businesss key performance indicators. The ability of an organisation to achieve its mission and its business objectives is directly linked to the state of its ICT assets. As discussed in Alberts and Dorofee (2003), an asset is something of value to the enterprise and includes systems, information, software, hardware and people. Systems store, process, and transmit the critical information that drives organisations. (iii) Analysis of threats to the organisations ICT assets The third stage involves threat analysis. For each identied asset, an assessment of the threats (AxTx) and their consequences that hinder the organisation from meeting its intended objective Ox takes place (where x identies the objective and likewise the corresponding threat, and can be from 1 up to n threats). If we take the example of business continuity as an objective, then the set of threats can be theft, power uctuation, virus or denial of service (DOS). (iv) Ensuring organisations objectives The fourth stage involves identication of countermeasures for each threat. Picking theft in the previous example, the policy (Px) may include backup, traceability and recovery, and user policy and procedures. The outcome report (of identied objectives, identied ICT assets, threats and their possible countermeasures) is compared with the current organisations ICT practices in order to estimate the security awareness in the organisation. The end result is the security benchmarking documented in a survey report that gives an overview of the security awareness and vulnerabilities in the organisations ICT assets.

computers & security 26 (2007) 4455

51

Fig. 5 Showing how insurance policies can be derived from the organisations objectives.

This exercise shed even more light on the magnitude of the security problem and information obtained from this step was vital for the discussion we held later with individual managers, in particular when discussing with the CFO on how to nancially hedge the identied risks. In addition, the obtained information was used to estimate security awareness when discussing with the IT department on which countermeasures are being practised and which are not. The discussion also took into consideration the output of the EMitL tool (the output of step 4) (Bakari et al, 2005b).

with not enough know-how, and improvement of the infrastructure which was also found to be part of the problem. Although all these were not budgeted for, the management saw the need to reallocate the budget for these immediately as they were seen to be cost effective, having a clear link in safeguarding the organisations mission and business objectives. A long-term plan was then worked out which included, among other things, a disaster recovery and business continuity plan, and developing countermeasures which included policies and various mechanisms including procedures on ICT security. These are detailed in step 10.

2.9. Step 9: work out the mitigation plan (short-term plan for issues that need immediate attention and long-term mitigation plan)
This is the step that came as a result of pressure from the management. Having realised how risky it was to go without proper ICT security management in place, the management was now at the forefront, suggesting that the security team come up with a mitigation plan. From the management side, an ICT steering committee (management focusing on ICT with security as a priority) was formed where management will work closely with the IT department. The need for control of information technology in use in the organisation was now realised as suggested in COBIT. We made use of OCTAVE method process 8 which involves developing a protection strategy to work out the mitigation plan. From the risk assessment and analysis and the quick scan that took place with the documentation, we found that there were issues that needed immediate attention. They included, for example, getting the issue of licences sorted out, patching the operating systems, training in some areas which were identied as critical but

2.10.

Step 10: develop countermeasures

The main question here was what set of countermeasures will provide the best protection against the identied risks and the state of ICT security in the organisation. The goal here is to design and develop countermeasures tailored to the organisation that will remedy the identied vulnerabilities and deciencies. After this stage, which is mainly analytical, the solutions are still on the drawing board, the process referred to in Information Security Management Systems (ISMS) (Bjorck, 2001). The operationalisation stage takes the conceptual level and makes it work in the organisation. This entails, for example, installation and conguration of technical security mechanisms (e.g. user policy and procedures, backup, etc.), as well as information security education and training of employees. By taking into consideration the suggestion made from the EMitL tool (what should have been in place), ITIL (why), ISO 17799 (what), COBIT (how) and nally the environment in which the organisation is operating, we started deriving the

52

computers & security 26 (2007) 4455

Policy: Routine procedures should be established for carrying out the agreed backup copies of data and rehearsing their timely restoration. Objective: To maintain the integrity and availability of information processing and communication services.

Fig. 6 Sample policy.

relevant countermeasures to be implemented in order to address the identied ICT risk exposure (ITIL, 2005; ISACA, 2005; ISO 17799). ITIL and COBIT helps in dening objectives of the processes involved in ICT organisation in general where ICT security is a part of the whole. We used ISO 17799 details on what should be done in addressing each dimension. For example, what should be done by human resource people to address the problem associated with ethics/culture. This is detailed under the subsection dealing with personnel security of the standard. Our approach was only to consider those issues that are basic and which can be achieved. This helped us to develop the ICT security policy and corresponding security mechanisms for the organisation. Fig. 6 shows part of the sample policy document where for each policy statement (what) there is the objective (why) which attempts to answer the question why the organisation should have such a policy statement. For each policy statement we had the corresponding objectives and what type of vulnerability is being addressed. Then

there is a pointer to the procedures which show in detail how such a policy is going to be implemented. For example, Fig. 7 shows how the above policy and objectives in Fig. 6 were translated into procedures. This step triggered another concern of redening job descriptions and responsibilities of the staffs in the organisation. The procedures and security mechanism we developed or suggested then became major inputs in this exercise. In addition, there was a reorganisation of the technical department to include the ICT security function. All these were driven internally through the ICT security project team (formed in step 3). This was achieved in two steps. First reorganisation of the IT departments organisational structure to ensure that there is a clear demarcation of responsibility. For example, system development was separated from the section that deals with change management, and the user department and the interface was centralised at the helpdesk. This was achieved by making use of ITIL (service management process) and ISO 17799 (personnel security). The second exercise

1.1.1 System backup Full Systems backup shall be done at least once a week or when there is a system change. 1.1.2 Backup Verification Test restores from backup tapes must be performed once every month. This ensures that both the tapes and the backup procedures work properly. 1.1.3 Storage Period Available backup tapes must cover a minimum of two weeks. Ideally backups of system data would go back about two months and backups of user data would go back about one month. 1.1.4 Storage access and security

All backup media must be stored in a secure area that is accessible only to authorised staff. The media should be stored in a special software fireproof safe when they are not in use... 1.1.5 Off-site Storage

Sufficient back tapes so as to provide a full copy of all information for each critical system in the organisation must be stored at a different location ...

Fig. 7 Sample procedures.

computers & security 26 (2007) 4455

53

involved brainstorming with the technical department on how the newly developed ICT security policy and procedures could be incorporated into the reviewed sections and the staffs roles and responsibilities. The activities identied in this second step were to wait until the following nancial year. In addition, the plans for the new nancial budget for each department took into consideration the operationalisation of the proposed countermeasures. One issue that brought about some discussion was the positioning of the security function in the organisation. Our nal conclusion for this, after discussing the advantage and disadvantage of positioning it in different departments, was to have ICT security positioned in the existing security department which was directly under the CEOs ofce and headed by the chief security ofcer with overall responsibility for ICT security. Another staff position that was created was that of ICT security administration at the IT directorate level. Finally, we convened the management team to present the mitigation plan and the proposed countermeasures. One of the key messages that we delivered at the meeting was for them to take responsibility for ensuring that ICT security policy and procedures are approved by the board before full implementation starts. We brought to their attention that it is the responsibility of the board of directors and executive management to provide oversight of the implementation of information security (Posthumus and Solms, 2005), and therefore the outcome of this step (policy and procedures) should be brought to the attention of the board. It was the responsibility of the ICT security project team and IT steering committee to ensure that the policy and procedures come into operation.

3.

Discussion

One of the major problems found in organisations today, including our case study, has to do with perception, where the management and general staffs perceive that ICT security is a technical problem and not a business problem. This situation leads to a misunderstanding of the nature of the security problem and consequently ends up in addressing the wrong problem. The observation has indicated that changing the way the management and general staffs perceive the problem is a necessary process and a prerequisite step towards a common understanding of managing ICT security in an organisation. This can be achieved through awareness-raising sessions. Furthermore, the backing and awareness of both management and the general staffs is vital for the success of the ICT security management programme, which leads to the appreciation that the protection of ICT assets is a business issue and not a technical issue. In the case study, since a sense of security in non-digital (manual) processes exists in the management and staffs in general, what needs to be cultivated is a shift of focus from the manual to the digital process. For example, it is common, in particular in state-owned organisations, to have high security in place on how to handle condential records in physical registries. This even includes a special type of recruitment of staffs (including vetting), who work in such ofces. Being aware, for instance, that system administration is more sensitive than the mere registry, since system administrators have

access to more information than that which is already printed, was another milestone. We also found that perception and interpretation of the words ICT security often leads to a misunderstanding of the actual ICT security problem. For example, the traditional interpretation of the word security for many people, in particular in Tanzania (where this study was conducted), meant something to do with physical security, the police, etc., and the word ICT refers to modern technology only. The two key words ICT and Security should therefore be used carefully. When discussing ICT security with the management, it may sound better if we used Managing technology risks instead of Managing ICT security. Similar suggestions are found in Blakley et al. (2001) where information security is viewed as information risk management. Our experience is that staffs tend to be more cooperative and proactive in dealing with the problem when they understand exactly what ICT- related risks are all about. For instance, sharing passwords or issuing passwords to fellow staff members was not considered such a big deal, because not many staffs realised how dangerous that was. ICT security is a multidimensional discipline consisting of, among other things, legal, human resources, technical, operations, security, audit, insurance, and nance (Solms and Solms, 2004). It is therefore important that the initialisation process, which involves the formation of a special project team, starts with the right staff. As discussed in the paper, for better results the team must be made up of senior staffs from all major departments (legal, human resources, technical, operations, security, audit, insurance, and nance) to be able to meet the multidimensional requirements of the ICT security problem. Another important aspect is to have practical examples during the awareness-raising sessions coming from the organisation itself, when discussing the ICT-related risks with the management and general staffs. This also helps when discussing the information security plan which must be based on the risk exposure of the organisation itself. Getting the current status of ICT security of the organisation documented properly gives more knowledge, not only to the security team, but also to the management and general staffs of the interrelationship of ICT assets, threats, and vulnerabilities, as well as the possible impact on the organisations mission and business objectives. It helps the management and general staffs appreciate the ICT security problem and hence assist in making them more supportive when dealing with the problem. In addition, awareness is very essential to all users but, as discussed before, it will have a signicant impact if it is extended and the matter brought to the specic attention of different departments in the organisation. For instance, when meeting corporate lawyers, the main discussion will be on ICT-related risks from a legal point of view. There are many internationally established codes of practice that are essential in the process of managing information security in an organisation. Studying these multiple sets of practices and guidelines is of importance for determining and understanding the features that are being recommended to organisations and which must be considered when managing information security. In our study, an attempt to approach the problem holistically was used, by initially merging two holistic approaches, BRITS and SBC

54

computers & security 26 (2007) 4455

model. BRITS gives the business view of the problem and the SBC the security by consensus. The result of the merger was used to approach the problem from the managements perspective as shown in step 5. We have used OCTAVE, ITIL, ISO 17799 and to some extent COBIT, in an attempt to compensate for the missing links in different steps. Looking at these three approaches, ITIL addresses ICT services and operational management practices that contribute to security, COBIT addresses control objectives for information technology security and process control and ISO 17799 is exclusive to the information security management process. A similar study by Solms (2005) has already shown the synergy of combining more than one framework when attempting to manage ICT security in an organisation. Reviewing the steps as described here, it becomes apparent that they t well with the issues discussed, such as a framework for information security governance and the like, and those discussed in the 10 deadly sins of information security management (Solms and Solms, 2004; Posthumus and Solms, 2004), although the order in which they appear here might be different. The process (10 steps) needs to be initiated from outside, but then there is a need to have the process driven internally. Not many organisations have the capability of putting together the ingredients from different methods. An expert is required to interpret and apply different methods and apply what is required in specic stages. Our experience, however, indicated that it is possible to address this problem by extending the proposed holistic approaches into a set of guidelines which can be used to address the problem in the organisation.

collaboration with other departments, by taking into consideration the non-technical dimensions as well. Discussing bridging of the gap between the management and the technical department in general would also involve other stakeholders as well as looking at other angles of the problem. Within the Tanzanian experience, part of the research into ICT security has covered, in particular, ICT security education and training, ICT security management, Security Controls implementation and ICT systems security assurance (Casmir, 2005; Bakari, 2005; Tarimo, 2003; Chaula, 2003). These are all ongoing activities that hopefully will enable the country to nd useful, efcient and socially acceptable ways of balancing the two main perspectives; the social (cultural and structural) and the technical (machines and methods) towards controllable, viable and homeostatic states.

references

4.

Conclusion and reections

Our objective to bridge the gap between the management and the technical department was achieved through the 10 steps. These included: the CEO buying into the idea rst; recognising that the technical departments are the custodians of ICT in the organisation; starting it as a special project; showing where the risks and their consequences are; getting the entire managements attention; taking stock of the existing situation; conducting awareness-raising sessions to address the ICT security problem with respect to the organisations specic environment; carrying out detailed risk assessment; working out a short-term plan for issues that need immediate attention and a long-term plan to nally develop the countermeasures for the identied problems. The study conrmed that the success of the ICT security management process begins with the management realising the importance of ICT security management. That implies that the management allows the organisation, through its own acquired knowledge and condence, to internalise the practices, thus enabling people to act condently at all levels. Knowing about the ICT risks and their consequences for the core service operations of the organisation, the management is more likely to offer its support for ICT security endeavours. Likewise, the technical department, following the support from the management, can address the ICT security problem more holistically in

Alberts C, Dorofee A. Managing information security risks: the OCTAVE approach. Addison Wesley, ISBN 0-321-11886-3; 2003. Bakari JK. Towards a holistic approach for managing ICT security in developing countries: a case study of Tanzania. Ph.L. thesis, SU-KTH, Stockholm. DSV report Series 05-011; 2005. Bakari JK, Tarimo CN, Yngstrom L, Magnusson C. State of ICT security management in the institutions of higher learning in developing countries: Tanzania case study. In: The 5th IEEE ICALT, Kaohsiung, Taiwan; 2005a. p. 100711. Bakari JK, Magnusson C, Tarimo CN, Yngstrom, L. Ensuring ICT risks using EMitL tool: an empirical study, IFIP TC-11 WG 11.1 & WG 11.5 joint working conference on security management, integrity, and internal control in information systems, December 12, Fairfax, Virginia, Washington, US; 2005b. p. 15773. Bishop M. Computer security, art and science. Addison Wesley, ISBN 0-201-44099-7; 2003. Bjorck F. Security Scandinavian style, interpreting the practice of managing information security in organisations. Ph.L. theses, Department of Computer and Systems Science, University of Stockholm and the Royal Institute of Technology, Stockholm; 2001. Blakley B, McDermott E, Geer D. Information security is information risk management. In: Proceedings of the 2001 workshop on new security paradigms. New York, NY, USA: ACM Press; September 2001. Casmir R. A dynamic and adaptive information security awareness (DAISA) approach. Ph.D Thesis, SU-KTH, Stockholm; 2005. No. 05-020. Chaula JA. Security metrics and public key infrastructure interoperability testing. Ph.L Thesis, SU-KTH, Stockholm, DSV report Series 03-021; 2003. Caralli AR. Managing for enterprise security. USA: Carnegie Mellon University; December 2004. ISACA. <http://www.isaca.org/cobit/>; 2005 [last accessed on 20 October 2005]. ISO 17799 Standard. ITIL. <http://www.itil.org.uk/>; 2005 [last accessed on April 2005]. Kowalski S. IT insecurity: a multi-disciplinary inquiry. Ph.D. Thesis, Department of Computer and Systems Sciences, University of Stockholm and the Royal Institute of Technology, Stockholm; 1994. ISBN: 91-7153-207-2. Magnusson C. Hedging shareholders value in an IT dependent business society. The framework Brits. Ph.D Thesis,

computers & security 26 (2007) 4455

55

Department of Computer and Systems Science, University of Stockholm and the Royal Institute of Technology, Stockholm; 1999. Solms BV, Solms RV. The 10 deadly sins of information security management. Computers & Security 2004;23(5). ISSN: 01674048:3716. Solms BV. Information security governance: COBIT or ISO 17799 or both? Computer & Security 2005;24:99104. Posthumus S, Solms RV. A framework for the governance of information security (Elsevier Ltd.). Computers & Security 2004;23:63846. Posthumus S, Solms RV. A responsibility framework for information security. In: IFIP TC-11 WG 11.1 & WG 11.5 joint working conference on security management, integrity, and internal control in information systems, Fairfax, Virginia, Washington, US; 12 December 2005. p 20521. Tarimo C.N. Towards a generic framework for implementation and use of intrusion detection systems. Stockholm University/ Royal Institute of Technology, Report series No. 2003-022, SU-KTH/DSV/R 2003SE; December 2003. Wilson M, Hash J. Building an information technology security awareness and training program. NIST Special publication 800-50; October 2003.

technical and non-technical ICT security controls within organisations, such as Intrusion Detection Systems. Louise Yngstrom is a Professor at the Department of Computer and Systems Sciences, Stockholm University/Royal Institute of Technology. She is also the Director of SecLab, Dean of research studies, and responsible for national and international masters programmes in ICT security. She started one of the very rst interdisciplinary academic IT security programmes in the world in 1985, naming it Security Informatics. She was awarded her Ph.D. in 1996 for the introduction of a methodology for such academic programmes, called the Systemic-Holistic Approach (SHA), where soft and hard sciences appropriate for IT security issues are mixed. Being one of the pioneers in the eld of systems sciences and security in Sweden, she has been with the department since 1968. Dr. Yngstrom founded IFIPs WG11.8 and the World Conference on Information Security and Education, and is an active member of various working groups within IFIP TC9 (Social accountability of IC&T) and TC-11 (Computer Security). Christer Magnusson is an Assistant Professor at the Department of Computer and Systems Sciences, Stockholm University/Royal Institute of Technology, specialising in IS/IT Security and IS/IT Risk Management. He brings two decades of industrial and academic information security experience to our group. Before joining SecLab, Dr. Magnusson was the Head of Corporate Security and Risk Management at Sweden Post and CEO of Sweden Post Insurance AB, and he has also been the Head of Corporate Security in the Ericsson group. He has also worked within the IT Security group of the Swedish Agency for Public Management (Statskontoret). Dr. Magnusson was awarded the SIG Security Award by the Swedish Computer Society in 1999 and in 2000 the Security Award by the Confederation of Swedish Enterprise (Svenskt Naringsliv) in recogni tion of the models and the integrated processes regarding IS/ IT Risk Management that he developed as a part of his research studies. He holds M.Sc. and Ph.D. degrees in Computer and Systems Sciences. Dr. Stewart Kowalski is a part-time lecturer and advisor at the Department of Computer and System Sciences, Stockholm University/Royal Institute of Technology in Sweden. He has over 25 years experience in teaching and IS/IT security. He is currently the Risk Manager for Ericsson Global Services which operates in over 140 countries around the world. His research interests include industrial and academic research in the development adoption and assimilations of IT security technologies and practices in organisations, markets and cultures.

Jabiri Kuwe Bakari is a Ph.D. student studying potential solutions in relation to the management of ICT security (holistic approach), at the Department of Computer and System Sciences, Stockholm University/Royal Institute of Technology in Sweden. He received his B.Sc. Computer Science degree at the University of Dar-es-Salaam Tanzania in 1996, M.Sc. (Eng.) Data Communication degree from the Department of Electronic and Electrical Engineering, Shefeld University in UK in 1999, and Licentiate of Philosophy degree from the Department of Computer and System Sciences, Stockholm University/Royal Institute of Technology in Sweden in 2005. He is an active member of the International Federation for Information Processing (IFIP) TC-11 Working Group 11.1, and IEEE. He has published and presented several papers in the eld of information security management at the ISSA, IFIP, IEEE and IST international conferences. Charles Tarimo is currently a doctoral candidate in computer and communication security at Stockholm University, Department of Computer and Systems Sciences. He holds a B.Sc. in Engineering (B.Sc Eng.) obtained in 1994 from the University of Dar-es-Salaam, Tanzania and a Licentiate of Philosophy (Ph. lic.) in Computer and Systems Sciences, obtained in 2003 from Stockholm University in Sweden. Charles is an employee of the University of Dar-es-Salaam Tanzania. His research interests are focused on operational and practical issues with regard to aspects of requirement development, designing, implementation, and maintenance of different