Chapter 10: Information Security

Chapter objectives

In this chapter we shall:

  • Cover the logical security aspects of information security.
  • Explain an holistic model of information security, BS7799, which also encompasses aspects covered in the previous chapter.
  • Outline how the information security management standard can help support your work to ensure that your systems are as secure as possible.

Logical security

Although the risks anticipated in chapter 9 are probably the most severe and likely risks for most not-for-profit organisations, as soon as an organisation connects several computers together or enables access from the outside, it needs to consider logical security. Logical security is a system of controls and procedures to minimise the risk of an unauthorised person accessing a particular system or data. While physical security might reduce the risk of unauthorised access somewhat, it does not eliminate it. For example, one of your fundraisers might have physical access to the same work space as your payroll clerk, but you can prevent the fundraiser from accessing the payroll through logical security (e.g. password protection on the payroll program and encryption of the payroll data). Logical security is the intangible security which supplements your physical security.

As more and more organisations are "wired" to the outside world for e-mail, use of the world-wide-web etc., the risk of unauthorised access through hacking from a remote location increases. This makes physical security decreasingly important and logical security increasingly important.

Logical security can be provided to any or all of the following aspects of your IT:

  • hardware
  • operating system
  • application system
  • data

It is important that you know at the time you set up your security what you want to protect, why, and how the applications and data are held. This is an area where it often really is beneficial to get some expert advice if you are at all unsure. Further, you need to adopt the sneaky mind of an IT hacker to make sure that you really are securing the data. The case below illustrates this point.

Case Example: How did they break in to our payroll?

A large not-for-profit organisation client discovered that some disaffected staff had somehow managed to find out several senior managers' salaries. Investigation of manual procedures and interviews with confidential staff led the investigators to believe that the most likely cause was unauthorised access to the payroll data. But how? To access the payroll system, you needed to use two levels of password, which only a handful of confidential staff knew.

However, that particular payroll system had what is sometimes called a back door. The payroll system stored data in an unencrypted form on a network drive. We quickly ascertained that the network drive was not logically protected and that any user could theoretically go to that drive and examine the payroll data files. This seemed the most likely source of security breach.

The theory was soon proved, when the local drive of one of the disaffected staff member's was found to contain a copy of a payroll data file and some other files which showed that this person had been extracting information from those files and working out which fields related to peoples salaries.

The client's comment on this matter, "I thought we were secure. It wouldn't even have occurred to me to try to break into a system that way".

The moral of this case study is to either ensure that:

  • sensitive systems you are procuring protect the data at the same time as they protect the application system (e.g. through encryption or binding the files together), or;
  • apply additional layers of logical security (e.g. password protected network data drives) to minimise the risk of unauthorised access to data relating to application systems which do not provide sufficient protection in themselves.

The following table sets out key risk factors for logical security in not-for-profit organisations, which you can use to help you.

Table 10.1.1 Logical Security Checklist - What you are securing
Risk area Assessment, impact and mitigation Severity Likelihood
Do you have up to date inventory of all of your computer systems?
Do you have up to date records on the access controls used for each aspect of each system?
Have you identified clear responsibilities for administering security for each system?
Have you identified specific risk factors for specific systems (e.g. fraud risk for payroll, poaching risk for fundraising data)
Table 10.1.2 Logical Security Checklist - Logical hardware security
Risk area Assessment, impact and mitigation Severity Likelihood
Do you enforce power-on passwords for computers?
Do you employ additional hardware access controls where appropriate (e.g. swipe cards, dongles, BACS code generating devices)?
Table 10.1.3 Logical Security Checklist - Logical operating system security
Risk area Assessment, impact and mitigation Severity Likelihood
Do all users on all operating systems have individual IDs??
Do all users on all operating systems have passwords?
Do you enforce periodic password changes upon all users?
Do you have procedures in place for reporting joiner and leaver information to all system administrators?
Do all your operating systems log user activity?
Do all your operating systems detect and report on irregularities (e.g. failed attempts to access)?
Do you periodically review logs of irregularities?
Table 10.1.4 Logical Security Checklist - Logical application security
Risk area Assessment, impact and mitigation Severity Likelihood
Do all users on all applications have individual IDs??
Do all users on all applications have passwords?
Do you enforce periodic password changes upon all users?
Do you have procedures in place for reporting joiner and leaver information to all system administrators?
Do all your applications log user activity down to function level (e.g. which user accessed which routines)
Do all your applications have appropriate logical access levels (e.g. read only access, process invoices but not payments etc.)
Do all your applications detect and report on irregularities (e.g. failed attempts to access)?
Do you periodically review logs of irregularities?
Do all your applications produce audit trail time and date stamped down to transaction level ((e.g. recording which user made which change on which transaction)?
Table 10.1.5 Logical Security Checklist - Logical data security
Risk area Assessment, impact and mitigation Severity Likelihood
Do you apply additional logical access controls to drives holding sensitive data?
Have you closed any known "back doors" into application data?
Is highly sensitive data encrypted whenever stored?
Is sensitive data encrypted whenever it is transmitted (e.g. through a WAN or through the World-Wide-Web?

Holistic information security management and BS7799

This chapter, together with the preceding chapter, should provide most not-for-profit organisations with enough material to manage a secure and safe IT structure. But how do you pull it all together? How can you be assured that everything is under control.

There is an holistic standard for information security management, BS7799, which can be a useful way ensuring that you have covered all your security needs. You can use external assessors to certify you, which can provide you with some external assurance. BS7799 is not a legal requirement for you, but regulations which are binding upon you (e.g. the Data Protection Act, see chapter 11) cite BS7799 as an example of best practice to ensure the security of your data. While smaller not-for-profit organisations probably don't need external certification under BS7799, the principles contained in the standard can be helpful in managing your information security.

BS7799 has two parts:

  • Part 1, published in 1995, is a code of practice containing guidance materials to help organisations to implement their own information security systems.
  • Part 2, published in 1998, in a specification document against which an organisation can be measured for compliance and certification. It has three sections:
  • Section 1 sets out the standards purpose and definitions · Section 2 explains the documentation required and risk assessment approach to be used · Section 3 lists ten topics containing over 100 controls from which an organisation can make a selection

One of the key elements of the holistic model is for an organisation to set its own policy and scope of information security management, making your IT security environment "fit for your purpose". BS7799 describes this environment the management framework. The following table (10.2) summarises the six steps the standard requires for establishing an information security management framework.

Table 10.2 Information Security Management Framework
Step No. Step description Tasks Outputs
1 define policy define and document policy
allocate responsibilities
information security policy document
2 scope the information security management system define the scope in terms of: organisation, location(s), assets, technology information security management system scoping document
3 risk assessment risk assessment for each information system included in scope: identify assets, identify threats, assess vulnerabilities, assess impacts risk management documentation (see checklists in chapter 9 and this chapter)
4 manage the risk determine areas and degrees of risk to be managed risk management documentation (see chapter 9 and this chapter)
5 select controls select control objectives and controls to be implemented
justify the selection with the results of the risk assessment
mapping risk management documentation with list of BS7799 control objectives and controls
6 statement of applicability prepare a statement of applicability document containing list of controls, selections and justifications

Security policy

Your organisation's security policy should cover the following elements:

  • Objective of information security in your organisation.
  • Statements of policy.
  • Outline of responsibilities.
  • Statement of authority and support.

An example policy documents is below

Information Security Policy Document


The objective of information security in this organisation is to ensure the confidentiality and integrity of our information and to ensure business continuity by preventing and minimising the impact of adverse security events


The organisation aims to protect all of its information assets from all threats, internal or external, accidental or deliberate

This information security policy has been approved by the organisation's Chief Executive

The organisation seeks to ensure that it:

  • makes information and information systems appropriately available to users;
  • protects information from unauthorised access;
  • assures confidentiality of information;
  • perpetuates integrity of information;
  • meets its legal and regulatory requirements;
  • has appropriate business continuity plans;
  • investigates any breaches of information security;
  • trains all staff and relevant volunteers to an appropriate level in information security.

The organisation has developed and will maintain appropriate procedures to support this policy.


The information security manager has direct responsibility for managing this policy and for overseeing its implementation

All managers are responsible for the implementation of this policy within their area of work and for overseeing adherence by the staff and relevant volunteers in their area of work

Every member of staff and every relevant volunteer should take personal responsibility for their adherence to this policy

Signed by the Chief Executive ____________________________________


This policy should be reviewed by the information security manager no later than

___________________________ (e.g. one year after initial date)

Information security management system scope

Defining the scope of your information security management system is key. This aspect can be comparatively tricky in not-for-profit organisations, especially when the organisation has general issues regarding the scope of its control. For example, if you are a federated or confederated organisation, you might only have limited ability to control information security in the outer lying reaches of your organisation. Indeed, you might need to exclude some aspects of your organisation from the scope of your information security system. Bear in mind, however, that you should be extremely careful about sharing sensitive information assets (e.g. names and addresses of young people in trouble or danger) with parts of your extended organisation that you cannot control and which perhaps do not protect information to your standards.

There are four key aspects of scope to consider and document:

  • Organisation - as discussed in the above paragraph. Also, you should consider where responsibilities sit within your organisation.
  • Location(s) - consider which sites are covered and their differing needs. For example, the information security requirements will be significantly greater at headquarters than at a small project with one computer and a modem link to headquarters.
  • Assets - consider which information assets should be included. An information asset can be any valuable element of your information system, and can include paper documents, software, data files, computers, communications equipment, data media, physical files, safes, intangibles such as intellectual property, human resources.
  • Technology - consider the various types of technology involved, including computers, communications systems and other relevant equipment.

In a larger organisation, it is usually helpful to use the scoping document (see step 2, Table 10.2) as an opportunity to segment the organisation into "security domains" for management purposes. In any event, you should ensure that the document clarifies security responsibilities throughout the scope.

Control requirements

Part 3 BS7799 supplies a list of ten topics and subtopics containing over 100 controls from which an organisation can select. These are:

  • information security policy
  • security organisation
  • assets classification and control
  • personnel security
  • physical and environmental security
  • computer and network management
  • system access control
  • systems development and maintenance
  • business continuity planning
  • compliance.

The following table sets out the topics, objectives and subtopics for controls. Within each of the subtopics there are one or more controls suggested in the standard.

Table 10.3.1 Control Requirements - Information Security Policy
Control topics / subtopics Objective Comments and examples
Policy document to provide management direction and support for information security see section Security policy above
Review and evaluation to ensure that the policy remains appropriate see section Security policy above
Table 10.3.2 Control Requirements - Security Organisation
Control topics / subtopics Objective Comments and examples
Information security infrastructure to manage information security within the organisation see section Security policy above
Security of third party access to maintain the security of organisational information processing facilities and information assets accessed by third parties where third parties have access to some of your information and/or systems, the arrangements should be formalised in contract between the parties
Outsourcing to maintain the security of information when the responsibility for information processing has been outsourced to another organisation your organisation's security requirements should be addressed in the outsourcing contract if you are outsourcing all or part if your IT management
Table 10.3.3 Control Requirements - Asset Classification and Control
Control topics / subtopics Objective Comments and examples
Accountability for assets to maintain appropriate protection of the organisation's assets each asset should have a clear, nominated owner
you should have an inventory of assets (see chapter Avoiding and Preparing For the Worst et seq. above)
Information classification to ensure that information assets receive an appropriate level of protection establish appropriate classification of information
information should be labelled (so you know which part of the classification it falls into)
Table 10.3.4 Control Requirements - Personnel Security
Control topics / subtopics Objective Comments and examples
Security in job definition and resourcing to reduce the risks of human error, theft, fraud or misuse of facilities screening procedures, confidentiality agreements, terms and conditions
these aspects should apply to relevant volunteers as well as paid staff
User training to ensure that users are aware of threats and concerns and that users are equipped to support the security policy in the course of their work remember to include relevant volunteers as well as staff when considering this type of user training
Responding to incidents and malfunctions to minimise damage from security incidents and malfunctions, to monitor incidents and to learn from them have clear procedures for reporting incidents
Table 10.3.5 Control Requirements - Physical and environmental security
Control topic / subtopics Objective Comments and examples
Secure areas to prevent unauthorised access, damage and interference to premises and information see section Physical security above
Equipment security to prevent loss, damage or compromise of assets and interruption to work see section Physical security above
General controls to prevent compromise or theft of information and information processing facilities e.g. clear desk policy, clear screen policy
Table 10.3.6 Control Requirements - Communications and operations management
Control topic / subtopic Objective Comments and examples
Operational procedures and responsibilities to ensure the correct and secure operation of information processing clear responsibilities and procedures for the IT operation in your organisation
System planning and acceptance to minimise the risk of systems failure in particular, pay attention to capacity planning if your not-for-profit organisation is growing fast or has bursts of activity
Protection from malicious software to safeguard the integrity of software and information avoiding viruses, worms, Trojan horses, logic bombs etc. (see section Virus protection above)
Housekeeping to maintain the integrity and availability of information processing and communication services see section Backing up et seq. above
Network management to ensure that information in networks is safeguarded and that supporting infrastructure is protected you need to be especially careful if your network interfaces with other organisations' networks
Media handling and security to prevent damage to assets and interruptions to activities these controls are about data media (disks, tapes etc.), not about being hounded by the newspapers
Exchanges of information and software to prevent loss, modification or misuse of information exchanged between organisations you should have agreements, procedures and standards in place for sharing information with other organisations
this is pertinent for many care organisations who share sensitive information e.g. with statutory authorities
Table 10.3.7 Control Requirements - Access Control
Control topic / subtopic Objective Comments and examples
Business requirement for system access to control access to information you should have policies on information dissemination and the authorisation of access to information
User access management to prevent unauthorised access to information systems you should have procedures and clear responsibilities for controlling the allocation of access rights
User responsibilities to prevent unauthorised user access make sure that users are aware of their responsibilities with regard to access controls
Network access control protection of networks control interfaces between your organisation's networks and other organisation's networks and/or public networks
Operating system access control to prevent unauthorised computer access it should be possible to identify and verify the identity of users, record system accesses (including failed attempts), provide authentication controls (e.g. passwords) and restrict connection times where appropriate
Application access control to prevent unauthorised access to information held in information systems each system should have access control policies
sensitive systems should be isolated from other systems
Monitoring system access and use to detect unauthorised activities e.g. event logging and usage monitoring
Mobile computing and teleworking to ensure information security when using mobile computing and teleworking facilities needs are likely to be location and/or function dependant
Table 10.3.8 Control Requirements - Systems Development and Maintenance
Control topic / subtopic Objective Comments and examples
Security requirements of systems to ensure security is built into information systems in particular, make sure that you include control requirements in system requirements specifications
Security in application systems to prevent loss, modification or misuse of user data in application systems validation of input, control of processing, authentication of messaging and validation of output
Cryptographic controls to protect the confidentiality, authenticity or integrity of information e.g. encryption, digital signatures, cryptographic keys, non-repudiation services
Security of system files to ensure that IT projects and support activities are conducted in a secure manner especially important during system implementations and/or upgrades
Security in development and support processes to maintain the security of application system software and information needed especially in organisations which undertake software developments
Table 10.3.9 Control Requirements - Business Continuity Management
Control topic / subtopic Objective Comments and examples
Aspects of business continuity management to counteract interruptions to activities and protect critical processes from the impact of major failures or disasters see section IT business continuity above
Table 10.3.10 Control Requirements - Compliance
Control topic / subtopic Objective Comments and examples
Compliance with legal requirements to avoid breaches of any criminal law, civil law, statutory obligations, regulatory requirements, contractual obligations or security requirements identify applicable "rules"
respect intellectual property rights
consider requirements in other countries if your organisation transmits data overseas
Review of security policy and technical compliance to ensure compliance of systems with organisational security policies and standards unrecognised failure to comply is a common risk
System audit considerations to maximise the effectiveness of and minimise interference to/from the system audit process controls to safeguard the audit process itself
seek to minimise the disruption to the organisation

Statement of applicability

Once you have done your risk assessment and decided how to manage your organisation's risks, you should be able to go through the list of controls in BS7799 Part 2 Section 3 and decide which are applicable to you, which aren't and why.  The output of that exercise is the statement of applicability.  An example extract is shown below.

Table 10.4 Extract From A Statement of Applicability
Control Selected Justification
establish agreements for electronic or manual exchange of information between organisations yes highlighted in risk assessment as high severity, high likelihood, as our organisation needs to exchange highly sensitive childcare data with statutory authorities. Currently done manually but plans for some electronic links
protection for media being transported yes currently done through secure couriers. Planned electronic links will mostly be logical (e.g. encrypted e-mail) but some might be physical (e.g. encrypted files on disks)
electronic commerce protection yes increasing amounts of procurement done electronically
policy for use of electronic mail yes see "Electronic Mail Usage Policy, ref XX/YY
policies and guidelines for use of electronic office systems yes see our "Office Users Guide", ref ZZ/WW
formal authentication process before information is made publicly available no organisation is so sensitive we don't make information publicly available
procedures and controls for information exchange through voice, facsimile, video communications etc. yes voice mail and facsimile used heavily, see "Office Users Guide", ref ZZ/WW
no imminent plans for video communications


  • Logical security protects your intangible information assets (e.g. your data).
  • An holistic information security management system, BS7799, can help you to pull all of your information security needs together, even if you choose not to opt for external assessment.
  • Key to information security management is your organisation defining its own policies and scope of security need before assessing risks and deciding what controls to put in place.
  • Not-for-profit organisations large and small are obliged to address these issues - it should be possible for you to scale what you do about them accordingly.
svg.lf_footer_svg{ height: 30px; width: 30px; }