1 Introduction

This procedure describes the steps to be taken when a nonconformity is found within the Information Security Management System (ISMS). A nonconformity is defined by ISO as the “non-fulfillment of a requirement”.
This is a wide definition which basically means that the ISMS is not succeeding in its purpose, which is to fulfil the information security requirements of the organization. A nonconformity may arise for many reasons, in many forms and from many different sources. The purpose of this procedure is to ensure that they are recorded when they are identified and that the appropriate steps are taken to ensure that the immediate and wider actual and potential impacts of the nonconformity are addressed.
In addition to internal and external audits, non conformity may be identified from the day- to-day performance of procedures, management meetings and communication with suppliers, customers and other interested parties.

2 Nonconformity Management Procedure

2.1 Procedure Diagram

The procedure for identifying and managing non conformity is summarized in the diagram below. The detail of the steps is described in the following sections.

2.2 Identifying Nonconformities

Nonconformities may be identified from any source and the [Information Security Manager] will encourage staff, users, customers and suppliers to propose ways in which they can be addressed. Such nonconformities may be identified from:

• Security reviews
• Team meetings
• Supplier meetings
• Risk assessments
• User surveys
• Internal and external audits

However, the above is not an exhaustive list.

2.3 Add to Nonconformity and Corrective Action Log

Once identified, the nonconformity will be documented within the Nonconformity and Corrective Action Log with a status of “Open”. At this stage, the action to correct the nonconformity has not necessarily been determined. As much detail as possible should be specified as to the exact nature of the nonconformity.

2.4 React to the Nonconformity

If action needs to be taken to address the nonconformity immediately then this should be done without delay. This may be to fix it, stop it from getting worse or to reduce its effects until further action may be taken. Appropriate resources should be allocated to addressing the nonconformity depending on the current assessment of its seriousness. Actions taken should be recorded in the action log, with dates.

2.5 Cause determination

Once logged and initial reactive actions put in place, the nonconformity will be evaluated to assess its underlying cause i.e. why it has arisen. Other parties may be consulted during this stage to understand the mechanism and events leading to the nonconformity. The identified cause should be recorded in the action log with as much description as appropriate.

2.6 Assess potential impact

Once the cause is understood, a review should be undertaken to assess whether similar nonconformities already exist elsewhere within the ISMS and whether they could potentially arise in the future. The findings of this review should be recorded in the action log.

2.7 Implement corrective action

Once the cause and real or potential impact has been established, appropriate corrective action should be identified to address both the current situation and potential future impact of the nonconformity. The expected benefits of correcting the nonconformity should be sufficient to justify the resources required to achieve the corrective action. The details of the corrective action to be taken should be recorded in the action log, along with the timescale and person responsible. Dated progress updates should also be added when appropriate. Once corrective action has been completed the status of the nonconformity record within the Nonconformity and Corrective Action Log should be updated to “Review Pending” and the date of closure recorded.

2.8 Review effectiveness of corrective action

After a reasonable period of time (which will depend on the nature of the nonconformity and the corrective action) the effectiveness of the corrective action should be reviewed to assess whether it has fixed the issue, including its actual and potential impacts. If the benefits expected are not achieved, the reasons for this will be investigated as part of the regular management review meeting. If successful, the date and results of the review will be recorded, and the status of the nonconformity will be updated to “Closed”.

2.9 Amend ISMS if necessary

If the nonconformity is judged to have occurred due to a fault in the ISMS, it may be necessary to amend the ISMS itself, including any relevant policies, procedures and forms. This should be done with the agreement of top management.

1 Introduction

“Documented information” is defined by ISO as “information required to be controlled and maintained by an organization and the medium on which it is contained”. This term covers what used to be referred to as “documents and records” and for reasons of clarity this procedure still draws a distinction between these two types of documented information. The use of documented information is an essential part of the Information Security Management System (ISMS) in order to set out management intention, provide clear guidance about how things should be done and provide evidence of activities that have been performed. The ISO/IEC 27001 standard requires that all documented information that makes up the ISMS must be controlled to ensure that it is available and suitable for use, where and when needed, and is adequately protected. Such control is essential in order to ensure that the correct processes and procedures are in use at all times within the organization and that they remain appropriate for the purpose for which they were created. The general principles set out in the standard and adopted within this procedure are that all documented information must be:
➤ Readily identifiable and available
➤ Dated, and authorised by a designated person
➤ Legible
➤ Maintained under version control and available to all people and locations where relevant activities are performed
➤ Promptly withdrawn when obsolete and retained where required for legal or knowledge preservation purposes
This procedure sets out how this level of control will be achieved within XXX.

2 Document Control Procedure

This procedure applies to “documents” (as opposed to “records” which are covered later) which are generally created via a word processor (or similar office application) and describe management intention such as policies, plans and procedures.

2.1 Overview
The overall process of control for documents is shown in the diagram below.

Each of these steps is described in more detail in the remaining sections of this procedure.

2.2 Creation of Documents
The creation of documents will be at the request of the XXX management team and may be done by any competent individual appropriate to the subject and level of the document. However, there are a number of rules that must be followed when creating a document to be used in the ISMS.

2.2.1 Naming Convention
The convention for the naming of documents within the ISMS is to use the following format:

ISMS-DOC-xx-yy Document Title Vn Status dd

where:

• ISMS = Information Security Management System
• DOC = Document
• XX = Dept
• yy = Unique document number
• Document Title = Meaningful description of document
• Vn= Version n
• Status = Status of document (Draft or Final)
• dd = Number of draft, if appropriate

2.2.2 Version control

A unique number will be allocated for each document and an index of document references maintained within the ISMS Quality System.

Document version numbers will consist of a major number only e.g. V2 is Version 2.
When a document is created for the first time it will have a version number of 1 and be in a status of Draft. Each time a draft is distributed, any further changes will result in the draft number being incremented by 1 e.g. from 1 to 2.
For example, when a document is first created it will be Version 1 Draft 1. A second draft will be V1 Draft 2 etc. When the document is approved it will become V1 Final.
The version number will be incremented when a subsequent version is created in draft status.
For example, a revision of an approved document which is at V1 Final will be V2 Draft 1 then V2 Draft 2 etc. until approved when it will become V2 Final.
Documents must include a revision history as follows:

Version	Date	Revision	Author	Summery of change

Once the document reaches its final version, only approved versions should be recorded in this table.

2.2.3 Document Status
The status reflects the stage that the document is at, as follows:
Draft = Under development and discussion i.e. it has not been approved
Final =Following approval and release into live work environment

2.2.4 Documents of External Origin
Documents that originate outside of the organization, but form part of the ISMS will be allocated a reference and a header page attached at the front of the document, setting out information that is normally included in internal documents i.e.:

• Document reference
• Version
• Date
• Status
• Distribution

Such documents will then be subject to the same controls as those that originate internally.

2.3 Document Review

Draft documents will be reviewed by a level and number of staff appropriate to the document content and subject.
Guidelines are as follows:

Document Type	Reviewer
Strategy
Policy
Procedure
plan

Once approved, the date of next scheduled review should be recorded in the Information Security Management System Documentation Log.

2.4 Document Approval

All documents must go through an approval board to ensure that they are correct, fit for purpose and produced within local document control guidelines. The board will differ dependent upon the type of document and may go to numerous groups prior to being approved. In standard terms, approval boards are:

Document Type	Approver
Strategy
Policy
Procedure
plan

Each document that requires approval should have a table for the purpose as shown below:

Approval

Name	Position	Signature	Date

Once approved a copy of the document must be printed and signed by the approver. [Note – you may choose to do this electronically rather than by printing a copy]. This copy will then be retained in a central file
Upon approval of a new version of a document, all holders of previous versions will be instructed to obtain a new version and destroy the old one.

2.5 Communication and Distribution

A distribution list will be included as follows:
Distribution

Name	Title

This list must be accurate as it will be used as the basis for informing users of the document that a new version is now available.

2.6 Review and Maintenance of Documents

All final documents must be stored electronically and in paper format both locally and off-site to ensure that they are accessible in any given situation.
ISMS documents are stored electronically on the shared drive under the relevant sub-folder (e.g. Management responsibility, Management review etc.). The drive is a shared drive to which all appropriate members of XXX have access, in line with the published Access Control Policy.
Final documents are stored in paper format in a filing structure that mimics the electronic version. [State the location of the paper files].
A full copy of final documentation will be reproduced and stored within the Definitive Media Library.

2.7 Archival of Documents

Approved documents exceeding their useful life are stored in a Superseded Folder on the shared drive in order to form an audit trail of document development and usage. They should be marked as being superseded in order to prevent them being used as a latest version by mistake.

2.8 Disposal of Documents

Paper copies of approved documents that have been superseded are to be disposed of in secure bins or shredded, in line with agreed Asset Handling Procedures.

3 Records Lifecycle

This section describes the control of the type of documented information that generally shows what has been done i.e. is a “record” of activity, such as a completed form, security log or meeting minutes.

3.1 Identification

There is a variety of types of record that may form part of the ISMS and these will be associated with the specific processes that are involved, such as:

• Security incidents
• Change requests
• Configuration items
• Security event logs

In addition, there will be more general items such as meeting minutes which could apply across processes. In terms of identification, in many cases this will be dictated by the tool creating the record, for example a unique numbering system such as INC000001 for security incidents or CHG000001 for changes will be used by the tool.

3.2 Storage

Many records within the ISMS will be stored in application databases specifically created for the purpose e.g. the security incident database. For non-database records, a logical filing structure will be created according to the area of the ISMS involved. Where possible, all records will be held electronically; paper documents should be scanned in if an original electronic copy is not available.

3.3 Protection

Records held in application databases will be subject to regular backups in line with the agreed backup policy. File storage areas will also be backed up regularly, with all latest backups held at an offsite location. Access to the records will be restricted to authorised individuals in accordance with the XXX’s Access Control Policy.

3.4 Retrieval

Records will generally be retrieved via the application that created them e.g. the service desk system for security incidents and an event viewer for logs. Reporting tools will also be used to process and consolidate data into meaningful information.

3.5 Retention

The period of retention of records within the ISMS will depend upon their usefulness to XXX and any legal, regulatory or contractual constraints. Security- related service desk records are useful for historical trend analysis and so will be kept for a period of at least 7 years. Particular care will be taken where records may have some commercial relevance in the event of a dispute e.g. contracts and minutes of meetings with suppliers and these should be kept for the same length of time. Records that are particularly detailed and only relevant for a short period of time such as server event logs should only be kept as long as there is an immediate requirement for them. Specific retention periods are set out in the Records Retention and Protection Policy.

3.6 Disposal

Many systems provide for the concept of archiving and in most cases, this should be used rather than deletion. However, once it has been decided to dispose of a set of records they should be deleted using the appropriate software e.g. the service desk system will provide a facility to delete security incident records. If such records are held on hardware that is also to be disposed of then all hard disks must be shredded by an approved contractor.Paper copies of records that are to be disposed of should be shredded in line with agreed Asset Handling Procedures.

Purpose

The purpose is to ensure that employees and contractors understand their responsibilities and are suitable for the roles for which they are considered. The employees and contractors are aware of and fulfill their information security responsibilities. To protect the organisation’s interests as part of the process of changing or terminating employment.

Scope

The scope is to define the functioning of the XXX focusing on the manpower & IT that is used to run the XXX. This policy applies to all those personnel working in the XXX as staff, contractors and also covers the aspect where any staff who requires access to XXX’s information systems or information of any type or format (paper or electronic).

Human Resource Security Policy

3.1 Screening

• As per ISMS HR Procedure, Screening of the candidate shall be carried out for all candidates
• Information on all candidates being considered for positions within the XXX is collected and handled in accordance with Indian legislation existing in the Pune jurisdiction. Depending on applicable legislation, the candidates are informed beforehand about the screening activities.

3.2 During Employment

• All staff/contractors are to follow Clear Desk and Clear Screen Policy.
• Management responsibilities shall include ensuring that staff and contractors:
  • Are properly briefed on their information security roles and responsibilities prior to being granted access to confidential information or information systems
  • Are provided with guidelines to state information security expectations of their role within the XXX
  • Are motivated to fulfill the information security policies of the XXX
  • Achieve a level of awareness on information security relevant to their roles and responsibilities within the XXX
  • Conform to the terms and conditions of employment/association, which includes the XXX’s security policy and methods of working
  • Continue to have the appropriate skills and qualifications and are educated on a regular basis.
• If staff and contractors are not made aware of their information security responsibilities, they can cause considerable damage to the XXX. Motivated personnel are likely to be more reliable and cause fewer information security incidents.

3.3 Terms And Conditions Of Employment

• The agreement with staff and contractors states their and the XXX’s responsibilities for the functioning within the XXX and in relation to information security.
• The agreements for staff or contractors reflect the XXX’s policies for the functioning of information security in addition to clarifying and stating:
  • That all staff and contractors who are given access to confidential information are also briefed upon the guidelines of information security.
  • Responsibilities for the clarification of information and management of XXX’s assets associated with information, information processing facilities and information services handled by the staff or contractor.
  • Responsibilities of the staff or contractor for the handling of information received from Interested parties;
  • Actions to be taken if the staff or contractor disregards the XXX’s security requirements.
  • Information security roles and responsibilities should be communicated to job candidates during the pre-employment process.
• The XXX ensures that staff and contractors agree to terms and conditions concerning information security, appropriate to the nature and extent of access they will have to the XXX’s assets associated with information systems and services.
• Where appropriate, responsibilities controlled within the terms and conditions of employment should continue for a defined period after the end of the employment.
• A Non- Disclosure Agreement (NDA) shall be signed by all staff, contractors.

3.4 Information Security Awareness And Training

• All employees of the XXX and, where relevant, contractors shall receive appropriate awareness education and training and regular updates in XXX policies and procedures, as relevant for their job function.
• Awareness, education and training can be part of, or conducted in collaboration with, other training activities, for example general IT or general security training. Awareness, education and training activities shall be suitable and relevant to the individual’s roles, responsibilities and skills.
• An assessment of the employees/contractors understanding is conducted at the end of an awareness, education and training course to test knowledge transfer.

3.5 Compliance With Rules And Regulations

• By signing the Appointment letter an employee is deemed to have expressed his/her acceptance of all the policies, rules, regulations, terms and conditions framed from time to time by the concerned authorized officers.
• During employment, the terms of employment of employee/ contractors shall be governed by the policies and rules framed from time to time covering, among others, Discipline, Code of Conduct etc.

3.6 Confidentiality And Non-Disclosure

Whether information in written or verbal, or contained in computer hardware or software, disk, hard disk, tape or other media, this information is of substantial value, highly confidential and is not known to the general public. Such Information is being provided and disclosed to the staff, contractor solely for use in connection with his/her employment or work of the XXX. NDA is to be signed by all employee/ contractors. Signing to be followed as per Procedure.

3.7 Alteration In The Terms Of Employment

• • XXX reserves the right to make reasonable changes to the duties of an employee, contractor according to the needs of the operation including, relocating/shifting such staff’s workplace and / or transferring such staff to serve at any other location of the XXX.
• • The XXX reserves the right to make reasonable changes to any terms or conditions of employment of any staff with prior notice.

3.8 Termination and Change Of Employment

• Information security responsibilities and duties that remains valid after termination or change of employment is defined, communicated to the staff or contractor and enforced.
• Changes of responsibility or employment are managed as the termination of the current responsibility or employment combined with the initiation of the new responsibilities or employment.
• The Human Resources function is generally responsible for the overall termination process and shall work together with the supervising Dept in change of the person leaving to manage the information security aspects of the procedures. In the case of a contractor provided through an external party, this termination process is undertaken by the external party in accordance with the contract between the XXX and the external party.
• Establishment Department shall inform employee or contractors of changes to personnel and operating arrangements.

3.9 Disciplinary Action

• There shall be a formal and communicated disciplinary process in place to take action against employee who have committed an information security breach.
• Disciplinary action shall be taken by the management depending upon the severity of the event.

3.10 Discharge/Dismissal/Termination

The services of employee may be terminated after giving him one month’s prior notice as per the terms of appointment / service agreement, if any, or payment of basic salary, in lieu thereof or for that matter clearance of any pending salary or financial reimbursements and terminate him immediately after settlement of the same.

3.11 Staff Exit Policy

• Processes are implemented to ensure that all access rights of users of XXX’s information systems are removed in a timely manner upon termination or suspension of their employment, contract or agreement.
• Processes and responsibilities are agreed upon and implemented to enable emergency suspension of a user’s access when that access is considered a risk to the XXX or its systems as defined. Establishment Dept. fill user’s clearance certificate & get it signed by their reporting Dept in charge before user’s last working day.

Enforcement

Any staff, contractor who is found to have violated the policies may be subject to disciplinary action, up to, including termination of employment or legal case against the staff, depending on the degree of the offense committed.

Sample Employment Contractual Agreement

Employee Information and Technology Security Agreement I acknowledge that [name of organization]’s information and technology security policies, guidelines, and procedures have been made available to me for review and consideration. I also certify that I have been given ample opportunity to have any and all questions about my responsibilities addressed. I am, therefore, aware that I am accountable for information and technology security procedures as they govern the acceptable performance of my job. I understand that failure to abide by any and all policies, guidelines, and procedures can result in organizational, civil, or criminal action and/or the termination of my employment. Signature: ______________________________ Printed Name: ______________________________ Job Title: ___________________________________ Date: ______/_____/______

Contractor/Consultant/Outsider Information and Technology Security Agreement I acknowledge that [name of organization] has provided me with adequate time to review and consider the information and technology security policies, guidelines, and procedures it deems applicable to responsibilities I am undertaking on behalf of [name of organization], regardless of my employment status. I also certify that I have been given ample opportunity to have any and all questions about my responsibilities addressed. I am, therefore, aware that I am accountable for those information and technology security procedures as they relate to my work for, or on the behalf of, [name of organization]. I understand that failure to abide by any and all policies, guidelines, and procedures can result in organizational, civil, or criminal action and/or the termination of my relationship with [name of organization]. Signature: __________________ Printed Name: __________________ Affiliation: _______________________ Date: /__

Purpose

XXX applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system.

Scope

XXX apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example

• developing layered protections;
• establishing sound security policy, architecture, and controls as the foundation for design;
• incorporating security requirements into the system development life cycle;
• delineating physical and logical security boundaries;
• ensuring that system developers are trained on how to build secure software;
• tailoring security controls to meet organizational and operational needs;
• performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and
• reducing risk to acceptable levels, thus enabling informed risk management decisions.

Policy

Top management at XXX understands that principles for engineering secure systems should be established, documented, maintained and applied to any information system implementation effort. To this end XXX has produced this secure system engineering principles policy to ensure that the Company:

Produces principles that will be applied to in-house information system engineering activities

– Ensures that security will be designed into all architecture layers balancing the need for security with that of accessibility

• Ensures that new technology is analysed for security risks
• Ensures that the design is reviewed against known attack patterns
• Ensures that Principles are reviewed to ensure their effectiveness in contributing to enhanced standards of security within the engineering process
• Ensure that Principles are reviewed to ensure they remain up-to-date in terms of combating any new potential threats and in advances in technology

Top management also understand that certain suppliers may have inadequate information security management and will, in such cases, identify and apply controls necessary to ensure security is maintained. It will use
confidentiality agreements

• non-disclosure agreements and
• second party audits where appropriate.

• The Company will also take into account any Data Protection regulations and will be aware of all legal and contractual responsibilities in the area.
• Application development procedures will also apply secure engineering principles when developing applications for both input and output interfaces.
• Responsibility for upholding this policy is truly company-wide under the authority of the Managing Director who encourages the personal commitment of all staff to address information security as part of their skills.

Principle for Engineering secure system

Security Foundation

Principle 1: Establish a sound security policy as the “foundation” for design.
A security policy is an important document to develop while designing an information system. The security policy begins with the organization’s basic commitment to information security formulated as a general policy statement. The policy is then applied to all aspects of the system design or security solution. The policy identifies security goals (e.g., confidentiality, integrity, availability, accountability, and assurance) the system should support and these goals guide the procedures, standards and controls used in the IT security architecture design. The policy also should require definition of critical assets, the perceived threat, and security-related roles and responsibilities.

Principle 2: Treat security as an integral part of the overall system design.
Security must be considered in information system design and should be integrated fully into the system life-cycle. Experience has shown it to be both difficult and costly to introduce security measures properly and successfully after a system has been developed, so security should be implemented in the design stage of all new information systems, and where possible, in the modification and continuing operation of all legacy systems. This includes establishing security policies, understanding the resulting security requirements, participating in the evaluation of security products, and in the engineering, design, implementation, and disposal of the system.

Principle 3: Clearly delineate the physical and logical security boundaries governed by associated security policies.
Information technology exists in physical and logical locations, and boundaries exist between these locations. An understanding of what is to be protected from external factors can help ensure adequate protective measures are applied where they will be most effective. Sometimes a boundary is defined by people, information, and information technology associated with one physical location. But this ignores the reality that, within a single location, many different security policies may be in place, some covering publicly accessible information and some covering sensitive or confidential information. Other times a boundary is defined by a security policy that governs a specific set of information and information technology that can cross physical boundaries. Further complicating the matter is that, many times, a single machine or server may house both public-access and sensitive information. As a result, multiple security policies may apply to a single machine or within a single system. Therefore, when developing an information system, security boundaries must be considered and communicated in relevant system documentation and security policies.

Principle 4: Ensure that developers are trained in how to develop secure software.
Ensure that developers are adequately trained in the design, development, configuration control, integration, and testing of secure software before developing the system.

RISK BASED

Principle 5: Reduce risk to an acceptable level.
Risk is defined as the combination of (1) the likelihood that a particular threat source will exercise (intentionally exploit or unintentionally trigger) a particular information system vulnerability and (2) the resulting adverse impact on organizational operations, assets, or individuals should this occur. Recognize that the elimination of all risk is not cost-effective. A cost-benefit analysis should be conducted for each proposed control. In some cases, the benefits of a more secure system may not justify the direct and indirect costs. Benefits include more than just prevention of monetary loss; for example, controls may be essential for maintaining public trust and confidence. Direct costs include the cost of purchasing and installing a given technology; indirect costs include decreased system performance and additional training. The goal is to enhance mission/business capabilities by mitigating mission/business risk to an acceptable level. (Related Principle: 6)

Principle 6: Assume that external systems are insecure.
The term information domain arises from the practice of partitioning information resources according to access control, need, and levels of protection required. Organizations implement specific measures to enforce this partitioning and to provide for the deliberate flow of authorized information between information domains. The boundary of an information domain represents the security perimeter for that domain. An external domain is one that is not under your control. In general, external systems should be considered insecure. Until an external domain has been deemed “trusted,” system engineers, architects, and IT specialists should presume the security measures of an external system are different than those of a trusted internal system and design the system security features accordingly.

Principle 7: Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of operational effectiveness.
To meet stated security requirements, a systems designer, architect, or security practitioner will need to identify and address all competing operational needs. It may be necessary to modify or adjust security goals due to other operational requirements. In modifying or adjusting security goals, an acceptance of greater risk and cost may be inevitable. By identifying and addressing these trade-offs as early as possible, decision makers will have greater latitude and be able to achieve more effective systems. (Related: Principle 4)

Principle 8: Implement tailored system security measures to meet organizational security goals.
In general, IT security measures are tailored according to an organization’s unique needs. While numerous factors, such as the overriding mission requirements, and guidance, are to be considered, the fundamental issue is the protection of the mission or business from IT security-related, negative impacts. Because IT security needs are not uniform, system designers and security practitioners should consider the level of trust when connecting to other external networks and internal sub- domains. Recognizing the uniqueness of each system allows a layered security strategy to be used – implementing lower assurance solutions with lower costs to protect less critical systems and higher assurance solutions only at the most critical areas.

Principle 9: Protect information while being processed, in transit, and in storage.
The risk of unauthorized modification or destruction of data, disclosure of information, and denial of access to data while in transit should be considered along with the risks associated with data that is in storage or being processed. Therefore, system engineers, architects, and IT specialists should implement security measures to preserve, as needed, the integrity, confidentiality, and availability of data, including application software, while the information is being processed, in transit, and in storage.

Principle 10: Consider custom products to achieve adequate security.
Designers should recognize that in some instances it may not be possible to meet security goals with systems constructed entirely from commercial off-the-shelf (COTS) products. In such instances, it may be necessary to augment COTS with non-COTS mechanisms.

Principle 11: Protect against all likely classes of “attacks.”
In designing the security controls, multiple classes of “attacks” need to be considered. Those classes that result in unacceptable risk need to be mitigated. Examples of “attack” classes are: passive monitoring, active network attacks, exploitation by insiders, attacks requiring physical access or proximity, and the insertion of back doors and malicious code during software development and/or distribution.

EASY TO USE

Principle 12: Where possible, base security on open standards for portability and interoperability.
Most organizations depend significantly on distributed information systems to perform their mission or business. These systems distribute information both across their own organization and to other organizations. For security capabilities to be effective in such environments, security program designers should make every effort to incorporate interoperability and portability into all security measures, including hardware and software, and implementation practices.

Principle 13: Use common language in developing security requirements.
The use of a common language when developing security requirements permits organizations to evaluate and compare security products and features evaluated in a common test environment. When a “common” evaluation process is based upon common requirements or criteria, a level of confidence can be established that ensures product security functions conform to an organization’s security requirements. The Common Criteria (CC; available at http://www.commoncriteriaportal.org/) provides a source of common expressions for common needs and supports a common assessment methodology. Use of CC “protection profiles” and “security targets” greatly aids the development of products (and to some extent systems) that have IT security functions. The rigor and repeatability of the CC methodology provides for thorough definition of user security needs. Security targets provide system integrators with key information needed in the procurement of components and implementation of secure IT systems.

Principle 14: Design security to allow for regular adoption of new technology, including a secure and logical technology upgrade process.
As mission and business processes and the threat environment change, security requirements and technical protection methods must be updated. IT-related risks to the mission/business vary over time and undergo periodic assessment. Periodic assessment should be performed to enable system designers and managers to make informed risk management decisions on whether to accept or mitigate identified risks with changes or updates to the security capability. The lack of timely identification through consistent security solution re-evaluation and correction of evolving, applicable IT vulnerabilities results in false trust and increased risk. Each security mechanism should be able to support migration to new technology or upgrade of new features without requiring an entire system redesign. The security design should be modular so that individual parts of the security design can be upgraded without the requirement to modify the entire system.

Principle 15: Strive for operational ease of use.
The more difficult it is to maintain and operate a security control the less effective that control is likely to be. Therefore, security controls should be designed to be consistent with the concept of operations and with ease-of-use as an important consideration. The experience and expertise of administrators and users should be appropriate and proportional to the operation of the security control. An organization must invest the resources necessary to ensure system administrators and users are properly trained. Moreover, administrator and user training costs along with the life-cycle operational costs should be considered when determining the cost-effectiveness of the security control.

INCREASE RESILIENCE

Principle 16: Implement layered security (ensure no single point of vulnerability).
Security designs should consider a layered approach to address or protect against a specific threat or to reduce vulnerability. For example, the use of a packet-filtering router in conjunction with an application gateway and an intrusion detection system combine to increase the work-factor an attacker must expend to successfully attack the system. Add good password controls and adequate user training to improve the system’s security posture even more. By using multiple, overlapping protection approaches, the failure or circumvention of any individual protection approach will not leave the system unprotected. Through user training and awareness, well-crafted policies and procedures, and redundancy of protection mechanisms, layered protections enable effective protection of information technology for the purpose of achieving mission objectives. The need for layered protections is especially important when COTS products are used. Practical experience has shown that the current state-of-the-art for security quality in COTS products does not provide a high degree of protection against sophisticated attacks. It is possible to help mitigate this situation by placing several controls in series, requiring additional work by attackers to accomplish their goals.

Principle 17: Design and operate an IT system to limit damage and to be resilient in response.
Information systems should be resistant to attack, should limit damage, and should recover rapidly when attacks do occur. The principle suggested here recognizes the need for adequate protection technologies at all levels to ensure that any potential cyber attack will be countered effectively. There are vulnerabilities that cannot be fixed, those that have not yet been fixed, those that are not known, and those that could be fixed but are not (e.g., risky services allowed through firewalls) to allow increased operational capabilities. In addition to achieving a secure initial state, secure systems should have a well-defined status after failure, either to a secure failure state or via a recovery procedure to a known secure state. Organizations should establish detect and respond capabilities, manage single points of failure in their systems, and implement a reporting and response strategy. (Related: Principle 14)

Principle 18: Provide assurance that the system is, and continues to be, resilient in the face of expected threats.
Assurance is the grounds for confidence that a system meets its security expectations. These expectations can typically be summarized as providing sufficient resistance to both direct penetration and attempts to circumvent security controls. Good understanding of the threat environment, evaluation of requirement sets, hardware and software engineering disciplines, and product and system evaluations are primary measures used to achieve assurance. Additionally, the documentation of the specific and evolving threats is important in making timely adjustments in applied security and strategically supporting incremental security enhancements.

Principle 19: Limit or contain vulnerabilities.
Design systems to limit or contain vulnerabilities. If a vulnerability does exist, damage can be limited or contained, allowing other information system elements to function properly. Limiting and containing insecurities also helps to focus response and reconstitution efforts to information system areas most in need. (Related: Principle 10)

Principle 20: Isolate public access systems from mission critical resources (e.g., data, processes, etc.).
While the trend toward shared infrastructure has considerable merit in many cases, it is not universally applicable. In cases where the sensitivity or criticality of the information is high, organizations may want to limit the number of systems on which that data is stored and isolate them, either physically or logically. Physical isolation may include ensuring that no physical connection exists between an organization’s public access information resources and an organization’s critical information. When implementing logical isolation solutions, layers of security services and mechanisms should be established between public systems and secure systems responsible for protecting mission critical resources. Security layers may include using network architecture designs such as demilitarized zones and screened subnets. Finally, system designers and administrators should enforce organizational security policies and procedures regarding use of public access systems.

Principle 21: Use boundary mechanisms to separate computing systems and network infrastructures.
To control the flow of information and access across network boundaries in computing and communications infrastructures, and to enforce the proper separation of user groups, a suite of access control devices and accompanying access control policies should be used. Determine the following for communications across network boundaries:

• What external interfaces are required
• Whether information is pushed or pulled
• What ports, protocols, and network services are required
• What requirements exist for system information exchanges; for example, trust relationships, database replication services, and domain name resolution processes

Principle 22: Design and implement audit mechanisms to detect unauthorized use and to support incident investigations.
Organizations should monitor, record, and periodically review audit logs to identify unauthorized use and to ensure system resources are functioning properly. In some cases, organizations may be required to disclose information obtained through auditing mechanisms to appropriate third parties, including law enforcement authorities. Many organizations have implemented consent to monitor policies which state that evidence of unauthorized use (e.g., audit trails) may be used to support administrative or criminal investigations.

Principle 23: Develop and exercise contingency or disaster recovery procedures to ensure appropriate availability.
Continuity of operations plans or disaster recovery procedures address continuance of an organization’s operation in the event of a disaster or prolonged service interruption that affects the organization’s mission. Such plans should address an emergency response phase, a recovery phase, and a return to normal operation phase. Personnel responsibilities during an incident and available resources should be identified. In reality, contingency and disaster recovery plans do not address every possible scenario or assumption. Rather, focus on the events most likely to occur and identify an acceptable method of recovery. Periodically, the plans and procedures should be exercised to ensure that they are effective and well understood.

REDUCE VULNERABILITIES

Principle 24: Strive for simplicity.
The more complex the mechanism, the more likely it may possess exploitable flaws. Simple mechanisms tend to have fewer exploitable flaws and require less maintenance. Further, because configuration management issues are simplified, updating or replacing a simple mechanism becomes a less intensive process.

Principle 25: Minimize the system elements to be trusted.
Security measures include people, operations, and technology. Where technology is used, hardware, firmware, and software should be designed and implemented so that a minimum number of system elements need to be trusted in order to maintain protection. Further, to ensure cost-effective and timely certification of system security features, it is important to minimize the amount of software and hardware expected to provide the most secure functions for the system.

Principle 26: Implement least privilege.
The concept of limiting access, or “least privilege,” is simply to provide no more authorizations than necessary to perform required functions. This is perhaps most often applied in the administration of the system. Its goal is to reduce risk by limiting the number of people with access to critical system security controls (i.e., controlling who is allowed to enable or disable system security features or change the privileges of users or programs). Best practice suggests it is better to have several administrators with limited access to security resources rather than one person with “super user” permissions. . Consideration should be given to implementing role-based access controls for various aspects of system use, not only administration. The system security policy can identify and define the various roles of users or processes. Each role is assigned those permissions needed to perform its functions. Each permission specifies a permitted access to a particular resource (such as “read” and “write” access to a specified file or directory, “connect” access to a given host and port, etc.). Unless permission is granted explicitly, the user or process should not be able to access the protected resource. Additionally, identify the roles/responsibilities that, for security purposes, should remain separate (this is commonly termed “separation of duties”).

Principle 27: Do not implement unnecessary security mechanisms.
Every security mechanism should support a security service or set of services, and every security service should support one or more security goals. Extra measures should not be implemented if they do not support a recognized service or security goal. Such mechanisms could add unneeded complexity to the system and are potential sources of additional vulnerabilities. An example is file encryption supporting the access control service that in turn supports the goals of confidentiality and integrity by preventing unauthorized file access. If file encryption is a necessary part of accomplishing the goals, then the mechanism is appropriate. However, if these security goals are adequately supported without inclusion of file encryption, then that mechanism would be an unneeded system complexity.

Principle 28: Ensure proper security in the shutdown or disposal of a system.
Although a system may be powered down, critical information still resides on the system and could be retrieved by an unauthorized user or organization. Access to critical information systems must be controlled at all times. At the end of a system’s life-cycle, system designers should develop procedures to dispose of an information system’s assets in a proper and secure fashion. Procedures must be implemented to ensure system hard drives, volatile memory, and other media are purged to an acceptable level and do not retain residual information.

Principle 29: Identify and prevent common errors and vulnerabilities.
Many errors reoccur with disturbing regularity – errors such as buffer overflows, race conditions, format string errors, failing to check input for validity, and programs being given excessive privileges. Learning from the past will improve future results.

DESIGN WITH THE NETWORK IN MIND

Principle 30: Implement security through a combination of measures distributed physically and logically.
Often, a single security service is achieved by cooperating elements existing on separate machines. For example, system authentication is typically accomplished using elements ranging from the user- interface on a workstation through the networking elements to an application on an authentication server. It is important to associate all elements with the security service they provide. These components are likely to be shared across systems to achieve security as infrastructure resources come under more senior budget and operational control.

Principle 31: Formulate security measures to address multiple overlapping information domains.
An information domain is a set of active entities (person, process, or devices) and their data objects. A single information domain may be subject to multiple security policies. A single security policy may span multiple information domains. An efficient and cost effective security capability should be able to enforce multiple security policies to protect multiple information domains without the need to separate physically the information and respective information systems processing the data. This principle argues for moving away from the traditional practice of creating separate LANs and infrastructures for various sensitivity levels (e.g., security classification or business function such as proposal development) and moving toward solutions that enable the use of common, shared, infrastructures with appropriate protections at the operating system, application, and workstation level. Moreover, to accomplish missions and protect critical functions, organizations have many types of information to safeguard. With this principle in mind, system engineers, architects, and IT specialists should develop a security capability that allows organizations with multiple levels of information sensitivity to achieve the basic security goals in an efficient manner.

Principle 32: Authenticate users and processes to ensure appropriate access control decisions both within and across domains.
Authentication is the process where a system establishes the validity of a transmission, message, or a means of verifying the eligibility of an individual, process, or machine to carry out a desired action, thereby ensuring that security is not compromised by an untrusted source. It is essential that adequate authentication be achieved in order to implement security policies and achieve security goals. Additionally, level of trust is always an issue when dealing with cross-domain interactions. The solution is to establish an authentication policy and apply it to cross-domain interactions as required. Note: A user may have rights to use more than one name in multiple domains. Further, rights may differ among the domains, potentially leading to security policy violations.

Principle 33: Use unique identities to ensure accountability.
An identity may represent an actual user or a process with its own identity, e.g., a program making a remote access. Unique identities are a required element in order to be able to:

• Maintain accountability and traceability of a user or process
• Assign specific rights to an individual user or process
• Provide for non-repudiation
• Enforce access control decisions
• Establish the identity of a peer in a secure communications path
• Prevent unauthorized users from masquerading as an authorized user

1.0 Purpose

The purpose of the XXX’s Information Asset Management Policy is to establish the rules for the control of hardware, software, applications, and information used by XXX

2.0 Scope

The scope of this policy extends to all XXX departments, employees, third parties, vendors and partners who utilize or who are responsible for the development, management and maintenance of all XXX’s information assets. The XXX’s Information Asset Management Policy applies to individuals who are responsible for the use, purchase, implementation, management, and/or maintenance of XXX information resources.

The XXX categorises information assets as:

• Information and Information Systems:
  • Databases
  • Data files
  • Hardcopy documents
  • User guides
  • Notebooks
  • Training material
  • Policies, Procedures
  • Business Continuity plans
  • Financial Data
• Software:
  • Applications
  • System software
  • Development software
  • Utilities software
• Physical:
  • Computer equipment
  • Communications equipment
  • Portable and local Media – storage and recording
  • Property and accommodation
• Services:
  • Communications
  • Utilities (power. lighting, environmental controls)
• Personnel:
  • Knowledge
  • Skills
  • Experience
• Intangibles:
  • Reputation

3 Some terms used

3.1 Information Asset Owner
The owners of an information asset are those individuals who have primary responsibility for the viability and suitability of the asset. The owner is a senior person within an organization with sufficient authority and officially designated as accountable for a specific business process / function within an organization. The owner must determine what information assets are they responsible for. The responsibility is not restricted to the information systems within their domain and should go beyond in defining the information that needs to be managed within those systems. Such information may include Personally Identifiable Information (PII) along with critical business data in both electronic and non-electronic formats. It is the owner’s responsibility to set the security requirements for information assets and communicate those requirements to all of the assets’ custodians. Owners are also responsible to assess these requirements from time to time based on the changing threat profiles and / or the value of information with passage of time. Owners should ensure that the defined security requirements are implemented and maintained by the data custodians. Further, the effectiveness of the controls implemented should be assessed at regular intervals (e.g. through audits). An owner may delegate these security responsibilities, but the owner remains ultimately responsible for the protection of the asset.

3.2 Custodian of an Information Asset
The term “custodian” refers to any individual in the organization who has the responsibility to protect an information asset as it is stored, transported, or processed in line with the requirements defined by the information asset owner. “Custodians” includes users from the Information Technology / Information Security function along with the staff who may be responsible for transporting information (e.g. paper records / CDs / USBs etc) from one place to another or even the facilities or security staff who may have physical access to information processing and storing facilities. Certain roles within the organization such as IT staff with administrative / root privileges may have unlimited access to the agency’s information system, these are critical roles and sufficient controls and procedures must be developed for such privileged access. Data Users also have a critical role to protect and maintain an organization’s information systems and data. For the purpose of information security, a Data User is any employee, contractor or third-party provider who is authorized by the Data Owner to access information assets. At times, the data custodian may play the role of a trusted advisor to the owner advising him on the risks and controls suitable for the information asset. However, the ultimate responsibility lies with the Owner and in no circumstances, the data custodian shall deem the role of an owner.

3.3 Risks to Information Assets
An Information Asset Owner should assess the risks to the information assets and ensure adequate controls to protect against:

1. Loss of Confidentiality: Inappropriate access to, or disclosure of, protectively marked or personal data by Data users, public and / or malicious actors, whether accidental or deliberate
2. Loss of Integrity: Data users acting in error or deliberately, or external parties accessing your information illegally, acting maliciously to compromise the integrity of your data with an intention to defraud you or your customers or to cause reputation damage to your organization
3. Loss of Availability: This could be either temporary or permanent.
   • Information loss – particularly during transfer or movement of information, or because of business change (mergers, acquisitions, restructuring).
   • Loss of access to information due to system / network outages caused due to errors or deliberate actions.
   • Loss of digital continuity – i.e. losing the ability to use your information in the way required when needed. By use we mean being able to find, open, work with, understand and trust your information. The lifecycle of a piece of information – how long you need to use and keep it – is often different to the lifecycle of the IT system used to access and support it.
4. Information Currency: Business needs change, systems change, the value of an information asset may change or the organization’s information risk appetite may change. An organization’s processes should be agile to manage the information security of the asset in accordance to the changing business environment.

4 Policy Statement

The XXX’s Information Governance Group (IGG) co-ordinates responsibility for the management of information assets by appointing nominated information asset owners across departments. All identified information assets must be recorded and managed by information asset owners in accordance with the XXX’s Information Security Management System. The XXX must take the following steps to ensure all information assets are appropriately identified, recorded and maintained:

4.1 Information and Information Systems

Information held and maintained by the XXX can either be in hard copy form stored in physical locations, filing systems, office locations or stored electronically using software and electronic backup systems.

Types of Information and Information Systems assets:

• Databases – Access to these must be given to authorised employees only and logs should be maintained to record all access to and changes made to any data held within any database system.
• Data files – Access to any data file(s) must be given to authorised employees only and logs must be maintained to record all access to and changes made to any data held within database systems.
• Hard copy documents – All hard copy documents containing sensitive and personal information must be accessed, processed, maintained and securely stored in accordance with the XXX’s Information Safe Haven guidance. Restricted hard copy documents requiring controlled access must have a signing in/out record maintained wherever appropriate.
• User guides – All user guides which assist and aid in the understanding of processes, procedures or systems should be safely stored and should be easily and readily accessible to all relevant employees – wherever possible. Guides which exist only in physical form should be digitised to include an electronic version which can be stored electronically on the XXX’s ICT Network.
• Notebooks – Information contained in notebooks which are used to record sensitive or personal information must be transferred to secure information systems as soon as possible and either the pages or entire notebook must be securely destroyed once the information has been transferred.
• Training material – All relevant training material(s) must be stored and made readily accessible to all relevant employees. Duplication or physical reproduction of training manuals must be kept to a minimum and avoided wherever possible.
• Policies and Procedures – All XXX Policies and Procedures should be made available and disseminated via the XXX’s main website. All original copies of Policies and Procedures documents whether electronic or hardcopy must be safely stored, regularly reviewed and a version history control record must be maintained for each document to ensure they are up to date.
• Business Continuity plans – All Business Continuity plans must be regularly reviewed, disseminated to appropriate employees and stored safely for easy retrieval as and when necessary.
• Financial Data – Data and Information relating to XXX financial data must be restricted to authorized employees only. Recording mechanisms must be in place for logging access, changes and use of financial data and information.

4.2 Software

Computer and IT systems software is widely used across the XXX and is vital to the day to day running of the XXX .The use of software has continued to change the way the XXX works. Substantial investment has been made in Software along with accompanying ongoing costs and expenditure such as annual software/systems support, licensing and staff training.

• Applications – Software used by the XXX must be appropriately sourced using XXX approved suppliers and must be evaluated for business need, suitability, efficiency, and ease of use, cost effectiveness and integration into existing XXX systems. All software approved for use by the XXX must be recorded on an approved software list. Appropriate numbers of software licenses must be purchased to cover volume of use and to satisfy legal requirements. Software media must be stored (physically and electronically) in a secure, centralized location along with software installation codes and registration numbers. Access to software media by employees must be controlled and limited to authorized employees only. A record must be maintained of all installations of software, licensing volumes SLA documentation and references in a centralized location where access is provided to authorize employees only. A signing in/out system should be used for controlling the use of physical software media.
• System software – Server/system software such as Operating Systems, must be evaluated for business need, suitability, efficiency, cost effectiveness and integration into existing XXX systems. Operating System installation media must be stored in a secure, centralized location along with installation codes. Access to Server/system software media by employees must be controlled and limited to authorized employees only. A record must be maintained of all installations of software, licensing volumes SLA documentation and references in a centralized location where access is provided to authorize employees only. A signing in/out system should be used for controlling the use of physical software media. Backups of complete Server/systems installations must be routinely carried out for disaster recovery purposes. Installation, configuration and maintenance of Server/system software must only be undertaken by employees who are trained and qualified to do so.
• Development software – software for the support of existing systems and for the development of in-house solutions must follow the same processes for procurement and use as for the applications and Server/systems software. Development software should only be used by employees who are trained or who are undergoing training to use the development software.

All types of software (with the exception of routine security updates and patches verified by software vendors) must go through agreed purchasing procedures and must be recorded on a XXX approved software list. Where the software is used in the storing, handling, processing or retention of data including personal data relating to the XXX’s information or services commissioned by the XXX, then the purchasing procedure should follow the guidelines contained within the XXX’s ‘Supplier Information Security Policy’ and approved by the Director of Finance and ICT Services in line with the ‘Protocol for the Approval of new Systems or Changes to Existing Systems by the Director of Finance’.

4.3 Physical

The XXX’s most visible information assets are those which are physically located throughout the XXX such as computers, printers and phones etc. Offices and buildings must also be considered as information assets – providing location for the housing and installation of the XXX’s ICT Data and Communications Network infrastructure and physically stored documents and information.

• Computer equipment – A large number of computing devices are in use across the XXX. Computers are one of the most costly single items of equipment and must be subject to controls from procurement to disposal. The XXX must be able to track all activity and use relating to all XXX computing devices using various means such as via the computer network and/or using logging systems such as signing in and out and other such recording mechanisms. All computers must be allocated a unique asset tag number which is recorded against the manufacturer’s serial number and model which should never be altered or exchanged with any other computer. Throughout its life, a computer may be subject to hardware upgrades, new software installations, configuration changes and maintenance and all such activity must be appropriately recorded, maintained and updated by the ICT Service.
• Communications equipment – Mobile and office phones are widely used communications devices across the XXX. Other network and communications devices identified as information assets include routers, switches, video conferencing equipment etc. Along with computing equipment, these devices must be allocated an asset tag number. All communications equipment must be identified, recorded and appropriately maintained by the ICT Service.
• Portable, local media storage – Media such as CD/DVDs, Magnetic tape, flash/portable hard disks are valuable information assets because they are used to save and retrieve XXX information and data. Irrespective of the information stored on them, all such media must be classified and handled as ‘RESTRICTED’ in accordance with the XXX’s Information Classification and Handling Policy. The portable nature of this type of media requires responsible use and adherence to all XXX policies, procedures and processes which are in place for the protection of information and data. Appropriate labelling and recording mechanisms should be in place to ensure the safety and integrity of media – enabling tracking of essential media such as for data backups e.g. media required to carry out data/file restores must be signed in and out from a secure location. Portable media must be used in accordance with the XXX’s Encryption & Cryptographic Controls Policy, Desktop and Mobile Device Procedures and Data Protection and Storage Media Handling Procedures. All physical computer, communications and storage media/devices must go through purchasing procedures and must be recorded on a XXX approved hardware inventory.
• Property and accommodation – The XXX’s Corporate Asset Management Plan provides comprehensive information relating to buildings and property as information assets. ICT equipment along with Data and Network Communications infrastructure equipment is housed in many buildings and property owned by the XXX and is therefore subject to the Corporate Asset Management Plan

4.4 Services

• Communications – It is vital for the XXX to maintain its ability to communicate in many different forms. Communications equipment must be maintained and clear processes, policies and procedures for the provision of this service must be in place. E-mail is also a vital means of communication and as such, requires a robust, reliable infrastructure to enable the XXX to communicate effectively and reliably, both internally and externally.
• Utilities (power. lighting, environmental controls) – These services are information assets as they provide fundamental requirements for the XXX to function appropriately, safely and effectively. It is essential that property maintenance and inspections are routinely carried out and that employees are proactive in reporting faults, whenever noted, to the XXX’s Property Services division.

4.5 Personnel

The XXX cannot function without its workforce – it is its largest asset. The provision of good public services requires XXX employees to have the necessary skills, knowledge and ability to work within many different areas and departments across the XXX. The number of unique functions and specialisms across the XXX requires a varied knowledge and skills base which must be supported by robust recruitment processes, appropriate training provision and good management of employee skill identification, work placement and allocation.

• Knowledge and Experience – The XXX has a great pool of employees who have a wide knowledge and experience base to draw on and as such, is a valuable information asset.
• Skills – All XXX employees must possess the necessary skills and ability to do their jobs.

4.6 Intangibles

Reputation – The XXX is very aware that public perception and confidence in its ability to deliver effective, efficient public services is of the utmost importance. Reputation is an asset which promotes confidence and generates support in what the XXX is trying to achieve. The XXX takes its reputation seriously and proactively engages to develop policies and procedures along with a consistent approach in maintaining and presenting the right image. The XXX encourages good reputation and is assisted by:

• Good working practices
• Corporate Image Branding
• Public Consultation

4.7 Information Classification and Handling

All XXX information has a value to the organization, however not all of the information has an equal value or requires the same level of protection. Being able to identify the value of information assets is key to understanding the level of security that they require. The XXX maintains an Information Classification and handling scheme which involves grouping information and categorizing content to establish the most appropriate way of handling, storing, retrieving and to determine who is authorized to access particular Information. All information in both electronic and physical forms must be categorized using either ‘PUBLIC’, ‘CONTROLLED’ or ‘RESTRICTED’ and must be appropriately labelled.
Any information that is not specifically marked as being ‘RESTRICTED’ or ‘CONTROLLED’ will be deemed to be ‘PUBLIC’. Where information is grouped together, the highest classification must be applied to all information in the group. The XXX’s information classification and handling policy and procedures provide further information

4.8 Guidelines for an Information Asset Owner

Information asset owner are individuals who are responsible and accountable for the information assets within an organization. Information asset owners shall define the controls necessary for the information asset and work with information custodians to ensure that they are implemented and effective.

• Classification: Asset owner should support the ISM in the task of asset classification by explaining the need and importance for all information asset assigned under his /her responsibility.
• Labelling: Asset owner SHOULD identify the appropriate labels for all assets as per their classification to support the Need-To-Know requirement and data labelling education and awareness for the staff, employees and contractors.
• Controls allocation: Owner SHOULD ensure the application of all baseline controls to all classified assets. Additional, stronger controls MAY be applied, if necessary and based on the risk assessment conducted. The controls shall consistently protect the Information Asset throughout their life cycle.
• Access Control and Physical Security: Asset Owner must authorize access to only those who have a business need for the information, and ensure that access is removed for those who no longer have a business need for the information. The Access control shall include physical as well as logical access to the information asset. The controls shall be chosen based on an assessment of risk.
• Logging & Security Monitoring: The asset owner shall identify suitable technical controls and processes to log and monitor systems for potential malicious activities or system disruptions.
• Awareness: The asset owner shall ensure that all personnel having access to the information asset are aware of the organization’s security requirements and any legal or regulatory responsibilities.
• Retention & Archival: The asset owner shall determine and document the retention periods of information assets governed by the organization’s policies and regulatory requirements.
• Incident Handling: The asset owner shall be responsible for the information asset. Any incident that compromises the confidentiality, integrity or availability of data should be reported and managed.
• Business Continuity: The information asset owner shall ensure the availability of information as and when required for the continuance of business.
• Ensure compliance: The asset owner shall ensure that the information asset is secured in compliance with the organizational security policy and state of Qatar laws and regulations.

4.9 Guidelines for the Information Asset Custodian

Information asset custodians are individuals in physical or logical possession of information. Information asset custodians are expected to work with information asset owners to gain a better understanding of these requirements. The information security controls implemented by the custodian must be documented and shared with the asset owner.

4.9.1 Information Technology Manager (IT Function)

• Classification: Assist the Asset owner along with the ISM in the task of asset classification.
• Labelling: Implement the data labeling as identified by the Asset owner. Advise the owner on technical limitations if any and possible technical mitigating solutions.
• Controls allocation: Identify and apply all controls (baseline and additional) to all information assets to protect the confidentiality, integrity, and availability of the information asset. The controls shall consistently protect the Information Asset throughout their life cycle.
• Access Control and Physical Security: Implement the necessary processes and controls to manage access control to information assets. Access shall be provided to only those who have a business need for the information, and ensure that access is removed for those who no longer have a business need for the information. The Access control shall include physical as well as logical access to the information asset. The controls shall be chosen based on an assessment of risk.
• Logging & Security Monitoring: Implement suitable technical controls and processes to log and monitor systems for potential malicious activities or system disruptions.
• Retention & Archival: Design and implement systems that shall ensure that information assets and the information life cycle are managed in line with the document retention policy.
• Incident Handling: Implement procedures for managing incidents. This should include incident reporting and incident response.
• Business Continuity: Design and implement the necessary procedures and controls to ensure the availability of information as and when required for the continuance of business.

4.9.2 Information Security Manager (Information Security Function)

• Information Governance: The Information Security Manager will manage the information security program of the organization. The ISM will develop information security policies to ensure that the organization’s information assets are secured adequately in line with the Information owner requirements and corporate policies and national regulations such as NIA Policy, Information Privacy Protection Law and Cyber crime law amongst others. IG and AC
• Information Classification: Assist the information owner in identifying assets and classifying them. The ISM should also assist the information asset owner and the ITM in selecting appropriate controls to provide the necessary assurance to information asset owners.
• Controls: Ensure the application of all baseline controls to all information assets.
• Risk Management: Conduct a Risk assessment in association with the information asset owner and prepare an appropriate Risk treatment plan. Monitor the effectiveness of risk treatment processes and plans periodically.
• Awareness: Design and deliver an information security awareness to all personnel having access to the information assets. The awareness shall elevate among the users an understanding of the organization’s security requirements and any legal or regulatory responsibilities.
• Incident Management: Define an Incident Management policy and necessary procedures. Work with the ITM to detect, respond and contain incidents. Inform and report senior management about critical incidents.
• Maintain co-ordination with government and law enforcement agencies to report and manage critical incidents.

4.9.3 Guidelines for Data User

• Information Governance: The Data user shall be responsible for the information assets (systems / infrastructure) provided to them to carry out their official responsibilities.
• Information Classification: The Data User shall adhere to the information classification scheme approved by the management and maintain the classification (label) provided by the information asset owner.]

5 Acceptable Use of Assets

All XXX departments, employees, elected members, contractors, vendors and partner agencies must observe and abide by all Acceptable Use policies and procedures pertaining to all XXX owned information assets.

6 Breaches of Policy

Breaches of this policy and/or security incidents can be defined as events which could have, or have resulted in, loss or damage to XXX assets, or an event which is in breach of the XXX’s security procedures and policies. All XXX employees, elected members, partner agencies, contractors and vendors have a responsibility to report security incidents and breaches of this policy as quickly as possible through the XXX’s Incident Reporting Procedure. This obligation also extends to any external organization contracted to support or access the Information Systems of the XXX. The XXX will take appropriate measures to remedy any breach of the policy and its associated procedures and guidelines through the relevant frameworks in place. In the case of an individual then the matter may be dealt with under the disciplinary process.

Example of Information Asset Register Format

S.No.	Asset Name	Category	Confidentiality	Integrity	Availability	Aggregate Security Level	Label	Group/ Department	Owner	Contact Details	Support Contact Details

1.0 Purpose

The purpose is to detect events, analyse them and determine an appropriate control action.This is to ensure that:

• Operational activities are performed as required and scheduled
• Operations are monitored, measured, reported and remediated
• All significant changes of information security is detected
• Appropriate control actions are determined for events and these are communicated to the appropriate
  functions.
• Provide the trigger, or entry point, for the execution of service operation processes and operations management activities.

2.0 Scope

The scope includes detection and management of all critical services and IT infrastructure in XXX. The scope predominantly includes, but not limited to the following infrastructure and any services provided via these.

• Servers
• Desktops/ Laptops
• Applications
• Databases
• Backup
• Storage
• Network Devices
• Security Devices

3.0 Process

3.1 Event Generation

• Requirements for events generation shall be established based on a risk assessment exercise.
• Systems and network infrastructure shall have the capability to capture and store security events based on the business / legal / regulatory / security requirements.
• Adequate and appropriate logging shall be enforced to ensure that security events / details related to the user / system activity are maintained.

3.2 Fault Logging

• Faults reported by Staff / Users or through an automated process related to problems with technology resources shall be logged, maintained and action taken by XXX
• Automated real-time alerts when faults / errors occur shall be enabled for infrastructure where feasible and required. Restricted or confidential information shall be masked from logging in the logs.

3.3 Contents of Audit Trails / Records

• Requirements for Audit Trails and Records shall be established based on a risk assessment exercise.
• Systems and network infrastructure shall have the capability to capture and store Audit Trails / Records based on the business / legal / regulatory / security requirements.
• The audit trail shall include sufficient information to establish ‘what activity occurred when and who (or what) caused them’.

3.4 Audit Log Reviews

• Audit trails shall be monitored and reviewed to detect suspicious or malicious activities and noncompliance to policies.
• Any activity that falls into these categories shall be investigated and the results of this analysis shall be recorded.

3.5 Time Synchronization

The time for all devices shall be configured to be synced / retrieve time from a centralized source to establish the time frames of the event generated / performed within the IT systems and infrastructure.

3.6 Audit Trail Security

• Access to audit logs shall be controlled.
• Audit logs shall be protected from intentional or unintentional deletion or modification.
• Adequate segregation of duties between staff performing the administration / review of audit trails and operational activities shall be enforced.

3.7 Log Rotation and Storage / Archiving

Logs shall be backed-up or archived regularly to a log management system or media to prevent alterations based on the business / legal / regulatory requirements and shall be stored in a physically secure environment.

3.8 Monitoring and Log Review

• Regular monitoring and review of audit logs shall be implemented to detect any suspicious activities / potential breach such as recurring failed logon attempts.
• Information security events detected because of the monitoring and review procedures shall be reported as stipulated by the XXX’s incident management policy.

3.9 Event Management Inputs & Outputs

3.9.1 Process Main Inputs
Alerts and events generated by the monitoring tools. While designing event management process, decision is taken on events need to be generated and how this can be done.
3.9.2 Process Main Outputs

3.9.2.1 Managed Events
Each type of event trigger will initiate actions prior to closure.

• Informational events do not require any actions to be taken
• Warnings are used to notify the appropriate teams/ processes so that corresponding actions can be
  taken
• Exceptional events get triggered when a service or application fails and when a CI doesn’t function
  normally.

3.9.2.2 Trigger to incident management
For those incidents that arise out of Exception events, the monitoring group assigns them to the appropriate resolver group in and informs the stakeholders and the Incident Manager .

3.9.2.3 Trigger to availability and capacity management
As a part of preventive and corrective actions taken to resolve exceptions which caused incidents,Availability and/or Capacity Management processes get triggered.

3.10 Define event logging criteria

• XXX Information security manager will define and identify the following:
• Identify and document the criteria for logging events considering risk and performance impact;
• Identify the event logging thresholds; and
• Define rules to report threshold breaches and event conditions.

3.11 Define what needs to be monitored

• XXX IS manager prepares a list of infrastructure assets that need to be monitored based on service criticality.
• Procedure documents are created to log events based on the rules defined.
• The duration for retention of event logs to meet legal/regulatory requirements and assist future investigations, is also defined at this stage.

3.12 Detect, filter events and create event logs

<Name the tool you are using>are monitoring tools which trigger the event management process. The monitoring tools are configured to monitor the critical and non-critical applications and servers. In the course of monitoring, three different types of events are generated: • Informational • Warning • Exceptional

3.13 Manual monitoring

Manual monitoring (wherever monitoring tools are not configured) is done for certain applications or servers on continuous basis in order to capture the events.

3.14 Gather monitoring data

The IS manager gathers the entire data with regard to manual monitoring for consolidation purpose.

3.15 Manual consolidation of events

Based on the Events occurred through manual monitoring, the IS Manager does manual consolidation.

3.16 Trigger alerts
Whenever an event occurs, the monitoring tools generate alert notifications. Separate monitoring tools are
configured to generate alerts for critical and non-critical systems

3.17 Correlate events

• All the events arising out of monitoring tools (for both critical and non-critical applications and servers) and manual monitoring are correlated.
• The decision on the significance and what actions need to be taken to deal with the events based on business rules is determined as a part of correlation.
• Correlation will take into account previous occurrences of the similar or related events, the CIs involved, component involvement in the event to arrive at the decision.

3.18 Enrichment process

• Event Management tool/team uses industry standard activities such as event correlation, suppression and
  aggregation; collectively known as “Event Enrichment”:
• Event Suppression: Event suppression is about ignoring events that are generated due to a higher-level
  event, thus significantly reducing the number of events that the monitoring team will handle.
• Event Correlation: The event correlation activity automatically clears active and related events,
  resulting in monitoring staff not having to manually clear all the related events.
• Event Aggregation: Event aggregation activity, also known as event de-duplication, is where duplicates
  of the same event are merged.

3.19 Type of event

Based on the event type ,XXX monitoring teams will transfer to the respective resolver groups. Events can be classified into:
3.19.1 Informational:

• An Informational event refers to an event which does not require any action. These events are the results of status checks of devices or services or confirmation of an activity.
• As the incidents created through the informational events do not affect the service, the Monitoring Group closes these incidents with “Status Reason” as “No action required”.

3.19.2 Warning:

• Warnings are generated when a service or device is approaching a predefined threshold. These are used to notify the appropriate person, process or tool so that corresponding action can be taken.
• As the incidents created through warnings may or may not impact the service, the Monitoring Group alerts the respective Resolver Group for appropriate action.

3.19.3 Exception:

An Exceptional event gets triggered in case an application service fails, or configuration item does not function normally. They may represent total failure, impaired functionality or degraded performance.

3.20 Inform the right resolver group

For those incidents that arise out of exception events, the monitoring group assigns them to the appropriate resolver group in service desk and informs the stakeholders/ incident manager.

3.21 Initiate preventive action

The Resolver Group will take the appropriate actions to prevent incidents from occurring. The action taken may trigger the availability and/or capacity management processes.

3.22 Update event log

• The preventive action initiated by the Resolver Group may or may not be effective.
• If it is not effective treat the event as an Incident and trigger the predefined Incident Management process.
• If the type of incident is either an exception or the actions taken in response to the warning event are
  not effective, then the predefined Incident Management process is triggered.
• The outcome of Incident Management may trigger Problem Management or Change Management. The
  output from all this process will be checked for effectiveness.
• If the action taken is effective, the event ticket is updated with actions taken

3.23 Close the event

The event related incident will be updated and closed

1.0 Purpose:

Non-disclosure agreements are contracts intended to protect information considered to be sensitive or confidential. Information technology resources shall be used only for intended purposes as defined by XXX and in compliance with applicable laws. All individuals are accountable for their actions relating to information technology resources and shall formally acknowledge that they will comply with the XXX security policies and procedures or they shall not be granted access to information technology resources. All employees will complete a non-disclosure agreement for information technology resources on an annual basis.

2.0 Scope:

The Non-Disclosure Agreement Policy applies to all authorized users who utilize XXX’s information technology resources (including, but not limited to, Employees, workers, temporary employees, vendors, consultants, employees of independent contractors, and visitors.)

3.0 Confidentiality

All employees/ workers/ temporary employees/ vendors/ consultants/ employees of independent contractors, must, from the date of the commencement of employment or other form of engagement, and thereafter, observe strict confidentiality in respect of any information held by the practice, and by each individual working on behalf of the practice. This includes dealings, transactions, procedures, policies, decisions, systems and other matters of a confidential nature concerning the practice and its affairs.
Other than in the proper course of their duties, employee must not, either during or at any time after the termination of their employment, exploit or disclose confidential information. Also, they must not, through negligence, wilful misconduct or inadvertence, allow the use, exploitation or disclosure of any confidential information relating to the affairs of the practice, processes, technology,customers, products , partners, employees, contractors, business partners or suppliers. There must be no attempt to use any confidential information in a manner that may either directly or indirectly cause, or be calculated to cause loss to the business, reputation or compromise Information security.

Non-disclosure of information
It is an obligation upon all employees during employment, or engaged under other contractual arrangements, to maintain information in confidence and not, directly or indirectly, disclose it other than for the purposes it was gathered. Any such information in the possession of an individual, either in electronic format or hard copy, shall be returned to the practice before or at the point in time that employment/contract ceases, however such cessation occurs.
Following the cessation of employment, or other contractual engagement , an individual must not, directly or indirectly, use for gain, discuss or pass on to others confidential information that can be classed as objective knowledge in that it has been gained during the course of employment. This includes information relating to partners, employees, contractors, customers, business, associates, suppliers, market information, contractual arrangements, dealings, transactions, policies, procedures, decisions, technology and systems or other matters of a confidential nature concerning the practice.

Third-party requests for information
Any employee approached by any third party, including any media source, and asked to make any comments or provide any information relating to the practice and its affairs (or the affairs of its customer, partners, employees, contractors or any business associate) must under no circumstances respond without having sought permission and guidance from the practice manager.

Whistle-blowing or protected disclosures
Nothing in this policy will prevent or limit an employee in making a protected disclosure under the practice’s whistle-blowing policy, in respect of any malpractice or unlawful conduct.

Non-disclosure agreement
All persons engaged to work for and on behalf of the practice will be required to sign the following nondisclosure agreement, which will be recorded on their personnel file.

CONFIDENTIALITY AND NON-DISCLOSURE AGREEMENT

To be signed by any individual employed or otherwise engaged by the practice.
I acknowledge that I have read and understood the confidentiality and non-disclosure policy, dated …………. issued by the practice and I agree to abide by that policy.

Signed:

Dated:

Name:

Purpose

To ensure that information security is designed and implemented within the development life cycle for applications and information systems.

Scope

All XXX applications and information systems that are business critical and/or process, store, or transmit sensitive data. This policy applies to all internal and external engineers and developers of XXX software and infrastructure.

Secure Software and System Development Policy

1 Data Storage

Personal Data information and its availability. It describes procedures for the secure storage of information in databases. It details the management of access permissions and distribution of passwords to be adopted for the operationalization of these structures.

1.1 Procedures and Media for Data Storage

You should not use a storage medium that does not have access for reading and writing restricted by password. You should preferably store encrypted data.

1.2 Permissions for Accessing Information in Databases

• Applications should not have access to any database utilizing a user login with root permissions.
• Applications should not have access to any database utilizing a user login with permissions to execute commands in Data Definition Language (DDL).
• Applications should not have access to any database utilizing a user login with permissions beyond those strictly necessary for its operation.

1.3 Password Management and Distribution for Data Access

• The creation of passwords that do not follow the standards established by Epimed Solutions should not be allowed. Passwords must have at least 6 (six) alphanumeric characters, using special characters (@ # $%).
• Password storage in source code should not be used.
• User data and systems using each password provided must be securely stored.
• The same passwords should not be used for development, testing, homologation and production environments.

2 – Password Management and Distribution of Data Access

2.1 Authorization and Authentication of Users

• Passwords should not be stored in plain text without using a salted secure hash algorithm.
• Nominal user and password control must be used to determine the user’s identity.
• Authentication via AD should be used whenever possible to authenticate internal users.
• Users must be made aware of the permissions and levels of access they have.
• Active Directory (AD) groups should be used to determine access policies and user roles.

2.2 Authentication on Web Systems

Since HTTP is a stateless protocol, which uses cookies to maintain user sessions, it is necessary to guarantee both the security of the exchange of credentials and also that of other pages accessed by users of web systems. The HTTPS protocol aims to contribute to ensuring that security is guaranteed.Thus, HTTPS must be used in all system screens

3 – Secure communication

This deal with the secure transmission of Sensitive Personal Data between systems, in order to safeguard the integrity, authenticity and other attributes pertinent to the use of communicated data. A communication channel with control of duplication and loss of information/messages must be used. Thus, HTTPS must be used in all system screens. A communication channel that provides integrity control of transmitted data (HTTPS) must be used. A communication channel with authentication control (HTTPS, digital certificates generated by trusted authorities, VPNs) must be used. The data to be transmitted at both ends of the communication must be securely stored. A communication channel that provides confidentiality of the transmitted data (HTTPS and VPNs) must be used.

4 – Attacks on Systems and their Defenses

It is recommended that the main known attacks be prevented, in order to prevent malicious attacks from compromising the security of the system, exposing Sensitive Personal Data and performing unauthorized operations, among other possible vulnerabilities.

• SQL injection attacks (SQL Injection) must be prevented.
• SQLs should not be created by concatenating textual parameters from non-secure sources, such as parameters filled in by users or even stored in the database.
• Access permissions to the database for application users must be restricted.
• It is necessary, whenever possible, to pass parameters in SQL commands (DML or DDL) using prepared statements. Queries that cannot be parameterized should receive special treatment, such as escapes or hexadecimal coding.
• HTML and Javascript injection attacks must be prevented.
• Cross-site scripting (XSS) attacks should be prevented.
• Broken Authentication and Session Management attacks must be prevented.
• Systems must be subjected to intrusion testing tools.

5 – Auditing, Tracking and Logs

This section presents guidelines for the maintenance of records/logs for subsequent auditing, tracking and consultation of incidents related to system security. Each system has a different criticality in terms of data access restriction, non-repudiation and history of operations carried out in the database. For this reason, this section does not define what information should be audited, but rather suggests possible items that can be audited, tracked or logged. These items, then, must be evaluated by product managers.

Examples of events that can be logged:

• Login and logout operations;
• Access to certain screens or sections of the system;
• Access to information with some restrictions (For example: confidential documents, personal data);
• Operations for the inclusion, alteration or deletion of records in the database;
• Change of access profile (for systems that have access with different profiles);
• Execution of jobs and automated tasks.

Examples of information that can be stored, related to each event:

• Date and time;
• User who performed the operation;
• IP address;
• User session identifier (when applicable, for example: cookies);
• Screen (page) of the system in which the operation was performed;
• Instance identifier (for clustered systems);
• For insertion, alteration or deletion operations, the type of operation, name of the table that was manipulated, record ID and, if applicable, previous and current values for each field;
• Parameters informed by the user (Examples: GET or POST parameters), being careful not to store Sensitive Personal Data, such as passwords;
• System response time;
• To execute jobs and automated tasks, store the result of the operation; failure, success, cancelation, etc.

6 – Prevention, Reaction, and Mitigation of security Breaches.

6.1 Backups

• The specification of the need and the assignment of the responsibility for making backups of the database and of the system source codes, as well as the access policies for this backup, must be included in the project plan.
• A structured procedure for restoring backups must be defined.
• Personnel in charge of the recovery of backups must be properly designated and trained.
• Baselines of the system versions must be created, facilitating the agile recovery to a previous version.
• Simulation of data restoration must be carried out continuously.

6.2 Tests

• Manual security tests must be carried out before each version of the software that changes its structure (login screens, unauthenticated services, new forms with user interaction, etc.).
• It must be ensured, through automated tests, that the services and confidential data are protected and available only to the users who hold the information.
• A specific testing policy must be developed, whether automated or not, aiming at guaranteeing non-vulnerability to the main known attacks on systems.
• Test scenarios should be defined to guarantee the non-functional software requirements, preferably carried out by a test team different from the software development team, in order to avoid bias.
• Test scenarios should be defined, mainly in terms of security, for cases of updates to the system architecture (application servers, database, browser versions, operating system versions, etc.).

6.3 Incidents

• A planned procedure must be maintained for immediate system unavailability and corrective maintenance.
• A specific policy to foster the follow-up on security breach incident response must be defined.
• Lessons learned from past incidents should be used to review the testing policy and increase system security.

7 – Development Environment .

Security is a requirement that must be included within every phase of a system development life cycle.  A system development life cycle that includes formally defined security activities within its phases is known as a secure SDLC. Per the Information Security Policy, a secure SDLC must be utilized in the development of all applications and systems. At a minimum, an SDLC must contain the following security activities. These activities must be documented or referenced within an associated information security plan. Documentation must be sufficiently detailed to demonstrate the extent to which each security activity is applied. The documentation must be retained for auditing purposes.

1.  Define Security Roles and Responsibilities
2.  Orient Staff to the SDLC Security Tasks
3.  Establish a System Criticality Level
4.  Classify Information
5.  Establish System Identity Credential Requirements
6.  Establish System Security Profile Objectives
7.  Create a System Profile
8.  Decompose the System
9.  Assess Vulnerabilities and Threats
10.  Assess Risks
11.  Select and Document Security Controls
12.  Create Test Data
13.  Test Security Controls
14.  Perform Certification and Accreditation
15.  Manage and Control Change
16.  Measure Security Compliance
17.  Perform System Disposal

There is not necessarily a one-to-one correspondence between security activities and SDLC phases. Security activities often need to be performed iteratively as a project progresses or cycles through the SDLC. Unless stated otherwise, the placement of security activities within the SDLC may vary in accordance with the SDLC being utilized and the security needs of the application or system.. Finally, it is important to note that the Secure SDLC process is comprehensive by intention, to assure due-diligence, compliance, and proper documentation of security-related controls and considerations. Designing security into systems requires an investment of time and resources. The extent to which security is applied to the SDLC process should be commensurate with the classification (data sensitivity and system criticality) of the system being developed and risks this system may introduce into the overall environment.  This assures value to the development process and deliverable.  Generally speaking, the best return on investment is achieved by rigorously applying security within the SDLC process to high risk/high cost projects. Where it is determined that a project will not leverage the full Secure SDLC  process – for example, on a lower-risk/cost project, the rationale must be documented, and the security activities that are not used must be identified and approved as part of the formal risk acceptance process.

Note: Data classification cannot be used as the sole determinate of whether or not the project is low risk/cost.  For example, public facing websites cannot be considered low risk/cost projects even if all the data is public.  There is a risk of compromise of the website to inject malware and compromise visitor’s machines or to change the content of the website to create embarrassment.

7.1 Source Code Access

A version control system with access control and recovery in case of failures must be used. (For example: Microsoft Team Foundation Server).

7.2 Separation of Environments

• The Development/Testing/Homologation environments must be separated from the Production environment.
• Different databases must be used for each environment.
• Different application/web servers must be used for each environment.
• Access to the Development/Testing/Homologation environment should only be provided to members of the development team and to those interested in the project (stakeholders).
• Periodic tests must be carried out to ensure the security of the development/testing/homologation environment.
• Developers should not be provided with passwords to access the production environment.

8 – Data Protection

8.1 Cryptography and Hashing

• A cryptographic method that follows the Kerckhoffs’ Principle should be used. The encryption method and its parameters must be public and documented, only the cryptographic key must be kept confidential.
• An encryption that admits a known method for breaking the cryptographic key (brute force), based on trial and error, should not be used.
• Electronic codebook (ECB) block encryption mode or less secure modes should not be used.
• A key size of less than 128 bits (symmetric encryption) or 1024 bits (asymmetric encryption) should not be used.
• The hash function should not be used without some type of salt.
• Algorithms that are considered obsolete for cryptography and cryptographic hashing should not be used. Examples: MD5, SHA1, DES/3DES, RC2, RC4, MD4.
• A key size of less than 192 bits (symmetric encryption) or 2048 bits (asymmetric encryption) should not be used.
• Cryptographic keys should not be distributed without the use of a public key infrastructure and, therefore, without the use of asymmetric encryption.
• A key size of less than 256 bits (symmetric encryption) or 4096 bits (asymmetric encryption) should not be used.

8.2 Passwords

• Password size: Passwords with less than 6 characters should not be used.
• Variation of symbols: At least upper and lower case letters must be used, together with at least one type of character (digit, symbol).
• Randomness: Passwords should not be created without the aid of random password generator software, configured to meet the parameters established below:
• Tests: You should not use a password that has not been validated by password strength checker software.
• Change frequency: Same passwords should not be used for more than 6 months.
• Password change and recovery: The use of the same password validation channel should not be allowed. The old password should not be sent to users, under no circumstances.
• Storage (user): You should not store a password that is not encrypted following the standard level of encryption set out in this document.
• Number of attempts: Password validation rate should not be allowed to exceed 5 attempts per minute. Passwords must be blocked in case of a maximum of 5 consecutive validation errors and its recovery must rely on a specific process.

9 – Software Life cycle

9.1 Design

• The software design model should include the following:
• Threat modeling stage;
• Clear definition of security risks;
• Severity level that the compromise of Sensitive Personal Data would bring to the system and institution.
• It should not be omitted, during the system development design and its execution, the definition of responsibilities for system data security and how this responsibility will be verified.
• A design schedule that includes security check points of the system developed during its construction must be used.

9.2 Coding

Protective measures applied in the source code must be documented, including in the application code, in order to indicate precisely the procedure used and its peculiarities.

9.3 Maintenance

• Automatic updates of software or components used in the construction of a system should not be enabled, otherwise security breaches may, inadvertently, come up.
• Third party software should not be modified, except when strictly necessary. Internal security controls can be invalidated. This change should be made by the original system developer whenever possible.

9.4 Personnel

Training and qualification of programmers should be provided for the acquisition and review of computer security principles and the development of secure software.

10. Framework for development of Software and System

10.1 Prepare the Organization

1 Define Security Requirements for Software Development

• Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.
• Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.
• Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software.

2 Implement Roles and Responsibilities

• Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC. Periodically review and maintain the defined roles and responsibilities, updating them as needed.
• Provide role-based training for all personnel with responsibilities that contribute to secure development. Periodically review personnel proficiency and role-based training, and update the training as needed.
• Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with development- related roles and responsibilities.

3 Implement Supporting Tool chains

• Specify which tools or tool types must or should be included in each tool chain to mitigate identified risks, as well as how the tool chain components are to be integrated with each other.
• Follow recommended security practices to deploy, operate, and maintain tools and toolchains.
• Configure tools to generate artifacts of their support of secure software development practices as defined by the organization.

4 Define and Use Criteria for Software Security Checks

• Define criteria for software security checks and track throughout the SDLC.
• Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.

5 Implement and Maintain Secure Environments for Software Development

• Separate and protect each environment involved in software development
• Secure and harden development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach.

10.2 Protect Software

1 Protect All Forms of Code from Unauthorized Access and Tampering

• Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

2 Provide a Mechanism for Verifying Software Release Integrity

• Make software integrity verification information available to software acquirers.

3 Archive and Protect Each Software Release

• Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.
• Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).

10.3 Produce Well-Secured Software

1.Design Software to Meet Security Requirements and Mitigate Security Risks

• Use forms of risk modeling – such as threat modeling, attack modeling, or attack surface mapping – to help assess the security risk for the software.
• Track and maintain the software’s security requirements, risks, and design decisions.
• Where appropriate, build in support for using standardized security features and services (e.g., enabling software to integrate with existing log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security features and services.

2. Review the Software Design to Verify Compliance with Security Requirements and Risk Information

• Have 1) a qualified person (or people) who were not involved with the design and/or 2) automated processes instantiated in the tool chain review the software design to confirm and enforce that it meets all of the security requirements and satisfactorily addresses the identified risk information.

3. Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality

• Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, open- source, and other third-party developers for use by the organization’s software.
• Create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components.
• Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles.

4. Create Source Code by Adhering to Secure Coding Practices

• Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements.

5. Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security

• Use compiler , interpreter and build tools that offer features to improve executable security.
• Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations.

6. Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements

• Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization.
• Perform the code review and/or code analysis based on the organization’s secure coding policy, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.

7. Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements

• Determine whether executable code testing should be performed to find vulnerabilities not identified by previous reviews, analysis, or testing and, if so, which types of testing should be used.
• Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediation in the development team’s workflow or issue tracking system.

8. Configure Software to Have Secure Settings by Default

• Define a secure baseline by determining how to configure each setting that has an effect on security or a security-related setting so that the default settings are secure and do not weaken the security functions provided by the platform, network infrastructure, or services
• Implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators.

Respond to Vulnerabilities

1.Identify and Confirm Vulnerabilities on an Ongoing Basis

• Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports.
• Review, analyze, and/or test the software’s code to identify or confirm the presence of previously undetected vulnerabilities.
• Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support that policy.

2. Assess, Prioritize, and Remediate Vulnerabilities

• Analyze each vulnerability to gather sufficient information about risk to plan its remediation or other risk response.
• Plan and implement risk responses for vulnerabilities.

3. Analyze Vulnerabilities to Identify Their Root Causes

• Analyze identified vulnerabilities to determine their root causes.
• Analyze the root causes over time to identify patterns, such as a particular secure coding practice not being followed consistently.
• Review the software for similar vulnerabilities to eradicate a class of vulnerabilities, and proactively fix them rather than waiting for external reports.
• Review the SDLC process, and update it if appropriate to prevent (or reduce the likelihood of) the root cause recurring in updates to the software or in new software that is created.

1.0 Introduction

1. This document states the procedures required for creating and maintaining a secure environment for the storage and dissemination of information at Information Processing Facilities.
   • It is critical that all the staffs at Information processing facilities are fully aware of the Policy, procedures, guidelines and best practices and commit to protecting the information of the XXX. Common sense and high ethical standards are required to complement the Procedure.
   • The procedures outlined represent the minimum security levels required at the Information Processing Facilities and must be used along with the  detailed security plan and additional policies

1.1 Background

1. This procedures applies to XXX’s Information processing facilities and are inclusive of their hardware facilities, software installations, and communication networks as well as information.
2. CISO has, among other responsibilities, the mandate to establish this procedure for information security and internal controls as well as contingency planning and disaster recovery at Information Processing facilities.

1.2 Audience

The procedures are for distribution to XXX’s Information Processing Facilities through their respective Security Representative who will then be responsible for communicating the details to XXX’s employees as well as contractors or other entities whose position responsibilities include the creation, maintenance, or access of XXX’s information residing on any computer system or platform.

2.0  Information

Management of information requires a working set of procedures that provide guidance and direction with regards to security. The primary focus is on the confidentiality and integrity of the information required for delivering information throughout the Organization.

2.1 Information Confidentiality

1. The overriding premise is that all information hosted or created at XXX’s Information Processing Facilities is property of the XXX. As such, this information will be used solely for performance of position related duties. Any transfers or disclosures are governed by this rule.
2. The confidentiality of all information created or hosted by XXX’s Information Processing Facilities is the responsibility of all XXX’s employees. Disclosure is governed by legislation, regulatory protections, rules as well as policies and procedures of the XXX and of the owning XXX. The highest of ethical standards are required    to prevent the inappropriate transfer of sensitive or confidential information.
3. Release of information is strictly for job related functions. Confidentiality is compromised when knowingly or inadvertently, information crosses the boundaries of job related activities.
4. Users must be required to follow good security practices in the selection and use of passwords. Passwords provide a means of validating a user’s identity and thereby establish access rights to information processing facilities or services. All agency staff must be advised to:
   • keep passwords confidential,
   • avoid keeping a paper record of passwords, unless this can be stored securely,
   • change passwords whenever there is any indication of possible system or password compromise,
   • select quality passwords with a minimum length of eight characters which are:
     • easy to remember,
     • not based on anything somebody else could easily guess or obtain using person related information, e.g. names, telephone numbers and dates of birth etc.,
     • free of consecutive identical characters or all-numeric or all- alphabetical groups,
   • change passwords at regular intervals (passwords for privileged accounts should be changed more frequently than normal passwords),
   • avoid reusing or cycling old passwords,
   • change temporary passwords at the first log-on,
   • not include passwords in any automated log-on process, e.g. stored in a macro or function key, and

2.2 Information Content

1. All information content hosted by XXX’s Information Processing Facilities is owned by and is the primary responsibility of the Facility in charge responsible for collecting and maintaining the authenticity, integrity and accuracy of information. The objective of the owning XXX’s Information Processing Facilities is to protect the information from inadvertent or intentional damage as well as unauthorized disclosure or use according to the classification standards and procedural guidelines of the owning XXX.
2. The following procedures must be followed by all staff at XXX’s Information Processing Facilities:
   • All information content must reflect the actual state of affairs of the Information Processing Facilities. Changes in the status of personnel who have system access are entered in the system immediately and the appropriate authorization / change form sent to the hosting Security Administration.

2.3 Information Access

1.Information access is subject to Access Control Policy and to the appropriate approval processes of the XXX. The Facilities in charge is responsible for maintaining current and accurate access authorities and communicating these in an agreed upon manner to the security function at the XXX’s Information Processing Facilities hosting the information.

2. XXX has a designated a security representative whose role includes:

• communicating the information security Policy to all their respective a employees,
• Communicating the appropriate procedures to the responsible user, owner, or people directly responsible for hosting   activities at Information Processing Facilities.
• granting user access to system functions, and
• reporting all deviations to the Policy, procedure.

3. Procedures for the Security Administration function are:

• Confirm set up to the Director and the individual concerned via  email when the set-up is complete for the role of Security Representative.
• Confirm set up to the Security Representative and the individual concerned when the set-up is complete for the use roles assigned.
• A daily report will be run by the dept. to list terminations. Security Administration will lock the access privileges at the end of day on the effective date. This does not preclude the responsibility of Facility in charge to notify the HR of terminations using agreed upon formal notice or by the phone and/or email in the case of dismissals.
• The HR dept. will run a weekly report of transfers and follow up with the Facility in charge concerned if a change notification is not received.
• Users not using the system for 60 days will be automatically deactivated. Security Administration will notify the Facility Head and will require an email or new activation form from the user dept.’s security representative to reactivate the individual.

4. The Facility in charge has the responsibility to adhere to procedures and put   into effect all authorized changes received from the CISO in a timely manner.

2.4 Information Security

1. The facility in charge collects and maintains (owns) the information is responsible for interpreting all confidentiality restrictions as well as establishing information classification and approving information access. It will staff a Security Administration  function whose responsibility will be operational control and timely implementation of access privileges.
2. System limitations may prevent all of the following procedures to be implemented, however, when possible, these rules apply:
   • Passwords will be required to be a minimum of 8 characters long, containing at least one (1) numeric character.
   • Passwords will expire in a maximum of 90 days.
   • Passwords will be deactivated if not used for a period of 60 days.

3. Employees that access the systems have the responsibility to protect the confidentiality of information which they use in the course of their assigned duties.

2.5  Information Availability

Information availability is the responsibility of the employees. Access to information will be granted as needed to all employees to support their required processes, functions and timelines. Proven backup and recovery procedures for all information elements to cover the possible loss or corruption of system data are the responsibility of the hosting employees. Required availability will vary with normal cycles of use (i.e. information is used constantly throughout the day, but is only periodically accessed during the evening by a backup process, becomes archival after the backup is complete). The following asset availability definitions should include a statement detailing over what time period the definition is accurate for (i.e. Constant during business hours, archival after year-end, etc.):

Availability	Frequency of Use	Loss / Absence Impact
Constant	Accessed at all times	Immediate cessation of supported business functions
Regular	Accessed   intermittently   by 1 individual but constantly by all users as a group    (i.e. email)	Interruption or degradation, but not cessation, of supported business functions
Periodic	Accessed intermittently, or on 1 a schedule (i.e. year-end records)	Delay of  supported  business functions
Archival	Not normally accessible	Disruption of business support objectives

The Facilities Security in charge will be responsible for:

1. publishing a Service Level Agreement for all users of the system including response time, hours of availability and all other services contracted,
2. ensuring all backups are current, secure and accessible,
3. ensuring information facilities and data can be recovered, and
4. ensuring adequate technical support for systems, data base access and operating systems.

3. Incident Management

1.Incident management responsibilities and procedures must be established by the CISO and its associates to ensure a quick, effective and orderly response to security incidents. Procedures must be established to cover all potential types of security incidents, including:

(A) information system failures and loss of service,
(B) denial of service,
(C) errors resulting from incomplete or inaccurate business information, and
(D) breaches of confidentiality.

2.In addition to normal contingency plans (designed to recover systems or services as quickly as possible), the procedures must also cover:
(A) analysis and identification of the cause of the incident,
(B) planning and implementation of remedies to prevent recurrence, if necessary,
(C) collection of audit trails and similar evidence,
(D) communication with those affected by or involved with recovery from the incident, and
(E) reporting the action to the security administration function at the hosting agency.

3.Audit trails and similar evidence must be collected and secured as appropriate, for:
(A) internal problem analysis,
(B) use as evidence in relation to a potential breach of contracts, policies, or regulatory requirements,
(C) use in the event of civil or criminal proceedings, e.g. under computer misuse or information protection, and
(D) use in negotiating for compensation from software and service suppliers.

4. Action to recover from security breaches and correct system failures should be carefully and formally controlled. The procedures must ensure that:
(A) only clearly identified and authorized staff are allowed access to live systems and information,
(B) all emergency actions taken are documented in detail,
(C) emergency action is reported to management and reviewed in an orderly manner, and
(D) the integrity of business systems and controls is confirmed with minimal delay.

4. Event Logging and Monitoring

1.Audit logs recording exceptions and other security-relevant events must be produced and kept for an agreed period to assist in future investigations and access control monitoring. Audit logs should include:

• user IDs,
• dates and times for log-on and log-off,
• terminal identity or location if possible,
• records of successful and rejected system access attempts, and
• records of successful and rejected data and other resource access attempts.

2. Certain audit logs may be required to be archived as part of the record retention procedures or because of requirements to collect evidence.

3. Procedures for monitoring use of information processing facilities must be established and the result of the monitoring activities reviewed regularly. Such procedures are necessary to ensure that users are only performing activities that have been explicitly authorized. The level of monitoring required for individual facilities should be determined by a risk assessment. Areas that should be considered include:

1. Authorized access, including detail such as:
   • the user ID,
   • the date and time of key events,
   • the types of events,
   • the files accessed, and
   • the program/utilities used.
2. All privileged operations, such as:
   • use of supervisor account,
   • system start-up and stop, and
   • I/O device attachment/detachment.
3. Unauthorized access attempts, such as:
   • failed attempts,
   • access procedure violations and notifications for network gateways and firewalls, and
   • alerts from proprietary intrusion detection systems.
4. System alerts or failures such as:
   • console alerts or messages,
   • system log exceptions, and
   • network management alarms.

5. Risk Management

Risk management encompasses risk assessment, risk mitigation as well as evaluation and assessment. The risk assessment process includes identification and evaluation of risks and risk impacts and recommendation of risk-reducing measures. Risk mitigation refers to prioritizing, implementing and maintaining the appropriate risk-reducing measures recommended from the risk assessment process. Through a continual evaluation process, the facility in charge is responsible for determining whether the remaining risk is at an acceptable level or whether additional security controls should be implemented to further reduce or eliminate the residual risk.

5.1 Risk Assessment

1. The Facility in charge will be responsible for determining the likelihood of an adverse event, the threats to system resources, the vulnerability of the system and the impact such an adverse event may have.
2. To determine the likelihood of an adverse event, consider:
   • Motivation
   • Nature of the vulnerability
   • Current controls
3. A threat needs, and cannot exist without a vulnerability. A vulnerability is a weakness that can be intentionally or accidentally triggered. Threats can be posed from a lot of sources, some of which are:
   • System Intruders (hackers)
   • Criminals
   • Terrorists
   • Espionage
   • Insiders which could be malicious or a result of poor training
4. In identifying the vulnerabilities, consideration must be given to:
   • Hardware
   • Software
   • Network
   • System Interfaces
   • Data and information
   • People who support and use the system.
   • Information sensitivity
5. The impact of an adverse event is the:
   • Loss of Integrity
   • Loss of Availability
   • Loss of Confidentiality

5.2 Risk Mitigation

Facility in charge is responsible for reducing risk to all information assets. The following are options provided in analyzing the alternatives.

1. Risk Assumption. To accept the potential risk and continue operating the IT system or to implement controls to lower the risk to an acceptable level.
2. Risk Avoidance. To avoid the risk by eliminating the risk cause and/or consequence (e.g., forgo certain functions of the system or shut down the system when risks are identified).
3. Risk Limitation. To limit the risk by implementing controls that minimizes the adverse impact of a threat exercising a vulnerability (e.g., use of supporting, preventive, detective controls).
4. Risk Planning. To manage risk by developing a risk mitigation plan that prioritizes, implements and maintains controls.
5. Research and Acknowledgment. To lower the risk of loss by acknowledging the vulnerability or flaw and researching controls to correct the vulnerability.
6. Risk Transference. To transfer the risk by using other options to compensate for the loss, such as purchasing insurance.

6.0 Personnel/ User Issues

1. Personnel awareness of the information security Policy, procedures, guidelines and best practices is the responsibility of all employees. Adherence to the Policy, procedures, guidelines and best practices is the responsibility of Facility in charge on behalf of the employees.
2. Information security must be adopted at all levels as a “norm” of job performance. Information systems and data are vulnerable. With constant re-enforcement and monitoring, individuals will accept their responsibility to protect the information assets of the State and relate their performance in this area to standards of performance.
3. The IT staff must be alert and trained in offensive and defensive methods to protect the information assets. Adequate staffing and key position backup are essential to run and maintain a secure environment.

6.1 Staffing

Adequate staffing, training and backup are the responsibility of facility in charge. Facility in charge will be responsible for

1. ensuring qualifications meet position requirements,
2. identifying roles that will impact operations when not filled, i.e. if the incumbent leaves or cannot perform the function,
3. ensuring training is in place to keep key individuals current with the technology available in the marketplace (this is particularly important with regards to the Internet and data base controls), and
4. documenting contingency plans if critical functions are not available.

6.2 Awareness/ Training

1.The purpose of awareness presentations are simply to focus attention on security and are intended to allow individuals to recognize IT security concerns and respond accordingly. Awareness relies on reaching broad audiences, whereas training is more formal, having a goal of building knowledge and skills to facilitate job performance.

2.Effective IT security awareness presentations must be designed. Awareness presentations must be on-going, creative and motivational, with the objective of focusing attention so that the learning will be incorporated into conscious decision- making.

3.The CSIO will be responsible for:

• communicating the minimum standards for all related policies and procedures,
• providing recommendations for best practices in selected areas related to information security, and
• providing all necessary information for the development of an awareness program

4.Facility in charge will:

• create and present security awareness sessions for their staff members, and
• ensure all staff members have attended an awareness session.

5.All current employees as well as new employees or contractors when hired that have access to any information assets must be briefed by the Facility in charge as follows:

• the access requirements of their position or contract,
• their responsibilities for safeguarding sensitive information and assets,
• all information security policies, procedures, guidelines and best practices, and
• a written document outlining the contents of the briefing and the date, which should be signed by the individual briefed acknowledging receipt of its contents.

6.3 Personal Computer Usage

1.All users are given access to computers and other equipment at Information Processing Facilities for job related duties and this usage must remain in compliance with XXX’s policies as well as all laws governing usage and communication of information. Failure to comply will result in the denial of access privileges and may for employees lead to disciplinary action up to and including dismissal. For contractors, it may lead to the cancellation of the contractual agreement. Litigation may ensue.

2. In the effort to protect the integrity of the network and its systems, any proof of unauthorized or illegal use of any computer and/or its accounts will warrant the immediate access to these files, accounts and/or systems by the
security and information systems staff and appropriate action will be taken.

3.Information Security Policy for computer usage prohibits the use of its resources to:

• Send email using someone else’s identity (Email forgery).
• Take any action that knowingly will interfere with the normal operation of the network, its systems, peripherals and/or access to external networks.
• Install any system or software on the network without prior approval.
• Install any software systems or hardware that will knowingly install a virus, Trojan horse, worm or any other known or unknown destructive mechanism.
• Attempt IP spoofing.
• Attempt the unauthorized downloading, posting or dissemination of copyrighted materials.
• Attempt any unauthorized downloading of software from the Internet.
• Transmit personal comments or statements in a manner that may be mistaken as the position of the XXX.
• Access, create, transmit (send or receive), print or download material that is discriminatory, derogatory, defamatory, obscene, sexually explicit, offensive or harassing based on gender, race, religion, national origin, ancestry, age, disability, medical condition, sexual orientation or any other status protected by state laws.

4. Furthermore, it is the XXX’s position that all messages sent and received, including personal messages and all information stored on the electronic mail system, voicemail system or computer systems are XXX property regardless of the content. As such, it reserves the right to access, inspect and monitor the usage of all of its technology resources including any files or messages stored on those resources at any time, in its sole discretion, in order to determine compliance with its policies, for purposes of legal proceedings, to investigate misconduct, to locate information or for any other business purpose.

6.4 Email Usage

1. Electronic mail (email) is a highly efficient form of modern communication media. Used appropriately, email provides people with a means to communicate thereby facilitating business contact. However, this convenience also tempts users to experiment or take advantage of this media, resulting in email of unwelcome types (collectively known along with other unwelcome activity as Net Abuse). The improper use of this email technology may jeopardize systems integrity, security and service levels. Access to email is provided to users to assist them to perform their work and their use of email must not jeopardize operation of the system or the reputation and/or integrity of the XXX.

2. Email accounts are made available to all staff that require the service for the performance of job related functions. The following statements apply:

• All email and associated system resources are the property of the XXX. Email is subject to the restrictions on its use and the review process as per policy of Access control. Its use and content may be monitored.
• Users must comply with all applicable legislation, regulations, policies and standards. This includes complying with copyright and license provisions with respect to both programs and data.
• While email is provided as a business tool to users, its reasonable, incidental use for personal purposes is acceptable. This use must not, however, detrimentally affect employee productivity, disrupt the system and/or harm the XXX’s reputation.

3. Users may not:

• use email for commercial solicitation or for conducting or pursuing their own business interests or those of another organization,
• use email to distribute hoaxes, chain letters or advertisements and/or send rude, obscene, threatening or harassing messages,
• use email to distribute pornographic material or hate literature,
• use email to harass other staff members,
• use email to send executable programs or games,
• use email to send potentially offensive material, and
• propagate viruses knowingly or maliciously.

4. Users must not send, forward and/or reply to large distribution lists concerning non-XXX business. In addition, users must consider the impact on the network when creating and using large, work-related distribution lists.

5. Email is a record and therefore management of email must comply with existing legislation, regulations, policies and standards.

6. Alleged inappropriate use of the email technology will be reviewed by the facility in charge on a case by case basis and may lead to disciplinary action up to and including dismissal. In respect to contractors, it may lead to cancellation of the contractual arrangement. In any of the cases, it may lead to litigation.

6.5 Internet/ Intranet security

1.The World Wide Web (WWW) is a system for exchanging information over the Internet. An Intranet is a proprietary network that is specific for our entity.

2.At the most basic level, the Web can be divided in two principal components:Web servers, which are applications that make information available over the Internet (in essence publish information) and Web browsers (clients), which are used to access and display the information stored on the Web servers. The Web server is the most targeted and attacked host on most organizations’ network. As a result, it is essential to secure Web servers and the network infrastructure that
supports them.

3.The specific security threats to Web servers generally fall into one of the following categories:

• Malicious entities may exploit software bugs in the Web server, underlying operating system or active content to gain unauthorized access to the Web server. Examples of unauthorized access are gaining access to files or folders that were not meant to be publicly accessible or executing privileged commands and/or installing software on the Web server.
• Denial of Service attacks may be directed to the Web server denying valid users an ability to use the Web server for the duration of the attack.
• Sensitive information on the Web server may be distributed to unauthorized individuals.
• Sensitive information that is not encrypted when transmitted between the Web server and the browser may be intercepted.
• Information on the Web server may be changed for malicious purposes. Web site defacement is a commonly reported example of this threat.
• Malicious entities may gain unauthorized access to resources elsewhere in the organization’s computer network via a successful attack on the Web server.
• Malicious entities may attack external organizations from a compromised Web server, concealing their actual identities and perhaps making the organization from which the attack was launched liable for damages.
• The server may be used as a distribution point for illegal copies software attack tools, or pornography, perhaps making the organization liable for damages.

4.The Facility in charge is responsible for the Web server. Some examples of controls to protect from unauthorized access or modification are:

• install or enable only necessary services,
• install Web content on a dedicated hard drive or logical partition,
• limit uploads to directories that are not readable by the Web server,
• define a single directory for all external scripts or programs executed as part of Web content,
• disable the use of hard or symbolic links,
• define a complete Web content access matrix that identifies which folders and files within the Web server document directory are restricted and which are accessible (and by whom), and
• use host-based intrusion detection systems and/or file integrity checkers to detect intrusions and verify Web content.

5.Maintaining a secure Web server is the responsibility of the facility in charge and involves the following steps:

• configuring, protecting and analyzing log files,
• backing up critical information frequently,
• maintaining a protected authoritative copy of the organization’s Web content,
• establishing and following procedures for recovering from compromise,
• testing and applying patches in a timely manner, and
• testing security periodically.

6.A firewall environment must be employed to perform the following general functions:

• filter packets and protocols,
• perform inspection of connections,
• perform proxy operations or selected applications,
• monitor traffic allowed or denied by the firewall, and
• provide authentication to users using a form of authentication that does not rely on static, reusable passwords that can be sniffed.

7.The Facility in charge’s responsible for Internet security will:

1. Keep operational systems and applications software up to date. Because software systems are so complex, it is common for security related problems to be discovered only after the software has been in widespread use. Although most vendors try to address known security flaws in a timely manner, there is normally a gap from the time the problem is publicly known, the time the vendor requires to prepare corrections and the time you install the update. This gap gives potential intruders an opportunity to take advantage of this flow and mount an attack on computers and networks. To keep this time interval as short as possible, it is required to stay aware of:
   • announcements of security-related problems that may apply,
   • immediate actions to reduce exposure to the vulnerability, such as disabling the affected software and
   • permanent fixes from vendors.
2. Restrict only essential network services and operating system on the host server.
   • Ensure that only the required set of services and applications are installed on the host server. Either do not install unnecessary services or turn the services off and remove the corresponding files (and any other unnecessary files) from the host.
3. Configure computers for file backup.
4. Protect computers from viruses and programmed threats.
5. Allow only appropriate physical access to computers.
6. Design, implement and monitor an effective firewall system.

7.0 Physical and Environmental Security

1.The Facility in charge has the responsibility for documentation, execution, monitoring and testing of a physical security plan for both computer and telecommunication assets. This physical security plan would evaluate the risks from potential losses due to

• physical destruction or theft of physical assets,
• loss or destruction of information and program files,
• theft of information,
• theft of indirect assets, and
• delay or prevention of computer processing.

2.Included in the plan would be measures for reducing the possibility of a loss and must address:

• changes in the environment to reduce exposure,
• measures to reduce the effect of a threat,
• improved control procedures,
• early detection, and
• contingency plans.

7.1 Operations center

The following are guidelines of the action items for establishing, implementing and maintaining a physical security program at the hosting agency:

• conduct a risk analysis,
• determine local natural disaster probabilities,
• protect supporting utilities.
• ensure computer reliability,
• provide physical protection.
• implement procedural security,
• plan for contingencies,
• develop security awareness, and
• validate the program.

7.2 Operations Monitoring

1.Facility in charge can monitor security effectiveness by comparing performance to the metrics in a service level agreement and incidents that occur in violation of security policies and procedures.

2.Guidelines for hosting agencies in establishing a service level agreement are:

• hours of system availability,
• hours of application system support,
• hours of technical support,
• off hours support,
• average system response time, and
• other metrics as suitable for agency specific applications.

3. Facilities in charge should have a goal of achieving 99.9%+ of the metrics established in the service level agreement. Failure to achieve these targets could be an indication of security breaches.

4. In so far as incidents are concerned, both offensive and defensive actions to protect the security of physical assets should be considered routine. Examples of offensive actions include:

• routine changes of passwords,
• develop an escalation procedure of incidents,
• routine changes of locks or combinations to the facilities,
• have more than one person knowledgeable for critical functions,
• rotate shifts or people between functions,
• monitor all incursion attempts,
• install latest versions of firewall software,
• maintain 24×7 vendor contact list,
• routine backups,
• off-site storage of system information and programs,
• redundant components, lines for critical systems, and
• testing of recovery procedures.

5. Examples of defensive actions include:

• report and action all deviations to security policies and procedures,
• shut down any infected machine immediately,
• disconnect any problem areas from the network,
• revoke privileges of users violating policies,
• assign severity to an issue and escalate, and
• acquire knowledgeable resources.

7.3 Back- Up of Information

Back-up copies of essential business information and software must be taken regularly. Adequate backup facilities should be provided to ensure that all essential business information and software can be recovered following a disaster or media failure. Backup arrangements for individual systems should be regularly tested to ensure that they meet the requirements of business continuity plans. The following controls must be considered:

• A minimum level of back-up information, together with accurate and complete records of the back-up copies and documented restoration procedures, should be stored in a remote location at a sufficient distance to escape any damage from a disaster at the main site. At least three generations or cycles of back-up information should be retained for important business applications.
• Back-up information should be given an appropriate level of physical and environmental protection consistent with the XXX’s Back up policy. The controls applied to media at the main site should be extended to cover the back-up site.
• Back-up media should be regularly tested, where practicable, to ensure that hey can be relied upon for emergency use when necessary.
• Restoration procedures should be regularly checked and tested to ensure that they are effective and that they can be completed within the time allotted in the operational procedures for recovery.
• The retention period for essential business information and also any requirement for archive copies to be permanently retained should be determined.

7.4 Access Control

Logical and physical access controls are required to ensure the integrity of the information and physical assets and should be done at per the XXX’s Access control policy. The following guidelines for controlling logical access should be implemented by the facilities in charge.

• document and adhere to procedures for granting, modifying and revoking access,
• ensure segregation of duties for access
• install detection mechanisms for unauthorized access attempts,
• timeout a session after 15 minutes of inactivity, and
• revoke access after an inactivity period of 60 days.

Physical access control guidelines for all employees include:

1. all telecommunication and computer related equipment are to be in a secured, locked environment,
2. access codes for secure environments must be changed at least every 60 days or in the event of an individual departing that previously had access,
3. account for all keys issued for those facilities using this method and replace locking mechanism when a key is missing,
4. when the system permits, log all accesses and retain, and
5. secure all peripherals such as air conditioning, generators, etc.
6. segregation of duties must be implemented to prevent unauthorized access to systems or data

7.5 Network

1. Unsecured connections to network services can affect the whole organization. Users must only have direct access to the services that they have been specifically authorized to use. This control is particularly important for network connections to sensitive or critical business applications or to users in high-risk locations, e.g. public or external areas that are outside the organization’s security management and control.
2. The use of networks and network services covers:
   • the networks and network services which are allowed to be accessed,
   • authorization for determining who is allowed to access which networks and networked services, and
   • management controls to protect the access to network connections and network services.
3. The path from the user terminal to the computer service must be controlled. Networks are designed to allow maximum scope for a sharing of resources and flexibility of routing. These features may also provide opportunities for unauthorized access to business applications, or unauthorized use of information facilities. Incorporating controls that restrict the route between a user terminal and the computer services its user is authorized to access, e.g. creating an enforced path can reduce such risks. The objective of an enforced path is to prevent any users selecting routes outside the route between the user terminal and the services that the user is authorized to access. This usually requires the implementation of a number of controls at different points in the route. The principle is to limit the routing options at each point in the network, through predefined choices.
4. The following methods should be implemented to limit the path to a service:
   • allocating dedicated lines or telephone numbers,
   • automatically connecting ports to specified application systems or security gateways,
   • limiting menu and submenu options for individual users,
   • preventing unlimited network roaming,
   • enforcing the use of specified application systems and/or security gateways for external network users,
   • actively controlling allowed source to destination communications via security gateways, e.g. firewalls, and
   • restricting network access by setting up separate logical domains, e.g. virtual private networks, for user groups within the organization.
5. External connections provide a potential for unauthorized access to business information, e.g. access by dial-up methods. Therefore, access by remote users must be subject to authentication. There are different types of authentication method, some of these provide a greater level of protection than others, e.g. methods based on the use of cryptographic techniques can provide strong authentication. It is important to determine from a risk assessment the level of protection required. This is needed for the appropriate selection of an authentication method.
   • Authentication of remote users should be achieved using one of the following techniques:
   • a cryptographic based technique,
   • hardware tokens,
   • a challenge/response protocol,
   • dedicated private lines or a network user address checking, and
   • call-back.
6. Dial-back and controls, e.g. using dial-back modems, can provide protection against unauthorized and unwanted connections to an organization’s information processing facilities. This type of control authenticates users trying to establish a connection to an organization’s network from remote locations. When using this control an organization should not use network services which include call forwarding or, if they do, they should disable the use of such features to avoid weaknesses associated with call forwarding. It is also important that the call back process includes ensuring that an actual disconnection on the organization’s side occurs. Otherwise, the remote user could hold the line open pretending that call back verification has occurred. Call back and controls should be thoroughly tested for this possibility.
7. A facility for automatic connection to a remote computer could provide a way of gaining unauthorized access to a business application. Connections to remote computer systems must therefore be authenticated. This is especially important if the connection uses a network that is outside the control of the organization’s security management. Node authentication can serve as an alternative means of authenticating groups of remote users where they are connected to a secure, shared computer facility.
8. Access to diagnostic ports must be securely controlled. Many computers and communication systems are installed with a dial-up remote diagnostic facility for use by maintenance engineers. If unprotected, these diagnostic ports provide a means of unauthorized access. They should therefore be protected by an appropriate security mechanism, e.g. a key lock to ensure that they are only accessible by arrangement.
9. Networks are increasingly being extended beyond traditional organizational boundaries as business partnerships are formed that may require the interconnection or sharing of information processing and networking facilities. Such extensions will increase the risk of unauthorized access to already existing information systems that use the network, some of which might require protection from other network users because of their sensitivity or criticality. In such circumstances, controls must be introduced in networks to segregate groups of information services, users and information systems.
10. The security of large networks should be controlled by dividing them into separate logical network domains, e.g. an organization’s internal network domains and external network domains, each protected by a defined security perimeter. Such a perimeter should be implemented by installing a secure gateway between the two networks to be interconnected to control access and information flow between the two domains. This gateway should be configured to filter traffic between these domains and to block unauthorized access in accordance with the organization’s access control procedures. An example of this type of gateway is what is commonly referred to as a firewall. The criteria for segregation of networks into domains should be based on the access control procedures and access requirements and also take account of the relative cost and performance impact of incorporating suitable network routing or gateway technology.
11. The connection capability of users must be restricted in shared networks, in accordance with the access control procedures.
12. Such controls should be implemented through network gateways that filter traffic by means of pre-defined tables or rules. The restrictions applied should be based on the access procedures and requirements of the business applications and should be maintained and updated accordingly. Examples of applications to which restrictions should be applied are:
    • electronic mail,
    • one-way file transfer,
    • both-ways file transfer,
    • interactive access, and
    • network access linked to time of day or date.
13. Shared networks must have routing controls to ensure that computer connections and information flows do not breach the access control policy of business applications. This control is essential for networks shared with third party (non-organization) users.
14. Routing controls should be based on positive source and destination address checking mechanisms. Network address translation is also a very useful mechanism for isolating networks and preventing routes to propagate from the network of one organization into the network of another. They can be implemented in software or hardware. Implementers should be aware of the strength of any mechanisms deployed. A wide range of public or private network services is available, some of which offer value added services. Network services may have unique or complex security characteristics.
15. A clear description of the security attributes of all network services used by the organization must be provided.

7.6 Electronic Commerce Security

1. Electronic commerce can involve the use of electronic data interchange (EDI), electronic mail and on line transactions across public networks such as the Internet. Electronic commerce is vulnerable to a number of network threats which may result in fraudulent activity, contract dispute and disclosure or modification of information and must be protected. The following issues must be resolved:
   • Authentication. What level of confidence should the customer and trader require in each other’s claimed identity?
   • Authorization. Who is authorized to set prices, issue or sign key trading documents? How does the trading partner know this?
   • Contract and tendering processes. What are the requirements for confidentiality, integrity and proof of dispatch and receipt of key documents and the non-repudiation of contracts?
   • Pricing information. What level of trust can be put in the integrity of the advertised price list and the confidentiality of sensitive discount arrangements?
   • Order transactions. How is the confidentiality and integrity of order, payment and delivery address details and confirmation of receipt, provided?
   • Vetting. What degree of vetting is appropriate to check payment information supplied by the customer?
   • Settlement. What is the most appropriate form of payment to guard against fraud?
   • Ordering. What protection is required to maintain the confidentiality and integrity of order information and to avoid the loss or duplication of transactions?
   • Liability. Who carries the risk for any fraudulent transactions?
2. Electronic commerce arrangements between trading partners should be supported by a documented agreement which commits both parties to the agreed terms of trading, including details of authorization. Other agreements with information service and value-added network providers may be necessary.
3. Consideration should be given to the resilience to attack of the host used for electronic commerce and the security implications of any network interconnection required for its implementation.

7.7 Mobile Computing

1. This must be in place and appropriate controls must be adopted to protect against the risks of working with mobile computing facilities, in particular in unprotected environments. For example, it should include the requirements for:
   • physical protection,
   • access controls,
   • cryptographic techniques,
   • back-ups, and
   • virus protection.
2. It should also include rules and advice on connecting mobile facilities to networks and guidance on the use of these facilities in public places.
3. Care should be taken when using mobile computing facilities in public places, meeting rooms and other unprotected areas outside of the organization’s premises. Protection should be in place to avoid the unauthorized access to, or disclosure of the information stored and processed by these facilities, e.g., using cryptographic techniques.
4. It is important that when such facilities are used in public places care is taken to avoid the risk of overlooking by unauthorized persons.
5. Equipment should be available to enable the quick and easy back-up of information. These back-ups should be given adequate protection against, e.g., theft or loss of information.
6. Suitable protection should be given to the use of mobile facilities connected to networks.
7. Remote access to business information across public network using mobile computing facilities should only take place after successful identification and authentication and with suitable access control mechanisms in place
8. Mobile computing facilities should also be physically protected against theft especially when left, for example, in cars and other forms of transport, hotel rooms, conference centers and meeting places. Equipment carrying important, sensitive and/or critical business information should not be left unattended and, where possible, should be physically locked away, or special locks should be used to secure the equipment.

7.8 Remote Computing

1. Remote computing uses communications technology to enable staff to work remotely from a fixed location outside of XXX. Suitable protection of the remote computing site should be in place against, e.g., the theft of equipment and information, the unauthorized disclosure of information, unauthorized remote access to the organization’s internal systems or misuse of facilities. It is important that remote computing is both authorized and controlled by management and that suitable arrangements are in place for this way of working.
2. Facility in charge should only authorize remote computing activities if they are satisfied that appropriate security arrangements and controls are in place and that these comply with the XXX’s security procedures and policies. The following should be considered:
   • the existing physical security of the remote computing site, taking into account the physical security of the building and the local environment,
   • the communications security requirements, taking into account the need for remote access to the organization’s internal systems, the sensitivity of the information that will be accessed and passed over the communication link and the sensitivity of the internal system, and
   • the threat of unauthorized access to information or resources from other people using the accommodation.
3. The controls and arrangements to be considered include:
   • the provision of suitable equipment and storage for the remote computing activities,
   • a definition of the work permitted, the hours of work, the classification of information that may be held and the internal systems and services that the user is authorized to access,
   • the provision of suitable communication equipment, including methods for securing remote access,
   • physical security,
   • the provision of hardware and software support and maintenance,
   • the process for back-up and business continuity, and
   • audit and security monitoring.

7.9 External Facilities

1. The use of an external contractor to manage information processing or communication facilities may introduce potential security exposures, such as the possibility of compromise, damage or loss of data at the contractor’s site.
2. Prior to using external facilities, the risks must be identified, and appropriate controls agreed with the contractor and incorporated into the contract. Particular issues that should be addressed include:
   • identifying sensitive or critical applications better retained in-house,
   • obtaining the approval of business application owners,
   • implications for business continuity plans,
   • security standards to be specified and the process for measuring compliance,
   • allocation of specific responsibilities and procedures to effectively monitor all relevant security activities, and
   • responsibilities and procedures for reporting and handling security incidents.

7.10 Encryption

1. Encryption should be applied to protect the confidentiality of sensitive or critical information.
2. Based on a risk assessment, the required level of protection should be identified taking into account the type and quality of the encryption algorithm used and the length of cryptographic keys to be used.
3. Specialist advice should be sought to identify the appropriate level of protection, to select suitable products that will provide the required protection and the implementation of a secure system of key management. In addition, legal advice may need to be sought regarding the laws and regulations that might apply to the organization’s intended use of encryption.
4. The use of cryptographic controls for the protection of information must be developed and followed. Such procedures are necessary to maximize benefits and minimize the risks of using cryptographic techniques and to avoid inappropriate or incorrect use.
5. The following should be considered:
   • the management guidelines on the use of cryptographic controls across the organization,
   • including the general principles under which business information should be protected,
   • the approach to key management, including methods to deal with the recovery of encrypted information in the case of lost, compromised or damaged keys,
   • roles and responsibilities, e.g. who is responsible for: the implementation of the procedures; the key management,
   • how the appropriate level of cryptographic protection is to be determined, and
   • the standards to be adopted for the effective implementation throughout the organization (which solution is used for which business processes).

8.0 Business Continuity

1. Information Technology facilities and systems are vulnerable to a variety of disruptions, some of which are short term (measured in minutes and hours) and others lasting for a day or longer. The intent of Business Continuity Planning is to be alert and ready to sustain an organization’s processes during and following a significant unforeseen disruption in services caused by disasters and security failures.
2. Business continuity should begin by identifying events that can cause interruptions to business processes, e.g., equipment failure, flood and fire. This should be followed by a risk assessment to determine the impact of those interruptions (both in terms of magnitude and recovery time frame). Both of these activities should be carried out with full involvement from owners of business resources and processes. This assessment considers all business processes and is not limited to the information processing facilities.
3. A strategy plan, based on appropriate risk assessment, must be developed for the overall approach to business continuity.
4. CISO will develop contingency plans for each major application or general support system to meet the needs of critical IT operations in the event of a disruption extending beyond a given time period. The length of the time period may vary with the system or facility involved. The execution of such a capability will be documented in a formal contingency plan, be reviewed annually and updated as necessary by the hosting agency. It must account for differential daily backups and complete weekly backups to be conducted and sent to a designated off-site facility. As well, the plans should assign specific responsibilities to designated staff or positions to facilitate the recovery and/or continuity of essential IT functions. Designated personnel will be trained to execute contingency procedures. An annual test of the recovery procedures will be conducted.
5. Business continuity management should include controls to identify and reduce risks, limit the consequences of damaging incidents, and ensure the timely resumption of essential operations.

8.1 Contingency Plan

1. A contingency plan provides the documented organizational plan to mitigate risks of business interruption and minimize the impact of any disruption of service. It must maintain instructions for achieving a full or minimally acceptable set of business objectives in the absence of assets, through cost-effective strategies to provide replacements for assets as they become unavailable. The Plan must involve advance planning and preparations to respond to external circumstances as determined by a risk assessment and continue to provide a pre-determined acceptable level of business functionality. It must be defined, implemented, tested and maintained to ensure continuity of organizational services in the event of a disruption. Each contingency plan is unique and must be tailored to organization’s requirements; it must be flexible enough to allow additions, modifications and maintenance. The plan should minimize dependency on individuals for interpretation and implementation – in the event of emergency, key personnel may not be available. It must ensure completeness and establish critical decisions. Always make sure that the plan remains current. The following questions must be answered:
   • What risks the organization is facing in terms of their likelihood and their impact, including an identification and prioritization of critical business processes?
   • How long can the enterprise operate without this asset?
   • What are the impact interruptions are likely to have on the business (it is important that solutions are found that will handle smaller incidents, as well as serious incidents that could threaten the viability of the organization), and establishing the business objectives of information processing facilities?
   • What is the maximum acceptable delay before which temporary systems must be made available?
   • What is the minimum time in which temporary systems may be expected to become available?
   • At what minimally acceptable level of functionality can the enterprise operate?
   • How long can the enterprise operate at a minimally acceptable level of performance?
   • At what point can the enterprise begin to resume normal operations?
   • At what point must the enterprise begin to resume normal operations?
2. A Contingency Plan should contain the roles, responsibilities and procedures for restoring a system or facility following a major disruption. The following guidelines represent the stages to be followed in preparing and executing a Contingency Plan:
   • Documentation – A plan must be documented, tested and communicated. Included in the plan should be a mission, a scope of what is included and not included assumptions, requirements, staffing and responsibilities.
   • Notification/Activation – Internally within IT, the notification, timing and paths should be documented. There should only be one voice talking for the recovery team for communication and escalation outside the boundaries of IT. Immediately following damage assessment, the plan is activated.
   • Recovery – The sequence of recovery activities should be documented in procedures. These activities are to restore operations which may be in temporary locations or with incomplete data.
   • Reconstitution – Restoring facilities and systems to the “norm” will include testing and proof of operations viability.
   • What equipment / facilities are expected to be unavailable?
   • What is the timing of the disruption?
   • What records, files and materials may / may not be expected to be protected from destruction?
   • What resources are available or required following the event?
     • Applications / Processes
     • Functionality / Capacity
     • Equipment / Infrastructure
     • Staff /Skills
     • Connectivity / Network
     • Data Sources
     • Facilities / Services / Physical Premises
     • Transportation
     • Documentation / Reference material
     • Security Policies and Procedures
     • Specific Policies and Procedures
     • Authorization
3. Following is a list of considerations that, at a minimum, must be addressed in creating contingency plans:
   • What additional security measures are required to protect assets in the planning, execution and maintenance of procedures to assure business continuity?
   • What degree of functionality is still available at the main facility, if any?
   • Availability of staff to perform critical functions defined within the plan.
   • Ability of staff to be notified and report to the backup site(s) to execute contingency plans.
   • Backup files and recovery methods.
   • Off-site storage facilities and materials availability.
   • Disaster recovery plan.
   • Suitability of subsets of the overall plan, to be used to recover from minor interruptions.
   • Availability of an alternate facility.
   • Off-site availability of critical forms and supplies, either at an alternate facility or off-site storage.
   • Existence of a backup site for processing the organization’s work.
   • Availability of long distance and local communications lines.
   • Quality of surface transportation in from local to remote sites.
   • Ability of vendors to perform according to their general commitments to support the organization in a disaster.
   • Provisions for staff while at off-site location (food, water, telephones, beds, etc.) This list of considerations is not all inclusive and must be added to as appropriate.
4. General requirements of contingency plans must include:
   • Definitions of conditions under which the Business Recovery Strategy must be implemented.
   • Recovery point objective stages.
   • Recovery time objective stages.
   • Security preservation checklist.
   • Task Assignments.
   • Post-event Recovery Analysis.
   • Required resources, by priority.
   • Required recovery time / levels of availability of resources.
   • Documentation of normal and response procedures.

8.2 Disaster Recovery plan

1. A Disaster Recovery Plan is intended to maintain critical business processes in the event of the loss of any of the following areas for an extended period of time:

• desktop computers and portable systems,
• servers,
• Web sites,
• local area networks,
• wide area networks,
• distributed systems, and
• mainframe systems.

2. Teams should be formed to address each of the areas indicated consisting of a team lead and designate as well as key knowledge personnel required for that particular area. All contact information must be available for IT management, team members, all IT personnel and designated business unit management. When available, this information should include:

• work telephone number,
• pager number,
• home telephone number,
• cellular telephone number,
• work email address,
• home email address, and
• home address.

3. Upon receiving the information of a serious incident any member of management can invoke the Plan. Depending on the nature of the incident a command center will be established, and appropriate teams mobilized. Management and the team leads are responsible for contacting all required personnel. All roles would have designated in the event one or more individuals are unavailable.

4. Communications to the IT department is the responsibility of Management and the Team Lead. In respect to external communications, it is extremely important that there is a single point of disclosure in order to ensure accurate and timely updates. The following roles and individuals must be determined and documented:

• Upwards, within the affected part organization.
• Outwards to affected agencies.
• Outwards to the public.

5. Hard copies of the Plan must be:

• stored off site at a secure location,
• stored at the personal residence of the team leads,
• stored at the personal residence of all IT managers and directors, and
• stored on a secure internet site.

6. As soon as an emergency is detected:

• Identify the problem and,
  • Notify emergency services in cases of physical threats to personnel or facilities,
  • Notify the CISO and his alternate.
  • Notify the appropriate team leads. In the event of a mainframe disaster, notify all team leads.
  • Notify vendors and business partners.
• Evacuate the premises if there are concerns of personal safety. All personnel should:
  • be aware of evacuation routes and
  • have in possession or be aware of notification numbers.
• educe any exposure:
  • In the event of air conditioning failure (this usually involves powering down the systems at a temperature determined by the tolerances set by the manufacturer),
  • In the event of fire (this usually involves the automatic releasing of fire retardant, cutting of power, notification to emergency services and evacuation),
  • In the event of electrical failure (If a UPS and generator are available, usually the only action is to monitor fuel levels of the generator. If a UPS only is available, shut down procedures should begin and be terminated with at least 20% of rated capacity left),
  • In the event of flood, water or wind damage (this usually involves the normal powering down all systems if possible. If not, the immediate cut off of power is required, followed by notification to emergency services and evacuation),
  • In the event of malicious intrusion (this usually involves the immediate isolation of affected hardware from all networks and connectivity. Usually, the extent of exposure and damage is not immediately known so the immediate isolation of all network links is recommended and processing on affected facilities halted pending analysis by crisis teams).
• Initiate backup site process:
  • The Plan Coordinator establishes a command-and-control center (usually an onsite and offsite center have been previously identified and the necessary computer and communication links are readily available).
  • The Plan Coordinator ensures all team leaders are notified (usually it is the responsibility of the Team Lead to get in touch with all team members).
  • The Plan Coordinator notifies the off-site storage facility that a contingency event has occurred and to ship the necessary materials as determined in the damage assessment to the alternate site.
  • The Plan Coordinator notifies the alternate site that a contingency event has occurred and to prepare the facility for the organization’s arrival.
  • Both upward and outward communication on status is the responsibility of the Plan Coordinator (usually set times are pre-established such as: immediate after 1 hour, after 3 hours, etc. or at major milestones such as problem determination, resolution plan, when planned resumption of services is known and start-up of services is accomplished).
  • The Plan Coordinator is responsible for managing expectations.
• Initiate recovery at the alternate site:
  • Contingency plan is followed using documented recovery points and defined priorities.
  • The Plan Coordinator reviews responsibilities with all team members and establishes recovery logs.
  • Recovery goals and procedures are established and prioritized by the Plan Coordinator.

7. The Disaster Plan appendices should include:

• Personnel Contact List
• Vendor Contact List
• Equipment and Specifications.
• Service Level Agreements.
• Related Contracts.

8.3 Business Recover Strategy

1. A Business Recovery Strategy provides the documented organizational plan to restore full business functionality as quickly and as cost-effectively as possible. The Business Recovery Strategy is initiated as soon as the enterprise is deemed able to resume normal operations following a disaster.
2. The Business Recovery Strategy must involve advance planning and preparations to recover from external circumstances. Recovery strategies must be created, implemented, tested and maintained to ensure restoration of organizational services in the event of an interruption.
3. A “worst case scenario” must be the basis for developing the plan, where the worst-case scenario is the destruction of the main or primary facility. Because the plan is written based on this premise, less critical situations can be handled by using subsets of the plan, with minor (if any) alterations required. Recovery from, or mitigation of a scenario should not be considered an all-or-nothing proposition. Many stages may be required, each with its own success conditions, before a ‘final’ state of continuity or recovery is reached.
4. Specific goals of the Business Recovery Strategy must include:
   • Complete service functionality recovery objectives, in stages, by delay, duration and degree.
   • Details of processes already in place to recover from an incident.
   • Details of what degree of business functionality they may be expected to restore.
   • In what length of time existing process may be expected to restore service.
   • Requirements to bridge from existing processes to sufficient processes.
   • Lead time to secure additional resources.
5. The Business Recovery Strategy must include detailed, step-by-step instructions for how to replace / restore the following, in appropriate sequence:
   • Applications / Processes
   • Functionality / Capacity
   • Equipment / Infrastructure
   • Staff /Skills
   • Execution Duration / Delay
   • Connectivity / Network
   • Data Sources
   • Facilities / Services / Physical Premises
   • Transportation
   • Documentation / Reference material.

9.0 Data Center Management

1. Related specifically to security of information and data center management, the pace of change, the reality of the World Wide Web and the increasing numbers of internal and external portals demand constant monitoring with both offensive and defensive strategies.

9.1 Process

1. The process should specify the instructions for the detailed execution of each job including the following:
   • processing and handling of information,
   • scheduling requirements, including interdependencies with other systems, earliest job start and latest job completion times,
   • instructions for handling errors or other exceptional conditions, which might arise during job execution, including restrictions on the use of system utilities,
   • support and owner contacts in the event of unexpected operational or technical difficulties,
   • special output handling instructions, such as the use of special stationery or the management of confidential output, including procedures for secure disposal of output from failed jobs, and
   • system restart and recovery procedures for use in the event of system failure.
2. The process should also be prepared for system housekeeping activities associated with information processing and communication facilities, such as computer start-up and close-down procedures, back-up, equipment maintenance, computer room and mail handling management and safety.

9.2 Operational Change Control

1. Changes to information processing facilities and systems must be controlled. Inadequate control of changes to information processing facilities and systems is a common cause of system or security failures. Formal management responsibilities and procedures should be in place to ensure satisfactory control of all changes to equipment, software or procedures.
2. Operational programs should be subject to strict change control. When programs are changed an audit log containing all relevant information should be retained. Changes to the operational environment can impact applications. Wherever practicable, operational and application change control procedures should be integrated.
3. In particular, the following controls must be implemented:
   • identification and recording of significant changes,
   • assessment of the potential impact of such changes,
   • formal approval procedure for proposed changes,
   • communication of change details to all relevant persons, and
   • procedures identifying responsibilities for aborting and recovering from unsuccessful changes.

9.3 Segregation of Duties

1. Duties and areas of responsibility must be segregated in order to reduce opportunities for unauthorized modification or misuse of information or services.

2. Small agencies may find this method of control difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision must be implemented. It is important that security audit remains independent.

3. Care should be taken that no single person can perpetrate fraud in areas of single responsibility without being detected. The initiation of an event should be separated from its authorization.

4. The following controls must be implemented:

• It is important to segregate activities which require collusion in order to defraud, e.g. raising a purchase order and verifying that the goods have been received.
• If there is a danger of collusion, then controls need to be devised so that two or more people need to be involved, thereby lowering the possibility of conspiracy.
• Separation of duties of both physical and logical access controls must be implemented to separate the access and functions of:
  • information systems and infrastructure administration to include configuration;
  • security, audit, and accountability functions;
  • privileged users and power user functions.
  • data analysis and report generation functions.
  • general user functionality and associated access must be segregation between user and administrative functions and access must be maintained.

9.4 Separation of Development and Operational Facilities

1. Development and testing facilities must be separated from operational facilities. Rules for the transfer of software from development to operational status should be defined and documented.
2. Development and test activities can cause serious problems, e.g. unwanted modification of files or system environment or of system failure. The level of separation that is necessary, between operational, test and development environments, to prevent operational problems should be considered. A similar separation should also be implemented between development and test functions. In this case, there is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access.
3. Where development and test staff have access to the operational system and its information, they may be able to introduce unauthorized and untested code or alter operational information. On some systems this capability could be misused to commit fraud or introduce untested or malicious code. Untested or malicious code can cause serious operational problems.
4. Developers and testers also pose a threat to the confidentiality of operational information. Development and testing activities may cause unintended changes to software and information if they share the same computing environment. Separating development, test and operational facilities is therefore desirable to reduce the risk of accidental change or unauthorized access to operational software and business information.
5. The following controls should be considered:
   • Development and operational software should, where possible, run on different computer processors, or in different domains or directories.
   • Development and testing activities should be separated the best way possible.
   • Compilers, editors and other system utilities should not be accessible from operational systems.
   • Different log-on procedures should be used for operational and test systems, to reduce the risk of error. Users should be encouraged to use different passwords for these systems and menus should display appropriate identification messages.
   • Development staff should only have access to operational passwords where controls are in place for issuing passwords for the support of operational systems. Controls should ensure that such passwords are changed after use.

9.5 Systems planning and acceptance.

To minimize the risk of systems failure:

1. Advance planning and preparation are required to ensure the availability of adequate capacity and resources.
2. Projections of future capacity requirements should be made, to reduce the risk of system overload.
3. The operational requirements of new systems should be established, documented and tested prior to their acceptance and use.

9.6 Capacity planning

1. Capacity demands must be monitored, and projections of future capacity requirements made to ensure that adequate processing power and storage are available. These projections should take account of new business and system requirements and current and projected trends in the organization’s information processing.
2. Mainframe computers require particular attention, because of the much greater cost and lead time for procurement of new capacity. Operations managers of mainframe services should monitor the utilization of key system resources, including processors, main storage, file storage, printers and other output devices and communications systems. They should identify trends in usage, particularly in relation to business applications or management information system tools.
3. These managers should use this information to identify and avoid potential bottlenecks that might present a threat to system security or user services and plan appropriate remedial action.
4. Acceptance criteria for new information systems, upgrades and new versions must be established and suitable tests of the system carried out prior to acceptance. Operations managers should ensure that the requirements and criteria for acceptance of new systems are clearly defined, agreed, documented and tested.
5. The following controls should be considered:
   • performance and computer capacity requirements,
   • error recovery and restart procedures and contingency plans,
   • preparation and testing of routine operating procedures to defined standards,
   • agreed set of security controls in place,
   • effective manual procedures,
   • business continuity arrangements as required,
   • evidence that installation of the new system will not adversely affect existing systems, particularly at peak processing times, such as month end,
   • evidence that consideration has been given to the effect the new system has on the overall security of the organization, and
   • training in the operation or use of new systems.
6. For major new developments, the operations function and users should be consulted at all stages in the development process to ensure the operational efficiency of the proposed system design. Appropriate tests should be carried out to confirm that all acceptance criteria are fully satisfied.

9.8 Operations and Fault logging

1. Operational staff must maintain a log of their activities. Logs should include as appropriate:
   • system starting and finishing times,
   • system errors and corrective action taken,
   • confirmation of the correct handling of data files and computer output, and
   • the name of the person making the log entry.
2. Faults must be reported, and corrective action taken. Faults reported by users regarding problems with information processing or communications systems should be logged. There should be clear rules for handling reported faults including:
   • review of fault logs to ensure that faults have been satisfactorily resolved, and
   • review of corrective measures to ensure that controls have not been compromised and that the action taken is fully authorized.

9.9 Management of Removable computer media

Appropriate Process must be established to protect documents, computer media (tapes, disks, cassettes, etc.), input/output data, and system documentation from damage, theft and unauthorized access. The following should be followed:

• If no longer required, the previous contents of any re-usable media that are to be removed from the organization should be erased.
• Authorization should be required for all media removed from the organization and a record of all such removals maintained.
• All media should be stored in a safe, secure environment, in accordance with manufacturers’ specifications.
• All process and authorization levels should be clearly documented.

9.10 Disposal of Media

Process for the secure disposal of media should be established to minimize this risk. The following controls should be considered:

1. Media containing sensitive information should be stored and disposed of securely and safely, e.g., by incineration or shredding or emptied of information for use by another application within the organization.
2. The following list identifies items that might require secure disposal:
   • paper documents,
   • voice or other recordings,
   • output reports,
   • one-time-use printer ribbons,
   • magnetic tapes,
   • removable disks or cassettes,
   • optical storage media (all forms and including all manufacturer software distribution media),
   • program listings,
   • test information, and
   • system documentation.
3. It may be easier to arrange for all media items to be collected and disposed of securely, rather than attempting to separate out the sensitive items.
4. Disposal of sensitive items should be logged where possible in order to maintain an audit trail.
5. Disposal of certain hardware must conform to the current EPA requirements or other relevant legislation in effect.

9.11 Exchanges of Information and Software

1. Exchanges of information and software between organizations should be controlled and should be compliant with any relevant legislation.
2. Exchanges should be carried out on the basis of agreements. Procedures and standards to protect information and media in transit must be established. The business and security implications associated with electronic data interchange, electronic commerce and electronic mail and the requirements for controls should be considered.
3. Agreements, some of which must be formal, must be established for the electronic or manual exchange of information and software between organizations. The security content of such an agreement should reflect the sensitivity of the business information involved. Agreements on security conditions should include:
   • responsibilities for controlling and notifying transmission, dispatch and receipt,
   • process for notifying sender, transmission, dispatch and receipt,
   • minimum technical standards for packaging and transmission,
   • courier identification standards,
   • responsibilities and liabilities in the event of loss of information,
   • information and software ownership and responsibilities for information protection, software copyright compliance and similar considerations,
   • technical standards for recording and reading information and software, and
   • any special controls that may be required to protect sensitive items, such as cryptographic.
4. Information can be vulnerable to unauthorized access, misuse or corruption during physical transport, for instance when sending media via the postal service or via courier. As such, media being transported must be protected from unauthorized access, misuse or corruption.

9.12 Publicly Available systems

1. Information on a publicly available system, e.g., information on a Web server accessible via the Internet, may need to comply with laws, rules and regulations in the jurisdiction in which the system is located or where trade is taking place. There must be a formal authorization process before information is made publicly available and the integrity of such information must be protected to prevent unauthorized modification.
2. Software, data and other information requiring a high level of integrity, made available on a publicly available system, should be protected by appropriate mechanisms, e.g. digital signatures. Electronic publishing systems, especially those that permit feedback and direct entering of information, should be carefully controlled so that:
   • information is obtained in compliance with any information protection legislation,
   • information input to and processed by the publishing system will be processed completely and accurately in a timely manner,
   • sensitive information will be protected during the collection process and when stored, and
   • access to the publishing system does not allow unintended access to networks to which it is connected.

9.13 Use of system utilities

1. Most computer installations have one or more system utility programs that might be capable of overriding system and application controls. Use of these system utility programs must be restricted and tightly controlled. The following controls should be considered:
   • use of authentication procedures for system utilities,
   • segregation of system utilities from applications software,
   • limitation of the use of system utilities to the minimum practical number of trusted authorized users,
   • authorization for ad hoc use of systems utilities,
   • limitation of the availability of system utilities, e.g. for the duration of an authorized change,
   • logging of all use of system utilities,
   • defining and documenting of authorization levels for system utilities, and
2. removal of all unnecessary software-based utilities and system software.

9.14 Monitoring system access and use

1. Systems should be monitored to detect deviation from access control policy and record system events to provide evidence in case of security incidents. System monitoring allows the effectiveness of controls adopted to be checked.
2. Audit logs recording exceptions and other security-relevant events must be produced and kept for a period defined by the agency and within the mandate of legislation to assist in future investigations and access control monitoring. Audit logs should also include:
   • user IDs,
   • dates and times for log-on and log-off,
   • terminal identity or location, if possible,
   • records of successful and rejected system access attempts, and
   • records of successful and rejected data and other resource access attempts.
3. Certain audit logs may be required to be archived as part of the record retention procedures or because of requirements to collect evidence.
4. Process for monitoring use of information processing facilities must be established and the result of the monitoring activities reviewed regularly. Such process are necessary to ensure that users are only performing activities that have been explicitly authorized. The level of monitoring required for individual facilities should be determined by a risk assessment. Areas that should be included are:
   • authorized access, including detail such as:
     • the user ID,
     • the date and time of key events,
     • the types of events,
     • the files accessed, and
     • the program/utilities used.
   • all privileged operations, such as:
     • use of supervisor account,
     • system start-up and stop, and
     • I/O device attachment/detachment.
   • unauthorized access attempts, such as:
     • failed attempts,
     • access procedure violations and notifications for network gateways and firewalls, and
     • alerts from proprietary intrusion detection systems.
   • system alerts or failures such as:
     • console alerts or messages,
     • system log exceptions, and
     • network management alarms.
5. The result of the monitoring activities should be reviewed regularly. The frequency of the review should depend on the risks involved. Risk factors that should be considered include:
   • the criticality of the application processes,
   • the value, sensitivity or criticality of the information involved,
   • the past experience of system infiltration and misuse and
   • the extent of system interconnection (particularly public networks).
6. A log review involves understanding the threats faced by the system and the manner in which these may arise. System logs often contain a large volume of information, much of which is extraneous to security monitoring. To help identify significant events for security monitoring purposes, the copying of appropriate message types automatically to a second log and/or the use of suitable system utilities or audit tools to perform file interrogation should be considered. When allocating the responsibility for log review a separation of roles should be considered between the person(s) undertaking the review and those whose activities are being monitored.
7. Particular attention should be given to the security of the logging facility because if tampered with it can provide a false sense of security. Controls should aim to protect against unauthorized changes and operational problems including:
   • the logging facility being de-activated,
   • alterations to the message types that are recorded,
   • log files being edited or deleted, and
   • log file media becoming exhausted and either failing to record events or overwriting itself.

9.15 Control of Operational Software

1. Control must be applied to the implementation of software on operational systems. To minimize the risk of corruption of operational systems, the following controls should be considered:
   • The updating of the operational program libraries should only be performed by the nominated librarian upon appropriate management authorization.
   • Operational systems should only hold executable code.
   • Executable code should not be implemented on an operational system until evidence of successful testing and user acceptance is obtained and the corresponding program source libraries have been updated.
   • An audit log should be maintained of all updates to operational program libraries.
   • Previous versions of software should be retained as a contingency measure.
2. Vendor supplied software used in operational systems should be maintained at a level supported by the supplier. Any decision to upgrade to a new release should take into account the security of the release, i.e. the introduction of new security functionality or the number and severity of security problems affecting this version. Software patches should be applied when they can help to remove or reduce security weaknesses.

9.16 Access control to source library

In order to reduce the potential for corruption of computer programs, strict control must be maintained over access to program source libraries.

1. Program source libraries should not be held in operational systems.
2. A program librarian should be nominated for each application.
3. IT support staff should not have unrestricted access to program source libraries.
4. Programs under development or maintenance should not be held in operational program source libraries.
5. The updating of program source libraries and the issuing of program sources to programmers should only be performed by the nominated librarian upon authorization from the IT support manager for the application.
6. Program listings should be held in a secure environment.
7. An audit log should be maintained of all accesses to program source libraries.
8. Old versions of source programs should be archived, with a clear indication of the precise dates and times when they were operational, together with all supporting software, job control, data definitions and procedures.
9. Maintenance and copying of program source libraries should be subject to strict change control procedures.

9.17 Change Control Process

1. The implementation of changes must be strictly controlled by the use of formal change control procedures to minimize the risk of system corruption. These formalized change controls must be enforced. They should ensure that security and control procedures are not compromised, that programmers are given access to only those units required for their work and that formal approvals are obtained. Changing application software can impact the operational environment. Whenever practical, application and operational change procedures should be integrated. These processes should include:
   • maintaining a record of agreed authorization levels,
   • ensuring changes are submitted by authorized personnel,
   • reviewing controls and procedures to ensure they will not be compromised by the changes submitted,
   • identifying all the software, databases and hardware that require change,
   • obtaining formal approval before work commences,
   • ensuring the changes are carried out to minimize any possible disruptions,
   • ensuring the system documentation is current,
   • maintaining version control on all updates,
   • maintaining an audit trail of all change requests,
   • ensuring that operational documentation and user procedures reflect the new environment, and (K) ensuring that the changes are implemented without business disruption.
2. Test environments should be separated from development and production environments.

9.18 Restrictions on changes to software

Modification to software packages must be discouraged and essential changes controlled. Only when deemed essential, should the packages be modified. The following points should be considered:

1. the possibility of controls and processes included in the base software being compromised,
2. the necessity of obtaining the vendor’s consent,
3. the possibility of the vendor including the changes into the base offering, and
4. the impact of incorporating these changes in future releases of the base software.

9.19 Intrusion Detection System (IDS)

1. Network IDS utilize traffic analysis to compare session data against a known database of popular application attack signatures. On detection, the network IDS can react by logging the session alerting the administrator, terminating the session and even reconfiguring the firewall or router to block selected traffic
2. Host IDS compare application / internal service log events against a known database of security violations and custom policies. If a breach of policy occurs, the host IDS can react by logging the action alerting the administrator and, in some cases, stopping the action prior to execution.
3. Application-Level IDS rely upon custom applications to log unauthorized or suspect activity and / or produce an alert. An example of an Application-Level IDS would be a Web application which maintains its own internal user / password system. Attempts to circumvent this system would not be noticed by a Network IDS or recorded by a Host IDS.

9.20 Controls on Malicious software

1. Detection and prevention controls to protect against malicious software and appropriate user awareness procedures must be implemented. Protection against malicious software should be based on security awareness appropriate system access and change management controls. The following procedures should be implemented:
   • compliance with software licenses and prohibiting the use of unauthorized software,
   • protection against risks associated with obtaining files and software either from or via external networks or on any other medium, indicating what protective measures should be taken,
   • installation and regular update of anti-virus detection and repair software to scan computers and media either as a precautionary control or on a routine basis,
   • regular reviews of the software and information content of systems supporting critical business processes—the presence of any unapproved files or unauthorized amendments should be formally investigated,
   • verification of files on electronic media of uncertain or unauthorized origin, or files received over un-trusted networks, for viruses before use,
   • verification of any electronic mail attachments and downloads for malicious software before use—this check may be carried out at different places, e.g., at electronic mail servers, desk top computers or when entering the network of the organization,
   • assignment of responsibilities to deal with the virus protection on systems, training in their use, reporting and recovering from virus attacks,
   • appropriate business continuity plans for recovering from virus attacks, including all necessary data and software back-up and recovery arrangements,
   • verification of all information relating to malicious software and ensure that warning bulletins are accurate and informative, and
   • verification that qualified sources, e.g., reputable journals, reliable Internet sites or anti-virus software suppliers are used to differentiate between hoaxes and real viruses.
2. Staff should be made aware of the problem of hoaxes and what to do on receipt of them. These controls are especially important for network file servers supporting large numbers of workstations.

9.21 Firewalls

1. Firewalls’ functionality must be documented and detail how they manage security policy as applied to network traffic and how they maintain internal security.
2. System documentation must detail the following:
   • Purpose / Business rationale for the system
   • Services offered, including business rationale
   • Rationale for the choice of platform, operating system, components and configuration.
   • Adjacent or integrated systems.
   • Modifications to the default system software configuration
   • Installed software
   • Installed software configuration
   • Installed hardware
   • Installed hardware configuration
   • Support contracts
   • Software licenses
   • Hardware lease details
   • Process for shutdown, restart and recovery
   • System maintenance schedule

9.22 External Facilities Management

1. The use of an external contractor to manage information processing facilities may introduce potential security exposures, such as the possibility of compromise, damage, or loss of data at the contractor’s site. Prior to using external facilities management services, the risks must be identified, and appropriate controls agreed with the contractor, and incorporated into the contract.
2. Particular issues that should be addressed include:
   • identifying sensitive or critical applications better retained in-house,
   • obtaining the approval of business application owners,
   • implications for business continuity plans,
   • security standards to be specified, and the process for measuring compliance,
   • allocation of specific responsibilities and procedures to effectively monitor all relevant security activities, and
   • responsibilities and procedures for reporting and handling security incidents.

10.0 Legal Requirements

All security related aspects of information processing may be subject to statutory or contractual security requirements. Each agency must be aware of their responsibilities as dictated by legislation and other legal commitments particularly as they apply to the information systems and practices required by the federal and state governments. All agencies should put in place the appropriate procedures to ensure compliance with legal considerations.

10.1 Software Copyright

Proprietary software products are usually supplied under a license agreement that limits the use of the products to specified machines and may limit copying to the creation of back-up copies only. The following controls should be implemented:

1. publishing software copyright compliance procedures which define the legal use of software and information products,
2. maintaining awareness of the software copyright and acquisition procedures and giving notice of the intent to take disciplinary action against staff who breach them,
3. maintaining appropriate asset registers,
4. maintaining proof and evidence of ownership of licenses, master disks, manuals, etc.,
5. implementing controls to ensure that any maximum number of users permitted is not exceeded,
6. carrying out checks that only authorized software and licensed products are installed,
7. providing procedures for maintaining appropriate license conditions, and
8. providing procedures for disposing or transferring software to others

10.2 Protection of Information

1. Important records of an organization must be protected from loss, destruction and falsification. Some records may need to be securely retained to meet statutory or regulatory requirements as well as to support essential business activities. The time period and information content for retention may be set by federal and state laws or regulations.
2. Records should be categorized into record types, such as accounting records, database records, transaction logs audit logs and operational procedures, each with details of retention periods and type of storage media, e.g. paper, microfiche, magnetic, optical. Any related cryptographic keys associated with encrypted archives or digital signatures, should be kept securely and made available to authorized persons when needed.
3. Consideration should be given to the possibility of degradation of media used for storage of records. Storage and handling procedures should be implemented in accordance with Manufacturer’s recommendations.
4. Wherever electronic storage media are chosen, procedures to ensure the ability to access information (both media and format readability) throughout the retention period should be included, to safeguard against loss due to future technology change.
5. The system of storage and handling should ensure clear identification of records and of their statutory or regulatory retention period. It should permit appropriate destruction of records after that period if they are not needed by the organization.
6. To meet these obligations, the following steps should be taken within an organization:
   • Guidelines should be issued on the retention, storage, handling and disposal of records and information.
   • A retention schedule should be drawn up identifying essential record types and the period of time for which they should be retained.
   • An inventory of sources of key information should be maintained.
   • Appropriate controls should be implemented to protect essential records and information from loss, destruction and falsification.

10.3 Privacy of Personal information

1. In many cases, legislation controls the processing and transmission of personal information (generally information on living individuals who can be identified from that information). Such controls impose responsibilities on those collecting, processing and disseminating personal information.
2. Controls must be applied to protect personal information in accordance with relevant legislation. Compliance with information protection legislation requires appropriate management structure and control. It is the responsibility of the owner of the information to ensure the information is protected and that there is awareness by all users of the information protection principles defined in the relevant legislation.

ICT Security Risk Management policy and Procedure

1. INTRODUCTION

1.1. Overview

XXX’s information and technology assets are highly valuable and must be closely safeguarded. XXX operate within an increasingly electronic, interconnected, and regulated environment that necessitates a consistent and standardized approach to securing technology and information assets. To ensure the continued protection of XXX information and to maintain a secure environment, the management team of XXX strongly believes that an ICT security approach aligned with industry standards is necessary.

1.2. Rationale
It is the mandate of XXX that the information assets are protected from all types of threat, whether internal or external, deliberate or accidental, such that:

• Confidentiality of information is maintained;
• Integrity of information can be relied upon;
• Information is available when the business needs it; and
• Relevant statutory, regulatory, and contractual obligations are met.

1.3. Purpose
This ICT Security Policy is the cornerstone of XXX’s ICT security program/strategy, aimed at securing the information assets of the institution. It is also the purpose of this document to outline the roles and responsibilities of relevant stakeholders that implement the security controls.

1.4. Scope
This policy is applicable to all employees, contractors, consultants, temporary and other workers at XXXincluding all personnel affiliated with external parties must adhere to this policy. This policy is applicable to information assets owned or leased by XXX or to devices that connect to XXX’s network or reside at XXX’s sites.

1.5 ICT Security Roles and Responsibilities

Line Manager Responsibilities
It is every Line Manager’s responsibility to ensure that both they and members of their team within their line management responsibility comply with this policy. Line Managers must inform the ICT Service Desk at least 5 working days before an employee who they are responsible for commences or ends their employment with the Combined Authority. Emails and personal data are retained for three months for all ex-employees unless the ICT Service Desk receives a line management request to vary this.
All Employee Responsibilities
It is the responsibility of every Combined Authority employee to ensure that they comply with and do not abuse the policy and procedure. All employees must ensure they complete the mandatory Human Focus training module covering ICT Security within 48 hours of starting with the Combined Authority and before access to personal and confidential data is granted.

Information Asset Owners
IAO’s should also ensure that when a system requires a password that differs from the network password, e.g Dream/Payrite/Haven, the system should follow the password guidance , such as complexity, length and expiration. ICT Services can assist with the configuration of the systems, but overall responsibility rests with the IAO.

2.0 ICT SECURITY POLICY STATEMENTS

2.1. ICT Security Governance and Management

2.1.1. Management and Direction for ICT Security
2.1.1.1. There shall be an ICT Security Governance Committee which may have members not necessary limited to XXX’s staff.
2.1.1.2. Single Point of Contact (SPOC) for ICT security Matters shall be appointed.
2.1.1.3. There shall be an ICT Security Strategy.
2.1.1.4. XXX’s shall allocate sufficient resources for effective ICT security management.

2.1.2. ICT Security Risk Management
2.1.2.1. XXX shall integrate ICT security risk management that include risk assessment, risk treatment, risk acceptance, risk communication and risk monitoring and evaluation into the Enterprise Risk Management Framework.

2.1.3. ICT Security Policies
2.1.3.1. XXX’s shall define a set of policies for ICT security, which shall be approved by management, published and communicated to employees and relevant external parties.

2.1.4. Review of the ICT Security Policies
2.1.4.1. The ICT security policies shall be reviewed at planned intervals or if significant changes occur, to ensure their continuing suitability, adequacy and Effectiveness.

2.1.5. Segregation of Duties
2.1.5.1. Conflicting duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the XXX’s ICT assets.

2.1.6 Contact with Authorities
2.1.6.1. XXX shall maintain appropriate contacts with relevant authorities.

2.1.7. ICT Security in ICT Project Management
2.1.7.1. XXX shall ensure that ICT security is addressed in ICT related projects.

2.1.8. Mobile Devices and Teleworking
2.1.8.1. XXX shall adopt a policy and supporting ICT security measures to manage the risks relating to mobile devices.
2.1.8.2. XXX shall implement a policy and supporting ICT security measures to protect information accessed, processed or stored at teleworking sites.

2.2. ICT Security Operations

2.2.1. Documented Operating Procedures
2.2.1.1. Operating procedures shall be documented and made available to all users who need them.

2.2.2. Change Management
2.2.2.1. Changes to the organization, business processes, information processing facilities and systems that affect ICT security shall be controlled.

2.2.3. Capacity Management
2.2.3.1. The use of resources shall be monitored, tuned and projections made of future capacity requirements to ensure the required system performance.

2.2.4. Separation of Development, Testing and Operational Environments
2.2.4.1. Development, testing, and operational environments shall be separated to reduce the risks of unauthorized access or changes to the operational environment.

2.2.5. Protection from Malware
2.2.5.1. Detection, prevention and recovery controls to protect against malware shall be implemented, combined with appropriate user awareness.

2.2.6. Information Backup
2.2.6.1. Backup copies of information, software and system images shall be taken and tested regularly in accordance with an agreed Backup policy.

2.2.7. Event Logging
2.2.7.1. Event logs recording user activities, exceptions, faults and CT security events shall be produced, kept and regularly reviewed.

2.2.8. Protection of Log Information
2.2.8.1. Logging facilities and log information shall be protected against tampering and unauthorized access.

2.2.9. Administrator and Operator Logs
2.2.9.1. System administrator and system operator activities shall be logged and the logs protected and regularly reviewed.

2.2.10. Clock Synchronization
2.2.10.1. The clocks of all relevant information processing systems within XXX shall be synchronized to a single reference time source.

2.2.11. Installation of Software on Operational Systems
2.2.11.1. Procedures shall be implemented to control the installation of software on operational systems.

2.2.12. Management of Technical Vulnerabilities
2.2.12.1. Information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, XXX exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.

2.2.13. Restrictions on Software Installation
2.2.13.1. A policy governing the installation of software by users shall be established and implemented.

2.2.14. Information Systems Audit Controls
2.2.14.1. ICT audit requirements and activities involving verification of operational systems shall be carefully planned and agreed to minimize disruptions to business processes.

2.2.15. Network Controls
2.2.15.1. Networks shall be managed and controlled to protect information in systems and applications.

2.2.16. Security of Network Services
2.2.16.1. Security mechanisms, service levels and management requirements of all network services shall be identified and included in network services agreements, irrespective of whether these services are provided in-house or outsourced.

2.2.17. Segregation in Networks
2.2.17.1. Groups of information services, users and information systems shall be segregated on networks.

2.2.18. Information Transfer Policy and Procedures
2.2.18.1. Formal transfer policy, procedures and controls shall be in place to protect the transfer of information through the use of all types of communication facilities.

2.2.19. Agreements on Information Transfer
2.2.19.1. Agreements shall be signed with relevant stakeholders to address the secure transfer of business information between the organization and external parties.

2.2.20. Electronic Messaging
2.2.20.1. Information involved in electronic messaging shall be appropriately protected.

2.2.21. Confidentiality and Non-Disclosure Agreements
2.2.21.1. Requirements for confidentiality or non-disclosure agreements reflecting the XXX needs for the protection of information shall be identified, regularly reviewed and documented.

2.3. Security of ICT Assets

2.3.1. Inventory of ICT Assets
2.3.1.1. ICT assets associated with information and information processing facilities at XXX shall be identified and an inventory of these assets should be drawn up and maintained.

2.3.2. Ownership of ICT Assets
2.3.2.1. ICT assets maintained in the inventory shall be owned by the relevant function or person at XXX.

2.3.3. Acceptable Use Policy for ICT Assets
2.3.3.1. Acceptable use policy of information, assets associated with information and information processing facilities shall be identified, documented and implemented.

2.3.4. Return of ICT Assets
2.3.4.1. All employees of XXXand external party users must return all XXXICT assets in their possession upon termination of their employment, contract or agreement.

2.3.5. Classification of Information
2.3.5.1. Information shall be classified in terms of legal requirements, value, criticality and sensitivity to unauthorized disclosure or modification.

2.3.6. Labelling of Information
2.3.6.1. An appropriate set of procedures for information labelling shall be developed and implemented in accordance with the information classification scheme adopted by XXX.

2.3.7. Handling of ICT Assets
2.3.7.1. Procedures for handling ICT assets shall be developed and implemented in accordance with the information classification scheme adopted by XXX.

2.3.8. Management of Removable Media
2.3.8.1. Procedures shall be implemented for the management of removable media in accordance with the classification scheme adopted by XXX.

2.3.9. Disposal of Media
2.3.9.1. Media shall be disposed off securely when no longer required, using the formal procedures established at XXX as per government directives.

2.3.10. Physical Media Transfer
2.3.10.1. Media containing information shall be protected against unauthorized access, misuse or corruption during transportation in and out of XXX.

2.3.11. Cryptographic Controls
2.3.11.1. XXX shall develop and implement cryptographic controls for protection of information and information processing facilities.

2.4. Identity and Access Management

2.4.1. Access Control Policy
2.4.1.1. Access Control Policy shall be established, documented and reviewed based on business and ICT security requirements of XXX.

2.4.2. Access to Networks and Network Services
2.4.2.1. Users at XXX shall only be provided with access to the network and network services that they have been specifically authorized to use.

2.4.3. User Registration and De-registration
2.4.3.1. A formal user registration and de-registration process shall be implemented at XXX to enable and disable assignment of access rights.

2.4.4. User Access Provisioning
2.4.4.1. A formal user access provisioning process shall be implemented at XXXto assign and revoke access rights for all user types to all systems and services.

2.4.5. Management of Privileged Access Rights
2.4.5.1. The allocation and use of privileged rights shall be restricted and controlled.

2.4.6. Management of Secret Authentication Information of Users
2.4.6.1. The allocation of secret authentication information shall be controlled through a formal management process.

2.4.7. Review of Access Rights
2.4.7.1. All ICT asset owners at XXX shall review users’ access rights at regular intervals.

2.4.8. Removal or Adjustment of Access Rights
2.4.8.1. The access rights of all staff at XXXand external party users to information and information processing facilities shall be removed upon termination of their employment, contract or agreement, or adjusted upon change.

2.4.9. Information Access Restriction
2.4.9.1. Access to information and application system functions shall be restricted in accordance with the Access Control Policy of XXX.

2.4.10. Secure Log-on Procedures
2.4.10.1. Where required by the Access Control Policy, access to systems shall be controlled through a secure log-on procedure.

2.4.11. Password Management System
2.4.11.1. Password management systems must be interactive and must ensure usage of strong passwords.

2.4.12. Use of Privileged Utility Programs
2.4.12.1. The use of utility programs that might be capable of overriding system and application controls must be restricted and tightly controlled.

2.4.13. Access Control to Program Source Code
2.4.13.1. Access to program source code shall be restricted.

2.5. ICT Security Incident Management

2.5.1. Responsibilities and Procedures
2.5.1.1. Management responsibilities and procedures shall be established to ensure a quick, effective and orderly response to information security incidents.

2.5.2. Reporting ICT Security Events
2.5.2.1. ICT security events shall be reported through appropriate management channels as quickly as possible.

2.5.3. Reporting ICT Security Weaknesses
2.5.3.1. Employees and contractors using the XXX information systems and services shall be required to note and report immediately after any observed or suspected ICT security weaknesses in systems or services.

2.5.4. Assessment of and Decision on ICT Security Events
2.5.4.1. ICT security events shall be assessed and it shall be decided if they are to be classified as information security incidents.

2.5.5. Response to ICT Security Events
2.5.5.1. ICT security incidents shall be responded to in accordance with the documented procedures.

2.5.6. Learning from ICT Security Incidents
2.5.6.1. Knowledge gained from analyzing and resolving ICT security incidents shall be used to reduce the likelihood or impact of future incidents.

2.5.7. Collection of Evidence
2.5.7.1. XXX shall define and apply procedures for the identification, collection, acquisition and preservation of information, which can serve as evidence.

2.6. Information Systems Continuity Management

2.6.1. Planning ICT Security Continuity
2.6.1.1. XXX shall determine its requirements for ICT security and the continuity of ICT security management in adverse situations, e.g. during a crisis or disaster.

2.6.2. Implementing ICT Security Continuity
2.6.2.1. XXX shall establish, document, implement and maintain processes, procedures and controls to ensure the required level of continuity for ICT security during an adverse situation.

2.6.3. Verify, Review and Evaluate ICT Security Continuity
2.6.3.1. XXXshall verify the established and implemented ICT security continuity controls at regular intervals in order to ensure that they are valid and effective during adverse situations.

2.6.4. Availability of Information Processing Facilities
2.6.4.1. Information processing facilities shall be implemented with redundancy sufficient to meet availability requirements.

2.7. Security of ICT Acquisition, Development and Maintenance

2.7.1. ICT Security Requirements Analysis and Specification
2.7.1.1. The ICT security related requirements shall be included in the requirements for new information systems or enhancements to existing information systems.

2.7.2. Securing Application Services on Public Networks
2.7.2.1. Information involved in application services passing over public networks shall be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification.

2.7.3. Protecting Application Services Transactions
2.7.3.1. Information involved in application service transactions shall be protected to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay.

2.7.4. Secure Development Policy
2.7.4.1. A policy for secure development of software and systems shall be established and applied to developments within the organization.

2.7.5. System Change and Control Procedures
2.7.5.1. Changes to systems within the development lifecycle shall be controlled by the use of formal change control procedures.

2.7.6. Technical Review of Applications after Operating Platform Changes
2.7.6.1. When operating platforms are changed, business critical applications shall be reviewed and tested to ensure there is no adverse impact on organizational operations or ICT security.

2.7.7. Restrictions on Changes to Software Packages
2.7.7.1. Modifications to software packages shall be discouraged, limited to necessary changes and all changes should be strictly controlled.

2.7.8. Secure System Engineering Principles
2.7.8.1. Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.

2.7.9. Secure Development Environment
2.7.9.1. XXXshall establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle.

2.7.10. Outsourced Development
2.7.10.1. XXX shall supervise and monitor the activity of outsourced system development.

2.7.11. System Security Testing
2.7.11.1. Testing of security functionality shall be carried out during development.

2.7.12. System Acceptance Testing
2.7.12.1. Acceptance testing programs and related criteria shall be established for new information systems, upgrades and new versions.

2.7.13. Protection of Test Data
2.7.13.1. Test data shall be selected carefully, protected and controlled.

2.8. Human Resource Security

2.8.1. Screening
2.8.1.1. Background verification checks on all candidates for employment shall be carried out in accordance with relevant laws, regulations and ethics and shall be proportional to the business requirements, the classification of the information to be accessed and perceived risks.

2.8.2. Terms and Conditions of Employment
2.8.2.1. The contractual agreements with employees and contractors shall state the employee’s and XXX’s responsibilities for information security.

2.8.3. Management Responsibilities
2.8.3.1. Management shall require all employees and contractors to apply information security in accordance with the established policy of XXX.

2.8.4. ICT Security Awareness, Education and Training
2.8.4.1. All employees of XXX and contractors shall receive appropriate awareness education and training and regular updates in XXX’s ICT security policy, as relevant to their job function.

2.8.5. Disciplinary Process
2.8.5.1. There shall be a formal and communicated disciplinary process in place to take action against employees who have committed an ICT’s security breach.

2.8.6. Termination or Change of Employment Responsibilities
2.8.6.1. ICT security responsibilities and duties that remain valid after termination or change of employment shall be defined, communicated to all employees and contractors of XXX, and shall be enforced.

2.9. Physical and Environmental Security

2.9.1. Physical Security Perimeter
2.9.1.1. Security perimeters shall be defined and used to protect information processing facilities and areas that contain either sensitive or critical information.

2.9.2. Physical Entry Controls
2.9.2.1. Secured areas shall be protected by appropriate entry controls to ensure that only authorized personnel are allowed access.

2.9.3. Securing Offices, Rooms and Facilities
2.9.3.1. Physical security for offices, rooms and facilities shall be designed and applied.

2.9.4. Protecting Against External and Environmental Threats
2.9.4.1. Physical protection against natural disasters, malicious attack or accidents shall be designed and applied.

2.9.5. Working in Secure Areas
2.9.5.1. XXX shall design and apply procedures for working in secure areas.

2.9.6. Delivery and Loading Areas
2.9.6.1. Access points such as delivery and loading areas and other points where unauthorized persons could enter the premises shall be controlled and, if possible, isolated from information processing facilities to avoid unauthorized access.

2.9.7. Equipment Sitting and Protection
2.9.7.1. Equipment shall be identified and protected to reduce the risks from environmental threats and hazards, and opportunities for unauthorized access.

2.9.8. Supporting Utilities
2.9.8.1. Equipment shall be protected from power failures and other disruptions caused by failures in supporting utilities.

2.9.9. Cabling Security
2.9.9.1. Power and telecommunications cabling carrying data or supporting information services shall be protected from interception, interference or damage.

2.9.10. Equipment Maintenance
2.9.10.1. Equipment shall be properly maintained to ensure its continued availability and integrity.

2.9.11. Removal of ICT Assets
2.9.11.1. Equipment, information or software shall not be taken off-site without prior authorization.

2.9.12. Security of Equipment and Assets Off-premises
2.9.12.1. Security shall be applied to off-site ICT assets taking into account the different risks of working outside XXX’s premises.

2.9.13. Secure Disposal or Re-use of Equipment
2.9.13.1. All items of equipment containing storage media shall be verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or re-use.

2.9.14. Unattended User Equipment
2.9.14.1. Users at XXX shall ensure that unattended equipment has appropriate protection.

2.9.15. Clear Desk and Clear Screen Policy
2.9.15.1. A clear desk policy for papers and removable storage media and a clear screen policy for information processing facilities shall be adopted.

2.10. ICT Security Compliance and Audit

2.10.1. Identification of Applicable Legislation and Contractual Requirements
2.10.1.1. All relevant legislative statutory, regulatory, contractual requirements and the XXX approach to meet these requirements shall be explicitly identified, documented and kept up to date for each information system and for XXX.

2.10.2. Intellectual Property Rights
2.10.2.1. Appropriate procedures shall be implemented to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products.

2.10.3. Protection of Records
2.10.3.1. Records shall be protected from loss, destruction, falsification, unauthorized access and unauthorized release, in accordance with legislatory, regulatory, contractual and business requirements.

2.10.4. Privacy and Protection of Personally Identifiable Information
2.10.4.1. Privacy and protection of personally identifiable information shall be ensured as required in relevant legislation and regulation where applicable.

2.10.5. Independent Review of ICT Security
2.10.5.1. XXX approach to managing information security and its implementation (i.e. control objectives, controls, processes and procedures for information security) shall be reviewed independently at planned intervals or when significant changes occur.

2.10.6. Compliance with ICT Security Policy and Standards
2.10.6.1. XXX shall ensure that regular reviews are done, on the compliance of information processing and procedures with the appropriate ICT security policy, standards and any other ICT security requirements.

2.10.7. Technical Compliance Review
2.10.7.1. Information systems shall be regularly reviewed for compliance with the XXXinformation security standards and guidelines.

3.0 Procedure

3.1 Security Organization

3.1.1 Responsibilities

The ICT Manager is responsible for:

• assigning security roles and responsibilities;
• co-ordinating the implementation of the security policy across the XXX;
• reviewing and if appropriate updating the Security Policies and procedure;
• reviewing and monitoring security incidents;
• reviewing third party access and security arrangements;
• monitoring exposure to major threats to information assets;
• agreeing and supporting XXX-wide security initiatives;
• ensuring patch management of devices is performed on a monthly basis and monitored.

The security of all hardware situated in departments and sections is the responsibility of the departmental or service manager. The security of all other hardware, operating systems, PC application, networking, infrastructure and corporate software is the responsibility of the ICT Manager.

3. 1.2 Acquisition of Information and Communications Technology

All acquisitions of Information and Communications Technology (ICT) shall be in accordance with XXX’s Procurement Procedures and be co-ordinated by the ICT Manager who shall obtain specialist advice if he considers it appropriate.

• All new acquisitions of a corporate nature shall be agreed by the Corporate Leadership Team.
• Departmental acquisitions shall be agreed between the appropriate Head of Service and the ICT Manager.
• The ICT Manager has delegated authority to replace obsolete equipment in accordance with an agreed replacement program and to upgrade/replace office productivity tools and software within an agreed programme.
• All new projects will be in accordance with the XXX’s corporate project management policies, have associated business case / justification documents and be in accordance with the current ICT strategy / road map.

3.1.3 Security Information Advice

Specialist advice on information security is available internally from the ICT Manager or Internal Audit.

3.1.4 Security Incidents

All suspected and actual security incidents shall be reported immediately to the ICT Service desk. Each incident will be recorded, investigated and corrective action implemented where appropriate. If the incident is perceived to be of a serious or urgent nature it will be escalated to the ICT manager or the Head of Customer Services. The XXX has a separate ICT Security Incident Reporting Procedure which gives full details on how to report any security incidents and this includes a copy of the reporting form which you may be asked to complete by the ICT Service desk.

3.1.5 Independent Review of Information Security

The content, implementation and practice of this policy will be reviewed independently to provide assurance that organisation practices properly reflect the policy and that the policy is feasible and effective. Independent reviews will be carried out by the internal Audit team or one that has been appointed.

3.2 Identification of Risks from Third Party Connections

Where there is a business need for third party access to ICT facilities and information assets the security implications and requirements will be determined, and controls agreed with the third party. All new systems will be assessed for risks from third party connections and, where appropriate, controls will be defined in a contract with the third party. Arrangements involving third party access, e.g. Support engineers, subcontractors, consultants will be based on a formal contract or security agreement containing, or referring to, all of the necessary security conditions to ensure compliance with the XXX’s security policy including obtaining an indemnity in respect of any loss caused by erasure or alteration of data or incorrect alteration of programs. The contract should be in place before access to the ICT facilities is provided. The implementation of any changes to systems should be strictly controlled using formal change control procedures. Any third party organisation carrying out work for the XXX will be expected to comply with these change control procedures and will ensure that all system changes are documented. All third party access will be controlled and is available to service providers via a secure internet connection using an SSL (secured sockets layer) VPN appliance, or an application such as Team Viewer. Where reasonably possible, for all access will use multi factor authentication using a soft token delivered via SMS to the user’s mobile phone or a mobile app. The remote support user will be given an access code and a onetime use password for that session. All systems have passwords enabled to ensure only authorised parties can access the XXX’s ICT, at agreed times and that each third party can only access the relevant systems. All contractors, consultants or other temporary staff will be issued with a unique user code and password in line with current procedures for the particular system being used. Under no circumstances should XXX staff allow their own user code or password to be used by anyone else. In certain circumstances it may be necessary to divulge a password for access by technical support staff and in such cases, it must be changed immediately after the authorised activities are completed. A log of such activity is maintained by the ICT department. A log of all third party access will be recorded on the Service Desk management system, with a copy of the completed third party access control form. All third parties accessing XXX systems or data must have had their own IT Security tested by a trusted third party or hold a valid accreditation such as Cyber Essentials or ISO 27001.

3.3 Inventory of Assets

An inventory of ICT assets shall be maintained by the ICT Manager who shall promptly update it for all acquisitions, disposals, updates and management of our cyber assets (this include transfer of assets to another user).The accuracy of the inventory shall be verified annually in accordance with Financial Procedure Rules. This includes equipment at staff homes for those who are working in an agile manner. All users must notify ICT if they move an asset to another location, within the XXX Offices or a remote site.

3.4 PERSONNEL SECURITY

3.4.1 General

Security roles and responsibilities for all staff using ICT facilities will be included in job descriptions and contracts where appropriate by the relevant manager. Managers are responsible for ensuring job descriptions or codes of conduct address all relevant security responsibilities. All potential recruits will be screened by:

• obtaining two satisfactory references;
• confirming academic and professional qualifications.

All employees and third party users of ICT facilities will be required to sign a confidentiality (non-disclosure) undertaking. Revenue Services benefits staff will be subject to recruitment procedures included in the Benefits Anti-Fraud Strategy. The appointment of employees with access to information classified as PROTECT or RESTRICTED will be subject to the specific Baseline Personnel Security Standards available on request from the Human Resources department. All users are responsible for the equipment issued to them and information that they have access to. Third party access to ICT equipment and data, without prior arrangement with IT is prohibited. When accessing XXX information, they must ensure that they do so in a secure environment and that persons who are not authorised to view said information cannot view it.

3.4.2 ICT and Cyber Security Training

All users will need to undertake a cyber security user awareness e-learning training module. All ICT users will be briefed in security procedures and the correct use of ICT facilities by IT staff in order to minimise possible security risks to the confidentiality, integrity and availability of data or services through user error. Managers are responsible for ensuring such training is provided to their staff. New user accounts will only be established and issued to staff who have received appropriate ICT induction and have been authorised by the relevant Head of Service or Director. All new ICT users will be issued with either a paper copy of the current ICT Security Policy and procedure or given access to the document on the XXX’s intranet. They must read the document and sign to acknowledgement the terms and conditions within 2 working weeks otherwise network access will be denied. All new ICT users who will have access to the Government Connect Secure Extranet (GCSx) or Government Secure Internet (GSi) networks will be also be required to comply with a Personal Commitment Statement pertaining to those services. Access levels to review / amend / delete data will be determined by the relevant Head of Service in association with the system owner(s) of any ICT applications which the new user intends to use. All third party suppliers, contractors and temporary staff will be required to read and acknowledge the terms and conditions before being granted access to XXX ICT resources. In the case of third party support companies where individual users may not be easily identifiable a board level representative of the company will be required to acknowledge the terms and conditions.

3.4.3 Responding to Incidents

A security incident shall mean:

• any event arising from negligence or deliberate default that has, or could have, resulted in loss or damage to the XXX’s IT systems or data;
• a compromise to the confidentiality, integrity or availability of IT systems or data;
• an action that is in breach of the security policy;
• any cyber security threat or incident.

All security incidents shall be reported immediately to the ICT Service Desk who will pass the calls to the ICT Security Officer or ICT Manager who will instigate an investigation and report any incidents that cause serious loss or damage to the Head of Customer services and the Data protection officer. Any security incident that may have the potential to lead to disciplinary action will involve the appropriate involvement and consultation with the Head of Human Resources and Organisation Development and/or (depending upon the nature of the incident) the Audit Services Manager. The XXX has a separate ICT Security Incident Reporting Procedure which gives full details on how to report any incidents and this includes a copy of the reporting form which you may be asked to complete by the ICT Service desk. This document is available from within the IT section of the XXX Intranet. The security incident will also be logged on the ICT Service Desk system. Any security incident which leads to loss or damage, or wilful abuse of the conditions of this policy may be cause for investigation and, where appropriate, formal action, in accordance with the XXX’s agreed disciplinary policy. Any incident or suspected incident must be handled in the manner as laid out in the XXX’s Incident and Response Policy and Procedures. The above Incident Response Policy and Procedures will be reviewed on a yearly basis

3.5 Physical and Environmental Security

3.5.1 Secure Areas

ICT facilities such as servers, server rooms and hosting facilities, hubs and routers supporting critical or sensitive business activities shall be housed in secure areas, i.e. protected from unauthorized access, damage and interference. Except for systems specifically intended for public use, ICT facilities should only be available to authorized persons, and wherever possible should be kept away from public access, and preferably view. Specialised IT equipment should be further restricted to authorised staff only in areas of extra security. The following specific conditions will apply to such secure areas:

• server rooms will be protected by electronic locking systems or digital locks on all entry points and will always be kept locked;
• access to any hosted / Data Centre facility is only for ICT staff, with proof of identification and access granted via a request system or logging portal;
• access to server rooms will be only to ICT support staff or to others acting under their close supervision;
• server rooms will be protected with fire detection and control equipment. Such equipment will be integrated into the XXX’s overall fire detection system;
• servers will be protected by Uninterruptible Power Supplies (UPS) enough to allow continuous working of equipment for a minimum of 2 hours in the event of loss of electrical supply to the rooms;
• server rooms will be regularly monitored to ensure an adequate operating environment for the equipment contained;
• network distribution cabinets will be protected with UPS enough to allow continuous working for a minimum of one hour;
• network distribution cabinets will always be kept locked and access granted only to ICT network support staff or others acting under their close supervision;
• remote access may be allowed to server, network and telephony equipment but will be limited to ICT support staff and specified third party support organisations. (Access by third parties will be subject to agreements specific to the software / equipment concerned and, always, will be with the express permission of ICT staff). This includes completing the Permit to work and Risk assessment documents, for all external contractors requiring access to the server room;
• A complete log of remote access by third party support organisations will be maintained.

3.5.2 Equipment Security

ICT equipment and cabling should be protected from spillage or leaks and must be sited away from where staff or the public walk and also to minimise opportunities for unauthorised access or removal. Staff should also be warned of the dangers of spilling liquids or food on IT equipment. Except for laptop and portable computers only IT staff should move, or supervise the moving, of IT equipment. All critical ICT equipment shall be protected by an uninterruptible power supply (UPS). UPS equipment should be self-testing and shall also be manually tested by IT staff at least every six weeks and serviced as necessary. Officers and members should always ensure that computer equipment and screens are positioned to prevent unauthorised viewing of data. Any faulty ICT equipment shall be reported to the IT section who will arrange for its repair or replacement. Under no circumstances shall members of staff attempt to repair, move, change equipment or open casings except for printers to replace consumables or clear a paper jam. Computers provided by the XXX for use at home are for the sole use of that officer or member, no unauthorised third party is allowed access to the computer equipment for any reason. The officer or member will be responsible for ensuring that computer is, always, used in accordance with XXX conditions of use. Laptop, portable computers and smart phones (unless permanently assigned to an officer or member) may be borrowed, with the permission of the officer’s manager, from the IT section who will maintain a record of issue and returns. Such equipment must be transported in appropriate carrying cases, such equipment must be transported in appropriate carrying cases and must not be left in clear view. If left in a vehicle it MUST be out of sight. Officers should treat laptop, smart phones and portable computers as if it were their own possession and uninsured. Any laptops, smart phones or computers currently assigned on a permanent basis to an officer or member can be recalled for a software audit on a one-week notice. The officer or member must arrange a mutually convenient time when the computer can be returned to the IT department within that week period. Once the audit has been conducted the IT department will either return the computer or inform the officer or member and arrange a collection time and date.

3.5.3 Equipment and Data Destruction

Obsolete equipment shall be checked by IT staff and all hard disks will be thoroughly cleansed of data before disposal, whether by sale, donation or destruction. Equipment will normally be disposed of via a third party accredited data disposal organisation who will ensure recycling, where possible. Any PCs disposed of by sale / donation will not include the operating system installed and no application software. All ICT equipment will be disposed of in accordance with the relevant environmental legislation.

3.5.4 Remote Access to Systems and Data

Where there is a business need, the XXX will allow employees and members to have remote access to data and systems from locations not covered by the XXX local and wide area networks. This will include ‘roaming’ users who with suitable technology are able to access data anywhere and ‘fixed point’ users such as home workers. Access to systems from non-XXX devices, will be controlled via multi factor authentication. The XXX will allow such remote users to make use of their own PC equipment subject to meeting minimum security standards including having up to date anti-virus and firewall software. Remote access to XXX systems will only be granted on the Authority of the relevant Head of Service or Director. Remote access will be only available by using multi factor authentication (i.e. the use of a 2 part password). XXX operates soft tokens which require the use of a unique personal PIN either sent to the work mobile combination with a dynamically generated pass code or generated with a mobile app. Specific conditions and responsibilities will apply to those users:

• data must not be stored on non-XXX devices used for remote access;
• confidential data must be encrypted on storage devices supplied by the ICT department;
• particular care should be taken with removable storage devices such as USB sticks, etc and if these are used to move or transfer data it must be stored in encrypted format using supplied “Safe Sticks”;
• any XXX data downloaded or stored on employees’ remote users’ PC equipment must be kept secure and inaccessible to others. Data must be removed as soon as is practicable when it is no longer required;
• any loss of equipment (own or XXX) must be reported immediately to the ICT Service Desk;
• any actual or perceived security threat relating to remote use of XXX IT systems must be reported immediately to the ICT Service Desk;
• no RESTRICTED information should ever be used on employees / members own equipment.

When undertaking video or conference calls discussing or displaying XXX information, they must ensure that no unauthorised person are privy to that information

3.6 Computer and Network Management

3.6.1 Operational Procedures and Responsibilities

The ICT Manager is responsible for the management and operation of all servers and networks and associated specialised hardware. Departmental managers are responsible for the safe day to day operation of portable and desktop computers and printers issued to them or their staff. Appropriate documented procedures for the management and operation of all servers and networks will be established by computer staff. Clearly documented procedures shall be prepared by computer staff and/or the system administrator for all operational computer systems to ensure their correct, secure operation.

3.6.2 System Planning and Acceptance

Advance planning and preparation are required to ensure the availability of adequate capacity and resources. Acceptance procedures for new systems will include the following:

• performance and computer capacity;
• preparation of error recovery and restart procedures;
• preparation and testing of routine operating procedures;
• evidence that the new system will not adversely affect existing systems, particularly at peak processing times
• training in the operation or use of new systems;
• formal consideration of the need for ongoing maintenance and support by a third party.

Emergency fall back arrangements should be identified for each system and adequate fall-back arrangements made wherever possible. Fall back arrangements for each system should be fully documented and responsibility for this lies with the relevant system administrator.

3.6.3 Configuration and Change Management

Operational changes must be controlled to reduce the risk of system or security failures. The ICT Manager is responsible for ensuring that changes to software or hardware are carried out in a controlled manner and appropriately documented. A formal change control (and authorisation) is in place which requires significant changes to software and hardware to be assessed, tested and verified before completion. This procedure will apply to anyone making such changes including permanent staff, temporary and contract staff, suppliers and third party support organisations. All PCs and servers are configured and installed with a standard security configuration, which may be changed only on the authority of the ICT Manager. Any attempts to amend the standard configuration will be logged and monitored.Specific protective measures are applied to servers accessed by users outside the XXX’s main network. Such servers are in a separate secure zone of the network known as a de-militarised zone or DMZ. Changes to software and hardware will, wherever possible, be applied in a test environment before being applied to operational systems.

3.6.4 Protection from Malicious and Unauthorised Software

It is essential that special measures, as detailed below, are implemented to prevent the introduction of malicious software such as computer viruses, ransomware and malware or the use of unauthorised software. Using unlicensed software can result in a raid (authorised by the courts) to identify the use of such unlicensed software which can result in a fine, adverse publicity and a block on the use of ANY computers until the licences are paid for or the offending software is removed, resulting in very serious disruption to the organisation’s activities. In extreme cases staff could face imprisonment. A computer virus or similar can cause severe damage to data and hence serious disruption. Every precaution must be taken to protect XXX data and programs. Unauthorised software is software that has not been purchased by, or whose purchase or use has not been agreed by the ICT Manager.To reduce the risks of infection or use of unauthorised software the following preventive, detective and corrective measures will be instituted:

• the introduction and/or use of unauthorised software, including screensavers, is prohibited and may lead to the application of relevant, formal disciplinary action;
• software licences will be complied with at all times;
• Reputable, up to date anti-virus software will be used to detect and remove or isolate viruses and malware;
• staff or members must not transfer data from their home PC to the XXX computers, whether by removable storage media or e-mail, unless their home PC has up to date (i.e. definitions updated within the previous week) anti-virus software and firewall installed. The anti-virus software used must be one verified by the XXX’s ICT support staff;
• removable storage media devices are blocked from being connected to corporate devices;
• any suspected viruses must be reported immediately to the computer section and, where appropriate, logged as a security incident;
• except where there is a justifiable business reason that has been expressly agreed with the ICT Manager, users should not open unsolicited e-mails from unverifiable sources and especially any attachments as there is a significant risk, they may contain a virus;
• users must not attempt to download executable files, i.e. program software, from the Internet without prior specific clearance from IT staff;
• any incoming e-mail that contains executable or compressed attachments will be automatically quarantined and routed to IT staff for checking before delivery to the intended recipient.

USB devices and removable media are not allowed on any machine. Device management software is in place to detect and block this type of activity. ICT can provide encrypted USB “safe sticks” for transfer of data, which is prohibited on all machines.

3.6.5 Housekeeping

Housekeeping measures are required to maintain the integrity and availability of services. Routine procedures will be established by computer staff for taking back-up copies of data, logging events and, where appropriate, monitoring the equipment environment. Documented procedures for each system shall include:

• data back-up,
• operator logs,
• fault logging,
• environmental monitoring,
• network and application restart procedures,
• change request logs,
• system updates / upgrades.

3.6.6 Network Management

Appropriate controls must be implemented to ensure the security of data in networks and the protection of connected services from unauthorised access. Each authorised user will be allocated a unique logon identifier by ICT Support staff and a password that the user must change at least every 90 days. The password must contain at least eight characters including a mixture of three of the following four elements (a complex password):

• lower case alpha characters,
• upper case alpha characters,
• numbers,
• special characters.

Access to the network is automatically barred after four successive unsuccessful attempts to logon. Users are responsible for ensuring the secrecy and quality of their password and shall be held responsible for all actions recorded against their unique logon identifier. The ICT Manager is responsible for ensuring the security of the networks.

3.6.7 Media Handling and Security

Computer media containing data shall be controlled and physically protected. Appropriate operating procedures will be established to protect computer media (tapes, disks, cassettes) input / output data and system documentation from damage, theft and unauthorised access. At least one copy of all computer media containing data or critical software will be stored in media fire safes. A copy of all such media should also be kept securely offsite. Computers that rarely physically connect to the network such as laptops or computers provided to members and some officers are not covered under our backup policy and data backups of these computers is the responsibility of the member or officer. A means of backing up the computer and a lesson on how to backup data will be provided by the ICT department

3.6.8 Data and Software Exchange

Exchanges of data or software between the XXX and third parties should be managed in accordance with the Information classification policy. For critical or sensitive data and software, formal agreements, (including software escrow agreements where appropriate) for exchange of data and software (whether electronic or manual) between organisations should be established. These agreements should specify appropriate security conditions which reflect the sensitivity of the information involved, including:

• management responsibilities for controlling and notifying transmission, despatch and receipt,
• minimum technical standards for packaging and transmission,
• courier identification standards,
• responsibilities and liabilities in the event of loss of data,
• data and software ownership and responsibilities for data protection, software copyright compliance and similar considerations,
• technical standards for recording and reading data and software,
• any special measures required to protect very sensitive items
• The use of personal e-mails for sharing of data is prohibited

In order to ensure security of physical media in transit reliable transport couriers should always be used. Packaging should be sufficient to protect the contents from any physical damage during transit and should be in accordance with manufacturers’ instructions. Data in transit should be sealed with tamper proof or evidence devices and have accompanying documentation to list package contents. All electronic commerce should be in accordance with the XXX’s Contract Procedure Rules / Financial Procedure Rules and subject to formal contract(s) drawn up between the XXX and the trading partner(s), including the specialised areas of communication processes, transaction message security and data storage. Managers will need to obtain the appropriate specialised advice upon, identify and take into account all external and internal requirements affecting this activity. These requirements are likely to include the acts and directives listed in section 9.1 of this policy. Also relevant will be international and local (to other countries) laws and directives, any national or international professional regulations such as accounting practice and tax regimes, any conditions specified by the XXX’s insurers, fair trade and human rights standards, and the requisite information and technology standards and controls to preserve the timeliness, accuracy and integrity, security, recoverability and processing of this activity.

3.6.9 Connection to Other Networks

For operational purposes, the XXX will sometimes require access to external networks both to make use of business applications and to exchange data. Access to such networks is only allowed under the following conditions:

• must be authorised by the relevant Head of Service;
• must be agreed by the ICT manager or ICT Security Officer;
• must be protected by a firewall configured to provide protection of all networks concerned;must be subject to a suitable data sharing agreement / contract;
• must have protocols in place to protect data in transit and at rest.

3.6.10 Electronic Mail

Controls to reduce the security risks associated with electronic mail (e-mail) should be implemented covering:

• vulnerability to unauthorised interception or modification. Confidential data should only be sent in encrypted form;
• vulnerability to error, for example incorrect addressing;
• legal considerations such as the need for proof of origin, despatch, delivery and acceptance;publication of directory entries;
• remote access to e-mail accounts.

All staff have internal e-mail facilities, and external e-mail will be made available to all members and those officers with the authorisation of their director or head of service.Users shall avoid responding to unsolicited e-mails from unverifiable sources, and in particular, except where there is a justifiable business reason that has been expressly agreed with the ICT Manager, shall not open such mail or any attachments in such circumstances as there is a significant risk they may contain a virus. IT staff shall monitor usage of e-mail and report any concerns to the appropriate director or head of service. All e-mail sent to external parties shall contain a standard disclaimer inserted by the e- mail system and in a form approved by the XXX’s Legal Officer. All e-mail inbound and outbound will be subject to security scans for spyware, malware and viruses.Electronic e-mail is not to be used via the Outlook App installed on personal devices. Forwarding of e-mails to personal e-mail accounts is prohibited. The use of personal e-mails for sharing of data is prohibited.

3. 6.11 Internet

The use of the Internet on the XXX’s computer systems shall be controlled and monitored to prevent:

• users wasting time and public resources by playing or “surfing” when they are paid to work;
• users accessing sites and importing material which the XXX, as a matter of policy, may find unacceptable;
• users accessing sites and importing illegal material;
• users importing a virus or other malicious software and hence compromising the accuracy, availability and confidentiality of XXX systems;
• users committing the XXX to expenditure in an unauthorised fashion.

Internet access is to be used only for access to sites relevant to work or vocational training during an individual’s working hours . Personal use of the internet is permitted outside of staff’s working hours and is subject to compliance with the XXX’s “Internet and E-mail Access – Conditions of Use” policy document. Internet access and e-mail is provided via a central connection to the internet which incorporates security features (intrusion detection and intrusion prevention) to safeguard the security and integrity of the XXX’s IT systems and data. This connection will always be used by Officers and members located at XXX offices unless specifically authorised to use other methods. The key terms and conditions are as follows:

• Authority to use the Internet and/or e-mail facility will only be granted by the Chief Executive, Directors, Heads of Service or Service Managers.
• All Officers and Members using the facility will be required to sign the “Conditions of Use” document to confirm that they have read and agree to abide by its conditions. A breach of the conditions of use may result in disciplinary action and/or criminal proceedings.
• All “Conditions of Use” forms must be countersigned electronically or manually, by a designated authorising supervisor and completed documents will be held by the IT section and Human Resources section.
• All users of the facility will be issued with their own unique User ID and password and users will be deemed responsible for any activity logged against the user ID so User IDs and passwords should not be disclosed to other persons.
• The XXX maintains logs of activity on our central Internet connection and may analyse and monitor those logs and all internet traffic.

All access to the Internet will be traceable to an originating user ID, both currently and retrospectively. All access and attempted access to the Internet will be logged by the IT section, and comprehensive information on usage, including the time and length of visits, will be supplied on request or in the event of concerns by the ICT Manager, to a user’s director or head of service or Chief Executive in the case of members. The IT section has implemented and maintains an automatic method for restricting which Internet sites may be accessed. No user shall attempt to access an Internet site which, from its address, may reasonably be considered to contain pornographic material or any other material prohibited by the “Conditions of use” policy. The corporate leadership team will define which sites are not to be accessed and any deliberate attempt to access such site/s will be considered in accordance with the disciplinary procedure. Intrusion protection system (IPS) is in place, to detect, monitor, analyse and alert on attempted cyber-attacks. Access to restricted and prohibited sites is automatically monitored and reports of activity will be made available to the user’s director or head of service. A monthly security review will be conducted to ensure security and compliance, led by the ICT security officer. The IT section has implemented and maintains a resilient security gateway device or “firewall” (software and hardware facilities) to control and vet and filter, incoming data to guard against recognized forms of Internet assaults and malicious software. Only IT staff may download software, including freeware from the Internet. This does not apply to documents, i.e. Word, Excel, PDF format.

3.7.1 System Access Control

3.7.1 Business Requirements for System Access

Access to computer services and data should be controlled on the basis of business requirements, but accesses granted to a system should not compromise situations where separation (segregation) of duties is important. Each system administrator will set up the system access rights of each user or group of users according to authorised business needs. Update access rights should be restricted to the minimum number of people commensurate with the need to maintain service levels. System access controls are reviewed by Internal Audit during their routine systems audit work program. Domain privileged access will be reviewed periodically.

3.7.2 User Access Management

Formal procedures will be developed for each system by the system administrator to cover the following:

• formal user registration and de-registration procedure for access to all multi-user IT services;
• restricted and controlled use of special privileges;
• Allocation of passwords securely controlled;ensuring the regular change and where appropriate quality and complexity of passwords;regular review of user access rights and privileged access rights;
• controlled availability of master passwords in emergencies.

User access will be suitably administered to ensure that the type of account granted to employees is such that it allows them to perform their day-to-day user activities and prevents access to any sensitive information not required for the purpose of undertaking their duties. Ensuring members of staff, contractors and third party access to information systems does not exceed the needs of the role on a ‘need to know’ basis; that their use of ICT is appropriate and the starter, leaver and amendments changes are properly processed and authorised. Network accounts which have not been logged into for 90 days will be reviewed and actioned taken. This activity will occur every 90 days to ensure accounts are disabled in quick and secure manner.

3.7.3 User Responsibilities

Effective security requires the co-operation of authorised users. Users must comply with XXX policies, standards and procedures regarding access controls, in particular the use of passwords and the security of equipment. In order to maintain security users must:

• not write passwords down where others may readily discover them;
• not tell anyone else their password/s;
• not use obvious passwords such as their name;
• not let other people observe when entering their password;
• use a password with at least eight characters in it including numeric or special characters;
• promptly change their password if they suspect anyone else may be aware of it;log out of applications if they will be away from their desk for any length of time;
• ‘lock’ their PC when away from their desk to prevent it being used by others (by using Ctrl + Alt + Del keys or the Windows key + L key);
• if working at home the device must be shut down at the end of the day, so that security polices can be applied on next start up and stored in a secure location, when not in use;
• follow the XXX’s ICT security policy (including reading and signing confidentiality and conditions of use agreements);
• restart PCs and laptops as required after the application of security updates;
• report security incidents to the ICT Service Desk;
• not to open e-mails containing suspicions attachments;check e-mail and names of people they received a message from to ensure they are legitimate;report scams, privacy breaches and hacking attempts;
• do not re-use password from other systems.

Staff will be held responsible for all activities logged to their unique user ID.

3.7.4 Network Access Control

Connections to networked services shall be controlled in order to ensure that connected users or services do not compromise the security of any other networked services. The ICT Manager is responsible for the protection of networked services. All machines including servers are patched every month, this is the patch management cycle, to keep our estate up to date and protected. A daily operations check is carried out as part of the daily checks procedure to ensure Antivirus, Antimalware and Anti Spyware updates are up to date on all PCs laptops and desktops. Devices not purchased by the ICT department are not to be plugged into or connected wirelessly to the XXX’s corporate network unless authorised by the ICT Manager or ICT Security officer. All mobile devices and including tablets, laptops and smartphones will be encrypted using device management software.

3.7.5 Computer and Application Access Control

Access to computer facilities should be restricted to authorised users. Computer facilities that serve multiple users should be capable of:

• identifying and verifying the identity of each authorised user, particularly where the user has update access;
• recording successful and unsuccessful attempts to access the system including files and folders;
• providing a password management system which ensures quality passwords;
• where appropriate restricting the connection times of users;controlling user access to data and system functions;
• restricting or preventing access to system utilities which override system or application controls;
• complete ‘lock out’ of user access after a pre-agreed number of unsuccessful attempts to access data.

3.8 Systems Development and maintenance

3.8.1 Security Requirements in Systems

All security requirements, including a risk analysis and the need for fall back arrangements, should be identified at the requirements phase of a project by the officer requesting the system in consultation with computer and audit staff. Security requirements should be justified, agreed and documented. The analysis of security requirements should:

• consider the need to safeguard the confidentiality, integrity and availability of information assets;
• identify controls to prevent, detect and recover from major failures or incidents;
• when specifying that a system requires a particular security feature, the quality of that feature must be specified, e.g. Password controlled – “the password must be held in encrypted format. Passwords must expire after a number of days set by the system administrator, passwords should not be reusable, the system administrator should be able to specify a minimum length and other rules concerning password composition”.

In order to ensure IT staff and users are aware of security controls in place, controls must be explicitly defined by the relevant system administrator in all relevant documentation.

3.8.2 Security of Application System Files

Access to application software, data files and system management files should be formalised and documented according to the sensitivity and importance of the system. Maintaining the integrity of applications is the responsibility of the system administrator who will ensure that:

• strict control is exercised over the implementation of software on the operational system;
• test data is protected and controlled.

3.8.3 Security in Development and Support Environments

All proposed system changes must be reviewed to ensure they do not compromise the security of either the system or operating environment. The ICT Manager is responsible for all operating systems and the appropriate system administrator is responsible for the application. It is essential that both parties work together to ensure the security of application software and data is maintained. Unsupported modifications to packaged software will only be authorised in exceptional circumstances. Wherever possible the required changes should be obtained from the vendor as standard program updates. The implementation of any changes to systems should be strictly controlled using formal change control procedures. All system changes will be documented. It should be a standard that any operational system has separate and secure test, training and development environments.

3.9 Compliance

3.9.1 Compliance with Legal Requirements

The XXX’s statutory obligation to have sound information and cyber security arrangements in place originates in the Indian IT Act 2000, The XXX depends on the confidentiality, integrity and availability of its information and ICT to such an extent however, that a serious breach of information security could impact on the XXX’s ability to deliver a wide range of statutory services. In addition the XXX has contractual obligations to ensure sound security if it is to use the Government Public Services Network (PSN) or receive or share information with partner agencies under information sharing arrangement

3.9.2 Control of Proprietary Software Copying

Proprietary software is usually supplied under a licence agreement which limits the number of users and/or limits the use to a specified machine. Copyright infringement can lead to legal action, fines and adverse publicity. It is XXX policy that no copyright material is copied without the owner’s consent.

3.9.3 Use of Unlicensed Software

Except for freeware, the use of unlicensed software amounts to theft and the XXX’s policy is only to use licensed software. The introduction and/or use of unlicensed software is prohibited and may be treated as gross misconduct.

3.9.4 Safeguarding of the XXX’s Records

Important records must be protected from loss, destruction and falsification. All financial records need to be retained for seven years or more to meet audit requirements. All historic data should be periodically archived by the relevant system administrator with copies being retained in media fire safes on and off site, in accordance with Goverment regulations.

3.9.5 Auditing and logging the use of ICT resources

The XXX maintains audit logs of events taking place across its complete network. This includes, but not limited to:

• user login times;
• details if failed login attempts;
• details of access to data files and software applications (user ID, times);
• details of any privileged access to system;software and hardware configuration changes;
• details of internet web usage and restricted access reports;
• details of files, folder and network access to objects.

3.9.6 Prevention of Misuse of IT Facilities

The XXX’s computer facilities are provided for XXX business or in connection with approved study courses. Staff and members are allowed to use the XXX’s computer facilities for personal use for the following:

• personal use of e-mail in accordance with the “Internet and E-Mail Access – Conditions of Use” policy document;
• access to the Internet, if granted for work purposes, in accordance with the Internet and E-Mail Access – Conditions of Use” policy document;
• limited use of PC software, particularly word processing, in their own time.

The following conditions will apply:

• all private printing must be paid for unless an agreement has been reached with the ICT Manager or the printing service;
• unauthorised or excessive personal use may be subject to disciplinary action;
• The Computer Misuse Act 1990 introduced three criminal offences:
• unauthorised access;
• unauthorised access with intent to commit a further serious offence;
• unauthorised modification of computer material, i.e. alteration, erasure or addition to programs or data.

Users should not attempt to gain access to systems they are not authorised to use or see, as they could face criminal prosecution.

3.9.7 Security Reviews of IT Systems

The internal and external security of IT systems including external penetration testing, will be regularly reviewed and subject to cyber security and penetration testing. The review of security processes will be carried out by Internal Audit, External Audit and managers. ICT will use specialist third parties to perform external and internal security and cyber security health checks, annually in order to maintain the Cyber Essential PLUS accreditation as well as meeting out PSN security obligations. Annual reviews will ensure compliance and assurance with the security policy, standards and best practice.

3.9.8 System Audit Considerations

Audit requirements and activities involving checks on operational systems shall be carefully planned and agreed to minimise the risk of disruptions to business processes. There should be controls to safeguard operational systems and audit tools during system audits. The following are to be observed:

• audit requirements to be agreed with the appropriate manager;
• the scope of any checks to be agreed and controlled;
• checks to be limited to read only access to software and data wherever possible;
• access, other than read only, only to be allowed for isolated copies of system files which must be erased when the audit is completed;
• IT resources for performing checks should be identified and made available;requirements for special or additional processing should be identified and agreed with service providers;
• wherever possible access should be logged and monitored;
• all procedures and requirements should be documented.

Access to system audit tools should be controlled

4.0 IMPLEMENTATION, REVIEWS AND ENFORCEMENT

4.1. Implementation and Reviews

4.1.1. This document shall come into operation once tabled and agreed in management meeting, and approved in its first page, and then shall be considered mandatory for all XXX’s business operations.
4.1.2. XXX’s staff found to have violated this policy may be subject to disciplinary action in accordance with rules defined by XXX’s administrative regulations.
4.1.3. This document shall be reviewed within three years, or whenever business environment of XXXchanges in a way that affects the current policy.

4.2. Exceptions

4.2.1. In case of any exceptions to this policy, it shall be thoroughly documented and follow through a proper channel of authorization using the same authority which approved this document.