Information Security Policy in Large Public Organizations: A Case Study Through ISO 27002

Introduction

Information Systems (IS) are today an integral part of the functioning of public administrations and bodies, the activity of businesses and the way of life of citizens. The security of these information systems has become a major issue for all public or private sectors, which would be very strongly affected in the event of serious malfunctions (T. R Peltier, 2016).

Information security policy is the general term used to describe any document that transmits an element of the security program in order to ensure compliance with the organization's security goals and objectives. Since this definition covers a wide range of security policy documents, it is useful to describe the various types of information security policies that an organization may use. The terms used below to describe these types of information security policies are generally used in the information security industry and will be used consistently throughout this chapter (Ifinedo, 2014). However, it is not unusual for a government organization or agency to have different names for the same types of information security policies. For example, in many organizations and certainly in government departments, the word “policy” is closely associated with laws and regulations (Rees, Bandyopadhyay, & Spafford, 2003). In these cases, a limited number of individuals (e.g., the legislature) have the power to create a policy, so that an information security policy is generally referred to by other names such as “information security statement”, or “information security document” or other terms avoiding the use of the word “policy”. The term used by an organization to describe these documents is irrelevant. The overall organization and completeness of these documents are important (Hong, Chi, Chao, & Tang, 2006).

The security policy is primarily implemented as a means of communication with system users and administrators, issues that must be taken into account when security decisions are made. It defines the explicit expectations and responsibilities of users and administrators, and allows both groups to know what to expect from each other (K. Knapp, Morris, E. Marshall, & Byrd, 2009). It should explain why certain decisions have been made and why they are important, to help all users understand how the policy is designed to benefit them (Flowerday & Tuyikeze, 2016).

The security policy should specifically state the types of data that are considered important enough to warrant protection. This would include user’s personal files in the form of programs, text documents like a thesis or an email message, as well as system-specific configuration files (Yassine, Maleh; Abdelkebir, Sahid; Abdellah, 2017). This helps to allow users to better understand why security measures are in place, and why certain insecure services have been restricted.

A password policy is already in place, however it should most definitely be mentioned in the security policy. This is one of many things the user could do to help keep the system secure, but is probably one of the most important. Other ways that a user could contribute to system security would be properly managing their file and directory permissions or using other software that was designed with the security conscious person in mind (K. Knapp et al., 2009).

Should a security incident occur, the security policy should state who is responsible for restoring the system to a secure state, as well as any procedures that should be followed throughout the course of the repair. If the person in charge of system security detects a break in, who should be notified and what should be done with the compromised machine? Issues like these must be addressed in order to ensure that firstly any disrupted services are restored in a timely manner and secondly so that proof of the incident can be obtained should the legal need arise (Maleh, 2018). The source of the security breach should be determined and fixed so the incident doesn't repeat itself and once the problem has been properly documented, the system administration team should be made aware of what happened.