It should be emphasized that security is an ongoing activity, which has to be an integral part of business planning, and not left to engineers only. At the heart of risk-management is human resources management. Technologically superior solutions will be in vain, if complementary organisational issues are not treated properly. Moreover, the majority of attacks have nothing to do with sophisticated kinds of technological attacks (Anderson, 1994), but fall into the domain of human resources management.
This is the basis for the second part of this chapter, which concentrates on organisational issues through human resources management to be properly embodied in security policy. Security policy is defined by documented procedures that are focused on the organisation's management of security—it is extremely important that this policy is backed by the management commitment. The basic standard in this area is BS 7799 (BSI, 1999), which recently became an international standard (ISO, 2000). This standard presents the main methodology that is followed by the growing number of organisations for establishing security policy.
BS 7799 consists of two parts. The first part describes a code of practice for information security management, while the second one specifies information security management systems. In the following, we will concentrate on code of practice to briefly state the main principles and activities. Of course, final implementation should closely follow the above-mentioned standard.
The scope of a code of practice is to give recommendations for information security management for use by those who are responsible for initiating, implementing or maintaining an organisation's security. It actually forms the basis, concentrated on organisational issues. Security policy activities start with a determination of an entity (information security manager, information security group) that is responsible for establishment, maintenance and review of security policy. Management of security policy is embodied in a security policy document. This document should start with the definition of information security, basic terms, its objectives and scope, brief explanations of principles, standards and compliance requirements, a definition of responsibilities for information security management and references to documentation that supports the policy.
The responsible entity identifies assets, classifies them and allocates responsibilities to members of an organisation. This requires the definition and documentation of security processes that are based on authorization procedures for every use of information processing facilities. Asset identification and classification should include:
data assets (databases, other files, system documentation, manuals, training material, operational procedures, continuity plans, archived information);
software assets (applications, operating systems, development tools);
physical assets (servers, clients, mainframes, terminals, notebooks, modems, routers, faxes, data media, cabling, printers, power supplies, air conditioning, furniture and accommodation).
Asset classification is achieved through labeling; labels reflect the importance of data in terms of confidentiality, integrity and availability. For each classification, handling procedures are defined that address the life cycle of related data, i.e., storage, copying, transmission (including spoken word) and destruction. All procedures should be documented and every change formally approved.
Although cryptography plays an important role in ensuring proper access and integrity of resources, it should be noted that cryptographic mechanisms only reduce the need for physical protection. Therefore, physical security has to be addressed carefully. It should address issues about clear desk policy, locking of sensitive information, prevention of unauthorized faxing, photocopying and clearance of sensitive data from printers. Appropriate secure areas have to be defined and physical entry controls put in place. This means supervision of visitors, recording of entry and departure, and issuing visitors with instructions. Visitors should also wear some form of visible identification. Securing offices, rooms and facilities should take into account all forms of natural and man-made disasters. Location of facilities should prevent public access; there should be reception areas and buildings which should give a minimum indication of their purpose. Equipment should be sited properly to avoid demand for access. Further, protected windows and slam shut doors should be considered, suitable intrusion detection systems and alarms should be installed, smart card based control throughout the building has to function. Finally, yet importantly, fallback equipment and back-up media should be stored at a safe distance. The same holds true for hazardous materials.
Special attention has to be paid to internal communications and operations, where certain groups of procedures might easily be overlooked. For example, operations related to administration and event logs are not paid sufficient attention, especially their storage, regular analysis and back-up. Further, media handling is underestimated. This may result in a paradox where high security measures are conducted within an organisation, but neglected when transporting back-up copies to a remote location.
Further, clock synchronization is frequently neglected, but it is the basis for effective analysis of logs, proper PKI operations and even essential for legal disputes. Further, common use of many electronic devices like faxes and mobile phones is assumed to present no danger, but it often happens that faxes are sent to wrong numbers, mobile phones are used for sensitive communication in public places, etc. Further, users manage their passwords without appropriate attention, they do not log off systems when they are not using them or they even leave equipment unattended. This is especially critical for equipment that is used off-premises. Management should authorize every such use and additional adequate insurance coverage for such equipment should be considered.
Further, operations related issues should include aspects of operational software: operating systems, applications, system files, and libraries. The modifications program for new installations and updates should be defined. Back-up copies of previous versions should be stored in a safe place, the same holds true for programs listings. Software patches have to be applied when necessary, which is almost obligatory in case of open source code products-whenever a security weakness is discovered, an attacker can analyze a patch and obtain unauthorized access to resources that are not updated.
With the introduction of networked and web-centric information systems, new requirements about security with regards to network access control appeared. Security policy should clearly define a use of network services that is based on user and node authentication, physical segregation of networks, enforced paths for services, filtering and limitation of connection time for high-risk applications.
When defining security policy, one should not overlook development environments. It should be a common practice that operational and development systems are separated, but this is often not the case. Development environments require a more relaxed atmosphere and they are therefore typically less protected. Access to data in this environment can be used for a breach into the operational system, e.g., testing is frequently done on extracted operational data, which can be easily exposed this way. Data input checks have to be put in place, together with control of internal processing to prevent abnormal behavior of applications. Output data validation is also needed. Even planning for appropriate capacity should be considered to prevent insufficient capacity that cannot support business requirements.
Although this chapter does not focus on legal issues, it should be noted that security policy has to take legal issues into account. A typical case are cryptographic controls, which are unavoidable in IS security. For selected cryptographic controls, the policy of their use has to be set and it should cover user roles, responsibilities and determination of the appropriate level of protection in line with information classification (algorithms, key lengths, protocols). Further, it should address appropriate standards with regard to key generation, distribution and activation, changing and updating keys, recovery of lost keys, certificates management, archiving keys for business and legislative needs, logging and auditing of key management. Appropriate procedures have to be defined for legislative reasons, i.e., accounting purposes or potential disputes, where cryptographically processed documents are used in a court as evidence. Procedures should also cover the problem of re-encrypting and resigning documents, when older technologies and keys of certain lengths become vulnerable to attacks. Nevertheless, before any security policy is formally approved in an organisation, a lawyer has to be consulted for legal advice. This advice should also include software licensing, support, assurance and licensing agreements.
The policy issues discussed so far have concentrated on issues related to internal members, but external, third party access, should be covered as well. According to the general threats prevention principle, this access is defined on the basis of identified risks. Afterwards, types of access are defined. For each type, reasons of access are given and appropriate measures are selected. Third party access should be based on formal contracts that include general security policy, description of services to be made available, acceptable levels of services and performance criteria. Further, contracts should declare liabilities and responsibilities with respect to legal matters, the right to audit contractual responsibilities, reporting and investigation of security incidents.
Security strongly depends on quality of systems. Therefore, to ensure appropriate quality of systems and services, it is advised that security policy considers ISO standards for quality assurance (ISO, 1995b). These standards generally address the problem of quality assurance through the definition of models for design, development, production, final inspection, installation, testing and servicing. For the specific subgroup that applies to IS see (ISO, 1997).
A security policy has to cover also business continuity, which is an extremely important issue that includes incident management procedures, which have to be defined together with fallback procedures and recovery steps. Further, each security policy has to be reviewed independently, be it internally or by a preferred external specialized organisation.
Finally, the basis of security is an informed, educated, satisfied and loyal employee. This implies the importance of user training that enables employees to become familiar with security policies, reporting incidents, malfunctioning and even detection of security weaknesses. Such employees enable the main objectives of security policies to be fulfilled, which are minimization of human error risk, misuse, fraud and theft.
To conclude this section, a security policy life cycle diagram is given (see Figure 2). The diagram can serve as a roadmap, related to the main stages of security policy activities and their sequence.
Figure 2: Managing Security Policy.