Queen Essays

7

Mobile devices

Mobile devices and teleworking

Control objective A.6.2 of ISO27002 is to ensure information security when mobile or when working remotely. The protection required should, of course, be proportional to the risks identified (through a risk assessment). Many of the issues related to both mobile working and teleworking have been touched on elsewhere in this book. These include issues around infor- mation classification (Chapter 9), equipment security (Chapter 16), virus control (Chapter 18) and access control (Chapter 11). The two sub-clauses deal, respectively, with mobile computing and teleworking.

Mobile computing

Control 6.2.1 of ISO27002 says the organization should have in place a formal policy and appropriate controls to protect against the risks of work- ing with mobile computing facilities, particularly in unprotected locations. If the organization has a BYOD (‘Bring Your Own Device’) policy, this is where it would primarily occur within the ISMS.

Any organization that operates a mobile computer network – and a Blackberry or smartphone network would count – should take specific steps to protect itself. These controls may also be relevant in respect of staff accessing organizational assets from their own private mobile devices. If it also has teleworkers, this policy for mobile computers could be integrated with that for the teleworkers. The first step is to design and adopt, within the ISMS, a mobile computing policy, which must be accepted in writing by those who wish to use mobile facilities before they are allowed to. The sensi- ble organization will also ensure that users receive appropriate training before they are issued with mobile computing equipment (notebooks, smart- phones).

IT GOVERNANCE116

This policy should consolidate all the procedures discussed elsewhere in this manual in respect of mobile computing and handheld usage. It should set out clearly the requirements for physical protection, access controls, cryptography, back-ups and malware protection. It should include clear guidance on how to connect to the organizational network and how mobile tools should be used in public places. ‘Public places’ include meeting rooms outside the organization’s own secure premises and wherever notebooks and handhelds remain tempting targets for hackers and thieves, who can have as much impact on the availability of data as a particularly virulent virus. Guidance on where mobile devices may be used, and for what purposes, should also be provided, with due consideration being given to who may be able to see or hear what is being ‘processed’.

The organization will need to develop an effective method of ensuring that anti-malware protection is completely up to date on mobile computers (which are also known as ‘endpoints’, reflecting the reality that for many networks, it is the notebook and mobile devices that exist beyond the secure corporate perimeter that are the endpoint for corporate security activity). This is best done by using an automatic update service that updates all computers the moment they log on to the organizational network. It is important that the mobile user is not given any authority to override this update and is not able to proceed until the update is complete. This principle should extend to ensuring that the software is fully patched, with all service packs installed; it is not unknown for someone whose primary use of a laptop is for e-mail to avoid actually logging on to the system for months on end, with the consequence that many patches and service packs are not installed. End-point security products have emerged to deal with these specific issues.

Where remote users access organizational facilities, strong authentication should be used, which makes use of strong protocols. Consideration should be given to authenticating the machine as well as the user to provide for the situation where a notebook has been stolen and the user authentication information compromised. The situations where this will be necessary should be identified through the risk assessment.

Back-up procedures (using, for instance, web-based data back-up services) are very important; unlike the requirement that should be in place for computers on a fixed network (no data stored on the C: drive), mobile computers may have all their data stored on the C: drive. The requirement for regular individual back-ups, together with a workstation configuration that automatically backs up the ‘My Documents’ folder to the main server

MOBILE DEVICES 117

when a laptop is logged on to the network (over an appropriate connection), combined with a requirement that any physical back-up media are appro- priately protected from theft, loss or degradation (issue protective, lockable boxes), is essential.

Physical security (ensuring that unattended notebooks are locked away and/or fitted with security locks and that notebooks with sensitive informa- tion are encrypted and are never left unattended) is an equally important component of an effective mobile computing policy. Given the ridiculously high number of laptops and smartphoness that are lost, stolen or otherwise go missing every year, organizations need to develop specific reporting and recovery procedures based on a risk assessment that includes any legal or insurance issues that may be relevant to the organization. Users should be physically trained in how to do these and should demonstrate that they know how to before they are released into the world with a notebook or handheld.

The proliferation of wireless networks, wireless networking facilities and public wireless access spots has brought a new dimension to mobile comput- ing security. The fact that an individual can access a public wireless network (from, for instance, an airport lounge or a coffee shop) is both extremely convenient and potentially very dangerous. It can be more dangerous than accessing the internet through a fixed link, in that a wireless computer is broadcasting information to the wireless access point – and, therefore, all that information is available to anyone who is interested in it.

A widely deployed security standard deployed on laptop computers is still (Wired Equivalent Privacy). It does not give the privacy of a wired equivalent; it is insecure, and there are many websites that provide informa- tion on its inadequacies and how to attack WEP, to decrypt current traffic, to inject new unauthorized traffic or, ultimately, to access the laptop itself. The default configuration for laptops should be that WEP is switched off. It is just as important to secure laptops that may use public access points to access corporate networks; WPA (preferably WPA2) and VPNs should be part of the basic security configuration.

It is essential that before any laptops are issued to mobile users, the organization carry out a risk assessment, and deploy those technological controls (which themselves are evolving quickly) that are most likely to minimize the threat to the organization arising from wireless vulnerabilities.

Increasingly, mobile phones and smartphones are falling within the cate- gory of information processing devices that this section is designed to address, and they should therefore, as previously indicated, also be subject

IT GOVERNANCE118

to appropriate controls determined as the result of a risk assessment. Clearly, consideration needs to be given to the logical boundaries between organiza- tional data and the systems, software and Apps on smartphones, which takes us back to the BYOD issues identified earlier.

Teleworking

Control 6.2.2 of ISO27002 says the organization should develop policies, operational plans and procedures to authorize and control teleworking activities. Where the organization has both teleworkers and mobile workers, the two policies should be integrated. Teleworking has increasingly become an extension of mobile working, rather than being simply one or a few work- ers based outside the organizational perimeter and accessing the network from time to time. The only significant difference between the two is that teleworking involves a fixed base and fixed connection to the organizational network; more information and more extensive facilities tend to exist in the teleworking location. The location itself, usually an employee’s home, does not have anything like the physical security that might be available in the workplace and is also vulnerable to domestic thieves.

There are particular controls that should be considered for teleworkers, and these should reflect a risk assessment and be incorporated into a formal policy within the ISMS. The teleworker should be required to sign a suitably modified version of the access agreement discussed in Chapter 12. A NIST publication, Security for Telecommuting and Broadband Communications, SP 800–44, available from the NIST website (https://csrc.nist.gov (archived at https://perma.cc/Z5WL-42XB)), is designed to help system administra- tors and users tackle the information security issues around these areas, and while written for a US audience, it is of value elsewhere. There are also issues of health and safety that will need to be considered, but these are outside the scope of this book.

The risk assessment should consider specific issues in relation to remote locations. Where the organization has a substantial number of teleworkers (eg staff working from home, either permanently or infrequently but regu- larly), it might consider a standardized form of risk assessment that looks for exceptions to minimum requirements, can be carried out at a distance and depends on employee information for completion. This input should be subject to random physical checks. If the system is too complex and

MOBILE DEVICES 119

time-consuming to set up, the benefits to be gained from teleworking will be outweighed by the work it requires to set someone up.

A key issue to consider, for teleworkers, is the physical security of the site. The organization should look at the physical security of the proposed build- ing (usually a house) and also take into account the security of the surrounding area. The teleworking environment within the building should also be considered: is it a separate office or is it in a communal area? The communications requirement should be assessed; this should take into account the information classification, the underlying linking technology and the sensitivity of the system to which it links. Lastly, the threat of unau- thorized access to the facilities (including from family and friends) should also be assessed.

There are a number of controls that might be considered and that should be included in the teleworking policy. As with the mobile working policy, teleworkers should not be authorized to start activity until they are satisfac- torily trained. The controls should include provision, by the organization, of suitable and adequate equipment and appropriate furniture that make stor- age and proper usage possible. Consideration should be given to printers, files, peripheral drives and safety equipment such as anti-glare screens and wrist rests that might be available in the workplace. Full-size screens, keyboards and mice might also be appropriate.

The permitted work should be defined, including the hours of work and the classification of information that may be held at, or accessed from, the location. The organizational systems and services that the user is authorized to access should also be described. Appropriate communication equipment should be provided (internal modem, ISDN, ADSL, broadband, etc, depend- ing on communication needs, available technology and the cost–benefit analysis), and how secure remote access is ensured must also be decided. Physical security – how the equipment is to be protected against breakage and theft – is as important as the establishment of appropriate insurance cover for it (it should not be left to the employee to organize cover under a household policy, as this will usually not be applicable). There should be rules about what access families and friends can have to the facilities and to the equipment. Critically, these must take into account any other devices that may run on a home network and any wireless devices or wireless networking. Appropriate steps should be taken to provide hardware and software support and maintenance; usually this includes an extended service from the organizational helpdesk staff, whose hours will need to be extended

IT GOVERNANCE120

to cover home working and whose skills will need to encompass their pecu- liar problems.

There are specific issues that will need to be addressed if the teleworker is going to use privately owned equipment. One such issue could be that of ownership of business ideas or intellectual property developed on privately owned equipment either during or after working hours, and this issue should be addressed (depending on the risk assessment) with the help of the organ- ization’s professional legal advisers; appropriate clauses, which should also cover dispute resolution, should be inserted into the teleworker’s access agreement. Other issues specific to privately owned equipment include the need for the organization to access the equipment (either to check security or as part of an investigation); software licensing agreements consequent upon the deployment to a private machine of organization-specific software; and requirements about the level of firewall and anti-malware protection. Like the IP issue, these should all be addressed in the light of a risk assess- ment and with professional advice that informs the teleworker’s access agreement.

There should be clear rules about back-up, anti-malware and continuity plans, with appropriate resources provided to make this as easy as possible. It should be borne in mind that the risks to the organization are greater in relation to individual teleworkers than in relation to individual users on the organizational network.

Teleworkers should certainly be subject to audit and monitoring just as for any other person attaching to the network, and there should also be a documented process for revoking general or specific teleworking authoriza- tions and to ensure that all equipment is returned.

8

Human resources security

Clause 5.1 of the standard requires the organization to ensure that the resources needed for the ISMS area available and clause 7.2 requires that that whoever is assigned an ISMS-related task has the necessary compe- tence. The HR aspects of two clauses can be satisfied at the same time as the relevant HR controls are implemented.

Clause 7.2, in particular, requires the organization to determine what competences are necessary for those doing work within the ISMS, and then to ensure (by assessment and evaluation) that these persons are actually competent, providing relevant education, training or experience, and to keep appropriate documentary evidence. Note that ‘persons doing work under organization’s control’ can extend to volunteers, associates and contractors as well as full-time employees.

Section 7 of ISO27002 is structured to deal with human resources secu- rity in a way that covers the three stages of employment: pre-employment, during employment and post-employment. Control 7.1 of the standard deals with pre-employment security issues. The objective of this clause is to ensure that employees and contractors are suitable for their roles, and understand their information security responsibilities. Control 7.1.1 deals with pre-employment screening, and 7.1.2 deals with contracts and roles and responsibilities in respect of the ISMS and information security within the organization. This should include both general and specific responsibilities.

Job descriptions and competency requirements

Every job description should contain: 1) a description of the competencies required for the role; and 2) a statement to the effect that every employee is required to be aware of the organization’s policy on information security

IT GOVERNANCE122

(a copy of the policy might be attached to the job description) and to take whatever actions may from time to time be required of him or her under the terms of the organization’s ISMS. In particular, the employee’s attention should be drawn to the responsibility to protect assets from unauthorized access, disclosure, modification, destruction or interference, the information classification and handling rules, the access controls (both physical and logi- cal), the incident reporting procedure, the requirements to carry out any other specific procedures and processes, the requirement personally to improve competence and skills in this area, and the fact that the employee will be held accountable for his or her acts of commission and omission. The job description should set out clearly that breach of information security controls may be considered a misdemeanour under the organization’s disci- plinary policy and that breach of them might, under specific circumstances, result in dismissal.

Specific requirements should in addition be included in the job descrip- tions of particular individuals. If the organization prefers not to identify required competencies for all roles, it will at least be necessary to do so for those involved in the ISMS. The people who should be considered for such specific requirements include:

●● the chief information and/or the chief information security officer;

●● the information security adviser;

●● members of the information security management forum;

●● IT managers;

●● network and website managers;

●● IT, website and helpdesk support staff;

●● premises security staff;

●● HR, recruitment and training staff;

●● general managers;

●● finance staff;

●● the company secretary and legal staff;

●● the business continuity and emergency response team.

People in each of these functions (and there are likely to be others – each organization is different and each organization needs to make arrangements that are appropriate to it) are likely to have a direct impact on the effective- ness of implementation of the information security policy and the ISMS.

HUMAN RESOURCES SECURITY 123

While Chapter 4 contained an initial discussion of the generic responsibili- ties that apply to particular functions, the only effective way to ensure that all information security responsibilities are captured will be for the members of the information security management forum to work through all the clauses of the standard, identifying which members of staff will be responsi- ble for implementing the clause or will be affected by it. These responsibilities should then be included in the job descriptions for these people.

This analysis should be underpinned by a review of all the roles, func- tions and employment levels of staff within the organization; this review should consider what responsibility, if any, people in given roles will have in ensuring the confidentiality, integrity and availability of information in the organization. The conclusions of this review should be compared with those generated by the analysis carried out on the basis of the clauses of the stand- ard. A statement of information security responsibility that combines both outputs should then be the final form of the amendment to the job description.

This statement of information security responsibility could either have a separate headlined and complete paragraph in the job description, in which case the member of staff affected should sign and date a copy of the amended job description, or there should be a separate statement attached to the job description and referred to in the job description, in which case both docu- ments should be signed and dated by the employee. The signed document should then be retained on the individual’s personnel file.

As part of any arrangements with third parties that involve their access to the organization’s information assets, security roles and responsibilities that match those required by the organization should be implemented by the third party and appropriately monitored by the organization.

Screening

Control 7.1.1 of ISO27002 deals with verification checks on permanent staff and contractors at the time of job applications. The organization should identify who will be responsible for carrying this out, how it will be done, how the data will be managed and who will have what authority in respect of the data and the recruitment process. Any screening and data collection activity must be carried out in accordance with the relevant local legislation. There is, in some roles, a legal requirement to carry out criminal screening, and there are clearly risks in taking unknown staff into the organization, not just in terms of fraud and confidentiality but also in terms

IT GOVERNANCE124

of integrity and availability. An inadequately experienced IT staff member could mismanage a vital server or application in such a way that informa- tion availability and integrity are compromised. This clause provides more information about the type of verification envisaged. It sets out five basic checks that should be completed:

1 Character reference checks, one personal and one business. These should, for preference, be written, but a substitute might be a signed and dated detailed note of a telephone reference given by a nominated third party to a competent (ie experienced in carrying out telephone reference checks) member of the organization’s staff.

2 A completeness and accuracy check of the employee’s curriculum vitae; this is usually carried out by means of written references supplied by previous employers or third-party organizations, and most employers will already have standard documents that are sent out to guide these third parties in replying. It is critical that the employer is methodical in ensuring that all facts are corroborated and that all forms are returned, duly completed, by previous employers. Where they are not returned within a defined time period (which should be short – perhaps 10 days at the outside), the organization should arrange to complete the form by means of a telephone interview with the previous employer.

3 Confirmation of claimed academic and professional qualifications, either by means of obtaining from the candidate copies of the certificates or other statement of qualification or through an independent CV checking service. These firms can, for a nominal sum, carry out detailed CV checks (including the checking of academic and other qualifications) that would satisfy the requirements of both point 2 above and this point 3.

4 There should be an independent identity check against a passport or similar document that shows a photograph of the employee.

5 A more detailed review of the individual’s credit history and/or criminal record may be appropriate for those who will have access to more sensitive information. These checks are available from specialist providers.

6 Finally, and this is in addition to the ISO27002 list, the individual’s entitlement to live and work in the country should be confirmed, by reference to appropriately endorsed travel or work documents.

Where a job, either on initial appointment or on promotion, involves access to information processing facilities, and particularly if it involves processing sensitive (financial or highly confidential) information, there should also be

HUMAN RESOURCES SECURITY 125

a credit check. Where individuals have considerable authority in their posi- tion, this check should be repeated regularly, either quarterly or annually as appropriate.

Normal practice would be that, while a draft contract is agreed between the prospective employee and the organization, it is not signed and the employee does not start work until the checks have been completed. Depending on the outcome of a risk assessment, some organizations might choose to allow people to start work, particularly in roles that deal with only a low level of information, subject to satisfactory references; in these circumstances, it is necessary to set a time limit within which the reference checking will be complete. The contract of employment will usually not be signed by the organization until the reference checks are completed, and if they are unsatisfactory or not completed within the allocated time, the employee is dismissed. A similar process should be carried out for tempo- rary or agency staff and contractors.

Where the staff are supplied by another organization (and this is often the case with IT staff, who are often directly employed by or contracted to the agency concerned), the contract with the third party should set out clearly its responsibility to carry out checks to a similar level. The contract also needs to set out what steps the agency has to take where answers to the screening process have been unsatisfactory or the process itself has not been completed. At the very least, these should include informing the employing organization, and in full, without delay, offering to replace any individual who has already started work, immediately and at no additional cost. The contracting organization should have adequate professional indemnity insurance, and this should be checked by obtaining and keeping on file a copy of the current insurance certificate.

While this may be relatively easy to implement for future hires, the organ- ization has to decide what to do in respect of existing staff. It will not be sufficient simply to adopt the approach that because the staff are already there, there will be no problems. Undoubtedly, the correct approach to this situation is to ensure that the organization has records for existing staff of equivalent completeness to those required for new hires. It will be important that existing staff are made aware that this process is to be carried out and that it will be done openly and quickly.

Statistically, the likelihood is that every organization will discover that one or more members of its staff have incorrect or false CVs. Each of these instances will have to be tackled, and the organization will have to judge the extent to which the individual threatens its information security; the

IT GOVERNANCE126

organization’s direct experience of the employee in the work environment may provide sufficient evidence to act on or to set aside the inaccuracy in the CV. If it is to be set aside, the employee should certainly be made aware that the inaccuracy was uncovered, and the reasons for its being set aside should be explained. This simple step can help the employee avoid such behaviours in the future.

New and/or inexperienced staff may, at certain times, have to be author- ized to have access to sensitive systems. The company should identify what level of supervision will be required in such circumstances and ensure that it has in place a procedure for providing the appropriate level of supervision. The performance of all staff in respect of information security, particularly those who have access to sensitive information, should be reviewed on a regular basis (at least annually) and appropriate steps taken to ensure that the standards set by the organization are maintained. This review can be by means of one or more questions that are incorporated into an existing annual appraisal system.

At annual reviews, and on a day-to-day basis, line managers within the organization should be aware of unusual behaviour by members of staff that may be signs of stress, personal problems or financial challenges. Apart from the human benefits of helping employees deal with these challenges, such issues have been known to affect people’s performance negatively (which may, of course, have implications for information security) and may also lead some individuals to commit crimes or fraud. Managers should be appropriately trained to spot and handle these situations within the restric- tions of the relevant legislation.

Personnel vetting levels in respect of UK government information can vary according to the classification of material that the job holder will normally need to access. If you require advice on the application of clear- ance levels in this context, the appropriate department security officer will be able to advise you.

Terms and conditions of employment

Control 7.1.2 of ISO27002 says the organization should ensure that employ- ees and contractors all agree and sign an employment contract that contains terms and conditions covering, inter alia, their and the organization’s responsibilities for information security. These terms and conditions should include a confidentiality agreement, constructed in accordance with local

HUMAN RESOURCES SECURITY 127

legal guidance, that covers information acquired prior to and during the employment and the effect of which should continue beyond the end of the employment.

This confidentiality agreement should be drafted by the organization’s lawyers. It should form an integral part of the contract of employment, so that acceptance of terms of employment automatically includes acceptance of the confidentiality agreement.

There are circumstances in which someone who is working for the organ- ization will not have signed an employment contract; he or she might, for instance, be working on a temporary or interim management basis, or even for short-term work experience. Anyone who has not signed a contract of employment should sign a confidentiality agreement of some description. This might form part of a contract for the provision of services or it might be a standalone confidentiality agreement. It should reflect the terms that are set out in the contract of employment, with any additional terms and sanctions that are recommended by the organization’s lawyers in respect of these third-party relationships.

This confidentiality agreement is designed to cover situations in which a person is exposed to confidential information in the ordinary course of the employment or project, and it sets out the organization’s requirements in these circumstances. It should cover legal responsibilities and rights in protection of copyright, intellectual property, data protection legislation, confidential and sensitive (particularly financially sensitive) information and any other relevant information issue. A different and specific non-disclosure agreement (NDA) should be signed by any organization to which confiden- tial information will be disclosed pursuant to a business transaction.

The agreement should be signed and dated, and the original returned to the organization before the individual is granted any access to confidential information. The terms of specific agreements should be reviewed when an employee’s circumstances change, particularly when he or she is due to leave the organization. It is often sensible to remind a departing employee (particu- larly someone who has had access to substantial amounts of confidential information in the course of the employment) of his or her obligations under the contract of employment and, in particular, of which obligations will survive termination of the employment. It is normal practice for compro- mise agreements to restate key confidentiality clauses.

Standard confidentiality agreements and NDAs should be reviewed after specific instances where loopholes in an existing agreement appear to have been found, and steps should be taken both to amend the document for the

IT GOVERNANCE128

future and, where the loophole is a significant one, to replace and re-sign existing confidentiality agreements and NDAs.

The contractual clauses should make clear that the employee has a responsibility for information security. This responsibility must be described. The simplest way to handle this is to attach the job description (and the separate statement of information security responsibilities, if this is the route that the organization has followed) to the contract of employment and for the contract of employment to refer explicitly to the responsibilities set out therein. As long as the information security clauses of the job description have been drafted in accordance with the guidance at the beginning of this chapter, and cover confidentiality, classification, responsibilities in regard to information received from third parties, responsibilities in respect of handling personal information, how the responsibilities are applied outside normal working hours and in any non-work (eg home) environment, and action to be taken in respect of anyone disregarding the organization’s requirements, this requirement of the standard will have been met.

The guidance for control A.7.1.2 additionally recommends that an employee’s or contractor’s responsibilities in respect of compliance with relevant legislation should also be clearly stated. This is particularly impor- tant in terms of data protection legislation, copyright laws and computer misuse legislation. The contract should contain a clause (drafted by the organization’s lawyers, and forming part of the contract of employment) that states that the individual will be personally responsible for ensuring that his or her activities in respect of information are not at any time or in any way in breach of these specific laws.

There is also the requirement to set clear rules for acceptable use of e-mail and the internet and, in the contract of employment, to set out very clearly the consequences for breaches of them. The rules do not need to be included in the contract, but the contract can refer explicitly to a section of the ISMS that contains them. E-mail usage rules are set out in detail in Chapter 20, as are acceptable internet use rules. Such policies must be consistently and firmly enforced; this sends a clear message to the organization that breaches will not be tolerated and helps build an environment of compliance.

During employment

Control 7.2.1 is a control requiring managers to ensure that everyone applies the organization’s security policies and procedures; it is, in other

HUMAN RESOURCES SECURITY 129

words, an extension of the requirements (see Chapter 3) that managers should be visibly committed to supporting the ISMS. ISO27002’s guidance on this control includes ensuring that staff (employees and contractors) are: properly briefed on their roles and responsibilities before they are granted access to sensitive information or information systems (evidenced by their (electronic) signature on their access rights document (see Chapter 12); motivated to fulfil their roles and conform to the policies (evidenced through the internal audit process); aware of information security threats, risks and vulnerabilities; and will maintain their competence.

Clauses 7.2 and 7.3 of the standard and control A.7.2 (information secu- rity awareness and training) require the organization to ensure that its employees and contractors are aware of information security threats as well as their responsibilities and liabilities, and that it has appropriately compe- tent personnel. The objective of this clause is simply to ensure that all users of the organization’s information assets, or those who are assigned respon- sibilities in the ISMS, are aware of information security threats and are competent and adequately equipped to perform the requested tasks and to support the organization’s information security policy in their work.

Control A.7.2.2 deals with information security awareness, education and training, and follows on from the previous control. All employees of the organization (including contractors) must receive appropriate awareness training and other training, as well as regular updates and communications.

Traditional training, which relies on someone delivering subject matter from the front of the classroom, is not a particularly effective method of ensuring that all of a large number of employees acquire the information, skills or knowledge that are needed. It is certainly not a method that reliably demonstrates that this requirement of the standard has been met. The best way of delivering information security staff awareness training is via e-learn- ing that is run on a recognized learning management system (LMS) or in a cloud-based environment, supported by a range of wall posters and computer screen reminders and related material.

Staff awareness e-learning can be delivered directly on to the desktop workstation of the targeted employee. It can be delivered in a way that improves uptake and retention as compared with traditional classroom training. It can be delivered through the web or rolled out quickly using the corporate network. It can be delivered to a consistent standard across an entire organization, and geography is no real barrier. The learning can be accessed by employees at a time to suit them, and because trainees are not required to go away on a training course, productivity is not affected by

IT GOVERNANCE130

e-learning. In fact, e-learning can be less expensive as a method of rolling out training than the traditional classroom approach, both because of these productivity benefits and because none of the usual costs of attending courses (whether internal or external) need to be incurred. There are a number of suppliers of e-learning products; one that can supply an appro- priate suite of ISO27001 products virtually off the shelf is likely to be less expensive as an option than an organization that makes a bespoke package specifically for its client. Information about information security e-learning and other awareness products is available from www.itgovernance.co.uk/ information-security-awareness (archived at https://perma.cc/5XRU-CYVU).

Web-based e-learning and any recognized LMS will both support network- based e-learning and provide a real audit trail that produces records of who has accepted specific policies, who has completed which e-learning modules and when they were done. The LMS can also run tests that can demonstrate the level of competence that the trainee has acquired in the subject matter. Administration of these systems can be done cost- effectively online.

E-learning is particularly cost-effective for training large numbers of staff. Small numbers of staff, particularly those who need detailed and extensive training, often involving feedback, questions and answers, coach- ing, etc, are better dealt with in the classroom. The areas of information security and the ISMS that are best dealt with through e-learning and that begin as part of the induction process are as follows:

●● all-staff briefing – ISMS awareness, known threats and the importance of information security and the ISMS, including general controls;

●● asset classification and control;

●● reporting events and responding to security incidents and malfunctions;

●● e-mail and web access awareness and rules;

●● user access control and responsibilities;

●● mobile computing and teleworking;

●● legal compliance awareness and related issues;

●● business continuity awareness and procedures.

Any staff involved in handling payment card data, and working within a cardholder data environment as defined by the PCI DSS, will also need specific training on their responsibilities in regard to that data.

HUMAN RESOURCES SECURITY 131

There are also a number of staff who will require other user-specific training. These include the staff identified at the beginning of this chapter as needing specific statements in their job descriptions and contracts of employ- ment about their information security responsibilities. These include:

●● the chief information officer and/or chief information security officer;

●● the information security adviser;

●● members of the information security management forum;

●● IT managers;

●● network managers;

●● IT and helpdesk support staff;

●● webmasters;

●● premises security staff;

●● HR, recruitment and training staff;

●● general managers;

●● finance staff;

●● the company secretary and legal staff;

●● internal management or system auditors;

●● business continuity and emergency response teams.

These staff should be exposed to the same all-staff training as discussed above. In addition, user-specific training will be required. The necessary training is best identified though an individual training needs analysis (TNA). The organization is likely to have a TNA process in place, and this should be applied to the security training issues. Those organizations that do not already have a TNA process in place have the choice between designing and implementing a process that will cover all of its training issues going forward, and implementing one that simply works for the information secu- rity training needs. Information security training is better tackled, on an ongoing basis, as part of a structured organizational approach to employee training. However, in situations where it is necessary to get security-specific training started, it may be simplest to apply a TNA process to deal specifi- cally with information security training.

Any handbook on corporate training, or a training professional, could provide appropriate support on a step that is fundamental to well-designed

IT GOVERNANCE132

training delivery. The principle underlying a TNA is that once the knowl- edge, skills and competency requirements of a particular role have been clearly established, and documented in the job description, the role holder’s own knowledge, skills and competence can be compared to the requirement and a gap analysis, or TNA, completed. The next step is to map out an indi- vidual learning path that will meet the requirements of the TNA and close the knowledge, skills and competence gap. This individual learning path will contain a mix of self-learning, instructor-led training and experience. It should identify clearly where the training is to come from and should set out the dates by when specific steps are to be taken, identified skills or competencies acquired and proof of acquisition generated. There is far more to a TNA than this, so do make use of a training professional to do the job properly.

While most organizations will have a TNA process in place for groups of staff, which identifies the gap between the individual’s skills and those of the generic role, there are individuals who, for information security purposes, must have very specific knowledge, skills and competencies that are in addi- tion to those needed by a group of employees of which they may be a part. Clause 7.2.2 expects that there will be an individual TNA, based on an individual or additional assessment of the knowledge, skills and competence required for each of these roles, for each of the people in one of the indi- vidual or specialist roles identified above. Where this is being put together for a new employee, the offer letter might make permanent employment conditional on achieving certain stages within certain time-frames.

Clause 7.2 of the standard requires the organization to maintain records of competence and this requirement is satisfied by following the recommen- dations of this chapter and attaching records of education, training, skills, experience and qualifications to the individual’s personnel file. More impor- tantly, the effectiveness of the training must be evaluated, and this requires the specific objectives for each piece of training, and the criteria for measur- ing its effectiveness, to be identified and agreed in advance. This is in line with best practice for effective staff training.

Training should clearly be delivered by competent trainers. In Chapter 4, there is an initial discussion on appropriate training for specialist informa- tion security advisers and the specialist training resources on the IBITGQ and IT Governance websites. This site should enable appropriate trainers for the various IT specialists to be identified.

Those IT staff charged with systems administration should be appropri- ately trained, by either the software supplier or by an approved training

HUMAN RESOURCES SECURITY 133

vendor, as system administrators for the software for which they are the nominated administrators. Evidence of this training should be retained on each individual’s personnel file. Those responsible for firewall, antivirus, encryption and any other security software should have appropriate train- ing certificates and should be required to keep their skills and knowledge current by attending regular refresher and update courses. These should be booked into the individual’s training calendar in advance and there should be evidence that they were attended. Certainly, in any Microsoft environ- ment there should always be a systems administrator who has a Microsoft certificate with the security extension, such as the MCSE with security.

Webmasters, in particular, need to be thoroughly trained and have their skills regularly updated. Their training needs to cover the security aspects of all the hardware and software for which they are responsible; in particular, they need to be capable of ensuring that the web servers are correctly config- ured and fully secured. It is essential that all high-risk systems are ‘hardened’ to at least the minimum standards identified by Microsoft on its technet website. Webmasters must be able to handle this.

Information security staff, company secretaries and legal staff and HR or personnel staff will also need specific legal training. There are a number of specific legal issues to do with information security (all discussed in Chapter 27), and the organization needs to know how to handle them, using stand- ard template documents wherever possible. It does not need to employ an in-house lawyer, as this can be unnecessarily expensive; external expertise can be brought in where and when necessary to deal with specific legal issues.

Staff dealing with voice systems and network hardware and software will all need specific, supplier-certified administration and security training that covers these products. The organization will need access to regular updates on information security issues relating to these products.

There is a discussion in Chapter 27 about training for internal auditors. There are two effective ways (particularly for a multi-site organization)

to make information security related material available to everyone in the organization. The first is to use a document management system that pushes information out to users across the network, usually in conjunction with ensuring that they are aware of policy and procedural issues. The second is to put it on a shared drive, an intranet or SharePoint. Either the organization already has an intranet, or SharePoint, in which case it simply needs to create an information security sector on it (or within the quality manage- ment sector), or it could consider setting up an intranet or SharePoint. This

IT GOVERNANCE134

does not need to be an expensive step and is undoubtedly the best way of dealing with information sharing. The organization’s existing webmaster or IT manager may have the skills necessary to set up SharePoint or it may be necessary to arrange appropriate training. Deployment of SharePoint does bring additional challenges of its own and, if this is the organization’s preferred course, it would be sensible to investigate how to deploy SharePoint server governance. Of course, it will also be necessary to ensure that appro- priate guidance on procedures is available to any affected staff in case of a system crash. This could mean that paper versions of the procedures should be available or, alternatively, a notebook computer with an up-to-date set of procedures that is part of the emergency response equipment.

The benefits of using SharePoint are that it can be the single repository of controlled documents; the information security manual and procedures can all be stored there and staff can be trained to access the relevant SharePoint site for anything to do with information security. It is easy to keep the controlled documentation up to date and to ensure that document control is effective. It is then easy to alert all relevant members of staff about changes to procedure simply by sending out an internal e-mail, with an appropriate link, that tells them which sections of the ISMS have been changed. Twitter might be another alternative. SharePoint can also have a section that carries information about information security developments and issues of which staff need to be aware. Someone within the organization needs to have the responsibility for keeping the site up to date, and this person obviously will need to be appropriately trained. The people who might have this role include the information security adviser, the quality manager, the marketing manager (if the marketing department has responsibility for internal communications) or the webmaster.

Disciplinary process

Control 7.2.3 of ISO27002 says the organization should deal with employee (and contractor) violations of its information security policy and procedures through a formal disciplinary process. Obviously, the organization should use its existing disciplinary process, and should be clear about this in employee contracts (as discussed earlier in this chapter) and in the ISMS itself.

Clearly, no disciplinary process can start until the existence of a breach has been verified (and control 16.1.7 deals with evidence collection), and formal commencement criteria may need to be documented that are legal in

HUMAN RESOURCES SECURITY 135

the local jurisdiction. The organization should ensure that those who are carrying out a disciplinary hearing in respect of a reported violation of an information security procedure are given the professional and technical support that they might need in order to deal fairly with the person and the issue. This might require the organization’s information security adviser to be involved in the process. On no account should inexperienced, uninformed managers attempt to deal with information security matters that are beyond their knowledge or experience, as this would be unfair to the employee concerned and potentially dangerous for the organization if the full implica- tions of an incident are not understood quickly enough. It could also, depending on the outcome of a disciplinary hearing conducted by an inex- perienced manager, potentially expose the organization to time-consuming and expensive industrial tribunal actions or trade union challenges for unfair treatment of an employee.

Termination or change of employment

The control area (A.7.3) dealing with termination or change of employment has a single control (A.7.3.1) that should work alongside A.8.1.4 (Return of assets) and A.9.2.6 (Removal or adjustment of access rights). In many organizations, experience suggests that administration of employment termination is, in information security terms, often sloppy. As a result. organizations are creating new vulnerabilities that needed to be assessed. The control objectives here are to ensure that termination of employment (or a change in job role) is carried out in an ordered, controlled and system- atic manner, with the return of all equipment and removal of all access rights.

Control 7.3.1 deals with termination responsibilities and simply says the organization should document clearly who is responsible for performing terminations and what these responsibilities are. These responsibilities should clearly include dealing with the ongoing clauses in the contract of employment. Usually, the HR department will be responsible for ensuring that all the termination aspects of an employment contract have been dealt with (usually in conjunction with the ex-employee’s line manager), and these may be standard aspects of a termination interview, which is carried out in a standard way, using a standard checklist.

The termination of contractors needs also to be dealt with. The organiza- tion simply needs to determine how it will achieve, with these personnel, the

IT GOVERNANCE136

same clarity as it seeks with ex-employees and who (agency, third-party organization) will be responsible for performing the task.

Control 8.1.4 requires all employees, third parties and contractors to return all organizational assets upon termination. As well as financial assets (eg credit cards and purchase orders) and HR or fixed assets (eg company cars), these assets fall into four categories: software, hardware, information and knowledge. Subject to local employment law, the contract of employ- ment should have a clause that allows the employer to withhold any outstanding payments of any description until all organizational assets are proven to have been returned and, after a suitable interval, to deduct from any such outstanding amounts the cost of replacing assets that have not been returned. Of course, this will tend to push the majority of resignations to the day immediately after monthly or other substantial payments have cleared the employee’s bank account, but such is life.

The first two asset types are best dealt with procedurally through a centralized recording and authorization process; there should be a record for each employee (maintained by the HR or IT department) that lists all laptops, smartphones and other hardware issued to employees. This list could be linked to the asset inventory discussed in Chapter 9, and the nomi- nated owner or custodian should clearly be the person to whom the asset is issued. There should be an acceptable use document for each asset, describ- ing what has been provided (and laptops should have a standard, documented ‘kit’; while laptops are often returned, the accessories are often missed), setting out clearly the organization’s expectations for the proper use of the asset and including (eg for mobile telephones) any expectations about how costs are to be split between employee and organization.

Information – classified documents, whether electronic or paper – should also all be returned. In fact, it is difficult to identify what documentation any individual has removed during the course of employment (unless they were limited-circulation numbered documents), and this control is, in practical terms, best met through the termination interview. One standing item on the schedule for this interview should be a question as to whether or not the employee has any classified information and, if none, a reminder that any such documents must be returned.

Knowledge – the skills and competence that a terminated employee may have – should be retained in the organization. This is, in real terms, not easy to achieve. In the case of people who have critical knowledge, there should be a risk assessment prior to starting any termination action, to identify any

HUMAN RESOURCES SECURITY 137

knowledge that must be retained and to plan methods of retaining it. Unless this step is taken, one can assume that the knowledge – particularly if it is held by someone who is being unwillingly terminated – will leave the company with the employee. It is not unknown for organizations to delay commencing termination procedures with employees until the employees have successfully transferred their knowledge.

Control 9.2.6, removal of access rights, is critical, as access rights may enable a disgruntled ex-employee to compromise a system; this section should be read in conjunction with Chapter 11. The organization needs a clear documented procedure to ensure that upon termination (and some- times – subject to risk assessment and local legislation – before termination), an employee’s (or contractor’s) access rights are also terminated. Similarly, any change in employment should also lead to a review and adjustment of existing access rights. These access rights include passwords, tokens and other authentication rights, e-mail and internet user accounts and user names, electronic files, etc and should be extended to include any identifica- tion cards, including business cards and headed notepaper. It may be necessary for ex-employee e-mail accounts to continue in use for a period after termination, and this should be covered by a standard policy that sets out how the e-mail auto-responder should be set up, who should have ownership of the account and how any incoming e-mails should be treated.

4

Organizing information security

It is both practical and sensible to consider the organization’s information security management structure at an early stage in the implementation process. This does, in fact, need to be thought through at the same time as the information security policy is being drawn up, as set out in Chapter 5. An effective information security management structure also enables the risk assessment (to be discussed in Chapter 6) to be carried out effectively.

The second control category in Annex A to the standard, in clause A.6.1, is ‘Internal organization’. Controls are selected to meet business, regulatory or contractual requirements (the baseline security criteria), or in response to the risk analysis (see Chapter 6); there is a business requirement to put an information security management structure in place from the start of the ISO27001 project. The control objective of control A.6.1 is to ‘establish a management framework to initiate and control the implementation and operation of information security within the organization’.

This objective encourages the creation of the management information security forum identified in earlier versions of the standard. More impor- tantly, it no longer prescribes any specific management structure; the key requirement is management’s active support for and commitment through- out the organization to the ISMS project. Without this, neither certification nor the project itself will be successful. Clause A.6.1.1 of ISO27002, says that information security responsibilities should be defined and allocated (which reflects also the requirement of ISO27001 clause 5.3) and explains, what best practice expects in terms of the allocation of roles and responsi- bilities. At the same time, the competence requirements of Clause 7.2 should also be considered.

IT GOVERNANCE56

Internal organization

ISO27002 echoes the requirement that managers should actively support security within the organization through ‘clear direction, demonstrated commitment, explicit assignment and acknowledgement of information security responsibilities’. In practical terms, this means that managers should set up a top-level forum or steering group to ensure that there is clear direc- tion and visible management support for security initiatives within the organization. It could be part of an existing management body, which might be appropriate in a smaller organization where the members of the top management team will also, broadly, be the members of an information security forum. More usually, it will be a separate cross-functional body, adequately resourced for its responsibility, reporting to a member of the top management team and reflecting top management support and commit- ment. In this book, we will usually refer to this management group as ‘the forum’. The effectiveness of this forum will be fundamental to both the effectiveness of the ISMS and compliance with clauses 5.1, 5.2 and 5.3 of the standard.

ISO27003, the formal guidance on ISMS implementation, identifies roles for an information security committee and an information security planning team. The information security committee should have delegated manage- ment responsibility for information security within the organization. The information security planning team is responsible for planning implementa- tion of the ISMS, resolving inter-departmental conflict and ensuring that the ISMS project runs to plan. In practical terms, in most organizations, the forum which was described earlier will usually evolve into an information security committee which effectively has governance responsibility for infor- mation security. In most organizations, it makes sense for the forum to have both roles: ownership of the ISMS and responsibility for planning and deploying it. In much larger organizations, it is usually sensible to follow the guidance of ISO27003: senior managers, who might be involved in the forum or committee, are not usually able to take part in the actual project work. Towards the end of the project, it is usually practical to merge the two groups, retaining an appropriate mix of roles and skills on the information security committee or future forum so that the ISMS can be maintained and developed after certification.

An effective approach to establishing the forum would be to seek member- ship from all levels of the organization, and from all parts of the organization that are likely to be affected by the ISMS project. Including, for instance,

ORGANIZING INFORMATION SECURITY 57

those who handle incoming physical mail, IT helpdesk staff, and user repre- sentatives will help the forum fully consider all relevant practical issues before making policy or procedure recommendations.

Once the ISMS has been fully established, the forum could become the information security committee identified by ISO27003, or could simply continue to be the forum. Whatever, it should meet at least twice a year and preferably quarterly. All its activities should be formally documented, together with its decisions and the reasons for them. Copies of all material presented at the meetings should be retained, and subsequent meetings should track actions agreed, report on progress for each of them and docu- ment these steps. This group should be responsible for:

 1 Identifying information security goals and strategy that meet the organization’s requirements; ensuring that goals are communicated and understood, checking whether there are adequate resources for achieving them, and whether the ISMS is properly integrated into the organization’s processes and business as usual.

 2 The review and approval of the organization’s information security policy, which must be explicitly agreed and supported by top manage- ment setting the scope of the ISMS, ensuring that information security objectives and plans are established, identifying internal and external issues and the requirements of interested parties, and agreeing how roles and responsibilities should be allocated. This should include appointing, or agreeing the appointment of, the manager responsible for informa- tion security within the organization, together with the key responsibilities of the role; this role could be given the explicit responsi- bilities identified in clause 5.3: to ensure that the ISMS conforms to the requirement of ISO27001 and to report to Top Management on the performance of the ISMS.

 3 Ensuring that sufficient resources are provided to develop, implement, operate and maintain the ISMS.

 4 Monitoring changes in exposure of key organizational information assets to major threats, deciding (within the context of any existing organizational risk treatment framework) acceptable levels of risk and ensuring that awareness of these threats is developed, as well as ensuring that the importance of complying with the ISMS is adequately commu- nicated to the organization.

 5 Ensuring that procedures and controls are implemented that are capable of promptly detecting and responding to incidents, as well as the review

IT GOVERNANCE58

and oversight of information security incidents. Receiving reports from the information security manager on the status and progress of specific implementations, security threats, results of reviews, audits, etc and ensuring that adequate steps are taken to implement findings or deal with non-conformities.

 6 The approval of major initiatives (such as any individual initiative asso- ciated with the implementation of ISO27001) to improve information security within the organization, including security aspects of systems acquisition.

 7 Establishing means of monitoring and ensuring compliance with the policy and reviewing the effectiveness of these measures periodically.

 8 Ensuring that information security objectives and requirements meet the business objectives.

 9 Ensuring that control implementation is coordinated and effective across the organization.

10 Ensuring that adequate steps are taken, on an ongoing basis, to continually improve the ISMS.

Management review

ISO27001 introduces, at clause 9.3, a requirement for a management review of the ISMS, and this should take place at predetermined intervals agreed by the board, whenever there have been significant changes to the organiza- tion’s risk environment, or business organization, and at least annually. The review process is similar to that required by ISO9001, and ISO27001 sets out clearly and in adequate detail the minimum inputs and outputs expected of such a review, which, ideally, should be carried out by the forum and, again, involve top management. The inputs are all discussed at appropriate points in this book, and the information security manager should be made responsible for gathering together the inputs and communicating, to all concerned, the outputs (decisions) of the review.

Management reviews should be fully documented, with an agenda, with minutes, and with follow-up actions. In integrated management systems, management review is likely to consider all aspects of its integrated manage- ment system: quality, environment, IT service management, information security and so on.

ORGANIZING INFORMATION SECURITY 59

The information security manager

Although good practice expects one manager to be made responsible for the co-ordination of all security-related activities, this is not a specific require- ment of ISO27001. There are potential conflicts between accepted good practice, the requirement for impartiality in ISO27001 clause 9.2.e, control A.6.1.2 for segregation of duties, and the resources actually available to the organization. One should pay particular attention to the standard, to the competences required of the role, and to reality when finalizing these arrangements. It is also worth bearing in mind that the organization may – depending on the expertise of the person selected for the information security manager role – also need access to specialist information security advice; if this is not provided by the person who manages the ISMS, it could be provided by someone else. That is entirely a matter for the organization concerned.

Practical experience demonstrates that one person really will need to be charged with managing the ISMS project, and this person should be appro- priately qualified. He or she could be appointed before the forum is set up, and his or her brief could include the formation of the forum. The benefit in this route is one of speed and, potentially, of simplicity. The board member who has been charged with responsibility for ensuring implementation of the ISMS could simply select and appoint an appropriate person and an initial project team, who could then take things forward. The selection and training of the members of a forum are potentially more time-consuming, and the period during which they are learning their roles will precede the point at which they are competent to select and appoint an appropriate information security manager. The organization may not wish to pursue this slower route.

While the information security manager does not need to be the same person as is appointed as the organization’s information security expert (the skill sets required for the managerial role, particularly in a larger organiza- tion, are likely to be different from those required for the security expert’s role), this person will still need adequate training in information security matters, and the discussion later in the chapter, headed ‘Specialist informa- tion security advice’, should be read in conjunction with this section. Obviously, the person selected for the managerial role will need to be an effective manager with well-developed communications and project manage- ment skills.

IT GOVERNANCE60

This manager should be charged with a number of defined and key activ- ities. Depending on the culture and structure of the organization, these could include:

 1 Establishing the management information security forum (unless the organization chooses to establish the forum first and then ask the forum to select the manager).

 2 Formalizing, with the forum, a standard glossary of terms. Words like ‘risk’, ‘threat’ and ‘incident’ mean different things to different people and it makes practical sense to have a standard corporate glossary that provides standard definitions of all the terms that are used for informa- tion security or in any of the management systems. ISO/IEC 27000 is a good place to start, in that it contains a full set of terms applicable to the ISMS. Other terms from other standards and frameworks (eg business continuity, or ITIL, or COBIT) could be added as required.

 3 Developing, with the forum, the security policy, its objectives and strategy.

 4 Defining, with the forum, the scope of the ISMS, taking into account internal and external issues and the requirements of interested parties.

 5 Briefing the forum on current threats, vulnerabilities and steps taken to counter them.

 6 Working with risk owners to carry out the initial information security risk assessment.

 7 Ensuring risk owners identify changed risks and that appropriate action is taken.

 8 Ensuring that the risk is managed by agreeing with the board, risk owners and the forum, the organization’s approach to risk management, the risk treatment plan and the level of assurance that will be necessary.

 9 Selecting control objectives and controls that, when implemented, will meet the objectives.

10 Preparing the statement of applicability and risk treatment plan.

11 Recording and handling security incidents, including establishing their causes and determining appropriate corrective and/or preventive action.

12 Reporting to the forum on progress with implementing the ISMS, and on incidents, issues, security matters and current threats.

13 Ensuring management reviews are carried out as required.

ORGANIZING INFORMATION SECURITY 61

14 Monitoring compliance with the standard and reporting to management on the effectiveness of the ISMS.

15 Driving continual improvement activity across the entire ISMS.

The cross-functional management forum

The concept of a cross-functional forum has disappeared from ISO27001. It was a sensible idea and organizations should consider setting one up. The driving logic is that information security activities would be coordinated by representatives from different parts of the organization with relevant roles and job functions. This is particularly relevant for larger organizations, where security activity needs to be coordinated across a number of divi- sions, companies or sites, each of which may have its own information security manager or adviser. This cross-functional forum could, in smaller organizations, be integrated into the management information security forum discussed earlier. The range of activities that might be carried out by this cross-functional forum are:

1 agreeing, across the organization, specific roles and responsibilities in respect of information security;

2 agreeing the specific methodologies and processes that are to be used in implementation of the information security policy;

3 agreeing and supporting cross-organizational information security initiatives;

4 ensuring that the corporate planning process includes information security considerations;

5 assessing the adequacy and coordinating the implementation of specific controls for new systems, products or services;

6 reviewing information security incidents;

7 supporting the communications strategy and ensuring that the whole organization is aware of the way in which information security is tackled.

There is a lot of overlap between the possible functions of the management forum and the cross-functional group described earlier in this chapter. An external certification auditor will want to know how the two key functions – coherent management of information security and coordination of infor- mation security-related activity – have been tackled. One route, clearly, is

IT GOVERNANCE62

for each forum to have very clearly differentiated functions and for the reporting lines between the two to be drawn very unambiguously.

Usefully, in all but the largest organizations these two forums can be combined. Practically, this is sensible, as otherwise the structural issues of relating the two forums and of clarifying what issues are dealt with at which level can create unnecessary bureaucracy. Where two separate groups are set up, the first to operate more at the strategic level and the second more at the implementation level, the time of the information security and functional specialists will be stretched as they will need to contribute to both. The managerial benefits of combining the two groups are so significant that this book will proceed on the basis that this is the appropriate route, and our use of the term ‘forum’ from now onwards will refer to this combined group.

The detailed work of the management forum is then best dealt with by asking the manager responsible for information security to draw up, outside the formal meetings, proposals as to how each of the issues should be dealt with.

These proposals should then be tabled, discussed and agreed by the forum. All meetings of this forum should be documented, as should actions agreed and progress against them.

The ISO27001 project group

Ideally, the forum should be set up at the outset of the project and be chaired by the senior executive or board member who is designated as responsible for the implementation of the ISMS. The forum should, initially, and in most smaller organizations, also be the project team that sees implementation through to successful conclusion and whose ongoing role clearly evolves from this initial responsibility. This intention should be clearly documented in the project plan and in the first minutes of the forum and/or terms of reference for the group.

Members

Members of the forum, a number of whom need to be in senior positions within the organization, should be selected from across the organization. Key functions that should be represented are quality or process manage- ment, human resources, training, IT and facilities management; these may all have to change their working practices significantly as a result of the

ORGANIZING INFORMATION SECURITY 63

decision to implement an ISMS. Apart from the manager responsible for information security and the trained information security expert, the most critical representation will be from HR, sales, operations and administra- tion. These tend to be the functions in which the majority of the organization’s personnel are employed and the ones that will be most affected by the imple- mentation of an ISMS. While the people invited to represent these functions should be among the most senior and widely respected individuals within them, it can also be beneficial to draw in representation from more junior ranks and certainly from end users. Without this perspective, the forum may be inadequately aware of issues ‘on the ground’, and may arrive at conclu- sions that, in practical terms, are difficult to implement.

As discussed earlier, the change process that ISO27001 implementation will require has a cultural impact. It is critical that those most able to repre- sent and articulate the needs and concerns of the key parts of the organization are included on the working party. Without their involvement, there is unlikely to be the ‘buy in’ necessary for the ISMS to be effectively developed and implemented.

Clause 7.2 of the standard requires the organization to ensure that all personnel are competent to perform the tasks assigned to them in the ISMS. This will require the organization to determine the competences required, first of the forum members and later of those charged with implementation. This chapter has pointed at the range of competences that may be required, and final decisions should be documented. See also the discussion on train- ing in Chapter 8.

As soon as the members of the implementation team have been chosen, and once their mission and role have been explained to them, it will be necessary to give them some initial exposure to the standard and to informa- tion security. There are a number of ways that this can be done. One is to send them on a Foundations of Information Security Management training course, which is a one-day seminar designed to inform and assist delegates who need a clear introduction to the principles and objectives of informa- tion security management. Such a course should be suitable as a general introduction to the subject for people who will not need to become too deeply involved in many of the details of the ISMS. Another, obviously, is to give them each a copy of this book; the first six chapters are probably the ones that will be most useful for the ‘lay’ members of the implementation team.

It is equally critical that all members of the working party understand clearly that their role is to put together and implement an ISMS that meets

IT GOVERNANCE64

the board’s requirement. The CEO needs to set this requirement clearly in front of the working party. There will undoubtedly be divergences of opin- ion between members of the team at many points during the implementation process and on a wide variety of issues. This should make for a stronger ISMS, as what emerges will be more likely to meet all the requirements of the organization. However, if the process is not managed effectively, this working party could also be the graveyard of the information security strat- egy.

When healthy disagreement degenerates to competition and open warfare, there will be little or no progress; if what emerges from the process is simply the view of one faction or another, it will not be successfully implemented.

Equally, it is possible for the working party to become bogged down in procedural issues or to be ultra-cautious in how it tackles the implementa- tion challenge. While the danger of the project dragging on can be dealt with by setting a very clear date by when implementation must be complete (even to the point of writing it into the individual performance objectives of all the members of the team), it can still fail because the working party simply does not work effectively. Clearly, therefore, the most important choice to be made in respect of both the implementation working party and the manage- ment forum into which it will evolve is that of its chairperson.

Chairperson

The choice of chairperson of this group is usually critical to its success, both as a group and in terms of how the rest of the organization views and responds to it. The chairperson needs, therefore, to be someone who is capa- ble of commanding the respect of all members of the working party. He or she needs to be wholly committed to achieving the goal of a certified ISMS within the board-agreed timetable. He or she needs to be pragmatic and prepared to ‘think outside the box’ in identifying solutions to organizational problems that are affecting implementation. This person should not be from any one of the organization’s support functions, as this will usually brand the project as an unimportant one. The project should on no account be led by an IT person, as the implementation of an ISMS simply cannot afford to be seen as only an IT project. The chairperson should, preferably, have a broad managerial responsibility within the organization as well as experi- ence in implementing cross-organizational change projects. Ideally, he or she will be the CEO or the main board director who has been charged with implementation of the board’s security policy. In smaller organizations, this

ORGANIZING INFORMATION SECURITY 65

person might also be the manager responsible for information security; in larger organizations, where this is likely to be a full-time role, the manager responsible for information security should properly report to the chairper- son of the forum. The need for segregation of duties needs also to be considered.

Not only is the structure outlined here the most effective method for delivery of the ISMS, but it is also very clear evidence of commitment from the very top of the organization to its implementation. The external ISO27001 auditor should be suitably impressed.

Records

Meetings should be scheduled ahead of time, to ensure that everyone who will be needed can record them in their diaries and be present. The frequency of meetings during the implementation phase will reflect the urgency and complexity of the implementation plan. In practical terms, meetings held fortnightly for the first few months of the implementation timetable can contribute to building momentum in it. After that, they can drop to monthly events. Once implementation is complete, the forum might meet on a quar- terly basis or when there are significant changes or business issues to consider. The forum should decide how often it needs to meet, set out its reasons and record the decision.

Meetings do not, of course, require physical attendance. They can take place by videoconference or by teleconference. What matters is that all members are able to take part, that they have adequate notice of the meeting and that the meetings are properly managed and documented.

Normal meeting principles should be established and maintained. All meetings should have an agenda and an attendance record, and action points and key decisions should be recorded in the minutes, with information about who is responsible for what actions and within what timescales. The minutes should be retained as part of the quality records, and the external auditor is likely to want to review them. In practical terms, the quality func- tion or PMO within the organization is usually best placed to provide the secretariat to this group.

While the external auditor will be particularly interested in what has been done about action points identified in the minutes, forum meetings can easily degenerate into long reviews of the minutes and actions arising from the previous meeting. Pragmatically, if the minutes are scheduled on the agenda to be dealt with at the end of the meeting, right before ‘any other

IT GOVERNANCE66

business’, meetings will be quicker and the organization will make substan- tially faster progress with the overall implementation. The chairperson should, prior to the meeting, have ensured that action points have been dealt with; this enables them to be reported on very quickly when the appropriate point on the agenda is reached.

As a matter of principle, one of the authors insists on starting meetings at the scheduled time, irrespective of how many people are in the room, and refuses to sum up progress so far for late arrivals. In the long (and some- times the short) run, everyone learns to arrive on time.

Allocation of information security responsibilities

ISO27001, at control A.6.1.1, says that ‘all information security responsi- bilities shall be clearly defined’. While the information security policy may provide general guidance as to who is responsible for which information security risk, this guidance is likely to be very broad, particularly if the policy model suggested in this book is adopted. It will not necessarily be clear to individual employees, from the policy statement, what their specific responsibilities will be. In any case, the organization will need to define clearly who is responsible for which risks, which security process and/or information asset and may have to look at geographic or site responsibilities as well.

For instance, while the need for an information security manager is clear, it is nevertheless sensible to identify individual owners of information secu- rity assets throughout the organization and confirm to them in detail and in writing their responsibilities in respect of these assets. This is an incredibly effective way of ensuring that the security of individual information assets is properly maintained on a day-to-day basis. Clause 8.1.2 (Ownership of Assets) of ISO27002 provides more information on this issue but does not add significantly to what we have said here.

There are generic responsibilities for members of particular groups of staff. The responsibilities of the members of the forum have been discussed, as have those of the information security manager. Those mentioned below could provide the basis for defining individual responsibilities within the organization and should be drawn more specifically to reflect the organiza- tional structure and systems.

IT departments should be accountable for the overall security of the system(s) for which they are responsible. This includes threat identification, assessing risks, managing projects, reviews and reporting on activity. Server room security should be another of their responsibilities.

ORGANIZING INFORMATION SECURITY 67

Local system administrators will have specific responsibilities for user registration and deletion, system monitoring, preparing security procedures, managing change control with defined boundaries and handling data back- up, designing application security, implementing internal controls and testing contingency and fall-back plans.

System managers should be responsible, at the system level, for threat identification, assessing risks, implementing selected security controls, securely configuring the system(s), setting up the user ID and password system, setting up system security monitoring, implementing change control and setting up all necessary security procedures and maintaining and testing business continuity plans.

Network managers should be responsible (at the individual domain or independent network level) for network perimeter threat identification, assessing risks, implementing selected network security controls (including firewalls), securely (designing and) configuring the network, setting up secu- rity monitoring, implementing change control, setting up security procedures and maintaining and testing network recovery plans.

Site managers should be responsible, in respect of the physical site for which they are the nominated manager, for threat identification, assessing risks, implementing selected physical controls (including perimeter controls), fire detection and response, utility services and their back-up, delivery and dispatch controls, and maintaining and testing the site’s business continuity plan. For the purposes of the ISMS, every site from which the organization operates should have at least one site manager. Where the site is a large and complex one, perhaps including a number of organizations or divisions of organizations, then a number of site managers may be required. A method of coordinating their activity will then be necessary. Clearly, the site manag- er’s responsibilities would normally be combined with a number of other line management responsibilities.

IT users throughout the organization should be required to be aware of and follow the organization’s security policy and procedures, maintain the clear desk policy and other physical security procedures, follow the pass- word and access control procedures, back up data (which is particularly important for notebook and mobile users) and comply with requirements in respect of social media and report security incidents.

Third parties should be required to comply with their contractual respon- sibilities. They should also be aware of the host organization’s security procedures and practices.

The identification of these individual responsibilities will be done throughout the process of pulling together the detailed information security

IT GOVERNANCE68

procedures; it is important for the forum members and the information security manager to be aware from the outset that this will be a key compo- nent of the drafting process for every procedure. It would be as well to adopt, at the outset, a standard template for the drafting of processes or procedures that includes headings such as ‘scope’, ‘purpose’, ‘process or procedure owner’, ‘individuals or roles identified as having responsibilities under this document’, ‘date for review (if any)’. These are in addition to the parameters required to effect suitable document control and confidentiality or availability status. There may be other items worth adding to such a template; the purpose is to ensure that all the key components are system- atically included in each new document.

Specialist information security advice

ISO27001:2013 does not have a specific requirement for an organization to deploy a specialist information security adviser. The reality, however, is that specialist advice may, at least, be necessary.

The organization may need advice from in-house or specialist external security advisers. While ISO27002 no longer provides detailed guidance on this issue, our view is that, while not all organizations will wish to employ their own specialist internal adviser and may prefer that a non-specialist internal adviser is given the security management responsibility, this person should have access to external advice (perhaps through a mentoring scheme or other support contract) that provides specialist input covering any areas in which the in-house person is deficient. It is particularly important that, in the areas of security technology and information technology generally, specialist advice is retained and is easily available. Technology, vulnerabili- ties, threats and defences are evolving so fast that it is difficult for any single individual to keep completely on top of them all.

While there is a discussion in Chapter 8 of this book about information security education and training, particularly for the users of information security facilities, it is at this point appropriate to look at the qualifications that might be appropriate for an in-house specialist adviser or that one might expect to be evidenced by an external specialist.

Bear in mind, while considering this issue, the requirement at clause 7.2 of the standard, that the organization must determine its requirements in terms of the competence necessary to perform tasks associated with infor- mation security, ensure that it is has those competences available, and that it keeps records to prove it.

ORGANIZING INFORMATION SECURITY 69

One option is for the organization to employ someone to provide the required specialist information and security advice who appears to be qual- ified by experience. However, it can be difficult for an inexperienced recruiter to identify someone who is really adequately experienced for this role. As correct selection of this person is critical to the early success of the ISO27001 project, it is worth taking a structured approach to resolving the issue.

It is recommended that any organization pursuing ISO27001 specifies from the outset that its information security adviser be appropriately quali- fied and that if someone who does not have a formal qualification but claims to be qualified through experience is recruited for the role, he or she be required (as a condition of continuing in employment beyond the initial probationary period) to demonstrate this competence by acquiring an appropriate qualification.

It is now possible to obtain a postgraduate qualification in information security management from the UK’s Open University. This course, numbered M886, is designed to help employees understand, create and manage both strategic and operational aspects of information security and it uses this book as its core textbook. We believe that this course is unique.

The International Board for IT Governance Qualifications (www.ibitgq. org (archived at https://perma.cc/XS5A-53RW)) has developed a range of ISO27001-focused certified training courses. These include a certified Lead Implementer and a certified Lead Auditor course. IBITGQ-accredited train- ing organizations are authorized to deliver training courses that prepare individuals for the externally set and monitored examination that leads to these certifications. Those who have attended these courses will all have a good understanding of key ISO27001 issues:

●● information security management concepts (confidentiality, integrity, availability, vulnerability, threats, risks and countermeasures, etc);

●● current legislation and regulations that have an impact on information security management in the United Kingdom (or in the jurisdiction in which the course is delivered, as appropriate);

●● current national and international standards, frameworks and organizations that facilitate the management of information security;

●● the current business and technical environments in which information security management takes place – security products, malicious software (malware), relevant technology, etc;

●● the categorization, operation and effectiveness of a variety of safeguards.

IT GOVERNANCE70

The British Computer Society (BCS), based in Swindon (www.bcs.org (archived at https://perma.cc/BQS6-994U)) is another link for any organiza- tion pursuing ISO27001. The BCS website describes a range of training programmes and regimes that are applicable to information professionals. More helpfully, it also describes the Information Systems Examination Board (ISEB) qualifications. The ISEB Certificate in Information Security Management Principles (CISMP) is designed to provide a foundation of knowledge for individuals who have security responsibility as part of their day-to-day role or who are likely to move into a security or security-related function.

Globally, there are now about 30 different vendor-neutral information security certificates, including those sponsored by ISACA and by the International Information Systems Security Certification Consortium (ISC 2). There is further discussion of training in Chapter 8.

The organization should, in appointing its information security adviser, pay as much attention to the quality of the individual as to his or her quali- fications and formal experience. The nature of information security threats is always changing, and the technology and context within which an organ- ization is maintaining its information are in constant flux. The information security adviser needs to be able to respond to new threats and find and protect vulnerabilities in new technologies that the organization wants to deploy to improve its competitive advantage. This requires a flexibility of thought allied to a depth of experience and a structured, balanced – and open-minded – approach to all the information security issues that the organization will encounter. Of course, high-quality people need appropri- ate compensation packages; this will be money well spent.

Segregation of duties

Another issue that has to be considered when setting up the ISMS is what the approach to segregation of duties should be. Control A.6.1.2 of ISO27002 provides for duty segregation, with the explicit objective of reducing the likelihood of misuse of organizational facilities or misappro- priation of organizational assets. The concept of segregation of duties is unlikely to be new to most readers of this book and the sensible approach is to extend the segregation rationale currently deployed within your internal control framework to cover your ICT activities as well. Key areas for consid- eration should include segregation between those who request user access

ORGANIZING INFORMATION SECURITY 71

rights and those who configure them; between those who do audits and those who are to be audited; those who update ISMS documentation and those who approve them for release; those who configure security controls (such as firewalls or IDS) and those test them – and between those who develop software and those who test or deploy it.

It should be noted that, although segregation of duties is available for selection as a control, it is not a specific requirement of the standard; the only requirement of the standard in this regard is in clause 9.2, which deals only with the requirement for internal audits to be impartial. The statement in the general introduction to the standard, that the ISMS should be scaled to the size of the organization is also relevant: smaller organizations will be much less able to segregate duties than larger ones.

Contact with special interest groups

As a practical matter, even where the organization recruits or appoints and trains a specialist security adviser, it is imperative that this person has access to specialist advice that covers the entire spectrum of information security.

It is equally imperative that there is a method of remaining current with changing issues in the information security environment. The environment and the threats within it change so rapidly that an organization systemati- cally has to keep on top of them. Your national CERT (Computer Emergency Response Team) or WARP (Warning, Advice and Reporting Point) are good starting points. The most important site for a Microsoft network is, of course, www.microsoft.com (archived at https://perma.cc/GX4A-BB7A). This carries a host of critical and relevant information, as well as updates and downloads, and should be consulted on a regular basis. The two most critical parts of the Microsoft site, from a security perspective, are the Safety & Security Centre (www.microsoft.com/en-gb/security (archived at https:// perma.cc/YY9A-6W65)) and Microsoft technet (https://technet.microsoft. com/en-gb (archived at https://perma.cc/PN7T-F4KH)). Every information security adviser should ensure that Microsoft best practice is integrated (where appropriate) into the organization’s ISMS.

There are a number of sources of regular information on information security issues. One is the information services available from this book’s website; it has a governance bias and is designed to be complementary to this book and to the range of information and support services provided by IT Governance Ltd. Other specific information security magazines worth

IT GOVERNANCE72

investigating are: SC Magazine – available online and offline, with editions for the United Kingdom, the United States and Asia Pacific, with a website at www.scmagazine.com (archived at https://perma.cc/BQS6-994U); and Infosecurity Today Magazine – website: www.infosecurity-magazine.com (archived at https://perma.cc/ZP6A-4BWB). We believe their subscription cost offers clear value for money.

There are also online services and information security websites. One online service worth exploring is https://searchsecurity.techtarget.com (archived at https://perma.cc/5SP8-ECWB), which provides a wide range of relevant, up-to-date information security advice.

Another critical website for the information security adviser is the site of the Computer Security Resource Center (US National Institute of Standards and Technology): https://csrc.nist.gov (archived at https://perma.cc/Z5WL- 42XB). This site is an excellent information centre resource for information security professionals; in particular, it carries substantial quantities of tech- nical and security information on most issues that will be of interest in setting up a certifiable ISMS.

Attendance at industry exhibitions, such as RSA and Infosec, should also be a standard part of the role. The major annual UK exhibition is Infosec, and details of exhibitions can be obtained through www.infosecurityeurope. com (archived at https://perma.cc/38HY-438C). These shows have a wide range of current products available for review, as well as a series of seminars and addresses on current and upcoming security issues.

Each of these sources of information should supplement regular visits to the Microsoft website as well as those of providers of any other chosen and installed corporate software, including particularly the providers of the chosen firewall and antivirus software. These sites will usually be the first places that identify specific threats to their software and propose solutions. The information security specialist should follow all these information sources on a regular basis and act immediately a new threat or vulnerability is identified. Sometimes the newspapers can identify threats as fast as any other organization; no source of information should be ignored!

There are two straightforward ways of identifying what local or national networks of specialists there might be. The first is by joining the local chap- ters of relevant professional organizations such as ISACA or ISC2. The second is through the ISO27001 auditor assigned to the organization by the company chosen to provide third-party certification of the ISMS against the standard. Asking the auditor for referrals and contacts is a completely sensi- ble thing to do; the auditor ought to be extremely well linked, and if he or

ORGANIZING INFORMATION SECURITY 73

she is not, then the expertise and current awareness of the auditor, and therefore his or her competence to do an adequate auditing job for the organization, ought to be questioned.

Contact with authorities

ISO27001 says, at control A.6.1.3, that ‘appropriate contacts’ should be maintained with ‘relevant authorities’ (law enforcement bodies, fire depart- ments, supervisory or regulatory bodies, ISPs and telecommunications operators) and with ‘special interest groups and other specialist security forums and professional associations (eg sources of specialist advice)’. Neither the standard nor ISO27002 sets out what would constitute ‘appro- priate contacts’; the latter does, however, set out clearly the purpose in maintaining contacts with authorities, which is to enable the organization to take appropriate action quickly, or to obtain appropriate advice, should events (security incidents) require it.

To an extent, this will be considered further in Chapter 26, which deals with business continuity management. For the purposes of this chapter, though, the organization’s information security adviser (who should be consulted and involved in all information security incidents) should system- atically develop, over the first months in the role, a series of contacts with the local police and, through them, with specialist digital forensics consult- ants, penetration testers, and the nearest police specialist ‘cybercrime’ unit (if one exists). The information security adviser should also develop contacts with the organization’s contracted providers of information and telecom- munications services, and, in particular, with those members of their staff who are responsible for dealing with information security issues, and with local or national networks of information security specialists.

Information security in project management

Control 6.1.5 deals, as the title suggests, with information security in project management. This control can apply to all projects, not just IT or informa- tion security projects, from a minor IT implementation through to a major business change project. Information security should be part of ‘business as usual’ and, therefore, information security risks and objectives should be considered at the outset of each project; where appropriate, a risk

IT GOVERNANCE74

assessment is conducted and specific controls selected and implemented to ensure the organization’s information security objectives are not compro- mised during, or as a consequence of, the project.

Independent review of information security

Control 18.2.1 says the organization should have its implementation of its information security policy independently reviewed. ISO27002 makes it clear that this can include bringing in outside auditors to review the ISMS or bringing in independent third-party certification auditors to certify it; the accredited certification audit meets this control requirement of the standard.

It does, however, recognize (as does any quality management system) that an organization ought to have its implementation of any key system or process reviewed by someone other than the person responsible for imple- menting it. This is a standard principle of an ISO9001-certificated management system, and any company that has such a management system in place can simply graft an extra responsibility on to those who have the existing ones.

An internal audit function that only has experience in financial audit will not, however, be adequately trained to carry out a quality management system audit. Equally, an audit function that already deals with internal audit of another management system will not be automatically capable of competently conducting an ISO27001 audit.

There is an IBITGQ Internal Audit qualification, and most third-party certification bodies are likely to provide training courses for internal audit teams. Quality system auditing is a necessary basis for ISMS auditing, but is not sufficient. At the very least, the internal auditor should attend a Foundations of Information Security Management course described earlier in this chapter – a one-day seminar for delegates who need a clear introduc- tion to the principles and objectives of information security management. Specific ISO27001 internal auditor courses are available, which are designed to ensure that those internal staff who are taking on an ISMS audit role will have the skills and knowledge they need. Ideally, the organization will have access to an appropriately qualified ISO27001 ISMS Lead Auditor, who can plan and oversee the entire internal audit process, and have an internal audit team that can be deployed to conduct the audits. The IBITGQ (identified earlier in this chapter) has both lead auditor and internal auditor qualifica- tions. Further information on relevant training courses can be accessed

ORGANIZING INFORMATION SECURITY 75

through https://www.itgovernance.co.uk/iso27001-information-security-training (archived at https://perma.cc/L7HP-GBH4).

Summary

The organization should put in place, from the outset, the management framework required by the standard and make it responsible for implemen- tation of the board’s information security policy. Initial training of the key people, particularly the specialist information security adviser, is important and worth investing time and money in before starting the process of imple- mentation. Once the groundwork is laid, progress can be quick.

5

Information security policy and scope

Once the information security management structure has been thought through, the initial ISMS establishment issues have been completely under- stood and the initial training of the key personnel who will be involved in the development of the policy has been put in place, the first and second steps in the Plan phase can be carried through.

Context of the organization

The Standard requires (at 4.1 and 4.2, respectively) that the context of the organization, as well as the requirements of interested parties, be identified (and preferably documented) as a preliminary step to determining both the scope of the ISMS and its overarching policy. This requirement simply forces the organization to consider, from the outset, all those factors which will determine the scope and focus of the ISMS.

ISO27000 defines ‘external context’ as being, in effect, any of the external factors that the organization has to take into account in creating its business plan and determining information security objectives; these can include sectoral characteristics; business, economic, technological, competitive and other, wider trends (on any geographic level) as well as the perceptions and requirements of stakeholders and regulatory bodies. ‘Internal context’ includes any of the aspects or characteristics of the organization that should be taken into account in designing the ISMS. These could include business model; governance structure, roles and accountabilities; organizational culture, capabilities and attitudes; existing policies, strategies, architectures and frameworks; and existing contractual relationships. Internal and external

IT GOVERNANCE78

context should be thoroughly documented. In particular, the needs and requirements of interested parties – legal, regulatory and contractual – should all be listed, preferably in a comprehensive database which enables you to describe exactly how those various information security require- ments are met within your ISMS. (See also Chapter 26 on compliance.) This step enables you to determine your baseline security criteria: the specific set of security controls that must be implemented in order to meet existing busi- ness (eg IPR protection), regulatory (eg DPA) or contractual (eg PCI DSS) requirements.

Information security policy

The information security policy is the founding document of the ISMS. It should set out top management’s vision for information security in the light of key strategic business objectives and reflect the key limitations and oppor- tunities that determine the scope of management’s ambition for the ISMS. Clause 5.2 of the standard (and control A.5.1) contains the basic require- ment. Creation of an information security policy is, however, not always as straightforward as it seems. It may be an iterative process (particularly in complex organizations dealing with complex information security issues and/or multiple domains), and the final form of security policy that is adopted may therefore have to reflect the final risk assessment that has been carried out and the statement of applicability that emerges from that.

Clause 5.2 sets out the requirements for the ISMS policy. The scope of the ISMS, and therefore the policy itself, must take into account the character- istics of the business, its organization, location, assets and technology. The policy must include or reference a framework for setting information secu- rity objectives and establish the overall sense of direction. It must take into account all relevant business, legal, regulatory and contractual security requirements. It must establish the strategic context (for both organization and risk management) within which the ISMS will operate. It must establish criteria for the evaluation of risk and the structure of the risk assessment. Of course, top management must approve it.

The security policy will also have to be regularly reviewed and updated in the light of changing circumstances, environment and experience. As a minimum, if there is no earlier reason for the board to review its policy, it should be reviewed annually and the board should agree that the policy remains appropriate (or otherwise) to its needs in the light of any changes to the business context, to the risk assessment criteria or in the identified risks.

INFORMATION SECURITY POLICY AND SCOPE 79

Initially, the information security policy is a short statement (we think organizations should aim for it to fit a maximum of two pages of A4) that is designed to set out clearly the strategic aims and objectives that will guide the development of the ISMS. The policy may go through a number of stages of development, particularly in the light of the risk assessment, but the final version must satisfy clause 5.2 of the standard and should appropriately reflect the good practice that is set out in clause 5 of ISO27002. Proof that the policy has been approved by top management, has been published and communicated internally and is reviewed regularly (usually annually, as a minimum), with any changes similarly published and communicated, will enable the organization to satisfy this requirement of the standard.

The key questions for the initial policy statement to succinctly answer are:

●● Who?

●● Where?

●● What?

●● Why?

Usually, the manager who has been charged with leading the implementa- tion of the ISMS will be charged with drafting a security policy and board paper that proposes how these questions should be answered. This paper should seek to be as objective as possible in working through the possible answers to these four questions so that the board can identify and focus on those issues that require clarification or where difficult decisions may be necessary.

A copy of that section of the minutes (preferably signed off by the chair- person as a correct copy) of the board meeting in which the security policy was debated and adopted should be filed with the security policy documen- tation. It can be a controlled record and it does, for audit purposes, provide useful and immediate evidence of the process by which the policy was adopted, and of any amendments to it. This, together with the proposal that was put to the board, is the first part of the evidence that top management have met the requirements of clause 5.1 in terms of committing to the crea- tion of an ISMS whose objectives are compatible with the strategic aims of the organization.

The policy itself should then be issued as a controlled document and made available to all who are doing work within its scope; copies could be posted on all internal noticeboards, both the physical and electronic ones. There are other methods of communication; what matters is that the

IT GOVERNANCE80

communication is effective. These copies of the policy document should of course be clearly marked as controlled copies, to ensure that they are updated to reflect any changes that take place. Copies handed out as part of training or awareness seminars, or to third parties, should be marked as uncontrolled copies.

Who?

‘Top management’ has to be completely behind and committed to the ISMS; therefore, the policy statement must be issued under their authority and there should be clear evidence, in the form of written minutes, that the policy was debated and agreed both by the board as a whole and by any separate management steering group. Any revisions to the policy should also be debated and agreed by both the board and the steering group.

From a practical point of view, it is worth keeping the policy statement as simple, as comprehensive, as principled and as strategic as possible so as to allow managers adequate freedom to respond to changing business and security circumstances in implementing it without needing to return to the board and the forum for the policy itself to be freshly agreed.

It will also require participation by all employees in the organization and should reflect the needs of customers, suppliers, shareholders and other third parties. This is part of the context of the ISMS referred to earlier. In thinking through the security policy, the board and the forum will need to consider what impact it will have on these constituents and/or audiences and the benefits and disadvantages that the business will experience as a result of this.

Where? (scope of the policy and the ISMS)

Those parts of the organization within which the policy is going to apply need to be clearly identified. The standard is explicit that the scope must be determined once the context of the organization (internal and external issues) and the requirements of interested parties have been established. This may be done on the basis of corporate, divisional or management structure, or on the basis of geographic location. There should be logical access to all assets within scope, and consideration given to occurrences of those assets at other sites. In other words, the dependencies and interfaces of the assets within scope will need to be made clear within the scope statement. In larger, more complex organizations, network maps, organization charts, business architecture diagrams and information flow charts may be useful tools for

INFORMATION SECURITY POLICY AND SCOPE 81

clarifying possible scope statements. ISO27003 says that, as part of the scoping exercise, the assets on which the key business processes depend should be identified, their ownership clarified and their security require- ments analysed.

A virtual organization, a cloud-based business or a dispersed, multi-site operation, may each have security issues different from those that affect one located on a single site. In practical terms, a security policy that encom- passes all of the activities within a specific entity for which a specific board of directors or ‘top management’ team is responsible is more easily imple- mented than one that is to be applied to only part of the entity. It is important to ensure that the management team that is implementing the policy does actually have adequate control over the operations contained within scope and that it will be able to give a clear mandate to implement the security policy within that scope. The section in Chapter 6 ‘Identify the boundaries’ should also be read at this point, particularly as the ISMS is required to be considered within the overall organizational context.

It is critical, if there are aspects of the organization’s activities or systems that are to be excluded from the requirements of the security policy, that these are clearly identified – and explained – at this stage. Multi-site or virtual organizations will need to consider carefully the different business requirements of their different sites and the security implications of them. There should be clear boundaries (‘defined in terms of the characteristics of the organization, its location, assets and technology’) within which the security policy and ISMS will apply. Any exclusions should be openly debated by the board and the steering group, and the minutes should set out how and why the decision was taken. It is possible that, in fact, divisions of the organization, components of the information system or specific assets will not be able to be excluded from the scope, either because they are already integral to it, or because their exclusion might compromise a depend- ent business process or undermine the information security objectives themselves. It must therefore be clear that any exclusions do not in any way compromise key business processes or undermine the security of the organi- zation to be assessed.

This is particularly important where outsourced processes are concerned. Outsourced processes (but not the organizations to which they are outsourced) should be included in the ISMS scope and subject to appropri- ate controls. This is sensible. You need assurance that your key business processes – even if operated by third parties – are still operated within your risk tolerance.

IT GOVERNANCE82

Auditors will be assessing how the management team applies its policy across the whole of the organization that is defined as being within the scope of the policy and should be expected to test to their limits the boundaries of the stated scope to ensure that all dependencies and interfaces with security- related processes have been identified and adequately dealt with.

In reality, as stated earlier, the process of designing and implementing an effective ISMS may be made simpler by including the entire organization for which the board has responsibility. Even so, there will still need to be deci- sions about client and supplier access as well as any disaster recovery site. Access to information assets within the scope (for example, data hosted on a server that is within scope) from a geographically remote site will have an effect on the arrangements for maintaining the confidentiality, integrity and/ or availability of that data, and so in one way or another will be a concern of the ISMS. These issues all need to be addressed through the scope state- ment and the risk assessment.

There is an argument, in large, complex organizations, for a phased approach to implementation. Where it really is possible to define adequately a subsidiary part of the organization, such that its information security needs can be independently assessed, it may be possible to gain substantial experience in designing and implementing an ISMS, as well as a track record of success and the momentum that accompanies it, such that a subsequent roll-out to the rest of the organization can be carried through successfully and smoothly. These considerations apply to any large, complex project, and the appropriate answer depends very much on individual organizational circumstances.

It would certainly be a mistake to define the scope too narrowly. While it may appear, on the surface, to be a quick and easy route to certification, it is in fact a route to a worthless certificate. Any external party assessing the organization’s ISMS will want to be sure that all the critical functions that may affect its relationship, and the information about which it is concerned, are included, and limiting the scope will compromise this objective.

The overall issue of scoping is certainly one where experienced, profes- sional support can be helpful in assessing the best way forward.

What?

The statement that the top management ‘is committed to preserving the confidentiality, integrity and availability of information’ is at the heart of a security policy and an ISMS. It is important to define precisely the key terms

INFORMATION SECURITY POLICY AND SCOPE 83

used in the policy, and we recommend that the definitions contained in ISO27000 are used. For ISMS purposes, ‘information’ should be very widely defined:

Information [can be] printed or written on paper, stored electronically,

transmitted by post or using electronic means, shown on films, [or] spoken in

conversation.

In other words, appropriate protection is required for all forms of information:

Confidentiality [is defined as] information not made available or disclosed to unauthorized individuals, entities or processes.

Integrity [is defined as] the property of accuracy and completeness.

Availability [is defined as] being accessible and usable upon demand by an authorized entity.

Availability is particularly important to cloud-based businesses, or those engaged in e-commerce or social media. A business that depends for its very existence on the availability of its website, but that fails to take adequate steps to ensure that the site is up, running and running properly at all times, is likely to fail as a business much more quickly than a traditional bricks- and-mortar business that is unable to open its shop doors for a few days.

Members of the board, the management team and the staff of the organ- ization should all understand that these are the definitions of these words, and they should be prominently described and set out in the early briefings to staff and in internal communications. Auditors from certification bodies are likely to check (probably randomly) that staff understand what these words mean, and while they will not look for staff to remember these defini- tions verbatim, they will want staff to demonstrate practical understanding of how the pursuit of these aspects of information security is likely to have an impact on their own work. This level of understanding is required, as a minimum, so that each member of staff is able to recognize and react appro- priately to a security incident. Information security incident management is covered in Chapter 24.

There is also the point at which the organization needs to determine its criteria for accepting risks and to identify the levels of risk it will accept. It is a truism to point out that there is a relationship between the levels of risk and reward in any business. Most businesses, particularly those subject to FRC Risk Guidance and similar standards, will want to be very clear about

IT GOVERNANCE84

which risks they will accept and which they won’t, the extent to which they will accept risks and how they wish to control them. The management team needs to specify its approach, in general and in particular, so that the busi- ness can be managed within that context.

Risk assessment is discussed further in Chapter 6.

Why?

Information security, broadly speaking, may be defined as: ‘the protection of information from a wide range of threats in order to ensure business conti- nuity, minimize business damage and maximize return on investments and business opportunities’ and is also ‘essential to maintain competitive edge, cash-flow, profitability, legal compliance and commercial image’. The initial staff communication process should set out clearly the nature of the threats faced by the organization and the possible costs, in both financial and non- financial terms, of information security breaches. The information provided in this book can be used for that purpose, but, wherever possible, local and/ or industry-specific information should be sought and used, as this gives immediacy and currency to the possible threats. Illustrations of the possible consequences to the organization itself should be developed in order to help all those involved to fully appreciate the need for the ISMS.

The ‘where’ and the ‘what’ answers above form the basis of the statement of the scope of the ISMS. There is a further, and more detailed, discussion of some of the issues related to scoping the ISMS in the next chapter, in the context of risk assessments. There should be a single document that identi- fies the internal and external context as well as the requirements of interested parties and, in that light, sets out clearly the organization(s) that fall within the scope of the policy, which locations, which assets and which techno- logies. This statement of policy is an essential initial document, which not only helps focus the development of the ISMS but also makes clear to all concerned the seriousness of their responsibilities. It may be sensible, at this stage, to divide the organization into separate security domains. A ‘domain’ is a discrete logical or physical area of an organization or network that is the subject of security controls designed to protect it from outside access. A domain should be capable of representation on a diagrammatic map. An organization or a network may be made up of one or a number of domains.

INFORMATION SECURITY POLICY AND SCOPE 85

A policy statement

The initial policy statement might, therefore, read as follows:

The board and management of organization Y, which operates in sector Z

(or is in the business of Z, etc), located in …, are committed to preserving

the confidentiality, integrity and availability of all the information assets

throughout their organization in order to maintain its competitive edge,

cash-flow, profitability, legal and contractual compliance and commercial

image. Information and information security requirements will continue to be

aligned with organizational goals, and the ISMS is intended to be an enabling

mechanism for information sharing for electronic operations, for e-commerce

and for reducing information-related risks to acceptable levels. All employees of

the organization are required to comply with this policy and with the ISMS that

implements this policy. Certain third parties, as defined in the ISMS, will also be

required to comply with it. This policy will be reviewed when necessary and at

least annually.

In addition, the policy should cover the following areas:

• It should announce that a top-level management steering group will be

established to support the ISMS framework and periodically review the

security policy.

• It should outline the approach to risk management, the criteria against which

risk will be evaluated, the structure of the risk assessment and who will be

responsible for it.

• It could briefly identify specific policy requirements, such as access policy,

malware stance, mobile working, back-up and roll-over, and security incident

reporting.

• It should contain a commitment to meet other information security or

compliance requirements, whether business, regulatory (eg data protection

acts), statutory (eg corporate legislation) or contractual (eg PCI DSS).

• There should be a clear statement of the requirement that information

security continue to be aligned to specific business goals and contain

a framework for setting information security objectives across the

organization.

• It could explain that all staff will receive security awareness training and

specialized staff will receive more specialized training.

• It could formally state the commitment to comply with, and achieve and

maintain accredited certification to, ISO27001.

IT GOVERNANCE86

It must state that the ISMS is subject to continual improvement. Such a statement would be sufficiently general to cover all the key compo-

nents of information security for organization Y for the foreseeable future, but sufficiently precise and clear to be effective as a policy statement. It should clearly be approved by the management information security forum and signed by the most senior person in the organization (the chairperson, president, CEO, director-general, etc). A template for an information secu- rity policy is included in the ISO27001 ISMS Documentation Toolkit.

The security policy statement can be expanded, in the light of the risk assessment, to take into account the further guidance of clause 5.1 of ISO27002. The policy statement proposed here does, however, meet the requirements of clause 5.2 of ISO27001.

Costs and the monitoring of progress

Any sensible board or management team will, at this stage, also require an estimate of the costs and resources involved in implementing the ISMS, an assessment and quantification of the potential benefits, and an outline imple- mentation plan that describes, at the top level, who will be responsible for doing what and by when. Such a document should be prepared and presented to the board along with the proposed security policy. This document should set out clearly the proposed dates at which the board will be invited to review progress towards final implementation so that it can ensure that its policy is being properly implemented.

As all organizations have their own preferred formats for doing this, this book does not set out how to do it. It only argues that review dates should be realistically spaced and that the plans it approves should allow executive managers sufficient flexibility in implementing a policy that will have to be designed in the light of facts that are not known at the point at which the policy is adopted.

It is suggested that the key points at which progress might be reviewed are:

1 After completion of the risk assessment; the full range of risks to be managed will have been identified.

2 After completion of a draft statement of applicability (SoA). Any costs incurred prior to this should be minimal, but until the SoA defines what

INFORMATION SECURITY POLICY AND SCOPE 87

needs to be done, it will not be possible to budget effectively for the implementation.

3 After implementation of the initial suite of procedures that apply the identified controls.

4 After completion of the first cycle of system audits and reviews in accordance with clause 9.2 of the standard and prior to the initial visit by the certification body.

5 Annually, as part of the regular review of the ISMS, to ensure that the budget is being correctly applied and that any new technology issues, threats or vulnerabilities have been taken care of.

It is assumed that the organization will already have well-developed proce- dures for dealing with projects that are missing key review dates and in which there is overspending or underperformance. The IT Governance website has resources and guidance on effective project governance, and this book will not, therefore, make any proposals about what action should be taken to rectify any shortfalls, but will make the observation that early and vigorous action by the board to ensure that there is compliance with its requirement to design and implement an information security policy and management system will go a long way to proving to the organization the seriousness of the endeavour and thus to bringing about its achievement.

6

The risk assessment and Statement of Applicability

Establishing security requirements

An earlier version of ISO27001 identified three sources for establishing the organization’s information security requirements: the risks that the organi- zation faces (business, risks, discussed further below); the risks arising from the compliance and contractual requirements imposed on the organization in each of the jurisdictions in which it operates (compliance requirements in particular are discussed in Chapter 26); and the ‘particular set of principles, objectives and business requirements for information processing that an organization has developed to support its operations’, which are the conse- quence of the IT architecture the organization has previously established to support its business model.

Risks, impacts and risk management

All organizations face risks of one sort or another on a daily basis. Risk management is a discipline that exists to deal with non-speculative risks – those risks from which only a loss can occur. In other words, speculative risks, those from which either a profit or a loss can occur, are the subject of the organization’s business strategy whereas non-speculative risks, which can reduce the value of the assets with which the organization undertakes its speculative activity, are (usually) the subject of a risk management plan (in ISO27001, a ‘risk treatment plan’). These are sometimes called permanent and ‘pure’ risks, in order to differentiate them from the crisis and speculative types.

IT GOVERNANCE90

Risk management plans usually have the following linked objectives, which are:

●● to eliminate risks;

●● to reduce to ‘acceptable’ levels the risks that cannot be eliminated;

●● to deal with the risks at ‘acceptable’ levels, in one of the following ways:

– living with them, exercising carefully the controls that keep them ‘acceptable’;

– transferring them, by means of insurance, to some other organization;

– committing to a plan to reduce the risk to an acceptable level within a defined time frame.

Pure, permanent risks are usually identifiable in economic terms; they have a financially measurable potential impact upon the assets of the organiza- tion. The requirements of Sarbanes–Oxley, COSO, the FRC Risk Guidance and, for financial sector organizations, the Basel 2/3 Frameworks have raised risk management – and, in particular, operational risk management – to a core function in most large organizations.

Risk acceptance criteria

Risk management strategies are usually based on an assessment of the economic benefits that the organization can derive from an investment in a particular control; in other words, for every control that the organization might implement, the calculation would be that the cost of implementation would be outweighed, preferably significantly, by the economic benefits that derive from, or economic losses that are avoided as a result of, its implemen- tation. ‘Risk appetite’ is the phrase used to describe managers’ level of preparedness to take risks. The capacity of the organization to absorb loss will be one of the key determinants of risk appetite. The organization uses risk acceptance criteria for determining which risks it will take and which ones it will reject. Alternatively, it could apply controls to reduce risks to a level that it can tolerate.

The organization should define its criteria for accepting risks (for exam- ple, it might say that it will accept any risk that has an economic impact less than the cost of controlling it) and for controlling risks (for example, it might say that any risk that has both a high likelihood and a high impact must be controlled to an identified level, or threshold).

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 91

Before we turn to a detailed consideration of the risk assessment process, we have to recognize that most organizations will already have made a number of decisions about risks (they have, after all, been in business for a time, dealing with threats and vulnerabilities for real) and will also have implemented a number of controls in order to comply with statutory, regu- latory or contractual requirements. The organization will need to decide how it incorporates these existing controls into its ISMS and its risk assess- ment methodology.

The first, sensible step is simply to recognize, in your risk assessment methodology, that the requirements of interested parties (what we have called the ‘Baseline Security Criteria’ have led the organization to implement specific controls; identify the interested parties and their requirements as described in Chapter 5 (‘Context of the Organization’), and state that the related controls – called Baseline Security Controls – are incorporated as they are into the ISMS. You then have to determine how you handle all the other controls which are already in place, the ones that you adopted at some earlier point to meet specific security criteria at the time. You either review them, now, for adequacy and effectiveness, or you recognize their existence and simply accept them as part of your baseline security control set, focus- ing your risk assessment on those remaining risks which are not yet appropriately treated. For example, a door is a control but, in assessing the security of a room you recognize that the door is already in place, accept its adequacy as a control, and focus on other entry routes (‘attack vectors’).

For most organizations, the practical approach is to adopt the baseline security control approach and focus on remaining risks. Thereafter all controls, new and old, can be reviewed for effectiveness as part of the continual improvement programme.

Approach to risk assessment

Approaches to enterprise risk management provide the backdrop against which the requirements of IT governance and ISO27001 should be consid- ered. ISO27001 requires a risk assessment to be undertaken. This is at the heart of the ISMS. Clause 6.1.2 of the standard requires the organization to ‘define and apply an information security risk assessment process’, which should be appropriate for the organization, its information security objec- tives and the identified business, legal and regulatory requirements (the baseline security criteria).

IT GOVERNANCE92

Although the standard identifies ISO31000 and ISO/IEC 27005 as providing useful guidance for risk assessment, the organization is in fact at liberty to deploy any appropriate risk assessment methodology that reflects its internal and external context and the requirements of its interested parties. The risk assessment methodology could – but does not need – to be asset-based. It must identify risks, risk owners and risk acceptance criteria, must analyse risks in terms of likelihood and consequence and, above all, must produce ‘consistent, valid and comparable results’.

ISO27001 allows flexibility in choice of risk assessment methodology both in order to simplify, for larger organizations, the process of integrating information security risk management with the enterprise-level risk manage- ment framework (eg ISO31000) already in place and, for organizations facing specific contractual or market requirements, customer and contrac- tual alignment.

There are a number of risk assessment methodologies – some asset-based, others scenario-based – which might be appropriate for use in an ISMS. We have drawn all those methodologies together into a single, comprehensive guide to risk management, called Information Security Risk Management for ISO27001/ISO27002 also by Alan Calder and Steve G Watkins (2019). This chapter focuses on the risk assessment methodology contained in ISO/ IEC 27005, as it is specifically designed for use within an ISO27001 ISMS.

Risk assessment is a systematic study of the probability and consequences of events, or, alternatively, the systematic and methodical consideration of: 1) the business harm likely to result from a range of business failures; and 2) the realistic likelihood of such failures occurring. Risk treatment (which, with risk assessment, makes up the two stages of risk management) might involve the selection of controls in order to reduce risk to an acceptable level.

The information security risk assessment must be a formal process. In other words, the process must be planned, and the input data (including how existing controls incorporated), their analysis and the results should all be recorded. ‘Formal’ does not mean that risk assessment tools must be used, although in many situations they are likely to turn a potentially diffi- cult and time-consuming task into one that can be completed in a meaningful timescale and to add significant value. Risk assessments must also produce ‘consistent, valid and comparable results’; this requirement (clause 6.1.2.b) tends to support the use of a purpose-developed risk assess- ment tool (like, for instance, vsRisk™), and a well-defined methodology.

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 93

The complexity of the risk assessment will depend on the complexity of the organization and of the risks under review. The techniques employed to carry it out should be consistent with this complexity and the level of assurance required by the board.

You should, at this point, extend your initial glossary of terms to in clude definitions (all of which should be sourced from ISO27000) of risk, risk analysis, risk assessment, risk evaluation, risk management and risk treatment.

Who conducts the information security risk assessment?

It is entirely up to the individual organization to choose who is to perform this risk assessment, and how. There are two issues to consider before decid- ing who will do it. The first is that there should be periodic reviews of security risks and related controls – taking account of new threats and vulnerabilities, assessing the impact of changes in the business, its goals or processes, technology and/or its external environment (such as legislation, regulation or society) and simply to confirm that controls remain effective and appropriate.

The second is that the standard requires the organization to identify the competences required of the people operating within the ISMS, including those involved in risk assessment. The need for an appropriately competent person was covered in some detail in Chapter 4. It is essential that risk assessment – the core competency of information security management – is conducted by an appropriately qualified and experienced person. This is logical; the key step on which the entire ISMS will be built needs, itself, to be solid. The ISO27001 auditor will therefore want to see documentary evidence of appropriate knowledge skills.

A number of organizations will already have a risk management function staffed by people with training that enables them to carry out risk assess- ments. The role of the risk management department is, usually, systematically to identify, evaluate and control potential losses to the organization that may result from things that have not yet happened. The skills and methodol- ogy of this department may or may not meet the organization’s requirements. Either way, there are potentially significant benefits for such an organization if its information security risk assessments can be carried out by the same function that handles all risk assessments. The benefits lie not just in cost- effectiveness but in the fact that such a risk management or risk control

IT GOVERNANCE94

department will have an existing and ongoing understanding of the busi- ness, its goals and environment, and an appreciation of all the risks faced by the business in the pursuit of its objectives. Equally, it should be able to assess how all the different risks, and the steps taken to mitigate them, may be related and coordinated.

Many organizations, however, do not already have an internal risk management function. There are then two possible ways to tackle risk assessment. The first is to hire an external consultant (or firm of consultants) to do it. The second is to train someone internally. The second is preferable in most cases, as the organization ‘shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur’, and having the expertise in-house enables this to be done cost- effectively. Chapter 4 discusses how to recruit and/or train a specialist information security adviser, and if information security risks are the only ones being considered, then this would be an appropriate person to under- take the risk assessment.

In circumstances where the organization has existing arrangements with external suppliers for risk assessment services, or is in the process of setting up a risk management function or capability (in the context of responding to the requirements of an external risk management requirement, perhaps), then it should from the outset investigate ways in which its risk assessment processes can be integrated.

It is more difficult for a smaller business to retain specialist information security expertise in-house than for a larger one; the internal risk assessment role needs to be maintained over time and the person concerned needs to continue being trained and involved in risk assessment issues, both inside and outside the organization. The disadvantage of hiring external risk asses- sors, apart from the cost, is that the organization does not necessarily get continuity of involvement from a firm of assessors. The advantage of the external hire, apart from its being a variable cost, is that the external asses- sor should be up to date on relevant issues and should be wholly objective. A possible middle route is to contract on a multi-year basis, with an appro- priately trained individual or consultancy firm to provide risk assessment support and guidance as and when it is required. But however the organiza- tion chooses to acquire this resource, it is crucial that a lead risk assessor is in place and fully involved in the risk analysis and assessment process that the rest of this chapter describes.

There are software tools that have been designed to assist in risk assess- ment, but the use of them is not mandatory. It is essential, though, that the

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 95

risk assessment should be done methodically, systematically and compre- hensively, producing valid, consistent and comparable results; this means that the process should not be subjective or rely exclusively on the experi- ence and judgement of one or two information security professionals. An appropriate information security risk assessment tool, designed with ISO27001 in mind and kept up to date in terms of changing information security issues, can be effective in this process. vsRisk™, from Vigilant Software Ltd, is one such tool.

Security in any system should be commensurate with its risks. However, determining which security controls are appropriate and cost-effective can be a complex and subjective process. One of the prime functions of security risk analysis is to put this process on to a more objective basis. Most forms of risk analysis involve the use of risk analysis tools, specific to ISO27001, that are designed to ensure that the scope of the exercise is comprehensive and the process rigorous.

There are a number of different approaches to risk analysis. However, these essentially break down into two: quantitative and qualitative.

Quantitative risk analysis

This approach looks at two issues: the probability of an event occurring and the likely loss should it occur. A single figure is produced from these two elements, by simply multiplying the potential loss (measured in monetary terms) by its probability (measured as a percentage). This is sometimes called the annual loss expectancy (ALE) or the estimated annual cost (EAC). Clearly, the higher the number that an event or risk has, the more serious it is for the organization. It is then possible to rank events in order of risk (ALE) and to make decisions based upon this.

The problems with this type of risk analysis are usually associated with the unreliability and inaccuracy of the data. Probability is usually assessed subjectively and is rarely precise. In some cases, this approach can promote or reflect complacency about the real significance of particular risks. The monetary value (particularly of reputational damage) of the potential loss is also often assessed subjectively, and when the two components are multi- plied together, the answer is equally subjective. When quantitative analysis is done accurately, the time cost of that accuracy quite often outweighs the benefits the organization is able to derive from it.

In addition, controls and countermeasures often have to tackle a number of potential risk, and the risks themselves are frequently interrelated.

IT GOVERNANCE96

A detailed ranking in order of ALE can make it difficult to identify these interrelationships and lead to poor, cost-ineffective decisions about controls, and this approach is not, therefore, recommended. Nevertheless, we do recognize that a number of organizations have successfully adopted quanti- tative risk analysis.

Qualitative risk analysis

The qualitative approach is by far the more widely used approach to risk analysis and is the approach at the heart of ISO27005. Numeric probability data are not required, and only estimated potential loss is used. Most quali- tative risk analysis methodologies make use of a number of interrelated elements, and they are best laid out in tabular form in a corporate risk log, so that, for each asset, its owner(s), threat(s), vulnerabilities and impact(s) are identified.

ASSETS WITHIN THE SCOPE

The first step is to inventory all the information assets (and ‘assets’ includes processes, information, information systems, hardware, software, etc; control 8.1.1. of ISO27002) within the ISMS scope and, at the same time, document which role and/or department ‘owns’ the asset, as provided for in control 8.1.2. Although not mandated by ISO27001, asset-based risk assessment is the most sensible approach.

THREATS

Threats are things that can go wrong or that can ‘attack’ the identified assets. They can be either external or internal to your organization; they are always external to the asset. Examples might include fire or fraud; many such potential threats are described in Chapter 1. Threats are always present for every system or asset; because it is valuable to its owner, it will be valuable to someone else; if it is lost, it would have an impact. If you cannot identify a threat to an asset, you might assume that it is not really an asset.

VULNERABILITIES

Vulnerabilities leave a system, or asset, open to attack by something that is classified as a threat, or allow an attack to have some success or greater impact. For example, for the external threat of fire, a vulnerability could be the presence of flammable materials (eg paper) in the server room. In the language of the standard, a vulnerability (which can be an absence of or

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 97

weakness in a control) can be exploited by a threat. The baseline security criteria approach means that, when carrying out a risk assessment, you are looking at risks which exploit vulnerabilities that exist in spite of the controls that are already in place to meet contractual, regulatory and business requirements.

IMPACTS

The successful exploitation of a vulnerability by a threat will have an impact on the asset’s availability, confidentiality or integrity – in respect of all or one of the business, contractual or compliance requirements of the business. These impacts should all be identified and, wherever possible, assigned a relative value based on the cost to the organization of that attribute being compromised.

RISK ASSESSMENT

The risks then have to be assessed to identify the potential business harm that might result from each of them. There should then be an assessment of the likelihood of the threat exploiting the vulnerability to create the impact. This enables one to identify the level of risk (and, for smaller organizations, a low–medium–high classification is usually adequate), and this enables one to conclude, for each risk, whether it is acceptable or if, conversely, some form of control is required.

CONTROLS

Controls are the countermeasures for risks. Apart from knowingly accepting risks that fall within the criteria of acceptability, or transferring the risk (through contract or insurance) to others, the ISC2 Common Body of Knowledge (CBK) describes five types of control:

1 directive controls, which are generally administrative, such as creating policies;

2 preventive controls, which protect vulnerabilities and make an attack unsuccessful or reduce its impact;

3 detective controls, which discover attacks and trigger preventive or corrective controls;

4 corrective controls, which reduce the effect of an attack;

5 recovery controls, which are often associated with business continuity and disaster recovery.

IT GOVERNANCE98

We believe the first of these is actually a way of delivering the second, third and fourth and that the fifth is a subset of the fourth.

It is essential that any controls that are implemented are cost-effective. The principle should be that the cost of implementing and maintaining a control should be no greater than the potential (time-sensitive) cost of the impact. It is not possible to provide total security against every single risk, but it is possible to provide effective security against most risks. However, these can change, and so the process of reviewing and assessing risks and controls is an ongoing one.

The process for assessing risk builds on the scoping exercise discussed in Chapter 5 and should be focused on critical systems and information assets (at least initially; organizations can, if they wish, deal with non-critical systems and assets at a later date). It can be broken down into a number of clearly defined steps:

1 Identify the boundaries of what is to be protected (the scope).

2 Identify the assets: all the systems necessary for the key business processes of receiving, storage, manipulating and transmitting information within those boundaries and the information assets within those systems.

3 Identify the relationships between these systems, the information assets and the organizational objectives and tasks.

4 Identify criticality: identify those systems and information assets that are critical to the achievement of organizational objectives and tasks.

5 Identify the potential threats to those critical systems and assets.

6 Identify the potential vulnerabilities of those critical systems and assets.

Clearly, the combination of the likelihood of the threat exploiting the vulner- ability, when combined with the impact on the organization of the asset being compromised, enables the risks that relate to each of the assets to be identified. However, we will first explore each of the steps above in more detail.

Identify the boundaries

It is essential to decide the boundary within which protection is to be provided. The business environment and the internet are each so huge and diverse that it is necessary to draw a boundary between what is within the organization and what is without. In simple terms, boundaries are physi- cally or logically identifiable. Boundaries have to be identified in terms of

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 99

the organization, or part of the organization, that is to be protected, which networks and which data, and at which geographic locations.

Identifying boundaries within the Cloud is particularly difficult. The key concept to have in mind is that the scope of the ISMS cannot include elements which are outside the control of management. A Software as a Service (SaaS) product (eg Office365) is outside the organization’s control; Microsoft make decisions about how to secure it and their customers can take or leave the consequences. All the client can do is to decide whether or not, on the basis of Microsoft’s ISO27001 certification, to trust its data to their SaaS offering.

ISO/IEC 27018 provides an additional set of controls, complementary to those in ISO27002, which are specifically intended for use in Cloud environ- ments, where a data controller contracts with a cloud processor in relation to personally identifiable information (PII). This control set is more broadly useful in helping organizations address security issues in a distributed cloud environment. ISO/IEC 27017 provides an additional generic set of controls for cloud computing services.

Cyber Essentials

This is a useful point to identify the existence of the UK Cyber Essentials scheme. This is an accredited certification scheme that sets out minimum security controls that every organization of any size should adopt in order to protect itself from the majority of low-level but high-volume cyber attacks. Achievement and maintenance of Cyber Essentials certification could be seen as a baseline security control, at the cyber level of fitting doors and windows with working locks; it is increasingly a baseline requirement for contracting with the UK government. The Cyber Essentials scheme works well with ISO27001; read more about it at www.itgovernance.co.uk/ iso27001-and-the-cyber-essentials-scheme (archived at https://perma.cc/ T4G2-FCSB).

Scope was first mentioned in Chapter 5. The organization that is within the ISMS scope must be capable of physical and/or logical separation from third parties and from other organizations within a larger group. While this does not exclude third-party contractors, it does make it practically very difficult (although not necessarily impossible) to put an ISMS in place within an organization that shares with others significant network and/or informa- tion assets or geographic locations. A division of a larger organization that,

IT GOVERNANCE100

for instance, shares a group head office and head office functions with other divisions could not practically implement a meaningful ISMS. Usually, the smallest organizational entity that is capable of implementing an ISMS is one that is self-contained. It will have its own board of directors or manage- ment team, its own functional support, its own premises and control over its own IT network.

It is nevertheless possible for divisions of larger organizations to pursue certification independently; the critical factors are the relative independence of management and the extent to which the division can be practically differentiated from other divisions of the same parent organization.

For larger organizations, with a multiplicity of systems and extensive geographic spread, it is as a general rule often simpler to tackle ISO27001 and, in particular, risk assessment on the basis of smaller business units that meet the general description set out above. Larger organizations that have a single business culture and largely common systems throughout are proba- bly better off creating a single ISMS.

Once the organizational scope is identified, it is necessary to list the phys- ical premises that the chosen organization occupies and to identify its network and information assets. The implementation team should list these, but should only do it at this point at the highest possible level.

Identify the assets

Assets are discussed in more detail in Chapter 8. Primary assets are the key business processes and information. Key information assets may have be either information systems or bodies of information. A system consists of a number of components. A single data asset (such as a file, whether electronic or paper) is a component of a system. At this stage, we are concerned only with the systems, although at a subsequent point it may be necessary to analyse vulnerabilities down to the individual data asset level.

These systems will include a number of IT systems, consisting of software (eg client relationship management system, payroll system, e-mail system, resource planning system, accounting system), hardware (eg servers, work- stations, routers), telecommunications systems and paperwork filing systems. The implementation team should list the key systems and their components throughout the organization. There are software tools that can be used to ensure that all the data assets and all the IT systems have been identified, and these are discussed later.

Telecommunications systems will include mobile phones as well as desk- based systems; smartphones are as important a component of the IT system

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 101

as are the remote access points and subcontracted services. Critical paper filing systems are as important as digital folders and drives. All the systems need to be identified, and if, in the process of doing this, there are found to be significant sharings of assets or information sharings that were not identi- fied earlier, then the scope of the ISMS may need to be revisited.

Individual items should be grouped by similarity of item type and expo- sure to risk. The sales teams laptops could, for instance, be treated as a single asset group: they all do the same thing, have the same value to the organization and are exposed to the same range of threats. Every asset has an owner, and for the risk assessment to be useful it is necessary to identify (by position, rather than name) the individual who owns – who is account- able for – each information asset.

Identify criticality: the relationships between assets and objectives

The key objectives (which may have business, contractual or legal aspects to them) should be identified in the organization’s business plan. Of course, if they are not, then this is a good opportunity for senior executives to identify and agree the key objectives of the organization and to map the tasks neces- sary to deliver them.

Objectives are often expressed as being to do with increasing market share, or increasing profitability, or increasing margin. These, however, are really the outcomes of pursuing operational objectives such as ‘sell more of product X to customer type Y’. There will be a hierarchy of objectives that reflects the value that the organization places on the outcomes that their achievement will deliver. There will also be a number of underlying objec- tives, which are really business requirements (the activities that are considered important for the ongoing effective operation of the organiza- tion). ‘Comply with the law’ is likely to be such an objective and will be common to most organizations.

Organizational business plan objectives should, like all objectives, be SMART (specific, measurable, achievable, realistic and time-bound). The key objectives should be clearly documented and this, or an excerpt from the business plan in which they are identified, should form part of the ISMS records.

Once the key objectives are clearly identified, then those systems that are most important to their delivery can also be identified. This is best done by the whole implementation team in a single session (which, depending on the size of the organization, may take one or more days) with lots of flipcharts. The starting point, after agreeing the scope of the planned ISMS, should be

IT GOVERNANCE102

to brainstorm a list of all the systems used within the business, whether digital or not. The team can then move on to review and understand the business objectives and then identify the relationships between systems and objectives.

The objective is to reach a conclusion that reflects all members’ experi- ence and knowledge; that identifies all the systems and in which all the business objectives have their critical system dependencies identified. It is possible that some objectives will have more than one system, and these interdependencies should also all be noted. Note that external consultants could only achieve this objective through a facilitated workshop or an extensive series of one-to-one interviews. It is important that the whole range of experience, perception and prejudice is involved in the process at this time, as otherwise it is likely that key dependencies may be missed or misconstrued.

It usually makes sense, in this same session, to move straight on to rank- ing the systems in order of critical priority – taking into account the business, contractual and legal requirements – to the business. This tends to be the best way to take full advantage of the momentum generated in the first session and ensures that the fullest possible analysis of the priorities is carried out. Meaningful ranking will depend, of course, on the effectiveness of the earlier analysis and ranking of business objectives.

The resulting report, a schedule that shows critical systems as dependen- cies of key organizational objectives, should be reviewed and agreed by the senior management team of the organization. It is critical that there is the fullest possible agreement on this, as this will be a key building block of the ISMS. The whole process set out above should be fully documented.

It is worthwhile, in tackling this (and the tasks below), to adopt an approach that is pragmatic, questioning and transparent. By this, we mean that the risk assessment should be done, and driven, by human beings – it is a subjective exercise in an environment where returns are derived from taking risks – and that it is preferable to be ‘approximately correct, rather than precisely wrong’. All individual inputs will reflect individual prejudice; the process of gathering input should question this input to establish what is known – and what unknown – in the individual assessment.

It is now possible to assess the impact on the organization of confidential- ity, integrity and availability for each of the identified assets. Broadly speaking, impacts will fall into one (or more) of three damage categories: damage to the organization’s business (its competitive position, its finances and its reputation), to its contractual commitments or to its legal responsi- bilities. The project team should identify the nature of each impact.

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 103

The next step is to assess the extent of the possible loss for each potential impact. One object of this exercise is to prioritize treatment (controls) and to do so in the context of the acceptable risk threshold; it therefore makes sense to categorize possible loss rather than attempt to calculate it precisely. The categories of business loss (for a large organization) might be:

None Losses are between nil and £10,000 Minor Losses would be above £10,000 but lower than £50,000 Medium Losses would be above £50,000 but lower than £100,000 High Losses would be above £100,000 but lower than £1 million Very high Losses would be above £1 million and lower than £10 million Extreme Disastrous – the financial viability of the organization is

threatened

The financial equivalents provided above should be adjusted, under the board’s guidance, to levels appropriate to the size of the organization and its current risk treatment (or enterprise risk management) framework. In assessing the potential costs, all identifiable costs – direct, indirect and consequential – including the costs of being out of business, should be taken into account. The ‘better to be approximately correct than precisely wrong’ approach should continue to be deployed in this exercise.

Identify potential threats and vulnerabilities (likelihood)

For each of the assets on the schedule, it is now necessary to identify the possible vulnerabilities and the potential threats to the key business systems. There are a high number of threats, and the range of possible vulnerabilities is also substantial. The input of the trained information security expert is, at this point, invaluable and the guidance of ISO27005, which includes lists of threats and vulnerabilities, can also save time. Threats tend to be external to the systems (but not necessarily to the organization). They include hostile outsiders such as hackers, non-hostile outsiders such as suppliers or cleaning contractors, and insiders, both the disaffected and the committed but care- less, or even just the poorly trained. Vulnerabilities are security weaknesses in the existing systems, weaknesses that can be exploited by threats, or that allow one or more of the confidentiality, integrity and availability of the asset to be compromised, accidentally or otherwise. A vulnerability can also simply be the absence of a control or a weakness in its implementation.

It is necessary to consider the links between threats and vulnerabilities. An example might be cleaning contractors who inadvertently pick up (a minor threat, being the unintentional error of a third party) the only copy of

IT GOVERNANCE104

an extremely confidential document off an executive’s desk (a minor vulner- ability, the forgetfulness of an executive) in the ordinary course of cleaning, and dispose of it. At this point, only the availability of the data has been affected, and the repercussions might be minor, as it might be possible – if embarrassing and time-consuming – to recreate the document. However, once an industrial espionage operative rummaging through the waste sacks of the organization finds the document and makes it available to the organ- ization’s competitors, the confidentiality of the information will have been compromised and the cost to the organization of the security breach starts increasing dramatically.

A telephone system that crashes, losing all stored voicemail, could have a significant impact on any organization that relies on voicemail for sharing critical information. Such an organization needs to have thought through how it will manage the security of these data.

Inevitably, the exercise to identify threats and vulnerabilities to the systems cannot be carried out without also identifying vulnerabilities in systems, and impacts on the organization, that are not necessarily threats to the availability, confidentiality or integrity of its information, but to which there is nevertheless a significant cost. An example is in digital telephone systems that enable direct-line users to access their voicemail externally and to redirect calls. The evident threat to data confidentiality is that unauthor- ized users could access information stored in voicemail. If voicemails can be deleted externally, then there is the threat that unauthorized users might make information unavailable. In addition, an unauthorized user could be able to use the organization’s telephone number to forward calls to his or her own number anywhere else in the world, or even to dial from the exten- sion to anywhere else in the world.

Essentially, threats for each of the systems should be considered under the headings of threats to confidentiality, to integrity and to availability. Some threats will fall under one heading only, others under more than one. It is important to have carried out this analysis systematically and comprehen- sively, to ensure that no threats are ignored or missed. The effectiveness of the controls that the organization eventually implements will reflect the quality of this particular exercise.

Many external threats will be classified under all three headings. A hacker might be able to steal confidential data and then disrupt the information system so that data are no longer available or, if they are, they are corrupted. A virus can affect not only the integrity and availability of data but also, because it could mail out a copy of an address book, confidentiality as well.

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 105

A business interruption, such as a fire in a data centre or a filing cabinet, is likely to affect the availability and integrity of information.

Similarly, what is likely to be a threat to one system is not necessarily a threat to another. For example, a fire in the server room is a threat to a number of systems based there, but is unlikely to be a threat to an organiza- tion’s mobile phone network.

The penultimate step is to assess the probability or likelihood of each impact occurring. The probabilities that might be used are:

Negligible Unlikely: less than once every five years Very low Likely to occur less frequently than once per year

but more frequently than once every five years Low Likely to occur more than once every year

but less than once every six months Medium Likely to occur more than once every six months but less than once every month High Likely to occur more than once every month

but less than once every week Very high Likely to occur more than once every week

but less than once every day Extreme Likely to occur at least daily

Create a risk matrix, using the scales you have created, that has likelihood along one axis and impact along the other. The risk acceptance criteria can be represented on the matrix by means of mapping then blocking out the levels of likelihood and impact that managers consider acceptable. For each threat–vulnerability combination, you can the plot the risk level onto this matrix by plotting the intersection of the likelihood and impact. Any risks that fall outside the organization’s risk acceptance criteria must be treated.

The final step in this exercise is to transfer the risk level assessment for each impact to the risk log. Although the examples we have used are based on five levels, we suggest that – particularly for smaller organizations – three levels of impact and likelihood are usually adequate: low, moderate and high. Where the likely impact is low and the probability is also low, then the risk level could be considered very low; where the impact is at least high and the probability is also at least high, then the risk level would be very high; anything between these two measures would be classed as moderate. However, every organization has to decide for itself what it wants to set as the thresholds for categorizing each potential impact.

IT GOVERNANCE106

Selection of controls and Statement of Applicability

The standard, at clause 6.1.3, requires the organization to select appropriate information security risk treatment options and then determine all the controls necessary to implement the selected treatment. ‘Organizations can design controls as required or identify them from any source.’ This does mean that the organization is at liberty to deploy any appropriate control set (typically driven by internal and external context and the requirements of interested parties). Appropriate control sets could include those from PCI DSS, NIST, COBIT, Cloud Security Alliance or, of course, ISO/IEC 27002 and the related ISO27000 family of standards. ISO 27017 and ISO 27018 tend to be particularly popular for those organizations operating in the cloud, and processing personally identifiable information in the cloud.

The selected controls are then compared with those listed in Annex A of ISO27001, and the organization produces a Statement of Applicability which identifies, with justifications for both inclusions and exclusions, which Annex A controls have been selected, and which additional controls have been selected. In addition, the SoA should identify which of the selected controls have actually been implemented. Annex A is, in this sense, a refer- ent control set, which enables organizations to ensure that they have not missed any relevant controls. This book proceeds on the basis that the Annex A/ISO27002 control set has been selected.

ISO27002 provides best practice guidance on the implementation and operation of the controls listed in Annex A. There may, however, be some areas in which organizations may need to go further than is described in ISO27002, and the extent to which this may be necessary is driven by the extent to which technology and threats evolve after ISO27002:2013 was published.

Controls are selected in the light of a control objective. A control objec- tive is a statement of an organization’s intent to control some part of its processes or assets and what it intends to achieve through application of the control. The selection of controls should be cost-effective, which means that the cost of their implementation (in cash and resource deployment) should not exceed the potential impact (assessed in line with our discussion above) of the risks (including safety, personal information, legal and regulatory obligations, image and reputation) they are designed to reduce.

It is important that, when considering controls, the likely security inci- dents that may need to be detected should be considered and planned for. In

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 107

effect, the process of selecting individual controls, whether from Annex A or elsewhere, should include consideration of what evidence will be required: 1) to demonstrate that the control has been implemented and is working effectively (the measuring of effectiveness is addressed at the end of this chapter); and 2) that each risk has thereby been reduced to an acceptable level. In other words, controls must be constructed in such a manner that any error, or failure during its execution, is capable of prompt detection and that planned corrective action, whether automated or manual, is effective in reducing to an acceptable level the risk of whatever may happen next.

Annex A of the standard has 14 categories, each of which has a number of subsections. There are, in total, 114 controls, each of which has a four- component alphanumeric control number. Each needs to be considered and a decision made as to whether or not it is applicable. As the controls are selected, the Statement of Applicability (SoA) can start to be drawn up. This SoA, specified in 6.1.3.d of the standard, is documentation of the decisions reached against the previous requirement and also an explanation or justifi- cation for the selection or non-selection of the controls that are listed in Annex A and whether or not the control has been implemented. This docu- ment needs to be reviewed on a regular basis and will be one of the first documents that the external auditor will want to see. It is also the document that is used to demonstrate to third parties the control framework that has been implemented, and is referred to, with its issue status, in the certificate of conformity issued by third-party accredited certification bodies.

The SoA could form the core of an ISMS manual or adopt the format set out below. The wording provided in the standard is repeated with appropri- ate variations to reflect the actual decisions made by the management steering group and its reasoning. The SoA can also refer to other documents, where these form the basis for any specific decisions recorded in it or which implement the decisions described. There are different ways of expressing the way in which different controls are applied, some of which are in the example below. The SoA should be signed by the owner of the ISMS (likely to be the CEO) for which it has been drawn up. This document is, for the external certification auditor, key evidence of the steps taken between risk assessment and implementation of appropriate controls.

The fact that someone reviewing an ISO27001 certificate might ask to see the SoA referred to should point at an appropriate level of classification; realistically, a standalone SoA that doesn’t contain any sensitive security information is a practical solution.

IT GOVERNANCE108

Statement of Applicability Example

Introduction

This is the SoA, as specified in clause 6.1.3.d to ISO/IEC 27001:2013 (‘the Standard’), for ABC Ltd. It was adopted by the Management Steering Group on [date] and will be reviewed in the light of significant information security incidents and at least annually. It reflects a risk assessment carried out on [date]. Controls are addressed in the same order and using the same number- ing as in Annex A of the Standard, and this statement explains which controls have been adopted and identifies those that have not been adopted and sets out the reasons for non adoption. All of the adopted controls have been implemented.

Statement of Applicability

A.5.1.1 Policies for Information Security ABC Ltd has adopted this control in order to meet business and contractual

requirements

A.6.1.2 Segregation of Duties ABC Ltd has adopted this control in order to meet regulatory requirements

A.6.2.2 Teleworking ABC Ltd has not adopted this control as it has no teleworking sites

As we indicated earlier, some thought needs to be given to the circulation of your SoA: it will be referenced on the certificate awarded following a successful audit to ISO27001, and so anyone who knows anything about ISO27001 certification will want to see a copy of the SoA as well as the certificate (and any other documents describing the scope, but this is normally stated on the certificate in its entirety). This suggests that the SoA will need to be a public document.

A catch could be that the complete SoA might include references to assets that the controls relate to and/or the ISMS documents that give life to the controls, and may have content in it that needs to be kept away from ‘public’ consumption. Those customers or other third parties who require sight of the SoA in order to establish the nature of the ISMS would therefore have to enter into a non-disclosure agreement before they could do so. This leads some organizations to produce two versions of their SoA, a limited version

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 109

for public consumption and a comprehensive version for internal or controlled use only.

For example, with the following SoA table (Table 6.1), the version containing the white columns could be made available publicly and access to the complete version that includes the shaded columns could be restricted. The ‘applied’ column provides for 3 options: yes and implemented; not selected.

TABLE 6.1 Statement of Applicability (SoA) table

Control Applied Y/YA/N JustificationReference Description

A.5.1.1 Infosec policies

Y Required by ISO 27001 with additional

policies required as a result of the information security risk assessment

– – – –

– – – –

This book will explore each of the controls listed under Annex A, looking to the good practice set out in ISO27002 for how best to implement them. The book will (mostly) tackle the controls in the order laid out in the standard; the organization should, however, tackle and implement controls in the order of priority identified through the baseline security criteria, the risk assessment and the risk treatment plan. The controls that are most critical for the organization will be those that relate to the threats and vulnerabili- ties that it has identified, through the risk assessment process, as being most serious to its most critical systems and/or information.

Gap analysis

As we said earlier, the reality is that most organizations that embark on ISO27001 already have a number of information security measures in place; ISO27001 necessitates ensuring that those controls that are in place are adequate and appropriate and that additional required controls are implemented as quickly as possible. In other words, an analysis of the gap between what is in place and what might be required might be carried out

IT GOVERNANCE110

could be a useful point of reference when carrying out the risk assessment; bear in mind, as well, our comments about the need for the management system as a whole to work to deliver the information security objectives.

The SoA will be complete once all the identified risks have been assessed and the applicability or otherwise of all the Annex A controls has been considered and documented. Usually, the SoA is started before any controls are implemented, and completed as the final control is put in place.

Risk assessment tools

There is a small number of software tools available that can, to a varying extent, automate the risk assessment process and generate the SoA. In theory, such a tool ought to encourage the user to perform a thorough and compre- hensive security audit on the organization’s information systems, and ought not to produce too much paperwork as a result. Tool availability is likely to change as the Standard is more widely taken up, and any organization inter- ested in pursuing this route should therefore do up-to-date research on what is available before making a shortlist. This book’s website contains informa- tion on available tools, including VS Risk™, from Vigilant Software Ltd.

The organization will need to compare tools before making a selection and should concentrate, in the comparison process, on the extent to which the tool really does easily and effectively automate the risk assessment and SoA development process; the amount of additional paperwork it generates; the flexibility it offers for dealing with changing circumstances and frequent, smaller-scale risk assessments; and the meaningfulness of the results it gener- ates. Of course, normal due diligence should also be done into the status of the supplier and manufacturer of the product to ensure that it is properly supported and likely to continue to be. References might also be sought from happy customers.

Risk assessments can, with difficulty, be done without using such tools. A thorough risk assessment, using a manually created spreadsheet for instance, for any significant business will be very time-consuming, and even more so if a software tool is not used. ‘Time-consuming’ means up to three months, or even longer for larger organizations. The use of a software tool will depend on the culture of the organization and the preferences of the infor- mation security adviser and manager. Practically speaking, once the organization has decided to purchase such a tool, it becomes dependent on that tool and on the staff members who are trained to use it. In considering

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 111

the appropriate route forward, consideration should be given to the speed with which incoming staff can become familiar with the chosen risk assess- ment tool; practicality and ease of use are likely to be key attributes.

If the organization decides to purchase such a tool, the steering group should document the reasons for its choice and selection; whoever is to use it will, of course, have to be appropriately trained in its use. Evidence of this training and level or proficiency achieved should be retained on the relevant HR file.

Risk treatment plan

Clause 6.1.3.e of the standard requires the organization to ‘formulate an information security risk treatment plan’; this should identify the appropri- ate management action, responsibilities and priorities for managing information security risks. Clearly, the risk treatment plan needs to be docu- mented. It should be set within the context of the organization’s information security policy and it should link clearly to the documents which set out the organization’s approach to risk and its criteria for accepting risk, as discussed earlier in this chapter. The risk assessment process must be formally defined, and responsibility for carrying it out, reviewing it and renewing it formally allocated. At the heart of the risk treatment plan is a detailed schedule that shows, for each identified risk, how the organization has decided to treat it, what controls are already in place (the baseline security controls), what additional controls are considered necessary, and the time-frame for imple- menting them. The gap to the acceptable risk threshold needs to be identified for each risk, as well as the risk treatment option that will bring the risk within an acceptable level.

ISO27001 imports the enterprise risk management concept of a Risk Owner into information security management. At 6.1.3.f, the Standard says that the Risk Owner must approve the risk treatment plan and accept any residual risk. The risk owner could be top management as a whole, or it could be an individual line or functional manager, as the organization considers appropriate. What matters is that the risk owner role is clearly allocated (and in line with clause 5.3), understood and effective, and that the risk owner’s formal approval for the RTP, and any residual risk (the risk left over after treatment) in respect of those risks for which they are responsible – is documented.

IT GOVERNANCE112

The Risk Treatment Plan may identify controls that are to be deployed in the future, whether for financial or operational reasons and, as long as the risk owner formally accepts the interim residual risk, this is a practical approach. It may also be that the treatment plan requires a series of actions at different times, with different priorities; a sensible RTP will define the timelines, responsibilities and dependencies.

The risk treatment plan links the risk assessment (expressed in the corpo- rate information asset and risk log) to the identification and design of appropriate controls, as described in the SoA, such that the board-defined approach to risk is implemented, tested and improved. This plan should also ensure that funding and resources for implementation of the selected controls are adequate, and should set out clearly what these are. The risk treatment plan should also identify and consider the individual competence and broader training and awareness requirements necessary for its execu- tion and continuous improvement.

We see the risk treatment plan as the key document that links all four phases of a Plan–Do–Check–Act (PDCA) cycle for the ISMS. It is a high- level, documented identification of who is responsible for delivering which risk management objectives, of how this is to be done, with what resources, and how this is to be assessed and improved; but at its core is the detailed schedule describing who is responsible for taking what action, in respect of each risk, to bring it within acceptable levels.

The risk treatment plan is a living document. As new risks are identified, old risks change, or improvement opportunities identified, the risk treat- ment plan needs to be updated. The organization needs, therefore, to have a managed process in place that ensures that revised (or new) risk assessments feed through to a revised risk treatment plan and that, where appropriate, changes are signed off by the risk owner.

Measures of effectiveness

ISO/IEC 27001:2013 requires, in clause 9.1, the organization to evaluate information security performance and the effectiveness of the ISMS. One aspect of this is to measure the effectiveness of controls (or groups of controls); controls are implemented to achieve a control objective, the control objectives are linked to the objectives for information security and, therefore, the effectiveness of each control contributes toward the overall effectiveness of the ISMS.

THE RISK ASSESSMENT AND STATEMENT OF APPLICABILITY 113

Measures of control effectiveness are ideally agreed during control selec- tion, but this can also be done later. In a sense, the structured decision process required by the risk assessment methodology, and the fact that controls are selected by objective, means that it is reasonable to deduce that if a prescribed control is fulfilling its objective (ie to reduce the predicted risk to the acceptable level) then it is being effective. In designing measures of effectiveness, there are three questions that must be answered:

●● What is the objective of each control?

●● How can you determine if the control is being effective?

●● What are the parameters that will give a positive or negative indication of control effectiveness?

ISO/IEC 27004 provides guidance on measuring control and information security management effectiveness.

Monitoring of measures of effectiveness can be particularly resource- intensive and so it is worth considering, at the point of selecting the controls, the basis on which the measures of effectiveness will be selected and moni- tored. A certification auditor would find it hard not to accept the selection of monitoring measures based on the largest risk areas, or in relation to those controls that have the biggest positive effect on reducing residual risk, and those should be reported to senior managers at the management review.

ISO27001 is an outcome-orientated management standard. It is a clear requirement of the standard (at clause 6.2) that the organization must moni- tor the performance of cti ISMS against its objectives; this is key demonstrating, to top management and interested parties, the effectiveness of the ISMS. All the principles of good performance management hold good when applied to information security and measuring the effectiveness of the ISMS and controls. In particular:

●● Over-reliance on negative reporting is likely to result in flawed measures.

●● Automated monitoring is preferable to manual arrangements.

●● The exact aspect being measured needs to be aligned with the main objective.

●● The integrity of the measures or statistics being produced is of paramount importance, as management decisions are likely to be based on this information.