In this chapter we shall:
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:
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.
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:
The following table sets out key risk factors for logical security in not-for-profit organisations, which you can use to help you.
| 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) |
| 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)? |
| 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? |
| 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)? |
| 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? |
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:
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.
| 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 |
Your organisation's security policy should cover the following elements:
An example policy documents is below
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:
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 ____________________________________
Date_______________________________________
This policy should be reviewed by the information security manager no later than
___________________________ (e.g. one year after initial date)
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:
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.
Part 3 BS7799 supplies a list of ten topics and subtopics containing over 100 controls from which an organisation can select. These are:
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.
| 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 |
| 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 |
| 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) |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
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.
| 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 |